The author suggests using deadbeef.1 instead of dead:beef::1. But his scheme cannot work. If you see deadbeef.ad there is no way to tell if it refers to his IPv6 notation, or to a domain under the .ad TLD (many other ccTLDs are valid hexadecimal numbers). And you can't replace the dot with a colon (because many of his other complaints were caused by colons). You can't use a character other than dot or colon (because so much network software is written assuming IPs/hostnames can only contains alphanumeric, dash, period, or colon chars that it would be too painful to introduce a new character).<p>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.
What is the rational reason, if any, for gripes like these?
The time to have this discussion would have been in like 1993 or so. Now, IPv6 is what we have, and the standards are what they are, flaws and all.<p>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.<p>Also, the double-click argument is crap for two reasons: Firstly, it can be fixed by configuring your local software, and secondly, IPv4 addresses <i>also had this so-called problem</i>.<p>> <i>IPv6 is still in the early stages of adoption</i><p>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 <i>last</i> 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.
If you're really adventurous, you could just use Braille which has 255 Unicode symbols. <i>Ahem</i><p>ip6emoji("fe8000000000000003ceecdfffe30c27",Char(0x2800))
=> "⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧"<p>Then:<p><pre><code> deadbeef000000000000000000000001
2607f2f8a36800000000000000000002
fe8000000000000003ceecdfffe30c27
fe800000000000000000000000000001
2607f8b040078090000000000000200e
</code></pre>
Becomes:<p><pre><code> ⣞⢭⢾⣯⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁
⠦⠇⣲⣸⢣⡨⠀⠀⠀⠀⠀⠀⠀⠀⠀⠂
⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧
⣾⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁
⠦⠇⣸⢰⡀⠇⢀⢐⠀⠀⠀⠀⠀⠀⠠⠎
</code></pre>
At first I was just playing around, but after a bit it begins to resemble one of those binary clocks. It even becomes somewhat natural to read. Might actually use this for myself... something nice about the 2x4 bit block patterns. 64bit pointer addresses?
Better not tell this guy about abbreviating ipv4 addresses. <a href="http://127.1/" rel="nofollow">http://127.1/</a> or <a href="http://2130706433/" rel="nofollow">http://2130706433/</a> might blow his mind.
If the colons make you sad, don't worry, the addresses are represented with dots in some places. For example, DNS:<p><pre><code> $ 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: 118</code></pre>
Another potential problem with the sometimes-length-varies aspect to IPv6 addresses is that serious software bugs can be hidden. An array allocated to an insufficient size may work for quite a long time with the vast majority of addresses that take advantage of shortening tricks like "abcd::::", and fail <i>only</i> when presented with an address string that uses the maximum possible IPv6 address length.<p>I think this article has a lot of really practical ideas that would help a lot.<p>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".
Most of these issues mentioned are created by trying to treat IPv6 like IPv4 instead of adopting modern techniques for IP address management, automation, named objects in network device configs, etc. I've only been using IPv6 in production for about a year and it's already second nature to me.
the double-click thingy can be remedied on xorg by adding 58:48 to the X resources, e.g:<p>XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48,43:48,58:48
> Then there’s how the :’s are used. For a full-length un-shortened IPv6 address, they are supposed to appear every 16 bits like:<p>> dead:beef:0000:0000:0000:0000:0000:0001<p>> I’m sure there was a reason for this choice, but to us after using IPv6 for years it still seems utterly arbitrary.*<p>If I had to guess, I would say they're there to chunk things up for reading aloud.<p>"Read me that address off the console."<p>"Okay, d-e-a-d..."<p>"Got it."<p>"...b-e-e-f..."<p>"Yep."<p>"...a bunch of zeroes, then 1."<p>They also make it harder to lose your place when reading it back.
What a bunch of nonsense !<p>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.<p>Omitting leading zeros is not mandatory, you can input all those zeros if you so choose (turns out the author actually does).<p>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.<p>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.<p>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 ?<p>All I take from this post is that zerotier is probably incompetent, refractory to ipv6 and is certainly whiny about non-issues.
The FIRST problem is that IPv6 wasn't designed to be backwards-compatible with IPv4.<p>That is the MAIN reason why its deployment and adoption rate has been a long clusterfuck.
The proposal says, "A nice de-facto standard would be to print the dot at the route netmask boundary". This will not work consistently because one does not (typically) know the netmask of a remote host, so this will result in IPv6 addresses being written differently locally and remotely (e.g., the address of a local DHCPv6 host in a /112 written as 20010DB80000000000000000..1 and remotely, perhaps, as 20010DB800000000..1 if SLAAC is incorrectly assumed. Thus they often will not match, complicating, for instance, help desk calls correlating users client IP address to server-side logs. One solution is to always do [zero] compression [only] at the longest run of zeroes, which is what the existing IPv6 address syntax does, i.e., consistently canonical behavior. Aside: this work is related to the reverse-engineering of IPv6 netmask remotely: <a href="http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf" rel="nofollow">http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf</a>
Sheesh. Best i recall, they chose this pattern because it matched the notation used for MAC addresses. And a IPv6 network can in essence self-assemble by using said MAC as a basis for the IPv6 address.<p>Edit:<p>BTW, don't most home routers etc take a hostname and add it to a .local DNS domain stored on the router?
I've mostly avoided IPv6 because AWS uses IPv4 and it works fine.<p>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.
I don't see any of it as an issue.<p>String representations of IPV4's aren't all of equal string length either.<p>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.<p>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.
I deal with IPv6 day in and day out and I don't share the same confusion and annoyances the author does. Sure, there's a learning hurdle, but once you're over it, it's fairly smooth.
The proposal doesn't mention it, but part of the existing IPv6 address syntax is that, for transition mechanisms, it offers the option to embed a dotted format IPv4 address syntax in the end of an IPv6 address:
<a href="https://tools.ietf.org/html/rfc4291#section-2.2" rel="nofollow">https://tools.ietf.org/html/rfc4291#section-2.2</a><p>Examples:
2001:DB8::13.1.68.3
::FFFF:129.144.52.38<p>In the suggested format, we'd lose this convenient transition feature and are left with:
20010DB8..d014403
..FFFF81903426<p>This is less clear than the existing method with the colons and dots.<p>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<p>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?<p>And what about parsing "FFFF129"? Are we really going to change base from 16 to 10 between the "F" and the "1"?<p>Or are we going to introduce another separator, e.g., a leading "." on IPv4 addresses?<p>..FFFF.129.144.52.38<p>Or are we going to require that the ".." be the separator there?<p>0000:0000:0000:0000:0000:FFFF..129.144.52.38<p>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.)<p>To add another historic complication for some implementations:
<a href="https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_address" rel="nofollow">https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_addr...</a><p>a leading zero on an IPv4 address octet meant that the byte is specified in octal.<p>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.<p>All in all, it looks to me like the early IPv6 community thought about the address syntax... a lot.
Actually the IPv6 address allows you to put a lot of useful detail into your address scheme. If this is supposed to be a complaint from a network admin he simply doesn't know how to plan an IPv6 deployment properly.<p>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<p>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.
What's the point of using non standard ports with IPv6? If a machine can have a million different IPv6, why would one even bother using a non standard port?
Interesting; Mac OS double-click highlighting doesn't actually handle all the examples given in the article. e.g. deadbeef00000000.1 works, but deadbeef.1 doesn't. I guess the first segment needs to contain a digit, which perhaps triggers a mode where the period is interpreted as a decimal point.
"Last but not least, nearly all graphical terminals refuse to highlight IPv6 addresses with a simple double-click. This issue might not have existed in the mid-late 1990s"<p>Yes, we'd barely introduced fire then, we certainly didn't have the technology to double click to highlight a word...
I don't see any problems with the current IPv6 apart from backward incompatibility with IPv4. If IPv6 is difficult to start with, I would recommend to look at MAC address, Wi-Fi address, Bluetooth address first and then you will understand more about IPv6
As I understand it a lot of work went into making SLAAC in order to overcome the hassle of having to manually handle these IPv6 addresses. The idea is that you shouldn't usually have to type in a full IPv6 address by hand.
Imagine reading IPv4 addresses over a crummy radio on a loud manufacturing plant floor while troubleshooting connectivity issues. Now imagine reading an IPv6 address in the same conditions.
Upper estimation of human population is 7.4 billion. With average number of devices at 5, that is 37 billion. In decimal that is 11 digits. In HEX (89D5F3200) that is 9 digits.
"Yes, this is very likely a pointless bunch of gripes."<p>The article should have <i>started</i> 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."
> To fix the ambiguity, brackets were introduced<p>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:::]"<p>the order for parsing for a URI is:<p>// host = IP-literal / IPv4address / reg-name<p>// IP-literal = "[" ( IPv6address / IPvFuture ) "]"<p>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<p>// [ userinfo "@" ] host [ ":" port ]<p>> why not re-use the dot from IPv4 notation<p>because you have conflicts from "0.0 -> 0.0.0.0" to "255.16777215 -> 255.255.255.255"<p>0-9 conflicts with an IPv4 decimal<p>a-f conflicts with GTLDs<p>the only reason your blobs don't have a conflict with an IPv4 Historic is because hexadecimal notation starts with 0x<p>> try double clicking on those<p>try double clicking on any of these valid characters from "reg-name"<p>// unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"<p>// sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "<i>" / "+" / "," / ";" / "="<p>or these from IPvFuture<p>// IPvFuture = "v" 1</i>HEXDIG "." 1<i>( unreserved / sub-delims / ":" )<p>// unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"<p>// sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "</i>" / "+" / "," / ";" / "="<p>if you want to develop your own "standard" either use the literal IPvFuture, or use a Registered Name<p>non literals IPv4, IPv4Historic, and Domain names are valid registered names, but domain names aren't even part of the URI standard<p>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<p>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<p>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<p><i>edit</i> trying to figure out newline parsing