Last Call Review of draft-ietf-v6ops-host-addr-availability-05
review-ietf-v6ops-host-addr-availability-05-rtgdir-lc-huston-2016-04-07-00

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