[ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT

Hi,

Thank you, Sander. I support your comments, which cover most of my points. 
However, I would like to add a few minor remarks:

> Page 8, 2 Definitions
There are other address generating mechanisms in use apart from "base it on 
the MAC address".

> Page 10, 6 Introduction to IPv6
RFC8200 does obsolete (not update) RFC2460.

> So, in summary: [...] It looks like an academic exercise without operational
> experience. It does not feel right to me to publish this as a recommendation 
Solely based on this draft I would have to conclude that IPv6 (addressing) is 
probably not the ITUs area of expertise. Other venues/bodies, e.g. this WG, 
might be more suitable for giving guidance.

Regards,
Markus



__________ ursprüngliche Nachricht __________

Von:		Sander Steffann <sander at steffann.nl>
Datum:	Donnerstag, 22. März 2018, 12:50:38
An:		"ipv6-wg at ripe.net" <ipv6-wg at ripe.net>
Kopie:	
Betr.:	Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation 
on IPv6 address planning for IoT

> 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:
> > 
> > https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel
> > 
> > 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
> 
> 

-- 
Markus de Brün
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Federal Office for Information Security, Germany
Mail: markus.debruen at bsi.bund.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </ripe/mail/archives/ipv6-wg/attachments/20180509/7e0bc65f/attachment.sig>