Re: Variable length internet addresses in TCP/IP: history
Bob Hinden wrote: Martin Rex wrote: With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. Just two days ago I had an extremeley disappointing experience with IPv6. Windows XP 64-bit (aka Win2003sp2) on a local network with a private DNS universe, IPv4 only network, Windows IPv6 protocol stack installed but IPv6 active only on the two virtual network interfaces of VMware. Somehow the DNS servers configured in the network settings had performed only a partial zone reload and were replying only to some queries, failing some DNS queries with server failure or timeout, and one DNS zone had become completely invisible. I noticed the problem suddenly during work because every new connection took ~16 seconds delay to complete. Wondering what was wrong, I started wireshark. I saw Windows2003 send out 23 DNS lookups for records for the requested hostname over the course of 16 seconds (some of which returned server failure, some of which failed with no such name), until Windows 2003 finally decided to also try a DNS A query--which got immediately successfully answered and the connection was established. The delay affected each and every connection attempt, even when contacting the same host repeatedly (although there is a DNScache service running...). Disabling IPv6 on all network adapters did not stop this Windows frenzy, I had to actually uninstall the IPv6 protocol stack (an action which immediately kills *ALL* network connectivity of the machine and requires a reboot to recover...) for this nonsense to end. During the past few years I had two similar encounters with sudden severe connectivity problems on a Windows XP and a Linux installation, and both times, the problem disappeared when I disabled IPv6. It is also significantly easier to configure the firewall for IPv4-only... -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
Martin, Yes, the issues with an unconditional prefer IPv6 approach have been noted, and operating systems of the vintages you mention certainly deserved criticism. In fact this has been a major focus of IPv6 operational discussions, and lies behind things like the DNS whitelisting method, the happy-eyeballs work, and my own RFC 6343. Old news; unfortunately it means you need new o/s versions. Disabling 6to4 and Teredo unless they are known to be working well is a good start, however. Regards Brian Carpenter On 2012-02-24 05:51, Martin Rex wrote: Bob Hinden wrote: Martin Rex wrote: With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. Just two days ago I had an extremeley disappointing experience with IPv6. Windows XP 64-bit (aka Win2003sp2) on a local network with a private DNS universe, IPv4 only network, Windows IPv6 protocol stack installed but IPv6 active only on the two virtual network interfaces of VMware. Somehow the DNS servers configured in the network settings had performed only a partial zone reload and were replying only to some queries, failing some DNS queries with server failure or timeout, and one DNS zone had become completely invisible. I noticed the problem suddenly during work because every new connection took ~16 seconds delay to complete. Wondering what was wrong, I started wireshark. I saw Windows2003 send out 23 DNS lookups for records for the requested hostname over the course of 16 seconds (some of which returned server failure, some of which failed with no such name), until Windows 2003 finally decided to also try a DNS A query--which got immediately successfully answered and the connection was established. The delay affected each and every connection attempt, even when contacting the same host repeatedly (although there is a DNScache service running...). Disabling IPv6 on all network adapters did not stop this Windows frenzy, I had to actually uninstall the IPv6 protocol stack (an action which immediately kills *ALL* network connectivity of the machine and requires a reboot to recover...) for this nonsense to end. During the past few years I had two similar encounters with sudden severe connectivity problems on a Windows XP and a Linux installation, and both times, the problem disappeared when I disabled IPv6. It is also significantly easier to configure the firewall for IPv4-only... -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
Yes, the issues with an unconditional prefer IPv6 approach have been noted, and operating systems of the vintages you mention certainly deserved criticism. In fact this has been a major focus of IPv6 operational discussions, and lies behind things like the DNS whitelisting method, the happy-eyeballs work, and my own RFC 6343. Old news; unfortunately it means you need new o/s versions. Disabling 6to4 and Teredo unless they are known to be working well is a good start, however. Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. Doug (well, maybe happily is too strong a word, but you get the idea) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. And systems running these old OS versions never under any circumstances move from one network to another where connectivity conditions change. Riiight. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
On 02/23/2012 14:48, Ned Freed wrote: On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. And systems running these old OS versions never under any circumstances move from one network to another where connectivity conditions change. Riiight. Brian already covered unconditional prefer-IPv6 was a painful lesson learned, and I'm not saying that those older systems did it right. What I am saying is that for most values of IPv6 Ready which included putting the system on an actual IPv6 network, they worked as advertised. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
On 02/23/2012 14:48, Ned Freed wrote: On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. And systems running these old OS versions never under any circumstances move from one network to another where connectivity conditions change. Riiight. Brian already covered unconditional prefer-IPv6 was a painful lesson learned, and I'm not saying that those older systems did it right. What I am saying is that for most values of IPv6 Ready which included putting the system on an actual IPv6 network, they worked as advertised. Which brings us right back to my original point: This definition of ready is operationally meaningless in many cases. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
In message 01occ10b11tc00z...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: On 02/23/2012 14:48, Ned Freed wrote: On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. And systems running these old OS versions never under any circumstances m ove from one network to another where connectivity conditions change. Riiight . Brian already covered unconditional prefer-IPv6 was a painful lesson learned, and I'm not saying that those older systems did it right. What I am saying is that for most values of IPv6 Ready which included putting the system on an actual IPv6 network, they worked as advertised. Which brings us right back to my original point: This definition of ready i s operationally meaningless in many cases. I contend that OS are IPv6 ready to exactly the same extent as they are IPv4 ready. This isn't a IPv6 readiness issue. It is a *application* multi-homing readiness issue. The applications do not handle unreachable addresses, irrespective of their type, well. The address selection rules just made this blinding obvious when you are on a badly configured network. No one expect a disconnected IPv4 network to work well when the applications are getting unreachable addresses. Why do they expect a IPv6 network to work well under those conditions? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
In message 01occ10b11tc00z...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: On 02/23/2012 14:48, Ned Freed wrote: On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: Old news perhaps, but an unavoidable consequence of this is that the oft-repeated assertions that various systems have been IPv6 ready for over 10 years don't involve a useful definition of the term ready. The OP specified IPv4 only network. I suspect that if he had IPv6 connectivity his experience would have been quite different. I happily use Windows XP on a dual-stack network, for example. And systems running these old OS versions never under any circumstances m ove from one network to another where connectivity conditions change. Riiight . Brian already covered unconditional prefer-IPv6 was a painful lesson learned, and I'm not saying that those older systems did it right. What I am saying is that for most values of IPv6 Ready which included putting the system on an actual IPv6 network, they worked as advertised. Which brings us right back to my original point: This definition of ready i s operationally meaningless in many cases. I contend that OS are IPv6 ready to exactly the same extent as they are IPv4 ready. This isn't a IPv6 readiness issue. It is a *application* multi-homing readiness issue. The applications do not handle unreachable addresses, irrespective of their type, well. The address selection rules just made this blinding obvious when you are on a badly configured network. That's because the choice has recently been made that the place to deal with this problem is in applications themselves. I happen to think this is an exceptionally poor choice - the right way to do it is to provide a proper network API that hides network selection details, rather than demanding every application out there solve the problem separately. And yes, I'm familiar with the line of reasoning that says applications are too varied in their needs, or their internal environments conflict with the necessary use of threads, or whatever. I don't buy any of it. Yes, such applications exist, but like most things there's a sweet spot that solves a significant fraction of the problem. No one expect a disconnected IPv4 network to work well when the applications are getting unreachable addresses. Why do they expect a IPv6 network to work well under those conditions? First, you're comparing apples and oranges. Losing all network connectivity is very different thing from losing partial network connectivity. Nobody expects an applications that's totally dependent on the network to work without connectivity. That's just silly. But with other sorts of applications, I *do* have that expectation. I often work from places without any network connectivity using applications that employ networking as part of their function but also do non-networked stuff, and pretty much without exception they handle the transition fine, and have done so for years. Then again, I use a Mac. I have no idea what the state of play of Windows or Linux apps is in this regard. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
Mark Andrews wrote: Brian already covered unconditional prefer-IPv6 was a painful lesson learned, and I'm not saying that those older systems did it right. You learned a wrong lesson, then. The essential problem is that there is half hearted support for handling multiple addresses. It is not an operational problem but a fundamental defects of protocols. I contend that OS are IPv6 ready to exactly the same extent as they are IPv4 ready. This isn't a IPv6 readiness issue. It is a *application* multi-homing readiness issue. The applications do not handle unreachable addresses, irrespective of their type, well. In part, it is an application problem. However, it is also an IP layer problem. The address selection rules just made this blinding obvious when you are on a badly configured network. The half hearted address selection rules will keep causing this kind of problems, until IPv6 specification is fundamentally fixed. No one expect a disconnected IPv4 network to work well when the applications are getting unreachable addresses. Why do they expect a IPv6 network to work well under those conditions? With proper IP layer support, which is lacking, which means IPv6 specification is not ready to handle multiple addresses, which means hosts are not IPv6 ready to handle multiple addresses, we can expect applications work well if one of an address among many works and rest of the addresses are unreachable. Masataka Ohta PS IPv4, of course, is not ready to handle multiple addresses properly, which causes some problems for multihomed hosts. But it is not a serious problem because IPv4 hosts do not have to have IPv6 addresses. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
On 2012-02-24 12:32, ned+i...@mauve.mrochek.com wrote: In message 01occ10b11tc00z...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: ... I contend that OS are IPv6 ready to exactly the same extent as they are IPv4 ready. This isn't a IPv6 readiness issue. It is a *application* multi-homing readiness issue. The applications do not handle unreachable addresses, irrespective of their type, well. The address selection rules just made this blinding obvious when you are on a badly configured network. That's because the choice has recently been made that the place to deal with this problem is in applications themselves. I happen to think this is an exceptionally poor choice - the right way to do it is to provide a proper network API that hides network selection details, rather than demanding every application out there solve the problem separately. I wish, I *really* wish, that it worked. Making it work, by one technique or another, is not a new topic, even when only IPv4 connectivity was at issue. Those things are often called 'connection managers' and are largely based on trial and error or reachability probes. Then there are efforts like SCTP and MPTCP to solve it in the transport layer, and shim6 to solve it in the network layer (for IPv6 only, but the issue is the same). These solutions are also essentially based on trial and error, and need to be supported by both hosts. And yes, I'm familiar with the line of reasoning that says applications are too varied in their needs, or their internal environments conflict with the necessary use of threads, or whatever. I don't buy any of it. Yes, such applications exist, but like most things there's a sweet spot that solves a significant fraction of the problem. That's been part of Java for some years (since 1.5 iirc). But it *doesn't* solve precisely the problem that Martin was describing, where a stack falsely believes that it has IPv6 connectivity but in fact it doesn't. In that sort of situation, short of manual intervention, something like happy-eyeballs seems to be needed in order for the application to fix things up when the network layer is confused. And no, I'm not happy with this, but it seems to be reality. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]
ned+i...@mauve.mrochek.com wrote: This definition of ready is operationally meaningless in many cases. The meaningful question is whether we have to modify code or not. If we have to, a host is not ready. And, if it is not an implementation problem, protocols must be fixed. If we don't have to, it's an operational issue. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
In message 201202231651.q1ngpxgl017...@fs4113.wdf.sap.corp, Martin Rex writes : Bob Hinden wrote: Martin Rex wrote: With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. Just two days ago I had an extremeley disappointing experience with IPv6. Windows XP 64-bit (aka Win2003sp2) on a local network with a private DNS universe, IPv4 only network, Windows IPv6 protocol stack installed but IPv6 active only on the two virtual network interfaces of VMware. Somehow the DNS servers configured in the network settings had performed only a partial zone reload and were replying only to some queries, failing some DNS queries with server failure or timeout, and one DNS zone had become completely invisible. I noticed the problem suddenly during work because every new connection took ~16 seconds delay to complete. Wondering what was wrong, I started wireshark. I saw Windows2003 send out 23 DNS lookups for records for the requested hostname over the course of 16 seconds (some of which returned server failure, some of which failed with no such name), until Windows 2003 finally decided to also try a DNS A query--which got immediately successfully answered and the connection was established. The delay affected each and every connection attempt, even when contacting the same host repeatedly (although there is a DNScache service running...). Disabling IPv6 on all network adapters did not stop this Windows frenzy, I had to actually uninstall the IPv6 protocol stack (an action which immediately kills *ALL* network connectivity of the machine and requires a reboot to recover...) for this nonsense to end. During the past few years I had two similar encounters with sudden severe connectivity problems on a Windows XP and a Linux installation, and both times, the problem disappeared when I disabled IPv6. It is also significantly easier to configure the firewall for IPv4-only... -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf We (ISC) learned a long time ago (last century) that partial DNS service for a zone is worse than total failure for a zone. By totally failing a zone on error it gets fixed instead of trying to limp by on partial service. I also suspect the search algorithm is not stopping on NOERROR NODATA or SERVFAIL. Searches really should stop on both those conditions. By stopping I mean not going onto the next element in the search list without getting a NXDOMAIN response. You can ask multiple servers on SERVFAIL. I've been arguing this for around 10+ years. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Bob Hinden wrote: ID/locator split, which I've been a proponent of for very many years, works a lot better with more bits, because it allows topological addressing both within and outside an organization. To confirm what your are saying about an ID/locator split in IPv6, that the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. I actually implemented such a system about 10 years ago and it worked fine. It was an experiment for hosts to use multiple IPv4 and IPv6 addresses, some of which may have ID/loc separation. DNS was used for ID-loc mapping. Mobility was also supported with multiple home locators and multiple foreign locators. We did something related to end to end multihoming and happy eyeball. ID locator separation was good, because it requires about half amount of space to store multiple addresses sharing an ID. Moreover, rewriting destination locators enables elegant forwarding from home agents to mobile nodes without tunneling (and associated MTU tax), if transport check sums do not involve locators. But, that's all. It was not very interesting that I abandoned further work on it after government funding period expired. Opinions vary if ID/locator split is useful, but we have a framework that would allow it without having to roll out another version of IP. A win IMHO. Assuming address must be 16B long, it may be good to have ID/loc separation. However, if we have choice, having 8B long addresses is much better, because it is more compact than 16B address with ID/loc separation. Even with 8B addresses, we can rewrite destination addresses, if there is a destination header option (or a mandatory field) original destination address to be used to confirm transport identity and checksum. So, along with the failure with a lot of confusion to have SLAAC, we can conclude that IPv6 addresses should have been 8B long. Maybe, even with the current IPv6 packet format, routers can look only at first 8B of addresses and ignore the latter 8B (used as original source/destination address for source/destination address rewriting). Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2/16/2012 6:46 PM, Steven Bellovin wrote: Why? Apart from the fact that if this transition is painful, the next one will be well-nigh impossible, having more bits lets us find creative ways to use the address space. Not to single out Steve, but my recollection is that that view was at the core of much of the thinking about v6, certainly in the early-/mid-90s. We only get this one (last) opportunity to make changes, so we'd better add everything we think we'll (ever) need. The view is wrong. Changing an established infrastructure is of course (a lot) more difficult and expensive than creating a new one, but infrastructures can and do get changed. There is a difference between saying we need to make all of the changes that we know we need now, versus saying we need to anticipate all of the changes we are going to need to make. Steve's phrasing points to the latter and that winds up as a fantasy exercise which adds complexity and delay. It also tends to add the wrong things in the wrong way. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Steve, On Feb 16, 2012, at 6:46 PM, Steven Bellovin wrote: On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote: Steven Bellovin wrote: Thus, IPv6 was mortally wounded from the beginning. The history is vastly more complex than that. However, this particular decision was just about the last one the IPng directorate made before reporting back to the IETF -- virtually everything else in the basic IPv6 design had already been agreed-to. I understand that, unlike 64 bit, 128 bit enables MAC based SLAAC with full of states, which is as fatal as addresses with 32 hexadecimal characters. That decision came later. In fact, the deficiencies of relying on MACs were discussed quite frequently in the directorate. And that's why the standard allows for other types of identifiers to be used to create Interface Identifiers. I don't think this was the wrong decision. Isn't it obvious that, with a lot more than 1% penetration of the Internet to the world today, we don't need address length much more than 32 bits? No. I did and I do think that 64 bits was inadequate. Why? Apart from the fact that if this transition is painful, the next one will be well-nigh impossible, having more bits lets us find creative ways to use the address space. Stateless autoconfig is one example, though I realize it's controversial. ID/locator split, which I've been a proponent of for very many years, works a lot better with more bits, because it allows topological addressing both within and outside an organization. To confirm what your are saying about an ID/locator split in IPv6, that the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. Opinions vary if ID/locator split is useful, but we have a framework that would allow it without having to roll out another version of IP. A win IMHO. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
From: Bob Hinden bob.hin...@gmail.com the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. ... we have a framework that would allow it without having to roll out another version of IP. Alas, the inclusion of _both halves_ of the IPv6 address in the TCP checksum means the framework you speak of is basically useless for an identity/location split. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Noel, On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote: From: Bob Hinden bob.hin...@gmail.com the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. ... we have a framework that would allow it without having to roll out another version of IP. Alas, the inclusion of _both halves_ of the IPv6 address in the TCP checksum means the framework you speak of is basically useless for an identity/location split. That's why I described it as a framework. The TCP pseudo-checksum would have to change and likely the addition of some sort of authentication at connection establishment to associate an identifiers with a set of locators. Not trivial, but doable. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2012-02-18 08:10, Bob Hinden wrote: Noel, On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote: From: Bob Hinden bob.hin...@gmail.com the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. ... we have a framework that would allow it without having to roll out another version of IP. Alas, the inclusion of _both halves_ of the IPv6 address in the TCP checksum means the framework you speak of is basically useless for an identity/location split. That's why I described it as a framework. The TCP pseudo-checksum would have to change and likely the addition of some sort of authentication at connection establishment to associate an identifiers with a set of locators. Not trivial, but doable. Authentication is not just doable, but done, in shim6. However, shim6 ducks the checksum issue by being a shim. ILNP deals with it up front, but is a bigger change from vanilla IPv6. The flexibility is there, but it's academic until we get IPv6 widely deployed. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Steven Bellovin wrote: Thus, IPv6 was mortally wounded from the beginning. The history is vastly more complex than that. However, this particular decision was just about the last one the IPng directorate made before reporting back to the IETF -- virtually everything else in the basic IPv6 design had already been agreed-to. I understand that, unlike 64 bit, 128 bit enables MAC based SLAAC with full of states, which is as fatal as addresses with 32 hexadecimal characters. I don't think this was the wrong decision. Isn't it obvious that, with a lot more than 1% penetration of the Internet to the world today, we don't need address length much more than 32 bits? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote: Steven Bellovin wrote: Thus, IPv6 was mortally wounded from the beginning. The history is vastly more complex than that. However, this particular decision was just about the last one the IPng directorate made before reporting back to the IETF -- virtually everything else in the basic IPv6 design had already been agreed-to. I understand that, unlike 64 bit, 128 bit enables MAC based SLAAC with full of states, which is as fatal as addresses with 32 hexadecimal characters. That decision came later. In fact, the deficiencies of relying on MACs were discussed quite frequently in the directorate. I don't think this was the wrong decision. Isn't it obvious that, with a lot more than 1% penetration of the Internet to the world today, we don't need address length much more than 32 bits? No. I did and I do think that 64 bits was inadequate. Why? Apart from the fact that if this transition is painful, the next one will be well-nigh impossible, having more bits lets us find creative ways to use the address space. Stateless autoconfig is one example, though I realize it's controversial. ID/locator split, which I've been a proponent of for very many years, works a lot better with more bits, because it allows topological addressing both within and outside an organization. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
G'day. Always fun to watch an exchange among entrenched perspectives... On 2/14/2012 9:31 AM, Bob Braden wrote: However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). Experience with development, deployment and operations using a core construct is not irrelevant when trying to upgrade an infrastructure function. As I recall, there was essentially no experience with variable length addresses -- and certainly no production experience -- then or even by the early 90s, when essentially the same decision was made and for essentially the same reason.[1] It's not that variable length addressing is a bad idea; it's that it didn't get the research work and specification detail it needed, for introduction into what had become critical infrastructure. What I recall during the IPng discussions of the early 90s was promotion of the /concept/ of variable length addressing but without the experiential base to provide assurance we knew how it would operate. Clearly the motivation for variable-length addresses is a Good Thing, since having it work properly would save needing to do an infrastructure change to quadruple the address space every 2-3 decades. (With 128-bit addressing, perhaps it will be longer; with the rapid expansion of the Internet, perhaps it will be sooner.) But really I'll suggest that fixed-vs-variable addressing is essentially irrelevant to the question of transition ease and backward compatibility. What mostly affects that is effort. Development, deployment and operations effort. For an established infrastructure, the more a change is different from what already is used, the more effort it takes to introduce the new thing. (Versions of this point have been made on this thread repeatedly by other folk, and mostly everyone is ignoring the premise. I'll add that for folk who have noted the potential significance of my occasional consonance with the views of John Klensin, please be aware that its occurrence with Randy Bush is considerably more rare...) Among the arguments being used to miss the point are: On 2/14/2012 2:34 PM, Brian E Carpenter wrote: I'm sorry, but*any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support32 bit addresses, you have the problem. This notes an objective reality about a limit, while entirely missing the potential benefit available until reaching it. In this case, that was a 15-20 year window. If the design goal had been restricted to the original increase the address space bits, without encumbering it with additional architecture and functional changes, and had been based on re-use of the existing IPv4 scheme, the initial upgrade could have: a) been with a module tacked on to existing IPv4 implementations and installed as a relatively minor software upgrade (albeit with some additional API hooks) to most implementations, rather than the traumatic installation of an entirely new stack b) used trivial format-mapping translators rather than having to deal with the software and operational complexities of gateways that have to reconcile independent address spaces and other functionality c) had essentially no incremental deployment or operations costs This would have gotten the core of the larger address space mechanism deployed and operational long before it was needed, and the focus after that would have been restricted to /using/ the additional bits, rather than trying to solve a variety of additional problems. Moving from re-using IPv4 addressing to expansion into new IPv6 bits for addressing could have then been a separate, incremental step. An important one, certainly. A step with its own challenges, sure. But incremental and narrow. The classic project management point for major change is to minimize critical dependencies. Instead, the IPv6 increased them. On 2/14/2012 3:56 PM, Bob Hinden wrote: The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. The Arpanet did not convert to production use of TCP/IP until it was forced to by a central authority in 1983. Long before 'revenue' was an issue. Absent coercion like this, organizations do not incur the considerable cost of infrastructure change in the absence of a strongly-perceived need that will have reasonably immediate and significant benefit. This is one of the very basic reasons that
Re: Variable length internet addresses in TCP/IP: history
From: Bob Braden bra...@isi.edu You probably remember this, but... I was on the very edge at the time (more below), but yes. A few things that caught my eye (including a minor date offset - I like to get noise out of the record before it gets engrained): argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) There was a discussion about this on the internet-history list (although in the content of TCP/IP-v4's birthday) back at the end of March, 2006: http://mailman.postel.org/pipermail/internet-history/2006-March/date.html It turned out that the relevant meeting was the one held at MIT on 15-16 June 1978 (minutes are in IEN-68); the final formats for TCP4 and IPv4 were picked on 16 June, and documented in IEN-44 (Latest Header Formats) immediately thereafter. I don't know about Jon or Danny, but I have a _very_ clear memory of David Reed coming out of the meeting and being totally disgusted! (My office was just a few feet down the hall from the conference room - I wasn't in the meeting, I guess I wasn't considered 'real' enough yet! My first meeting was the August, 1978 meeting.) His argument was that TCP/IP had to be simple to implement if it were to succeed ... variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. The sad part is that we could have had our cake, and eaten it too! If we'd kept the variable length packet format, and said 'for now, the only supported length is 4', we'd have had the best of both worlds: simple implementations, and longer-term flexibility. (I have no problems with implementation hacks: e.g. the early MIT router code for subnets initially had a 'MyANet' static variable in it, which was non-0 on a subnetted network! :-) It would have been so _easy_, if only we'd thought of it! And look how much it would have saved us!! Oh well, 20/20 hindsight. But this need to have a perfect balance between implementability and long-term flexibility is a lesson that has stayed with me very forcefully. (and survive the juggernaut of the ISO OSI protocol suite). I don't really recall the ISO suite being a big concern at that point? I know some years later it was, but it was totally off my personal radar at that point. I do recall very clearly some mutterings in the hallway after the June 78 meeting about the number of pointer registers available at interrupt time in TENEX (although to be fair I doubt that was the reason fixed-length was chosen)! Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Wed, 2012-02-15 at 13:23 -0500, Noel Chiappa wrote: The sad part is that we could have had our cake, and eaten it too! If a (hierarchical) variable length addressing would not have mandated a hierarchical routing as well, then yeah, cake would have tasted well as it remained there on the table. /M signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 15-Feb-12 08:42, Dave CROCKER wrote: As I recall, there was essentially no experience with variable length addresses -- and certainly no production experience -- then or even by the early 90s, when essentially the same decision was made and for essentially the same reason.[1] It's not that variable length addressing is a bad idea; it's that it didn't get the research work and specification detail it needed, for introduction into what had become critical infrastructure. What I recall during the IPng discussions of the early 90s was promotion of the /concept/ of variable length addressing but without the experiential base to provide assurance we knew how it would operate. The problem with variable-length addressing that, in practice, one needs to specify a maximum length. The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2/15/2012 1:10 PM, Stephen Sprunk wrote: The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms. The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. For most variable-length schemes, yes, but not all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
This is essentially correct. The apparent conceptual difference is that a variable length address looks more like source routing. The end system owns only a small part of the total address; the rest is the network portion, fashioned to seem like a source route. Depending on how the address is interpreted, the division of the network portion into routing steps will be specified in advance or will be interpreted at each step. The latter alllows gradual evolution of the network by consolidating small switches into larger ones. The transition to CIDR within IPv4 accomplished pretty much the same thing and had the same benefits. Nonetheless, 32 bits just isn't enough. The only way variable length address would have provided a smooth transition is if there had been room to increase the length of the address after some years of use. Well, if we had left room in the address field for more than 32 bits, we'd have had the same advantage. But we didn't. Steve On Feb 15, 2012, at 4:10 PM, Stephen Sprunk wrote: On 15-Feb-12 08:42, Dave CROCKER wrote: As I recall, there was essentially no experience with variable length addresses -- and certainly no production experience -- then or even by the early 90s, when essentially the same decision was made and for essentially the same reason.[1] It's not that variable length addressing is a bad idea; it's that it didn't get the research work and specification detail it needed, for introduction into what had become critical infrastructure. What I recall during the IPng discussions of the early 90s was promotion of the /concept/ of variable length addressing but without the experiential base to provide assurance we knew how it would operate. The problem with variable-length addressing that, in practice, one needs to specify a maximum length. The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms. I look forward to your design for a forwarding plane based on streaming addresses :) Does anyone really think that we'll need more than 128 bits? --Richard The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. For most variable-length schemes, yes, but not all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms. One example would be a linked-list of strides... - Wes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2/15/2012 1:39 PM, Richard Barnes wrote: The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms. I look forward to your design for a forwarding plane based on streaming addresses :) Does anyone really think that we'll need more than 128 bits? You might have missed my opening qualification by refererring to practical terms as an actual limit? I was responding to a comment about design limitations; I wasn't recommending infinite-length addressing. I wasn't being as theoretical as one might assume. Although I had no direct hands-on, some of the folks on this list did: http://en.wikipedia.org/wiki/Word_%28computer_architecture%29#Variable_word_architectures d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
From: Steve Crocker st...@shinkuro.com
a variable length address looks more like source routing.
...
the network portion, fashioned to seem like a source route.
... the division of the network portion into routing steps will be
specified in advance or will be interpreted at each step.
This is sort of tangential, and I apologize for that, but...
I hear this assertion (that hierarchical addresses are effectively a
source route) a fair amount, and I'd like to push back on it, because I
think it's somewhat misleading, and confuses beginners more than it helps
them.
The thing is that at each level, a hierarchical address is _very limited_ in
what it can pick as the 'next hop' of the 'source route': it cannot go
sideways in the hierarchy (e.g. from A.p to A.q), and it cannot go up
(e.g. from A.p to B). It can only select one of the 'next layer down'
elements: i.e. from A.p, it can only select one of A.p.1 ... A.p.{n}.
It may seem in some ways a bit like a route, but it's really not (and,
like I said, I have seen beginners get terribly confused in trying to fit
it into that paradigm).
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Scott, if memory serves you and I wanted the high-order 2 bits of the IPng address to select between 64, 128, 192, and 256-bit addresses -- and when we couldn't get that we got folks to agree on 128-bit addresses instead of 64-bit, which is what had been on the table. On Feb 14, 2012, at 1:37 39PM, Bradner, Scott wrote: in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not Scott Scott O Bradner Senior Technology Consultant Harvard University Information Technology Innovation Architecture (P) +1 (617) 495 3864 29 Oxford St. Rm 407 Cambridge, MA 02138 On Feb 14, 2012, at 1:34 PM, Steve Crocker wrote: The word alignment issue was very strong and the router people had considerably more influence than the host folks. I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all. Steve Sent from my iPhone On Feb 14, 2012, at 6:31 PM, Bob Braden bra...@isi.edu wrote: On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Variable length internet addresses in TCP/IP: history
But the maximum for implementation is not necessarily the maximum for the packet format. Thus one could have started with a variable length address format, but said For the immediate future we will always pick a length of 32 bits. Then at some point we could have said in 5 years we are going to start assigning 64 bit addresses, you MUST update your implementations to support this as well -- same packet format and everything else stays the same. We would have needed to be very careful to ensure that the packet formats allowing variable lengths applied to all protocols that carry or use IP addresses (such as DNS records, ...). Such architectural care is not easy to enforce. Whether everyone actually would have updated their implementations is another issue -- but at least in theory it *might* have been simpler than upgrading to a new version of IP. Of course, since we don't have time machines, it is too late to change our past (and we will note that other types of networks have run out of addresses / digits / area codes also). Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Sprunk Sent: Wednesday, February 15, 2012 4:10 PM To: ietf@ietf.org Subject: Re: Variable length internet addresses in TCP/IP: history On 15-Feb-12 08:42, Dave CROCKER wrote: As I recall, there was essentially no experience with variable length addresses -- and certainly no production experience -- then or even by the early 90s, when essentially the same decision was made and for essentially the same reason.[1] It's not that variable length addressing is a bad idea; it's that it didn't get the research work and specification detail it needed, for introduction into what had become critical infrastructure. What I recall during the IPng discussions of the early 90s was promotion of the /concept/ of variable length addressing but without the experiential base to provide assurance we knew how it would operate. The problem with variable-length addressing that, in practice, one needs to specify a maximum length. The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 15, 2012, at 5:44 53PM, Ross Callon wrote: But the maximum for implementation is not necessarily the maximum for the packet format. Thus one could have started with a variable length address format, but said For the immediate future we will always pick a length of 32 bits. Then at some point we could have said in 5 years we are going to start assigning 64 bit addresses, you MUST update your implementations to support this as well -- same packet format and everything else stays the same. We would have needed to be very careful to ensure that the packet formats allowing variable lengths applied to all protocols that carry or use IP addresses (such as DNS records, ...). Such architectural care is not easy to enforce. Whether everyone actually would have updated their implementations is another issue -- but at least in theory it *might* have been simpler than upgrading to a new version of IP. One argument against the 64/128/192/256 proposal was that untested code paths would be buggy. Very true -- which is why we should have done things like use 192-bit addresses for loopback, 256 for multicast, 128 for root servers, etc. Of course, since we don't have time machines, it is too late to change our past (and we will note that other types of networks have run out of addresses / digits / area codes also). Fred Brooks has noted (in the context of computer address spaces) that every successful architecture has eventually run out of bits. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Steve Crocker wrote: The only way variable length address would have provided a smooth transition is if there had been room to increase the length of the address after some years of use. Bottom up approach to extend address length toward port numbers, thus, worked, is working and will keep working with or without NAT. If necessary, we can have new TCP, UDP and other transport protocols with 32 or 48 bit long port numbers without changing core routers, though it requires minor modifications to transport and application code. Anyway the current 48 bit space of IPv4 addresses and 16 bit port numbers will be suffice for a decade or two. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Steven Bellovin wrote: Scott, if memory serves you and I wanted the high-order 2 bits of the IPng address to select between 64, 128, 192, and 256-bit addresses -- and when we couldn't get that we got folks to agree on 128-bit addresses instead of 64-bit, which is what had been on the table. Thus, IPv6 was mortally wounded from the beginning. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 15, 2012, at 7:43 30PM, Masataka Ohta wrote: Steven Bellovin wrote: Scott, if memory serves you and I wanted the high-order 2 bits of the IPng address to select between 64, 128, 192, and 256-bit addresses -- and when we couldn't get that we got folks to agree on 128-bit addresses instead of 64-bit, which is what had been on the table. Thus, IPv6 was mortally wounded from the beginning. The history is vastly more complex than that. However, this particular decision was just about the last one the IPng directorate made before reporting back to the IETF -- virtually everything else in the basic IPv6 design had already been agreed-to. It was a long, painful effort, with a lot of debate over very many of the points that have been discussed over and over again. I don't think this was the wrong decision. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Variable length internet addresses in TCP/IP: history
On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The word alignment issue was very strong and the router people had considerably more influence than the host folks. I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all. Steve Sent from my iPhone On Feb 14, 2012, at 6:31 PM, Bob Braden bra...@isi.edu wrote: On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not Scott Scott O Bradner Senior TechnologyConsultant Harvard University Information Technology Innovation Architecture (P) 1 (617) 495 3864 29 Oxford St. Rm 407 Cambridge, MA 02138 On Feb 14, 2012, at 1:34 PM, Steve Crocker wrote: The word alignment issue was very strong and the router people had considerably more influence than the host folks. I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all. Steve Sent from my iPhone On Feb 14, 2012, at 6:31 PM, Bob Braden bra...@isi.edu wrote: On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Bob Braden wrote: Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). I'm quite OK with both, IPv4 fixed-length 32-bit addresses and IPv6 fixed-length 128-bit addresses, and consider fixed-length addresses reasonable. What I really don't like is that IPv6 was not made to be transparently backwards compatible (on the IPv4 address range), but instead a completely different protocol that requires non-trivial translation IPv4-IPv6. One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. You would not have two distinct routing tables for two independent Internets, but a single routing table for a single Internet. And the first network interfaces that would be using 32-bit IP-addresses exclusively would have been networking equipment of ISPs that does not need to be IPv4-addressable by everyone and his dog anyway (that is not so much different from the /10 shared address space that CGNs will be using). The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary and the security assessment for an IPv6 enabled network *MUCH* simpler. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
In message 201202142245.q1emjaou019...@fs4113.wdf.sap.corp, Martin Rex writes : The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary and the security assessment for an IPv6 enabled network *MUCH* simpler. Happy eyeballs just points out problems with multi-homing in general. IPv4 has the *same* problem and sites spend 1000's of dollars working around the issue which could have been addressed with a couple of extra lines of code on the client side in most cases. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Martin, On Feb 14, 2012, at 2:45 PM, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. These if we had only done foo discussions all miss the biggest deployment factor. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, Sure. address mapping, and translation. Not at all. Realm Specific IP [RFC3102] is such an example without any mapping nor translations. Abstract of the RFC states: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support32 bit addresses, you have the problem. The only problem is that some people misinterpret it that we had needed IPv6. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Mark Andrews wrote: Happy eyeballs just points out problems with multi-homing in general. IPv4 has the *same* problem and sites spend 1000's of dollars working around the issue which could have been addressed with a couple of extra lines of code on the client side in most cases. It's Brian Carpenter who refused to discuss such issues in MULTI6 WG. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. perhaps 'engineering' includes thinking about the costs of deployment. perhaps backward compatibility would have reduced the costs. randy, whose $dayjob did deploy very early ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2012-02-15 11:45, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. Why would the economic incentives have been significantly different? You would not have two distinct routing tables for two independent Internets, but a single routing table for a single Internet. True, but why is this a particular advantage? It wouldn't have affected the need for an update to BGP4, for example. And the first network interfaces that would be using 32-bit IP-addresses exclusively would have been networking equipment of ISPs that does not need to be IPv4-addressable by everyone and his dog anyway (that is not so much different from the /10 shared address space that CGNs will be using). Neither is it so much different from dual stack routing, which has been working for, what, 15 years now? I don't see the comparison with CGN though, which is a carefully engineered single bottleneck of failure, in contrast to dynamic routing. The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary As someone else said, this is to do with multihoming and multi-interfacing; the fact that there are two address lengths is a side-issue. We would still have needed to update the socket interface to deal with 32 bit addresses, and ditto the DNS. and the security assessment for an IPv6 enabled network *MUCH* simpler. I agree that the fact that IPv6 has a different feature list from IPv4 has provided entertainment for security analysts. I will shut up on this topic and get back to IPv6 deployment. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. rant the routers had v6 code in the mid to late '90s. servers had the kame stack before then. etc etc etc. except for dhcp, of course, as the v6 religious zealots did not want to allow dhcp, it would make enterprise conversion too easy. what we did not have was a way to deploy around the fracking incompatibility. it was not until 2001 or so that we could even run useful dual stack, so we early deployers had two parallel networks for some years. religion has always been more important to the ietf than deployment. look at dhcpv6, the zealots are still stonewalling router discovery. look at the deprecation of nat-pt, now nat64/dns64. it is as if the ipv6 high priesthood did everything in their power to make ipv6 undeployable without very high cost. and they have succeeded admirably. so today, since the costs of ipv6 incompatibility and lack of feature parity are still high, for some folk it is easier to deploy nat4. what a win for the internet. congratulations. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 14, 2012 7:40 PM, Randy Bush ra...@psg.com wrote: Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. rant the routers had v6 code in the mid to late '90s. servers had the kame stack before then. etc etc etc. except for dhcp, of course, as the v6 religious zealots did not want to allow dhcp, it would make enterprise conversion too easy. what we did not have was a way to deploy around the fracking incompatibility. it was not until 2001 or so that we could even run useful dual stack, so we early deployers had two parallel networks for some years. religion has always been more important to the ietf than deployment. look at dhcpv6, the zealots are still stonewalling router discovery. look at the deprecation of nat-pt, now nat64/dns64. it is as if the ipv6 high priesthood did everything in their power to make ipv6 undeployable without very high cost. and they have succeeded admirably. so today, since the costs of ipv6 incompatibility and lack of feature parity are still high, for some folk it is easier to deploy nat4. what a win for the internet. congratulations. randy /rant But, this pig too shall fly Cb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. With Realm Specific IP [RFC3102]: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. what is necessary are minor modification on IPv4/transport stack of new (but not existing) hosts and minor extension of DHCP. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote: Martin, On Feb 14, 2012, at 2:45 PM, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. These if we had only done foo discussions all miss the biggest deployment factor. I disagree with that. With things that take considerable effort to develop and deploy, any sane business or agency would do a cost/benefit analysis, and not deploy unless they can see how it pays off. Smaller projects sometimes go under the radar. Maybe the cost-benefit analysis says it's not worth doing a cost-benefit analysis. When investment is low, people do things even without assurances that those would in fact be needed. I'll leave example from our employer out of this thread. If adding support for the next IP version in products was easy (say, 1-2 man-years for an OS, and 1-2 man months for an application), then Windows XP, Mac OS 10.1 and whatever Linux was running at the time and Solaris 2.9 would have had the support, and applications would follow quickly, long before IPv4 addresses became scarce. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
