Last Call Review of draft-ietf-v6ops-host-addr-availability-05

Request Review of draft-ietf-v6ops-host-addr-availability
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-03-09
Requested 2016-02-27
Authors Lorenzo Colitti, Vinton Cerf, Stuart Cheshire, David Schinazi
Draft last updated 2016-03-08
Completed reviews Genart Last Call review of -05 by Roni Even (diff)
Opsdir Last Call review of -05 by Victor Kuarsingh (diff)
Opsdir Telechat review of -06 by Victor Kuarsingh (diff)
Rtgdir Last Call review of -05 by Geoff Huston (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-ietf-v6ops-host-addr-availability-05-opsdir-lc-kuarsingh-2016-03-08
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2016-03-08


Dear Authors,

I have reviewed this document as part of the Operational directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written with the intent of improving the 

operational aspects of the IETF drafts. Comments that are not addressed 

in last call may be included in AD reviews during the IESG review.  

Document editors and WG chairs should treat these comments just like any 

other last call comments.

Document Reviewed - Host address availability recommendations

Link to Document -


The document is focused on a  recommendation to provide hosts 

(generally) with multiple IPv6 addresses and remove the need for 

overhead needed for a host to be able to attain additional addresses 

(i.e. provisioning cycles or special requests).  The document stresses 

the limitations that can arise with lack of multiple IPv6 addresses 

available to a host, and explores related topics around the number of 

addresses needed/desired, NAT challenges if used, and options for 

providing multiple addresses.

General Comments and Feedback:

The document is generally well writen and has gone through WG review.  

The document did include an operational considerations section which was 

expanded upon and did cover some needed operational topics.  One 

additional area may need to be made note of, and that’s covered in my 

additional feedback and captured in the textual review below.

The general recommendation of providing additional addresses to hosts is 

made clearly, but there are also some subtle recommendations / 

requirements that may add additional administrative requirements for 

operators should they ensure some of the more subtle recommendations are 


The key additional recommendation is the supply of /64s to a host (i.e. 

in Section 8 and Section 9.2).  To me, this seems like a sound and 

viable practice and does remove many of the scaling challenges which may 

arise if many hosts then acquire many address in a common L2/L3 domain.  

However, the ability to supply the needed addressing (or more 

importantly the right size blocks to support this model) is variable per 

environment.  Such models may work well by default in 3GPP/Mobile, WiFi 

or in DSL like environments where there is a high degree of aggregation 

to a Layer-3 boundary (therefore the need to supply complicated address 

planning may not be burdensome).

However, in other network environments, where Layer-3 is highly 

distributed, ensuring there are enough block resources at key 

aggregation points to support the addressing models desired can require 

significant planning on the operator’s part.  I think this is a valid 

ask, but this point should be made clearly in the operational 

considerations section.  It will require more then trivial actions to 

ensure this type of model is successful.  Even for enterprises, planing 

around such models may be a stretch to what the designers / 

administrators are used to. However, as noted by the authors, practical 

deployments do exist in the enterprise by which it demonstrates viability.

Some additional considerations for operators would also include the need 

the ensure the DHCPv6 system (when / where used) is also maintained to 

support this model.  Where the layer-3 network is highly distributed, 

the planning is not only around ensuring enough blocks are made 

available to have support the recommendation, but the DHCPv6 system 

would then also need to be maintain to match that model (i.e. DHCP 

superscope). This is not a major issue for operators (making sure there 

are enough address blocks is the main type of consideration), but it is 

an administrative item that needs to be considered.

Overall, the document covers the needed areas to support the overall 

recommendation , however, with just a few suggestions /recommendations 

from this review.  I think the recommendations are sound, and with 

enough text around the full set of considerations to employ this model, 

I think the recommendations can go a long way to making the Internet better.

Some textual feedback is included below (text update recommendations).


Text Review:

Section 1: Introduction:
Pr.1 Last Sentence

<old> “However, in some areas, it can lead to carrying over IPv4 

practices that are not appropriate …”

<suggested>”However, in some design and operational areas, it can lead 

to carrying over IPv4 practices that are limiting or not appropriate in 

IPv6 as a result of  significant differences between the protocols in 

some aspects.”

NOTE: In the introduction, the texts suggest that “in most aspects, the 

IPv6 protocol is very similar to IPv4”, but then suggest there are 

“significant differences”.  Although both can be right, that may confuse 

readers. I attempted to capture that with the suggested text above.

Pr.3. First Sentence
<old> “This document describes the benefits of providing multiple addresses
   per host and the problems with not doing so””

<suggested> “This document describes the benefits of providing multiple 


   per host and the limitations with not doing so”

Section 2:  Common IPv6 Deployment Model

NOTE: in some cases, such as Cable Networks, directly attached hosts to 

modems are not generally allowed to consume multiple addresses via SLACC 

or DHCPv6. Typically a single address per host is allowed.  SLACC is 

also not typically used at all in those environments (however IA_PD 

is).  This is due to the nature of the environment where most endpoints 

used by customers/subscribers are behind a router/gateway.  A single 

host behind a Cable Modem is considered atypical

Section 3: Benefits of providing multiple addresses

Pr2, Bullet 5.
<old> Some of these require the availability …
<new> Some of these technologies require the availability ….

Section 4: Problems with restricting the number of addresses per host

Pr. 1, Bullet 4.  how does limit addresses actually increase load on 

provisioning servers?  I understand that it’s possible in models where 

each address assigned is mapped to a provisioning transition, then this 

can be the case (Maybe), but just limited addresses does not inherently 

add provision load.

Note about hosts on network, vs. host in ent/soho.

Section 5: Overcoming limits using Network Translation

Pr 4.
<old> This is not a desirable outcome.

<suggested> Resorting to the use of NAT to overcome a limitation on the 

number host addresses is not a desirable outcome.

Section 6: Option for providing more then one address

Section 7: Number of addresses required

Section 8: Recommendation

Note: for the recommendation, would it be advisable to also note that 

it’s recommended that operations, where applicable, set assign enough 

address blocks, so downstream networks (i.e. home, SOHO, businesses, 

etc) can ensure sufficient address space?

Section 9: Operational Considerations

Section 9.1: Stateful addressing and host tracking

Section 9.2: Address space management

NOTE1. In paragraph 1 it’s suggested that an Enterprise can easily get a 

/48 or in paragraph 2 that a large enterprise that need a /8 in IPv4 

could get a /40.  This is true, however, there is the operational  

consideration that getting block may impose administrative and cost 

overhead in addition to what the enterprise is accustom to.  I am in 

agreement that the recommendation is sound, however, the management/cost 

is an operational consideration.

NOTE2: I think there is a suggestion that the routing (and aggregation 

of that routing), is straight forward. To accomplish the goal of having 

each host get a /64, the management overhead of ensuring the model may 

not be trivial.  There are many topologies that exist in various 

networks, and to match up the desire to get a /64 to each host may be 

overwhelming for some.  It’s till good goal, but may or may not be 

administrative feasible.

Section 9.3 Addressing link layer scaleability issues via IP routing