RE: V6 still not supported

[Vasilenko Eduard via NANOG <nanog () nanog org>]

Hi all,
Hierarchical addressing when the small zone has a smaller address size, but the bigger zone has a bigger address size
Does not make too much sense.
Indeed, it is possible to increase the source address from 32bits to something bigger when the packet would go out of 
the small zone (and decrease when the packet would go in the reverse direction).
But it is not possible to do the same for the destination address - it should be long enough (more the 32bits) from the 
source host to point to another host far away.

Hence, the assumption below is optimistic that may be smooth interoperability between smaller and bigger address spaces.
It is the same disruptive as the introduction of IPv6.
Eduard
-----Original Message-----
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com () nanog org] On Behalf Of Mark Delany
Sent: Sunday, March 20, 2022 7:25 AM
To: nanog () nanog org
Subject: Re: V6 still not supported

On 19Mar22, Matt Hoppes allegedly wrote:

> So, while it's true that a 192.168.0.1 computer couldn't connect to a
> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch 
> would be very simple and quick to deploy

Let's call this ipv4++

Question: How does 192.168.0.1 learn about 43.23.0.0.12.168.0.1? Is that a DNS lookup?

How does the DNS support ipv4++ addresses? Is that some extension to the A RR? It better be an extension that doesn't 
break packet validation rules embeded in most DNS libraries and middleware. You give 'em an A RData longer than 32 bits 
and they're going to drop it with prejudice. Perhaps you should invent a new ipv4++ address RR to avoid some of these 
issues?

In either case, how does every program on my ipv4 computer deal with these new addresses that come back from a DNS 
lookup? Do you intend to modify every DNS library to hide these extensions from older programs? How do you do that 
exactly? What about my home-grown DNS library? Who patches that?

Here's a code fragment from my ipv4-only web browser:

       uint32 ip
       ip = dnslookup("www.rivervalleyinternet.net", TypeA)
       socket = connect(ip)

What does 'ip' contain if www.rivervalleyinternet.net is ipv4++ compliant and advertises 43.23.0.0.199.34.228.100? Do 
these magical concentrators sniff out DNS queries and do some form of translation? How does that work with DoH and DoT?

Or are you suggesting that www.rivervalleyinternet.net continues to advertise and listen on both 
43.23.0.0.199.34.228.100 *and* good ol' 199.34.228.100 until virtually every client and network on the planet 
transitions to ipv4++? In short, the transition plan is to have www.rivervalleyinternet.net run dual-stacked for many 
years to come. Yes?

Speaking of DNS lookups. If my ipv4++ DNS server is on the same LAN as my laptop, how do I talk to it? You can't ARP 
for ipv4++ addresses, so you'll have to invent a new ARP protocol type or a new LAN protocol. Is that in your patch 
too? Make sure the patch applies to network devices running proxy ARP as well, ok?

If I connect to an ipv4++ network, how do I acquire my ipv4++ address?  If it's DHCP, doesn't that require an extension 
to the DHCP protocol to support the larger ipv4++ addresses?  So DHCP protocol extensions and changes to all DHCP 
servers and clients are part of the patch too, right? Or perhaps you plan to invent a new DHCP packet which better 
accomodates all of the ipv4++ addresses that can get returned? Still plenty of code changes.

And how do I even do DHCP? Does ipv4++ support broadcast in the same way as ipv4? What of DHCP relays? They will need 
to be upgraded I presume.


So let's say we've solved all the issues with getting on a network, talking over a LAN, acquiring an ipv4++ address, 
finding our ipv4++ capable router and resolving ipv4++ addresses. My application is ready to send an ipv4++ packet to a 
remote destionation.

But what does an ipv4++ packet look like on the wire? Is it an ipv4 packet with bigger address fields?  An ipv4 packet 
with an extension? Or do you propose inventing a new IP type? Do these packets pass thru ipv4-only routers untainted or 
must they be "concentrated" beforehand?  Won't all the firewalls and router vendors need to change their products to 
allow such packets to pass? Normally oddball ipv4 packets are dropped of course. As we know, vendor changes can 
notoriously take decades; just ask the ipv6 crowd.

Ok. We've upgraded all our infrastructure to route ipv4++ packets. The packet reached the edge of our network. But how 
does the edge know that the next hop (our ISP) supports
ipv4++ packets?  Do routers have to exchange capabilities with each 
ipv4++ other? How do they do
that?

For that matter, how does my application know that the whole path thru to the destination supports ipv4++? It only 
needs one transition across an ipv4-only network somewhere in the path and the packet will be dropped. I think you're 
going to have to advertise ipv4++ reachability on a per-network basis. Perhaps using BGP? Oh, so that means your patch 
has to add ipv4++ capabilities to all BGP implementations. Hmm.


> However, to get back 192.168.0.1 can proxy through an IPv4.1 to IPv4.2 concentration system.

Sounds like you're proposing a global deployment of reverse CG-NATs (aka concentrators) which need to run for as long 
as the transition takes. Do you run concentrators on ISP borders where one party is ipv4 and the other party is ipv4++? 
Not sure a lot of edge/border routers have the memory footprint or CPU grunt to maintain NAT tables that might involve 
1,000s or millions of flows. Your patch might have to include a memory upgrade. Will these address ranges fit into 
32bit CAM or will routers need to drop back to regular memory and software lookups? That's a pretty nasty performance 
hit which was an argument against ipv6 for quite a while.

One of the bigger problems with your "concentrators" (apart from who implements them and
where) is that they mask the address of all incoming connections originating from ipv4++ sources. Lots and lots of 
products and tools rely on source addresses to uniquely identify friend or foe: VPNs, iptable filters, Rate-limiters, 
Antispam systems, etc. Can you give an example of how 43.23.0.0.12.168.0.1 collapsed down to an ipv4 address and still 
allows an ipv4 recipient to uniquely identify the true source? I'm going to suggest it's not possible. These 
concentrators effectively create false-identification risk for ipv4++ early adopters just as CG-NATs do for clients.

You might need to have a think about a global deployment of concentrators.


On another front. What of all the IP addresses stored on disk? Every s/w product, program and database which parses or 
manages IP addresses needs to change to support
ipv4++. IPAMs, dhcp configs, access control lists, DNS config parsers, 
ipv4++RBL lookups,
anti-spam filters, firewall rules, almost all of the 1,000s upon 1,000s of network applications, the myriad private 
databases, geo-location lookup tools, reporting tools and much more besides. This is a shedload of work.

And what of those systems which rely on the address space fitting in memory? I'm embarrassed to say I was involved with 
one of those in this century - blush. 32bits is tractable on current computers, but 64 bits for ipv4++, not so much. 
Such applications need a ground-up redesign to cope with the larger addresses.


You might argue that tooling and source address management can come later, but it can't. You need at least dhcp, dns, 
arp, concentrators, router "patches", switch "patches", bgp support, application code changes and inbound protection 
mechanisms in place before a single production ipv4++ packet can be exchanged. And any decent ISP is going to want far 
more than those basics in place prior to carrying ipv4++ packets on behalf of their customers: address management, 
diagnostic tools, training, portals, billing systems, etc.


All in all, this doesn't sounds "simple and quick to deploy". Rather, one could argue that
ipv4++ effectively recreated much of the work required to get ipv6 
ipv4++ running with added
complexity in the form of "concentrations" and address masking. And the reason for the similarity is simple: it's the 
address size increase which creates much of the work. Whether these larger addresses are stashed in minimally augmented 
ipv4 containers or brand new ipv6 containers is secondary. The whole planet spent decades writing code, designing data 
structures and building h/w which fundamentally relies on addresses being 32bits long. Add a single bit to that in any 
way and you pretty much break everything.


But here's the real problem with ipv4++. It's a technical solution to an incentive problem.

If good ol' ipv4 runs just fine while the internet transitions to your brand new ipv4++, what incentive is there for 
*any* of the ipv4 crowd to ever upgrade? Won't you end up in exactly the same situation we have today with ipv6? Not 
enough incentive to adopt?

You need a rock solid incentive which more or less compells everyone to move to ipv4++ in a timely manner. You also 
need to show how that incentive can't be applied to ipv6. Solve both of these and you might be on to something.


Mark.