>> Doubt it all you want. Once it's gone, it stops generating support calls, or >> they become very short: >> >> C: "Hi, my application isn't working through my NAT." >> TSR: "Hi… Get IPv6, we don't support NAT any more." >> TSR: "Is there anything else I can help you with today?" > > C: "Hi, my application isn't working between me and my grandmother" > TSR: "Hi... Get IPv6, we don't suppotr NAT any more." > C: "Screw you guys... my grandmother isn't served by an ISP that is offering > IPv6 and her old operating system barely supports it anyway. Please refund my > money." >
Point is that Grandma's ISP will support IPv6 by the time this comes to pass, or, Grandma will be 1/10,000 and the ISV will either cheerfully refund the price of the application in those limited circumstances, or, say "I'm sorry, we don't offer refunds. You're welcome to continue using the old version which includes NAT traversal." In either case, there are some customers that it's just too expensive to maintain vs. what you get from them. Once IPv4 ceases to be the internet lingua franca, the ones clinging to it will rapidly fall into that category. > The point being that for some applications, *both ends* need to be on IPv6 > before any of this complexity can go away. Point being that once a sufficient set of end points is on IPv6 that the market share lost by not supporting IPv4 and/or IPv4 NAT traversal will stop getting supported. Just like many developers don't support the 10+% of us that use Macs, the 5% or less that don't have IPv6 in a few years will fall off the supportability list. > For the rest, they're just talking to web services... and until the places > those are hosted run out of IPv4 addresses, nobody cares. I don't think this is anywhere near as large a userbase as you think these days. >> NAT will most likely become a thing of the past. I know you prefer to remain >> in denial about this, but more and more of the ISVs I have talked to are >> saying that they have no intention of adding NAT traversal to their IPv6 >> code. > > I'm not in denial about this. I just don't think IPv4 is going away in the > next 30-60 days... and so my next one to two releases, which is what I'm > engineering for this week, need to support it, and NAT traversal, and all > that. > It'd be nice if they supported IPv6 as well, but really when you rank on a > big list all the things customers are demanding, IPv6 is *way* down that list. If you're not looking past 60 days, then we're not having the same conversation. What will exist in the next 30-60 days is already determined, so any discussion of positive change to that situation is pretty much irrelevant as it can't possibly come to fruition. >> The firewall shouldn't be adjusting the packet. I'm not sure why you think >> it would or what adjustments you think it would be making. > > Option stripping, Diffserv scrubbing, all sorts of things that make the > packets no longer identical. Perhaps I should have said "identical enough to be readily recognizable using the same tcpdump filter string." As long as they don't change the IP addresses or the port numbers, that's pretty much the case. Mucking with the other things is undesirable, but not fatal. >>>> Finally… There are 7 billion people on the planet. There are 2 billion >>>> currently on the internet. >>>> >>>> The other 5 billion won't fit in IPv4. If you want to talk to them, you'll >>>> need IPv6. >>> Or a very big CGN. >> If you think this will actually scale and provide a user experience that >> will be considered at all acceptable, then you are delusional. > > For most web and web-service based applications, it'll work just fine. Which is about 60% of modern internet traffic. The remaining 40%... > In the "long run", sure, it runs out of steam... but I'm already talking > about times way sooner than your 5-8 years. I think you will be surprised how fast it runs out of steam even for web services. On any sort of a large customer-base scale, it very quickly becomes a maintenance and support nightmare. >> I don't think that's actually true. I think that the economic incentives to >> drop IPv4 support from the inter domain world as soon as possible will apply >> strong pressure to expedite this process once IPv6 achieves a certain level >> of critical mass. > > Yes... and will that "certain level of critical mass" happen before the end > of this June? If not, all it means is extra work, not less. Granted, it's much more work at first and a little work as long as IPv4 maintenance is required. If your application was stupidly designed such that it's unnecessarily difficult to add dual-stack support, then it's even worse. However, you're having a 60 day conversation while I'm talking about considerations applicable to something on an enterprise-roll-out time table (most likely closer to 24 months than 2 and probably 12-18 months of preparation before the roll-out starts in earnest). > >> >>> Trying to sell this to smart engineers writing code or testing it as "less >>> work" is just going to get you laughed out of the room as the crazy IPv6 >>> zealot. >> Actually, smart engineers realize that in the long run it's a lot less work. > > Yes. In "the long run"... which is way farther out than the backlog for the > current sprint or even release, I'm afraid. 1. You're talking development, I'm talking enterprise. 2. You're talking immediate action, I'm talking enterprise rollout timescales. >> That there's a brief period where it's way more work followed by a much >> better long-term. > > That "brief period" lasts longer than most software startups are in > existence. Your shortest prediction was 5 years... an eternity, still. So > right now, today, when you take the powerpoint deck to the engineers, you are > asking them to do >2x the work, starting now, for some unknown future > benefit... likely after they are either 1) working somewhere else or 2) the > entire operation has been acquired by someone else. 5 years from now. Given the speed with which the average enterprise moves on an undertaking like this, that's probably not much more than 12 months after they deliver IPv6 to the desktop. > >> I'll leave off the obvious question about how smart can engineers be if they >> built an application in the 90s that was as strongly tied to unistack as >> Skype is when it was obvious that unistack IPv4 was a very temporary >> phenomenon. > > Well maybe it wasn't that obvious in Estonia in the early 1990s. When I wrote > my P2P stack in the same era, it supported both IPv4 and IPv6, and a version > of that is what is in every copy of Flash Player. Working *and tested* to > support IPv6. If you were on the internet, it's hard to imagine how you missed the fact that we knew we were going to run out of IPv4 addresses fairly quickly back then. If you learned enough about NAT to know about doing NAT traversal, odds are pretty good that you knew that address exhaustion was driving NAT and that IPv6 was the longer term solution while NAT was a hack to get us by until then, > > Matthew Kaufman
