6to4 IPv6 Tunneling

By stretch | Monday, March 15, 2010 at 12:29 a.m. UTC

"6to4 tunneling" is an IPv6 transition mechanism described in RFC 3056. Like many other transition mechanisms, it enables encapsulation of IPv6 packets into IPv4 for transport across an IPv4 network. What's really neat about 6to4 is that it allows for automatic IPv6-to-IPv4 address translation, and treats the underlying IPv4 network as one big non-broadcast multiaccess (NBMA) network, rather than a collection of independent point-to-point links.

Consider the following topology:


Three sites, each with its own IPv6 LAN, are connected to one another via an IPv4-only backbone. One way to connect the IPv6 LANs would be to configure individual point-to-point IPv6-in-IPv4 tunnels, so that each site would have an individual tunnel interface to reach every other site. This is a fair solution for our scenario with only three sites, however it obviously does not scale well, requiring n(n-1)/2 tunnels for n sites (e.g. ten sites would require 45 tunnels for full mesh connectivity).


A more efficient solution would be to use automatic 6to4 tunneling. 6to4 works by taking advantage of a reserved IPv6 prefix, 2002::/16. A 6to4 tunnel interface automatically converts the 32 bits in its IPv6 address following this prefix to a global unicast IPv4 address for transport across an IPv4 network such as the public Internet. Before digging any deeper into the theory behind 6to4 tunneling, let's look at the configuration involved.

6to4 Configuration

To configure 6to4 tunneling, we first need to create a tunnel interface on each dual-stack edge router. There are three key components relevant to 6to4:

  • The tunnel mode (6to4)
  • The tunnel source (IPv4 interface or address)
  • The 6to4 IPv6 address (within 2002::/16)

On R1, we create the tunnel interface, configure it as 6to4, and specify its cloud-facing IPv4 interface as the tunnel source:

R1(config)# interface tunnel0
R1(config-if)# tunnel mode ipv6ip 6to4
R1(config-if)# tunnel source

To the determine the IPv6 address of the tunnel interface, we convert the IPv4 source address to hexadecimal in IPv6 notation, so that becomes 0a00:0101. then we append it to the 6to4 prefix (2002::/16), and fill the remainder of the address with zeros. Host masks (/128) are used for 6to4 addresses in this article, although other prefix lengths (and addresses within the /48) can be used as well.

R1(config-if)# ipv6 address 2002:a00:101::/128

This process is repeated to create 6to4 tunnel interfaces for the two other sites as well. Only a single tunnel interface is needed per router.

R2(config)# interface tunnel0
R2(config-if)# tunnel mode ipv6ip 6to4
R2(config-if)# tunnel source
R2(config-if)# ipv6 address 2002:a00:201::/128
R3(config)# interface tunnel0
R3(config-if)# tunnel mode ipv6ip 6to4
R3(config-if)# tunnel source
R3(config-if)# ipv6 address 2002:a00:301::/128

Note that, unlike when configuring point-to-point tunnels, we have not designated any tunnel destination addresses.

Now that the 6to4 address of each router is known, we can go back and add the necessary static routes to achieve IPv6 connectivity between all three routers. Three static routes must be added on each router. The first indicates that 2002::/16 is reachable out of interface Tunnel0. The other two are routes for the individual /64 prefixes at either of the other sites, which are to be routed via the 6to4 tunnel.


ipv6 route 2002::/16 tunnel0
ipv6 route 2001:db8:0:2::/64 2002:a00:201::
ipv6 route 2001:db8:0:3::/64 2002:a00:301::


ipv6 route 2002::/16 tunnel0
ipv6 route 2001:db8:0:1::/64 2002:a00:101::
ipv6 route 2001:db8:0:3::/64 2002:a00:301::


ipv6 route 2002::/16 tunnel0
ipv6 route 2001:db8:0:1::/64 2002:a00:101::
ipv6 route 2001:db8:0:2::/64 2002:a00:201::

At this point we should have IPv6 connectivity among the IPv6 LANs at all three sites:

R1# ping 2001:db8:0:2::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:2::1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/31/56 ms
R1# ping 2001:db8:0:3::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:3::1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms

How 6to4 Works

The logic behind 6to4 tunneling may not be readily apparent. Let's trace the path of an IPv6 packet from a host behind R1 to a host behind R2. The packet begins as a normal IPv6 packet with IPv6 source and destination addresses. These addresses do not change for the life of the packet.


R1 receives the IPv6 packet and compares the destination IPv6 address against its IPv6 routing table.

R1# show ipv6 route
IPv6 Routing Table - 7 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
C   2001:DB8:0:1::/64 [0/0]
     via ::, Loopback0
L   2001:DB8:0:1::1/128 [0/0]
     via ::, Loopback0
S   2001:DB8:0:2::/64 [1/0]
     via 2002:A00:201::
S   2001:DB8:0:3::/64 [1/0]
     via 2002:A00:301::
S   2002::/16 [1/0]
     via ::, Tunnel0
LC  2002:A00:101::/128 [0/0]
     via ::, Tunnel0
L   FF00::/8 [0/0]
     via ::, Null0

The closest match is our static route for 2001:db8:0:2::/64, with a next-hop of 2002:a00:201::. This forces a recursive lookup for a route for 2002:a00:201::. The closest (and only) matching route is out interface Tunnel0; note that no next-hop IP address is specified for this second route.

This is where 6to4 comes into play. As the IPv6 packet is routed out of Tunnel0, it is encapsulated into IPv4. The source IPv4 address for the new header is taken from the tunnel source address. The destination IPv4 address is calculated from the next-hop address of our route for 2001:db8:0:2::/64; 2002:a00:201:: is converted to using the reverse of the process we used earlier to decide the tunnel interfaces' IPv6 addresses.


The encapsulated packet is routed through the IPv4 cloud until it reaches R2. The IPv4 header is stripped upon entering R2's interface. The remaining IPv6 packet is routed onto the IPv6 LAN toward Host B.


Our example relies on static routes. Note that internal routing protocols such as EIGRP and OSPFv3 cannot be used across 6to4 tunnels because link-local IPv6 addresses (needed to form router adjacencies) are not supported across 6to4 tunnels. BGP, which supports adjacencies based on global IPv6 addresses, can be used instead.

Also note that despite its NBMA nature, 6to4 tunnels are still tunnels, requiring both an ingress and egress IPv6 interface; they cannot be used to communicate directly between IPv4 and IPv6 hosts.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in IPv6


March 15, 2010 at 11:25 a.m. UTC

Hi Jeremy,

Thanks for another great article! Please could you change the link formula? As written it implies n raised to the power n-1 divided by 2, as opposed to n multiplied by (n-1) divided by 2.



eric (guest)
March 15, 2010 at 10:41 p.m. UTC

Another awesome article. The last sentence makes me curious however...

Say you have an IPv6 ONLY network. What would you need to allow connectivity to the IPv4 world?

March 15, 2010 at 10:55 p.m. UTC

@guym: Fixed, thanks for catching that!

@eric: Ideally, IPv6 should be being configured to run in parallel with IPv4 (obviously the situation in the real world is less than ideal). There was an effort behind developing multiprotocol NAT (NAT-PT) at one point but I think that's been abandoned. Application-level gateways (ALGs) are one way to go. There's also RFC 3142, though I don't know whether the theory it discusses has been implemented successfully. AFAIK IPv6-to-IPv6 translation is still a work in progress.

Ken Johnson (guest)
March 16, 2010 at 6:18 p.m. UTC


As a newbie to IPV6, this gives a good example to do a GNS3 project. Will give me some experience with IPV6.

March 19, 2010 at 8:59 p.m. UTC

Nice article, like always very clear and easy to understand. It was my first hands on ipv6.

March 20, 2010 at 4:10 p.m. UTC

Hi Stretch, yet again great article as usual,
But I have few curious question related to IPv6. From ISP perspective.

--If ISP switches to IPv6 dual stack network, is it he has to buy a seprate IPv6 transit link, If upstream ISP don’t have dual stack network??

--Second thing, if ISP take's IPv6 transit LINK, then can end user access all site normally or he can access only IPv6 sites and application?

--recently I heard about YouTube switched to IPv6, what does really it means?? Is it all content provider has to switch to IPv6, so IPv6 user can access their sites or IPv6 user can access all sites like IPv4 users?

And finally sorry for so many questions… I tried to search on Google; I couldn’t find the satisfactory answers.

Andy (guest)
April 21, 2010 at 9:16 p.m. UTC

Very good article, Well done Congratulation.

tommy (guest)
July 15, 2010 at 8:37 p.m. UTC


How could be BGP would be configured instead of having static routes?

Thank you

DavidJ (guest)
December 7, 2010 at 1:26 a.m. UTC

You will configure it the same way you do on IPv4; however, use the global IPv6 addresses for your neighbor statements:

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:AC10:C01:1::1/64
 tunnel source Serial0/0
 tunnel mode ipv6ip 6to4

router bgp 65400
 no synchronization
 bgp log-neighbor-changes
 neighbor 2002:AC10:1703:1::3 remote-as 65400
 no auto-summary


Jason Wang (guest)
February 18, 2011 at 1:45 a.m. UTC

Thanks for this awesome article. I was trying to look up the difference between generic ipv6ip and ipv6ip 6to4.

Ianjf (guest)
February 24, 2011 at 1:49 a.m. UTC

Hi Jeremy,

Nice article... a lot of this stuff is often overlooked in texts, your example is very nice however, covers everything!!! I understand that IGPs can not run across the 6to4 tunnels with the exception of BGP etc.

However, how would you go about bringing the actual 6to4 tunnels up without using the static routes to the other tunnel end points e.g.

ipv6 route 2001:db8:0:2::/64 2002:a00:201::
ipv6 route 2001:db8:0:3::/64 2002:a00:301::

Is it possible to bring the tunnels up with just the 2002::/16 static and some Dynamic Protocol on top??


saravanan (guest)
August 25, 2011 at 11:18 p.m. UTC

very informative, thank you.

March 19, 2012 at 7:30 p.m. UTC

Half an hour of reading your blog posts are more productive than 3 days of studying the same info in Ciscopress books. They are much clearer, informative and relevant.

Someone needs to pay you to write a book.

November 30, 2012 at 9:48 a.m. UTC

very informative and nice presentation. I would request for further revision if any in this and other artcles from your side.. thx for your time and clear way of presentation..

Strags (guest)
December 6, 2012 at 12:43 a.m. UTC

Hang on... I don't get it. How is this any better than 6in4? You're still configuring n(n-1) static routes, aren't you?

Matt (guest)
February 12, 2013 at 10:27 p.m. UTC

Great example. Is there any example for multicast traffic over 6to4 tunnel?

A guest
May 6, 2013 at 12:13 a.m. UTC

Absolutely brilliant post Stretch, I really appreciate it! Keep up the great work mate.

David (guest)
June 7, 2013 at 10:29 a.m. UTC

I must say that, as a beginner trying to learn 6to4, this tutorial massively confused me. Now that I understand 6in4 and, subsequently, 6to4... I can appreciate this article much more.

If anyone out there is trying to grasp 6to4 maybe this comment will help: typically you wouldn't number the IPv6 subnets arbitrarily (i.e. you wouldn't use 2001:db8::/32). You would use the 2002:xxxx:xxxx::/48 subnet that is unique to the IPv4 address of the respective gateway routers (in this case, R1, R2, and R3), and you would only need a single static route in each router (e.g. on R1 for R2's v6 subnet: ipv6 route 2002:a00:102::/48 tunnel0).

See http://www.youtube.com/watch?v=JY7INWIcqvk for more clarity.

Otherwise, very nice article Jeremy. The only catch/question I would have is this: wouldn't this configuration require IPv6 hosts behind each router to have one or more of the following?

  • a default route to the border routers
  • OSPFv3 or some other IPv6 routing protocol running
  • static routes for the other 2 IPv6 subnets


tommyt (guest)
August 15, 2013 at 10:00 p.m. UTC

best explanation and example of automatic 6to4 on the internet.

i echo the sentiments of another poster, you should write for cisco as your explanations are a lot clearer than theirs, i came here in desperation as i couldn't understand the technology.


Rado (guest)
August 17, 2013 at 12:53 p.m. UTC

Thank you, mate, great job!

Ernesto (guest)
November 24, 2013 at 7:49 a.m. UTC

This is a really good explanation about automatic 6to4, as a matter of fact this is THE explanation. No need for more. Thank you so mutch, you save me lot of time, absolutely brilliant.

sergey (guest)
January 13, 2014 at 12:13 p.m. UTC

Great article.

It's surprising IPv6 tunnel interfaces can be given only the network portion without the host portion of the IPv6 address.

Is it a built in mechanism in the 6to4 technology?


saumya (guest)
May 19, 2015 at 7:09 a.m. UTC

Is ND resolution required NH reachability from one island to another over 6to4 ? This should on same lines as Ipv6 over Ipv4 tunnel.

BK (guest)
December 16, 2015 at 3:26 a.m. UTC

Great example.

Question: What are the key differences between automatic versus manually configured IPv6 in IPv4 tunnel?

Comments have closed for this article due to its age.