Noel Chiappa wrote: > ... > IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's > just > not enough better to make it worth switching - and you can flame all day > about > how NAT's are preventing deployment of new applications, but I can't run > an > SMTP or HTTP server in my house because my provider blocks incoming SMTP > connections unless I pay for business service, and I personally find that > a > lot more problematic than the limitations of NAT. This sounds more like a point to raise with a regulatory agency than a technical discussion. Your ISP would make you a prime candidate for a tunnel-broker that will get you past the blockage: http://www.freenet6.net/ > > IPv6's only hope of some modest level of deployment is, as the latter part > of > your message points out, as the substrate for some hot application(s). > Somehow > I doubt anything the IETF does or does not do is going to have any affect > on > whether or not that happens. You may be right, but that only argues that the IETF is irrelevant to the development of applications. If that is true, why do we have an applications area full of working groups? My question was really why they are not recognizing that at this point IPv4 is a dead end, and stopping any work that assumes an IPv4 substrate? Yes apps are supposed to be agnostic, but we all know that apps insist on hooks down the stack, because the app developer believes he can do a better job of managing the network than the OS. > > Of course, that still doesn't get you to the "general replacement for > IPv4" > stage. I don't think that goal is reachable - IPv6 just isn't enough > better > (i.e. more functionality) than IPv4. It's ironic that one of IPv6's big > concept points ("the IPv4 architecture is fine, we just need to fix a few > details") turns out to be IPv6's Achilles' heel. (Although some of us > predicted that at the time IPv6 was adopted....) As you may recall, I really don't care about the bit pattern in the header, as long as it has enough bits. I have been the pragmatist focused on getting whatever is implemented actually deployed (we could have had TUBA deployed long ago, as some of us had the routing infrastructure up before the IPv6 decision). IETF internal conflict has had more to do with any delays than the market could have. > > > Now if basic IPv6 (and basic IPv6 applications) were reworked so that it's > IMPOSSIBLE to tell, from looking at the packet, what kind of service it's > going to - e.g. by using random TCP ports for applications servers, and > having > the ICP include a service name (the field for which is encrypted so > middle-boxes can't read it) to do the rendezvous - that would be the kind > of > thing that might interest a few more people. As I recall, several people including Peter Ford were arguing that the transport layer should be reworked at the same time, because making the stack and application changes would be a big enough job that people would only want to do it once. There was a vast outcry in the IETF to make the minimum number of changes and keep the architecture exactly the same. Now we find continuing efforts to rework the architecture because various groups didn't get the 'minor' tweak they wanted. > > And while we're at it, you probably want to make it impossible for the ISP > to > even tell if it's a TCP SYN, otherwise they'll probably just filter them > *all* > out incoming... See tunneling comment above. > > > > Continuing work on IPv4 only creates the illusion that it is a > viable > > protocol for application developers to rely on for future income. > > Continuing work on IPv6 only creates the illusion that it is a viable > protocol > for the network as a whole to rely on for the provision of ubiquitous > datagram > substrate service. > > In anything even vaguely like its current form, that goal is completely > unreachable for IPv6, and the continued chanting of "IPv6 is the future" > only > prevents work on *feasible* upgrades that will allow the continued > provision > of ubiquitous datagram substrate service. Clearly work on IPv6 is not preventing work on changing the fundamental Internet architecture (see multi6). Turning your earlier argument around, there is nothing the IETF does or does not do that precludes the IETF from doing something else. What the IETF can influence is public perception (read that average developer on the street) by where it places a clear focus. From the outside, the IETF is continuing to work on IPv4, therefore the IETF doesn't believe it is a dead end. The average developer is not going to take the time to learn something different unless it is clear the market is going away from what he already knows. We can debate all day about how much influence the IETF has on the market, but given the current abundance of vendor participants, there is a clear path from standards focus to products available to the marketplace. Like it or not, we are at the end of the IPV4 road, and IPv6 is the only viable alternative. Anything that comes out of rearchitecting the Internet will be at least another 10 year process. I realize you would like things to occur much faster than that, but even IPv4 took over 10 years to make it out of the lab and into mainstream use (this is easy to overlook if you were so close to the action that you missed the forest for all those pesky trees). The market will adopt any technology that seems to solve the perceived problem cheaper than the alternatives. In a world of apps where consumer clients connect to publicly operated servers, IPv4 w/NAT is the cheapest approach. In a world with arbitrary app interactions, the cost of managing code development and NAT configurations/updates will easily exceed the cost of changing protocols. At the same time, anyone trying to make a sweeping one-shot change is just asking for pain. There are tools to make the change reasonably straight forward for the average network manager. Can the same be said for a completely new architecture? Tony