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 “However, in some areas, it can lead to carrying over IPv4 practices that are not appropriate …” ”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 “This document describes the benefits of providing multiple addresses per host and the problems with not doing so”” “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. Some of these require the availability … 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. This is not a desirable outcome. 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