As someone who grew up on IPv4, i will miss it, but the leap to 340 undecillion unique addresses is exciting in many ways so i think i can learn to live with this transition. If we ever need more than that, i can't even imagine what that future would look like.
I grew up with IPv4 too but after learning and configuring my network for IPv6 I won't miss v4 at all. It's just so nice having each device with its real IP address rather than some private NAT thing. Then it's just firewall config if you want to run servers etc rather than messing with NAT configs.
Agreed. My favorite part is that you don’t need any special consideration for local/WAN splits in DNS. Your DNS address for your homelab server is the same address on your LAN as it is on the WAN, so your DNS can just be the same. Thus “ssh hostname.fqdn” works whether you’re on the local network or remote, and your packets just automatically stay on your LAN when you’re local (they don’t even have to hit your router… they can directly unicast if you’re on the same switch. No “hairpin NAT” or anything like that needed.)
You can add ULA addresses to devices and use those in local DNS. Or just use the automatic link-local ones, One of the best things about IPv6 is support for multiple addresses per host and using them in different contexts.
I stopped maintaining local DNS and use mDNS instead which updates automatically.
I use ULA addresses in my local dns, the global address can change, privacy addresses can cycle and my local DNS keeps working. This also guarantees that the data you are pushing locally stays local since ULAs will never be sent out of the local network.
So if I'm checking local server log files to debug a problem that started a few days ago, I can't easily tell where the incoming connections are coming from?
I assume it's possible to prevent machines from changing their IP address? I have a few where DNS cannot reasonably be used and I use raw IP addresses instead.
IPv6 not just allowing, but expecting multiple scoped addresses relieves this quite nicely.
The most common setup for this is that you have a static link-local address, and a static global address. And listening processes should listen to these static addresses.
Then you have a temporary global address, and outbound connections should use the youngest temporary global address (because temporary addresses don't disappear when they age out, they disappear when they age out AND no existing connection is still using them).
The net effect is that the address you leave in example.com's httpd logs is a temporary address that has no listening processes. And the address you use in dns, mdns, when connecting intentionally, etc is a static address.
I add a specific static ip where I care (dns resolver). The machines usually give themselves a few other routable ips I guess for fun? No idea why they don’t go away.
The last time I looked into this (which was a few years ago), ISPs were allocating blocks containing billions of IPv6 addresses to anyone who paid a nominal sum.
So that vast address space might not last as long as it would seem...
> So that vast address space might not last as long as it would seem...
Have you done the math?
* math property: x^y = x^(a+b) = (x^a )x(x^b )
* IPv4 addresses are 32 bits (2^32 )
* 2^32 ~ 4.3 billion
* So the IPv4 Internet has ~4.3B devices on it
* IPv6 subnets are 64 bits, /64 (2^64 )
So, a IPv6 2^64 subnet is the same as (2^32 )x(2^32 ), which means (4.3B)x(IPv4 Internet). I.e., a single IPv6 subnet can hold the equivalent of four billion (IPv4) Internets.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
So (4x10^11 )x(2x10^12 )=8x10^23 stars in the universe.
* Size of IPv6 address space: 3.4x10^38
Find the ratio between addresses and stars:
* 3.4x10^38 / 8x10^23
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.
A third way: On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km2. Not counting the oceans, that would be 28 IPv4 addresses per km2 of land.
IPv6 gives 10^17 addresses per mm2 (yes, square millimeter).
In terms of volume, 10^8 IPv6 addresses per mm3 throughout the Earth.
Imagine a scenario where we have nano-bots to perform "repairs" in our bodies or whatever, and obviously each individual nano-bot use TCP over IPv6 because future software developers are also as lazy as us.
Instead of taking paracetamol, people take nano-bot-shots which include (presumably) millions (or even billions?) of nano-bots that we inject into our bodies. However, they disappear after a week (or some other more realistic timeline).
Now, how many people can use these on a monthly basis before we run out of IPv6 addresses?
Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever? This seems like an unlikely scenario, but I'll assume it's just an intellectual exercise and take a stab!
- Total number of /64 subnets available: 2^64
- Total number of humans in this future: Let's say 16 billion (roughly twice what we're at now)
To get the total number of months before we'd run out of /64 subnets, assuming each human is absorbing one every month, we divide the number of /64 subnets by the number of humans:
2^64 / 16 billion =~ 1,152,921,505
Divide by 12 to get the total number of years:
1,152,921,505 / 12 =~ 96,076,792
So by my math, assuming the human population stayed steady at 16 billion (which seems just as absurd as the initial premise) we'd have about 100 million years to figure out how to start reusing some of those old subnets before we started running into trouble.
> Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever?
No, I meant it as "You can reuse the subnet after 1 week + N" basically.
> it's just an intellectual exercise and take a stab!
Indeed it was, and thanks for conjuring a gratifying answer :)
I think this turns out to be a pretty good example of how stupidly big the ipv6 space is. Because it sounds like a big ask until it meets the numbers.
So you want "even billions(!!1!)" of nanobots per allocation. Well I'm lazy, and dynamically allocating a /64 is built right into the protocol. So lets let my medication dynamically allocate out of a /64. How many billions? Billions of billions. So lazy, so sorted.
But of course, I don't want my medication talking to my wife's medication. So lets de-conflict that. In fact, let's de-conflict everyone's medication.
We all know that 32bits is a bit over 4 billion. So 33 bits is going to be a bit over 8 billion. That's enough for now, but it's iffy, so let's go for 34bits, a bit over 16 billion. But in ipv6 world, it's polite to land on a nibble-boundary, so we'll go for 36 to be polite.
I'm going to steal the old allocation for ULA as an example. It was /7, but I'm going to call it /8 because I like round numbers.
So lets have an 8-bit prefix ala ULA. Then an 8bit planet number. Then an 8bit country/healthservice/issuingbody number. Then a 40bit human number, because I ran out of reasons to waste 8's There's our 64bit network number. With 64 bits left for billions of billions of nanobots to dynamically allocate.
The best bit about ipv6 isn't billions, it's that we get to actually structure our networks instead of cramming them into every nook and cranny we can buy.
IPv6 devotes a giant chunk of space to ephemeral link-local connections, if I recall correctly, at least a /64. So you'd need about 10^18 nanobots or so before you start to have to worry about link local address exhaustion.
These do not have to be globally unique, just unique on the local network.
Currently all public addresses are being assigned out of 2000::/3. The following are reserved for future (public?) use: 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3.
Everything that starts with "f" is a special case, so the vast (vast) majority of address space is cleaved off.
That sure sounds like a lot. But "billions" is less than a /64. Try "sextillions" (/56) or "septillions" (/48). Of course, when the denominator is "undecillions", it becomes clear that this is actually a non-issue.
>ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6. A reasonable sized /32 allocation [...]
The more one digs, the more egregious it seems. If the NETIFY webpage is accurate, it shows that Capital One already had "/32" and "/36" blocks, and yet they also got "/16" : https://www.netify.ai/resources/networks/capital-one
There doesn't seem to be any public transparency of the approval process to explain how a non-ISP company could justify a "/16" block so it just leaves everybody guessing.
It seems more likely to me that ARIN is following the text of published policy, but Capital One found a way to interpret it that violates its spirit. My guess is that they're treating each customer debit/credit card as a serving site that qualifies for a /48. To address this, ARIN should fix the policy, not raise fees.
It's ARIN's job to call BS on BS justifications, otherwise they're not following the policy, they're following whatever they allow. "The purpose of a system is what the system does" and all.
That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).
Too bad ARIN tickets aren't public - I would love to read the one in which that was justified. Reading NRPM 6.5.2.1, it seems that they must have submitted documentation claiming at least 2^28 distinct serving sites in order to qualify for an assignment that large.
I find the insistence of using /64s everywhere for networks frustrating. Any network larger than a /112 seems crazy, that's already 65k IPs per subnet. A /104 for every normal end user (256 subnets per user), or a /80 for massive companies like Capital One (4 billion subnets) should be more than enough.
There is a really practical reason behind this, and it is called "routers". Due to longest prefix match, you'll end up wasting resources on the networking hardware. And you waste both precious and expensive TCAM and LPM latency for matching the prefixes. So routers do optimize for anything shorter than /64, and have special lookup memory for /64 and /128. But nothing in-between.
thankfully I replied to a comment speaking about a tangent (/64s) and not to its parent. /s
Snark aside, very much agreed, and I don't like that they got away with it. It's precisely with the mindset of "we'll have enough" that companies like ford have a /8 or the DoD has more /8s that we can count. And with this mindset we'll run out of IPv6 the same we ran out of IPv4.
That's fair enough, in which case ipv6 is really only a /76 (having more than 1000 hosts on a subnet isn't a great thing, even with no broadcast and arp and other traffic, and /76 allows 4000 on a /64)
Those fanboys going "we'll never run out of 2^128 IPs" are being disingenuous when about 2^59 of them have been burnt straight away (I'd guess most subnets have less than 30 devices)
2^64 subnets is a reasonable number, but when they are handed out like candy that number dwindles quickly. ARIN is allocating the equivalent of a /15 every year. That's fine if it's a constant allocation, there's 100,000 years worth, but if that rate grows, the space will be eaten in a matter of a few decades.
It's not being burnt, there are two useful things we're doing with the 64-bit network size:
* Sparse networks. 64 bits is too big to feasibly do a brute force scan on, which reduces how often servers get exploited by random network attacks.
* SEND secures NDP by using those 64 bits for a public key
Reducing network sizes to 12 bits would destroy both advantages.
Having a ludicrously large address space is kinda the point of IPv6.
You're not ment to utilize every address assigned to you. Trying to do so will always lead you to situations where you messed up and need to renumerate.
The up to 42 deep hierarchy of routing levels built into IPv9 must
have been one of the key features for its wide deployment. [...]
As yet, no requirement has been found for levels 40-42, with level 39
still being used for experimental interrogation of atomic structure
of components where required.
So the funny thing is .. they didn't. They really didn't.
The original numbering plan for IP was that each network number became a /8. Which is how we miraculously ended up with 10/8, because network 10 was ARPANET itself, so 'flag day' left 10/8 vacant.
But back to the point at hand. IP itself is RFC 791, September 1981, nice and famous. The addition of classful networking because 255 network numbers wasn't going to last long, was RFC 790.
The first workaround for IP exhaustion was published before IP. It's been a Known Issue since day negative-one.
Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?
That subnet is large enough to then assign an IP address to every individual atom in that grain of sand.
For comparison, if we wanted to assign every living person on Earth a grain of sand, we would only need a few cubic feet of it (less than 1 cubic meter).
> Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?
As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.
And when IPv16 finally appears in the future, people will yet again make exactly the same argument.
> As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.
You're ignoring the sheer scale of this question. We don't have enough raw materials on this planet, or likely in the observable universe, to produce enough devices that would consume that many IPs.
We could colonize 1 billion planets.
Each of those planets could have 100 billion people.
Each of those 100 billion people could own 1 billion "things" that could be considered "networked devices".
Each of those "things" could consume 1 billion IPs.
We could have all that, and we would still have 70% of the IPv6 space left.
> The decision to put a 32-bit address space on there was the result of a year’s battle among a bunch of engineers who couldn’t make up their minds about 32, 128 or variable length. And after a year of fighting I said — I’m now at ARPA, I’m running the program, I’m paying for this stuff and using American tax dollars — and I wanted some progress because we didn’t know if this is going to work. So I said 32 bits, it is enough for an experiment, it is 4.3 billion terminations — even the defense department doesn’t need 4.3 billion of anything and it couldn’t afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we’d have an opportunity to do a production version of it. Well — [laughter] — it just escaped! — it got out and people started to use it and then it became a commercial thing.
One use case is private entities squatting on massive ranges that they have no hope of ever practically using, and thereby extorting other people and organizations as the rest of the address space gets massively over-allocated to other uses.
One of the features of IPv6 is address autoconfiguration, obviating the need for a central authority like DHCP on v4.
However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.
But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.
If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)
I don't understand why getting rid of DHCP is desirable. DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!). Checking "Does my interface have an IP address?" is also a really really useful and quick analogue for "is the gear related to the LAN pretty much working or is something broken/misconfigured?".
As it is, all my interfaces just have these random IPv6 addresses configured which don't work most of the time. I don't get it.
> I don't understand why getting rid of DHCP is desirable.
It's less infrastructure to run, especially with embedded networks.
> DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!).
You are limiting your thinking to macro-scale 'user-managed' devices, as opposed to things like embedded things:
FWIW; SLAAC works by setting the local part to the mac address.
So, if you have knowledge of your mac address (which is what you say you are using for DHCP) then you will know the fe80::<> IPv6 IP too, which, while not globally routable is probably what you want based on this comment.
It is not the host-component of IPv6 that determines routability, it is the prefix.
If you have a link-local prefix (fe80::/10) then it is not global, if it is a private prefix (fc00::/7) then it also may not be global; if it is part of IANA's unicast allocation (2000::/3) it is global (firewall permitting).
There's an education here that unfortunately I don't have the time to give you.
SLAAC is the replacement for DHCP, it provides a local prefix address (fe80::) and optionally (and, crucially: additionally) provides a publicly routable IP if there's a public prefix available.
You can think of the subject being split into two components:
I'm actually running dnsmasq from a FreeBSD host. How would dnsmasq know about the self-configured addresses? I guess I could run DHCPv6, but it's next to impossible to get any kind of prefix delegation going with my ISP anyway.
At the moment their router hands out the v6 addresses and I use v4 for dnsmasq.
They are fully compliant, SLAAC is part of the standard whereas DHCPv6 is an optional extra.
DHCPv6 also does not work without RA. DHCPv6 just assigns an address, a routable prefix, dns servers etc, it does not assign a subnet or any routes, you need route advertisements for that.
Seen like this, you can also argue that DHCP is an optional extra for IPv4, but it almost essential in most networks. Sure, IPv4 has no SLAAC that can be a valid alternative, but still, given that SLAAC doesn't solve every use case...
Published guidance says they're meant to give out at least a /56. I don't know that making autoallocation work on smaller subnets would help with this problem - ISPs that currently give out the smallest possible subnet would probably just switch to whatever the new smallest possible subnet was.
Some do give you one but in the most incorrect way possible. When I had fibre through Orange France, they properly allocated a /56 to my connection, but the ISP provided router only routed the first /64 from the block. The UI even proudly displayed the full /56 in all of its glory followed by a "xx/64 usable".
Oh and I ended up disabling IPv6 altogether as their router would crap itself with a modest amount of IPv6 traffic. Pulling ~10Mbps of IPv6 would completely DoS the router, as it would not even go as far as answering to ARP. Some quality hardware for sure.
CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn't really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.
Collisions are just as likely with the 48 bits as they are with the last 24 bits, as some OUI vendors reuse mac addresses.
Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.
On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested "Prefix Delegation" in which case they'd give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.
Shitty ISPs will always give you as little as they can get away with. If the software enforces /64, they'll you /64. Raise the limit to /128 and they'll give you /128.
At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.
This is the same as if you get a /24 from your ISP, but the ISP has the .1 address on their router. In this case, you can't (easily) subnet the v4 range either, since the ISP router expects to be able to arp for all the 254 ips, meaning you have to resort to trickery in order to make subnetting almost work.
Same goes for ipv6. If you get one single net (and a 'small' one at that), you once again have to resort to trickery to subnet at your end.
Preferably in both cases, you would get a small (/31 for v4, /127 for v6) transport net that goes to the ISP router or your first fw device, then the ISP routes the real net /24 (or whatever size you can get from it on v6) behind your IP on the /31,/127 so that your first device can split this in any way you prefer.
Not if you want SLAAC to work in each LAN. Basically in IPv6 each LAN is supposed to have a /64, that's the real minimum allocation by design. Per the official recommendations, ISPs are supposed to give every individual customer at a minimum a /56.
ISPs are SUPPOSED to allocate a /64 for a single customer. Mine does, so I have 4.5 billion available addresses within my 2001:4653:nnnn:nnnn::/64 prefix...
Billions of addresses might seem like a lot, but every IPv6 network has at least 2^64 addresses and it doesn't make much sense (to me) to give any customer less than one network.
(Maybe you meant billions of /64 blocks? ISPs could be providing a /32 ≈ 4 billion /64 blocks, though there still are 2 billion of those in the entire IPv6 space)
The space currently assigned to globally routable addresses is 1/8th of the v6 address space. Over 50% of the addressable space is currently reserved.
The numbers are frankly mind-bending. Even if we we make a complete pigs ear of assigning billions of IPs to billions of networks in the current /3, we have space for more than one do-over.
But I do believe there's a higher chance the next /3 will be assigned to Mars.
I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.
And the IPv8 would be 0.0.0.0.1.2.3.4 whenever we need it, but probably not for a long time
When I saw all the double-colons and slashes and monstrosities like f00f:00f:::ea//dead::beef/3 I just kept using IPv4.
I can't even remember Google's IPv6 DNS ffs. 8.8.8.8 was easy to remember. Now it's got some hex bullshit in it and a double colon thrown in somewhere.
Exactly this misconception comes up (often multiple times) every time there’s a discussion about IPv6 on HN.
No, it’s not possible without running into the exact same problems that we had with IPv6 (which actually has various compatibility mechanisms, to the point where now some mobile networks are IPv6 only but still work to let people access IPv4).
The problem with your proposal is the same issue we have now - something that only talks the old protocol can’t possibly talk to something in the new protocol (without the same kind of hacks we use with IPv6 like NAT64/464XLAT), since IP addresses in headers are fixed sized. Which also means that any router in the middle can’t possibly route packets to networks with the expanded addresses. So we have the exact same issue - everything needs to be upgraded to deal with your new scheme, but unless that all happens on the one same day, you need to be able to deal with the old addresses. So you need dual stack, just like with IPv6 until everything is transitioned.
So basically all you’d have with this kind of proposal is exactly the same problems, but it would be more confusing why older devices can’t talk to the newer devices since the addresses would look very similar!
3. An alternative form that is sometimes more convenient when dealing
with a mixed environment of IPv4 and IPv6 nodes is
x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
the six high-order 16-bit pieces of the address, and the 'd's are
the decimal values of the four low-order 8-bit pieces of the
address (standard IPv4 representation). Examples:
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
or in compressed form:
::13.1.68.3
::FFFF:129.144.52.38
So in addition to having the addresses embedded on binary level, you even have that text notation that uses traditional ipv4 dot-notation!
You might ask why they are not more prevalent, but then you will find the practical issues that various transition mechanisms are attempting to solve.
IPv4 isn't a text based protocol where IP addresses are parsed like DNS. It's a binary protocol where addresses are recorded in binary and adding more address space WOULD BE A BREAKING CHANGE.
For a practical demonstration: That's the reason decimal IPs work, too - i.e. http://3520653007/ is the same as http://209.216.230.207/ (and both will go to HN) - it's all just nice formating for our human brains.
Nothing would stop us from formatting IPv6 the IPv4 way except the monstrous length of the resulting address.
Wow learned something new today. What's interesting is that the decimal representation looks more like a phone number which people would be used to. Interesting that IP addresses as they are written today was the format that won, as a kid before learning how computers worked I always found it weird how 255 was the highest number in each group.
Its often challenging enough for people to do CIDR subnet calculations in their head when its broken out into octets. I'd have just given up on networking entirely if the standard was to use decimal notation.
Not at all. We could have taken one of the unassigned /8's at the time and allocated it to v6 transitional addressing (the failure to address 4->6 reachability is IMO why v6 failed). For the sake of this example lets use 53.0.0.0/8. All new addresses start with 00110101 followed by the first three bytes of the new v6 prefix. The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.
Now your border router can announce your assigned transitional prefix, i.e. 53.32.122.91/32, and is responsible for routing packets to a NAT gateway that knows both v4 and v6 and rewrites packets seamlessly each way.
What we are left with is a scheme that allows v6 to exist on top of v4 and continue working across the existing internet, and the only people who need to worry about it or upgrade anything are the ones who need more address space.
But instead they followed the model of baking in every stakeholders random pet project into v6 to get consensus in the hopes of forcing adoption. They put letters in the middle of numbers, and expected us to not hate it like algebra.
If you prefer, you could write an IPv6 address in dotted-decimal notation just like an IPv4 address, or an IPv4 in hexadecimal notation like an IPv6 address. It's just 128 (IPv6) or 32 (IPv4) bits of data after all, the representation is completely independent of the protocol.
> The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.
Your proposal, as usual for these kinds of proposals, fails to consider how would an "old world" endpoint talk to a "new world" endpoint. An "old world" endpoint wouldn't know about these "additional 5 bytes", and would both send packets without them to "new world" endpoints (confusing them) and treat them as data bytes when receiving from "new world" endpoints. The only solution would be to upgrade all the computers on the "old world" first, but once you have to do that you could move them all to the "new world" instead.
If what you want is just the addressing (for instance, you already have 192.0.2.1, and want to use it for IPv6 without needing to obtain an IPv6 address first), there's already 6to4, which has most of the properties you want: it exists on top of IPv4, your router announces the IPv4 prefix, and IPv6 packets sent to it are transparently routed to a relay router which encapsulates them inside IPv4 packets destined to that IPv4 address (in the other direction, your encapsulated packets are sent to a relay router which extracts the IPv6 packet and forwards it). I've used this in the past to give full IPv6 connectivity to a site which had only a single IPv4 address, and it worked well.
I address that. Old hosts and networks only know about the first part of the address and the rest of the address resides in the data section so a new application can run on an old host even. When you cross from an old to a new network, the router can hand packets to a side box that runs CGNAT. This allows for new hosts and networks to talk to old without having to include their full address in the data payload.
Think of it like the mail service. For the majority of the journey your letter is only routed based on the first 3 digits of the zip code. When it reaches the last mile sorting facilities is when the full address becomes relevant.
Your scheme already exists, although instead of using the first octet of the IP address it uses a 41 in the protocol field, so it doesn't need to eat an entire /8. Routers can see the 41 as a flag and then read the v6 address from the beginning of the packet payload.
You haven't managed to suggest anything that v6 doesn't already do, or anything that would solve any of the problems v6 has when doing it. I'm not sure you even noticed the problems, yet you think you can throw stones at the v6 people, who not only noticed the problems but had to solve them too?
Throw that packet at a non-v6 router and let me know what happens. v6 could have been an overlay extension to solve the address space issue without the migration complexities.
We are now 26 years in and v6 has only gotten serious adoption because mobile carriers came along too late in the game to get enough number resources.
Of course IPv4 devices wouldn't be able to use IPv6 addresses, that would be impossible. But it is possible to "keep" IPv4 addresses, just make a.b.c.d to correspond 0.0.a.b.c.d.
First of all, the 4 in IPv4 has nothing to do with its addresses typically being represented in dotted 4-octett notation. That's a coincidence. Each address is a 32 bit number, that's it. Early versions of IPv4 as well as some of the experimental IPv3 drafts actually used 128 bits. In IPv6 there are 128 bits for each address. Nothing to do with 6, which is just a version number.
Second, IPv6 is not just about addressing, it's a new protocol. Many things are different in IPv6, lots make much more sense. The header structure is different. Etc etc. The address space and notation are just the most visible aspects. But it's like comparing IRC and Signal. It's not just about user names, it's a different protocol.
Third, there are embeddings of the IPv4 address space into the IPv6 address space. For example ::ffff:192.0.2.128. Note the mix in notation. This is a valid IPv6 address! Perhaps a bit more cumbersome to write than your suggestion, but for technical reasons it was preferred to keep things syntactically unambiguous (that it's an IPv6 address).
Source: I work at a large router vendor, in the routing team.
Also, none of this is secret. Just read the Wikipedia page. I'm slightly shocked how a tech forum supposedly full of hackers is posting so much half truths and plain wrong information. It's all easily available and understandable, and it's not like we're discussing neurosurgery or epidemiology where we're all amateurs.
You and Plasmoid completely misunderstood dheera and me. I failed to clarify this misunderstanding explicitly (I still don't see where does it come from), so I do it now.
> I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.
As you can see, dheera did not state that IPv4 or IPv6 work with strings. They just said that they wished/expected the trivial extension of the IPv4 protocol, with the same notation, and preserving the existing IPv4 addresses. (These are 2 distinct wishes.) Acknowledging that this did not happen.
Nor dheera nor me posted any half truth or plain wrong information.
It wouldn't be trivial in practice. You'd still end up needing to replace everything in between. And if you're going to replace everything in between, you might as well upgrade it to something much larger instead of taking little half steps that will need to be repeated again and again.
> preserving the existing IPv4 addresses
But it wouldn't really in the end. 0.0.1.2.3.4 is still a different address than 1.2.3.4. You'd still end up needing to translate 0.0.1.2.3.4 to 1.2.3.4, aka a 6to4 tunnel. So, you're in the same place in the end as where we are with the current IPv6, just with only a baby step in changes that will probably need to be upgraded again in the future.
How many people managing networks who knew their ip addresses by heart and typed it regularly for all kind of tasks were put off by the new format and decided, consciously or not, to wait until "I really have to deal with it"?
Some people get really angry when you point that out ;)
Good thing for IPv6 it didn't really have any competitor (except IPv4).
2a09:: 2a11:: and 2409:: are even shorter than 8.8.8.8, though not quite as memorable.
I'm not recommending those DNS servers, just highlighting that "vanity" IPv6 addresses exist now. It's possible that 2222:: or 3333:: could be allocated someday.
Technically it's just 128 bits, it doesn't matter how you represent it. I've written this IPv4ES solution, which allows you to use 128 bit addresses using IPv4 format.
Huh? IPv6 does have backwards-compatible-ish notation for writing IPv4 addresses. To take your example: 1.2.3.4 would be ::ffff:1.2.3.4, the 96-bit prefix indicated by ::ffff: is where all of the IPv4 addresses live in the larger IPv6 space.
If your issue is with the use of colons at all, they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.
Usually IPv6 addresses are enclosed in square brackets when a port number is involved. But it's true that in many configuration files IPv6s are a nightmare to put in, especially because you never remember what syntax you have to use: sometimes you even have to duplicate semicolons (that's what Exim does...). But I think this is rather a convention problem for the config files, rather a problem of IPv6 addresses themselves.
The IPv6 people must have known that : was a common way to separate IPv4 and port numbers. IPv6 was standardized 4 years after the URL format which used a colon to denote a port number.
