[zinekeller]

> This gets repeated over and over, but the issue is that it's an impossible task.

The counterpoint gets repeated and repeated all over, because it was already done in BGP.

Unfortunately, most are purists who will never look at using TUBA (https://datatracker.ietf.org/doc/html/rfc1347) or something because they want "clean code" or something.

Real world is messy, and code should adopt over it.

[throw0101a]

> TUBA

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.

Which is basically describing AAAA records.

---

* https://news.ycombinator.com/item?id=28326806#unv_28328593

[welterde]

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.

[kazen44]

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.

[nybble41]

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.