The problem : What if we want to speak IPv6 but the whole path isn’t IPv6?
Here is our topology let’s begin.
IOSv1 and 2 are dual stacked, however the link between IOSv1 and IOSv2 is not IPv6.
This link represents many routers. There’s always a chance that they don’t support IPv6 for whatever reason.
In this scenario we would have to tunnel IPv6 into IPv4 statically. This will be a point to point tunnel so it will look like a new IPv6 link.
Let’s configure R4#
Ipv6 unicast-routing
Ipv6 router eigrp 1
Router-id 4.4.4.4
Int g0/1
Ipv6 eigrp 1
No shut
Int lo0
Ipv6 address 2001:5555::1/64
Ipv6 eigrp 1
Explained: I enabled ipv6 routing, then I created an EIGRP ipv6 instance. I had to give it a router-ID or else it would not function properly.
Then I configured the loopback with an IPv6 address and told it to speak EIGRP and be put into the EIGRP updates.
R1#
Ipv6 unicast-routing
Ipv6 router eigrp 1
Router-id 1.1.1.1
Int g0/1
Ipv6 address 2001:1111::1/64
No shut
Ipv6 eigrp 1
Int g0/2
Ip address 192.168.1.1 255.255.255.0
No shut
Int tun0
Tunnel source g0/2
Tunnel destination 192.168.1.2
Tunnel mode ipv6ip
Ipv6 address 2001:2222::1/64
Ipv6 eigrp 1
Explained: I created a tunnel interface, then told it the source was g0/2, then I told it the IPv4 address at the end of the tunnel.
Finally I specified the IPv6ip tunnel or else the default would have been GRE I believe. I completed the tunnel with an IPv6 address and told it to speak EIGRP.
<R2#
Ipv6 unicast-routing
Ipv6 router eigrp 1
Router-id 2.2.2.2
Int g0/1
Ip address 192.168.1.2 255.255.255.0
No shut
Int g0/2
Ipv6 address 2001:3333::1/64
Ipv6 eigrp 1
Int tun0
Tunnel source g0/1
Tunnel destination 192.168.1.1
Tunnel mode ipv6ip
Ipv6 address 2001:2222::1/64
Ipv6 eigrp 1
Explained: I did the same thing on this end but I my tunnel source was different, and so was my destination IP of the tunnel.
R3#
Ipv6 unicast-routing
Ipv6 router eigrp 1
Router-id 3.3.3.3
Int g0/1
Ipv6 address 2001:3333::2/64
No shut
Ipv6 eigrp 1
Int lo0
Ipv6 address 2001:6666::1/64
Ipv6 eigrp 1
Now from R4 (iosv4) we should be able to ping the loopback on R3 sourcing our loopback
We can verify the tunnel is working by going to R1 and doing “debug tunnel” and then pinging across it
Of course we can also “show ipv6 route” from R4 to verify we have the route to the loopback of R3 via EIGRP:
Finally, we will look at a packet capture of the tunnel.
I took this capture from G0/2 of R1
Notice how the IPv4 header is after the Ipv6 header in the packet. Once it reaches R2, he will know to expect this packet and decapsulate it accordingly.
Once he gets to the IPv6 header he will make a forwarding decision based on his routing table.
You should be aware routers know they an IPv6 and IPv4 header to process in a packet because they see the IP protocol field as “41”. This tells the to expect a second IPv6 header after processing the IPv4 header.