[arin-ppml] IPv6 Heretic thoughts

[John Santos]

On Fri, 5 Sep 2008, Dan White wrote:

> Cliff Bedore wrote:
> > I read it and am impressed that you have gone as far as you have. I
> > think you will have to admit you are not a typical CEO in a typical 
> > for-profit company and are probably in the very small minority of 
> > entities who have gone gung ho for IPv6.  As you point out, lots of 
> > people bought Beta video players, HD DVD.  Hell I was a big proponent of 
> > CPM86/Concurrent CPM/86.  It was a much better system than MSDOS but 
> > that didn't make it a success.  And don't get me wrong.  I'm not 
> > particularly anti-IPv6 but it's just NOT happening in most of the 
> > world.  It doesn't seem like we're going to get a disruptive application 
> > for IPv6 so we need another hook to get people to buy in.  The only one 
> > I see is to get IPv6 and IPv4 talking transparently so we don't need 
> > dual stack and people can keep resources that use IPv4 and get to IPv6 
> > as progress and funds allow.  No one wants to go to IPv6 by itself 
> > because there is too much IPv4 they couldn't reach.  Dual stack is a 
> > kludge(IMO).  We need transparent communication between them and without 
> > that, I don't believe IPv6 will take off in my lifetime.
> >
> > Cliff
> >   
> 
> I think there's an implication in this line of reasoning that IPv6 is 
> hard, and that dual stack is bad.
> 
> Dual-stack IPv4/IPv6 is easy. You just enable it in your OS, or perhaps 
> it already is. IPv4 continues to work uninterrupted, dual stack servers 
> are reachable and IPv6 only sites are reachable. I don't really see any 
> downsides to this approach except for inevitable bugs and issues that 
> are bound to pop up with new technology.

I think there are 2 serious issues with this.  1) It doesn't immediately
get you anything (with IPv4 runout) because each dual stacked host
needs *TWO* addresses, an "easily obtainable" IPv6 address and a scarce
IPv4 address.  2) Due to the way IPv6 defaults (apparently this is
defined in the specifications), it tries an IPv6 connection 1st and
then fails back to an IPv4 connection.  If the destination host is IPv4
only, then this isn't much of a problem (the DNS lookup for an IPv6
address will fail, but the originator will find an IPv4 address quickly
and use that, which will just increase connection setup time a bit),
but if the destination is dual-stacked also, but the IPv6 connectivity
isn't there yet, there will be *long* timeout delays while the source
tries to set up a session over IPv6.  Can you imagine the support
calls from people saying "why is it taking me a minute to connect to
google while I can connect to other places right away?"

So it's not that dual-stacking is *bad*, but it just isn't too
helpful until the infrastructure is up to snuff, and you can start
introducing IPv6-only hosts.  But to support existing IPv4-only
hosts, *all* publicly accessible servers will have to be dual-stacked
for the forseeable future.  (Someday, someone at Amazon or similar, or
at one of the major IP transport companies will make an execute decision
that they have to little remaining IPv4 traffic to justfy the support
costs, and will decree "turn it off!", and few people will notice.
Then, based on that precedent, lots of corporate IT departments will
make the same decision, causing a disaster of Y2K proportions, as
they discover all the little DOS boxes and PDP-11's running the
steel mill are IPv4-only and don't work with the new routers.  :-)



> 
> Of course, this is an overly simplistic scenario, but my point is that 
> it's supposed to be easy for customers. It's not their job to worry 
> about all the network engineering involved to make this happen. As a 
> service provider, or network manager, it's your job, in my opinion, to 
> engineer the network to support easy access to IPv6 and to figure out 
> all the hard stuff for the benefit of your users. If engineered 
> correctly, IPv6 deployment should be nearly unnoticeable to the majority 
> of typical Web/Email users.

I'm not a service provider, so I guess I don't have to do anything ;-)
However, at least one of our customers has asked about IPv6 on their
internal network, with the implication that they want it soon.  (We
supply database management systems to the Telecom industry, and this
customer has a bunch of our systems.)  Since they are also a major ISP,
I think that would be of interest to the people who are asking what the
big ISPs are doing about IPv6, but I don't know if this is public
knowledge, so I can't identify them further.


> 
> Networks are certainly different, and there are many barriers to entry 
> (consumer routers being a big one) but making roll out as easy as 
> possible for service providers, using translators and proxies and such, 
> should not really be our primary goal.
> 
> Also, IPv6 was not designed as a product. It should not really depend on 
> residential demand. It's a protocol designed to address the short 
> comings of IP4 and should be used as a tool to provide better service, 
> or service where it would not be feasible.

I think residential demand is what has driven the exponential growth
of the Internet and is what has caused the IPv4 runout and the need
for IPv6 in the first place?  Does ARIN have anyway of knowing this?
(If ISPs mostly catered to business or mostly to residence, you could
estimate, but I think most ISPs, except the ones selling only T1 or
faster service on dedicated lines, cater to both markets, so you can't
just divided up the allocations into two piles, and I doubt ISPs need
to or would want to provide this information to ARIN when requesing
new allocations.  Direct assignments (PI) are probably almost all to
medium or large businesses or educational users, but I would think they
are actually a very small slice of the pie compared to ISP allocations.)


> 
> - Dan
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539