Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
From: j...@mercury.lcs.mit.edu (Noel Chiappa) Ironically, TCP/IP had variable length addresses put in _twice_, and they were removed both times! Sigh, another correction for the record: it was _three_ times!!! Early versions of IPv4 (IEN-28, confusingly titled Draft Internetwork Protocol Specification: Version 2 - it was actually somewhere between 3.1 and 4; then IEN-41) also had them; they were removed shortly thereafter (IEN-44). (Excuse me if I'm having a hard time keep track of this; they got put in and taken out so many times my head is spinning... :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2/13/2012 7:09 PM, Brian E Carpenter wrote: On 2012-02-14 13:42, Dave CROCKER wrote: On 2/13/2012 4:38 PM, Brian E Carpenter wrote: There were very specific reasons why this was not done. Is there a useful citation that covers this strategic decision? You may recall that at the time, we were very concerned about the pre-CIDR growth rate in BGP and there was, iirc, a generalised aversion to anything that would import the entire IPv4 BGP4 table into IPv6. So, an initial requirement that simply said we need a larger address space became we need a larger address space, a new routing architecture, and a slew of other new mechanisms. For an exercise like creating IPv6, this is called second system syndrome.[1] If often accounts for massive delays. 15 years qualifies. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. The translator needed today is a complete gateway between two entirely incompatible protocols. The one that I'm describing would have been a trivial re-formatter. The development, deployment and interoperability differences between these is massive. Honestly, having had an MSc student who benchmarked translation vs application proxying vs native, I don't think so. In theory, there is no difference between theory and practice... By saying 'benchmarking' you appear to be referring to something like transformation time. But notice that I gave a list that had nothing to do with cpu or i/o performance. I fear that anyone who thinks that developing and operating a slightly enhanced router, such as I described, is the same as an application gateway probably does not understand the relative complexities or OAM demands of either very well. d/ [1][http://en.wikipedia.org/wiki/Second-system_effect -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
Hi Randy and Brian, I am sure the discussion of the discussion has been had before, but: IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. i guess you forget the discussion of variable length. i hope we don't have to rehash it here. decisions were made. some were quite bad. v6 had some real zingers. remember tla/nla? no feature parity, such as dhcp (a war which has not finished)? it is almost as if it was designed to fail. randy I think that the compatibility issue is a key reason why adoption has been difficult. Others are: No compelling IPv6 only features - From my reading several key features were directed at IPv6 only originally, like IPsec. Successive works to provided all non-address IPv6 features in IPv4. - This in part is being addressed by helpful capabilities such as DHCPv6PD (although we could kill things entirely by back porting this to IPv4 ;-) No local use benefit - Ostensibly deploying IPv6 only gets you (slightly) more work. - compare this to transformative technologies such as Ethernet and IPv4, which had a better price point and enabled new local capabilities, which did not rely on neighbours adopting the same protocol. Of course, these are short-sighted analysis. Being able to uniquely address a peer device is a key benefit which we will see drive adoption once 103.X/8 is gone. Another key benefit is local addressability which handles organizational merges/changes/private peering with ULAs (resolves the RFC-1918 collision problem). For a few years I have been involved in an extremely pragmatic market where people want to see the money they will save by deploying a networking technology. What would get my customers adopting would be a compelling TCO argument. Sincerely, Greg Daley Solutions Architect Logicalis Australia Pty Ltd gda...@au.logicalis.com t +61 3 8532 4042 m +61 401 772 770 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2/13/2012 4:17 PM, Brian E Carpenter wrote: People say this from time to time, but it's a complete myth. well, not completely... IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. The path that the IETF followed ensured the maximum amount of incompatibility. Really a completely independent stack. In contrast, the IETF could easily have chose a path toward minimizing incompatibility that would have allowed IPv6 to interwork with IPv4, within the limitations of the v4 address space. That is, the IETF could begun IPv6 by assigning to it IPv4 addresses, reserving the remainder for latter definition and allocation. It could have targeted simple, basic reformatting at the IP level to permit early IPv6 adoption to require a minimal gateway for interworking with the IPv4 world. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2012-02-14 13:32, Dave CROCKER wrote: On 2/13/2012 4:17 PM, Brian E Carpenter wrote: People say this from time to time, but it's a complete myth. well, not completely... IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. The path that the IETF followed ensured the maximum amount of incompatibility. Really a completely independent stack. In contrast, the IETF could easily have chose a path toward minimizing incompatibility that would have allowed IPv6 to interwork with IPv4, within the limitations of the v4 address space. That is, the IETF could begun IPv6 by assigning to it IPv4 addresses, reserving the remainder for latter definition and allocation. It could have targeted simple, basic reformatting at the IP level to permit early IPv6 adoption to require a minimal gateway for interworking with the IPv4 world. There were very specific reasons why this was not done. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2/13/2012 4:38 PM, Brian E Carpenter wrote: There were very specific reasons why this was not done. Is there a useful citation that covers this strategic decision? Given that that decision was an essential part of what caused a roughly 15 year delay, it would be helpful to have it documented. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. The translator needed today is a complete gateway between two entirely incompatible protocols. The one that I'm describing would have been a trivial re-formatter. The development, deployment and interoperability differences between these is massive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. i guess you forget the discussion of variable length. i hope we don't have to rehash it here. decisions were made. some were quite bad. v6 had some real zingers. remember tla/nla? no feature parity, such as dhcp (a war which has not finished)? it is almost as if it was designed to fail. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2012-02-14 13:42, Dave CROCKER wrote: On 2/13/2012 4:38 PM, Brian E Carpenter wrote: There were very specific reasons why this was not done. Is there a useful citation that covers this strategic decision? You may recall that at the time, we were very concerned about the pre-CIDR growth rate in BGP and there was, iirc, a generalised aversion to anything that would import the entire IPv4 BGP4 table into IPv6. I don't recall without a lot of archive grepping whether this was explicit in the IPng decision or whether it came a bit later. Given that that decision was an essential part of what caused a roughly 15 year delay, it would be helpful to have it documented. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. The translator needed today is a complete gateway between two entirely incompatible protocols. The one that I'm describing would have been a trivial re-formatter. The development, deployment and interoperability differences between these is massive. Honestly, having had an MSc student who benchmarked translation vs application proxying vs native, I don't think so. The mechanics of packet translation are trivial. The hard part is exactly the same as with NAT44, caused by the shortage of IPv4 addresses and all the state that goes with sharing the pool of transport ports for a single address. On 2012-02-14 13:49, Randy Bush wrote: i guess you forget the discussion of variable length. i hope we don't have to rehash it here. I haven't forgotten. The worst row I ever had at an IETF meeting was on that topic. decisions were made. some were quite bad. v6 had some real zingers. remember tla/nla? no feature parity, such as dhcp (a war which has not finished)? it is almost as if it was designed to fail. DHCP for v4 was still wet behind the ears at that time, so this wasn't as obvious then as it is now; there's a bit of 20/20 hindsight here. But yes, we could of course have done better. Unfortunately my time machine is broken. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
From: Brian E Carpenter brian.e.carpen...@gmail.com The design error was made in the late 1970s, when Louis Pouzin's advice that catenet addresses should be variable length, with a format prefix, was not taken during the design of IPv4. Ironically, TCP/IP had variable length addresses put in _twice_, and they were removed both times! (You can't make this stuff up! :-) - TCPv1 (no separate TCP and IP at that point) had variable lenth addresses of up to 15 4-bit nibbles - TCP/IPv3 had variable lenth addresses of up to 15 8-bit bytes (but the 'network number' part was supposed to be only the first byte, exactly like IPv4 in its early days) This latter change happened shortly before I joined the project, otherwise no doubt I would have strenously objected! :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
Brian E Carpenter wrote: There were very specific reasons why this was not done. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. The fact is that an old-IP-only host can talk to a new-IP-only host without a translator, if the new IP uses port numbers for addressing/routing. Though NAT is doing similar thing with translation, the translation is not essential and can be reversed at end systems using NAT information obtained through UPnP/PCP. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
