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.
