Maybe having multiple streams within a single connection, like QUIC does, would have been a better choice. Also being able to demarcate message boundaries within the protocol itself, perhaps, instead of it being a simple byte stream.
1. It would have 128-bit addresses. 2. It would have end-to-end encryption (or was it authentication, I forget).
IPv6 was supposed to fix both of these, with IPsec mandatory, but the latter demand sort of faded out into obscurity. We ended up basically solving encryption by pushing everything into TLS anyway, which I guess solved much of the same problems although at a very different layer.
I always wonder if the internet is thesurvivor of the networking cambrian explosion, with a slight roll of the dice making another candidate the winner.
Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.
Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4?
Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8.
IPv8 solves precisely zero of the problems that is causing a 'slow' roll out of IPv6 / replacement of IPv4:
"""
So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
You have to change the version number.
You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
[…]
Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events.
"""
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...
* Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s
I'm always fascinated by how many people think IPv6 adoption would have gone lightning-fast if we just used This One Weird Trick, where said trick has actually been tried and didn't help. They usually refuse to back down even after you tell them so.
6to4 is exactly ownership:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
The relaying is a necessity:
OLD DUAL NEW
----------------------
OLD | 32 | 32 | XX |
|------|------|------|
DUAL | 32 | 64 | 64 |
|------|------|------|
NEW | XX | 64 | 64 |
----------------------
There's no way around it: a non-IPng-having node will have to go through a translation box of some kind.
Yes. Note that it doesn't need to be someone else's relay; anyone with IPv4 connectivity could easily route 2002::/16 into IPv4-land (without having to announce it in BGP for others to use). You could even announce 2002:aabb:ccdd::/48 as a more-specific in BGP if you wanted, although this was more exotic.
::ffff:1.2.3.4
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
By having 1.2.3.4 you also got 2002:1.2.3.4::/48 'for free' (per 6to4). So if you want to send things to 1.2.3.4 / ::ffff:1.2.3.4, you tell your router that it's available via 2002:1.2.3.4::/48.
Any idea that you think is clever and to 'just' do X and/or Y for IPng, and would work, has probably already been thought of and attempted in the last 20-30.
There's no one clever trick to make the transition easy, the idea is to preserve the v4 address blocks in v6. That cascades down to a bunch of different decisions, some of which include keeping NAT around. They've most likely thought of that too, and turned it down because they wanted to start with a clean slate and maybe also had some other vision of pure P2P apps.
Sure they could: if your ISP owns 1.2.0.0/16, it could advertise 2002:1.2::/24 via BGP. So if someone on the other side of the planet wants to send something to 2002:1.2.3.4::/48 they would know where to send it.
And just like how something sent to 1.2.0.0/16 globally is then handled internally via IS-IS/OSPF/etc so your ISP knows how to send something for 1.2.3.4 to your CPE, your ISP would know how to handle 2002:1.2.3.4::/48 to get it to your CPE.
Routers are told to map traffic for (::ffff:)a.b.c.d to 2002:a.b.c.d::/48. If you're sending from w.x.y.z, you can put the source address as from something in 2002:w.x.y.z::/48.
It has nothing to do with "clean slate" or not. There are two immovable facts:
"""
IPv4 implementations, in 1994 and still today, have the 32-bit address format built into their code. Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
1. You have to change the version number.
2. You have to add new code to handle the new version.
""
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...
And this also includes 'accessory protocols': DNS A records are fixed at 32-bits, so if you want to use hostname with IPng you needed to upgrade the DNS infrastructure, including APIs to say "give me A and Ang", and then you perhaps need fallback mechanisms, in which case you're at:
* https://en.wikipedia.org/wiki/Happy_Eyeballs
Any IPng protocol, including 'just' adding bits, regardless of how you want to hand wave it as being 'just' an extension of IPv4 will be in same situation because you can't fit >32-bits in the 32-bits of the original code. You're rolling out new code in a rolling fashion, just like had to be done with IPv6.
I understand the limitation that you can never put a 128-bit address in a 32-bit field, and one way or another two hosts and everything in between have to understand the new packet format. That didn't force them to make ipv6 its whole separate network from v4 where almost no state is shared with v4. Having separate DHCP6 vs DHCP4 was a choice, likewise with DNS, NAT, and even the routing tables. It makes the difference for service operators who would be fine adopting ipv6 but don't want it to be a big project.
Anyone can publish an IETF draft document, it doesn't mean it's a serious proposal under consideration or will ever actually be implemented.
You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.
We're slowly reinventing OSI, one step at a time: OSI had multiple sessions per transport connection (QUIC), 20 byte addresses (IPv6) and a directory system with public-key infrastructure (DANE, vCard, SSHFP, etc).
It's a shame TUBA (CLNP + TCP) failed.
See "The Recommendation for the IP Next Generation Protocol", §8.3 TUBA Reviews:
* https://datatracker.ietf.org/doc/html/rfc1752
The document explains why SIPP was chosen (with the tweak of 128-bit addresses instead of 64).
The "solving" of encryption with TLS should not be celebrated.
Everything needs to go over TLS/HTTP-443 because of middleware boxes basically blocking everything else by default in many cases, and so application/protocol designs have to shoehorn / kludge everything into a round hole even if it's a square peg.
Certainly I'd want everything to have encryption at the higher layers (OSI 5-7), but having opportunistic encryption at IP (OSI 3) would also be great because snoopers could tell that two nodes are communicating but not how / what: RTSP? Torrent? Mindcraft? PvP2 game? If every node could (say) do an IKEv2 negotiation with every other node have IP-level traffic wrapped in IPsec that would help with traffic analysis.
This thinking can be seen in the allocation of network blocks. Mercedes Benz getting 53.0.0.0/8 is just a "we have more addresses than we ever need."
If somebody had imagined "yeah, let's give an address to each of our vehicles" they would have realized the space running out.
In a sense, he did. Take a look at RFC 4838.