Last Call Review of draft-ietf-v6ops-host-addr-availability-05
review-ietf-v6ops-host-addr-availability-05-opsdir-lc-kuarsingh-2016-03-08-00

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 - 


https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-05






Summary:



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 


met.






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



draft-ietf-v6ops-host-addr-availability-05



https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-05




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 


addresses



   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