| |||||||||||||
TP/IX and similar plansTP/IX and similar plansPosted Jan 30, 2011 15:15 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: What about IPv6 right here on earth? by butlerm Parent article: LCA: Vint Cerf on re-engineering the Internet
You can't make things compatible by sheer force of will. TP/IX isn't really compatible with IPv4, the RFC leaves you in no doubt whatsoever about that if you ignore the repeated but unfounded assertions to the contrary. The "compatibility" advertised for TP/IX is the same compatibility delivered by dual-stack, in fact it _is_ dual-stack by another name. Everyone must speak both protocols if they want to participate on the Internet.
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.
(Log in to post comments)
TP/IX and similar plans Posted Feb 5, 2011 16:46 UTC (Sat) by butlerm (subscriber, #13312) [Link]
First, no one would have to dual stack. Same stack, larger address space. Routers would do wire format conversion where necessary. Second, technical errors in the TP/IX RFC have no bearing on the merit of the principle described. The IETF was just incredibly short sighted on that point, preferring a start over from scratch design to one where the transition would be practically seamless.
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.
TP/IX and similar plans Posted Feb 9, 2011 14:21 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
"Same stack, larger address space"
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.
TP/IX and similar plans Posted Feb 9, 2011 17:21 UTC (Wed) by daniel (subscriber, #3181) [Link]
<quote>DNS unambiguously defines A records as exactly 32-bits. Hence the existence of 'AAAA' records</quote>
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.
|
|||||||||||||