Re: [v6ops] RigDir review: draft-ietf-v6ops-host-addr-availability

[Geoff Huston <[e-mail]>]

> On 10 Mar 2016, at 12:59 AM, Lorenzo Colitti <[e-mail]> wrote:
> 
> Geoff,
> 
> I've teed up the other fixes for review by my coauthors, but I have a question about this one.
> 
> >     2. The Recommendations section could include consideration of routing / cache scaling.
> >
> >     The recommendations in Section 8 do not include some recommendations related to the management of MAC to IPv6 address bindings, and indeed on the nature of these provisioned multiple addresses. I was expecting to see either some level of admonition of a practice of "chequerboarding" the address space, where multiple hosts on a network are provisioned with discrete /128 addresses, or a particular recommendation relating to the use of prefix delegation as this allows more efficient forms of MAC to address binding, and limits the level of propagation of individual host routes in the network
> >
> > The current text on DHCPv6 PD is a compromise. Previous versions contained stronger language in support of DHCPv6 PD, but a small number of WG participants felt that it was not acceptable to recommend DHCPv6 PD in a BCP document because of the lack of widespread support in current host operating systems. The draft already makes these scaling recommendations in section 9.3, though. Is that not sufficient?
> >
> 
> 
> ** perhaps you may instead want to add the advice as a final sentence to the third paragraph:
> 
> "For these reasons the use DHCPv6 PD, where available, represents a more operationally prudent approach.”
> 
> Which does not contain an explicit recommendation, but does state a preference with associated justification.
> 
> Where do you suggest we put this text? At the end of section 8 or at the end of section 9.3? (They both have three paragraphs).


I thought at the end of section 9.3
> 
> I'm leery of using the exact words "operationally prudent" because there was a vocal minority in the WG that maintained that DHCPv6 PD is not known to be operationally feasible due to lack of deployment. However, it's indisputable that DHCPv6 PD suffers from none of the ND cache scaling problems that affect shared links, so we could definitely make that statement. It also might be worth mentioning that, on networks where the client is uniquely identified by its MAC address, such as 802.11 networks in infrastructure mode, SLAAC with a dedicated prefix has the same attractive scaling properties.

how about:

“From the considerations of ND cache scaling the use of DHCPv6 PD would represent an operationally prudent approach, as would SLAAC with a dedicated prefix to be associated with a single MAC addresses where MAC addresses are used as link layer identifiers.”

would this work?

Geoff