The only reason I can think of is psychological: People don’t want to learn new things, so they find reasons to dislike the new thing to be able to pretend they don’t need to learn it.
Also, the double-click argument is crap for two reasons: Firstly, it can be fixed by configuring your local software, and secondly, IPv4 addresses also had this so-called problem.
> IPv6 is still in the early stages of adoption
It really, really isn’t. It might look that way to you, in the US, at your home endpoint, but move to the backbone or outside the US and you get a very different picture. ARIN in the US just happened to be the last of the RIRs (except AFRINIC in Africa) to run out of IPv4 addresses, so the US was able to put off switching for longer than most, and the whole of the US is now consequently behind the curve.
The rational reason is that despite tons of "we have to adopt IPv6 or the world will end", people aren't learning it. Trying to understand the underlying reasons is worthwhile. The shittyness of the representation is one of those reasons.
(I agree with the people who say "making the parsing namespace even more complex won't help anyone" though)
We can chance these things easier than our visual pattern matching engine. (Not that we can't train it to perform better, but that just means we'll still make more mistakes and will be less efficient than with this small change.)
Fixed width fonts and indentation are good things, the majority of programmers use it for some reason, why not go for sane ergonomics in network related stuff?
I seriously doubt that any change in notation would be beneficial enough to be worth the 10 years of work, incompatibilities and bugs.
You don’t see people making this kind of fuss about MAC addresses; that’s because people know that they aren’t supposed to memorize them, and we treat them accordingly. That’s the thing about IPv6 - you have to realize that you have to let go of the notion of memorizing IP addresses, just as it would never occur to you to know your MAC address by heart. Use the DNS; eliminating the need to memorize IP addresses is what the DNS is meant for.
They're individual preferences not problems. We can't realistically have a bunch of different notation standards to make everyone happy.
I'm not saying that is a good thing or not, I'm just saying it IS.
It would be a pain to use ipv6 internally.
So.. Have you ever actually used ipv6?
With ipv6 your organization gets a prefix assigned, usually a /32 or a /48
So you would get assigned a prefix like 2626:32:400::/48
With ipv4 where if you were lucky you had a /16 that had 65,536 addresses - with "simple" /24 subnetting for 256 subnets of 256 hosts each.
With ipv6 you minimally have a /48 that has 65,536 subnets.
So you can just start subnetting things like 2626:32:400:0/64 is headquarters, 2626:32:400:1/64 is marketing. And you never have to worry about running out of address space on each subnet, since each subnet has room for 18,446,744,073,709,551,616 addresses.
And since there is room for 65,536 subnets, you can easily do things like immediately carve that up into blocks of 512 subnets for every geographical location and project... once. And not end up with "10.1.3.0 is marketing, but also 10.1.58.0 because we ran out of room"
So really, if you can type 192.168.x.y, you can type 2626:32:400:x:y.
The fact that IPv6 addresses are so unruly is a blessing in disguise. Use DNS, /etc/hosts, bonjour, .ssh/config, whatever. Use names, stop using addresses directly, even with IPv4.
All the alternatives are either unreliable and slow (bonjour/mDNS) or require manual setup prior to use. Given that machines, networks, routes, etc. are all becoming increasingly ephemeral in the end all you end up with is a DNS, .ssh/config, or hosts file with hundreds or thousands of stale entries for things that existed for five minutes. In some environments there are nice systems for naming things and IP address management but these are hard to set up and maintain and aren't feasible in really heterogenous settings.
I guess Martin Fowler was right: there are two hard things in CS, cache invalidation and naming things. This is naming things.
An end user could tweak the text representation for their own tools, while continuing to exchange packets with the rest of the Internet.
The US may have been slow to start, but is probably ahead of the curve now. AT&T (6rd, but still) and Comcast have a large amount of residential users that are IPv6 enabled; T-Mobile, Verizon, AT&T and Sprint all support it on wireless too (subject to apns and access technology).
In Europe for example, the IT profession has been bombarded with news on how IPv4 was running out, then it ran out, and then all problems because it ran out. Network courses have been teaching IPv6 for a long time, government has issued mandates to use it (and governments are not known to be fast on those issues...), and IT conferences used to talk about it to the point where it's such old news that it is no longer worth talking about.
Globally (again using user access to google as measurement) the adoption rate is still less than 10%, One could argue this could be considered still early stages of adoption.
actually, according to these statistics, the adoption rate in belgium is much higher: 40.39%
ip6emoji("fe8000000000000003ceecdfffe30c27",Char(0x2800)) => "⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧"
Then:
deadbeef000000000000000000000001
2607f2f8a36800000000000000000002
fe8000000000000003ceecdfffe30c27
fe800000000000000000000000000001
2607f8b040078090000000000000200e
⣞⢭⢾⣯⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁
⠦⠇⣲⣸⢣⡨⠀⠀⠀⠀⠀⠀⠀⠀⠀⠂
⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧
⣾⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁
⠦⠇⣸⢰⡀⠇⢀⢐⠀⠀⠀⠀⠀⠀⠠⠎
At the moment I happen to be on an up-to-date version of Windows 7 and here's what it looks like:
*edit: though it appears to render properly on Debian
And some users change their default font and don't even use installed fonts and override preferences because they're in charge of how things display on their computer.
I use Sofia-Pro and this is what I see: http://i.imgur.com/8PoNfdJ.png
(though interestingly when I open this page up with links2 on my vps, accessed through a terminal on the iphone, which is using a monospace font... it renders fine.. it doesn't render fine if I see the same thing with Putty on the Win8 computer. I guess fonts support in general on Win is bad)
Wonder if there would be an interesting way to visualize a cascading failure of the kind that brought down AWS in past years. Which of course makes one wonder if there would be any kind of useful calculus for a series of such glyphs.
PS: according to wikipedia there is a calculus of communicating systems of sorts: https://en.wikipedia.org/wiki/Calculus_of_communicating_syst...
Without using the shift key it's easy to type base 32 numbers. That comes out to an average of 26 characters per IPV6 address.
So Hex
deadbeef000000000000000000000001
2607f2f8a36800000000000000000002
fe8000000000000003ceecdfffe30c27
fe800000000000000000000000000001
2607f8b040078090000000000000200e
6ULMVEU0000000000000000001
160VPFH8R80000000000000002
7UG000000000007JNCRVVU6317
7UG00000000000000000000001
160VSB0G07G28000000000080E
3q2+7wAAAAAAAAAAAAAAAQ
Jgfy+KNoAAAAAAAAAAAAAg
/oAAAAAAAAADzuzf/+MMJw
/oAAAAAAAAAAAAAAAAAAAQ
Jgf4sEAHgJAAAAAAAAAgDg
But maybe an alphabet with emoji could be practical. You could have smiley or sad faces in your IP address. All kinds of possibilities with that. Though software such as this HN website would have to be fixed to be able to display it. But you know, a long term project.
[1]: http://lifehacker.com/162484/save-time-with-text-substitutio...
Base 32 seems like a good half-way solution of length reduction vs glyph complexity, as Base 64 or Base 89 (or whichever the RFC suggest) include too many distracting characters (IMHO).
Of course, Chinese/Japanese speakers have a natural advantage here (Katana and Hirigana both fall short of a contiguous 64 character mapping):
ip6emoji("fe8000000000000003ceecdfffe30c27",Char(0x3300),stride=8) => "㏰㌀㌏㏷"
( though hopefully that's not some form of insult in Chinese! ;) )
::6ULMVEU0000000000000000001
::160VPFH8R80000000000000002
::7UG000000000007JNCRVVU6317
::7UG00000000000000000000001
::160VSB0G07G28000000000080Ehttp://f.cl.ly/items/0E182U1p3r430M073w2i/braille.png
Seems like the font that OS X’s text rendering system substitutes for the braille characters (U+28E3, etc.) is Apple Braille Regular over the other fonts installed that also have glyphs for those codepoints (Apple Symbols, Everson Mono (font I installed myself), and Symbola (font I installed myself)).
As an aside (and yes, I’m copying part of a post I made more than a year ago¹; I’m still interested in knowing the answer to this!) I’m pretty interested on how OS X and Windows decide on which font to use when there are multiple fonts installed containing the required glyph. For example, I have two other fonts on my OS X system that have a glyph for U+2705 (Everson Mono and Symbola), but OS X always seems to consistently pick Apple Color Emoji’s glyph. Maybe OS X’s text rendering system goes through the fonts in alphabetical order and uses the first one it finds containing the required glyph? It would be great if end users could have a bit more control over the font substitution process. I know it’s possible to do in some text editors like Emacs², but I believe that programs like that use their own text rendering systems instead of that supplied by the OS (could be wrong though).
――――――
¹ — https://news.ycombinator.com/item?id=8865067
² — http://stackoverflow.com/questions/6491202/overriding-emacs-...
This is not really an end-user issue but it is a serious usability issue for IT admins and developers. It's very very common to schlep around raw IPs constantly when messing with networks and I don't see that going away. It's also very important to be able to visually parse IPs when understanding the topology of a network, writing firewall rules or routes, etc.
This is a DX (developer experience) issue more than a UX (user experience) issue.
Edit: three specific problems with DNS:
(1) What happens when things are not configured yet?
(2) OSes are designed to have one DNS server but people belong to many networks either at once (local + VPN + virtual + ...) or serially via mobility. In reality you need many DNS servers, but then how do you deal with naming conflicts?
(3) DNS is dependent on IP so you can't use DNS to debug DNS issues. It's a circular dependency.
In practice IP schlep is very common.
Actually that's not a problem for that. Since people who are actually using them have no idea about IPv4, too and just copy addresses. Actually you could create local address with everything prefixed by fd + 40 bit which could be just fdff:ffff:ffff:ffff::1 which isn't really hard to remember.
On the other hand, DNS could fix this - just have a TLD of ip6 and have it resolve all the examples in the article. It would require no changes to current software and will work transparently. I.e. you'd enter http://deadbeef.ip6:1234 and when the ip6 TLD servers receive a request for deadbeef.ip6, they will reply with dead:beef:0:0:0:0:0:0. Similarly with deadbeef.1.ip6 and so on. You could easily implement this in the OS too without much hassle and not even need servers on the internet to do it.
In an embedded system where memory is at a premium and you may have serious constraints on how long things take (e.g. for timing purposes), the ability to hard-code an address or have it entered in some way saves you from having to support an entire DNS layer in that system.
I think this article has a lot of really practical ideas that would help a lot.
I suppose the only other thing I’d want to allow in an IPv6 address is a Perl-like underscore anywhere for visual separation that acts like a comment; e.g. Perl lets you say things like 1_000_000 to mean 1000000. The article suggests a single dot but I think that could still be combined with visual underscores for things like "dead_beef_._0001".
If the array you are referring to is the human-readable buffer used to store ipv6 addresses, I would assume the 'bugs' you are talking about are entirely similar with ipv4.
"dead.beef" is bound to exist now that ICANN is going crazy with top-level domains.
"dead:beef:0000:0000:0000:0000:0000:0001"
becomes
"3q2+7wAAAAAAAAAAAAAAAQ"
Which sucks because of the non-alphanumeric characters and the long run of A's, but one gets the idea. Which is to a general user hex encoding might as well be Hungarian.
(base 85 representation of IPv6 addresses)
This is not a bad thing either - when all apps act like they're distributed, or could be, we'll get a lot better tooling for actually writing them.
So get over it. IPv6 is not meant to be usually exposed to endusers. Use hosnames. Use DNS, or mDNS or LLMNR on small networks without a resolver. Etc.
If you need to connect from machine to machine in the lan, use mdns and host names. This already works out of the box even in v4.
> IPv6 is not meant to be usually exposed to endusers.
"You're holding it wrong". This is a crap argument against the article. Network admins have to manipulate this stuff all the time, and the article is written from the point of view of a netadmin, not an enduser. It's trying to describe both a problem (lack of client uptake despite support; struggles with human comprehension) and a potential solution. The idea that humans would never have to look at an ip6 address has proven to be a fantasy.
That is the MAIN reason why its deployment and adoption rate has been a long clusterfuck.
Arstechnica has an article about it: http://arstechnica.com/business/2016/01/ipv6-celebrates-its-...
The prefix should be all zeroes, so you get something like: ::12.123.99.222 Which is not that hard to remember. :P
In fact I'm not sure why it wasn't done that way to begin with, unless IPv6 fixes a bunch of other problems I was not aware of
2001:4b10:bbc::1
2a03:2880:2110:df07:face:b00c:0:1 www.sprint.net has address 208.24.22.50
www.sprint.net has IPv6 address 2600::literals were introduced because the order of parsing for an email host is first "Domain" for any non literal, then literal which defaults to IPv4 [127.0.0.1], then a literal prefix was added for IPv6 and any future registered protocol "[IPv6:::]"
the order for parsing for a URI is:
// host = IP-literal / IPv4address / reg-name
// IP-literal = "[" ( IPv6address / IPvFuture ) "]"
ipv6 just happens to use a colon which conflicts with the port delimiter from authority in a URI so it's a literal and not a registered name
// [ userinfo "@" ] host [ ":" port ]
> why not re-use the dot from IPv4 notation
because you have conflicts from "0.0 -> 0.0.0.0" to "255.16777215 -> 255.255.255.255"
0-9 conflicts with an IPv4 decimal
a-f conflicts with GTLDs
the only reason your blobs don't have a conflict with an IPv4 Historic is because hexadecimal notation starts with 0x
> try double clicking on those
try double clicking on any of these valid characters from "reg-name"
// unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
// sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "" / "+" / "," / ";" / "="
or these from IPvFuture
// IPvFuture = "v" 1
HEXDIG "." 1( unreserved / sub-delims / ":" )// unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
// sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "
" / "+" / "," / ";" / "="if you want to develop your own "standard" either use the literal IPvFuture, or use a Registered Name
non literals IPv4, IPv4Historic, and Domain names are valid registered names, but domain names aren't even part of the URI standard
the only reason you would have conflicts with domain names is because they're de facto parsed after an IP, so a double dot would probably be discarded as invalid, which is why punycode exists for unicode
if at that point you didn't have any conflicts it would be a registered name, but you wouldn't have any way to resolve them
lastly, if you want to fix the nonissue of double clicking use a registered name, if you chose to use underscore you may have conflicts with dns
edit trying to figure out newline parsing
This is exactly what the article means by
> To fix the ambiguity, brackets were introduced
The addition of brackets disambiguates the grammar.
> the order for parsing for a URI is:
> // host = IP-literal / IPv4address / reg-name
No, that's a part of the grammar; it only means that a host is either an IP-literal, an IPv4address, or a reg-name; it does not imply any sort of ordering to those rules. Normally, the grammar should be unambiguous. Unfortunately here, the grammar for IPv4address and reg-name actually are ambiguous; I'll get to that.
> the only reason you would have conflicts with domain names is because they're de facto parsed after an IP
It's not defacto. It's in the same standard,
> The syntax rule for host is ambiguous because it does not completely distinguish between an IPv4address and a reg-name. In order to disambiguate the syntax, we apply the "first-match-wins" algorithm: If host matches the rule for IPv4address, then it should be considered an IPv4 address literal and not a reg-name.
$ dig -x 2600:3c03::f03c:91ff:fe93:50b0
; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> -x 2600:3c03::f03c:91ff:fe93:50b0
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40052
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;0.b.0.5.3.9.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.3.0.c.3.0.0.6.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
0.b.0.5.3.9.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.3.0.c.3.0.0.6.2.ip6.arpa. 18272 IN PTR itchy.jrock.us.
;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Feb 19 22:34:49 EST 2016
;; MSG SIZE rcvd: 118XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48,43:48,58:48
> dead:beef:0000:0000:0000:0000:0000:0001
> I’m sure there was a reason for this choice, but to us after using IPv6 for years it still seems utterly arbitrary.*
If I had to guess, I would say they're there to chunk things up for reading aloud.
"Read me that address off the console."
"Okay, d-e-a-d..."
"Got it."
"...b-e-e-f..."
"Yep."
"...a bunch of zeroes, then 1."
They also make it harder to lose your place when reading it back.
The colon is a non-starter, not everyone uses a qwerty layout (azerty layout has direct access to the colon) but as ipv4 fields can be smart and automatically add a . after 3 characters or with a press of the left arrow (windows has been doing this for 15+ years), ipv6 fields can automatically add a : when needed.
Omitting leading zeros is not mandatory, you can input all those zeros if you so choose (turns out the author actually does).
Better blobs for double clicking selects them ? Well maybe try triple clicking then, though in my shell with default settings double clicking an ipv6 address selects it. Also separating fields of 4 characters improves readability, ipv4 also separated fields but I don't see the author criticizing this.
why not re-use the dot from IPv4 notation? Because it would add unnecessary complexity, also 17 years later is a bit too late to ask for such a drastic change in an established standard.
Lastly if you find the : unappealing, why don't you code your tools to show them as . and while at it add a layer in your code that will translate your preferred way of displaying ipv6 into the actual one ?
All I take from this post is that zerotier is probably incompetent, refractory to ipv6 and is certainly whiny about non-issues.
Edit:
BTW, don't most home routers etc take a hostname and add it to a .local DNS domain stored on the router?
but yeah, whenever I see an ipv6 format address, it takes way too long to parse it out. unless you were a network engineer at some point, it's not going to become second nature any time soon.
String representations of IPV4's aren't all of equal string length either.
IPV6 can't be shortened into, for example, dead.beef.de, because it's ambiguous as to whether that would be a domain name, or an IPV6 address. Likewise, other suggestions make it ambiguous with an IPV4, or even if not technically ambiguous, likely to break some existing code.
Raw IP's aren't exposed to the masses often anyway, so the bulk of the downsides of the current compromise should be constrained to just technical people. They will just have to figure it out.
Examples: 2001:DB8::13.1.68.3 ::FFFF:129.144.52.38
In the suggested format, we'd lose this convenient transition feature and are left with: 20010DB8..d014403 ..FFFF81903426
This is less clear than the existing method with the colons and dots.
If one decides, in this proposal, to support trailing IPv4 addresses as is currently supported, e.g., for IPv6-mapped-IPv4 addresses, some pretty ugly things happen: 20010DB8..13.1.68.3 ..FFFF129.144.52.38
Is .13.1.68.3 a typo of an IPv4 address with missing whitespace or is it an IPv6 address with an IPv4 address embedded at the end?
And what about parsing "FFFF129"? Are we really going to change base from 16 to 10 between the "F" and the "1"?
Or are we going to introduce another separator, e.g., a leading "." on IPv4 addresses?
..FFFF.129.144.52.38
Or are we going to require that the ".." be the separator there?
0000:0000:0000:0000:0000:FFFF..129.144.52.38
Or are we going to use the existing format for IPv6 addresses that embed IPv4 addresses, and another format only otherwise (Hint, of course one must support the existing 20 year old format.)
To add another historic complication for some implementations: https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_addr...
a leading zero on an IPv4 address octet meant that the byte is specified in octal.
One can easily argue that the best solution is to use a different special character, e.g., ":", for IPv6 rather than the IPv4 "." because leading zeroes had a special meaning in IPv4 syntax.
All in all, it looks to me like the early IPv6 community thought about the address syntax... a lot.
Edit: he hasn't even mentioned zone IDs represented by a % which would make him even more angry if he had to figure them out
tl;dr use mdns. You should never have to type an IP. Yes the mdns software sucks and has a huge attack surface because it's bloated.
Yes, we'd barely introduced fire then, we certainly didn't have the technology to double click to highlight a word...
No case issues, semicolons don't appear in dns or ipv4, no shift key required.
The article should have started with this. Could have saved me countless seconds of skimming the article while summarizing in my head "boo hoo, I haven't figured out how to make my workflow any better after 2 years."