Automatic 6to4 IPv6 Tunnels

[JohnTylerPearce]

Hey Guys,

I understand this implementation pretty well, I'm just having trouble understanding one important part. I understand that if you have R1<--->R2,

with IPv4 connectivity, and then R1 and R2 also each has an IPv6 network on the LAN side, you're address will be 2002::/48, but the bits after

2002:xxxx:xxxx will be the IPv4 source address of the tunnel in hexadecimal. I know you need a route saying to get to 2001:DEAD:BEEF::1/64

goto tunnel0 (etc etc). It will know how to get there automatically by going to 2002:303:303:x.y (Which I'm assuming is the IPv4 remote address in hex)

but how does it know to go to 2002:303:303: automatically........

Im assuming that R1 has physical IP going to R2 of 1.1.1.1 and R2 has a physical IP of 2.2.2.2 going to R1.

[Nagendra Kumar Nainar]

Hi John,

As you said, the Automatic 6to4 address is of format 2001:v4-addr::/48. On each border node connecting v4 and v6 domain, you will have a static route poiting to the tunnel (on which you have automatic 6to4 enabled).

In the above topology, you can see that Left_Router on receiving IPv6 packet from the PC destinated to 2001:4545::4 will perform recursive lookup and derive the egress interface as tunnel 24.

Now Tunnel 24 is multipoint tunnel (like NBMA) and it uses the nexthop v6 address to derive the IPv4 nexthop. In this case, the nexthop to reach 2001:4545::/64 is 2002:9602:404::4. (9602:0404 is 150.1.4.4) and send the apcekt to 150.1.4.4.

HTH,

Nagendra

[James Leinweber]

In the classic 6to4 scenario, you would be depending on the existence of two additional 3rd party relay routers.  The relay routers would be anycasting 192.88.99.0/24 on the v4 side and 2002::/16 on the v6 side.  Typically the sending client would only have v4 connectivity, not v6.  Some operating systems build in 6to4 tunneling, and some endpoints might be dual-stack, so the number of relays could be reduced.

Sender:

    1. client v6 encapsulated-->192.88.99.1 via next hop R1

    2. R1 -> dual stack relay A (advertising 192.88.99.0/24) via v4

    3. relay A -> v6 destination via R2

    4. R2 -> destination server (v6)

On the reply path,

    5a dual-stack server with embedded 6to4 encapsulates reply directly to client IPv4 address via R2

  or

    5b IPv6-only server sends native v6 reply to relay B at 2002::/16 via R2 using IPv6

    6a R2 forwards v4 packet toward final destination

    6b R2 forwards v6 packet toward dual stack relay B (advertising 2002::/16)

    7a relay B is not involved if the server did its own 6to4 encapsulation

    7b relay B encapsulates the v6 packet in a v4 envelope addressed to the decoded v4 address of the client

    8 R1 receives a v4 encapsulated packet via either R2 or relay B, depending on step 5 choice

    9 client decapsulates v6 reply from v4 envelope received from R1

Geof Huston and others have described why automatic tunnels like Teredo and 6to4 are a bad idea, e.g.

http://www.potaroo.net/ispcol/2010-12/6to4fail.html

-- Jim Leinweber, WI State Lab of Hygiene

[JohnTylerPearce]

Thanks guys for all the help. I'm pretty sure I got this done right now.

So let's say I have R1<---------->R2

R1 has

---------

gi0/0 - 2001:DEAD:BEEF:1111::1/64

WAN - 100.100.100.1

R2 has

---------

gi0/0 - 2001:DEAD:BEEF:2222:1/64

WAN  200.200.200.1

So when Host-A on R1 needs to send a IPv6 packet to 2001:DEAD:BEEF:2222::50 it will send out an IPv6 packet wth that as the destination and the source IPv6 address of 2001:DEAD:BEEF:1111::50. Once it reaches R1, it will go out through the tunnel (for this example Tunnel0), and will get encapsulated into an IPv4 packet with a source address of the "tunnel source" address such as 100.100.100.1 and a destination address of the next-hop IPv4 address specified in the route statement.

For example: ipv6 route 2001:DEAD:BEEF:2222::/64 2002:C8C8:C801::

So R1 will have an IPv4 next hop ip address of 200.200.200.1 when the destination is an IPv6 address within the 2001:DEAD:BEEF:2222::/64 network.

Does that sound correct guys?

[James Leinweber]

What you are describing is a point-to-point tunnel scenario, typically called "6in4" as distinct from the 3rd-party anycast relay scenario called "6to4".  Point-to-point tunnels aren't automatic and don't scale well, but are indeed one of the most preferred mechanisms for v6 traffic to cross IPv4 moats, as described in e.g. rfc4213.

6to4 anycast relay is described in rfc3056; there is follow-on advice in rfc's such as 6343 and 6732.  It's falling out of favor due to a combination of performance issues, reliability issues, and its absolute need for an unshared public client IPv4 address.  ISP's which aren't fully dual-stack or native v6 on their backbones are much more likely to deploy 6rd (rfc5969) and 6PE (rfc4798) as interim measures instead.  They can still be fully dual-stacked at the CPE side and their border routers while they are working on their backbone, with only a minor MTU and latency hit.

The v6 transition has a zillion tunneling proposals, and a lot of them share the protocol 41 encapsulation (IPv4 header fronting an IPv6 payload), including 6in4, 6to4, ISATAP, and 6over4.  Look up "6over4" if you want to boggle at the ways people thought up of abusing multicast.

FYI, both IPv4 and IPv6 have designated prefixes for use in published examples.  For v6 the prefix is 2001:db8::/32; for v4 any of 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 as described in rfc's 3849 and 5737.

With the exhaustion of v4 address space and dual-stacking of all the tier-1 backbones, most of the tunneling excitement is now focused on the converse problem of carrying tunneled v4 over native v6 backbones. 

Best wishes,

-- Jim Leinweber, WI State Lab of Hygiene