Posts Tagged ‘ripng’


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.

Continue Reading

Tags: , , ,


Hi Brians,

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,


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.

Tags: , ,


CCIE Bloggers