North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IPv6

  • From: Joe St Sauver
  • Date: Sun Jun 15 14:09:56 2003

Hi,

The real question when it comes to IPv6 is "What happens if I ignore it?"

At one level, the obvious answer is "Nothing, the planets all continue to 
spin." It is clearly still a unicast IPv4 world out there. At another level:

-- There are numerous free tunnel brokers out there; random users can and 
   will get tunnelled v6 connectivity if native v6 connectivity isn't 
   available. Some *might* assert that transcontinental/intercontinental
   tunnels aren't the best thing for the network (from a global perspective) 
   for a variety of reasons...

-- There are various 6to4 gateways out there, and they, too, are getting used.
   If you enable IPv6 on XP, for example, by default 6to4 gets turned up. 
   Some might assert that 6to4 gateways provided by <fill in the blank> might
   not be the best thing for the network (from a global perspective) for a 
   variety of reasons...

-- While you ignore v6, some of your competitors aren't. They're getting
   address space, they're getting their router issues worked through, they're
   getting their DNS servers squared away, they're working out local 
   addressing plans and figuring out application support strategies. They're
   getting experience before they need it for production requirements, and
   while it is still non-embarassing to be "just coming up to speed." 

-- Or consider IPv6 in higher education as an indication that IPv6 may be 
   becoming ripe for easy deployment/may be beginning to become "real". At 
   least for most of the ten or so measurement peers shown at 

   http://amp.nlanr.net/active/cgi-bin/v6_sitesummary.cgi?
   amplet=amp-uoregon&date=103.6.15

   you'll see v6 performance that's roughly comparable to v4 performance. Yes,
   this is across Internet2/Abilene, but at least for IPv6, Abilene has been 
   peering with commercial v6 entities when everyone's in the right spot(s) 
   and it makes sense to do so. 

I understand that in some cases hardware choices make v6 deployment hard (if 
not impossible), and that more v6-incompatible-hardware is unquestionably
getting purchased out there as I write this. I understand that lots of 
applications still aren't ready. And I understand that customers aren't 
beating down your door saying, "Hey, when can I get IPv6?" (just as they 
probably haven't beaten down your door asking about IP multicast in a 
commercially meaningful way). 

On the other hand, I do believe that IPv6 is one of those technologies that
will creep up on folks (if they aren't careful) simply because it does NOT
require "top down" deployment to get a toehold, and the fact that ISPs
AREN'T paying attention to it.

For example, even if many folks carefully track/shape/police IPv4 P2P
traffic, or block cusotmer servers, I'd be willing to bet that most folks 
pay zero attention to their current v6 traffic (whether native, tunnelled, 
or gatewayed)... 

And there *ARE* v6 P2P applications out there (the most notable of which is 
probably Microsoft's 3 degrees), although others are rumored to be porting 
their P2P applications to run dual stack. [There's a nice post about 3 degrees 
entitled "Operational experience with 3 degrees" by Christian Huitema at 
http://dict.regex.info/ipv6/v6ops/current/0183.html if folks are interested.]

And if you aren't paying attention to "Teredo" as a technology, you might want
to see http://www.microsoft.com/windowsxp/pro/techinfo/administration/
p2p/overview.asp -- quoting from that piece,

     Teredo, also known as IPv4 network address translator (NAT)
     traversal for IPv6, is an IPv6/IPv4 transition technology that
     provides address assignment and host-to-host automatic
     tunneling for unicast IPv6 connectivity when IPv6/IPv4 hosts
     are located behind one or multiple IPv4 NATs. To traverse
     IPv4 NATs, IPv6 packets are sent as IPv4-based User
     Datagram Protocol (UDP) messages. [continues...]

Regards,

Joe St Sauver ([email protected])
University of Oregon Computing Center