I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that.
Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that.
Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6.
After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).
> I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that.
We need more addresses. That's the primary problem of IPv4 right now.
So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?
AFAICT, code updates will needed to occur on every device that needs to talk to the new address scheme. So what's the difference between updating every device to handle IPv6 versus updating every device to handle this hypothetical IPv7?
> So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?
IETF also asked that for AS numbers (which were only ~60,000 originally!) Sure enough, there were some reserved bits actually on the spec, which they used to add an extended address. Nowadays, the original BGP actually operates on a single number: AS23456 and the actual AS number is on that reserved spot.
> The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses.
[…]
In §3 Migration:
> Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.
So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses.
How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing?
In §6 on DNS:
> TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses.
IPv6 format is just too damn confusing and mental overhead.
Prefixing all IPv4 with 0.0, opens up another 64k copies of the 4 billion address space of a.b.c.d. This would have been far easier for everyone (not just a few admins, but everyone that ever has to deal with an IP address) - to understand and deal with. It still could be, with the aforementioned-yet-not-developed-nor-propsed IPv7.
Sorry, that is a misinformed view. Your proposal has exactly the same problem IPv6 has - all network hardware knows the format of an IPv4 header, and you can’t fit larger addresses in it without changing all network hardware and software. So large swathes of the internet would be inaccessible until all those routers, firewalls, middle boxes, cell towers, etc. are replaced, which would take another 20 years! Whereas it’s mostly been done for IPv6.
This gets repeated over and over, but the issue is that it's an impossible task.
A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host.
The issue is simply that you cannot fit more than 32bit of information into 32bit.
There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.).
And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.
First - we already have extended the IPv4 address space by using + PORT in many cases (ie, running through CGNAT). So if I want to talk to another IPv4 host, we focus on IPv4+PORT, and the CGNAT's translate that to private IPv4 addresses on their local networks.
Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates. The basic approach was a simpler ipv6 that didn't change all the concepts around with an ipv4 range embeded in it.
Routing then just proceeded as normal, but if an IPv6 host was trying to talk to an IPv4 host, if the next step in route was IPv4, then router drops the extra IPv6 bits (would likely have been hop before server).
Conversely, when IPv4 host is talking to an IPv6 only host, they are routing back, and then when the next link in route is IPv6 only you rehydrate the IPv4 address with the IPv6 IPv4 prefix. The IPv4 network is talking to you using IPv4+PORT. The Port is basically how we get extra address space ALREADY with IPv4 and CGNAT (but to allow transition now you map that inbound IPv4+PORT to an IPv6 address. Being smart you can actually do a predictable mapping here if you wanted).
Other little tweaks make this better - but the key is that I as an end user can go IPv6 only on my network (ideally in a more IPv4 style without the complexity).
Anyways, some networks are already converging / heading this way with things like X64LAT or whatever - allowing devices to basically see an IPv6 only world. But you are still dragging along this insane IPv6 complexity
You're essentially describing NAT64, a thing which exists in v6 already. I use it on my desktop, which has no v4 address. You're arguing for something we already have.
v6 isn't really very complex. In fact it's generally simpler than v4, especially when you run out of v4 address space and NAT gets involved.
> First - we already have extended the IPv4 address space by using + PORT in many cases (ie, running through CGNAT). So if I want to talk to another IPv4 host, we focus on IPv4+PORT, and the CGNAT's translate that to private IPv4 addresses on their local networks.
So how does a VPS / cloud provider use the +PORT to give themselves and their customers more publicly-available addresses to assign to virtual machines?
> Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates.
This was brought up in another part of the thread. I'm copy-pasting my reply:
---
From the RFC (emphasis added):
> The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses.
[…]
In §3 Migration:
> Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.
So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses.
How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing?
In §6 on DNS:
> TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses.
In case of BGP it was possible since it's not a end to end communication protocol.
How exactly does TUBA solve the problem where ipv4-only host wants to communicate with a non-ipv4 host?
This proposal solves none of the issues we are facing of IPv6.
The RFC suggests some of the transitional technologies that are in issue with IPv6 today/the past: tunneling IPv6 over IPv4 (6in4, teredo, etc.), dualstack, NAT64 and other mapping, AAAA recrods in dns.
But it doesn't get around the fact that you cannot fit more than 32bit of information into a 32bit address.
also, in the case of BGP it is also possible because it is a protocol with a strict process around its use in the default free zone with a community of peers who all benefit from being interconnected and being able to exchange routes.
it is far easier to convince a couple of thousand organizations to modify their highly specialized infrastructure compared to end users and manufacturers who just want to use or create widgets which will do what is required.
RFC1347 (TUBA) is architecturally not very different from a Dual Stack IPv6 setup with 6rd and IPv4 (CG)NAT, except that you're stuck with the fragmented IPv4 routing table forever since the extended (CLNP) packets are routed over the original IPv4 network. And of course it's missing various other improvements made in IPv6 such as the higher baseline MTU of 1280 bytes (vs. the IPv4 baseline MTU of 576 bytes minus the CLNP headers), the removal of in-route IP fragmentation, the streamlined IP header, etc. Implementing TUBA would still requirement changes to all existing network applications and many protocols to work with extended addresses, so you might as well just add IPv6 support instead.
This exists for IPv6 and would need to exist for any alternative proposal.
And there are certain deployments of this in action, where hosts only have IPv6 and they only receive IPv4 connectivity via NAT mapping at the edge.
One issue with it is however that it doesn't address the address exhaustion issue since you would still need one IPv4 address for each IPv6 address you want to map to.
I think folks are trying to break apple's stranglehold / monopoly so that other app stores can be offered on iOS. This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements.
> This should help address these types of issues so more devs can get onto iOS more easily without having to meet Apple's level of requirements.
Well if an app developer does not ensure that their code works on a device that only has an IPv6 address they will be in for a big surprise: lots of mobile telcos only give out IPv6 addresses.
Connecting to the IPv4 world is done via CG-NAT with the first few hops being IPv6-only.
Realistically, such a new protocol will only make it worse. No doubt that new problem will lack some features that IPv6 has and that are in active use. So some group will refuse to move to the new protocol.
Some group will not move at all. IPv4 is fine for them.
And the rest of the world will get an endless amount of translation between IPv4 and the new protocol that is a nightmare to debug.
There is also the big question whether there actually exists a better transition path. I have not seen any ideas that are likely to be accepted on a large scale by the networking community.
Nope, you don't need to, because of a simple fact that there is a very minuscule amount of IPv6-reliant systems in the wild. Most of them also operate in IPv4 (because IPv4 is more prevalent).
Not really, since IPv6 adoption is low, a service that doesn't also exist on IPv4 practically does not exist, so if you have a good migration path (unlike v6) from v4, you're taking approximately all services with you.
Comcast's entire core network is pure IPv6. Every cable box, cable modem, everything is connected and managed using IPv6 addressing.
None of it is IPv4.
T-Mobile's core network is entirely IPv6, IPv4 lives on the edge only.
Facebook's entire internal network is IPv6, they have IPv4 edges that translate to IPv6 internally so that it is routed as if it were IPv6 and all services see IPv6 only.
Sorry, but your "adoption is low" is very VERY wrong and IPv6 has already solved a lot of problems, for example the "we are out RFC1918 space, and adding more NAT is not the solution".
That last part is literally why Comcast moved to an IPv6 core.
Mobile networks, for example, have huge deployments of IPv6. Whether or not they are used to access IPv6-only services doesn’t change the fact that IPv6 is an integral part of their network design and therefore an alternative to IPv6 would need a migration pathway from it.
This is what Python 3 did. Python 3.0 removed a lot of Python 2 features which were then progressively re-added in 3.1, 3.2, and 3.3. No matter how good your design, you need people using something else to actually want to make the move.
Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that.
Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6.
After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).