IPv6 Pain Experiment

Tue Oct 8 01:02:20 UTC 2019

> On Oct 5, 2019, at 13:36 , bzs at theworld.com wrote:
> 
> 
> On October 4, 2019 at 15:26 owen at delong.com (Owen DeLong) wrote:
>> 
>> OK… Let’s talk about how?
>> 
>> How would you have made it possible for a host that only understands 32-bit addresses to exchange traffic with a host that only has a 128-bit address?
> 
> A bit in the header or similar (version field) indicating extending
> addressing (what we call IPv6, or similar) is in use for this packet.
> 

This still requires you to basically rewrite the L3 stack to accommodate the new addresses.

> They may not be able to talk but rather than a whole new stack it
> would have just been an extension of the commonly used IPv4 stack,
> more like a (e.g.) new ICMP option.

Uh, no, it would still have required reimplementing the entire L3 stuff at pretty much the same
work level as the current IPv6 mechanism. You would still have needed to update:

	All L4->L3 binding code
	All Name Resolution code

You’d still be faced with all the really hard problems that came with IPv4->IPv6 transition:

	Updating your applications to understand 128-bit addresses in logs, etc.
	Updating your provisioning systems to track 128-bit addresses.
	etc.

> Or even an octet indicating how many octets in this address, default
> would be four (or even a nybble indicating how many 16-bit words.)

This doesn’t make transition any easier and it makes ASIC processing of
packet forwarding a heck of a lot harder.

> Something simple like that could have, at least in the early stages
> (which we're still in w/ IPv6 unfortunately), have been entirely
> handled in userspace in the software.

Nope… It really couldn’t and that would actually be worse… Right now, the biggest hurdles
to IPv6 adoption aren’t the kernel level changes for a new stack, they’re the legacy application
changes needed to support bigger addresses.

> IPv4? Do the usual. Extended addressing? Hand to a userspace
> library. A minor poke to the drivers plus the userspace software. In
> many cases wouldn't even require a reboot to install, but at worst a
> quick reboot to install the low-level driver that knows to switch
> extended addressing packets to userspace.

I think you’re very confused about where the pain points with IPv6 are and what it would
take to actually implement what you are suggesting here.

> Particularly if the low 32 bits indicated the same IPv4 interface w/in
> a campus so primarily only the routers needed to interpret the rest of
> the address.

Uh, so a packet arrives at your 32-bit only application and you can’t tell whether you
need to reply to the student’s laptop on the other side of the room or the linear
accelerator 3,000 miles away because that’s all included in the 96 bits you didn’t even
see that got spirited away to some user-space translator layer.

What am I missing?

> So it'd get to the right router who'd hand it off to the right
> (32-bit) host. Only a problem if your campus happened to have 4B+
> hosts (or maybe 2B+), not likely.

Or if you need to communicate both within and outside of your campus (far more likely).

> It's similar to IPv4v6 stacks but the host would return the full
> address in the (extended) IP packet.

How’s the host supposed to do that if the host hasn’t been updated to handle extended
addressing? If the host has been updated, then there’s no difference from the current
situation with IPv6… The need to update every host (and these days, more relevant,
the need to update every application).

> In current IPv4v6 stacks (NAT et al) the router has to keep track and
> interpolate by rewriting the packets or similar. In what I describe
> that's not necessary as each packet retains the full address as it
> passes through the host.

Yeah, except, you’re assuming every host gets updated with the necessary software to
handle essentially IPv6 addressing without adding the IPv6 stack. This sounds like more
pain for less gain to me.

> Well, basically your question asks for a complete stack design right
> here right now, is that really where we want to go?

My point is that the changes to implement IPv6 on a given host (at the kernel level) are
not significantly more than the changes you are proposing to do what you want. Difference
is that they’ve mostly been done for the vast majority of hosts for IPv6 whereas yours would
be a new implementation.

It still doesn’t yield any greater compatibility because you’ve still got the difficulty of coping
with the applications that simply can’t understand a larger internet (which is the biggest hurdle
with IPv6 right now).

> But the sort of thing I suggest was suggested.

And did not gain consensus for the same reasons I outline above, I suspect.

> Some of the considerations as to why not do it this way were good,
> such as get some other bugs/limitations out of IPv4. And some not so
> good like bit-level performance and compatibilty considerations that
> have changed considerably since 1990.

Hindsight always yields what seems like errant judgment calls 30 years ago.

At the time, they seemed like a good idea.

> Were the 36-bit'ers still at the table in 1990? Probably.

36-bits would have been a terrible idea, frankly. Look how long it’s taken for IPv6
to get any real traction? Think about how painful it will be if we have to try and
change the address format again?

Far better to go for such an excessive number of addresses as to obviate the problem
as permanently as possible. It’s not that I think IPv6 will last for ever, I’m just hoping that
it’s something other than address shortage that leads to its obsolescence. In fact, if we
don’t have an address shortage, the next protocol might be able to continue using IPv6
addresses and reduce the transition pain.

> And CGNAT et al wasn't really conceived of yet or not very completely
> so it was assumed this would all be so urgent as to propel itself into
> the mainstream.

Frankly, I’m not convinced we wouldn’t all be better off if CGNAT hadn’t been conceived
and implemented and this had been so urgent as to propel itself into the mainstream.
It certainly would have been a higher level of pain in the short run, but it also would have
led to a much shorter period of pain.

>> How would you have made a 128-bit address more human-readable? Does it really matter?
> 
> That really depends on your priorities. If the priority was, as with
> ipv4, location independence so all bits are equally meaningful (i.e.,
> necessary to know what's desired), then it's difficult.
> 
> If it were actually treated as a potential problem then more defaults
> may have been engineered in.
> 
> But since this is a human interface problem I lean towards better
> software to view and manipulate addrs and let the engineers do what
> they need to do.

Seems reasonable, but I think what we’ve got is reasonably good.

I have found that with a little experience and a good subnetting plan, IPv6
addresses can become quite human readable when it matters.

> It's the tail wagging the dog or perhaps the dog returning to its, um,
> whatever.
> 
> We developed, w/ IPv4, this entire culture and software regime which
> thought it was reasonable to sometimes enter/read IPv4 addrs because
> they weren't too hard and then carried that over to IPv6 (not in
> theory, in practice.)

Yes, but I’d argue that the difficulty people have understanding CIDR in IPv4
and getting net masks and their implications right are a clear indication that
decimal-coded-octets were NOT the right choice for address readability.
Further, an IPv6 address using the same scheme would look something like:

38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2

If my math is correct, that’s the equivalent of:
38.32.0.0.144.48.0.0.0.0.0.0.32.0:0.2
 2620:  0:  0930:  0:  0:  0: 200:  2 (keeping the : aligned with the corresponding decimal)
2620:0:930::200:2 (Human readable form)

I don’t know about you, but that looks more like an SNMP OID
than anything useful to me. I find the hex representation
much easier.

It doesn’t get better for addresses containing letters, either.

Consider:

2620:0:930::dead:beef
 2620:  0:  0930:  0:  0:  0:   dead:   beef
38.32.0.0.144.48.0.0.0.0.0.0.208.173.190.239

I’ll take the 2620:0:930::dead:beef version any day.

> Meaning, for example, if DNS isn't working for you then you're often
> left to entering raw IP addresses manually, and "you" can often be
> non-technical users. IPv4, not a big deal, IPv6, challenging.

Well, entering a 128-bit number is going to be challenging no matter how
you format it. Humans just don’t cope well with large numbers.

If you’ve got an idea for a better format, I’m all ears. But grousing about the
fact that 128 bit numbers are bigger than 32 bit numbers isn’t particularly
helpful, since 32-bit numbers can’t represent the necessary number of hosts.

> Mere cut+paste no doubt helps.

Certainly one solution. DNS failures aren’t all that common these days in my
experience, either.

>> IPv4 is not particularly human readable. How many hosts do you keep IPv4 addresses in your head for? How long does it take you to get someone at the other end of a support call to correctly transcribe an IPv4 address?
> 
> IPv4 is not that much more difficult than a phone number. IPv6 is.

That depends… Are you including all variations of all international phone numbers in that calculation, or, just NANP numbers
(e.g. +1.408.555.1212)?

For NANP, sure, they’re relatively easy, but it’s an 11 digit number where the first digit is always 1.

That supports a total of 10,000,000,000 devices, which is a bit more than IPv4 since it’s a true decimal number
and doesn’t suffer from the octet-encoding overhead (0-255 instead of 000-999), so in 12 digits, you only get
4 billion instead of 10 in effectively 10 digits.

> IPv4 benefits from chunking, like phone numbers.

IPv6 has chunking too. The separator is a : and not a - or ., but so what?

I don’t think 2620.0.930..200.2 is significantly easier to read or better
chunked than 2620:0:930::200:2.

> If I have an idea of the "net", by which I mean the part which comes
> up repeatedly (such as w/in a campus) often the first two numbers,
> then all I really have to remember anew is the last two numbers, maybe
> only the last. For IPv6 it can be more difficult to commit a prefix to
> memory even if it's used somewhat regularly.

I don’t know… I don’t find 2620:0:930:: any harder to remember than
192.159.10, but perhaps that’s just me.

> But I'd agree this is mostly a red herring, better human interface
> software should help and that might take time to evolve.

I think what we have now is reasonably good, actually. It takes some getting
used to, but I bet you’ve had more years getting used to IPv4 than most of us
have with IPv6.

>> All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, AAAA, or both records.
> 
> As I said it often comes up precisely because, for some reason, DNS
> isn't available or not working correctly.

Well… I don’t run into this very often any more, but I guess if you have a poorly run DNS environment, it might be more of an
issue.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191007/9cc5620a/attachment.html>