Subject: [dhcwg] Follow up on WGLC Comment on draft-ietf-dhc-rfc3315bis-05 - numbering the uplink

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 Dec 2016 14:37:39 +0000

In https://www.ietf.org/mail-archive/web/dhcwg/current/msg17590.html, Tim commented:

Section 17.1.10.1 (-05, this is 18.2.10.1 in the -06 document):

p.60 [p. 58] There was discussion in 6man/v6ops about using a /64 from the delegated prefix for a site for numbering the uplink. I think Jordi’s recent survey of ISPs showed this was more common than expected? So do we want to say MUST NOT assign here?  (I have no strong feeling myself…)

A question for Tim and Lorenzo (and others) is should we do something to relax this “MUST NOT” given the interest in using PD to clients (not just routers).

I think a key point here is not to assign the uplink (delegating) router an address from the delegated prefix on that downlink interface? But that shouldn’t prevent the client itself from assigning an address on that interface from the delegated prefix.

-          Bernie

---

From: Tim Chown <[email-masked]>
Date: Thu, 8 Dec 2016 13:42:19 +0000

On 7 Dec 2016, at 14:37, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

To be specific, the /64-to-the-host context is as per draft-ietf-v6ops-unique-ipv6-prefix-per-host-01.

Indeed, and the above draft describes the process for the host using a /128 from the delegated prefix, and use of DAD, at the end of section 4.

Tim

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Dec 2016 16:42:00 +0000

Tim:

draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 says nothing about using IA_PDs  / DHCPv6 prefix delegation … so not sure it is appropriate to reference it in this context.

The text in draft-ietf-dhc-rfc3315bis-06 section 18.2.10.1 is:

   -  For each delegated prefix, the client assigns a subnet to each of
      the links to which the associated interfaces are attached, with
      the following exception: the client MUST NOT assign any delegated
      prefixes or subnets from the delegated prefix(es) to the link
      through which it received the DHCP message from the server (see
      [RFC6603<https://tools.ietf.org/html/rfc6603>] for exceptions).

RFC 6603 is the prefix-exclude option which allows for a subnet from the delegated prefix to be used.

I wonder if we could change the text above to read:

   -  For each delegated prefix, the client assigns a subnet to each of
      the links to which the associated interfaces are attached, with
      the following exception: the client MUST NOT advertise any delegated
      prefixes or subnets from the delegated prefix(es) to the link
      through which it received the DHCP message from the server (see
      [RFC6603<https://tools.ietf.org/html/rfc6603>] for exceptions).

The change here is “assign” to “advertise” (as in send a router advertise with a PIO on that link). This would allow the client to “assign” the subnet to that link, but just not advertise it on that link.

If you want to suggest better and more clear wording than just that single word change or that wasn’t the intention, please do!

-          Bernie

From: Tim Chown [mailto:[email-masked]]
Sent: Thursday, December 08, 2016 8:42 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; [email-masked]
Subject: Re: Follow up on WGLC Comment on draft-ietf-dhc-rfc3315bis-05 - numbering the uplink

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Dec 2016 18:58:11 +0900

On Sat, Dec 10, 2016 at 1:42 AM, Bernie Volz (volz) <[email-masked]> wrote:

>       [RFC6603 <https://tools.ietf.org/html/rfc6603>] for exceptions).
>
>
>
> The change here is “assign” to “advertise” (as in send a router advertise
> with a PIO on that link). This would allow the client to “assign” the
> subnet to that link, but just not advertise it on that link.
>
>
>
> If you want to suggest better and more clear wording than just that single
> word change or that wasn’t the intention, please do!
>

Your suggested text works for me.

That said, I'm not entirely sure there's a conflict here. I think the
expected model for prefix-per-host is that that the host would get a /64
from a delegating router or server, assign it to a loopback or internal
virtual interface, and potentially use one or more of the addresses in that
/64 on the link through which it received. This model would conflict with
the current text only if using an IPv6 address from that /64 counts as
"assigning a subnet from the delegated prefix". Perhaps it does, and even
if it doesn't, it may be better to go with your suggested text anyway.

---

From: Tim Chown <[email-masked]>
Date: Wed, 14 Dec 2016 11:33:04 +0000

On 13 Dec 2016, at 09:58, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Dec 10, 2016 at 1:42 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I wonder if we could change the text above to read:

That said, I'm not entirely sure there's a conflict here. I think the expected model for prefix-per-host is that that the host would get a /64 from a delegating router or server, assign it to a loopback or internal virtual interface, and potentially use one or more of the addresses in that /64 on the link through which it received. This model would conflict with the current text only if using an IPv6 address from that /64 counts as "assigning a subnet from the delegated prefix". Perhaps it does, and even if it doesn't, it may be better to go with your suggested text anyway.

I think Bernie’s text is fine.

Tim