2000:1::1 would expand to 2000:0001:0000:0000:0000:0000:0000:0001

2000::1::1 could be 2000:0000:0000:0000:0001:0000:0000:001, or 2000:00000000:0001:0000:0000:0000:001

There's ambiguity on where to fill in the five groups of 0000 in the second case.

The second address is invalid. You can only use :: once per address.

Edit: Whoops. Didn't read what the above post was in response to. My bad.

That exactly what was the question about and they explained why it is invalid…

> This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.

Except if you're using a mobile phone, in which case many telcos hand out only IPv6 addresses to handsets. 2018 NANOG presentation "T-Mobile's journey to IPv6":

* https://www.youtube.com/watch?v=d6oBCYHzrTA

From 2014, "Case Study: T-Mobile US Goes IPv6-only Using 464XLAT":

* https://www.internetsociety.org/deploy360/2014/case-study-t-...

But who cares about mobile phones, right? They're only second-grade devices.

my tmobile 5g modem has ipv4 but changes ip every single page load, it's wild

I'm used to cablemodems with static ipv4 for months basically until mac changes

Is it per chance 100.64.0.0/10?

* https://en.wikipedia.org/wiki/IPv4_shared_address_space

It could be 21.0/8

ref:https://old.reddit.com/r/tmobileisp/comments/1gg7361/why_is_...

I booted an LTE router using a T-Mobile SIM.

Within an hour I had changed WAN IP. Both were from AS749 US-DOD NIC

    in 33.79.135.0/24 & 21.140.100.0/24.

They were cgnat'd behind TMble's advertised asn.

> my tmobile 5g modem has ipv4 but changes ip every single page load, it's wild

They're probably using CG-NAT, though IP changes that often is a bit aggressive.

> They're probably using CG-NAT, though IP changes that often is a bit aggressive.

TMobile uses IPv4 addys in DOD's address space. They do change unexpectedly often.

And yeah. Being DOD IPs, they're cgnat'd behind tmobile's public ASN.

Your IPv4 packets are getting tunneled to a CGNAT server which has an IP address pool.

Your website will load faster on cellphones if it supports IPv6. This is because the packets take more direct routes (because they don't go to the central CGNAT server) and because less processing is applied to them. Almost all mobile networks are now IPv6-only, with IPv4 traffic tunneled and CGNATted. Apparently T-Mobile is the rare exception.

I said this in a previous post and was shot down hard. I think you are right. Every time I look at a ipv6 address my brain goes “fack this”.

> Every time I look at a [long] ipv6 address my brain goes “fack this”.

I do get that but I also get 'There are so many I could have all I wanted ... or I could if any of our fiber ISPs would support it, that is'

I finally clicked when I worked out it was 2^64 subnets . You have a common prefix of you /48, which isn’t much longer than an ipv4 address - especially as it seems everything is 2001::/16, which means you basically have to remember a 32 bit network prefix just like 12.45.67.8/32.

That becomes 2001:0c2d:4308::/48 instead

After that you just need to remember the subnet number and the host number. If you remember 12.45.67.8 maps to 192.168.13.7 you might have

2001:0c2d:4308:13::7

So subnet “13” and host “7”

It’s not much different to remebering 12.45.67.8>192.168.13.7

> especially as it seems everything is 2001::/16

I was sort of expecting that this week.

I had to transcribe a v6 addy for a WAN-WAN test (a few mi apart).

That's when I noticed that Charter (Spectrum) had issued

   2603:: for one WAN and 
   2602:: for the other WAN.

ref: https://bgp.he.net/AS33363#_prefixes6

The current global unicast space is actually limited to just 2000::/3.

https://www.iana.org/assignments/ipv6-address-space/ipv6-add...

IPv4 isn't perfect, but it was designed to solve a specific set of problems.

IPv6 was designed by political process. Go around the room to each engineer and solve for their pet peeve to in turn rally enough support to move the proposal forward. As a bunch of computer people realized how hard politics were they swore never to do it again and made the address size so laughably large that it was "solved" once and for all.

I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.

My personal preference would have been to open up class E space (240-255.*) and claw back the 6 /8s Amazon is hoarding, be smarter about allocations going forward, and make fees logarithmic based on the number of addresses you hold.

> IPv4 isn't perfect, but it was designed to solve a specific set of problems.

IPv4 was not designed as such, but as an academic exercise. It was an experiment. An experiment that "escape the lab". This is per Vint Cerf:

* https://www.pcmag.com/news/north-america-exhausts-ipv4-addre...

And if you think there wasn't politics in iPv4 you're dead wrong:

* https://spectrum.ieee.org/vint-cerf-mistakes

> IPv6 was designed by political process.

Only if by "political process" you mean a bunch of people got together (physically and virtually) and debated the options and chose what they thought was best. The criteria for choosing IPng were documented:

* https://datatracker.ietf.org/doc/html/rfc1726

There were a number of proposals, and three finalists, with SIPP being chosen:

* https://datatracker.ietf.org/doc/html/rfc1752

> I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.

The primary reason for IPng was >32 bits of address space. The only way to make them shorter is to have fewer bits, which completely defeats the purpose of the endeavour.

There was no way to move from 32-bits to >32-bits without every network stack of every device element (host, gateway, firewall, application, etc) getting new code. Anything that changed the type and size of sockaddr->sa_family (plus things like new DNS resource record types: A is 32-bit only; see addrinfo->ai_family) would require new code.

This is a lot of basically sharpshooting, but I will address your last point:

> There was no way to move from 32-bits to >32-bits without every network stack of every device element (host, gateway, firewall, application, etc) getting new code. Anything that changed the type and size of sockaddr->sa_family (plus things like new DNS resource record types: A is 32-bit only; see addrinfo->ai_family) would require new code.

That is simply not true. We had one bit left (the reserved/"evil" bit) in IPv4 headers that could have been used to flag that the first N bytes of the payload were an additional IPv4.1 header indicating additional routing information. Packets would continue to transit existing networks and "4.1" capable boxes at edges could read the additional information to make further routing decisions inside of a network. It would have effectively used IPv4 as the core transport network and each connected network (think ASN) having a handful of routed /32s.

Overlay networks are widely deployed and have very minor technical issues.

But that would have only addressed the numbering exhaustion issues. Engineers often get caught in the "well if I am changing this code anyway" trap.

An explicit goal of IPv6 considered as important as the address expansion was the simplification of the packet header, by having fewer fields and which are correctly aligned, not like in the IPv4 header, in order to enable faster hardware routing.

The scheme described by you fails to achieve this goal.

I am glad you brought this up, that is another big issue with IPv6. A lot of the problems it was trying to solve literally don't exist anymore.

Header processing and alignment were an issue in the 90s when routers repurposed generic components. Now we have modern custom ASICs that can handle IPv4 inside of a GRE tunnel on a VLAN over MPLS at line rate. I have switches in my house that do 780 Gbps.

It is irrelevant what we can do now.

At the time when it was designed, IPv6 was well designed, much better than IPv4, which was normal after all the experience accumulated while using IPv4 for many years.

The designers of IPv6 have made only one mistake, but it was a huge mistake. The IPv4 address space should have been included in the IPv6 space, allowing transparent intercommunication between any IP addresses, regardless whether they were old IPv4 addresses or new IPv6 addresses.

This is the mistake that has made the transition to IPv6 so slow.

> The IPv4 address space should have been included in the IPv6 space, allowing transparent intercommunication between any IP addresses, regardless whether they were old IPv4 addresses or new IPv6 addresses.

How would you have implemented it that is different from the NAT64 that actually exists, including shoving all IPv4 addresses into 64:ff9b::/96?

Ideally, 464XLAT should have been there from the beginning and its host part (CLAT) should have been a mandatory part of IP stack.

> The IPv4 address space should have been included in the IPv6 space […]

See IPv4-mapped ("IPv4-compatible") IPv6 addresses from RFC 1884 § 2.4.4 (from 1995) and follow-on RFCs:

* https://datatracker.ietf.org/doc/html/rfc1884

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

> That is simply not true. We had one bit left (the reserved/"evil" bit) in IPv4 headers […]

Great, there's an extra bit in the IPv4 packet header.

I was talking about the data structures in operating systems: are there any extra bits in the sockaddr structure to signal things to applications? If not, an entirely new struct needs to be deployed.

And that doesn't even get into having to deploy new DNS code everywhere.

But v6 did do what you're describing here?

They didn't use the reserved bit, because there's a field that's already meant for this purpose: the next protocol field. Set that to 0x29 and it indicates that the first bytes of the payload contain a v6 address. Every v4 address has a /48 of v6 space tunnelled to it using this mechanism, and any two v4 addresses can talk v6 between them (including to the entire networks behind those addresses) via it.

If doing basically exactly what you suggested isn't enough to stop you from complaining about v6's designers, how could they possibly have done any better?

Imo they should have just clawed 1 or 2 bits out of the ipv4 header for additional routing and called it good enough

This would require new software and new ASICs on all hosts and routers and wouldn't be compatible with the old system. If you're going to cause all those things, might as well add 96 new bits instead of just 2 new bits, so you won't have the same problem again soon.

IPv6 is literally just IPv4 + longer addresses + really minor tweaks (like no checksum) + things you don't have to use (like SLAAC). Is that not what you wanted? What did you want?

And what's wrong with a newer version of a thing solving all the problems people had with it...?

There are more people than IPv4 addresses, so the pigeonhole principle says you can't give every person an IPv4 address, never mind when you add servers as well. Expanding the address space by 6% does absolute nothing to solve anything and I'm confused about why you think it would.

> Can someone explain why it's ambiguous?

Because you don’t know how many zeroes are on each side around the 0001 in the middle.

It can be 2000:0000:1:0000:0000:0000:0000:1 or 2000:0000:0000:0000:0000:1:0000:1 etc.

This shortcut system of ipv6 only makes it worse. It's too hard to remember how it works.

Is it really hard to remember? A hint is in the syntax itself. What's in between the two colons '::'? Nothing. In other words, all zeros.

IPv4 also has a similar, though rarely documented or utilized, shortcut system. Try `ping 1.1` for example. It expands to 1.0.0.1.

":: is all zeros" is too hard??

It's not just ":: is all zeroes"

… such as?

I am not clear what your point is. The parent's point stands. A double colon only represents zeros (that were compressed and are not displayed).

Your link does not show different addresses from a valid compression, it shows different addresses from an invalid compression. The link examples what we don't do.

Conversely, if we compress the expanded addresses in your link, we will get 2 different compressed addresses.

That's a post about invalid things that are not IPv6 addresses.

In IPv6 addresses, :: is all zeroes and there's no ambiguity.

How many zeros?

Exactly enough to fill out the address, which is always the same length. BTW, IPv4 does basically the same thing. The address 127.1 is equivalent to 127.0.0.1.

Not really the same, the mechanics are different and this particular behaviour is pretty much an accident, not abbreviation.

In IPv4 you also have 127.257 equal to 127.0.1.1, 123456789 equal to 7.91.205.21, and 010.010.010.010 is a well-know DNS server. This notation is also rejected by most implementations.

But IPv6 is "too hard"

It is? Those alternate IPv4 notations are all accepted by Linux, FreeBSD, and MacOS. I remember playing around with "alternate notations" 30+ years ago on old SunOS boxes.

However many it takes to make the whole A::B number exactly 128 bits long.

However many are left. In what circumstances do you care?

“Enough”

There are a total of 8 groups of 4 hex digits, so 8 minus however many groups you already have.

google.com: 2607:f8b0:4009:819::200e (5 groups) -> 2607:f8b0:4009:0819:0000:0000:0000:200e (3 groups of added zeros)

a ULA address: fd2a:1::2 (3 groups) -> fd2a:0001:0000:0000:0000:0000:0000:0002 (5 added)

localhost: ::1 -> 0000:0000:0000:0000:0000:0000:0000:0001

> Network-related things are generally easy to .. type from memory [but] IPv6 is just too long

I was reminded of this 2d ago; I was testing one IPv6 WAN from another. DDNS had failed so I didn't have my usual crutch to lean on.

I've said this since time immemorial, and networking people often dismiss it. "Just use DNS," say people who have never actually worked netops or devops.

The length of the addresses and the clunky nature of their ASCII representation is absolutely the #1 reason the IPv6 has taken this long. User experience is the most powerful force affecting large scale adoption, and IPv6 has poor UX.

I think the UX is partly fixable by creating less horrible ASCII representation, but this would take a lot of coordination that was hard even back then and is virtually impossible now. If someone told me in 500 years we're still running dual-stack IPv4/IPv6 absolutely unchanged, I'd believe it.

Half the reason (literally) the address looks so bad is not because of IPv6 but because everyone keeps choosing to implement randomized in-subnet addresses and cycle through them for privacy reasons.

E.g. 2600:15a3:7020:4c51::52/64 is not too horrible but 2600:15a3:7020:4c51:3268:b4c4:dd7b:789/64 is a monster by unrelated intent of the client.

This is pretty much on the money. IPv6 addressing can be pretty simple if you design your subnets and use low numbers for hosts. But hosts themselves will forgo that and randomly generate 64 bit random host addresses for themselves - some times for every new connection. Now you have thousands of IPv6 addresses for a single computer speaking out to the Internet.

"Modern" tooling in the consumer space is pretty dire for IPv6 support too. The best you can reasonably get is an IPv6 on the WAN side and then just IPv4 for everything local. At least from the popular routers I've experienced lately.

I’ve been amazed for years at the fact that many of the best routers turn V6 off by default.

Of course I know why. If you turn it on it slightly increases edge case issues as complexity always does. Most people don’t actively need it so nobody notices.

Yes, I forgot about SLAAC and worthless privacy extensions.

Privacy extensions are worthless because there are just sooooo many ways to fingerprint and track you. If you are not at least using a VPN and a jailed privacy mode browser at a bare minimum, you are toast. If you’re serious about privacy you have to use stuff like Tor.

V6 privacy extensions are like the GDPR cookie nonsense: ineffective countermeasures with annoying side effects.

SLAAC sucks too. They should have left assignment up to admins or higher level protocols like with V4. It’s better that way.

Privacy extensions are the reason your ISP can't make you pay money for the number of internet-connected devices at your house.

I think you just changed my mind. I hadn’t thought about that angle.

Respect for considering new information.

If ISPs tried that, everyone would just go back to using NAT, even for IPv6.

Most people are just using the ISP provided router as their gateway today anyways. E.g. ATT fiber is proud to advertise to you that it knows about each of your devices on the ONT+Router combo - that's even the only way to set up a port forward (you can't just type in an IP, you have to pick a discovered device).

"But people can NAT the v4 with another router to hide it!" -> sure, and the same crappy solution works with v6.

"But at least prosumers can replace the ONT via cloning the identifiers and certain hardware" -> also no change with v6.

Randomized addresses do have valid use cases though, particularly when connecting to Wi-Fi networks other than your own when set to randomize the MAC per connection (not just the scanning MAC) as well, but I'm just not really convinced this is a realistic example as framed.

I mean yes, but there’s no escape from the fact that ip addresses need to be longer as amount of devices on the internet already exhausted the pool of IPv4 addresses by multiple orders of magnitude.

I guess it could be possible to implement sort of mnemonic phrases for addresses, à la bip-39, but it would be just trading one kind of pain for another.

whats the rule to say where the first 1 floats between the 2000: and the :1 at the end? the :: rule says "all zeros" but not how long.

the :1 is short for :0001 basically and then just put that bit of the address at the very end and put the first bit of the address at the front, and then just fill each missing group inbetween with 0000

"just"

Yes, in fact "just". This isn't remotely hard.

These types of complaints are how I know the objection to v6 is not serious.

Well, okay, show us how to follow those instructions then.

"the :1 is short for :0001 basically" is easy enough: you get 2001::0001::0001.

Then "just put that bit at the very end" -- but which bit? If it means the ":0001", then there's two of them and they can't both go at the very end. If not, then it fails to specify which bit. Either way I don't see how these instructions are followable at all, let alone easily.

It’s a really complicated rule called “subtraction”. Addresses are always 128 bits long, or 8 groups of four hex digits. 2000::1 is two groups, so you need six groups in between to make 2000:0000:0000:0000:0000:0000:0000:1. But I don’t know why people always ask this, because it’s always the computer you are typing addresses in to that does the subtraction. You never ever have to type out the whole address. Just type the shortened version, because 2000::1 _is_ the whole address.

They were answering the question of why "2000::1::1" would be ambiguous if it was allowed.

My answer was too terse. IF there was two :: in the address, then the length of EACH :: denoted section is not known. It can be either longest left :: or longest right :: and that wasn't defined, because the rule is THERE IS ONLY ONE :: section.

Posed as a question, disingenuously.

> IPv6 is just too long and requires copy/paste all the time.

That is only true for autogenerated/SLAAC IPs. In contrast, manually assigned IPs are often much simpler and easier to remember in IPv6 than in IPv4. I have one common subnet prefix that can be uniformly split to end networks and last number in IP address for such network always end with 0 (and therefore the first device is xxx::1). While in IPv4 i had multiple prefixes, each split non-uniformly based on how many devices was expected to be on that end network, and because most end network prefixes were smaller than /24 (say /26-28), the last number of IP address varies between these networks.