This topic is to discuss the following lesson:
Nice write-up. I think what would be cool is a follow-up blog entry on why the 6to4 automatic tunnels should NOT be used today in anything other than the lab networks. The 6to4 mechanism itself is pretty cool but it can create the problems if used for one’s real-world live traffic. Managed tunnels, if one has to use tunnels, are a much better approach.
Is it possible if we use dynamic routing protocol instead of static route for both of ipv6 segments ?
Futura(config)#ipv6 route 2001::3/128 2002:C0A8:1703::3
Futura(config)#ipv6 route 2002::/16 tunnel 0
Destiny(config)#ipv6 route 2001::1/128 2002:C0A8:C01::1
Destiny(config)#ipv6 route 2002::/16 tunnel 0
or we just use static route for ipv6 route 2002::/16 tunnel 0 as recursive routing whereas for segment ipv6 2001::YY/128 we use dynamic route.
Is it possible ? please advice me.
Hi Andria,
For the automatic 6to4 tunneling we can’t use dynamic routing on the Tunnel interfaces. If you have a lot of IPv6 prefixes, it’s better to create some tunnels yourself and configure EIGRP or OSPFv3 on it.
Rene
Great explanation and example!!!
I did the same scenario using BGP instead of static routing.
Glad to hear you like it Jose! BGP will also work, I used the static routes for this example to keep it simple.
Hi Rene,
I’m doing the configuration, but when i tried to configure the static routes I’m getting this error:
R1(config)#ipv6 route 2001:1111:2222:5555::1/128 2002:101:101::1
% Not allowed to point static routes through yourself
Hi Charalambos,
The next hop should be the next hop of the remote router, not your own router. Otherwise you are telling the router that in order to reach a network it has to go to its own address…that’s not going to work 
Directly connected networks are already in the routing table by default.
Rene
Hello,
Why did we change the prefix here?
Futura#show ipv6 general-prefix
IPv6 Prefix MYPREFIX, acquired via 6to4
2002:C0A8:C01::/48<--------------
Destiny#show ipv6 general-prefix
IPv6 Prefix MYPREFIX, acquired via 6to4
2002:C0A8:1703::/48<------
Futura(config)#interface tunnel 0
Futura(config-if)#ipv6 address 2002:C0A8:C01::1/64 <----------
Futura(config-if)#tunnel source fastEthernet 0/0
Futura(config-if)#tunnel mode ipv6ip 6to4
Destiny(config)#interface tunnel 0
Destiny(config-if)#ipv6 address 2002:C0A8:1703::3/64
Destiny(config-if)#tunnel source fastEthernet 0/0
Destiny(config-if)#tunnel mode ipv6ip 6to4
Thanks
Fabian,
The IPv6 RFC has set aside the address space of 2002::/16 for Automatic 6to4 Tunneling. As you know, when you convert the 32-bit IPv4 address to hex to get the specific 6to4 prefix for the IPv4 address in question, you have a ::/48 bit address (16 + 32 = 48). This is where the first number is coming from (MYPREFIX).
It is common practice in IPv6 to use 64 bits for the network and 64 bits for the host address. This means that for any 2002:XXXX:XXXX::/48 address, you have 16 more bits you can use to create additional networks (65,000+ of them!) that would still be processed by the IPv4 hosts through which the 6to4 traffic is flowing. For example, you could use the following range:
2002:C0A8:1703:0000::/64 - 2002:C0A8:1703:FFFF::/64
So in the Rene’s example, we are using the first /64 length network within the /48 network–namely 2002:C0A8:1703:0000::/64 which can be written as just 2002:C0A8:1703::/64
Great, ok thanks.
Fabian
Hey Rene,
Great write up! Why does Cisco recommend using Automatic 6 to 4 tunneling over ISATAP for inter area routing? I mean, I see the name intra-site, but trying to get more clarity on why ISATAP would not/or could not be used for inter area.
Thank you
Roland
Hi Roland,
I think it’s because of the additional overhead that ISATAP has. I found a nice document that did some benchmarks for all tunneling protocols:
http://www.ijidcs.org/issues/v2n2/ijidcs-18-149-156.pdf
Take a look at their conclusion
Rene
Thank you Rene! I appreciate you digging in to find the answer. I was coming up short! Awesome as always
Roland
Hi Rene ,
i think missed a piece of the puzzle for automatic 6to 4 tunneling . for tunnel source we are using tunnel source fastEthernet 0/0 command and for destination tunnel mode ipv6ip 6to4 to get the ip address from the ipv6 address 2002:C0A8:C01::1/64 . the hex part of ipv4 is C0A8:C01::1=192.168.12.1 which is the source ip of our interface .how can the tunnel is going up as we need the destination ip 192.168.23.3 à C0A8:170 of destiny router ;
Futura(config)#interface tunnel 0
Futura(config-if)#ipv6 address 2002:C0A8:C01::1/64
Futura(config-if)#tunnel source fastEthernet 0/0
Futura(config-if)#tunnel mode ipv6ip 6to4
thanks in advance
Hi Dionisis,
The tunnel mode ipv6ip 6to4 command tells the router to fetch the destination IPv4 address from the IPv6 address.
Router futura has these two static routes:
Futura(config)#ipv6 route 2001::3/128 2002:C0A8:1703::3
Futura(config)#ipv6 route 2002::/16 tunnel 0
When we send a ping to 2001::3, it knows it has to fetch the IPv4 destination address from 2002:C0A8:1703::3 which is 192.168.23.3.
The same thing applies to Destiny for the other way around.
Rene
HI Rene ,
Thanks a lot , this was very helpful for me
Dionisis
Hello,
I have a question regarding the 6to4 implementation:
Should it work if i use another prefix than 2002:?
I read couple of articles and in every place it’s written that 2002 is reserved for 6to4 implementation (like router knows how to extract 32 bit IPv4 address encoded in Hex format that goes after that prefix).
But in my lab i just used another prefix (just for testing): 1002: and the 6to4 stuff worked properly as well.
Can you please explain this behavior? Is it a correct and expected behavior or not?
Thanks,
Vladimir
This might have to do with the complexity (or lack thereof) for your lab. As you indicated, the 2002::/16 is a signal to IPv6 routers that they are supposed to convert the next 32 bits into an IPv4 address for routing over an IPv4 network. Without that signal, the IPv6 routers would not do this conversion, so they would have to have a native IPv6 route and path for delivery to the destination.
So to answer your question, this would be unexpected behavior unless you were in an environment so simple that 1002::/? could take place via some other native IPv6 capabilities.
Hi Rene,
Thank you for the great write-up. I am just wondering that you mentioned ISATAP but you did not explain it or has any example.
BR,
Collin