<div dir="auto">This might be relevant to this list as well. Best, <div data-smartmail="gmail_signature">-Michael</div></div> <div class="gmail_quote"><div dir="ltr">---------- Forwarded message --------- From: Sander Steffann <<a href="mailto:sander@steffann.nl">sander@steffann.nl</a>> Date: Thu, Mar 22, 2018, 12:52 PM Subject: Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT To: <a href="mailto:ipv6-wg@ripe.net">ipv6-wg@ripe.net</a> <<a href="mailto:ipv6-wg@ripe.net">ipv6-wg@ripe.net</a>> </div> Hi, > We are happy to announce that ITU Study Group 20 has responded positively to our offer and have decided to share the current working draft with us, for the purpose of review and for RIPE community to provide feedback. > > As it is quite big, the text of this draft Recommendation Y.IPv6RefModel “Reference model of IPv6 subnet addressing plan for Internet of things deployment” has been made available on the IPv6 WG pages: > > <a href="https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel" rel="noreferrer noreferrer" target="_blank">https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel</a> > > We kindly invite you to provide feedback and comments on the contents of this document via this mailing list or of course the RIPE Forum web interface. The RIPE NCC has agreed to ensure that the comments will be collected and made available to the ITU via response to the Liaison Statement below. Thanks! As the document is indeed quite long I will give feedback by mentioning the page number, section and quote the particular bit I'm commenting on. I assume, as there are still editorial notes in the document, that minor issues such as grammatical errors don't need comments and will be fixed in a future updates. > Page 3, Introduction: "The current ISPs practice tend to allocate /48 or /64 prefixes to regular customers (e.g., homes) and up to /29 for companies registered at RIRs." There are two issues with this text. The practice of assigning only a /64 goes against the best practice documented in RIPE-690. While I agree that it happens, this should be noted. Also, the "up to /29" text is plain wrong. There are plenty of examples of larger-than-/29 allocations. I guess it means to talk to enterprises that become an LIR, and I don't know any examples for that specific subset. (I'm explicitly NOT going into the difference between allocations and assignments. That doesn't bother me in documents like this) Suggested text: "The current ISPs best current operational practice advises to allocate /48 or /56 prefixes to regular customers (e.g., homes) and up to /29 for enterprises that become LIRs themselves." I think this also better aligns with the scope defined later in the document. > Page 9, 4 Abbreviations and acronyms Might want to add LIR here as well. > Page 13, 9 IPv6 address structure, "Larger networks owners, such as large companies, can get up to /32 global routing prefixes." This contradict the text on page 3. Suggested: "Larger networks owners, such as large companies, can commonly get up to a /29 global routing prefixes." > Page 14, 10 Subnet address requirements, "a smooth transition from IPv4, to dual stack environment (IPv4 and IPv6) and finally to IPv6 only deployments" It might be noted here that IPv4 -> dual-stack -> IPv6 is often no longer the preferred transition path. Technologies like SIIT-DC and NAT64 make it increasingly preferable to skip the dual-stack step. Both to save the cost of an extra transition step and to reduce the complexity caused by the dual-stack phase. > Pages 15&16, 11 Reference model for IPv6 subnet addressing plan I'm not mentioning specific sentences here because I don't agree with the concept behind the whole section. I understand the incentive to map IPv4 prefixes to IPv6 prefixes in the short term. The problem with that strategy is that the given approach results in a very bad IPv6 addressing plan. And it won't be applicable unless the IPv4 addressing plan already conforms to a whole set of conditions. If the IPv4 plan deviates even slightly from the proposed plan then it can't be used. That realistically only makes it deployable in greenfield, in which case there are much better addressing plan possible. Some unrealistic constraints on the IPv4 plan: - the organisation uses a /16 split into /24s - the "categories" subnets have to be kind of hex-aligned (DMZ=0-31, Servers=32-63 etc) And then it creates a suboptimal IPv6 addressing plan: - it is aggregated by building - but the "IPv4-mapping" part is completely unaggregatable - which causes overly complex routing topologies - which causes overly complex firewall rules Without the IPv4 mapping the addressing plan would be close to what the SURFnet addressing plan document recommends (note: I'm one of the authors of that document). In short: this suggested plan is likely not deployable on existing networks, and greenfield networks could do much better. I therefore think this is not a good recommendation at all. > Later sections While there is some sense in the general structure of section 11 (except for the IPv4 mapping), the whole concept is wrangled to pieces in the subsequent sections. For the /56 it's still understandable, but applying this to a /36 is really not even close to a best practice anymore. Networks of that scale just aren't organised in the way that this paper assumes. Furthermore, it also is assigning more than a /44 to a single site, which would violate RIPE policy unless explicitly approved by the RIPE NCC IPRAs. And with a badly structured plan like the recommended one I just can't see that happening. That makes the plan undeployable. So, in summary: it is great that the ITU is helping organisations with deploying IPv6. This plan however seems too far removed from operational reality to be really usable. It looks like an academic exercise without operational experience. It does not feel right to me to publish this as a recommendation unless the shortcomings of the /48 plan section are addressed, and the sections that talk about larger address blocks take common architectures of larger networks into account. Cheers, Sander </div>