At the IP level, packets are stateless. This means that there is no such thing as a “unidirectional” flow of packets.
Virtually every useful flow of packets in one direction requires a relatively symmetrical flow of packets in the other direction. Thus, even if you can “increase the size of the source address at transition” in one direction, this utterly ignores the requirement that this process must be reversible to send replies. Owen > On Mar 21, 2022, at 00:45, Vasilenko Eduard via NANOG <nanog@nanog.org> wrote: > > 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.
