If you loved the simplicity of the IPv6 manual tunnel we created in Part 1, you should love the Generic Routing Encapsulation (GRE) approach to tunneling IPv6 traffic through an IPv4 cloud just as much.

This simple approach takes the IPv6 packet and encapsulates it using the standard IPv4 GRE tunnel. But wait a minute? In Part 1 of this blog series, we had IPv4 encapsulate the IPv6 packet directly for tunneling across the v4 cloud. Why do we even need this additional method that adds GRE encapsulation to the process? Well, the answer is that this method is required within integrated IS-IS and IPv6 tunnel environments. If you plan on sending both IS-IS traffic and IPv6 traffic over the tunnel, you need the protocol field of the GRE header that allows identification of the passenger protocol.

This blog series was recommended by another of our awesome students and IEOC community members, Marcio A. Costa.

In the first part of this series, we will look at the Manual IPv6 tunnels that are simple to create in order to connect two “islands” of IPv6 separated by IPv4-only devices. For this blog, we will use the following simple topology:

The IPv6 section for IEWB-RS Volume 1 Version 5.0 is now posted on the members site. This leaves only BGP and Multicast left for completion, which are both currently in development. More information will be posted on those shortly. The following sections are available for IPv6:

IPv6 NAT-PT is to be used with IPv4 to IPv6 migration scenarios and it’s purpose is to provide bi-directional connectivity between IPv4 and IPv6 domains. Cisco points out that many other transition techniques are possible, and NAT-PT (Network Address Translation – Protocol Translation) should not be used when other, more “native” options exist, such as having dual stack hosts communicate directly through dual stack routers. Another example provided of when NAT-PT is not needed is when two islands of IPv6 want to communicate over an IPv4-only backbone. We know that many different tunnels exist for this purpose. For more information about these tunnel techniques, see the Transition Technique series in this blog category.

For the job of NAT-PT, a dual-stack router with interfaces in both IPv4 and IPv6 networks is capable of performing this task. The difference from classic IPv4 NAT is that translations should be done both ways: IPv6 packets routed towards IPv4 hosts should have their src/dst addresses changed to some IPv4 equivalents and vice versa, while IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.

Just a quick question about the “include-connected” command when redistributing IPv6 protocols (especially RIPng and OSPFv3). From the DocCD it says that it allows the quote “target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running”. Is there any reason why this is now necessary to do with IPv6 routing protocols, whereas IPv4 routing protocols would automatically advertise the networks of the connected interfaces if the source protocol is running on them. By the way, this blog is a fantastic idea/revison tool. Keep up the excellent work.

Kind Regards,

Colin

Hi Colin,

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

In previous IOS versions this was not always the case however. In many network designs, especially in service provider environments, transit links themselves are not advertised into the routing domain. Based on this design traffic cannot be sent *to* the network itself, only *through* the network. Over the course of IOS releases however this behavior was mostly updated, and now we see that IPv4 protocols, with the exception of IS-IS, do automatically redistribute their connected interfaces.

For IPv6 whether or not connected links are included in redistribution is up to you at the time of configuration. If we take the previous case for IPv4 and translate it to IPv6 we’ll see that the behavior is not the same. By this I mean that if we issue the “redistribute rip 1” command under the OSPFv3 process, the router will only look at the output of the routes from the “show ipv6 route rip” command, and not the output from the “show ipv6 route connected”. To get connected interfaces to be included in this redistribution we can either issue a separate “redistribute connected” command under OSPFv3, which will take all connected IPv6 interfaces by default, not those just running RIPng, or we can issue the “redistribute rip 1 include-connected” command. This is the preferred design as it gives us more flexibility as to which particular networks we choose to advertise.