The Department of Work and Pensions, UK has an entire /8

Thu Sep 20 23:47:47 UTC 2012

> -----Original Message-----
> From: Nick Hilliard [mailto:nick at foobar.org]
> Sent: Thursday, September 20, 2012 2:37 PM
> To: Tony Hain
> Cc: nanog at 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