-----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Friday, September 21, 2012 9:13 AM To: Tony Hain Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8
On 21/09/2012 00:47, Tony Hain wrote:
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.
Address translation (already commonplace on many networks) is the consequence of the lack of a scalable addressing model. Yup, NAT breaks lots of things. Piles. It sucks.
Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'.
Networking people build and (in some cases) care about networks. It's not the job of nanog people to fret about software development.
The real costs are in app development and support
It's certainly one of the costs. And application developers have only just begun to realise that they now need to be aware of the network. Previously, they could just open up sockets and fling data around. Now they need to handle protocol failover and multiple connectivity addresses and the like. Yep, it's an extra cost point - one which has been studiously ignored by most ipv6 evangelists over the lifetime of ipv6.
App developers have never wanted to be aware of the network. As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality. The only place IPv6 gets involved is that it offers a way back to the transparent end-to-end consistent addressing model. The actual path may have firewalls which prevent communication, but that happens on both versions and has nothing to do with the simplicity of a consistent addressing model.
That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street,
Most organisations are in this category, not just those beholden to the whims of Wall Street.
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.
There are never shortages of fingers when failures happen, whether they be used for wagging or pointing.
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.
6to4 is full of fail. Inter-as tunnelling is a bad idea.
Asymmetric inter-as tunnelling is worse, and asymmetric inter-as tunnelling based on anycast addresses with no hope of tracing blackholes is complete protocol fail.
Despite the total failure that it causes the ipv6 world, we couldn't even agree on v6ops@ietf that 6to4 should be recategorised as historical. My facepalm ran over my wtf.
But really, 6to4 is a minor player.
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.
I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because the network operator has control over all points along the way. It fixes
And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric. the
problem of having eyeball access devices which don't support v6 properly. Don't hate it - it's useful for some operators, and quite good for deploying v6 over an older infrastructure.
There is no 6rd hate here. I personally spent many hours helping Remi tune up the original doc and get in into the IETF process. My point was that we didn't need to go through that entire process and have extended policy discussions about what size prefix each org needs when they are deploying 6rd. At the end of the day, a 6to4 relay at every point that has a 6rd router does exactly the same thing at the tunneling level (except that 6to4 always results in a /48 for the customer). It may have resulted in more prefixes being announced into the IPv6 table, but given the ongoing proliferation of intentional deaggretation for traffic engineering, there may eventually be just as many IPv6 prefixes announced with 6rd.
So far neither MSFT or AAPL has been willing to push hard on the app development community.
This is a generic awareness problem in the developer community and it's
not
microsoft's or apple's business to tell them what to do about it. Deprecating historic APIs is fine, but you cannot force an application developer to do what they don't want to do. Software didn't get ported from ipx and decnet to ipv4 just because the compiler manufacturers nagged the developers about it.
Those ports happened because there were more endpoints reachable directly without having to deal with network layer gateways and translators. IPv4 lost that with RFC 1597, and with the layering of the problem that is ahead, the app community will be driven away. MSFT & AAPL can't make the app developers change, but they can offer a path to make their life easier. If one does so and word starts to spread that "it is easier to build and support location aware apps on platform Z", expect the other to announce the same tool set to counter that. In some ways I am surprised that GOOG hasn't already started something like that for the 4G android devices, but maybe it just hasn't gone public yet ...
IPv6 will become commonplace when there is a compelling reason for it to
do
so. History tells us that it won't happen before this point.
And network managers that are squeezing the balloon to over optimize their part of the system without concern for the rest will provide the compelling event. Those that are doing so intentionally, while providing the long term path in parallel, can be described as weaning their customers off the legacy. Those that are doing so inadvertently, because they don't care about anything but their tiny part of the overall system, will lose customers to the provider offering the long term path. Tony
Nick