
The IPv6 Numeric IP Format Is a Usability Problem - LukeLambert
https://www.zerotier.com/blog/?p=724
======
mrb
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
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
Developers deal with raw ipv4s, but end users? Unless you're setting up a
wireless router, when does that actually happen?

~~~
jfoster
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
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
Exactly. There wouldn't be any need for the colons if the addresses weren't
intended to be looked at or typed by humans.

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

~~~
emmelaich
Most IT operations people within corporate networks use ips instead of names.
And unix admins only trust ips in their host firewalls. So many things rely on
the ip address that people get to know that 10.1.0.0 is headquarters and
10.1.3.0 is marketing and 10.4.0.0 is Seattle .. etc etc.

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.

~~~
mulmen
I know that some network configurations will still have to use actual IPv6
addresses but for the most part you could save yourself a lot of pain by just
using DNS and hostnames.

~~~
emmelaich
When I speak to our network guys to get a firewall entry they don't want to
hear about names. Their network diagrams don't have names. Using names to them
is unnecessary cognitive load.

~~~
belorn
What would happen if your current ISP got problems and you had to switch to a
different ISP with a new range of addresses (assuming you don't have operator
independent addresses and not using BGP)?

~~~
wmf
They'd NAT. And they're probably already NATed, so it would just be a few
changes on the outside of the firewall.

~~~
feld
Good luck NATing v6

~~~
soneil
That's already done. If you're big enough that renumbering is a concern, but
small enough that you don't have your own assigned prefix, you use unique
local addresses (fc00::/7) and NAT them to your providers space. (Which works
better than it sounds - because you have enough space to nat one-to-one, the
translation mechanism doesn't need to keep state. Simply replace one prefix
with another, whack a new checksum in and send it along)

------
elcritch
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?

~~~
na85
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

~~~
Nadya
_> That results in a different usability problem. Installed fonts are very
nonstandard._

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](http://i.imgur.com/8PoNfdJ.png)

~~~
arm
Your browser/OS should be using font substitution¹ though when it encounters a
character that the current font doesn’t have a glyph for. Font substitution is
pretty much necessary since it’s currently impossible for one font to hold
Unicode’s repertoire of 110,000+ characters; even the OpenType format is
limited to a maximum of 65,536 glyphs.

Assuming that it _is_ using font substitution (as it should be whether or not
you’ve chosen _Sofia Pro_ as your browser’s default sans-serif font… unless
you’ve also changed some other settings too), then the reason those characters
show up as question marks is because you don’t have any fonts installed
containing glyphs for those characters. (I’d recommend _Everson Mono_ ² or
_Symbola_ ³).

――――――

¹ —
[https://en.wikipedia.org/wiki/Font_substitution](https://en.wikipedia.org/wiki/Font_substitution)

² —
[https://en.wikipedia.org/wiki/Everson_Mono](https://en.wikipedia.org/wiki/Everson_Mono)

³ —
[https://web.archive.org/web/20150625020428/http://users.teil...](https://web.archive.org/web/20150625020428/http://users.teilar.gr/~g1951d/)

~~~
Nadya
_> Assuming that it is using font substitution (as it should be whether or not
you’ve chosen Sofia Pro as your browser’s default sans-serif font… unless
you’ve also changed some other settings too),_

Yes, actually. The _only_ two fonts my browser is permitted to use are Sofia
Pro and Meiryo. My point being nothing is wrong with alphanumeric
representations of hexadecimal. Short of glyph fonts like Webdings, every font
supports alphanumerics - even CJK fonts.

Some users change settings - heavily so. The "safest default" should be the
assumption. Changing something that works for most people to work only for
"people with a proper supporting font installed" is breaking the web as far as
any devs should be concerned.

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

------
__david__
Better not tell this guy about abbreviating ipv4 addresses.
[http://127.1/](http://127.1/) or [http://2130706433/](http://2130706433/)
might blow his mind.

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

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

~~~
joveian
[https://www.ietf.org/rfc/rfc1924.txt](https://www.ietf.org/rfc/rfc1924.txt)

(base 85 representation of IPv6 addresses)

~~~
Dylan16807
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
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_C...](https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments)

[1] [https://tools.ietf.org/html/rfc1149](https://tools.ietf.org/html/rfc1149)

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

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

~~~
multinglets
I don't even get why we have IP addresses anymore. Just use DNS duh.

~~~
aikah
DNS are centralized , IPs are not. When USA decides to block or take down you
domain name, because they can, all you have left is your IP, they can't take
your IP.

~~~
Piskvorrr
Meet [https://www.arin.net/](https://www.arin.net/) and friends.

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

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

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

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

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

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

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

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

------
ck2
To make things worse are vanity ipv6 addresses

    
    
         2001:4b10:bbc::1
    
         2a03:2880:2110:df07:face:b00c:0:1

~~~
mnordhoff

        www.sprint.net has address 208.24.22.50
        www.sprint.net has IPv6 address 2600::

------
digi_owl
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?

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

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

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

------
plonka
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_addr...](https://en.wikipedia.org/wiki/Dot-
decimal_notation#IPv4_address)

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.

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

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

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

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

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

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

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

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

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

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

------
emmelaich
How about base32 with semicolons for separators?

No case issues, semicolons don't appear in dns or ipv4, no shift key required.

------
epx
People complain too much about anything...

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

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

------
emansom
This is satire, right?

~~~
digi_owl
If only...

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

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

------
jacksonsabey
> 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" 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

~~~
deathanatos
> _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._

