IPv6 is 128 bits... so we already made a change. Why can IPv7 not be 128 bits as well, but vastly more readable/recognizable than IPv6. Hex is hard on the eyes, especially for those who don't stare at it all day.
I'd argue that the most common format such as 2001:db8::f00f is already pretty darn readable, and not hard to copy+paste when you need bare addresses. Base85 is an alternative if you'd like something that's purely optimized for fewer characters, but it only really helps with exceptionally long addresses like 2001:db8:424b:b4ff:fcb5:b643:f721:b703 becoming 9R}vSk6QzV!G$<lwB;|~
Memorize that :) Then try to tell it over the phone.
That being said, telling an address over the phone (another unlikely situation, to be honest) wouldn't be that hard in hexadecimal form.
I don't know, I just checked my linux box that takes ipv6 from one of my routers and it's the full 16 bytes, no zeros to skip.
I suppose example.com has a lot of consecutive zeros and is shorter to type...
> (another unlikely situation, to be honest)
Kid calls you when you're out and asks where in your local network the minecraft server is running. Or on which samba server the mod archives are. Real story.
But also do you think 24414.64517.21200.44298.46574.49887.23623.7394 is really that much easier to type? Or 231.22.96.68.14.229.38.41.242.44.72.220.156.50.232.95 if you keep to 8 bit octets?
But -
> The move to hex is to avoid people having to memorise all these offhands
Point taken. It does seem in practice though people will still have a need to memorize/recognize addresses for various purposes, such as administration/dns/etc.
It's easy. Long sequence of 10 possible tokens that we're always used to seeing together. Easier to memorize because you subconsciously use any patterns you notice, and with just 10 possibilities the patterns are there. And you've been reading sequences of digits since you were old enough to get given pocket money.
Vs long sequence of 16 possible tokens, of which 10 belong in one cognitive group and 6 in another. The extra 6 you've never memorized before in random order because they're for representing your language and that has other ingrained patterns.
Let's not forget they admitted ipv6 addresses are too long and allow you to skip parts of it so now you have to count the colons carefully...
Also many of my account numbers and my nations equivalent of a SSN are alphanumeric so 36 vs 16 choices.
It's quite easy to remember things like "Mmm-mmm, went the little green frog one day".
I mean... yes, actually; I can type those blindly on a normal numpad. I'm sure somebody somewhere has made a hex number pad, but realistically on any normal keyboard entering hex means going back and forth between number and letter keys.
(There's already at least 4 different ways you can write an IPv4 address, and your OS is happy to accept any of them.)
[ff00:abcd::0]:1234I think the reason they needed to use a different delimiter is because IPv6 addresses can also omit entire portions of zeros as a convenience feature to shorten addresses, which means there are a subset of shortened addresses that look exactly like IPv4 if not for the delimiter.
To prevent that, you can write tons of test cases. IPv6 notation parsing and generating test cases are oodles of fun.
It was entirely inappropriate for small scale personal networking and assumed an "administrative scope" that's too cumbersome and without purpose for most implementations.
I wonder if a dedicated "local" network prefix with a fixed /64 mask and an operating system recognized "alias" would have been a good mechanism to introduce. Something like fec0::/64 with an option to call it "local::". Then you might be able to more easily move from a world of 192.168.10.1, 192.168.10.2 to a world of local::1, local::2, that being translated to fec0::1 and fec0::2.
Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above.
In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained.
It's been a mess, and at some point, the IETF just seems to have given up on it.
Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work.
There is no need for a ULA registry because you're supposed to pick a random prefix within the ULA space. The ULA space has 7 bits already defined, so you're picking a random prefix from a space 57 bits big. The chance that you will pick the same prefix as some other specific person is effectively zero.
(the birthday paradox does not apply because we don't care if your prefix matches anyone else on earth, just the one specific person/organization that you want to merge networks with).
> In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained.
Err, what? ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. They are valid addresses within the address space and the only thing that makes them "not globally routable" is that all routers have certain prefixes baked into the firmware as non-routable. If you don't trust your router not to route them for IPv6, why do you trust it for IPv4?
Thanks for explaining my own motivations to me, while at the same time denying that any discussed changes are relevant to anyone.
> There is no need for a ULA registry
I was merely summarizing what the public opinion on the matter happens to currently be. Which suggests that the current recommendation to pick a random address and be happy with it is inadequate. The original posts dissatisfaction with being able to deploy IPv6 _conveniently_ also hints that improvements would be welcome by most people.
> ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global.
RFC1918 explicitly defines it's addresses as local and not globally unique. RFC4193 specifies that these addresses are meant to be globally unique. RFC1918 requires a more specific level of filtering than RFC4193, and the definition of "site local" has always had some ambiguity to it.
So, within the very specific and nuanced points I was trying to make, no, they're different.
Also important to note that while RFC1918 is roughly equal to RFC4193/ULA, that "site local" is another beast entirely (FECO ) that was, as you noted, ambiguous and was deprecated in rfc3879
But - what if that Local bit is set to 0 - then:
Set to 1 if the prefix is locally assigned.
Set to 0 may be defined in the future.
Concur with the rest- and, honestly, RFC 4193 is one of the simply written RFCs out there - understandable within 30 minute read - I'd encourage everyone to dig into it.
They are meant to be globally _unique_ (or effectively so, by utilizing RNG you ensure that it is very, very unlikely for two organizations to have the same ULA), but they are not globally routable.
Thankfully there is near-100% compliance with PTR reverse-dns for IPv6 addresses and networks. /s