IPv6 traffic data in Asian networks?

Nick Hilliard nick-lists at netability.ie
Fri Mar 23 01:28:03 CET 2007


> Note Google is much more than just a search engine.   They're innovating
> in other areas too, and thus getting just one such Google project that
> shows a potential benefit to Google would be good.

GOOG and ${GOOG} companies are advertising resellers with a variety of 
front-ends, mainly search engines.

It makes no sense whatever for ${GOOG} companies to enable AAAA records 
for www.${GOOG}.com. They all provide a functional and reliable service 
over IPv4; by introducing IPv6, they will cause terminal reachability 
problems for a small number of people who use pathologically broken, 
older DNS servers.  Furthermore, for people with native ipv6 or IPv6 
tunnels enabled - whether by accident or design - connectivity almost 
certainly be substantially degraded compared to ipv4 connectivity.  This 
means loss of page views, customer dissatisfaction and ultimately loss 
of revenue.

Yes, there are counterexamples, but it is very often the case that v6 
connectivity is substantially poorer than v4.  Can we acknowledge this 
and move on?

We're network engineers and operators on this list, and we understand 
ipv6 connectivity reachability problems.  ${GOOG} companies cater for 
mom and pop who know nothing at all about how computers and networks 
work.  Are we seriously saying that they are ready for ipv6 yet?  I 
really don't think so.  The ipv6 DFZ is hazy and ill-defined; most ISPs 
don't support it at all; reachability is often poor (ARIN and RIPE are 
two cases in point where they should both have had sterling v6 
connectivity but didn't. That the IETF had serious connectivity problems 
is inexcusable); we still have crazy-assed networks providing transit to 
everyone (not going to mention any names here, but we all know some 
notorious candidates), and sloppy network management practices in the 
far east where commercial and NREN networks are not properly 
distinguished, causing all sorts of weird-ass connectivity problems, and 
packets from points A and B in Europe being routed through Seoul and 
Beijing.  And we're talking about the merits of enabling AAAA for the 
top most visited sites in the world?  How crazy is that?

Even worse, we still haven't got past the idea of building tunnels from 
point A to point B, and providing production connectivity service from 
6to4 and teredo relays.

Am I the only person around here who thinks that this is string and gum? 
  One thing's for sure - it's pretty damn lousy network design.

We also still have no v6 PI.  We have virtually no v6 on the last mile, 
and even less on the CPE side of things.  And we still have almost all 
of the problems that we discuss regularly on this mailing list - broken 
routers, silly filtering policies that go unnoticed for months, and so 
on and so forth.

Look, outside a few very specific examples, IPv6 is a plaything right 
now[1].  There is a possibility - and I stress that it's only a 
possibility - that when v4 space hits the wall in a short number of 
years time, that we can realistically start pushing v6 as a viable 
alternative.  A more likely scenario is that at least in the very short 
term, people will pile NAT upon more NAT, and horse trade in v4 space. 
It's not a scenario I like, but given the short-sightedness foisted upon 
us by laziness and quarterly SEC reporting, it is unfortunately the most 
likely one.

So what's the point of this rant?  Very simple:  right now, there is no 
point to ipv6, however unpalatable that view may be to us.  Despite all 
the years since the first v6 packets flew around test networks, it's 
still just a toy, primarily built and maintained as a hobby and for 
research purposes.  There is no commercial requirement for it and 
therefore little justification to spend time and money in implementing 
parity support with v4 connectivity.  However, because we are facing a 
hard wall in terms of v4 exhaustion, this provides probably the only 
real opportunity we'll ever have to prepare for a proper ipv6 internet.

The points below need to be brought home to the business decision makers 
in all our companies, who are the ultimate arbiters of what level of 
expenditure is assigned to v6 support:

1.  we're on a train running out of track.  There are a couple of years 
left to decide what to do when we reach the end of the line, but unless 
there is a viable alternative in place before RIR v4 space disappears, 
business expansion will likely be crippled.
2.  this will cause material loss of revenue and will affect the bottom 
line.
3.  IPv6 is a potential alternative for when the crash happens, even 
though v4 support will be a requirement for a very long time indeed.
4.  for access providers, given that CPE equipment has a lifetime of up 
to a couple of years, it is becoming important right now to ensure that 
the next generation of CPE equipment which is deployed either supports 
v6 or can be upgraded to support v6.
5.  implementation of v6 will cost time and money.
6.  if they choose to delay implementation of decent ipv6 support, as 
network operators we need a commitment to re-examine this position on a 
regular basis.

[and: that we also sort out the other operational policy issues soon - 
v6 PI space, beating up transit providers to provide a better v6 
service, stop using tunnels and pretending that they are suitable 
network links for a production service, and all of the other things we 
talk about]

Good ipv6 connectivity will not happen without expenditure, and business 
decision makers will listen only to issues that will affect the bottom 
line.  It's time to get out of our cubicles and talk to them about a 
future where public v4 space will be expensive and hard to get.

Nick,
now returning you to your regular schedule of "this isn't working; 
pkease fix"

[1] see the comcast talk on http://www.nanog.org/mtg-0606/durand.html 
for pretty much the only good example I've ever seen about why ipv6 
should be deployed on a particular service provider's network.


More information about the ipv6-ops mailing list