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

["Tony Hain" <alh-ietf () tndh net>]

> -----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.  

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. 

> 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
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