V6 still not supported

Sun Mar 20 04:24:30 UTC 2022

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 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, 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 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.