Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-v6ops-host-addr-availability-05.txt
Reviewer: Geoff Huston	 
Review Date: 3 March 2016 
IETF LC End Date: 9 March 2016 
Intended Status: BCP

Summary: 

    I have some minor concerns about this document that I think should be resolved before publication.

Comments:

    BCP documents cover a wide range of purposes - some limit themselves to documenting current operational practices. Other advocate the adoption of operational practices that may not be in widespread use at present. It appears that this document falls into the latter category as it exposes that network operators provide a IPv6 service that admits the provision of multiple addresses at connection time.

   The draft has generated considerable discussion in the V6ops Working Group, principally relating to the description of the available technology to perform such provisioning.

   Section 9.3 comments on Routing, but actually considers the layer 2 issue of the binding of L2 MAC addresses to IP addresses, noting that in a totally unconstrained environment it is possible to encounter scenarios where the number of bindings exceed the capacity of the network devices. The solution offered, using a single binding entry that binds a MAC address to a /64 prefix would obviate this problem and also obviate the need to perform ND and DAD when selecting additional local addresses, but the document does not make any reference to current router behaviour and the treatment of multi-addressed hosts. 

Major Issues:

    No major issues found.

Minor Issues:

    1. The Security Considerations section is empty, while the document explicitly discusses issues relating to the operational integrity of networks that has an impact on the security of the service.

    I find it rather anomalous that section 9.3 describes a potential scenario that would impact the operational integrity of a network, yet the Security Considerations says “None so far.” As an absolute minimum it would be reasonable to this reviewer to have the Security Considerations section reference the considerations described in Section 9.3 as a potential source of operational instability under certain circumstances. (While it is not part of a routing-related review I also note that Section 9.1 talks about security issues as well)

    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

Nits:

    1. Introduction:
    --  “virtually unlimited amount of address space” is a very imprecise term, and historically its been proved wrong when claimed for other large spaces. Could the authors think of another term that avoids any use of the word “unlimited”?

    --  “future applications” is not a benefit per se, at least not grammatically correct one. “flexibility to accommodate future applications’ needs” might be closer to what the author intended.

    --  “the ability to deploy the Internet” - surely this is about “the ability to deploy IPv6-based Internet services” instead?

   4. Problems…

    --  "Reasons might include hardware limitations” - begs the inclusion of a forward reference to section 9.3