14 ms·

The IPv6 Numeric IP Format Is a Usability Problem

323 points by LukeLambert 11y ago

makecheck 11y ago
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 only when presented with an address string that uses the maximum possible IPv6 address length. 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".
- Gibbon1 11y ago
  I wonder if some sort of base64 encoding wouldn't have been better. "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.
  - vidoc 11y ago
    Anything that would make addresses case sensitive would I think be a terrible idea.
  - joveian 11y ago
    https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)
    - Dylan16807 11y ago
      Base85 naturally encodes 32 bits at a time into 5 characters, why is this using 128 bit math? I can't tell if it's a joke, with that date. Edit: The commentary at the end suggests more of a joke, even though "It may be expected that future processors will address this defect, quite possibly before any significant IPv6 deployment has been accomplished." wasn't exactly false. I'm not sure why you linked an intentionally-bad RFC for a reasonable concept?
      - greggyb 11y ago
        April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C... [1] https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149
        Dylan16807 11y ago
        Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.
        joveian 11y ago
        I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.
    - Gibbon1 11y ago
      My Dad told me once, every good idea has already been thought of by someone else.
- vidoc 11y ago
  > 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 only when presented with an address string that uses the maximum possible IPv6 address length. 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.
- nradov 11y ago
  Formats like this are a great place to apply fuzz testing. It's easy to write automated test code that generates IPv6 addresses which at least look valid according to the BNF specification. That way you can get pretty good test coverage without having to manually figure out all the possible edge cases.
- zimbatm 11y ago
  The issue with the dot alone is that in some cases it's indistinguishable from a domain name. "dead.beef" is bound to exist now that ICANN is going crazy with top-level domains.
  - api 11y ago
    Someone on Reddit suggested two dots.
    - zeveb 11y ago
      Which of course doesn't help save keystrokes…
      - api 11y ago
        Sure it does: : == two keystrokes using two separate fingers . == one keystroke using one finger .. == ~1.25 (ish) keystrokes, since your finger has to move to the dot once and then tap twice and only one finger is involved :: == 3 keystrokes using two fingers
        wallacoloo 11y ago
        I respectfully disagree. In normal typing, I don't consider a capital "I" to be significantly more taxing than a lowercase "i". Relatedly, I think there's a reason that I've never heard an argument about why we should prefer square brackets over parentheses (square brackets require no shift while parentheses do). Right off the bat, I notice that when I'm quoting something using double quotes or placing something in parentheses or curly braces, I don't even have to think about pressing shift. I type them just as quickly as any other punctuation. So I don't think there's much validity to this argument based solely on keystrokes.
        krylon 11y ago
        > square brackets require no shift while parentheses do On a German keyboard, parentheses require a shift, but to get square brackets, one needs to hit AltGr (or "Option" on a Mac keyboard) which quickly gets annoying if one has to do it a lot. Except for that, I agree with you.
- moreentropy 11y ago
  An IPv6 address has 16 bytes and that's how to store them, period. For parsing / generating a string representation there's RFC5952 and libraries in every language that implement it.
victorhugo31337 11y ago
Finally, someone said it! I've always felt that the biggest hurdle in IPv6 adoption is the complicated address notation.
Piskvorrr 11y ago
Aaand that's why we have DNS. Solved decades ago, next.
- api 11y ago
  Not solved on LANs, ad-hoc local networks, virtual networks, or when DNS is down or broken. 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.
  - tekklloneer 11y ago
    Hostname discovery (mdns), etc solves it on local networks. If DNS is down or broken, it would be difficult for me to "use the internet", and I'd have to copy and paste a lot anyways.
    - api 11y ago
      mDNS is slow and unreliable and on large networks it doesn't scale. I personally don't find it very useful since half the time it barely works even on wired LANs let alone big WiFi or distributed networks. It's also prone to naming conflicts (is this linux-1, linux-2, or linux-3?) and other OS configuration issues and is not secure.
      - jauer 11y ago
        On a network like that, wouldn't DDNS solve the problem? I mean DDNS where the DHCP server tells the DNS server which IP has what hostname, not e.g. dyndns.
cm2187 11y ago
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?
- mcherm 11y ago
  Because we have decades worth of existing software and existing standards which count on there being ports. We have standard ports for different software applications, we have changing port number on the same machine to reach a different service -- if we eliminated ports it wouldn't just replace IP addresses of one type with a new type, it would ALSO change lots of other things from the networking layer all the way up to the application layer.
  - cm2187 11y ago
    I am not suggesting eliminating ports. The author describes having to specify a non standard port in the browser as a major annoyance. In a world where you have infinite IPs you would rather use another IP than listen to https on a non standard port.
  - XorNot 11y ago
    Except we are heading in that direction anyway with software containers and efforts to give full networking support to them. 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.
  - killface 11y ago
    Kind of like switching an addressing format?
- akira2501 11y ago
  You can have millions if you manually configure them, the DHCPv6 and SLAAC will not grab several addresses for use.
  - cm2187 11y ago
vidoc 11y ago
the double-click thingy can be remedied on xorg by adding 58:48 to the X resources, e.g: XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48,43:48,58:48
baudehlo 11y ago
Let's just speak them: http://blog.jgc.org/2011/07/pronounceable-ipv6-addresses-wpa2-psk.html http://blog.jgc.org/2011/07/pronounceable-ipv6-addresses-wpa...
teddyh 11y ago
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. 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.
- pas 11y ago
  So, why not fix these problems? Go through the RFC process, if it doesn't collide with anything, it'll make it into the standard, IPv6.1 or whatever, and eventually things will support it. Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all? 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?
  - teddyh 11y ago
    > Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all? 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.
tyingq 11y ago
I don't see any of it as an issue. 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.
mintplant 11y ago
> 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: > 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.
mrb 11y ago
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). 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.
- alexandrerond 11y ago
  It helps little to say it wasn't designed to be exposed, because it will. We have DNS now, and still many times we deal with raw ipv4s, end users too. It's not like we have a choice most of the times...
  - praxulus 11y ago
    Developers deal with raw ipv4s, but end users? Unless you're setting up a wireless router, when does that actually happen?
    - jfoster 11y ago
      Not all, but many end users frequently need to input IP addresses when any type of connection is being made on a private network that isn't using DNS.
      - baby 11y ago
        And that's when having a : every X letters will help you catch where you are when you'll be typing that long string.
        jfoster 11y ago
emansom 11y ago
This is satire, right?
- digi_owl 11y ago
  If only...
x0 11y ago
Thank you! Finally, someone else is saying what I've been thinking.
ck2 11y ago
To make things worse are vanity ipv6 addresses 2001:4b10:bbc::1 2a03:2880:2110:df07:face:b00c:0:1
- mnordhoff 11y ago
  www.sprint.net has address 208.24.22.50 www.sprint.net has IPv6 address 2600::
epx 11y ago
People complain too much about anything...
kaydo_com_au 11y ago
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
paulannesley 11y ago
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.
jsz0 11y ago
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.
nemith 11y ago
Good points, just 25 years too late. This shouldn't be a post in 2016.
elcritch 11y ago
If you're really adventurous, you could just use Braille which has 255 Unicode symbols. Ahem ip6emoji("fe8000000000000003ceecdfffe30c27",Char(0x2800)) => "⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧" Then: deadbeef000000000000000000000001 2607f2f8a36800000000000000000002 fe8000000000000003ceecdfffe30c27 fe800000000000000000000000000001 2607f8b040078090000000000000200e Becomes: ⣞⢭⢾⣯⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁ ⠦⠇⣲⣸⢣⡨⠀⠀⠀⠀⠀⠀⠀⠀⠀⠂ ⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧ ⣾⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁ ⠦⠇⣸⢰⡀⠇⢀⢐⠀⠀⠀⠀⠀⠀⠠⠎ 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?
- proactivesvcs 11y ago
  I parsed that as Conway's Life. Which is odd, because I've not played with, nor seen it, since about 1993! I'll be plumbing that into Life to see what happens.
  - elcritch 11y ago
    hehe, now I'm going to envision a giant Conway's game of life being played every time I see a room full of IoT devices on IPv6. 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_systems https://en.wikipedia.org/wiki/Calculus_of_communicating_syst...
- kbenson 11y ago
  I guess if you make sure to always use a mono-space version of Braille (I'm not sure that makes sense, it could be a requirement it be mono-spaced) and have really good whitespace awareness. That output gives me a very good quick general feel of an address, but very poor fidelity.
- na85 11y ago
  That results in a different usability problem. Installed fonts are very nonstandard. At the moment I happen to be on an up-to-date version of Windows 7 and here's what it looks like: http://imgur.com/U5vZFRQ http://imgur.com/U5vZFRQ *edit: though it appears to render properly on Debian
csours 11y ago
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.
- simoncion 11y ago
  You do what the US Army has been doing on the battlefield for many, many decades: use the NATO phonetic alphabet. https://en.wikipedia.org/wiki/NATO_phonetic_alphabet https://en.wikipedia.org/wiki/NATO_phonetic_alphabet
digi_owl 11y ago
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. Edit: BTW, don't most home routers etc take a hostname and add it to a .local DNS domain stored on the router?
lamontcg 11y ago
"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" Yes, we'd barely introduced fire then, we certainly didn't have the technology to double click to highlight a word...
castratikron 11y ago
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.
emmelaich 11y ago
How about base32 with semicolons for separators? No case issues, semicolons don't appear in dns or ipv4, no shift key required.
killface 11y ago
I've mostly avoided IPv6 because AWS uses IPv4 and it works fine. 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.
jacksonsabey 11y ago
> To fix the ambiguity, brackets were introduced 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" 1HEXDIG "." 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
- deathanatos 11y ago
  > ipv6 just happens to use a colon which conflicts with the port delimiter from authority in a URI 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.
acscott 11y ago
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.
pmarreck 11y ago
The FIRST problem is that IPv6 wasn't designed to be backwards-compatible with IPv4. That is the MAIN reason why its deployment and adoption rate has been a long clusterfuck.
- TenOhms 11y ago
  I wonder if it couldn't still be accomplished at this late hour. An RFC to reserve 32 bits of an IPv6 Address along with a logical (read: Easy to remember) remaining 96 bits might be in order.
  - chronid 11y ago
    In theory - and if I remember correctly - you can embed IPv4 addresses into IPv6 addresses. The prefix should be all zeroes, so you get something like: ::12.123.99.222 Which is not that hard to remember. :P
  - pmarreck 11y ago
    Could they modify IPv4 in a backwards-compatible way, allocating more address space to that part of the TCP header for example? And including perhaps a version flag? 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
- _ikke_ 11y ago
  The problem isn't that IPv6 isn't backwards compattible. The problem is that IPv4 is not forwards compattible. Arstechnica has an article about it: http://arstechnica.com/business/2016/01/ipv6-celebrates-its-20th-birthday-by-reaching-10-percent-deployment/2/ http://arstechnica.com/business/2016/01/ipv6-celebrates-its-...
- lurkinggrue 11y ago
  Yeah, they really didn't think though the transition when designing IPv4.
runjake 11y ago
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.
jrockway 11y ago
If the colons make you sad, don't worry, the addresses are represented with dots in some places. For example, DNS: $ 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
exxo_ 11y ago
You can already have dots in IPv6 addresses if it's an IPv4-mapped/compatible address (e.g. ::FFFF:129.144.52.38)
imoverclocked 11y ago
"Yes, this is very likely a pointless bunch of gripes." 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."
__david__ 11y ago
Better not tell this guy about abbreviating ipv4 addresses. http://127.1/ http://127.1/ or http://2130706433/ http://2130706433/ might blow his mind.
bekreyev 11y ago
You can write everything as you like in DNS. IPv6 is not a problem.
bekreyev 11y ago
You can write as you like in DNS. IPv6 is not a problem.
feld 11y ago
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. 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.
feld 11y ago
No mention of ipv6buddy.com in the comments is a real shame
plonka 11y ago
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: http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf
plonka 11y ago
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: https://tools.ietf.org/html/rfc4291#section-2.2 https://tools.ietf.org/html/rfc4291#section-2.2 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_address 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.
bigbugbag 11y ago
What a bunch of nonsense ! 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.

323 points by LukeLambert 11y ago

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 only when presented with an address string that uses the maximum possible IPv6 address length. 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".

Gibbon1 11y ago
I wonder if some sort of base64 encoding wouldn't have been better. "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.
- vidoc 11y ago
  Anything that would make addresses case sensitive would I think be a terrible idea.
- joveian 11y ago
  https://www.ietf.org/rfc/rfc1924.txt https://www.ietf.org/rfc/rfc1924.txt (base 85 representation of IPv6 addresses)
  - Dylan16807 11y ago
    Base85 naturally encodes 32 bits at a time into 5 characters, why is this using 128 bit math? I can't tell if it's a joke, with that date. Edit: The commentary at the end suggests more of a joke, even though "It may be expected that future processors will address this defect, quite possibly before any significant IPv6 deployment has been accomplished." wasn't exactly false. I'm not sure why you linked an intentionally-bad RFC for a reasonable concept?
    - greggyb 11y ago
      April Fool's RFCs are a bit of a tradition[0]. I'm a fan of the proposal for IPoAC[1]. [0] https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C... [1] https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149
      - Dylan16807 11y ago
        Oh I understand why the RFC exists. But they should have put a bit more effort into it, and joveian should have made clear that it was a low-effort RFC, joke or not. I'll be more clear about my earlier post. I realized the RFC itself was put out as a joke, but I couldn't really tell if the 128 bit math was bad on purpose or out of laziness. Or what the RFC author actually thought about using such a compact representation.
        joveian 11y ago
        I am curious about the background behind it and the author's opinion of the basic idea as well. I think the 128-bit math part was just intended to invent context for a jab at standards that assume recent hardware and not really intended to make sense in context. I admit it was a low effort comment on my part :/. It seems like something along those lines could be a good idea, although in practice I think 22 URL-safe base64 characters with four error correction bits would be better representation. Looking at Wikipedia's nice base64 page, one possibility would be to use '-' and '_' for the two non-alphanumeric characters and allow the longest run of zeros ('A's) to be changed to '~'. Automatic error detection seems like a really good idea whenever humans are forced to interact with 128-bit numbers, but then you can't easily generate subnet masks by hand. In general, I think avoiding interacting with them as much as possible is the most important step. At this point, it would take a while for any alternate representation to be widely supported by software even if there was wide agreement that it was a good idea. OTOH, a general "least bad" compact representation of larger numbers with error detection could potentially be useful for other things (even if it doesn't get used for IPv6), such as ECC public keys.
  - Gibbon1 11y ago
    My Dad told me once, every good idea has already been thought of by someone else.
vidoc 11y ago
> 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 only when presented with an address string that uses the maximum possible IPv6 address length. 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.
nradov 11y ago
Formats like this are a great place to apply fuzz testing. It's easy to write automated test code that generates IPv6 addresses which at least look valid according to the BNF specification. That way you can get pretty good test coverage without having to manually figure out all the possible edge cases.
zimbatm 11y ago
The issue with the dot alone is that in some cases it's indistinguishable from a domain name. "dead.beef" is bound to exist now that ICANN is going crazy with top-level domains.
- api 11y ago
  Someone on Reddit suggested two dots.
  - zeveb 11y ago
    Which of course doesn't help save keystrokes…
    - api 11y ago
      Sure it does: : == two keystrokes using two separate fingers . == one keystroke using one finger .. == ~1.25 (ish) keystrokes, since your finger has to move to the dot once and then tap twice and only one finger is involved :: == 3 keystrokes using two fingers
      - wallacoloo 11y ago
        I respectfully disagree. In normal typing, I don't consider a capital "I" to be significantly more taxing than a lowercase "i". Relatedly, I think there's a reason that I've never heard an argument about why we should prefer square brackets over parentheses (square brackets require no shift while parentheses do). Right off the bat, I notice that when I'm quoting something using double quotes or placing something in parentheses or curly braces, I don't even have to think about pressing shift. I type them just as quickly as any other punctuation. So I don't think there's much validity to this argument based solely on keystrokes.
        krylon 11y ago
        > square brackets require no shift while parentheses do On a German keyboard, parentheses require a shift, but to get square brackets, one needs to hit AltGr (or "Option" on a Mac keyboard) which quickly gets annoying if one has to do it a lot. Except for that, I agree with you.
moreentropy 11y ago
An IPv6 address has 16 bytes and that's how to store them, period. For parsing / generating a string representation there's RFC5952 and libraries in every language that implement it.

victorhugo31337 11y ago

Finally, someone said it! I've always felt that the biggest hurdle in IPv6 adoption is the complicated address notation.

Piskvorrr 11y ago

Aaand that's why we have DNS. Solved decades ago, next.

api 11y ago
Not solved on LANs, ad-hoc local networks, virtual networks, or when DNS is down or broken. 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.
- tekklloneer 11y ago
  Hostname discovery (mdns), etc solves it on local networks. If DNS is down or broken, it would be difficult for me to "use the internet", and I'd have to copy and paste a lot anyways.
  - api 11y ago
    mDNS is slow and unreliable and on large networks it doesn't scale. I personally don't find it very useful since half the time it barely works even on wired LANs let alone big WiFi or distributed networks. It's also prone to naming conflicts (is this linux-1, linux-2, or linux-3?) and other OS configuration issues and is not secure.
    - jauer 11y ago
      On a network like that, wouldn't DDNS solve the problem? I mean DDNS where the DHCP server tells the DNS server which IP has what hostname, not e.g. dyndns.

cm2187 11y ago

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?

mcherm 11y ago
Because we have decades worth of existing software and existing standards which count on there being ports. We have standard ports for different software applications, we have changing port number on the same machine to reach a different service -- if we eliminated ports it wouldn't just replace IP addresses of one type with a new type, it would ALSO change lots of other things from the networking layer all the way up to the application layer.
- cm2187 11y ago
  I am not suggesting eliminating ports. The author describes having to specify a non standard port in the browser as a major annoyance. In a world where you have infinite IPs you would rather use another IP than listen to https on a non standard port.
- XorNot 11y ago
  Except we are heading in that direction anyway with software containers and efforts to give full networking support to them. 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.
- killface 11y ago
  Kind of like switching an addressing format?
akira2501 11y ago
You can have millions if you manually configure them, the DHCPv6 and SLAAC will not grab several addresses for use.
- cm2187 11y ago

vidoc 11y ago

the double-click thingy can be remedied on xorg by adding 58:48 to the X resources, e.g: XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48,43:48,58:48

baudehlo 11y ago

Let's just speak them: http://blog.jgc.org/2011/07/pronounceable-ipv6-addresses-wpa2-psk.html http://blog.jgc.org/2011/07/pronounceable-ipv6-addresses-wpa...

teddyh 11y ago

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. 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.

pas 11y ago
So, why not fix these problems? Go through the RFC process, if it doesn't collide with anything, it'll make it into the standard, IPv6.1 or whatever, and eventually things will support it. Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all? 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?
- teddyh 11y ago
  > Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all? 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.

tyingq 11y ago

I don't see any of it as an issue. 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.

mintplant 11y ago

> 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: > 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.

mrb 11y ago

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). 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.

alexandrerond 11y ago
It helps little to say it wasn't designed to be exposed, because it will. We have DNS now, and still many times we deal with raw ipv4s, end users too. It's not like we have a choice most of the times...
- praxulus 11y ago
  Developers deal with raw ipv4s, but end users? Unless you're setting up a wireless router, when does that actually happen?
  - jfoster 11y ago
    Not all, but many end users frequently need to input IP addresses when any type of connection is being made on a private network that isn't using DNS.
    - baby 11y ago
      And that's when having a : every X letters will help you catch where you are when you'll be typing that long string.
      - jfoster 11y ago

emansom 11y ago

This is satire, right?

digi_owl 11y ago
If only...

x0 11y ago

Thank you! Finally, someone else is saying what I've been thinking.

ck2 11y ago

To make things worse are vanity ipv6 addresses 2001:4b10:bbc::1 2a03:2880:2110:df07:face:b00c:0:1

mnordhoff 11y ago
www.sprint.net has address 208.24.22.50 www.sprint.net has IPv6 address 2600::

epx 11y ago

People complain too much about anything...

kaydo_com_au 11y ago

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

paulannesley 11y ago

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.

jsz0 11y ago

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.

nemith 11y ago

Good points, just 25 years too late. This shouldn't be a post in 2016.

elcritch 11y ago

If you're really adventurous, you could just use Braille which has 255 Unicode symbols. Ahem ip6emoji("fe8000000000000003ceecdfffe30c27",Char(0x2800)) => "⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧" Then: deadbeef000000000000000000000001 2607f2f8a36800000000000000000002 fe8000000000000003ceecdfffe30c27 fe800000000000000000000000000001 2607f8b040078090000000000000200e Becomes: ⣞⢭⢾⣯⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁ ⠦⠇⣲⣸⢣⡨⠀⠀⠀⠀⠀⠀⠀⠀⠀⠂ ⣾⢀⠀⠀⠀⠀⠀⠀⠃⣎⣬⣟⣿⣣⠌⠧ ⣾⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁ ⠦⠇⣸⢰⡀⠇⢀⢐⠀⠀⠀⠀⠀⠀⠠⠎ 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?

proactivesvcs 11y ago
I parsed that as Conway's Life. Which is odd, because I've not played with, nor seen it, since about 1993! I'll be plumbing that into Life to see what happens.
- elcritch 11y ago
  hehe, now I'm going to envision a giant Conway's game of life being played every time I see a room full of IoT devices on IPv6. 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_systems https://en.wikipedia.org/wiki/Calculus_of_communicating_syst...
kbenson 11y ago
I guess if you make sure to always use a mono-space version of Braille (I'm not sure that makes sense, it could be a requirement it be mono-spaced) and have really good whitespace awareness. That output gives me a very good quick general feel of an address, but very poor fidelity.
na85 11y ago
That results in a different usability problem. Installed fonts are very nonstandard. At the moment I happen to be on an up-to-date version of Windows 7 and here's what it looks like: http://imgur.com/U5vZFRQ http://imgur.com/U5vZFRQ *edit: though it appears to render properly on Debian

csours 11y ago

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.

simoncion 11y ago
You do what the US Army has been doing on the battlefield for many, many decades: use the NATO phonetic alphabet. https://en.wikipedia.org/wiki/NATO_phonetic_alphabet https://en.wikipedia.org/wiki/NATO_phonetic_alphabet

digi_owl 11y ago

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. Edit: BTW, don't most home routers etc take a hostname and add it to a .local DNS domain stored on the router?

lamontcg 11y ago

"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" Yes, we'd barely introduced fire then, we certainly didn't have the technology to double click to highlight a word...

castratikron 11y ago

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.

emmelaich 11y ago

How about base32 with semicolons for separators? No case issues, semicolons don't appear in dns or ipv4, no shift key required.

killface 11y ago

I've mostly avoided IPv6 because AWS uses IPv4 and it works fine. 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.

jacksonsabey 11y ago

> To fix the ambiguity, brackets were introduced 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" 1HEXDIG "." 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

deathanatos 11y ago
> ipv6 just happens to use a colon which conflicts with the port delimiter from authority in a URI 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.

acscott 11y ago

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.

pmarreck 11y ago

The FIRST problem is that IPv6 wasn't designed to be backwards-compatible with IPv4. That is the MAIN reason why its deployment and adoption rate has been a long clusterfuck.

TenOhms 11y ago
I wonder if it couldn't still be accomplished at this late hour. An RFC to reserve 32 bits of an IPv6 Address along with a logical (read: Easy to remember) remaining 96 bits might be in order.
- chronid 11y ago
  In theory - and if I remember correctly - you can embed IPv4 addresses into IPv6 addresses. The prefix should be all zeroes, so you get something like: ::12.123.99.222 Which is not that hard to remember. :P
- pmarreck 11y ago
  Could they modify IPv4 in a backwards-compatible way, allocating more address space to that part of the TCP header for example? And including perhaps a version flag? 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
_ikke_ 11y ago
The problem isn't that IPv6 isn't backwards compattible. The problem is that IPv4 is not forwards compattible. Arstechnica has an article about it: http://arstechnica.com/business/2016/01/ipv6-celebrates-its-20th-birthday-by-reaching-10-percent-deployment/2/ http://arstechnica.com/business/2016/01/ipv6-celebrates-its-...
lurkinggrue 11y ago
Yeah, they really didn't think though the transition when designing IPv4.

runjake 11y ago

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.

jrockway 11y ago

If the colons make you sad, don't worry, the addresses are represented with dots in some places. For example, DNS: $ 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

exxo_ 11y ago

You can already have dots in IPv6 addresses if it's an IPv4-mapped/compatible address (e.g. ::FFFF:129.144.52.38)

imoverclocked 11y ago

"Yes, this is very likely a pointless bunch of gripes." 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."

__david__ 11y ago

Better not tell this guy about abbreviating ipv4 addresses. http://127.1/ http://127.1/ or http://2130706433/ http://2130706433/ might blow his mind.

bekreyev 11y ago

You can write everything as you like in DNS. IPv6 is not a problem.

bekreyev 11y ago

You can write as you like in DNS. IPv6 is not a problem.

feld 11y ago

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. 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.

feld 11y ago

No mention of ipv6buddy.com in the comments is a real shame

plonka 11y ago

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: http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf

plonka 11y ago

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: https://tools.ietf.org/html/rfc4291#section-2.2 https://tools.ietf.org/html/rfc4291#section-2.2 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_address 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.

bigbugbag 11y ago

What a bunch of nonsense ! 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.