Christopher Morrow <morrowc.lists@gmail.com> wrote:
Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf!
I'm sure he would:) Though I can't claim a credit for the idea... it's way too old, so old, in fact, that many people have forgotten all about it. Mark Andrews <marka@isc.org> wrote:
This has been thought of before, discussed and rejected.
Of course, it was Discussed and Rejected. I fall to my knees and beg the forgiveness from those On High who bless us with Their Infinite Wisdom and Foresight. How could I presume to challenge Their Divine Providence? Mea culpa, mea maxima culpa. ...well, kind of. What you don't mention is that it was thought to be ugly and rejected solely on the aesthetic grounds. Which is somewhat different from being rejected because it cannot work. Now, I'd be first to admit that using LSRR as a substitute for straightforward address extension is ugly. But so is iBGP, CIDR/route aggregation, running interior routing over CLNS, and (God forbid, for it is ugly as hell) NAT. Think of it, dual stack is even uglier. At least, with LSRR-based approach you can still talk to legacy hosts without building completely new and indefinitely maintaining a parallel legacy routing infrastructure. Scott W Brim <scott.brim@gmail.com> wrote:
There are a number of reasons why you want IP addresses to be globally unique, even if they are not globally routed.
And do you have it now? The last time I checked, NAT was all over the place. Ergo - global address uniqueness (if defined as having unique interface address labels) is not necessary for practical data networking. In fact, looking at two or more steps in the source route taken together as a single address gives you exactly what you want - the global uniqueness, as long as you take care to alternate disjoint address spaces along the path and designate one of these spaces (the existing publicly routeable space) as the root from which addressing starts. Bill Manning <bmanning@vacation.karoshi.com> wrote:
just a bit of renumbering...
Ah, that's nice, but I don't propose expanding use of NAT. Or renumbering on massive scale. In fact I want to remind that NAT was never a necessity. It's a temporary fix which gave IPv4 a lot of extra mileage and became popular precisely because it didn't break networking too much while allowing folks to keep using the existing stuff. The real problem with NAT is called "P2P" (and I think it will become important enough to become the death of NAT). Jima <nanog@jima.tk> wrote:
This seems like either truly bizarre trolling,
I guess you haven't been around NANOG (and networking) too long, or you'd be careful to call me a troll:) What I want is to remind people that with a little bit of lateral thinking we can get a lot more mileage out of the good old IPv4. Its death was predicted many times already. (Let me remember... there was that congestion collapse, then it was the routing table overwhelming the IGPs, and then there was that shortage of class Bs and routing tables outgrowing RAM in ciscos, and then there was a heated battle over IP address ownership, and there was the Big Deal about n^2 growth of iBGP mesh). I don't remember what was the deal with Bob Metcalfe and his (presumably eaten) hat. Something about Moore's Law?
or the misguided idea of someone who's way too invested in IPv4 and hasn't made any necessary plans or steps to implement IPv6.
"Too invested in IPv4"? Like, the Internet and everybody on it? You know, I left the networking soapbox years ago, and I couldn't care less about the religious wars regarding the best ways to shoot themselves in the foot. The reason why I moved to different pastures was sheer boredom. The last interesting development in the networking technology was when some guy figured out that you can shuffle IP packets around faster than you can convert a lambda from photons to electrons - and thus has shown that there's no technological limitation to the bandwidth of Internet backbones.
you'd have to overhaul software on many, many computers, routers, and other devices. (Wait, why does this sound familiar?)
You probably missed the whole point - which is that unlike dual-stack solution using LSRR leverages existing, installed, and paid for, infrastructure.
too bad we don't have a plan that could be put into action sooner
The cynical old codgers like yours truly have predicted that the whole IPv6 saga would come precisely to that - when it was beginning. The reason for that is called the Second System Effect of which IPv6 is a classical example. A truly workable and clean solution back then would be to simply add more bits to IPv4 addresses (that's what options are for). Alas, a lot of people thought that it would be very neat to replace the whole piston engine with a turbine powerplant instead of limiting themselves to changing spark plugs and continuing on the way to the real job (namely, making moving bits from place A to place B as cheap and fast as possible). Now, we don't have a problem of running out of IPv4 addresses - NAT takes care of that, and will continue to do so for many years more. We do have a problem of having no way[*] to initiate connections to boxes hidden behind NATs. Which is bad for P2P applications. To solve this problem three things need to be done: 1) to create network infrastructure which can haul packets with extended addresses (be it IPv4 or IPv6) and extend network stacks in the OSes to support this transport; 2) to create a way to map domain names to those addresses; 3) to get applications to work with the extended addresses. You also need a clean migration path from legacy to the new architecture (which IPv6 lacks), just to stay in the realm of practical. 1 and 3 are seriously expensive. 2 is relatively easy as DNS has provisions for expansion which were actually used (instead of reinventing the wheel, thankfully). The issue #1 can be sidestepped by use of LSRR as I suggested. #2 and #3 are, to a considerable extent, already solved by the people implementing IPv6. Now, listen carefully: you don't have to use IPv6 packets to use IPv6 addresses. In fact, all we need to get benefits of extended addressing w/o going to the trouble of implementing native or tunneled IPv6 networks is a simple shim (either within kernels or within language libraries) which takes IPv6 address/socket and translates it into IPv4 socket with appropriate LSRR option information attached. (A small subset of IPv6 addresses could be set aside for the purpose... one /32 or such; just so you can still have IPv6 in all its glory if you wish). The entire amount of development for a Unix-like OS is about 500 lines of code (that's my educated guess based on the gut feeling developed while I was hacking various Unix kernels for living since v6). My question to the community - is it interesting enough? I.e. should I spend my time on writing I-D on IPv4 Extended Addressing, or will I be dismissed as a troll for my trouble? --vadim [*] chownat exceeds even my tolerance for ugliness, though the expoit itself is an elegant use of the quasi-paradox from probability theory.