Subject: [v6ops] draft-templin-v6ops-pdhost a working group draft?

From: Fred Baker <[email-masked]>
Date: Thu, 16 Nov 2017 10:19:33 +0800

At IETF 100, we discussed this document. The “hum” regarding adoption was slightly in favor, but not clear. However, we had one comment that IF it were adopted, it needs to be expanded to be an architectural document describing /64-to-the-host deployments.

Shall we adopt it as a working group draft?

Sent using a machine that autocorrects in interesting ways...

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 16 Nov 2017 02:30:34 +0000

Does this mean that the document desires to include all the dynamics of address assignment subscriber management when PD is used? (i.e. subscriber vs address correlation state, identification of the subscriber/host, etc...)?

If that is a yes, then this is something I think that this easily will result in a too wide scope and boiling the ocean. I think before deciding to adopt or not, it would be great to understand the exact scope intended. (I know for a fact that configuration guide of vendors regarding subscriber management tend to be huge and lengthy (+1000 pages) documents). I want to make sure that v6ops progresses with a pragmatic document of value to operators and not a pure academic exercise.

G/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, November 16, 2017 10:20
To: [email-masked]
Subject: [v6ops] draft-templin-v6ops-pdhost a working group draft?

Sent using a machine that autocorrects in interesting ways...
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 03:33:40 +0100

I support, under the condition that a few problems are fixed at various 
providers.

This is not a problem at operator.  With this draft most things happen 
in the end-user device; the operator may provide DHCPv6 service that 
could be tested; if the first condition is met (see first line of this 
message) then it's a success.

Also, if this runs on VPN then there is really no problem to deploy it, 
and it seems some running code is there already.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Nov 2017 05:35:04 +0000

Hi Gunter,

> From: v6ops [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
> Sent: Wednesday, November 15, 2017 6:31 PM
> To: Fred Baker <[email-masked]>; [email-masked]
> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
> 
> Does this mean that the document desires to include all the dynamics of address assignment subscriber management when PD is
> used? (i.e. subscriber vs address correlation state, identification of the subscriber/host, etc...)?

This draft is about what a host can do internally when it gets a prefix delegation
through whatever means. It lists DHCPv6 PD as an example PD service, but does
not impose any special requirements on the delegating router in the operator's
network. The host is required to participate in the client-side prefix delegation
control messaging specified by the prefix delegation service, however.

Thanks - Fred

> If that is a yes, then this is something I think that this easily will result in a too wide scope and boiling the ocean. I think before deciding
> to adopt or not, it would be great to understand the exact scope intended. (I know for a fact that configuration guide of vendors
> regarding subscriber management tend to be huge and lengthy (+1000 pages) documents). I want to make sure that v6ops progresses
> with a pragmatic document of value to operators and not a pure academic exercise.
> 
> G/
> 
> At IETF 100, we discussed this document. The “hum” regarding adoption was slightly in favor, but not clear. However, we had one
> comment that IF it were adopted, it needs to be expanded to be an architectural document describing /64-to-the-host deployments.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Nov 2017 05:41:09 +0000

Hi Alex,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, November 15, 2017 6:34 PM
> To: [email-masked]

Yes, that is right. PD-capable DHCPv6 servers have been available for a
long time and the ones I have tested work great. But, as you say, this
document concerns what a host does with a delegated prefix once it
receives one and not so much about the prefix delegation service itself.

> and it seems some running code is there already.

Yes, I have been doing DHCPv6 PD over VPN on Android for a long time.
The DHCPv6 server robustly provides the prefix and sets up the routing,
and the Android uses it for multi-addressing on the VPN interface according
to the strong end system (strong host) model per this document.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Nov 2017 05:55:54 +0000

Hi Fred,

> Sent: Wednesday, November 15, 2017 6:20 PM
> To: [email-masked]

The way I understood the comment was that the draft needs more supporting
text on the rationale for doing what the document describes (e.g., the benefit
for not having to place the upstream interface in promiscuous mode, efficiencies
for not doing link-scoped multicasting over the upstream interface, avoiding
disturbance of other nodes on the upstream link, etc.

I did not think the comment was asking to expand the document to cover all
methods of conveying a /64 to the host (e.g., unique-ipv6-prefix-per-host,
3GPP, etc.). This document only concerns methods that meet the description
of prefix delegation as described for examples such as DHCPv6 PD.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 21:21:02 +1300

> This draft is about what a host can do internally when it gets a prefix delegation

What is a bit confusing is whether, having acquired a prefix, it's going
to turn itself into a forwarding device. If so, surely there is nothing
to say except that IPv6 router requirements apply. (Which does not
mean it's going to run a routing protocol, since it can default route
everything to its upstream. But things like redirects are covered by
6434(bis), which also mandates that routers must send RAs etc.)

So I guess my point is: what is specific to a host about the discussion
in this document? Just to take an example, in section 4:

   When the node receives the prefix, it can distribute the prefix to
   downstream networks and configure one or more addresses for itself on
   downstream interfaces.  The node then acts as a router on behalf of
   its downstream networks and configures a default route via a neighbor
   on an upstream interface.

So that is describing what a *router* does, not what a host does.

If it's *not* going to be a forwarding device, I wonder what it's
going to use the prefix for? Also in section 4:

   The node could instead (or in addition) use portions of the delegated
   prefix for its own multi-addressing purposes.  In a first
   alternative, the node can assign as many addresses as it wants from
   the prefix to virtual interfaces.  In that case, applications running
   on the node can use the addresses according to the weak end system
   model.

Fair enough. But it's very confusing to mix the end host behaviours
in with the router behaviours. And since a lot of the document is
about router behaviours, the document title itself is confusing.
(I don't agree with Lorenzo that the host/router distinction is
confusing in itself.)

I suggest
(a) changing the title. Something like "IPv6 Prefix Delegation Models".
(b) refactoring the contents to clearly separate the router-like
    and host-like behaviours.

Also, perhaps, identify any points that would be better moved
into 6434bis (or 6434ter).

With those changes I'd be happy to see this as a WG draft.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Nov 2017 08:47:53 +0000

Brian, thank you for your constructive input. Bob Hinden and others have also
been consistently reminding me about the host/router distinction and I have
not been ignoring them - I just didn't know how to speak to the distinction.
But, your input gives some useful clues.

Some comments and questions below:

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, November 16, 2017 12:21 AM
> To: Templin, Fred L <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]>; Fred Baker <[email-masked]>; [email-masked]

My understanding is that routers only send RAs over advertising
interfaces, and nodes that receive prefix delegations over an
upstream interface would not configure that interface as an
advertising interface. So, I agree that the delegating router
would send RAs, but the requesting router would not send RAs
over the upstream interface. But, perhaps you did not mean to
imply otherwise?

> So that is describing what a *router* does, not what a host does.

Yes. Even though it may be a "host-like" device like my laptop or cellphone
if it forwards packets that are not explicitly addressed to itself it is a router.

> (a) changing the title. Something like "IPv6 Prefix Delegation Models".

OK.

>     and host-like behaviours.

I think I can do that.

> into 6434bis (or 6434ter).

Can you give some examples of what could be moved there?

> With those changes I'd be happy to see this as a WG draft.

Thanks for raising these points.

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 22:01:03 +1300

> over the upstream interface. But, perhaps you did not mean to

No, that sounds right.

> if it forwards packets that are not explicitly addressed to itself it is a router.

Exactly.
 
> Can you give some examples of what could be moved there?

Not really, that would require some close study. But if you
have identified some behaviour that is in practice required,
but is not already implicitly or explicitly covered in 6343bis,
surely it belongs there?

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Nov 2017 21:05:16 +0800

> On 16/11/2017 18:35, Templin, Fred L wrote:
[....]
> With those changes I'd be happy to see this as a WG draft.

I agree with these.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fred Baker <[email-masked]>
Date: Sun, 19 Nov 2017 17:27:49 -0800

One comment on the draft in question.

Looking at figure 1 (applies to all of the figures, but let me be specific for the purposes of a comment) I don't see any reason to believe that the node marked "Delegating Router" is in fact a router or is connected directly to the "Upstream Interface". AFAIK, given the relay capability present in RFC 3315, the common practice is to have a more central server respond to IA_NA and IA_PD requests, and simply have a router connected on the ISP link. That might get complex to draw in a figure, but I'd worry about any implicit assumption in the WG version of the document that only routers implemented the PD service.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 10:36:29 +0900

+1, in most scenarios the delegating node does not have an interface
connected to the requesting node.

On Mon, Nov 20, 2017 at 10:27 AM, Fred Baker <[email-masked]>
wrote:

> Looking at figure 1 (applies to all of the figures, but let me be specific
> for the purposes of a comment) I don't see any reason to believe that the
> node marked "Delegating Router" is in fact a router or is connected
> directly to the "Upstream Interface". AFAIK, given the relay capability
> present in RFC 3315, the common practice is to have a more central server
> respond to IA_NA and IA_PD requests, and simply have a router connected on
> the ISP link. That might get complex to draw in a figure, but I'd worry
> about any implicit assumption in the WG version of the document that only
> routers implemented the PD service.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 10:42:19 +0900

> of prefix delegation as described for examples such as DHCPv6 PD.

FWIW my comment at the mike was asking for the latter as well. There are
many ways that a host can get a dedicated prefix, and we should provide
guidance on what a host should do in this situation. Also if we look at
current deployments, way more hosts get dedicated prefixes via RAs then via
PD: all 3GPP networks provide a dedicated prefix, and very few hosts
implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD is focusing on
a niche use case.

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 09:42:58 +0100

Lorenzo,

> FWIW my comment at the mike was asking for the latter as well. There are many ways that a host can get a dedicated prefix, and we should provide guidance on what a host should do in this situation. Also if we look at current deployments, way more hosts get dedicated prefixes via RAs then via PD: all 3GPP networks provide a dedicated prefix, and very few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD is focusing on a niche use case.

The "dedicated" prefix over 3GPP networks is not something that you can generalise right?
It is a property implied by that particular link-layer.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 17:50:09 +0900

> It is a property implied by that particular link-layer.

I think there are properties we can generalize such as "hosts don't need to
send DAD packets to the network for any address formed from that prefix",
"hosts can likely form as many IPv6 addresses from that prefix without
causing ND cache scaling issues in the network", "hosts can use RFC 7278
tethering safely", etc.

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 11:07:02 +0100

> On 20 Nov 2017, at 09:50, Lorenzo Colitti <[email-masked]> wrote:
> 
> I think there are properties we can generalize such as "hosts don't need to send DAD packets to the network for any address formed from that prefix", "hosts can likely form as many IPv6 addresses from that prefix without causing ND cache scaling issues in the network", "hosts can use RFC 7278 tethering safely", etc.

I really don't want to see the hack of 7278 spread further.
My point was that there is no way for the host to know this prefix is dedicated to it, apart from making a guess based on data-link layer type.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 19:21:14 +0900

On Mon, Nov 20, 2017 at 7:07 PM, Ole Troan <[email-masked]> wrote:

> > I think there are properties we can generalize such as "hosts don't need
> to send DAD packets to the network for any address formed from that
> prefix", "hosts can likely form as many IPv6 addresses from that prefix
> without causing ND cache scaling issues in the network", "hosts can use RFC
> 7278 tethering safely", etc.
>
> My point was that there is no way for the host to know this prefix is
> dedicated to it, apart from making a guess based on data-link layer type.
>

Sure, in general there is no way for the host to know (at least currently).
But there are lots of things that we can say the host can/should do if it
does know that the prefix is dedicated to it. Two ways it can know are a)
it's a 3GPP link and b) it received a prefix delegation.

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 11:39:25 +0100

Lorenzo,

> Sure, in general there is no way for the host to know (at least currently). But there are lots of things that we can say the host can/should do if it does know that the prefix is dedicated to it. Two ways it can know are a) it's a 3GPP link and b) it received a prefix delegation.

Right. Which goes back to your point that there are currently many ways for a host to get a dedicated prefix. No, there isn't. There is really only one that is generic. Two if you count 6rd. Three if you include manual configuration.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Nov 2017 12:30:48 +0100

Hi Fred,

If you refer to the danir draft, we could add a small cloud, or a few
dots, to say there are many intermediary routers in between.

About the question in the Topic line "who implements the DHCP service".

There is at least one trial in cellular network that has DHCP Service on
the PGW (I copy the relevant person).

Some earlier modem in Huawei E392 USB key (User Equipment) may host a
'proxy' DHCP Server that replies to Requests issued by the linux
computer.  We are checking that now to be sure.

The modem Qualcomm QDSP6 MDM9207 (a modem present in many smartphones)
does not 'support' DHCPv6; the ticket response person recommends the use
of RS/RA instead of DHCP.  By 'not support' one should read that it does
not implement a DHCPv6 proxy (like the Huawei does), and it blocks
DHCPv6 Solicit that is multicast and is port 547 (does not block DHCPv6
Solicit unicast 547, nor multicast 24683).

On the ARM part of the Sierra module WP76xx (a recent IoT device), and
on Android Huawei Mate 8, we do support DHCPv6 clients with Prefix
Delegation feature.

For home, small boxes like openwrt do have odhclient with prefix
delegation feature.

There are at least three independent publicly available open-source
DHCPv6 clients with PD feature.

Alex

Le 20/11/2017 à 02:27, Fred Baker a écrit :
> Looking at figure 1 (applies to all of the figures, but let me be 
> specific for the purposes of a comment) I don't see any reason to 
> believe that the node marked "Delegating Router" is in fact a router
>  or is connected directly to the "Upstream Interface". AFAIK, given 
> the relay capability present in RFC 3315, the common practice is to 
> have a more central server respond to IA_NA and IA_PD requests, and 
> simply have a router connected on the ISP link. That might get 
> complex to draw in a figure, but I'd worry about any implicit 
> assumption in the WG version of the document that only routers 
> implemented the PD service.
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Nov 2017 13:18:35 +0100

Hi,

On Mon, Nov 20, 2017 at 11:39:25AM +0100, Ole Troan wrote:
> Right. Which goes back to your point that there are currently
> many ways for a host to get a dedicated prefix. No, there isn't.
> There is really only one that is generic. Two if you count 6rd.
> Three if you include manual configuration.

Four, as soon as we've added appropriate functionality to OpenVPN
(the need to be able to "number more things than just the VPN-pointing
interface" is clearly there, as in all other "/64 to the host" examples,
but the mechanics are not there, and not very well understood either)

So it's reasonable to spend a bit of thinking on "what would a host do
with a /64 if it knew it's all reserved for itself"

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 23:09:06 +0900

> but the mechanics are not there, and not very well understood either)

Great to hear you're working on this. A while ago I asked around to see if
there were any VPN providers that handed out more than a single /128 and I
couldn't find any. Once this is supported in OpenVPN it might be easier for
providers to offer it.

> with a /64 if it knew it's all reserved for itself"

One thing we're thinking of is to give apps an API to create new IPv6
addresses for their own use. This is only really useful if the prefix is
dedicated to the host, as doing this on a shared prefix may not work and
may end up causing scaling issues to the network.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 17:38:12 +0000

Hi Fred,

The figures are derived directly from RFC3633, Section 5.1. Please see that
document for the answers to your questions.

Thanks - Fred

> From: Fred Baker [mailto:[email-masked]]
> Sent: Sunday, November 19, 2017 5:28 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Who implements the DHCP service?
> 
> Looking at figure 1 (applies to all of the figures, but let me be specific for the purposes of a comment) I don't see any reason to believe
> that the node marked "Delegating Router" is in fact a router or is connected directly to the "Upstream Interface". AFAIK, given the
> relay capability present in RFC 3315, the common practice is to have a more central server respond to IA_NA and IA_PD requests, and
> simply have a router connected on the ISP link. That might get complex to draw in a figure, but I'd worry about any implicit assumption
> in the WG version of the document that only routers implemented the PD service.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 17:49:51 +0000

We have DHCPv6 PD working with OpenVPN on Android today - have
been using it for the better part of two years. We are currently using
the kea DHCPv6 server and it works great, but I am sure the many
other publicly-available DHCPv6 servers could work as well.

The DHCPv6 client piece in OpenVPN is a few hundred lines of code
and was not hard to implement. And, if the client needs to do
something to request, manage and maintain a delegated prefix it
might as well be DHCPv6.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Monday, November 20, 2017 4:19 AM
> To: Ole Troan <[email-masked]>
> Cc: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Nov 2017 19:15:46 +0100

Hi,

> something to request, manage and maintain a delegated prefix it

So what does your patch *do* with the received prefix (since it's 
an out of tree patch I haven't seen yet)?  "Just configure it on the
tun interface" (you do not need DHCPv6-PD for that)?

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Nov 2017 19:19:49 +0100 (CET)

> with a /64 if it knew it's all reserved for itself"

We did some of this thinking in the PIO-X draft in 6man. It's not 
complete, but there is some thinking about it...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 18:32:53 +0000

Hi Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Monday, November 20, 2017 10:16 AM
> Cc: Gert Doering <[email-masked]>; Ole Troan <[email-masked]>; [email-masked]

It configures addresses derived from the prefix and assigns them
to the tun interface. It does not join the solicited-node multicast
address nor perform DAD over the tun interface.

Right now, it is only assigning a single address but it can in fact assign
as many addresses as it wants as shown in Figure 3 of 'pdhost'
without having to invoke MLD or DAD.

Do you want to see our code?

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Nov 2017 19:37:55 +0100

Hi,

> address nor perform DAD over the tun interface.

So where's the benefit of doing DHCPv6-PD here?  *This* is a function
OpenVPN can do out of the box just fine... *scratch head*

Single address, or "many"?

> Do you want to see our code?

It would be nice to have a look, but the "do DHCPv6-PD handshake" is not
the really challenging bit - "do something interesting with the prefix"
is...

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 18:56:29 +0000

Hi Gert,

> Sent: Monday, November 20, 2017 10:38 AM

There is nothing particularly challenging about assigning multiple addresses
from the prefix to the tun interface (tens, hundreds, thousands or more if
you'd like) - although that in itself would be very interesting. Again, see
Figure 3 of 'pdhost' along with the  supporting text.

Thanks - Fred

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 21 Nov 2017 16:38:12 +0100

Hello Fred,

You could find interesting, that the danir draft describes, how the prefixes are obtained via DHCPv6 and are advertised on the links. Precisely, multiple IPv6 Global Unique Network Prefixes (GUNPs) are derived from the GUNPs pool and are advertised on the multiple links.

&gt; configures addresses derived from the prefix and assigns them 

&gt; to the tun interface. It does not join the solicited-node multicast 

&gt; address nor perform DAD over the tun interface. 

At this moment, the implementation, described by the danir draft (the code), is able to advertise multiple GUNPs, derived from the GUNPs pool, on the multiple links.

&gt; Right now, it is only assigning a single address but it can in fact assign 

&gt; as many addresses as it wants as shown in Figure 3 of 'pdhost' 

&gt; without having to invoke MLD or DAD. 

Also I suppose, you could find useful, that danir draft describes the DHCPv6 implementation without VPNclient usage on the UE side:

&gt;&gt;The DHCPv6 client piece in OpenVPN is a few hundred lines of code 

&gt;&gt;and was not hard to implement. And, if the client needs to do 

&gt;&gt;something to request, manage and maintain a delegated prefix it 

&gt;&gt;might as well be DHCPv6. 

&gt;&gt; Fred.

&gt;&gt;There is at least one trial in cellular network that has DHCP Service on 

&gt;&gt;the PGW (I copy the relevant person). 

&gt;&gt;On the ARM part of the Sierra module WP76xx (a recent IoT device), and 

&gt;&gt;on Android Huawei Mate 8, we do support DHCPv6 clients with Prefix 

&gt;&gt;Delegation feature. 

&gt;&gt;Alex.

---- On Mon, 20 Nov 2017 19:32:53 +0100 Templin, Fred L &lt;[email-masked]&gt; wrote ----

Hi Gert, 

&gt; -----Original Message----- 

&gt; From: Gert Doering [mailto:[email-masked]] 

&gt; Sent: Monday, November 20, 2017 10:16 AM 

&gt; To: Templin, Fred L &lt;[email-masked]&gt; 

&gt; Cc: Gert Doering &lt;[email-masked]&gt;; Ole Troan &lt;[email-masked]&gt;; [email-masked] 

&gt; Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? 

&gt; 

&gt; Hi, 

&gt; 

&gt; On Mon, Nov 20, 2017 at 05:49:51PM +0000, Templin, Fred L wrote: 

&gt; &gt; We have DHCPv6 PD working with OpenVPN on Android today - have 

&gt; &gt; been using it for the better part of two years. We are currently using 

&gt; &gt; the kea DHCPv6 server and it works great, but I am sure the many 

&gt; &gt; other publicly-available DHCPv6 servers could work as well. 

&gt; &gt; 

&gt; &gt; The DHCPv6 client piece in OpenVPN is a few hundred lines of code 

&gt; &gt; and was not hard to implement. And, if the client needs to do 

&gt; &gt; something to request, manage and maintain a delegated prefix it 

&gt; &gt; might as well be DHCPv6. 

&gt; 

&gt; So what does your patch *do* with the received prefix (since it's 

&gt; an out of tree patch I haven't seen yet)? "Just configure it on the 

&gt; tun interface" (you do not need DHCPv6-PD for that)? 

Thanks - Fred 

&gt; Gert Doering 

&gt; -- NetMaster 

&gt; -- 

&gt; have you enabled IPv6 on something today...? 

&gt; 

&gt; SpaceNet AG Vorstand: Sebastian v. Bomhard 

&gt; Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann 

&gt; D-80807 Muenchen HRB: 136055 (AG Muenchen) 

&gt; Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 

v6ops mailing list 

[email-masked]