On October 4, 2019 at 15:26 o...@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.
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.
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.)
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.
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.
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.
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.
It's similar to IPv4v6 stacks but the host would return the full
address in the (extended) IP packet.
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.
Well, basically your question asks for a complete stack design right
here right now, is that really where we want to go?
But the sort of thing I suggest was suggested.
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.
Were the 36-bit'ers still at the table in 1990? Probably.
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.
>
> 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.
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.)
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.
Mere cut+paste no doubt helps.
>
> 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.
IPv4 benefits from chunking, like phone numbers.
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.
But I'd agree this is mostly a red herring, better human interface
software should help and that might take time to evolve.
>
> All of this is mostly absurd as DNS names are human readable regardless of
> whether they point to A, , or both records.
As I said it often comes up precisely because, for some reason, DNS
isn't available or not working correctly.
>
> Owen
>
Anyhow, this is all fantasy sports.
--
-Barry Shein
Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*
