Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
What about IPv6 right here on earth?
Posted Jan 29, 2011 16:53 UTC (Sat) by butlerm (subscriber, #13312)
I like a plan where a.b.c.d address format is changed to an administratively compatible format where each of the four components is a 16 bit number represented in text format in decimal form.
In binary form the IPv4 address C0 A0 20 01 would become 00C0 00A0 0020 0001. All existing address prefixes would be preserved, except in expanded form when represented in binary. In text format the address would be 22.214.171.124 in both cases. Then one day about ten years later, addresses like 300.278.22.1 would become publicly routable. Or even addresses like 6700.45320.658.33781.
A straightforward expansion would allow a variable number of components where the number varied from 4 to 8 or so. That way everyone with an IPv4 style 4 component address could add publicly addressable sub networks without getting a new allocation. The network core would generally only do routing on the first four components (64 bits) for economic reasons, but hardware routers with 128 bit prefix capability would eventually be come common, starting at large edge networks. Trailing zero bits would be implied.
Existing configurations would be preserved, although alternative netmask indicators would eventually have to be added, because a current "/24" would in actuality be a 48 bit prefix, and if you want to specify netmasks that end on any of the inserted bits a different syntax would need to be used. "//48" style perhaps.
One of the other advantages of a variable length addressing scheme like this is that most addresses would only be 64 bits, not 128, significantly reducing the overhead for small packets like those used in VOIP, especially on lower bandwidth connections. Who really wants their MAC address broadcast all over the Internet anyway? For servers, it is practically useless. For individuals it is a privacy nightmare.
TP/IX and similar plans
Posted Jan 30, 2011 15:15 UTC (Sun) by tialaramex (subscriber, #21167)
It's a huge sprawling mess, far more invasive than the eventual IPv6. I can only say that I'm indebted to whoever persuaded its author that his entirely new routing protocol and algorithms deserved their own "informational" RFC alongside this one, so that people asked to read about one needn't waste their time reading the other.
The economics (remember, that's why IPv6 has a fraction of a percent of penetration, rather than say 80%) are if anything worse. First you must get enough people to deploy "version 7". Your ten year estimate seems optimistic when you realise that although this costs a lot of money it delivers no immediate benefit whatsoever. Far more so than deploying IPv6 today, deploying "version 7" would have been a leap in the dark, trusting that some day we'd get the wider addresses working and it would be for the best. But then they must upgrade _again_ to have wider addresses. In fact they might have to do so repeatedly.
Ullmann's plan reserves 75% of addresses, rationalising that they can be used if the initial proposal turns out to be a bad idea. A similar strategy was chosen in IPv6. But Ullman reserves the wrong bits. An experienced engineer would know that if you leave the top few bits empty, some clown will either use them for a purpose you didn't intend meaning they can never be put into production, or they will confuse signed and unsigned terms and drop the top bit, again rendering it useless in practice. IPv6 was careful to use those top few bits for something obligatory, so implementers would notice and correct such bugs. [ For another example look at the way x86-64 handles virtual addresses ]
There are also numerous technical errors in the specification. e.g. Like some earlier LWN comments it assumes that DNS records are just arbitrary text strings so changing to a system where 'A' answers are sometimes too long for IPv4 is fine, everything will just work. Leaving aside the naivety of imagining that no-one would inadvertently rely on something that's been true for as long as the system has existed the simple technical answer is: No, can't do that, DNS unambiguously defines A records as exactly 32-bits. Hence the existence of 'AAAA' records.
Posted Feb 5, 2011 16:46 UTC (Sat) by butlerm (subscriber, #13312)
In short, the counterargument here has to be not against the weaknesses of a seventeen year old network proposal per se, but rather against the entire idea of preserving the existing address space on a long term basis without renumbering.
Posted Feb 9, 2011 14:21 UTC (Wed) by tialaramex (subscriber, #21167)
Reality isn't interested in proof by assertion, if I call a frog a bird it will not make it fly. TP/IX is a completely new stack. "Just" widening the address field (which is not what TP/IX does) is like "just" adding an extra floor to the middle of every house in the country.
"no one would have to dual stack"
"routers would do wire format conversion"
Do you even read what you're writing? In order to "do wire format conversion" the routers not only need to have both stacks, but they have to be able to convert from one to the other, a major additional expense. Worse, for TP/IX (and any alternative I can imagine) this is stateful. So the plan becomes "instead of buying an expensive IPv4 and IPv6 router, buy an even more expensive IPv4 and TP/IX router-converter" and you've made things worse, not better.
"technical errors in the TP/IX RFC have no bearing on the merit of the principle described. The IETF was just incredibly short sighted"
Of course, how stupid of me. It doesn't need to actually work, someone who needs things to work is being "short sighted". I can't address problems in a non-existent alternative and neither can the IETF.
Fortunately thanks to such "short sighted" people we have a plan, not a painless or easy plan, but one that will work. Now it remains to be seen if everyone will implement it, and how long that will take.
Posted Feb 9, 2011 17:21 UTC (Wed) by daniel (subscriber, #3181)
For the proposal at hand, which as I understand it is to extend the IPv4 address space by 16 bits on the right, an 'AA' record will do and only needs to be implemented at the edges of the classic IPv4 space. In other words, at points under complete control of participants in the experiment.
An 'AA' record would sensibly be defined with the classic IPv4 space in the middle four bytes, the IPv4++ bytes on the right, and the two remaining bytes on the left reserved for future expansion.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds