Subject: [RTG-DIR] RigDir review: draft-ietf-v6ops-host-addr-availability

From: Geoff Huston <[email-masked]>
Date: Thu, 3 Mar 2016 16:54:56 +1100

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 5 Mar 2016 19:44:19 +0000

Thanks Geoff.

Lorenzo et al: the draft is right now in IETF Last Call. When that ends, you will want to update it to address those comments. Include this, please.

> On Mar 3, 2016, at 6:54 AM, Geoff Huston <[email-masked]> wrote:
> 
> Hello,
>

---

From: Geoff Huston <[email-masked]>
Date: Mon, 7 Mar 2016 18:59:10 +1100

> On 7 Mar 2016, at 4:23 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Mar 3, 2016 at 2:54 PM, Geoff Huston <[email-masked]> wrote:
> 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.
> 
> I think an important point to note is that the vast majority of IPv6 networks (certainly in terms of number of devices) already does this. This is stated pretty clearly in section 2:
> 
>    In most general-purpose IPv6 networks, including all 3GPP networks
>    ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC
>    [RFC4862], IPv6 hosts have the ability to configure additional IPv6
>    addresses from the link prefix(es) without explicit requests to the
>    network.
> 
> The main goal of this document is to observe that the majority of IPv6 use is on devices that *do* have access to multiple addresses, and that this provides many benefits, and to recommend that networks provide multiple addresses regardless of what address provisioning methodology is in use.

** This was a general comment on my part - no changes in the text was proposed, so I accept your observation.

> How about this?
> ====
> As mentioned in section 9.3, on shared networks using SLAAC it is possible for devices to attempt to exhaust network resources and possibly deny service to other devices by creating unreasonable numbers (e.g., hundreds or thousands) of addresses. Networks that provide access to untrusted devices can mitigate this threat by providing a dedicated /64 prefix per device. It is also possible to mitigate the threat by limiting the number of ND cache entries that can be created for a particular device, but care must be taken to ensure that the network does not restrict the IP addresses available to non-malicious devices.
> 
> Security issues related to host tracking are discussed in section 9.1.
> ====

** Yes, I agree with this proposed text for the Security Considerations section.

> 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.

> I've tried to address these in the next version.

** Great, thanks Lorenzo.

  regards,

    Geoff

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 7 Mar 2016 14:23:50 +0900

On Thu, Mar 3, 2016 at 2:54 PM, Geoff Huston <[email-masked]> wrote:

> 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.
>

I think an important point to note is that the vast majority of IPv6
networks (certainly in terms of number of devices) already does this. This
is stated pretty clearly in section 2:

The main goal of this document is to observe that the majority of IPv6 use
is on devices that *do* have access to multiple addresses, and that this
provides many benefits, and to recommend that networks provide multiple
addresses regardless of what address provisioning methodology is in use.

    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)
>

How about this?

====
As mentioned in section 9.3, on shared networks using SLAAC it is possible
for devices to attempt to exhaust network resources and possibly deny
service to other devices by creating unreasonable numbers (e.g., hundreds
or thousands) of addresses. Networks that provide access to untrusted
devices can mitigate this threat by providing a dedicated /64 prefix per
device. It is also possible to mitigate the threat by limiting the number
of ND cache entries that can be created for a particular device, but care
must be taken to ensure that the network does not restrict the IP addresses
available to non-malicious devices.

>     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?

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…
>

Cheers,
Lorenzo