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

This might be relevant to this list as well.

Best,
-Michael

---------- Forwarded message ---------
From: Sander Steffann <sander at steffann.nl>
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: ipv6-wg at ripe.net <ipv6-wg at ripe.net>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/iot-wg/attachments/20180322/b586921f/attachment.html>