Re: US DoD and IPv6
I said that it seems to have been the original marketing pitch, not that it was a good one or that it was going to add security. That was when almost all of us (myself included) were going through our 'cryptography makes everything secure phase'. On Wed, Oct 13, 2010 at 4:27 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2010-10-13 12:46, Phillip Hallam-Baker wrote: The original idea seems to have been that IPSEC would be a big enough incentive to upgrade. I've been keeping out of this conversation because I have other things to do, like working on effective technologies for v4/v6 coexistence, but I have to protest at this version of the IPv6 is more secure myth. I don't think anybody ever advanced this as a serious technical incentive. What was always pointed out is that IPv6 use of IPsec doesn't have to deal with NAT traversal, which was an issue for IPv4 use of IPsec, until RFC 3948 came along in 2005. Since then, even the weak form of the more secure myth has been indefensible. I am of course discounting bogus marketing arguments. Brian -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER d...@dcrocker.netmailto:d...@dcrocker.net wrote: On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. snip Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice. Mere exhortations from the great and the good have very limited effect. The elephant in the room which this discussion hasn't considered is Why would a widget maker want to spend money, thereby reducing their bottom line, to upgrade their network to IPv6? Applying traditional business risk/reward analysis, is there even one real *business advantage* to justify such an expense? If there isn't any, then IPv6 would only rationally be deployed by such an end user if it were both transparent and free. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
I would hope that a practical benefit of IPv6 would be improved performance as a result of support for large packets. That said, I expect to be disappointed. I had really hoped that IEEE would have made support for jumbo frames an absolute requirement for all gigabit ethernet. But no, its an option so we missed out on that opportunity. On Tue, Oct 12, 2010 at 11:24 AM, Fleischman, Eric eric.fleisch...@boeing.com wrote: On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER d...@dcrocker.netwrote: On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. snip Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice. Mere exhortations from the great and the good have very limited effect. The elephant in the room which this discussion hasn't considered is Why would a widget maker want to spend money, thereby reducing their bottom line, to upgrade their network to IPv6? Applying traditional business risk/reward analysis, is there even one real *business advantage* to justify such an expense? If there isn't any, then IPv6 would only rationally be deployed by such an end user if it were both transparent and free. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
When the big dig was going on in Boston, an entire interchange had to be constructed was used for some years and then torn down again. The cost of the interchange was in the high tens of millions of dollars. On Tue, Oct 12, 2010 at 3:13 PM, Dave CROCKER d...@dcrocker.net wrote: Perhaps beating a horse that has long left the gate, since I'm responding to a note earlier than the one I already responded to... But this issue really needs to be settled carefully, IMO, and the modern renditions about this period of time are typically off the mark: On 10/8/2010 6:47 AM, Steve Crocker wrote: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. Bob Hinden and I chaired a working group that was answering your question BEFORE IPv6 was adopted and while there were a number of very different proposals. The community chose to drop the work and ignore the issue for 10 or 15 years. It happens that Deering's proposal came out of participation in our working group, muttering something like all this transition stuff is fine, but when it's done, what we'll be left with will be ugly. So he designed his elegant IP enhancement. One bit of work that came out of the group was IPAE. More generally, it's interesting to review documents of the competing proposals and note quite a few references to transition: http://www.sobco.com/ipng/internet-drafts/index.html My point, here, is that the failures here were ones of goals, priorities and management, not technology. Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
The original idea seems to have been that IPSEC would be a big enough incentive to upgrade. Since then IPSEC has been separated out and we have discovered that packet layer security is not nearly so useful as transport layer. Back in PARC there was a think called error 33: building research on research. Tying deployment of necessary functionality to unrelated infrastructure projects has not had a good success record. On Tue, Oct 12, 2010 at 4:08 PM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: From: Dave CROCKER d...@dcrocker.net On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better The community got ambitious It's interesting that you should say this, because I've always been critical of IPv6 because, IMO, it wasn't _ambitious enough_ - in fact, I think that was a big factor in something you raised in a later message: Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. The lack of market incentives is, IMO, intimately connected to the lack of new functionality - functionality which would have meant a more ambitious design. However, on thinking about this, I think there is a way to reconcile your 'too ambitious' and my 'not ambitious enough' - and it's a way that provides what I think is an important insight. I think you're right in a way about the 'too ambitious', in the sense that the plan supposed not an incremental, interoperable evolvement of IPv4 (such as the ones you mentioned with all this transition stuff is fine, but when it's done, what we'll be left with will be ugly), but spent most of its technical energy thinking about a 'clean slate' design; in a way, one could say it was too ambitious in the 'engineering details', as it were. At the same time, I think I'm right in a way about the 'not ambitious enough', in the sense that the plan supposed pretty much the same architecture as IPv4; in short, one could say it was not ambitious enough in the 'architectural big picture'. So, if people will forgive me, I think one can play on one of Jon's favourite quotations, and say that when contemplating the evolution of a very-large-scale communication network, one should 'be conservative in ones engineering details, and liberal in one's architectural vision'. The 'conservative in the engineering details' means that interoperability and evolution will be maximized, which will minimize adoption barriers; and the 'liberal in architectural vision' will maximize incentives - thereby giving one the best possible change of overcoming the adoption barriers which have so hampered deployment of the stuff currently being discussed. smacked of the overreaching that is often called second system syndrome From: Marshall Eubanks t...@americafree.tv Was it second system syndrome I think it's useful to remember that if one looks at the original source of the 'second system syndrome', Mythical Man Month by Brooks, it ends the discussion of 'second system syndrome' with the following observation: The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions. I will leave it to readers to gauge if, and how much, this applies to our current situation. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 2010-10-13 12:46, Phillip Hallam-Baker wrote: The original idea seems to have been that IPSEC would be a big enough incentive to upgrade. I've been keeping out of this conversation because I have other things to do, like working on effective technologies for v4/v6 coexistence, but I have to protest at this version of the IPv6 is more secure myth. I don't think anybody ever advanced this as a serious technical incentive. What was always pointed out is that IPv6 use of IPsec doesn't have to deal with NAT traversal, which was an issue for IPv4 use of IPsec, until RFC 3948 came along in 2005. Since then, even the weak form of the more secure myth has been indefensible. I am of course discounting bogus marketing arguments. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/13/2010 4:27 PM, Brian E Carpenter wrote: I have to protest at this version of the IPv6 is more secure myth. I don't think anybody ever advanced this as a serious technical incentive. I heard the most august Howard Schmidt make a simple and direct claim that it was, a few years back. I asked him about it privately and got an answer that mostly was of the form it's a new chance to look at security issues. This, of course, had nothing to do with the sort of assertion he had made. v6 has regularly been sold with promises for all sorts of things it was not designed to deliver. While it's never possible to ensure that this sort of thing never happens, the v6 effort really did not work very hard at producing and delivering a clear message of the problems it /would/ solve. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Phillip Hallam-Baker wrote: I would hope that a practical benefit of IPv6 would be improved performance as a result of support for large packets. That is, like almost all the other ambitiously extended functionality of IPv6, an illusion. I had really hoped that IEEE would have made support for jumbo frames an absolute requirement for all gigabit ethernet. But no, its an option so I'm not sure what is an option, as maxUntaggedFrameSize of Ethernet is 1518B without any option, though larger frames are not actively prohibited. I'm not sure what jumbo frames mean, as 9KB frames which is available also to IPv4. But, if you are talking about jumbograms, which is larger than 64KB, which is IPv6 specific, they are useless. While some computers (vector super computers, especially) are slow to react on interrupts and context switching to receive packets, which was the motivation to introduce jumbograms, such computers have I/O subsystem, which can take care of TCP without bothering main CPUs. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Brian E Carpenter wrote: What was always pointed out is that IPv6 use of IPsec doesn't have to deal with NAT traversal, which was an issue for IPv4 use of IPsec, It should be noted that IPsec, including AH, works transparently over port restricted IP, including end to end NAT, if a 4B SPI is used as a 2B source and a 2B destination port numbers. until RFC 3948 came along in 2005. Since then, even the weak form of the more secure myth has been indefensible. IP over TCP is a more robust kludge for legacy NAT. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER d...@dcrocker.net wrote: On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. [other good stuff I mostly agree with deleted] The problem is not merely marketing in the sense of messaging. The problem with each one of the stalled IETF infrastructure upgrades is deployment deadlock. Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice. Mere exhortations from the great and the good have very limited effect. Specifically, with the IPv6 upgrade we need to catalog each of the stakeholders that have to upgrade their gear and work out a unilateral deployment incentive for each one in turn. Whenever I try to propose this sort of thing to conferences the referees always kick the papers back saying that it is 'obvious'. Well if it is so damn obvious, how come we don't seem to be able to manage to do it? I think it is a fairly obvious consequence of a rational choice model. Assume that each actor is not going to budge unless there is a short term benefit to themselves for changing behavior. Now I agree that there are major differences between the way the world really works and the axioms of rat choice modeling. But they certainly work as models in cases where there is a strong positive feedback loop (network effect). What I want as a consumer is a box that enables me to do things like peer to peer video chat efficiently and without all my traffic going in and out of some peer to peer network whose real function is no more than NAT bypass. Trying to tie functionality to the flavor of network I am on is a losing proposition for me. I only have one broadband provider in my area at the moment and they know it. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Perhaps beating a horse that has long left the gate, since I'm responding to a note earlier than the one I already responded to... But this issue really needs to be settled carefully, IMO, and the modern renditions about this period of time are typically off the mark: On 10/8/2010 6:47 AM, Steve Crocker wrote: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. Bob Hinden and I chaired a working group that was answering your question BEFORE IPv6 was adopted and while there were a number of very different proposals. The community chose to drop the work and ignore the issue for 10 or 15 years. It happens that Deering's proposal came out of participation in our working group, muttering something like all this transition stuff is fine, but when it's done, what we'll be left with will be ugly. So he designed his elegant IP enhancement. One bit of work that came out of the group was IPAE. More generally, it's interesting to review documents of the competing proposals and note quite a few references to transition: http://www.sobco.com/ipng/internet-drafts/index.html My point, here, is that the failures here were ones of goals, priorities and management, not technology. Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: Dave CROCKER d...@dcrocker.net On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better The community got ambitious It's interesting that you should say this, because I've always been critical of IPv6 because, IMO, it wasn't _ambitious enough_ - in fact, I think that was a big factor in something you raised in a later message: Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. The lack of market incentives is, IMO, intimately connected to the lack of new functionality - functionality which would have meant a more ambitious design. However, on thinking about this, I think there is a way to reconcile your 'too ambitious' and my 'not ambitious enough' - and it's a way that provides what I think is an important insight. I think you're right in a way about the 'too ambitious', in the sense that the plan supposed not an incremental, interoperable evolvement of IPv4 (such as the ones you mentioned with all this transition stuff is fine, but when it's done, what we'll be left with will be ugly), but spent most of its technical energy thinking about a 'clean slate' design; in a way, one could say it was too ambitious in the 'engineering details', as it were. At the same time, I think I'm right in a way about the 'not ambitious enough', in the sense that the plan supposed pretty much the same architecture as IPv4; in short, one could say it was not ambitious enough in the 'architectural big picture'. So, if people will forgive me, I think one can play on one of Jon's favourite quotations, and say that when contemplating the evolution of a very-large-scale communication network, one should 'be conservative in ones engineering details, and liberal in one's architectural vision'. The 'conservative in the engineering details' means that interoperability and evolution will be maximized, which will minimize adoption barriers; and the 'liberal in architectural vision' will maximize incentives - thereby giving one the best possible change of overcoming the adoption barriers which have so hampered deployment of the stuff currently being discussed. smacked of the overreaching that is often called second system syndrome From: Marshall Eubanks t...@americafree.tv Was it second system syndrome I think it's useful to remember that if one looks at the original source of the 'second system syndrome', Mythical Man Month by Brooks, it ends the discussion of 'second system syndrome' with the following observation: The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions. I will leave it to readers to gauge if, and how much, this applies to our current situation. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 12, 2010, at 3:13 PM, Dave CROCKER wrote: Bob Hinden and I chaired a working group that was answering your question BEFORE IPv6 was adopted and while there were a number of very different proposals. The community chose to drop the work and ignore the issue for 10 or 15 years. It happens that Deering's proposal came out of participation in our working group, muttering something like all this transition stuff is fine, but when it's done, what we'll be left with will be ugly. So he designed his elegant IP enhancement. One bit of work that came out of the group was IPAE. More generally, it's interesting to review documents of the competing proposals and note quite a few references to transition: http://www.sobco.com/ipng/internet-drafts/index.html My point, here, is that the failures here were ones of goals, priorities and management, not technology. Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. Or people cared more about making the end result right (for some meaning of right) than about how to get there. (which is pretty close to the definition of second system effect.) There are a lot of things I didn't/don't like about HTTP, but I had to admit that early versions (especially 0.9 and 1.0) were optimized for deployability. Say what you will about its quality, efficiency, robustness, etc., but it's certainly been successful from an evolutionary perspective. HTTP 1.1 tried to fix a lot of the omissions in 1.0, and was partially successful, but it would never have succeeded as an initial version. I also remember that the current Internet email system evolved from a hodgepodge of dissimilar systems, first by most of those systems adopting (more-or-less) a common message format (at least for external traffic), then by MX records providing a way to tie all of those dissimilar systems into a common addressing framework, then (finally) by widespread adoption of IP and SMTP. At each step there were incentives to local adoption. RFC 822 headers gave systems a more flexible way to represent message metadata (especially with things like Reply-To), MX records solved the problem of how to route traffic between the Internet and mail domains not connected via IP, and moving to SMTP provided faster and more-reliable service. I've often wondered whether we could have used something like IPAE as a stepping-stone to something like SIPP (which evolved into IPv6). Especially since, in hindsight, it turned out to be much easier to get the host support for IPv6, and even support for IPv6 in major applications, than to get the networks upgraded. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Phillip Hallam-Baker wrote: The problem is not merely marketing in the sense of messaging. The problem with each one of the stalled IETF infrastructure upgrades is deployment deadlock. Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice. Mere exhortations from the great and the good have very limited effect. It's interesting to note that, with monopoly by telco, deployment of ITU standards was almost automatic. However, on the Internet with full competitive backbone and the end to end principle, upgrading has been occurring from the end. For example, ftp servers and clients are upgraded to web servers and clients at the ends without any changes to the backbone. Subnetting was an issue within end sites. NAT is another example. What I want as a consumer is a box that enables me to do things like peer to peer video chat efficiently and without all my traffic going in and out of some peer to peer network whose real function is no more than NAT bypass. Upgrading NAT boxes in consumer houses and edge ISPs by end to end NAT gives you the environment you want. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Noel Chiappa wrote: The lack of market incentives is, IMO, intimately connected to the lack of new functionality - functionality which would have meant a more ambitious design. IPv6 and Neighbor Discovery were designed so ambitiously that they have so much new functionality. The problem is that the added functionality does not function as expected, is not required by the market and is rather harmful than useless. Examples are 16B addresses, unlimited optional headers, path MTU discovery, support for NBMA (ATM) networks, stateless auto configuration and flow. So, how can you say more ambitious? but spent most of its technical energy thinking about a 'clean slate' design; in a way, one could say it was too ambitious in the 'engineering details', as it were. Using a clean slate is of no help when you write much more than what was already written on a scribbled slate. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/12/2010 4:08 PM, Noel Chiappa wrote: The community got ambitious It's interesting that you should say this, because I've always been critical of IPv6 because, IMO, it wasn't _ambitious enough_ - I didn't say creative. I didn't say it targeted a new paradigm. I merely meant that it tried to attack more than the problem at hand. And I didn't say it did that well. By the same token, one can and I believe should note that those insisting that a new paradigm be used were given a 15 year window of opportunity and didn't seem to pursue it very much... Quite simply, we did not pay attention to larger issues such as market incentives and adoption barriers. The lack of market incentives is, IMO, intimately connected to the lack of new functionality - functionality which would have meant a more ambitious design. yup. however note that companies successfully market products that have no interesting new features... I think you're right in a way about the 'too ambitious', in the sense that the plan supposed not an incremental, interoperable evolvement of IPv4 (such as the ones you mentioned with all this transition stuff is fine, but when it's done, what we'll be left with will be ugly), but spent most of its technical energy thinking about a 'clean slate' design; in a way, one could say it was too ambitious in the 'engineering details', as it were. ack. At the same time, I think I'm right in a way about the 'not ambitious enough', in the sense that the plan supposed pretty much the same architecture as IPv4; in short, one could say it was not ambitious enough in the 'architectural big picture'. there was no mandate to create a new architecture. to adopt a new architecture would have required making an extremely compelling case, with more detail and demonstration. and although the formal choice was made early, the actual failure to deliver 'product' provided a 15-year window, as I said. Please note that OSI also was committed to early and also failed to deliver... and was replaced by an alternative that /did/ deliver. So we have a nice example that this later adoption of a better alternative was feasible. So, if people will forgive me, I think one can play on one of Jon's favourite quotations, and say that when contemplating the evolution of a very-large-scale communication network, one should 'be conservative in ones engineering details, and liberal in one's architectural vision'. ... but not necessarily at the same time. incremental evolution is a fine and valid and efficient path. changing architectural paradigms is massively traumatic and, therefore, needs a more compelling incentive. The 'conservative in the engineering details' means that interoperability and evolution will be maximized, which will minimize adoption barriers; and the 'liberal in architectural vision' will maximize incentives - thereby giving one the best possible change of overcoming the adoption barriers which have so hampered deployment of the stuff currently being discussed. sounds about right to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Dave CROCKER wrote: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. That is an option because, with port restricted IP, we have enough time for the transition. That is, there is no reason to insist on deploying IPv6 with 16B addresses when SIP with 8B address will do. However, original SIP is unnecessarily combined with Steve's other proposals and is still too complex. For example, considering that his favorite PMTUD does not really work elegantly to detect increase of PMTU, minimum MTU should be increased without PMTUD or reserved header field should be used to record the current PMTU to be modified at each hop. His favorite multicast should be purely optional because broadcast is a lot simpler. Flow ID for his favorite RSVP is unnecessary, because QoS capable L2s have its own label. There may be other simplifications possible. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/2010 3:44 PM, Steve Crocker wrote: Mebbe. I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control. Alas... Along with the imposition of ASN.1's complexities as the MIB format, for compatibility between the competing network management protocols (SNMP and CMOT), IPv6 was an early demonstration of the problems that accrue from treating technical design as a political process, trying to accommodate too many factions. Such accommodations seem to rarely provide the long-term benefit that is intended, but instead consistently add complexity and limitations. Politicized technical processes rarely allow good folk to adequately have things in control. (I'm sure that your experiences on the ICANN Board and its SSAC have not disclosed this unexpected fact of life to you yet, so I thought it worth pointing out.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. No matter how elegant it is technically, without a benefit for deployment there is no way to get past very small scale deployment (some folks will deploy anything to see if it has value, but most won't.) That is one of the main stumbling blocks that Noel reported publicly for getting Nimrod off the ground separately from the IPv6 effort. The operators who had to deploy it did not gain anything. As long as our path is one of minimal change, we were inherently locked in to a behavioral set that matched Ipv4. that is what SIP proposed. That is what IPv6 gave us. For any proposal to work, there has to be a benefit to folks to use it. Even before it is ubiquitous. As far as I can tell, we ignored that question during the 1993-1999 period when we should have been working on it. We also get ourselves into a mind set of we need an answer now. There is no time to do technically hard work. That was a bad call. 5 extra years spend=t serously working on what the needs were, what the deployments could be, and what the technology could look like, might have given us a better path. (No, there is no guarantee. We could have blown it anyway.) Yours, Joel M. Halpern On 10/10/2010 6:41 PM, Dave CROCKER wrote: On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. The only counter I will make -- and it is not an attempt to contradict your point -- is that the adoption barrier for the scheme I described is minuscule, when compared with the full, incompatible, dual-stack scheme that we've pursued. Most of the software could be shared between v4 and the simplified v6 I described, and initially most of the operations procedures could be shared. And router products could have been enhanced to include the translation pretty easily. Again, none of this contradicts the lack of an attractive value proposition for adopters. But it could have made incremental adoption much cheaper and simpler and could have started it much sooner. As long as our path is one of minimal change, we were inherently locked in to a behavioral set that matched Ipv4. that is what SIP proposed. That is what IPv6 gave us. The current IPv6 is not minimal change. It is an entirely incompatible dual stack model. That really is fundamentally different from what I described, which was actually a clean upgrade to the existing system and would have remained entirely compatible with it, semantically, when initially deployed. For any proposal to work, there has to be a benefit to folks to use it. Even before it is ubiquitous. As far as I can tell, we ignored that question during the 1993-1999 period when we should have been working on it. Yup. The motivating requirement was address space, but address space is not functional enhancement, in terms of marketing to adopters. Fixing address space, for most folk, would have been an overhead expense. We also get ourselves into a mind set of we need an answer now. There is no time to do technically hard work. That was a bad call. 5 extra years spend=t serously working on what the needs were, what the deployments could be, and what the technology could look like, might have given us a better path. (No, there is no guarantee. We could have blown it anyway.) Probably not. If we were going to be blown away, there turned out to be plenty of time for that to have developed. One could argue that those likely to pursue that path of innovation were discouraged from it, but I think it more likely that the spiffy, mind-blowing enhancement is still eluding folk. So we are left with the ideal alternative of an unrealized, unspecified, superior choice, versus the concrete, flawed path we went down. The former always looks better, since it is not constrained by the real world. FWIW, when work seriously began, in the early/mid 90s, we were already turning down legitimate requests, such as from the electricity folks (EPRI). Instead we chose to focus on global exhaustion rather than individual denial. That was the real mistake. There really was urgency back then and we convinced ourselves there wasn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Mebbe. I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control. Steve On Oct 10, 2010, at 6:41 PM, Dave CROCKER wrote: On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/2010 3:44 PM, Steve Crocker wrote: Mebbe. I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control. Alas... Along with the imposition of ASN.1's complexities as the MIB format, for compatibility between the competing network management protocols (SNMP and CMOT), IPv6 was an early demonstration of the problems that accrue from treating technical design as a political process, trying to accommodate too many factions. Such accommodations seem to rarely provide the long-term benefit that is intended, but instead consistently add complexity and limitations. Politicized technical processes rarely allow good folk to adequately have things in control. (I'm sure that your experiences on the ICANN Board and its SSAC have not disclosed this unexpected fact of life to you yet, so I thought it worth pointing out.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 10/10/10 4:02 PM, Dave CROCKER wrote: On 10/10/2010 3:44 PM, Steve Crocker wrote: Mebbe. I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control. Alas... Along with the imposition of ASN.1's complexities as the MIB format, for compatibility between the competing network management protocols (SNMP and CMOT), IPv6 was an early demonstration of the problems that accrue from treating technical design as a political process, trying to accommodate too many factions. Such accommodations seem to rarely provide the long-term benefit that is intended, but instead consistently add complexity and limitations. Politicized technical processes rarely allow good folk to adequately have things in control. The difference with ipv4 address length being mainly that at the end of the day the darpa program manager could say, stop your bickering we're doing it this way. I'm reminded of Churchill, Democracy is the worst form of government, except for all those other forms that have been tried from time to time. while that's not our process, I think it's a bit presumptuous to suppose that some other organizational construct might produce a different, and presumed better result. By the time this thread is done perhaps the axes will have been ground down to nubs. (I'm sure that your experiences on the ICANN Board and its SSAC have not disclosed this unexpected fact of life to you yet, so I thought it worth pointing out.) d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 10, 2010, at 7:02 PM, Dave CROCKER wrote: On 10/10/2010 2:51 PM, Steve Crocker wrote: A compatible solution would have been better, but I don't think IPv4... -- were designed in a way that permitted a compatible extension. Oh? Perhaps: 1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed. 2. Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits. (In other words, defer more interesting schemes until later.) 3. Design header translation devices to map between the two formats. 4. Start fielding these implementations. (That could have started by 1994 or so.) The gateways between v4 and v6 would initially be notably for having almost no work to do and of not losing any information. In particular, barely qualifies as a dual stack. With this approach, incompatibility between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned. We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design. The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...) Dear Dave; Not being directly involved at the time, I have always wondered this : Was it second system syndrome, or was a slowness to realize that the time to drastically change the system increased from months to (effective) infinity somewhere between 1988 and 1994 ? Regards Marshall d/ [1] http://tools.ietf.org/html/draft-deering-sip-00 -- 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: US DoD and IPv6
On 10/10/2010 4:45 PM, Marshall Eubanks wrote: Was it second system syndrome, or was a slowness to realize that the time to drastically change the system increased from months to (effective) infinity somewhere between 1988 and 1994 ? In fact, it was /too much/ realization of likely deployment time. That is, there was an ingrained belief that this one be the last time that things under the hood would get to be revised for many years. Hence the belief that it was important to stuff in as many changes as possible... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
The referral problem he refers to is real, but I see it more as a consequence of the IETF being too rigid in its approach to address numbering. How would changing IETF's approach to address numbering help the referral problem? The basic question here is that we have two hosts that are to connect for a peer-peer protocol in which either endpoint can initiate or respond to a connection request. Clearly this is rather challenging if the boundaries between addressing schemes are arbitrary and becomes somewhat simpler in a uniform addressing model. But the real Internet is not like that. It is a network of networks and crossing the boundary between a private network and the interconnect space between the networks has consequences. One of those consequences is that addresses can change at the private/interconnect border. Another consequence is that crossing that boundary should have security consequences. In the real Internet, the boundary between a private network and the interconnect space is fuzzy and arbitrary, especially from a security point-of-view, and becoming moreso all the time. Opening up a port to receive connection requests has considerably greater security consequence than making the request. The requester is opening a communication channel with a single, specified entity, the responder is opening access to any host on the Internet. And far better mechanisms than opening up a port are feasible even within the classic Internet architecture. If the industry hasn't provided them, that's not the fault of the architecture. So opening a port is an event that should be mediated by access control at the host level and private/interconnect border at a minimum. In a default deny network there will be additional policy enforcement within the private network. There's a fundamental problem in that people have come to expect that somehow the network is responsible for keeping hosts secure from attack. Again, that's not the fault of the architecture. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: Keith Moore mo...@network-heretics.com
What doesn't work well is to have everyone decide for himself how to
change the architecture.
The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).
With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen. Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with. It also means accepting that we have multiple naming domains at
the end-end level, and will for the forseeable future; and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Let me say this more strongly. These two defects, it wasn't economically
feasible ... and it didn't offer any interesting/desirable new capabilities
were mild compared to an even bigger defect: There simply wasn't a technically
feasible plan on the table for co-existence and intercommunication of IPv4 and
IPv6 networks.
In addition to working our way through the IPv6 adoption and co-existence
process, I think it would be useful to do a little soul-searching and ask
ourselves if we're so smart, how come we couldn't design a next generation IP
protocol and work out a technically viable adoption and co-existence strategy.
The dual stack approach implicitly assumed everyone would have both an IPv6
and an IPv4 address. If everyone has both kinds of addresses, that implicitly
asserts there's no visible shortage of IPv4 addresses, which is contrary to
fundamental reason IPv6 is needed. Further, although some scenarios suggest
IPv4 usage will start to decline steeply once IPv6 transport, products and
services are widely available, the safer bet is that IPv4 networks will persist
for a fairly long time, say 20 to 50 years.
Steve
On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:
From: Keith Moore mo...@network-heretics.com
What doesn't work well is to have everyone decide for himself how to
change the architecture.
The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).
With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen. Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with. It also means accepting that we have multiple naming domains at
the end-end level, and will for the forseeable future; and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
Noel
___
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: US DoD and IPv6
Phillip Hallam-Baker hal...@gmail.com wrote: Since the one legacy protocol that has a dependency on IP address constancy is FTP, it would seem to me to be much easier to upgrade FTP to remove the dependency than to try to control the network. There are other protocols hiding out there. MATIP, RFC2351 (not from the IETF, obviously), allows either endpoint to send a session-open setting some paramaters for the session, and to confirm the session-open from the other side. So if both sides send session-open, they're both supposed to ignore the session opened by the endpoint with the lower-numbered IP. In practice, what this seems to mean is that sometimes when you set up new links, MATIP doesn't work, you get on the phone with the admins at the other side, and you agree which one of you will send the session open. Then you configure one endpoint never to send it. The RFC was published in 1998, though I don't know when they actually came up with the protocol. Its use is, I think, still increasing, as more airline industry links are set up over TCP/IP networks. I wouldn't have known about MATIP if I hadn't gotten a job related to airline industry networking, and I'm sure there are other naive protocols out there, designed by people or groups who were not that familiar with the way of the Internet and do protocols their own ways. [MATIP has a host of other problems that I won't mention :) ] -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
any design for architecural change (e.g. introducing separation of location and identity) is going to be somewhat ugly, because we don't have a clean sheet of paper to work with. Location independent identifiers can be introduced at the transport or application layer, without having to change the network infrastructure. There is nothing to prevent researchers or application developers to design a transport that sits on top of IPv4/IPv6, or even on top of UDP, and manage location independent identifiers. This is the classic overlay play, at the end of which IPv6/IPv4 addresses, or address+port pairs, are redefined as mere lcators. Obviously, this only works for new applications, or new application releases. But if application developers really believe they will benefit from the split, they can do it. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
--On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
And our friends at the ITU are standing by ready to help us too :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Fri, 8 Oct 2010, John C Klensin wrote: --On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ 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: US DoD and IPv6
On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote: From: Keith Moore mo...@network-heretics.com What doesn't work well is to have everyone decide for himself how to change the architecture. The reason we have/had a free-for-all on the architectural front is that the IETF's choice for architectural direction (15 years ago) was non-viable (i.e. wrong); it wasn't economically feasible (in terms of providing economic benefits to early adopters, or otherwise having an economically viable deployment plan), and it didn't offer any interesting/desirable new capabilities (which was a big factor in the former). In hindsight, I suspect IETF could have made a better choice for IPv6. Or even accepting the basic IPv6 approach that we ended up with, slight changes to some of the details might have made a big difference. And it's worthwhile to try to learn lessons from that choice and the consequences. However, I don't see how it's constructive to say that the choice was wrong. There is today an increasingly widespread realization that the worldwide deployment of IPv6 is a better path forward than any of the likely alternatives. That doesn't mean it's the best possible path forward, of course. But as we're both painfully aware, having a better idea isn't sufficient. A necessary condition for success is to get widespread buyin to the idea. For better or worse, IPv6 is still the only semi-viable long-term strategy that has anything like widespread buyin. With an 'approved direction' that didn't work, having people go off in their own directions instead was an inevitable corollary. Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. The problem was that the 'approved direction' was wrong, it was that in many important spaces for both IPv4 and IPv6, there was no approved direction - only a hodgepodge of half-baked hacks that didn't fit together well. Which is why I am urging the IETF to be _realistic_ now, and accept the world as it actually is, and set direction from here on out based on that, and not on what we wish would happen. Sigh. Anytime someone makes an appeal to accept reality I wish a (small) brick would fall on his head. That's exactly the same kind of argument that was made in the late 1990s within IESG as to why IETF could not do anything to make NATs predictable to applications. But for what it's worth, I do share your assumption that we don't have the luxury of working from a clean sheet design. And I agree that at least in the near term it's going to be ugly. But I think the goal should be to facilitate a transition to a world that's less ugly, or at least more functional. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. There's nothing the IETF could, or even should, have done to avoid this, and FWIW, the ISPs got terribly upset with you for using NATs at the time, and given the very few implementations (Linux IP Masq, for instance), some were able to detect and filter. As NATs moved from Linux IP Masq into the mainstream, though, ISPs simply took advantage of this - it meant that there was no configration distinction between a single user and a network - and that's a useful property. In hindsight, this would have been a good time for the IETF to step in and try to address the actual problem, but unfortunately consumer networking has never been a strong point of the IETF - I think largely because few of the stakeholders are average internet users for obvious reasons. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote: On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Of course there is, but I was trying to be brief. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. But part of that was because single-address-per-customer (or dialin session) was naturally a commodity service, while routing a block down a modem was something that required special-case handling at the ISP. And I think it's fair to say that that was the assumption in IETF also. I don't recall any efforts toward autoconfiguration of networks then, particularly not for those connected via point-to-point links. It's hard to not blame the ISPs for wanting to charge differently for one-address dialin vs. other accounts that required more customization, setup, and support on their part. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) Not sure what you mean by a CIDR DNS RR, but I hope it's nothing like A6 / DPTR was. There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. And there's always considerable pressure on and within IETF to just embrace NAT for this. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. But the NATs are good mentality would still be widespread.Old timers hate to learn how to use new tools, even if the old tools are crap. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Architecture (was US DoD and IPv6)
{'Borrowing' a new, more appropriate Subject: from a private reply...}
From: John C Klensin john-i...@jck.com
What does this say about the IETF and how we make decisions? Does that
need adjusting?
Perhaps, but even I shrink from tackling that particular windmill!
while ... recriminations based on hindsight may be satisfying in some
ways, the question is what to do going forward.
I couldn't agree with your latter point more.
There are communities out there who believe that we have managed to
prove that datagram networks, with packet-level routing, are a
failure at scale and that we should be going back to an essentially
connection-oriented design at the network level.
I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet
architecture was never intended to grow to this size, and that it has done so
at all (albeit via the use of a number of hacks, some merely kludgy, others
downright ugly) is a testament to how well the basic concept (of unreliable
packets, and minimal state in the network) works.
I do think that the architecture does require some work, though, and for a
number of reasons. For one, the real requirements have become more complex as
the network has grown, and a number that have arrived (e.g. provider
independence for users; the need for ISP's to be able to manage traffic
flows; etc) aren't really handled well (or at all) by the existing
architecture. For another, we need to bring some order to the cancerous chaos
that has resulted from piecemeal attempts to deal with the previous point.
Finally, it's a truism of system design that arrangements that work at one
order of scale don't at another, and as the network has grown beyond almost
our wildest expectations - and certainly larger than it was ever designed to
- I think we're seeing that too.
If not, then there are other focused discussions that would be helpful.
The latter discussions that have almost started in this and related
threads, but have (I believe) gotten drowned out by the noise, personal
accusations about fault, and general finger-pointing.
Well, sometimes one has to clear the air (or underbrush, if you will), and
get everyone's minds open, before one can make forward progress. But I agree,
'hah-hah, your end of the ship is sinking' rapidly becomes totally
unproductive.
How would you propose moving forward?
Well, IMO there are a number of things we need to do, which can be done all
in parallel.
The first is to be honest with ourselves, and with the people out there who
depend on us to set direction, about what's really likely to happen out in
the network; e.g. a very long period during which we are stuck with multiple
naming realms with various kinds of translators (NATxx) gluing them together.
This whole 'don't worry, everything will be fine' schtick has got to go -
we're now in what I call The Emperor's New Protocol land, where (almost)
everybody knows the theoretical plan isn't going to work, and major revisions
are needed, but nobody wants to come right out and say so formally.
We need to do that.
I think a group (set up by the IAB, who make these kind of pronouncements)
should sit down and draw up a _realistic_ picture of what the future over the
next couple of years (say, up to 5 years out - 5 only, because of a second
parallel effort, below) is likely to be, and get that out, so people have a
realistic appraisal of how things stand (and restore a little bit of the I*'s
credibilty, in the process).
That group (or perhaps a sister group) should produce a formal statement
covering the implications for IETF work of that present/future; i.e. about the
_existing_ architectural environment in which the protocols the IETF designs
have to operate, and thus have to be designed for. E.g. a formal IETF policy
statement 'all IETF protocols MUST work through NAT boxes'. Etc, etc.
The second is to set up a group (and again, this is the IAB's job) to try and
plan some sort of evolutionary architectural path, which would have two
phases: i) to survey all classes of stakeholders (ISP's, content providers,
users) to see what the network needs to be able to do that it can't now, and
ii) provide both a) an architecture that meets those needs, and b) a
_realistic_ plan for getting there. Realistic in economic, interoperability,
etc terms - all the things we have learned (painfully) are so critical to the
viable roll-out of new stuff.
Do note that that effort implies that the current solution _doesn't_ provide
all those things. So we might as well swallow hard and admit _that_ publicly
too.
Whether all the above is politically feasible in the current IETF - who knows?
If not, it's back to 'The Emperor's New Protocol' for another year or so, I
guess, by which time the environment may be a bit more receptive.
Noel
___
Ietf mailing list
Ietf@ietf.org
Re: US DoD and IPv6
Noel Chiappa wrote:
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen.
The only realistic approach is to accept IPv4 at least for next
10 or 20 years, which is possible with port restricted IP while
keeping the end to end transparency.
Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with.
ID locator separation is not essential. All we need is an architecture
to handle multiple addresses (which may be raw addresses or an ID and
multiple locators).
It also means accepting that we have multiple naming domains at
the end-end level,
It means to handle multiple IP addresses.
and will for the forseeable future;
It means to handle multiple IPv4 addresses.
and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
The basic architectural problem so many people want to ignore
is that IP is connectionless, which means there is no time out
at the IP layer to know some address is not working.
As a result, there are a lot of wrong proposals seen in multi6
WG, which declare TCP connections are dead merely because
no traffic is observed for a while, which is no different from
poor legacy NAT violating the end to end principle.
Interestingly enough, IPv6 failed partly because its neighbor
discovery has introduced a lot of time out at the IP layer,
which is architecturally wrong (in this case, timing depends
on link layers). Requirements on RtrAdvInterval was finally
loosened in RFC3775 (MIPv6) but rest remains.
Once it is recognized that the problem of multiple addresses can
be solve only at (in case of TCP) or above (in case of UDP) the
transport layer, the solution is easy and straight forward.
Details are documented in draft-ohta-e2e-multihoming-00.txt
in Apr. 2000.
Though my experimental implementation is in IPv6 with ID/locator
separation, same is doable with (port restricted) IPv4.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 8, 2010, at 10:49 AM, John C Klensin wrote: --On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. I think that many, perhaps most, of the people who believe that would believe it regardless of the facts on the ground. Regards Marshall If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ 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: Internet Architecture (was US DoD and IPv6)
From: Dave Cridland d...@cridland.net So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. Even assuming we could provide 1-3 above in some way (which I am somewhat dubious about), I would have to say 'I don't think so' to your conclusion - because I think your list is incomplete. The Internet as actually deployed depends crucially on having a number of disjoint low-level naming realms - which necessitate NAT boxes between them. For one, my understanding of the current plan for interoperability between IPv6 devices with an IPv6-only address, and 'the' IPv4 Internet, is the 'IPv4/IPv6 Translation' work from BEHAVE, and that's basically NAT. (There was, a long time ago, some proposal for having such IPv6 devices with an IPv6-only address 'share' an IPv4 address, to enable access to 'the' IPv4 Internet, but I guess it never came through.) On that alone, NATs will be with us for decades to come. For another, there are lots of people who have networks behind NAT boxes, for a variety of reasons (maybe they couldn't get the address space, maybe - like all those home wireless networks - it was just easier to do it that way). And there is, for most of them, no economic incentive to change that, to give up their private naming realm. (Sure, there will be a few exceptions, for whome it does make economic sense to get rid of NAT - e.g. large ISPs for whom NAT hacks make life too complex - but there will still be a lot left after that. So unless you have a viable scenario in which disjoint naming realms go away, then you do not have a viable scenario in which NATs go away. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)
On 10/6/2010 10:04 PM, Richard L. Barnes wrote: NEW NON-IETF LIST ANNOUNCEMENT IETF Ad Hominem Discussions This group is dedicated to the discussion of the personal flaws of IETF participants. Such a fertile thread you've created. So much to play with... If I want to say that this new list is a foolish idea and you are being hopelessly naive in creating it -- and thereby I am crossing into ad homimen... or am I -- must I do that on the new list that I disapprove of or should I do it here, where its formation is announced? To the extent that there is a hint of seriousness to my post, I'll merely note that expecting folks to a) acknowledge that they are making an ad hominem, and b) choose to move to another venue is, ummm... a tad idealistic, given the emotions and style that tend to be present in a poster who is making ad hominem comments. So I applaud your goal, but can't imagine its being achieved. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
All true, but based on the information available at the time, I am not sure how a different outcome would have been arrived at. Having a group to make unpopular but right decisions always seems a great idea in hindsight. But there is a real practical difficulty distinguishing such groups form similar groups whose ideas are both unpopular and wrong. The reason the IAB has no authority is that the selection mechanism is designed to ensure that it has no accountability. No accountability means no authority. What you seem to be saying is that the IETF should have made deployment a much higher priority in the design of IPv6. Which is what I have been saying for years. I treat deployment as an engineering problem. I have been constructing models and running simulations to test various approaches to deployment since 1992. I can construct a plausible deployment model for IPv6 based on NAT boxes. But I can't see a plausible model which does not involve NAT44, NAT46 and NAT66 during the transition period and since I am anticipating that lasting around thirty years, I can't see much point in modeling what comes after. On Thu, Oct 7, 2010 at 10:58 AM, Keith Moore mo...@network-heretics.comwrote: On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See, this is the kind of thing I was talking about in my early post in the recent incarnation of this thread. Complaining about the existence of disjoint naming realms, and how it has complicated our lives, is like a rocket scientist complaining about gravity, and how hard it makes their job. (OK, it's not quite a perfect analogy, since gravity is fundamental, but I think my point is clear.) They were inevitable, end of story. No, they were not inevitable, at least not in the long term. Two cases: 1. There were IPng proposals that would have made IPng an extension of IPv4 space, and allowed (at least in the interim) all IPng traffic to be tunneled over IPv4 networks. This understandably made routing people and network operators uneasy as nobody wanted to live with the Class C swamp forever. But in hindsight there were probably other ways of dealing with that problem. And being able to leverage the existing IPv4 network in a general way would have made IPng easier to deploy. (Admittedly, what looked deployable in the early 1990s when these tradeoffs were being discussed is very different from what looks deployable now. In 1991, say, it was much easier to imagine the whole Internet migrating to a new protocol than it was even a couple of years later.) 2. In the late 1990s when it became apparent that NATs were causing problems, IETF had an opportunity to put a stake in the ground. It could have tried to find a way to integrate NATs into an explicit Internet architecture; it could have explained why NATs presented difficult problems for which there were no good solutions; it could have tried to define NAT in such a way as to permit a more graceful migration to IPv6. It failed at all three of these, not because of insurmountable technical difficulties, but because (a) too many people were afraid of alienating NAT vendors, and (b) IAB, the only part of IETF that had any responsibility for architectural direction, had been stripped of its power in the wake of Kobe. In fact, as we should realize by now, IAB's concerns that dictated the Kobe decision were extremely well founded, even if a lot of us (myself included) didn't like the specific choice they made. But as it turned out, we didn't really have enough time to use our normal rough consensus process to specify IPng. All of this is water that has already flowed under the bridge, of course. But I think there is at least one thing that we need to learn from this going forward, and that is that there really is a need for a small group of wise and widely-trusted people to be able to set architectural direction for the internet. And occasionally, they're going to make unpopular decisions. But those are the sort of issues for which a rough consensus process demonstrably does not work. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
[Replying to John, Steve, others] This might sound like a completely off the wall suggestion. But is it possible that we could use an IPv4 extension header to carry the internal address of a NAT-ed host in some way and thus preserve end-to-end addressability? Assume for the sake of argument that we have a secure DNS deployed and that this scheme makes it efficient to publish policy records for protocols. [I have a detailed justification for why this is possible]. Such that when a client attempts to connect to the http protocol for www.example.com it is going to receive back a DNS record chain from its resolver that includes: www.example.com A18.1.1.1 AA 18.1.1.1.10.1.0.0 _http._tcpESRVIP=a+aa+ If the application is going to use the AA record it has to have an IPv4.1 stack. This causes it to emit IPv4 packets where the first four bytes are sent in the IPv4 header and the remaining four bytes are sent as a header option. The NAT box at 18.1.1.1 now has all the information it requires to allow complete transparency in either direction. Clients can connect to a server behind a NAT box provided only that they have a current IP stack. I can even provide a pretty good solution to Brian's mobility/referral problem. Say that there are 256 points of presence, each of which has a distinct IPv4 address. All we need to do is to tell the mobile device when to change its Internet point of presence address. The target need not know that the gateway has been changed. Of course one objection that would be made against this is likely to be that it solves the problem a bit too well and eliminates the need for IPv6 entirely. The other objection is going to be that we are now so far into the deployment of IPv6 that 'it is too late to change'. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Fri Oct 8 17:49:28 2010, Keith Moore wrote: On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote: On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Of course there is, but I was trying to be brief. Oh, sure, but I think the points you glossed over in that effort were more significant that the points you retained. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. But part of that was because single-address-per-customer (or dialin session) was naturally a commodity service, while routing a block down a modem was something that required special-case handling at the ISP. And I think it's fair to say that that was the assumption in IETF also. I don't recall any efforts toward autoconfiguration of networks then, particularly not for those connected via point-to-point links. It's hard to not blame the ISPs for wanting to charge differently for one-address dialin vs. other accounts that required more customization, setup, and support on their part. Absolutely, and I basically stated that later - that's why the ISPs changed from actively trying to supress such usage into actively supporting it, because it meant that network setups became, from their viewpoints, free. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) Not sure what you mean by a CIDR DNS RR, but I hope it's nothing like A6 / DPTR was. In IPv4 terms a DNS RR that meant I could lookup what dave.cridland.net's network was, and get back 217.155.137.156/29, and therefore use the network name instead of the IP addresses in configuration, such as firewalling rules, DHCP server config, etc. I vaguely recall the A6/DPTR combination as being rather more ambitious than that, but really, a search/replace on a zonefile during a renumber is pretty easy. It's the hunting down the network references in router configs and firewall rules that's the pain. There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. And there's always considerable pressure on and within IETF to just embrace NAT for this. Right - it's a vicious circle, too, because we must embrace NAT because no other solution exists, but there's no point developing a better solution because NAT exists. Unfortunately, renumbering still happens even when you're using 10/8, so NAT doesn't answer all the cases. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. But the NATs are good mentality would still be widespread.Old timers hate to learn how to use new tools, even if the old tools are crap. Right, and we need to work around that damage with stuff like BEHAVE, and careful application design. Still, to my mind, I have the feeling that end-to-end addressing could actually be a security and reliability benefit to many peer-to-peer applications (VOIP and IM file transfer being just two that spring to mind), so there could be interest in getting there from here. Moreover, if we tackle the renumbering and automated routing case (and I think the latter is largely done - not my area though) then we've provided the tools for home and enterprise alike to ween themselves off NAT quite effectively. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP,
Re: US DoD and IPv6
On Fri Oct 8 16:14:02 2010, Phillip Hallam-Baker wrote: If the application is going to use the AA record it has to have an IPv4.1 stack. This causes it to emit IPv4 packets where the first four bytes are sent in the IPv4 header and the remaining four bytes are sent as a header option. Can't one then use a DNS lookup which tells it a tunnel endpoint for an IPv6-in-IPv4 tunnel, and provide transparent IPv6 at both ends? This could be implemented entirely at the network edge, eliminating the need for special stacks at the endpoints. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)
Yes, please, stop immediately this thread (at least the personal way it is
going on) or I will be forced as sergeant-at-arms to remove the participants
from the IETF mail exploder.
Regards,
Jordi
From: Richard L. Barnes rbar...@bbn.com
Reply-To: rbar...@bbn.com
Date: Wed, 6 Oct 2010 22:04:46 -0700
To: Michel Py mic...@arneill-py.sacramento.ca.us
Cc: ietf@ietf.org, Keith Moore mo...@network-heretics.com, Noel Chiappa
j...@mercury.lcs.mit.edu
Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
NEW NON-IETF LIST ANNOUNCEMENT
IETF Ad Hominem Discussions
This group is dedicated to the discussion of the personal flaws of
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies
http://groups.google.com/group/ietf-ad-hominem
On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly
that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless
some,
(rather large) amount of some flavor of NAT was unavoidable and I
still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised
architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please
note
that this is not a I told you so post; I would certainly have
opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this
grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
Our collective failure is that we have launched a protocol with to be
delivered soon advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
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
**
The IPv6 Portal: http://www.ipv6tf.org
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: IETF-ad-hominem (Was: Re: US DoD and IPv6)
Fine, remove me.
-Original Message-
From: JORDI PALET MARTINEZ [mailto:jordi.pa...@consulintel.es]
Sent: Wednesday, October 06, 2010 11:02 PM
To: rbar...@bbn.com; Michel Py
Cc: ietf@ietf.org; Keith Moore; Noel Chiappa
Subject: Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)
Yes, please, stop immediately this thread (at least the personal way
it is
going on) or I will be forced as sergeant-at-arms to remove the
participants
from the IETF mail exploder.
Regards,
Jordi
From: Richard L. Barnes rbar...@bbn.com
Reply-To: rbar...@bbn.com
Date: Wed, 6 Oct 2010 22:04:46 -0700
To: Michel Py mic...@arneill-py.sacramento.ca.us
Cc: ietf@ietf.org, Keith Moore mo...@network-heretics.com, Noel
Chiappa
j...@mercury.lcs.mit.edu
Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
NEW NON-IETF LIST ANNOUNCEMENT
IETF Ad Hominem Discussions
This group is dedicated to the discussion of the personal flaws of
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies
http://groups.google.com/group/ietf-ad-hominem
On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly
that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless
some,
(rather large) amount of some flavor of NAT was unavoidable and I
still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised
architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please
note
that this is not a I told you so post; I would certainly have
opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this
grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the
last
ones to try either.
Our collective failure is that we have launched a protocol with to
be
delivered soon advanced features that unfortunately have proved to
be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
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
**
The IPv6 Portal: http://www.ipv6tf.org
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the contents
of this information, including attached files, is prohibited.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: IETF-ad-hominem (Was: Re: US DoD and IPv6)
Keep your head in the sand. Efforts towards convergence to a post mortem
are rarely fast and rarely painless.
-Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com]
Sent: Wednesday, October 06, 2010 10:05 PM
To: Michel Py
Cc: Keith Moore; Noel Chiappa; ietf@ietf.org
Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
NEW NON-IETF LIST ANNOUNCEMENT
IETF Ad Hominem Discussions
This group is dedicated to the discussion of the personal flaws of
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies
http://groups.google.com/group/ietf-ad-hominem
On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly
that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless
some,
(rather large) amount of some flavor of NAT was unavoidable and I
still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised
architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please
note
that this is not a I told you so post; I would certainly have
opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this
grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
Our collective failure is that we have launched a protocol with to be
delivered soon advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
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: US DoD and IPv6
Michel Py wrote:
Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a I told you so post; I would certainly have opposed
what I will suggest below.
Agreed.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
I specified and implemented ID/LOC separation and it worked.
So, I have some insight on it.
impossible to deliver. Such as, {cough} PA-based multihoming.
For PA-based multihoming, ID/LOC is not essential. An ID and
multiple locators is just as good as multiple addresses.
W.r.t. IPv6, however, an 8B ID and 8B locators means about half
amount of storage than 16B addresses. That's all.
So, the better solution should have been IPv6 with 8B addresses.
Then, the problem for PA is that, when you say PA, you must
define what P is, as everyone want to be a P.
To me, it is obvious that there should be small number
of Ps, to which all the other entities (including small ISPs)
should be multihomed.
But, it is also obvious that my idea is not politically acceptable
to regional NICs where small ISPs have dominant voting rights.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: IETF-ad-hominem (Was: Re: US DoD and IPv6)
On Thu Oct 7 07:00:35 2010, Michel Py wrote: Fine, remove me. Yeah! He started it! It's so unfair. I don't even like your stupid mailing list anyway, so there! Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: David Conrad d...@virtualized.org ISPs that have routers that are on the edge memory- or CPU-wise should really consider upgrading, as there is likely to be a flood of long prefix IPv4 routes as the markets take effect. Excellent point. Happily, there are a number of things being worked on that can help with this, if they succeed and get reasonably widely deployed. In particular, to the extent that we can separate location and identity (and there are a number of active schemes which do this), the fractionalization of the identity namespace (to make maximum utilization of it, since smaller allocations inevitably mean more efficient utilization, whereas larger one meak more wastage) would to a certain degree cease to be an issue. (I say if they ... get reasonably widely deployed because if you look at interoperability issues with unmodified installed base, very patchy deployment of these new things would leave us unable to really get the full benefit, in terms of routing table diminuation, because you'd have to keep advertizing legacy routes to allow legacy equipment to interoperate. We'll see...) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
From: Brian E Carpenter brian.e.carpen...@gmail.com The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See, this is the kind of thing I was talking about in my early post in the recent incarnation of this thread. Complaining about the existence of disjoint naming realms, and how it has complicated our lives, is like a rocket scientist complaining about gravity, and how hard it makes their job. (OK, it's not quite a perfect analogy, since gravity is fundamental, but I think my point is clear.) They were inevitable, end of story. This is the architectural reality we live in, and we need to accept that, and fully align IETF work around that reality - and not act like it's a red-headed step-child that will sit in a corner and be quiet if we don't deign to pay attention to it. Yes, it does make our lives as engineers a lot harder. Trying to do fundamental architectural upgrade an enormous, in-service communication system is hard too - much, much harder than a clean sheet design, and filled with all sorts of kludges on the edges where you have to interface to existing stuff. However, if you just accept that that's what you have to do, and get on with it, you can make non-trivial progress. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 8:57 PM, Fernando Gont wrote: On 06/10/2010 05:40 p.m., Keith Moore wrote: It's perfectly reasonable for applications to include IP addresses and port numbers in their payloads, as this is the only way that the Internet Architecture defines to allow applications to make contact with particular processes at particular hosts. Some might see this as a deficiency in the Internet Architecture, but that's the best that we have to work with for now. If anything, the fact that this is is the only way that the Internet Architecture defines... doesn't make it reasonable. So basically you're arguing to impair the ability of applications to function, just so that network operators can futz around with addresses. No. I'm arguing that you should not blame NATs for broken application designs, and that you should not assess reasonable-ness based on existing (and questionable) application designs. Reasonableness of an application should have to do with whether it's operating within the expectations established by the standard IP, TCP, etc. protocol specifications, not with whether it happens to conform to the expectations established by any particular religion. As currently defined, IP assumes a global address space that is used consistently throughout the network, and that the network will make a best effort to deliver each packet to its destination. The problem is that significant violations of fundamental design points of IP are now so widespread and varied that there's no longer any objective view of reasonableness. What you cite as reasonable is arbitrary. It isn't a consequence of any explicit design of the protocol or the network, it just reflects your personal prejudices. Who is to say whose prejudices are right? What is desperately needed in the Internet today is an architecture. By architecture I mean a set of explicit, conscious, well-considered decisions that dictate the roles of various components of the network and how they interact with one another. And that architecture has to be maintained to reflect changing circumstances over time. We don't have an architecture today. What we have today are the remnants of an architecture that is 30+ years old, and a lot of competing religions. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See, this is the kind of thing I was talking about in my early post in the recent incarnation of this thread. Complaining about the existence of disjoint naming realms, and how it has complicated our lives, is like a rocket scientist complaining about gravity, and how hard it makes their job. (OK, it's not quite a perfect analogy, since gravity is fundamental, but I think my point is clear.) They were inevitable, end of story. No, they were not inevitable, at least not in the long term. Two cases: 1. There were IPng proposals that would have made IPng an extension of IPv4 space, and allowed (at least in the interim) all IPng traffic to be tunneled over IPv4 networks. This understandably made routing people and network operators uneasy as nobody wanted to live with the Class C swamp forever. But in hindsight there were probably other ways of dealing with that problem. And being able to leverage the existing IPv4 network in a general way would have made IPng easier to deploy. (Admittedly, what looked deployable in the early 1990s when these tradeoffs were being discussed is very different from what looks deployable now. In 1991, say, it was much easier to imagine the whole Internet migrating to a new protocol than it was even a couple of years later.) 2. In the late 1990s when it became apparent that NATs were causing problems, IETF had an opportunity to put a stake in the ground. It could have tried to find a way to integrate NATs into an explicit Internet architecture; it could have explained why NATs presented difficult problems for which there were no good solutions; it could have tried to define NAT in such a way as to permit a more graceful migration to IPv6. It failed at all three of these, not because of insurmountable technical difficulties, but because (a) too many people were afraid of alienating NAT vendors, and (b) IAB, the only part of IETF that had any responsibility for architectural direction, had been stripped of its power in the wake of Kobe. In fact, as we should realize by now, IAB's concerns that dictated the Kobe decision were extremely well founded, even if a lot of us (myself included) didn't like the specific choice they made. But as it turned out, we didn't really have enough time to use our normal rough consensus process to specify IPng. All of this is water that has already flowed under the bridge, of course. But I think there is at least one thing that we need to learn from this going forward, and that is that there really is a need for a small group of wise and widely-trusted people to be able to set architectural direction for the internet. And occasionally, they're going to make unpopular decisions. But those are the sort of issues for which a rough consensus process demonstrably does not work. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)
It is not an ad-hominem argument. And ad-hominem is only invalid as a form
of logical argument, it is actually legitimate when considering facts and
axioms.
Strictly speaking Ad-Hominem would be 'that idea must suck, X likes it'.
What was stated was 'your refusal to be reasonable on this issue is the
reason why IPv6 is not deployed'.
Which in this particular case happens to be the fact.
For the past fifteen years, the IPv6 deployment strategy has been based on
features. Which is a bad strategy because applications want to have as few
dependencies on the details of the underlying layers as is possible.
In particular there have been people who have argued against making NAT
transparent in case it is a little too good and delays deployment of IPv6
further.
After fifteen years the market has rejected that approach. Carrier grade NAT
has a much higher priority than IPv6 for the product managers of all the
router layer companies who send people to IETF.
On Thu, Oct 7, 2010 at 1:04 AM, Richard L. Barnes rbar...@bbn.com wrote:
NEW NON-IETF LIST ANNOUNCEMENT
IETF Ad Hominem Discussions
This group is dedicated to the discussion of the personal flaws of IETF
participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies
http://groups.google.com/group/ietf-ad-hominem
On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless some,
(rather large) amount of some flavor of NAT was unavoidable and I still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a I told you so post; I would certainly have opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
Our collective failure is that we have launched a protocol with to be
delivered soon advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
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
--
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
Brian is playing unfair here by introducing an actual application layer consequence into the architecture discussion :-) The referral problem he refers to is real, but I see it more as a consequence of the IETF being too rigid in its approach to address numbering. The basic question here is that we have two hosts that are to connect for a peer-peer protocol in which either endpoint can initiate or respond to a connection request. Clearly this is rather challenging if the boundaries between addressing schemes are arbitrary and becomes somewhat simpler in a uniform addressing model. But the real Internet is not like that. It is a network of networks and crossing the boundary between a private network and the interconnect space between the networks has consequences. One of those consequences is that addresses can change at the private/interconnect border. Another consequence is that crossing that boundary should have security consequences. Opening up a port to receive connection requests has considerably greater security consequence than making the request. The requester is opening a communication channel with a single, specified entity, the responder is opening access to any host on the Internet. It is much better to give than to receive So opening a port is an event that should be mediated by access control at the host level and private/interconnect border at a minimum. In a default deny network there will be additional policy enforcement within the private network. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Keith, On Oct 7, 2010, at 4:32 AM, Keith Moore wrote: As currently defined, IP assumes a global address space that is used consistently throughout the network, I actually think it's a bit worse than that. As currently defined, IP assumes a global address space in which each individual address has the potential for being topologically significant. Topological aggregation to permit scaling was an afterthought that doesn't fit particularly well into that architecture. Who is to say whose prejudices are right? If it doesn't work (for some value of the variable 'work'), it's fairly clear it's wrong. What is desperately needed in the Internet today is an architecture. ... We don't have an architecture today. What we have today are the remnants of an architecture that is 30+ years old, and a lot of competing religions. I wonder if the folks in the telephony world would say the same thing (modulo 100+ instead of 30+). Given people's reliance on the Internet, the idea that we can throw out the existing (non-)architecture and replace it wholesale with something new is mere fantasy. Even back with IPng was being chosen, the assumption that this would be possible was probably a core mistake. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 7, 2010, at 1:32 PM, David Conrad wrote: Keith, On Oct 7, 2010, at 4:32 AM, Keith Moore wrote: As currently defined, IP assumes a global address space that is used consistently throughout the network, I actually think it's a bit worse than that. As currently defined, IP assumes a global address space in which each individual address has the potential for being topologically significant. Topological aggregation to permit scaling was an afterthought that doesn't fit particularly well into that architecture. Fair enough. But very few applications out there make assumptions about topology based on address assignments. If IP address assignment suddenly became non topologically significant, hardly any applications would break. Routing would have to change, but assuming you had a way to do it, such a change would be far less disruptive than say IPv4-IPv6 transition. Who is to say whose prejudices are right? If it doesn't work (for some value of the variable 'work'), it's fairly clear it's wrong. From that point of view, everything in IPv4 is wrong. Using NATs is wrong because it doesn't work for some apps; not using NATs is wrong because it doesn't provide enough address space. In other words, the problem of making IPv4 continue to be viable is (probably inherently) overconstrained. Given people's reliance on the Internet, the idea that we can throw out the existing (non-)architecture and replace it wholesale with something new is mere fantasy. Even back with IPng was being chosen, the assumption that this would be possible was probably a core mistake. No disagreement there. Clearly you can't replace the internet architecture wholesale, but it might be possible to evolve it. What doesn't work well is to have everyone decide for himself how to change the architecture. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
David Conrad wrote: Topological aggregation to permit scaling was an afterthought that doesn't fit particularly well into that architecture. Topological aggregation to divide an IP address into network and local address parts with classes A, B and C to permit scaling has been there from the beginning. It's inherent to fundamental architecture of the CATENET model. You can find more than two levels of aggregation in RFC796. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Noel, On Oct 5, 2010, at 5:42 PM, Noel Chiappa wrote: So whatever's going to happen when IPv4 addresses run out, a mass conversion of traffic to IPv6 probably isn't it. Of course not. Obtaining IPv4 addresses will simply become more expensive, with all that implies. Folks that depend on a cheap supply of new IP addresses are going to figure out ways of continuing to obtain their supplies, but costs will be non-linear and unpredictable. This will encourage ISPs to cannibalize internal public holdings (e.g., addresses for internal infrastructure) migrating to RFC 1918 or IPv6 internally and, when that runs out (which won't take long), purchase IPv4 address on the black/grey/white (depending on how the RIRs deal with runout) market. Costs will, of course, be passed down to the end user. End users will either respond by: a) deciding they are OK with 1 or 2 public addresses and NATv4'ing everything else, returning PA address space to their ISPs or selling/leasing PI address space to folks willing to pay; and/or b) turn on IPv6 and demand their ISPs and preferred content providers support it, and deploy v4 to v6 NAT as a stop gap (which probably will such just as much and as little as option (a)). Option (b) is probably better in the long run, though some folks might disagree. Oddly enough, I don't see a way forward that doesn't include vast amounts of NAT. The only question is what flavor of NAT. ISPs that have routers that are on the edge memory- or CPU-wise should really consider upgrading, as there is likely to be a flood of long prefix IPv4 routes as the markets take effect. If they can't upgrade, then we revisit history and see prefix length filters showing up again. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 1:10 AM, Michel Py wrote: Noel Chiappa wrote: The interesting question, of course, is whether (and if so, when) the IETF will deign to notice this reality - or will it continue to prefer to stick its collective fingers in its ears and keep going 'neener-neener-neener'. Keith Moore wrote: Do you actually have a point to make, Noel, or are you just taking pot shots at IETF again? Look who's talking. Despite a brilliant mind and sometimes significant contributions, you are one of the main persons behind the failure of IPv6. The living example of the IETF ivory tower. Has it occurred to you that, if it was not for your blind opposition to NAT, we could be living in a world of 6to4 implemented in the ubiquitous NAT box? Why do you think I proposed 6to4 in the first place? There was no vendor interest in putting 6to4 in NAT boxes. For that matter, I also proposed a mechanism to allow applications to better cope with NAT between v4 and v6 (and by extension between v4 and v4) by making the NATs explicitly controlled by the endpoints. There was no interest in that either. Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464...whatever and all of these with heavy ALG layers to make it more palatable. I think you give me far more credit than I'm due. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
From: Michel Py mic...@arneill-py.sacramento.ca.us you are one of the main persons behind the failure of IPv6. I think that's unfair. To my mind (when I sat and did a long post-mortem after the IETF adopted IPv6 almost two decades ago, trying to understand why I hadn't been able to convince people to do something different), in some sense the real guilty party in the IPv6 choice is the IETF at large, the ordinary members - for accepting what was basically 'IPv4 with a few more bits', instead of a fundamentally revised architecture that would provided real benefits in the form of major new capabilities (e.g. separation of location and identity), thereby giving actual operational incentives to drive migration. We have met the enemy, and he is us. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: Keith Moore mo...@network-heretics.com Do you actually have a point to make That depends. Are you still of the opinion that IPv6 will, in our lifetimes, become ubiquitously deployed, thereby restoring us to a world of transparent end-end, or do you think we should acknowledge that that's not going to happen, and start to think about how to design for a permanently mixed Internet - and actually have that model in mind when doing protocol work? Because there are clearly a lot of people who don't buy into that (viz. this recent comment Now is not the point to invest time fixing the ipv4 internet.). Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464 I think you give me far more credit than I'm due. I have to agree. In some sense, NAT became inevitable way back in 1976 (or so, don't recall the exact date of this), when variable length addresses were removed from IPv3 (I think it was) in favour of the 32-bit fixed-length addresses. (The failue to differentiate between interface names and endpoint names also was a factor, but somewhat tangential.) The reason is simple: i) 32 bits would eventually be too few for naming endpoints, and ii) when that happened, since no evolutionary path to a larger namespace had been defined, naming domains separated by translators were driven by economics as the cheapest way forward. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 11:00 AM, Noel Chiappa wrote: From: Keith Moore mo...@network-heretics.com Do you actually have a point to make That depends. Are you still of the opinion that IPv6 will, in our lifetimes, become ubiquitously deployed, thereby restoring us to a world of transparent end-end, or do you think we should acknowledge that that's not going to happen, and start to think about how to design for a permanently mixed Internet - and actually have that model in mind when doing protocol work? Honestly, I don't think we can tell. In the short term, it certainly doesn't look good for end-to-end transparency.But unlike 10 years ago, today there's a widespread understanding of the problems caused by lack of transparency, and much less denial about it. The central problem with the Internet seems to be that nearly everybody who routes traffic thinks it's okay to violate the architecture and alter the traffic to optimize for his/her specific circumstances - and the end users and their wide variety of applications just have to cope with the resulting brain damage. (Admittedly there's a wide variation in _how much_ these people think it's okay to mess with transparency.) But I am not sure that that's the fault of the current Internet architecture, or that a different architecture would fare better. I think it's fairly inherent in that people can always understand their specific circumstances better than they can see the big picture, and that most of the world's economies are biased toward short-term thinking (and thus, hill climbing / dead ends). Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Tue, Oct 5, 2010 at 8:16 PM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: From: RJ Atkinson rja.li...@gmail.com It seems so incredibly unlikely that end-to-end connectivity (i.e. without NAT, NAPT, or other middleboxes) is going to increase in future. Indeed. It seems that the likelihood of IPv6 being used ubiquitously to provide end-end IPv6-IPv6 connectivity, as originally envisioned, is fairly small; instead, it seems we are headed for a future of various kinds of lash-ups (e.g. the scenario you posited with content providers, or with IPv6 being used between the cable modem and some sort of CGN IPv6/IPv4 NAT, with IPv4 on the other pieces of the path, as one large ISP has proposed). The interesting question, of course, is whether (and if so, when) the IETF will deign to notice this reality - or will it continue to prefer to stick its collective fingers in its ears and keep going 'neener-neener-neener'. Application designers who produce designs that rely on IP addresses being end-to-end are going to find their work fails. Since the one legacy protocol that has a dependency on IP address constancy is FTP, it would seem to me to be much easier to upgrade FTP to remove the dependency than to try to control the network. Since FTP is layered on Telnet (no really, it is) it would seem that the more sensible approach would be to standardize the file handling extensions to SSH and move FTP to historic status. At the moment we have a situation where everything layers over HTTP or HTTPS because they provide NAT passthrough. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
Gentlemen: The IPv6 deployment is what it is and nobody is to blame that it isn't greater or less than it is. It should not surprise anybody that IPv6 hasn't been more widely deployed to date, because, after all, I explained back in 1993 in RFC 1687 why that would happen. Going forward, there are many business reasons why IPv6 will increasingly become deployed and many business reasons why IPv4 use will actually grow. Thus, we can be assured that the Internet will be a mixed environment for the next many years to come. We have many existing technologies and approaches that handle such mixed environments. There is no reason to be upset -- this is the most probable result to the IPv4 address depletion problem. No surprises here. Best wishes, --Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Wed, Oct 6, 2010 at 12:43 PM, Keith Moore mo...@network-heretics.comwrote: The central problem with the Internet seems to be that nearly everybody who routes traffic thinks it's okay to violate the architecture and alter the traffic to optimize for his/her specific circumstances - and the end users and their wide variety of applications just have to cope with the resulting brain damage. Objective observation suggests that the Internet architecture *is* that anyone who wants to can molest traffic in any way they feel fit. Thats the 'Twits on the Wire' model in a nutshell. But really, I do not understand why people have to fetishize the constancy of IP addresses end to end. IP addresses are not particularly interesting to look at. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
And what would we say of architects who continued to build to their original plan after the bombs had been flying for twenty years and showed no sign of stopping? I would prefer the architects with the plans for a bomb shelter. On Wed, Oct 6, 2010 at 1:53 PM, Keith Moore mo...@network-heretics.comwrote: On Oct 6, 2010, at 1:45 PM, Phillip Hallam-Baker wrote: On Wed, Oct 6, 2010 at 12:43 PM, Keith Moore mo...@network-heretics.comwrote: The central problem with the Internet seems to be that nearly everybody who routes traffic thinks it's okay to violate the architecture and alter the traffic to optimize for his/her specific circumstances - and the end users and their wide variety of applications just have to cope with the resulting brain damage. Objective observation suggests that the Internet architecture *is* that anyone who wants to can molest traffic in any way they feel fit. If a bomb hits a famous building, we don't generally call the resulting rubble part of the building's architecture. (unless, maybe, it's the Hiroshima Peace Dome, which was repurposed to commemorate perhaps the worst man-made disaster in history.) But really, I do not understand why people have to fetishize the constancy of IP addresses end to end. IP addresses are not particularly interesting to look at. It's one of the two fundamental principles on which the Internet is based. Universal packet format, universal address space. That's IP in a nutshell. Keith -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 1:59 PM, Phillip Hallam-Baker wrote: And what would we say of architects who continued to build to their original plan after the bombs had been flying for twenty years and showed no sign of stopping? which architects would those be? I see little sign of architectural development in the Internet anymore. and some of the damage isn't from bombs, it's from lack of maintenance. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 3:38 PM, Fernando Gont wrote: On Wed, Oct 6, 2010 at 2:43 PM, Keith Moore mo...@network-heretics.com wrote: When applications that e.g. include point of attachment addresses in the app protocol break in the presence of NATs, one should probably ask whether the NAT is breaking the app, or whether the NAT is making it clear that the app was actually already broken. It's perfectly reasonable for applications to include IP addresses and port numbers in their payloads, as this is the only way that the Internet Architecture defines to allow applications to make contact with particular processes at particular hosts. Some might see this as a deficiency in the Internet Architecture, but that's the best that we have to work with for now. If anything, the fact that this is is the only way that the Internet Architecture defines... doesn't make it reasonable. So basically you're arguing to impair the ability of applications to function, just so that network operators can futz around with addresses. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 6, 2010, at 1:46 PM, David Conrad wrote: On Oct 6, 2010, at 7:43 AM, Keith Moore wrote: DNS has never been, and never will be, suitable as a general endpoint naming mechanism. What do you mean by a general endpoint naming mechanism? It's a good question, but it might take an internet-draft to answer that question in sufficient detail for this environment. The services required aren't hard to describe, but it's hard to get the definitions of the terms right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 06/10/2010 05:40 p.m., Keith Moore wrote: It's perfectly reasonable for applications to include IP addresses and port numbers in their payloads, as this is the only way that the Internet Architecture defines to allow applications to make contact with particular processes at particular hosts. Some might see this as a deficiency in the Internet Architecture, but that's the best that we have to work with for now. If anything, the fact that this is is the only way that the Internet Architecture defines... doesn't make it reasonable. So basically you're arguing to impair the ability of applications to function, just so that network operators can futz around with addresses. No. I'm arguing that you should not blame NATs for broken application designs, and that you should not assess reasonable-ness based on existing (and questionable) application designs. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
existing (and questionable) application designs [was Re: US DoD and IPv6]
On 2010-10-07 13:57, Fernando Gont wrote: On 06/10/2010 05:40 p.m., Keith Moore wrote: It's perfectly reasonable for applications to include IP addresses and port numbers in their payloads, as this is the only way that the Internet Architecture defines to allow applications to make contact with particular processes at particular hosts. Some might see this as a deficiency in the Internet Architecture, but that's the best that we have to work with for now. If anything, the fact that this is is the only way that the Internet Architecture defines... doesn't make it reasonable. So basically you're arguing to impair the ability of applications to function, just so that network operators can futz around with addresses. No. I'm arguing that you should not blame NATs for broken application designs, and that you should not assess reasonable-ness based on existing (and questionable) application designs. The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See draft-carpenter-referral-ps-01 Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
Brian E Carpenter wrote: The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. That's why we shouldn't use IPv6. With port restricted IPv4 (such as A+P, E2ENAT, PE-ARP), the addressing realm of address+port is identical as the current IPv4 Internet that there are no kludges necessary. Application protocols and programs, including but not limited to FTP, are working as is without ALG kludges. As PR-IP effectively expands IPv4 address space by a factor of 100 or 1000, there is no point to migrate to old and poor IPv6, even if we need a long term solution. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless some,
(rather large) amount of some flavor of NAT was unavoidable and I still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a I told you so post; I would certainly have opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
Our collective failure is that we have launched a protocol with to be
delivered soon advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
The problem with such opinions is that a bunch of purple are deploying ipv6, so that in a couple of years you will have to extend your NAT draft to cover communicating with v6 nodes anyway, and what's the point then? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF-ad-hominem (Was: Re: US DoD and IPv6)
NEW NON-IETF LIST ANNOUNCEMENT
IETF Ad Hominem Discussions
This group is dedicated to the discussion of the personal flaws of
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies
http://groups.google.com/group/ietf-ad-hominem
On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?
Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.
They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly
that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.
Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.
I think you give me far more credit than I'm due.
Maybe, and I certainly deserve some credit myself; nevertheless
some,
(rather large) amount of some flavor of NAT was unavoidable and I
still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.
Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised
architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.
Problem is that IPv6 is much more than IPv4 with more bits. Please
note
that this is not a I told you so post; I would certainly have
opposed
what I will suggest below.
In the end though, we would be better off now if we had gone the road
it's all the same just pad some extra zeroes instead of this
grandiose
solve-it-all almost-perfect protocol we all dreamed of.
As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.
Our collective failure is that we have launched a protocol with to be
delivered soon advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.
Now, what we have on our hands is a mess with a protocol in state of
non-deployment that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb just more bits upgrade.
Michel.
___
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: US DoD and IPv6
From: Thomas Narten nar...@us.ibm.com
Just as a general FYI, for those not following this space more closely,
industry's position wrt IPv6 has clearly shifted during the last year.
... A year ago, many big operators and companies were still taking a
wait-and-see approach to IPv6. Over the last year, we are seeing some
major players come to the realization that we have to do this and
have actually started doing so. This is real deployment, not just
playing around. But of course, there is a long road ahead, with more
trials and testing before a lot of this can go live in a production
setting.
Actually, I really was just asking for a clarification on what the DoD was up
to. But since you bring up IPv6 in general...
We have now heard, over the nearly two decades since IPv6 was picked as 'the
replacement for IPv4', numerous expressions of the form 'IPv6 will succeed
when {X} happens'. The most recent value for {X}, after none of the previous
dozen or two expressions of pious hope proved accuate, is 'when IPv4
addresses run out'.
Well, that's about to happen in just a few months from now.
So what %-age of traffic across major backbones is now IPv6? And how quickly
is that changing?
(On this line, it would be interesting to know what %-age of traffic across
major backbones has, or will, pass through a NAT at some point - as an
interesting counterpoint. But I digress...)
So now I'm curious as to what the _next_ value for {X} we hear is going to
be...
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: RJ Atkinson rja.li...@gmail.com It seems so incredibly unlikely that end-to-end connectivity (i.e. without NAT, NAPT, or other middleboxes) is going to increase in future. Indeed. It seems that the likelihood of IPv6 being used ubiquitously to provide end-end IPv6-IPv6 connectivity, as originally envisioned, is fairly small; instead, it seems we are headed for a future of various kinds of lash-ups (e.g. the scenario you posited with content providers, or with IPv6 being used between the cable modem and some sort of CGN IPv6/IPv4 NAT, with IPv4 on the other pieces of the path, as one large ISP has proposed). The interesting question, of course, is whether (and if so, when) the IETF will deign to notice this reality - or will it continue to prefer to stick its collective fingers in its ears and keep going 'neener-neener-neener'. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 5, 2010, at 8:16 PM, Noel Chiappa wrote: From: RJ Atkinson rja.li...@gmail.com It seems so incredibly unlikely that end-to-end connectivity (i.e. without NAT, NAPT, or other middleboxes) is going to increase in future. Indeed. It seems that the likelihood of IPv6 being used ubiquitously to provide end-end IPv6-IPv6 connectivity, as originally envisioned, is fairly small; instead, it seems we are headed for a future of various kinds of lash-ups (e.g. the scenario you posited with content providers, or with IPv6 being used between the cable modem and some sort of CGN IPv6/IPv4 NAT, with IPv4 on the other pieces of the path, as one large ISP has proposed). The interesting question, of course, is whether (and if so, when) the IETF will deign to notice this reality - or will it continue to prefer to stick its collective fingers in its ears and keep going 'neener-neener-neener'. Do you actually have a point to make, Noel, or are you just taking pot shots at IETF again? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
End to end NAT (was Re: US DoD and IPv6)
RJ Atkinson wrote: It seems so incredibly unlikely that end-to-end connectivity (i.e. without NAT, NAPT, or other middleboxes) is going to increase in future. Say end-to-end NAT (draft-ohta-e2e-nat-00.txt). Port restricted IP by end-to-end NAT keeps the end-to-end connectivity and effectively extend IPv4 address space by factor of 100 or 1,000. The point is to keep the end-to-end transparency is to let end systems aware of and help NAT functionality. Current loss of end-to-end connectivity by existing NAT boxes will be restored if the boxes are replaced/upgraded to have end-to-end NAT capability. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Noel == Noel Chiappa j...@mercury.lcs.mit.edu writes: Noel So what %-age of traffic across major backbones is now IPv6? Noel And how quickly is that changing? From what I've read, it's about the same size as the IPv4 in 1992, and it's growing at the same rate it did then. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: Michael Richardson m...@sandelman.ca So what %-age of traffic across major backbones is now IPv6? ^ From what I've read, it's about the same size as the IPv4 in 1992 I don't think so... unless you meant 'total number of packets', not 'percentage' (as I asked). The point is that backbone traffic is still mostly IPv4 - and with the IPv4 address space runout in only a few months, that's unlikely to change substantially between now and then. So whatever's going to happen when IPv4 addresses run out, a mass conversion of traffic to IPv6 probably isn't it. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 5, 2010, at 11:42 PM, Noel Chiappa wrote: From: Michael Richardson m...@sandelman.ca So what %-age of traffic across major backbones is now IPv6? ^ From what I've read, it's about the same size as the IPv4 in 1992 I don't think so... unless you meant 'total number of packets', not 'percentage' (as I asked). The point is that backbone traffic is still mostly IPv4 - and with the IPv4 address space runout in only a few months, that's unlikely to change substantially between now and then. So whatever's going to happen when IPv4 addresses run out, a mass conversion of traffic to IPv6 probably isn't it. I think the demise of IPv4 will be a lot like the demise of BITNET. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
Noel Chiappa wrote: The interesting question, of course, is whether (and if so, when) the IETF will deign to notice this reality - or will it continue to prefer to stick its collective fingers in its ears and keep going 'neener-neener-neener'. Keith Moore wrote: Do you actually have a point to make, Noel, or are you just taking pot shots at IETF again? Look who's talking. Despite a brilliant mind and sometimes significant contributions, you are one of the main persons behind the failure of IPv6. The living example of the IETF ivory tower. Has it occurred to you that, if it was not for your blind opposition to NAT, we could be living in a world of 6to4 implemented in the ubiquitous NAT box? Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464...whatever and all of these with heavy ALG layers to make it more palatable. Congratulations. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Michel Py wrote: Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464...whatever and all of these with heavy ALG layers to make it more palatable. FYI, with end to end NATv4, all the applications, including PORT command of FTP, just work without any ALG layers at all. End to end NAT does not even have TLG layers of transport checksum recalculations, and port translations. For the end to end transparent NAT, NAT boxes can do nothing other than the simplest address translation and rest of the job must be done by end systems. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
A bit before then, Thomas Narten wrote: There are DoD networks where IPv6 is running today, and there certainly are networks where it is not. The quote above seems very precisely phrased, and as an accidental result seems a bit misleading. It appears to refer to the Defense Research Engineering Network (DREN), which is widely reported to be dual-stack IPv4 and IPv6. [e.g. see Ron Broersma's slides from the Google IPv6 Implementer's Workshop] However, the trade press and other public sources consistently indicate the DoD considers DREN to be experimental or research, rather than operational (at least for the DoD meaning of the word 'operational'). One also consistently reads that the actual operational DoD backbone (i.e. DISA's GIG-BE network) is IPv4 only, in part for security reasons and in part for lack of any business case to do otherwise, and that all other DoD operational networks are also IPv4 only. The DoD is forbidden from running native IPv6 operationally, per the STIGs and MO guidelines. MO1 and 2 get some IPv6 in place, in tunnels across the GIG ... MO3 will be the first step in native/operational IPv6, not even signed yet IIRC. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
TJ wrote: A bit before then, Thomas Narten wrote: There are DoD networks where IPv6 is running today, and there certainly are networks where it is not. The quote above seems very precisely phrased, and as an accidental result seems a bit misleading. It appears to refer to the Defense Research Engineering Network (DREN), which is widely reported to be dual-stack IPv4 and IPv6. [e.g. see Ron Broersma's slides from the Google IPv6 Implementer's Workshop] However, the trade press and other public sources consistently indicate the DoD considers DREN to be experimental or research, rather than operational (at least for the DoD meaning of the word 'operational'). One also consistently reads that the actual operational DoD backbone (i.e. DISA's GIG-BE network) is IPv4 only, in part for security reasons and in part for lack of any business case to do otherwise, and that all other DoD operational networks are also IPv4 only. The DoD is forbidden from running native IPv6 operationally, per the STIGs and MO guidelines. MO1 and 2 get some IPv6 in place, in tunnels across the GIG ... MO3 will be the first step in native/operational IPv6, not even signed yet IIRC. Part of the confusion is a terminology issue. Within the DoD networking context, operational generally refers to customer base and the mission, not whether the network itself is operational. For the DoD networks that support the operational military forces and functions related to that, IPv6 is not yet authorized. The Milestone Objectives (MO's) described above apply in that context. These networks correctly take a conservative approach, because of what's at stake. On the other hand, the DoD research and engineering community lives on separate networks, most of which use DREN as their ISP. This community supports Research and Development, Test and Evaluation, Modeling and Simulation, High Performance Computing, and so forth. The network itself is absolutely operational in the sense that it is a fully functional network providing critical networking services between all of these resources. It is not a testbed. It is not just an experimental network. It has SLAs like any other network. It is a full production network environment, and it has been running IPv6 for a decade. So, the statement DoD is forbidden from running native IPv6 operationally gives the wrong sense of the situation. DREN has been running IPv6 operationally as a production service since 2003, when it was selected as the official DoD IPv6 pilot network. Years before that DREN was operating a dedicated wide area IPv6 testbed. There are enterprises (customers) on DREN where everything is 100% dual stack (ever server, every client, etc.). I think you'll find that parts of DREN and its customer base have been very aggressive in rolling out IPv6 wherever possible, and sharing lessons learned at every opportunity, and pressing vendors to eat their own dogfood and to deliver feature parity, and pushing for national policy to incentivize IPv6-enabling all public facing services, etc. I hope that helps to clarify some of the discussion here. Regards, --Ron (Ron Broersma, DREN Chief Engineer) smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Earlier, Joel Jaggli wrote:
The fact of the matter as a vendor, is that if you want
to get through network equipment requirements for, for example
the army approved products list (AAPL), ipv6 conformance testing
is now no longer an annnex, it's simply part of the process.
Interesting to know. Of course, the above was also true
for OSI CLNP, IS-IS, and ES-IS (under GOSIP) for many many years.
A bit before then, Thomas Narten wrote:
There are DoD networks where IPv6 is running today,
and there certainly are networks where it is not.
The quote above seems very precisely phrased,
and as an accidental result seems a bit misleading.
It appears to refer to the Defense Research Engineering Network
(DREN), which is widely reported to be dual-stack IPv4 and IPv6.
[e.g. see Ron Broersma's slides from the Google IPv6 Implementer's
Workshop]
However, the trade press and other public sources consistently
indicate the DoD considers DREN to be experimental or research,
rather than operational (at least for the DoD meaning of the
word 'operational').
One also consistently reads that the actual operational DoD backbone
(i.e. DISA's GIG-BE network) is IPv4 only, in part for security
reasons and in part for lack of any business case to do otherwise,
and that all other DoD operational networks are also IPv4 only.
If someone has contradictory data, it would be very interesting
to know the name of any operational (again, in the DoD meaning
of that word) DoD networks that have a non-experimental/non-research
deployment of IPv6 today.
A bit before that, Brian Carpenter wrote:
On 2010-09-28 16:25, Phillip Hallam-Baker wrote:
The US DoD is running out of IPv4 space?
Where did I say that?
I very much doubt it.
Maybe, maybe not... how would we know?
One could check the public IANA allocation information,
and perhaps combine it with other public information.
Published reports indicate the US DoD has very interesting
portion of the IPv4 unicast address space, even after
they gave a few blocks back earlier this decade.
However, in this case, that question is directly answered
in the article that Noel originally mentioned.
To quote directly:
“I don’t forsee a crisis, per se … the big driver,
in my mind, excluding DoD, will be the explosion
of requirement for IP addresses, given where we are
headed from a technology standpoint,” he added.
Conversely, he said, the Department of Defense networks
won’t be under the same strain.
So official DoD sources have said publicly that the DoD
does not have an IPv4 address shortage.
In any case, we can't rewrite history, and many operators are
well beyond project and well into plan. Content providers
who aren't into plan have a problem coming up if they
still want to grow their audience a few years from now.
One hears reports that for several large ISPs ('operators'),
in different areas of the world, the plan involves
carrier-scale deployment of:
'Stateful NAT64: Network Address and Protocol Translation
from IPv6 Clients to IPv4 Servers'
draft-ietf-behave-v6v4-xlate-stateful-12.txt
which I think is now approved for publication on the IETF
standards-track.
If those reports are true, then might it not be likely that
vendors are busy implementing the above in products, so
ISPs can deploy that capability, in turn so that any residential
users who only have an IPv6 address could still access the
content of the (for the moment much larger) IPv4 Internet ?
If one were a commercial content provider, only having an IPv6
address might seem incredibly limiting. Might one imagine such
a content provider would refuse to buy for IPv6-only service ?
Might that not create a business case to lease/purchase IPv4
address space (e.g. using the IPv4 trading provisions that
some RIRs reportedly are setting up) ?
BOTTOM LINE:
The mind boggles at the myriad possibilities here. It seems so
incredibly unlikely that end-to-end connectivity (i.e. without
NAT, NAPT, or other middleboxes) is going to increase in future.
Yours
Ran
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
--On Tuesday, September 28, 2010 14:34 -0400 RJ Atkinson rja.li...@gmail.com wrote: ... However, in this case, that question is directly answered in the article that Noel originally mentioned. To quote directly: I don't forsee a crisis, per se … the big driver, in my mind, excluding DoD, will be the explosion of requirement for IP addresses, given where we are headed from a technology standpoint, he added. Conversely, he said, the Department of Defense networks won't be under the same strain. So official DoD sources have said publicly that the DoD does not have an IPv4 address shortage. ... BOTTOM LINE: The mind boggles at the myriad possibilities here. It seems so incredibly unlikely that end-to-end connectivity (i.e. without NAT, NAPT, or other middleboxes) is going to increase in future. Of course, one of those myriad possibilities, at least in principle, is that the Administration decides that DoD should move forward with IPv6, wait until the IANA allocations of IPv4 addresses run out, and then auction their considerable surplus at scarcity-market rates... thereby reducing the national debt and postponing the date of a real IPv4 address crisis by a few months :-). No, I'm not holding my breath. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On 9/27/10 7:20 PM, Brian E Carpenter wrote:
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
The fact of the matter as a vendor, is that if you want to get through
network equipment requirements for, for example the army approved
products list (AAPL), ipv6 conformance testing is now no longer an
annnex, it's simply part of the process.
The 2005 mandate said that equipment and services you procure for
certain roles in the network must have the ipv6 compliant checkbox
ticked, we're well beyond that now.
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be
required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Hi Noel. I don't think there is any real change in DoD policy. Anyone who has followed the DoD IPv6 work more closely or who sells products to the DoD has long seen that the IPv6 requirements are more nuanced and depend on a lot of factors. And there have always been exceptions and waivers, depending on local circumstances. We are still in that situation today, though overall, the requirement for IPv6 is still there and is stronger than ever. Joel said it pretty well. Vendors have mostly moved beyond this. There are DoD networks where IPv6 is running today, and there certainly are networks where it is not. IPv6 deployment has never been as simple as you must do it. Just as a general FYI, for those not following this space more closely, industry's position wrt IPv6 has clearly shifted during the last year. As one colleague recently put it, reality has set in. A year ago, many big operators and companies were still taking a wait-and-see approach to IPv6. Over the last year, we are seeing some major players come to the realization that we have to do this and have actually started doing so. This is real deployment, not just playing around. But of course, there is a long road ahead, with more trials and testing before a lot of this can go live in a production setting. But momentum clearly seems to be shifting. See the following articles for some indications of where things are and what is happening in the pipeline. Akamai: http://www.networkworld.com/news/2010/091610-akamai-ipv6.html Verizon: http://www.networkworld.com/news/2010/082410-verizon-ipv6.html http://www.networkworld.com/news/2010/090310-verizon-ipv6.html?source=NWWNLE ATT: http://www.networkworld.com/news/2010/082610-att-ipv6.html http://www.business.att.com/enterprise/exchange_resource/Topic/tech T-Mobile USA: http://groups.google.com/group/tmoipv6beta And of course, the IPv6 efforts of Comcast, Google, Netflix, Limelight, etc. are all old news at this point. Oh, and today, there is an NTIA-sponsered workshop on IPv6: http://www.affirm.org/NTIA_IPv6 http://www.ntia.doc.gov/advisory/IPv6/IPV6WorkshopAgenda_09282010.pdf And presumably the entire USGv6 program is old news these days. (http://w3.antd.nist.gov/usgv6/testing.html). Yet that program appears to be humming along, with lots of vendors getting products tested (and fixed!). (And like the DoD program, there are nuances to USGv6, there are exceptions, it's not an absolute no-wiggle-room requirement, etc.) And if you want to understand who is about to get slammed by the pain of address shortages, look at the mobile wireless space. During 2010, the number of mobile subscriptions worldwide is expected to reach 5B (yes 5 billion), and 1B of those will include internet access (http://reviews.cnet.com/8301-13970_7-10454065-78.html). The number of mobile subscriptions is expected to double to 10B by 2015 (according to Morgan Stanley)! All those mobile devices need addresses! Lots of stuff happening. Much of it behind the scenes. None of this will play out quickly. But I think industry has really turned a corner in the last year, and momentum is building. The landscape will look very different a year from today. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
The US DoD is running out of IPv4 space?
I very much doubt it.
Problem with the idea that resource depletion will drive adoption of IPv6 is
that it ignores the fact that people who have plenty of IPv4 addresses may
not be that worried about the inability of others to get hold of them.
And some people are going to see ways of keeping out the competition. Their
view of IPv4 will like the view of the medallion owners who keep New York
Taxis expensive and hard to find even though there is no shortage of drivers
willing to work.
The reason IPv6 is still at the project stage is that the designers had the
wrong view of economics. You don't make IPv6 attractive by making it
different to IPv4, you make it attractive by eliminating all the
differences.
On Mon, Sep 27, 2010 at 10:20 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris
Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need
or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the
Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29,
2003,
which said that:
the DoD has established the goal of transitioning all DoD networking
to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case
to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality
has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from
August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which
said
that:
... waiver submissions for programs not transitioning to IPv6 by
FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be
required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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
--
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
US government and IPv6 (was US DoD and IPv6)
not the DoD but maybe of interest Scott http://www.cio.gov/Documents/IPv6MemoFINAL.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Oh and this just in today, a new OMB directive for all of USG (http://gcn.com/articles/2010/09/28/kundra-sets-new-ipv6-deadlines.aspx): âThe federal government is committed to the operational deployment and use of Internet Protocol version 6,â states the transition memo, which was released through OMB. The memo directs agencies to: * Upgrade the servers and services the public uses, such as Web, e-mail and Domain Name System servers, to use native IPv6 by the end of fiscal 2012. * Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to use native IPv6 by the end of fiscal 2014. * Designate an IPv6 transition manager by Oct. 30 as the person responsible for leading the agencyâs transition activities. * Ensure that agency procurements of networked IT comply with Federal Acquisition Regulation requirements for using the USGv6 profile and testing program for the completeness and quality of IPv6 capabilities. The Federal IPv6 Task Force will meet with agencies to explain government policy and share best practices. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
US DoD and IPv6
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that updated
policy, but it still seems to be a change in emphasis and direction.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that updated
policy, but it still seems to be a change in emphasis and direction.
___
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: US DoD and IPv6
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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: US DoD and IPv6
Phill,
On 2010-09-28 16:25, Phillip Hallam-Baker wrote:
The US DoD is running out of IPv4 space?
Where did I say that?
I very much doubt it.
Maybe, maybe not... how would we know?
Problem with the idea that resource depletion will drive adoption of IPv6 is
that it ignores the fact that people who have plenty of IPv4 addresses may
not be that worried about the inability of others to get hold of them.
Sure, and those people can live in their own little world, until
something changes. Then, they either have a plan in place, or they panic.
And some people are going to see ways of keeping out the competition. Their
view of IPv4 will like the view of the medallion owners who keep New York
Taxis expensive and hard to find even though there is no shortage of drivers
willing to work.
Yes, just as incumbent telcos fought against the Internet twenty years
ago, until something changed.
The reason IPv6 is still at the project stage is that the designers had the
wrong view of economics. You don't make IPv6 attractive by making it
different to IPv4, you make it attractive by eliminating all the
differences.
If only life was that simple, Phill. In any case, we can't rewrite history,
and many operators are well beyond project and well into plan.
Content providers who aren't into plan have a problem coming up if they
still want to grow their audience a few years from now.
Brian
On Mon, Sep 27, 2010 at 10:20 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris
Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need
or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the
Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29,
2003,
which said that:
the DoD has established the goal of transitioning all DoD networking
to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case
to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality
has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from
August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which
said
that:
... waiver submissions for programs not transitioning to IPv6 by
FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be
required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
