Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Author Topic: Trying to understand the main transition methods  (Read 4969 times)

milliamp

  • Newbie
  • *
  • Posts: 4
Trying to understand the main transition methods
« on: October 11, 2009, 01:41:03 AM »

Lets say I get a native IPv6 address from my ISP and I need to reach yahoo.com
I will attempt a AAAA lookup for them, and if they don't have one I will....
Try an A lookup instead and send my HTTP get request to some 2002::ya:h:oo address?

If this is the case, my ISP must handle all of traffic destined to 2002::/16 through some kind of gateway that will forward the packet as native IPv4 I suppose?

I have read through a handful of docs, I am just trying to wrap my head around a real world example.
Logged

jimb

  • Hero Member
  • *****
  • Posts: 805
  • ^^^ Warped picture
Re: Trying to understand the main transition methods
« Reply #1 on: October 11, 2009, 03:20:37 AM »

Lets say I get a native IPv6 address from my ISP and I need to reach yahoo.com
I will attempt a AAAA lookup for them, and if they don't have one I will....
Try an A lookup instead and send my HTTP get request to some 2002::ya:h:oo address?

If this is the case, my ISP must handle all of traffic destined to 2002::/16 through some kind of gateway that will forward the packet as native IPv4 I suppose?

I have read through a handful of docs, I am just trying to wrap my head around a real world example.
First, the 2002 addresses you are using wouldn't be what you would use if you were using native IPv6.  Anything starting with 2002::/16 is a 6to4 address.  6to4 is an automatic tunneling mechanism which aims to provide IPv6 connectivity to networks which only have IPv4 connectivity to the internet.  It works by forming a 6to4 IPv6 site prefix (/48) for your network or node by appending the network or node's public IPv4 address to the 2002 IPv6 prefix.   IPv6 subnets and addresses can then be assigned out of this /48.  Your 6to4 router will tunnel your IPv6 traffic to the IPv6 internet via 6in4 to the well known IPv4 anycast address for 6to4 tunnel servers (the anycast routes the IPv4 encapsulated IPv6 traffic to "closest" 6to4 tunnel server).  Your IPv6 traffic then enters the IPv6 internet.  Return IPv6 traffic is ultimately routed to a 6to4 tunnel server (because the 2002::/16 routes on the IPv6 internet will ultimately lead to one), where they'll be tunneled back to your 6to4 router via 6in4, your 6to4 router's IPv4 address having been extracted from the IPv6 address.  

Second, as for DNS, if a site doesn't have an IPv6 address, and you are dual stack, you will simply use IPv4 to talk to the site.  If you're IPv6 only, then one of many solutions must be used to talk to the IPv4 internet.

There's a bunch of transition methods for native IPv6 to get to the IPv4 internet.  Things such as TRT, NAT64/DNS64, and Dual-Stack Lite.  With TRT and NAT64/DNS64, a special DNS server called a DNS Application Level Gateway (DNS-ALG) is required which translates IPv4 addresses into fake-prefix IPv6 addresses containing the IPv4 destination.  Your router/network is set up to route this fake IPv6 address to a gateway which will get your IPv6 traffic to talk to the IPv4 internet using one method or another.  

One method, TRT acts sort of like a proxy, talking to the IPv4 internet with the TRT gateway's own IPv4, and relaying the return traffic back to your IPv6 only node, which thinks it's talking native IPv6.  Another, NAT64 works similarly, but instead of using a "proxy", ultimately routes the fake-prefix IPv6 traffic to a Carrier Grade Nat (CGN) device located at your ISP which NATs your IPv6 into a public IPv4 in a similar fashion to "normal" IPv4 NAT (e.g. it remembers the address/port mappings in a connection table and translates the return traffic back based on these table entries).  In both of these methods, the gatway pulls the outbound destination IPv4 from the fake-prefix IPv6 address which the DNS-ALG handed to your IPv6 only node.

Dual-Stack Lite uses another approach entirely, tunneling your IPv4 traffic to a CGN device located at your ISP over an IPv6 based tunnel.  Sort of like 6in4 in reverse.  The beauty of this approach is that IPv4 addresses from multiple customers can overlap, and the CGN sorts it all out by putting the tunnel ID from which the given IPv4 traffic came into the connection table.  So you can have multiple people using, say, 192.168.0.100 via the same CNG, and it can figure out which is which based on the tunnel it came from and its associated IPv6 source address.  Also, since you're tunneling IPv4 over IPv6, there's no need to fake up an IPv6 address.  The end nodes just use IPv4.  The CGN device is really just doing a modified version of IPv4/IPv4 NAT, and stuffing the return traffic down the appropriate tunnel.  Neat eh?  BTW, DS-Lite was developed in part by Comcast, and is likely what they will use for their IPv6 only customers in the future.

You can read about all this in gory detail from links located here:  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms
« Last Edit: October 11, 2009, 03:31:54 AM by jimb »
Logged

milliamp

  • Newbie
  • *
  • Posts: 4
Re: Trying to understand the main transition methods
« Reply #2 on: October 12, 2009, 05:42:05 PM »

OK, so if I may ammend my question with a follow-up, if my ISP gives me both an IPv4 and IPv6 address (dual stack), is there a need for them to deploy any of the transition methods you describe?
Logged

jimb

  • Hero Member
  • *****
  • Posts: 805
  • ^^^ Warped picture
Re: Trying to understand the main transition methods
« Reply #3 on: October 12, 2009, 06:00:54 PM »

OK, so if I may ammend my question with a follow-up, if my ISP gives me both an IPv4 and IPv6 address (dual stack), is there a need for them to deploy any of the transition methods you describe?
Yep.  No need at all.  You'll be able to talk IPv4 or IPv6 to anyone.  Typically, I've found that windows and linux boxes are configured so that if there's a global unicast IPv6, it prefers it over IPv4, but for Teredo IPv6, it prefers IPv4, etc.  All controlled by ip addrlist & /etc/gai.conf on *nix, and I believe "netsh int ipv6 show prefixpolicy" under Windoze.  

The IPv6 -> IPv4 (TRT, NAT64, DS-Lite, yadda yadda) solutions are designed for people who are stranded on an IPv6 only island and still need to talk to the IPv4 networks.  The IPv4 -> IPv6 (6in4, 6to4, Teredo) solutions are designed for people who are stranded on an IPv4 only island and need to speak to the IPv6 internet.  As IPv4s get more scarce and expensive in the future, ISPs will have no choice but to only give new customers IPv6 space.  This is one of the reasons Comcast has been researching this and has come up with DS-Lite as one of the possible (likely) solutions they will use for customers in this situation.

I'm not very familiar with any IPv4 native <-> IPv6 native translation methods, but I think this is also under consideration, although I don't really see the point since to me it'd be better just to do something like 6in4 or 6to4, or just go to IPv6.  Plus such things would also slow IPv6 adoption.  :P

EDIT:  I recently read this article, which goes over all the current IETF proposals for these transition mechanisms.  It's pretty intresting:  http://tools.ietf.org/html/draft-wing-nat-pt-replacement-comparison-02
« Last Edit: October 12, 2009, 06:34:47 PM by jimb »
Logged