Tussles in IPv6 Land

[Brian E Carpenter <[e-mail]>]

Hi,

I wrote the text below a couple of months ago, but then got distracted.
However, I do think it's important that as we argue about (for example)
/64, to remember what's going on behind the apparent argument.

Regards
   Brian

Tussles in IPv6 Land

Today (April 2017) we seem to have three very active tussles in the IPv6 technical
community.

1. Is header insertion on the fly OK, or is it the work of the devil?

2. Is the fixed interface identifier length of 64 bits OK, or is it the work of the devil?

3. Which is the work of the devil: getting the DNS server address via Router Advertisments,
or getting the DNS server address via DHCPv6?

Each of these issues has generated several hundred emails recently. Clearly, they matter
to some part of the community. Why? And why now? None of them are exactly new.

Why they matter *now* seems clear. IPv6 is on the march. Although there are still IPv6
'deniers' it's become a bit like climate change denial: the temperature is up, the waters 
are rising. More and more operators are being forced to consider IPv6 not as a remote
possibility, but as a requirement that will directly impact how they operate and how
much it costs to operate successfully.

To a significant extent the above three issues are tussles between operational needs
and conceptual purity. To be specific:

1. Large data centres need to achieve throughput and parallelism. To do that they
need to chain services together across very large numbers of nodes. The large
address space of IPv6 is potentially very valuable for that, if it can be brought
to bear: and an attractive way of doing so is segment routing. An attractive way
of doing segment routing is using an IPv6 routing header. An attractive way of doing
that within the data centre is by having the first-hop router insert the IPv6
routing header, so that the application servers don't need to know about it. So
data centre operators like this idea. So router vendors like this idea too. Unfortunately,
many people involved in the IPv6 design think it's a terrible idea (and a misreading
of the IPv6 standard). That's because inserting stuff (any stuff, not just this header)
in a packet changes its length and thereby breaks all known methods of determining
the maximum packet size allowed on a given path across the Internet.

So, header insertion is the work of the devil across the Internet and also the goose
that might lay the golden egg inside a data centre.

2. The interface identifier length was fixed at 64 bits about 20 years ago. It
was not an arbitrary choice then - it was designed to match the hardware address
size of FireWire, then expected to be the network of the future. (It actually
turned out that the network of the past, Ethernet, became the network of the
future. But if we'd fixed on 48 bits for that reason, we'd be having the same
tussle about 80+48 that we're having today about 64+64.) Network operators have
two complaints about the boundary at 64 bits. Firstly, although in theory it could
be different for different media (for example, 64 for FireWire and 48 for Ethernet)
in practice it's been set at 64 for everything. Secondly, bitter experience with
IPv4 25 years ago taught everybody (we thought) that routing should always be
"classless" with no rigid rules about the length of routing prefixes. But the de
facto rule in IPv6 is that leaf subnet prefixes MUST be 64 bits long. ISP operators
would like that 64-bit boundary to float. Unfortunately, many people involved
in the IPv6 design think it's a terrible idea (and a change to the IPv6 standard).
There are several reasons for that - though the main one seems to be that having
a 64 bit boundary everywhere makes portability (of code, and of computers) easier.
Also, much software blindly assumes the 64 bit rule. But this has its own downside:
suppose an ISP follows bad practice and gives a retail subscriber exactly one
64 bit prefix. If the subscriber needs to operate more than one subnet in their
home or office, they simply can't do so unless the 64 bit rule is relaxed. That
wastes considerable potential for IPv6 deployment. But - again, but - if the
64 bit rule was made flexible, perhaps some ISPs would decide to go further -
say give a retail subscriber exactly one 80 bit prefix. This could generate
a race to the bottom, where the really cheap and nasty ISPs give a subscriber,
say, exactly one 120 bit prefix, wasting even more of IPv6's potential. On this
argument, sticking to the 64 bit rule seems safest.

So, the 64 bit boundary is the well-understood solution that works everywhere,
or the spawn of the devil that blocks future flexibility for both routing
and address space conservation.

3. An IPv6 host can get its DNS server's IPv6 address in two ways (let's
call them Alpha and Omega). Therefore, a router can supply a DNS server's
IPv6 address in two ways (also Alpha and Omega of course). So some host
operating systems support Alpha or Omega alone; some routers support
both, but others support either Alpha or Omega alone. So it is entirely
possible for a host that only supports Alpha to roam to a network that
only supports Omega (or vice versa), in which case the host can't get
DNS service over IPv6 at all. Believe it or not, the fallback is then
DNS service over IPv4, even to retrieve IPv6 addresses.

Alpha is the work of the devil if you (a network operator) prefer to
assign host addresses using Omega. And vice versa. However, some operators
are pragmatic enough to support both Alpha and Omega in their routers,
regardless of whether they prefer Alpha or Omega for assigning addresses
to hosts.

So this is an interesting tussle, because operators don't agree among themselves
about the best approach; neither do router vendors; neither do host operating
system developers.

Feel free to assign the values "RA/RDNSS" and "Stateless DHCPv6" to Alpha and
Omega either way round. It makes equal sense.

--