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