GRE vs. IPv6ip

[JoshGarmonCiscoCCNA]

Which should you use for 6to4 tunneling?

What's the difference?

Packet Tracer topology:

Do my tunnels need their own IPv6 addresses? I gave them some just in case.

Do my Loopback IPv6 addresses need to be incorporated into routing?

Do my Tunnel addresses need to be incorporated into routing?

[Peter Paluch]

Hi Josh,

First of all, when talking about 6to4 tunneling, we're not talking just about any IPv6-inside-IPv4 packet transport, but about a very specific method of tunneling that puts IPv6 packets right into IPv4 packet payloads, and in addition, a method that defines how the IPv4 addresses of tunnel endpoints will be algorithmically derived from the IPv6 addresses of the end hosts that want to communicate.

So the tunnelling has two aspects to it: How are the packets encapsulated one into another, possibly with some additional headers to provide extended tunneling functions, and, how are the tunnel endpoints determined.

When talking about GRE and IPv6IP, both these tunneling types refer specifically to static configuration of tunnel endpoints. Both with GRE and IPv6IP, the tunnel endpoints are fixed and configured statically when you are creating the tunnel. The difference is in the way the encapsulation is performed. With GRE, the resulting packet after encapsulation is: IPv4|GRE|IPv6. The GRE is a 4-byte long header that, among other things, contains a 2-byte field acting as an EtherType field to describe the type of the inner encapsulated packet. Thanks to this, GRE tunnels are capable of carrying multiple different packet types through the same tunnel because the receiving endpoint will be able to properly distinguish between them. With IPv6IP, the resulting packet is simply IPv4|IPv6. This tunnel type can carry only IPv6 packets and no other traffic. It is less universal - basically it is for a single purpose only - but it has a slightly smaller overhead.

When talking about 6to4, this is a combination of IPv6IP and of a clever addressing scheme that allows embedding the IPv4 addresses of tunnel endpoints into IPv6 addresses of end hosts behind those tunnel endpoints. The 6to4 IPv6 addresses have the form 2002:<Upper IPv4 half>:<Lower IPv4 half>::/48+ and by this scheme, every IPv6 host reachable through a particular tunneling router can use a 6to4 address that contains the IPv4 address of that router embedded as 3rd - 6th octet.

Do my tunnels need their own IPv6 addresses? I gave them some just in case.

Strictly speaking, no, your tunnel interfaces do not need their own global unique IPv6 addresses. However, in order to be configured as IPv6-enabled interfaces, they either need an IPv6 address assigned, or at least, they need to be configured with ipv6 enable command. Having a global address assigned to a tunnel allows you to handle it just like any other interface, ping it, send pings from it, etc.

Do my Loopback IPv6 addresses need to be incorporated into routing?

Not unless you want to reach them remotely for whatever reason.

Do my Tunnel addresses need to be incorporated into routing?

The same as before.

Please feel welcome to ask further!

Best regards,
Peter

[JoshGarmonCiscoCCNA]

Peter,

Yeah I should have said...I got OSPF and OSPFv3.

I'm not sure what all does, doesn't need to be Routed for the Tunnel to work...?

What's a good show command also?

[JoshGarmonCiscoCCNA]

How will I know if my tunnel is working or not?

[JoshGarmonCiscoCCNA]

Alright

I've got OSPF running for all my IP 4 addresses.

I've got OSPFv3 running for all my IP 6, including my tunnels.

However, neither of my far side routers know about each other's IPv6 information.

My middle router has nothing Ipv6 configured on it.

What am I supposed to do now?

[Peter Paluch · Accepted solution]

Hi Josh,

I apologize for responding so late - these have been busy days.

Let me try to provide you with a simple example of configurations for three routers that use tunneling to transport IPv4 and IPv6 packets - you can then compare your configurations with the ones provided here.

In this topology, it is assumed that R2 does not run IPv6 at all, and in addition, R2 knows only the directly connected networks, and has no idea about the private networks 10.0.1.0/24 and 10.0.2.0/24 behind R1 and R3, respectively. In order to allow the networks behind R1 and R3 to talk to each other, a tunnel needs to be established between R1 and R3, and routing run over it.

R2's configuration, as far as IP is concerned, will be extremely simple:

hostname R2
!
interface FastEthernet0/0
 description => To R1 <=
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
interface FastEthernet0/1
 description => To R3 <=
 ip address 192.0.2.5 255.255.255.252
 no shutdown

Basic R1 configuration (no tunnel yet) will also be relatively simple:

hostname R1
!
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/0
 description => To R2 <=
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
interface FastEthernet1/0
 description => IPv4 LAN <=
 ip address 10.0.1.1 255.255.255.0
 no shutdown
!
interface FastEthernet1/1
 description => IPv6 LAN <=
 ipv6 address 2001:db8:cafe:1::1/64
 no shutdown
!
ip route 0.0.0.0 0.0.0.0 192.0.2.2

R3's configuration would be very similar:

hostname R3
!
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/1
 description => To R2 <=
 ip address 192.0.2.6 255.255.255.252
 no shutdown
!
interface FastEthernet1/0
 description => IPv4 LAN <=
 ip address 10.0.2.1 255.255.255.0
 no shutdown
!
interface FastEthernet1/1
 description => IPv6 LAN <=
 ipv6 address 2001:db8:cafe:2::1/64
 no shutdown
!
ip route 0.0.0.0 0.0.0.0 192.0.2.5

At this point, R3 would be able to ping R1 (and vice versa) using their public addresses, but hosts in the private IPv4 LANs would be unable to talk to each other, not even talking about the IPv6 LANs.

The most straightforward tunneling configuration here would be to create a GRE tunnel that is capable of tunneling both IPv4 and IPv6 at the same time, and have R1 and R3 advertise their networks over this tunnel.

On R1, you would add the following configuration:

interface Tunnel0
 description => GRE tunnel to R3 <=
 tunnel source 192.0.2.1
 tunnel destination 192.0.2.6
 ip address 10.0.13.1 255.255.255.0
 ipv6 enable
 ip ospf 1 area 0
 ipv6 ospf 1 area 0
!
interface FastEthernet1/0
 ip ospf 1 area 0
!
interface FastEthernet1/1
 ipv6 ospf 1 area 0

R3's configuration would be again similar:

interface Tunnel0
 description => GRE tunnel to R1 <=
 tunnel source 192.0.2.6
 tunnel destination 192.0.2.1
 ip address 10.0.13.2 255.255.255.0
 ipv6 enable
 ip ospf 1 area 0
 ipv6 ospf 1 area 0
!
interface FastEthernet1/0
 ip ospf 1 area 0
!
interface FastEthernet1/1
 ipv6 ospf 1 area 0

This configuration would set up a static GRE tunnel between R1 and R3 and run both OSPFv2 (IPv4) and OSPFv3 (IPv6) over this tunnel, enabling R1 and R3 learn about their networks through this tunnel and pass packets from these networks through this tunnel.

The tunnel itself, as an interface, is assigned an IPv4 and IPv6 address on both R1 and R3. This is necessary for two purposes: First, an interface without an assigned IPv4 (IPv6) address is not considered an interface enabled for IPv4 (IPv6), and no IPv4 (IPv6) packets are allowed to pass through it. Second, routing protocols and other mechanisms running on the router that originate IP packets require that each interface of the router has an IPv4 (IPv6) address assigned, otherwise a packet originated by the router and sent out a particular interface would not have any source IPv4 (IPv6) address. For example, the OSPFv2 packets originated by R1 and sent out the Tunnel0 interface will have their source IPv4 address set to 10.0.13.1. Of course you have to keep in mind that there is always tunneling involved, so the entire OSPFv2 packet sent by R1 will be:

Outer header (S=192.0.2.1, D=192.0.2.6) | GRE | Inner header (S=10.0.13.1, D=224.0.0.5)

Now, for IPv4, I have assigned explicit IPv4 addresses to the tunnel interfaces. For IPv6, I've made a little trick: Because the tunnel is a purely transit link, most probably not intended to be "pinged" from any remote location, I have simply used the ipv6 enable command on both tunnel interfaces which will cause the router to create link-local unicast addresses for the interfaces and start the IPv6 on the interfaces. These tunnel interface won't have any global unicast IPv6 addresses assigned because for the basic operation, they do not need them. Of course I could assign global IPv6 addresses to the tunnel interfaces, but in this topology, it would not be useful: OSPFv3, just like any internal IPv6 routing protocol, uses only link-local addresses as next hop addresses, and the global addresses would be irrelevant as far as routing is concerned.

Note here that I have used the GRE type of tunnel (it is the default tunnel type). I could have used the IPv6-over-IPv4 tunnel type (tunnel mode ipv6ip) but if I did that, this tunnel would be capable of carrying IPv6 traffic only. That would mean that I would be unable to run OSPFv2 through it, and the 10.0.1.0/24 and 10.0.2.0/24 networks would not be able to operate with it. Only IPv6 packets would be allowed to pass through it. I would in fact need to establish another standalone tunnel for the IPv4 traffic. GRE is much more flexible in this regard, at the expense of extra 4B required for each tunneled packet for its own header.

Please try to go over this carefully. All your questions are welcome.

Best regards,
Peter

[Masoud Pourshabanian]

Nice explanation.

[JoshGarmonCiscoCCNA]

Hey Peter

Well I got mine working after setting up ONE LOOPBACK address with TWO ip addresses on my R1 and R2.

one ip4 and one ip6 address

i also used IPv6IP type tunnel

with that...i finally had connection

weird