> -----Original Message----- > From: Nick Hilliard [mailto:n...@foobar.org] > Sent: Thursday, September 20, 2012 2:37 PM > To: Tony Hain > Cc: nanog@nanog.org > Subject: Re: The Department of Work and Pensions, UK has an entire /8 > > On 20/09/2012 20:14, Tony Hain wrote: > > Once the shift starts it will only take 5 years or so before people > > start asking what all the IPv4 fuss was about. > > Tony, ipv4 succeeded because it was compelling enough to do so (killer apps > of the time: email / news / ftp, later www instead of limited BBS's, teletext, > etc), because the billing model was right for longhaul access (unmetered > instead of the default expensive models at the time) and because it worked > well over both LANs and WANs (unlike SNA, IPX, decnet, etc). > > ipv6 has none of these benefits over ipv4.
You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user. > The only thing in its favour is a > scalable addressing model. Other than that, it's a world of pain with > application level support required for everything, poor CPE connectivity, lots > of ipv6-incapable hardware out in the world, higher support costs due to > dual-stacking, lots of training required, roll-out costs, licensing costs (even on > service provider equipment - and both vendors C and J are guilty as accused > here), Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. The real costs are in app development and support, so crap in the middle of the network (which is only there to keep the network managers from learning something new) will be worked around. While shifting apps to IPv6 has a cost, doing that is a onetime operation vs. having to do it over and over for each app class and new wart that the network managers throw into the middle. IPv4 even with all its warts makes a reasonable global layer-2 network which IPv6 will run over just fine. (Well mostly ... I am still chasing a 20ms tunnel asymmetry which is causing all my IPv6 NTP peers to appear to be off by 10ms) > poor application failover mechanisms (ever tried using outlook when > ipv6 connectivity is down?), etc. Outlook fails when IPv4 service is lame (but I could have stopped at the second word). I use Outlook over IPv6 regularly, and have had more problems with exhausted IPv4 DHCP pools than I have with Outlook over IPv6 in the last 10 years. > > The reality is that no-one will seriously move to ipv6 unless the pain of > address starvation substantially outweighs all these issues from a business / > financial perspective. It may be happening in places in china - where there is > ipv4 significant address starvation and massive growth, but in places of > effectively full internet penetration and relatively plentiful > ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages > substantially outweigh its sole advantage. That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, then you will have a hard time making a case before the customers have started jumping ship in significant enough numbers that you will never get them back. If your time horizon is measured in decade units, you will have an easier time explaining how a 5 year roll out will alleviate costs and minimize pain down the road. Most of the press and casual observers didn't get the point of the 2003 DoD/US Fed mandates for 2008. That date was not picked because they believed they needed IPv6 in production by 2008, it was picked because they had significant new equipment purchases starting at that point that would be in production well past the point when it becomes likely those devices will find themselves in some part of the world where 'IPv6-only' is the network that got deployed. The only way you turn a ship that big is to set a hard date and require things that won't make sense to most people until much later. > > I wish I shared your optimisation that we would soon be living in an ipv6 > world, but the sad reality is that its sorry state bears more than a passing > resemblance to the failure of the OSI protocol stack. If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion. In any case, the end system stacks that are less than 10 years old are ready, so the missing component is to get the app vendors to switch api's. That has been difficult since they are waiting for a network, and the network managers are waiting for apps. The entire point of the transition technologies was to break the dependencies and deadlock. The part that didn't happen that should have was for MSFT to fix DevStudio to constantly scream at the app dev about using a deprecated API, thereby getting them to shift to the new one just to shut the compiler up. If the apps are using the new api, they will continue to use IPv4 if that is all DNS gives them, but as soon as DNS is updated with a AAAA record, all that traffic will shift, and tunnel if it has to. That plan makes network managers upset, because they want to be in control, but if they really want that control they have to get out in front and deploy native IPv6 so the tunnel never starts, or is managed between routers they control. Again the vast majority of the support cost is at the edges, so it is cheaper from the edge perspective to ignore and tunnel over the middle if it is not ready. I focused on MSFT above, but AAPL could do the same at the drop of a hat if they chose to. Consider the impact if AAPL chose to change the requirement for an app to be in the iTunes store such that it 'had to work over an IPv6-only network, and could work over an IPv4 network'. If they coupled that with bundling miredo in the OS X & iOS updates, then published a few AAAA records, the network managers would be blinded to what their customers are doing overnight. All they would see was a vast shift to udp, while the app developers would see cheaper support costs after the initial investment to change api's. So far neither MSFT or AAPL has been willing to push hard on the app development community. If the network managers keep making life harder by inserting even more nonsense into the network, they won't have to do more than suggest there is an easier way, and packet shuffling will become even more of a commodity than it already is, because the endpoints will be working in a different space and immune to changes in service providers. Yes life in the core looks pretty dismal right now, because bean-counters lack vision. Those bean-counters will find replacement jobs though at the ISPs offering IPv6 once the customer base has abandoned the IPv4-only one. The people that will have trouble finding new work will be the ones that should have shouted down the bean-counters and pointed out the cliff they were driving the failed company over. Tony > > Nick
