 |
| http://blog.ipspace.net/2010/05/nat64-and-dns64-in-30-minutes.html |
IPv4/IPv6 Transition Mechanisms
http://www.ripe.net/ripe/meetings/regional-meetings/dubrovnik-2011/presentations/IPv6_Transition_Mechanisms_Ripe_07092011_v1.2.pdf
Unlike tunneling for the Point-to-Point Tunneling Protocol (PPTP) and
Layer Two Tunneling Protocol (L2TP), there is no exchange of messages for
tunnel setup, maintenance, or termination. Additionally, IPv6 over IPv4
tunneling does not provide security for tunneled IPv6 packets.
Protocols
This is a list of IP numbers used in the Protocol field of the IPv4 header and the Next Header field of IPv6 header.
1 0x01 ICMP Internet Control Message Protocol RFC 792
6 0x06 TCP Transmission Control Protocol RFC 793
17 0x11 UDP User Datagram Protocol RFC 768
41 0x29 IPv6 IPv6 Encapsulation RFC 2473
43 0x2B IPv6-Route Routing Header for IPv6 RFC 2460
47 0x2F GRE Generic Routing Encapsulation RFC 2784, RFC 2890
50 0x32 ESP Encapsulating Security Payload RFC 4303
51 0x33 AH Authentication Header RFC 4302
58 0x3A IPv6-ICMP ICMP for IPv6 RFC 4443, RFC 4884
88 0x58 EIGRP Cisco EIGRP
89 0x59 OSPF Open Shortest Path First RFC 1583
112 0x70 VRRP VRRP RFC 3768
| Type | Name | Mode | Tunnel Source | Tunnel Destination | Interface Prefix or Address |
| Manual |
Manual
|
ipv6ip | An IPv4 address, or a reference to an interface on which IPv4 is configured. | An IPv4 address. | An IPv6 address. |
| GRE/IPv4 | gre ip | An IPv4 address. | An IPv6 address. | ||
| Auto | IPv4- compatible | ipv6ip auto-tunnel | Not required.
These are all point-to-multipoint tunneling types. The IPv4 destination address is calculated, on a per-packet basis, from the IPv6 destination. |
Not required. The interface address is generated as ::tunnel-source/96. | |
| 6to4 | ipv6ip 6to4 | An IPv6 address. The prefix must embed the tunnel source IPv4 address. | |||
| 6RD | ipv6ip 6rd | An IPv6 address. | |||
| ISATAP | ipv6ip isatap | An IPv6 prefix in modified eui-64 format. The IPv6 address is generated from the prefix and the tunnel source IPv4 address. |
| Tunneling Type | Suggested Usage | Usage Notes |
|---|---|---|
| Manual | Simple point-to-point tunnels that can be used within a site or between sites. | Can carry IPv6 packets only. |
| GRE- and IPv4- compatible | Simple point-to-point tunnels that can be used within a site or between sites. | Can carry any packets: IPv6, Connectionless Network Service (CLNS), and many other types of packets. |
| IPv4- compatible | Point-to-multipoint tunnels. | Uses the ::/96 prefix. We do not recommend using this tunnel type. |
| 6to4 | Point-to-multipoint tunnels that can be used to connect isolated IPv6 sites. | Sites use addresses from the 2002::/16 prefix. |
| 6RD | IPv6 service is provided to customers over an IPv4 network by using encapsulation of IPv6 in IPv4. | Prefixes can be from the SP’s own address block. |
| ISATAP | Point-to-multipoint tunnels that can be used to connect systems within a site. | Sites can use any IPv6 unicast addresses. |
1) Dual-stack - IPv4 and IPv6 protocol stack
2) Address translation
IPv4/IPv4
NAT44 - (Large Scale NAT - LSN)
NAT444 (LSN + NAT44) or CGN (using 100.64.0.0/10 http://tools.ietf.org/html/rfc6598)
IPv4/IPv6 Address Translation - Enables communication between IPv4-only and IPv6-only devices
NAT-PT (RFC 2766) - deprecated
NAT64:
Framework for IPv4/IPv6 Translation (RFC 6144)
IPv6 Addressing of IPv4/IPv6 Translators (RFC 6052)
DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers (RFC 6147)
IP/ICMP Translation Algorithm (RFC 6145)
Stateless NAT64 (not very usefull, why?)
|
Stateful NAT64
|
1:1 translation
|
1:N translation
|
No conservation of IPv4 address
|
Conserves IPv4 address
|
Assures end-to-end address transparency and scalability
|
Uses address overloading, hence lacks in end-to-end address transparency
|
No state or bindings created on the translation
|
State or bindings are created on every unique translation
|
Requires IPv4-translatable IPv6 addresses assignment (mandatory requirement)
|
No requirement on the nature of IPv6 address assignment
|
Requires either manual or DHCPv6 based address assignment for IPv6 hosts
|
Free to choose any mode of IPv6 address assignment viz. Manual, DHCPv6, SLAAC
|
3) Tunneling
RFC 2893 - Transition Mechanisms for IPv6 Hosts and Routers:
IPv6-over-IPv4 tunneling - The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.
Configured tunneling - IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulating node.
The tunnels can be either unidirectional or bidirectional. Bidirectional configured tunnels behave as virtual point-to-point links.
Automatic tunneling - IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4-compatible destination address of the IPv6 packet being tunneled.
The two tunneling techniques -- automatic and configured -- differ primarily in how they determine the tunnel endpoint address.
GRE Tunneling (tunnel mode ipv6ip) - RFC 2473 - Generic Packet Tunneling in IPv6 Specification ( tunnel mode gre ip )
6to4 (tunnel mode ipv6ip 6to4) - RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds
- Automatic tunnel provisioning
- IPv6 address is calculated from IPv4 (2002:192.168.100.1::/48)
- 2002::/16
- Public 6to4 anycast relay – 192.88.99.1 -> 2002:c058:6301:: (RFC3068 - An Anycast Prefix for 6to4 Relay Routers)
Auto-Tunnel (IPv4-Compatible IPv6 Tunnels) (tunnel mode ipv6ip auto-tunnel)
- if the IPv4 address is 172.16.101.1, the IPv4-comaptible IPv6 address is ::172.16.101.1
IPv6 6RD - 6 Rapid Deployment (tunnel mode ipv6ip 6rd ) RFC 5969
- Automatic tunnel provisioning
- ISP IPv6 address space
- IPv6-only access network
Teredo - RFC 4380 - Teredo: Tunneling IPv6 over UDP through Network AddressTranslations (NATs) :
- NAT traversing
- 2001:0000 prefix
- Supported “by default” on Microsoft OS
- Slow
- UDP
ISATAP - RFC 5214 - Intra-Site Automation Tunnel Addressing Protocol (ISATAP) :
- Corporate & academic environments (Intranet)
- Single administrative domain
6PE - RFC 4798 - Configuring IPv6 Islands over IPv4 MPLS Using Provider EdgeRouters
- Core remains IPv4
- Edge devices (6PE) must support dual-stack
- IPv6 packets transported over LSP
- IPv4 Control plane (IGPv4, LDPv4, MP-BGP)
- Fast Re-Route (FRR), Traffic Engineering (TE)
6VPE - RFC 4659 - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
- IPv6 VPN provisioning over IPv4/MPLS
- Edge devides (6VPE) must support dual-stack
- Same MPLS VPN features as for IPv4
- VRF, RT, RD
- MP-NGP
- Mainly used in enterprises
Most of the barriers for a migration to IPv6 have been removed:
- The IPv6 protocol set has been complete for more than a decade.
- Many products, including the most common client and server operating systems, support IPv6.
- Cisco routers have supported IPv6 long enough that IPv6 support exists in the most commonly deployed IOS versions.
- The product support means that IPv6 deployment should not be inhibited by the availability of IPv6 in commonly used software.
- The Internet’s support for IPv6 is growing.
Barriers do still exist, but IPv6 adoption may have finally reached the point of gathering momentum worldwide.
Process of migrating billions of IPv4-based computers and devices to IPv6–devices under the control of millions of organizations and maybe billions of individual people–will not happen overnight. In the real world, the migration from IPv4 to IPv6 will probably take a generation to complete–arguably, it has been in progress for a decade already.
IPv4 and IPv6 will likely coexist in a given internetwork for a very long time.
During this possibly long migration, three main classes of tools may be used to allow IPv4 to continue to work well, while supporting IPv6:
■ Dual IPv4/IPv6 stacks (dual stacks)
■ Tunneling
■ NAT Protocol Translator (NAT-PT)
IPv4/IPv6 Dual Stacks
The term dual stacks - means that the host or router uses both IPv4 and IPv6 at the same time.
To support both IPv4 and IPv6 hosts, the router could then receive and forward both IPv4 packets and IPv6 packets.
The hosts using dual stacks follow the same general process of using DNS to resolve a name into an IP address.
The DNS requests can return either an IPv4 address or an IPv6 address.
The dual stack host can then choose to use IPv4 to communicate with an IPv4 host or IPv6 to communicate with an IPv6 host.
Two general approaches:
- Native IPv6: Configure IPv6 on most or all routers, on most or all production interfaces, making all routers use a dual stack.
- IPv6 tunnels:Configure some routers with IPv6, others without IPv6, and tunnel the IPv6 packets over the IPv4 network by encapsulating IPv6 packets inside IPv4 packets.
Tunneling
Tunneling - refers to a process by which one router or host encapsulates the IPv6 packet inside an IPv4 packet.
- gives engineers a tool with which to avoid a full native migration to IPv6 on all routers,
- all tunneling methods add more overhead to the routers that perform the tunneling encapsulation and decapsulation
- the networking devices forward the IPv4 packet, ignoring the fact that the packet’s payload is an IPv6 packet. Some later device or host decapsulates the original IPv6 packet, forwarding it on to the final destination.
- it allows a quicker migration from no IPv6 support to enough support to get IPv6 packets between two sites.
- fewer routers need new configuration, the smaller number of changes means less operational risk, and the end hosts can still forward IPv6 traffic to each other.
 |
| Implementing Tunneling for IPv6 (cisco.com) |
Point-to-point IPv6 Tunnels
- two devices (and only two) sit at the ends of the tunnel (work like a virtual point-to-point serial link),
- to create the tunnel shown in the figure, each router configures a type of virtual interface called a tunnel interface (Tunn0),
- the tunnel interface numbers can be any integer (up into the low billions), much like choosing loopback interface numbers, with no advantage or disadvantage of using any particular interface number,
- the two routers on the ends of the tunnel treat the tunnel interfaces like serial interfaces on a point-to-point serial link,
- point-to-point tunnels work best when the IPv6 occurs regularly.
Point-to-Multipoint IPv6 Tunnels
Multipoint IPv6 tunnels allow the sending router (the “point”) to use a single tunnel interface to send packets to multiple remote routers.
- multipoint tunnels works much like a LAN, or even more like a Non-Broadcast Multi-Access (NBMA) network like Frame Relay.
- multipoint tunnels generally work best when the IPv6 traffic occurs infrequently, or even in cases where the traffic volumes are less predictable.
- multipoint tunnels still encapsulate the IPv6 packets, but they need additional logic so that the sending router (the “point”) knows to which of several remote routers (the “multipoints”) to send the encapsulating IPv4 packet.
Problem: how a router chooses which of the many remote tunnel endpoints should receive a particular packet. Multipoint tunnels rely on either the IPv6 packet’s destination address, or next-hop information in the IPv6 routing table, to determine which of the multiple remote devices should receive a given packet. This decision happens dynamically on the sending router.
Two general options for these dynamic tunnels exist: automatic 6to4 tunnels and ISATAP tunnels. In both cases, the 32-bit IPv4 address of the destination is embedded in the destination IPv6 address.
IPv6 Tunneling Options
1) Manually Configured (static), topology - Pt-pt
Acts like a virtual point-to-point link, supporting IPv6 IGPs. Good for more permanent tunnels. Supports IPv6 IGPs. Slightly less overhead than GRE.
2) GRE (Static), topology - Pt-pt
Generic Routing Encapsulation. Same advantages as previous, plus it can support other Layer 3 protocols over the same tunnel.
3) 6to4 (Dynamic), topology - Mpt
It may require less configuration than all other types when adding a new site. Supports global unicasts, with some extra configuration.
Uses second and third quartets to store IPv4 address.
4) ISATAP (Dynamic), topology - Mpt
It easily supports global unicast addresses for all prefixes. Uses seventh and eighth quartets to store IPv4 address.
NPTv6 - Network Prefix Translation version 6
https://tools.ietf.org/html/rfc6296
- NPTv6 is sometimes referred to as IPv6-toIPv6 Network Prefix Translation.
- Unlike NAT, NPTv6 cannot do any sort of NAT address overloading. Instead it simply translates one IPv6 prefix to another.
- For example, a router configured for NPTv6 might translate a prefix from 2001:1::/64 to 2001:2::/64.
- is an experimental specification for IPv6 to achieve the address-independence at the network edge.
- provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes,
- Use cases for NPTv6 include peering with partner networks, multi homing, and redundancy and load sharing.
Restrictions for NPTv6 support on ASR1k/CSR1k/ISR4k (link)
- Virtual Routing and Forwarding (VRF) is not supported by NPTv6 support on ASR1k/CSR1k/ISR4k feature.
- does not support configuring NAT64 on the same interface.
- Multicast is not supported.
- Firewall is not supported.
- Application Level Gateways (ALG) is not supported by NPTv6 support on ASR1k/CSR1k/ISR4k feature.
- Payload address or port translation is not supported.
- High Speed Logging (HSL) and syslog is not supported..
NAT Protocol Translation
These mechanisms have been deprecated by the IETF. (July 2007)
Network Address Translation/Protocol Translation (or simply NAT-PT) is defined in RFC 2766 but due to numerous problems, it has been obsoleted by RFC 4966 and deprecated to historic status.
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Deprecated_methods
Some time during the migration toward IPv6, the network may need to support the ability for an IPv4-only host to communicate with an IPv6-only host.
Between the two hosts must translate between the two different protocols (IPv4 and IPv6). The solution is the Network Address Translation–Protocol Translation (NAT-PT) feature.
 |
| http://tomicki.net |
- Not only does NAT-PT translate IP addresses, but also it translates the entire IPv4 and IPv6 header, plus other headers as well, such as TCP, UDP, and ICMP.
- The router performing NAT-PT must convert the requests between DNSv4 and DNSv6, keeping track of the names and address bindings so that the NAT-PT translation process converts to the correct addresses.
Static NAT-PT example:
NAT-PT uses a 96-bit IPv6 network prefix to direct all IPv6 traffic that needs to be translated to the NAT-PT router. This prefix can be any routable prefix within the IPv6 domain. IPv6 routing must be configured such that all IPv6 packets addressed to this prefix are routed to the NAT-PT device. When the NAT-PT router receives an IPv6 packet destined for the NAT-PT prefix, it translates the packet according to the configured mapping rules. This prefix is also used in the translation of IPv4 address into IPv6 addresses.
R1(config)#interface s0/0/0Notice that this prefix is directly connected to the interface NVI0; NVI0 is a NAT virtual interface and exists to allow NAT traffic flows.
R1(config-if)#ipv6 nat
R1(config-if)#interface s0/1/0
R1(config-if)#ipv6 nat
R1(config)#ipv6 nat v6v4 source 14::4 172.16.123.100
R1(config)#ipv6 nat v4v6 source 172.16.123.2 1144::1
R1#debug ipv6 routing
IPv6 routing table events debugging is on
R1(config)#ipv6 nat prefix 1144::/96 (could be only /96)
R1(config)#
IPv6RT[Default]: connected, Route add 1144::/96 [new]
IPv6RT[Default]: connected, Add 1144::/96 to table
IPv6RT[Default]: connected, Adding next-hop :: over NV10 for 1144::/96, [0/0]
IPv6RT[Default]: Event: 1144::/96, Add, owner connected, previous None
R1(config)#
R1#show ipv6 route connectedConfigure routing protocol
C 13::64 [0/0]
via FastEthernet0/0, directly connected
C 14::/64 [0/0]
via Serial0/0/0, directly connected
C 1144::/96 [0/0]
via NV10, directly connected
R4#show ipv6 route | inc 1144
R4#
R1(config)#ipv6 router rip NAT-PT
R1(config-rtr)#redistribute connected metric 3
R1(config-rtr)#
R4#show ipv6 route | inc 1144
R 1144::/96 [120/4]
R4#show ipv6 route ripVerify
R 13::/64 [120/2]
via FE80::1, Serial 1/1.7
R 1144::/96 [120/4]
via FE80::1, Serial 1/1.7
R1#show ipv6 nat translationsNotice that, unlike IPv4 NAT configurations, no inside or outside keywords are required, because having an IPv6-only side and an IPv4-only side resolves the issue of boundaries.
Prot IPv4 source IPv6 source
IPv4 destination IPv6 destination
—- —- —-172.16.123.2 1144::1
icmp 172.16.123.100,7364 14::4, 7364
172.16.123.2, 7364 1144::1, 7364
—- 172.16.123.100 14::4
—- —-
R1#
This example illustrated that static NAT-PT is quite simple to configure, but it requires planning the translated addresses in both domains.
Static NAT-PT is not scalable; it would be very cumbersome to create static entries for multiple sources communicating with multiple destinations.
Dynamic NAT-PT for IPv6
With dynamic NAT-PT, addresses are allocated from an address pool, the same as is done with IPv4 dynamic NAT. And again, the commands have similar syntax to their IPv4 NAT counterparts.
With dynamic NAT-PT, the NAT-PT router receives, for example, a packet with an IPv6 destination address of an arbitrarily assigned 96-bit prefix (the NAT-PT prefix), the same as it did with static NAT-PT. This time though, instead of translating this to an IPv4 address that was statically configured, the NAT-PT router translates it to an IPv4 address from an address pool.
R1(config)#interface FastEthernet0/0
R1(config-if)#ipv6 nat
R1(config-if)#interface Serial0/0/0.2
R1(config-subif)#ipv6 nat
R1(config-subif)#interface Serial0/0/0.4
R1(config-subif)#ipv6 nat
R1(config-subif)#interface Serial0/1/0
R1(config-if)#ipv6 nat
R1(config)#
R1(config)#ipv6 nat v4v6 source 172.16.12.2 1144::2
R1(config)#ipv6 nat v4v6 source 172.16.123.2 1144::1
R1(config)#
R1(config)#ipv6 nat v6v4 source list LOOPBACK pool POOL_12
R1(config)#ipv6 nat v6v4 source list PHYSICAL pool POOL_123
R1(config)#
R1(config)#ipv6 nat v6v4 pool POOL_12 172.16.12.100 172.16.12.101 prefix-length 24
R1(config)#ipv6 nat v6v4 pool POOL_123 172.16.123.100 172.16.123.101 prefix-length 24
R1(config)#
R1(config)#ipv6 access-list LOOPBACK
R1(config-ipv6-acl)#permit ipv6 104::/64 any
R1(config-ipv6-acl)#permit ipv6 103::/64 any
R1(config)#ipv6 access-list PHYSICAL
R1(config-ipv6-acl)#permit ipv6 13::/64 any
R1(config-ipv6-acl)#permit ipv6 14::/64 any
R1(config)#
R1(config)#ipv6 nat prefix 1144::/96
R1(config)#ipv6 router rip NAT-PT
R1(config-rtr)#redistribute connected metric 1
Static Point-to-Point IPv6 Tunnels
- MCT (manually configured tunnels) - refers to an RFC standard encapsulation of IPv6 inside IPv4 packets.
- GRE (Generic Routing Encapsulation) tunnels.
MCT and GRE tunnels have many similarities:
- both create a virtual point-to-point link between two IPv4 routers for the purpose of supporting the forwarding of IPv6 packets,
- IPv6 IGP routing protocols can run over these virtual links,
- to support multiple features (IGPs), the routers will assign link local addresses on these links and allow the forwarding of IPv6 multicast traffic.
- both types allow the configuration of additional security features over the tunnel interfaces,
- both require static configuration of both the tunnel source and the tunnel destination IPv4 addresses.
 |
| Comparing Manual and GRE IPv6-over-IP Tunnels |
GRE’s flexibility allows a single GRE tunnel to carry IPv6 plus other traffic as well, whereas manually configured tunnels cannot.
- MCT simply conform to the rules about generic IPv6 tunnels outlined in RFC4213, which defines how to encapsulate IPv6 inside an IPv4 packet, without additional headers.
- GRE tunnels use a generic encapsulation originally defined by Cisco and later standardized in RFC2784. GRE uses an additional stub header between the IPv4 and IPv6 header; this extra header includes a protocol type field, which allows a GRE tunnel to carry many passenger protocols. GRE also supports several transport protocols (transport protocols encapsulate the passenger protocol), although IPv4 typically is the only transport protocol used for tunneling IPv6.
 |
Configuring GRE @ www.h3c.com |
- Find the tunnel IPv4 addresses planned for the tunnel
- Create a tunnel interface using the interface tunnel <number>
- Define the (local) source IPv4 address of the tunnel using the tunnel source {interface-type interface-number| ipv4-address}
- Define the destination IPv4 address for the encapsulation using the tunnel destination ipv4-address
- Define the tunnel as a manually configured tunnel (not GRE) tunnel mode ipv6ip
R1Verification
ipv6 unicast-routing
interface loopback 1
ip address 10.9.9.1 255.255.255.255
interface tunnel 0
tunnel source loopback 1
tunnel destination 10.9.9.3
tunnel mode ipv6ip <- MCT mode
no ip address
ipv6 address 2013::1/64
ipv6 eigrp 1
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2111::1/64
ipv6 eigrp 1
!
ipv6 router eigrp 1
eigrp router-id 1.1.1.1
no shutdown
R3
interface loopback 3
ip address 10.9.9.3 255.255.255.255
interface tunnel 3
tunnel source loopback 3
tunnel destination 10.9.9.1
tunnel mode ipv6ip
R1# traceroute ipv6 2222::3GRE Tunnels
R1# show interfaces tunnel0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Tunnel source 10.9.9.1 (Loopback1), destination 10.9.9.3
Tunnel protocol/transport IPv6/IP
R1# show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::213:19FF:FE7B:5026
2111::1
Tunnel0 [up/up]
FE80::A09:901
2013::1
R1# show ipv6 interface tunnel0
Tunnel0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::A09:901
Global unicast address(es): 2013::1, subnet is 2013::/64
Joined group address(es):
FF02::1
FF02::2
FF02::A
FF02::1:FF00:1
FF02::1:FF09:901
Only one difference exists in the configuration between MCT and point-to-point GRE tunnels: the tunnel mode. (tunnel mode gre ip)
IOS defaults to use GRE over IP, you can alternatively just omit the tunnel mode command as well.
- The configurations are indeed almost identical.
- Issue the no tunnel mode ipv6ipcommand on both routers’ tunnel interfaces, which reverts to the default of GRE over IP.
- The verification command output looks almost identical as well, but with just a few differences to note.
If the two routers’ tunnel modes do not match, the tunnel interfaces can stay up/up, but the routers cannot forward IPv6 packets because of the mismatched encapsulations.
What's the difference between an ipv6ip tunnel and a gre tunnel?
- IPv6 IP (protocol 41) - MCT v6 packets in an ipv6ip tunnel are directly encapsulated in an IPv4 header, (new IPv4 header) + (original IPv6 packet)
- GRE (protocol 47) - v6 packets in a GRE tunnel are encapsulated in a GRE header and then the IPv4 header. (new IPv4 header) + (GRE header) + (original IPv6 packet), There are 4 bytes less overhead with IPv6IP.
Dynamic Multipoint IPv6 Tunnels
Multipoint IPv6 tunnels give engineers a good means to implement IPv6 connectivity for short periods of time.
The tunnels can allow easier addition of new sites, with less configuration on existing routers.
- convenient tool to use when irregular or infrequent IPv6 traffic occurs between sites,
- new sites can join into the tunnel without requiring additional configuration on the existing routers
- multipoint tunnels in some cases allow IPv6 hosts to act as tunnel endpoints, allowing a host at a remote site to connect into the Enterprise IPv6 network even if the local router has no knowledge of IPv6.
Disadvantages:
- IPv6 address planning must follow some additional rules and constraints,
- do not support IPv6 IGPs, can be used of either static routes or multiprotocol BGP,
- dynamic forwarding logic requires more work per packet as compared with point-to-point tunnels, which is one of the main reasons multipoint tunnels are best used for less frequent traffic.
Automatic 6to4 Tunnels
- use a special reserved range of addresses (start with 2002::/16 or 0x2002) that will never be assigned as global unicast addresses (2000::/3).
- next 4 bytes will be the HEX equivalent of IPv4 address,
- RFC3056 (Connection of IPv6 Domains via IPv4 Clouds)
- network engineer can then create a /48 prefix (can assign each tunnel endpoint (router or host) its own /48 prefix, used for all prefixes connected to that local router)
- engineer can allocate /64 prefixes for each required subnet connected to each router by allocating a unique subnet number in the fourth quartet
 |
| 6to4 address http://en.wikipedia.org/wiki/6to4 |
Prepend - to add something to the beginning of something else. (2002:c000:0204::/48, 2002 is prepended to c000:0204)
append - the opposite.
Prepend 0x2002 with hex representation on IPv4 creates an IPv6 6to4 address.
6to4 tunnels enable the fast deployment of IPv6 in a corporate network without the need for public IPv6 addresses from ISPs or registries.
The biggest limitation of 6to4 tunnels is that only static routes or BGP can be used across them.
Configuration for network without INTERNET (engineer chose all IPv6 addresses from the reserved 2002::/16 range)
ipv6 unicast-routing
!
interface Loopback1
ip address 10.9.9.1 255.255.255.255
!
interface Tunnel0
no ip address
ipv6 address
ipv6 address 2002:a09:901::/128
tunnel source Loopback1
! Do NOT define a tunnel destination with the tunnel destination
tunnel mode ipv6ip 6to4
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2002:A09:901:1::1/64
!
! Define a static route for 2002::16, with outgoing interface of the tunnel interface
ipv6 route 2002::/16 Tunnel0
1) R1 will have 3 routes: 2 connected IPv6 routes (F0/0’s and tunnel0’s) in the 2002::/16 and a static route for the entire 2002::/16 range.
2) When R1 receives an IPv6 packet, destination in the 2002::/16 range, and the destination is not in one of the connected subnets, R1 will try to forward the packet out tunnel0.
3) tunnel mode ipv6ip 6to4 command tells R1 to look to the 2nd/3rd octets to find the destination IPv4 address, and perform the tunneling
R1’s logic works without any preconfigured addressing information about R3, and to R4, and to hundreds of future routers, if the engineer plans the IPv6 addresses correctly.
R1# show ipv6 routeUsing Global Unicasts with Automatic Tunnels
IPv6 Routing Table - Default - 5 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
...
S 2002::/16 [1/0]
via Tunnel0, directly connected
LC 2002:A09:901::/128 [0/0]
via Tunnel0, receive
C 2002:A09:901:1::/64 [0/0]
via FastEthernet0/0, directly connected
!
R1# show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::213:19FF:FE7B:5026
2002:A09:901:1::1
Tunnel0 [up/up]
FE80::A09:901
2002:A09:901::
- Plan the prefixes and addresses for the LANs using the global unicast range assigned to the Enterprise.
- Configure an additional static route for each remote subnet, configuring the tunnel as outgoing interface and configuring the next-hop IPv6 address. That next-hop must be the remote router’s tunnel IPv6 address, which embeds the destination IPv4 address as the second and third octets. (You also can use BGP for IPv6 to learn the route)
ipv6 route 2000:0:1:3::/64 tunnel0 2002:a09:903::When a new router is added to the multipoint tunnel, each router already on the tunnel needs to add additional static routes or the alternative additional BGP configuration.
ipv6 route 2000:0:1:4::/64 tunnel0 2002:a09:904::
6to4 vs ISATAP (link)
ISATAP is meant to be a host-to-host tunnel, while 6to4 is meant to be a site-to-site tunnel. ISATAP is the Intra-Site Automatic Tunnel Addressing Protocol. The key here is "intra-site", where 6to4 is an inter-site tunnel.
For example if you have two offices that connect to the normal IPv4 Internet and you want them to be able to talk IPv6 with each other you would normally use 6to4 to connect both sites instead of ISATAP.
However if you have two hosts on an IPv4 only LAN within the same site, and you want them to talk IPv6 to each other, you would use ISATAP.
Another way to think of this is that ISATAP runs on your end hosts, like inside Windows, while 6to4 runs on your router, like Cisco IOS.
ISATAP is meant to be a host-to-host tunnel, while 6to4 is meant to be a site-to-site tunnel. ISATAP is the Intra-Site Automatic Tunnel Addressing Protocol. The key here is "intra-site", where 6to4 is an inter-site tunnel.
For example if you have two offices that connect to the normal IPv4 Internet and you want them to be able to talk IPv6 with each other you would normally use 6to4 to connect both sites instead of ISATAP.
However if you have two hosts on an IPv4 only LAN within the same site, and you want them to talk IPv6 to each other, you would use ISATAP.
Another way to think of this is that ISATAP runs on your end hosts, like inside Windows, while 6to4 runs on your router, like Cisco IOS.
6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts. 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes.
Routing between 6to4 and native IPv6
To allow hosts and networks using 6to4 addresses to exchange traffic with hosts using "native" IPv6 addresses, "relay routers" have been established.
6to4 uses, a "relay router" and a "border router"
- "relay router" is a 6to4 router configured to support transit routing between 6to4 addresses and pure native IPv6 addresses.
An IPv4 address prefix ( 192.88.99.0/24 ) is used to advertise an IPv4 route to an available 6to4 Relay Router.
An IPv4 address (192.88.99.1) used to reach the nearest 6to4 Relay Router.
6to4 IPv6 relay anycast address - IPv6 address derived from the 6to4 Relay anycast address according to the rules defined in 6to4, using a null prefix and a null host identifier. The value of the address is "2002:c058:6301::"
The 6to4 routers are configured with the default IPv6 route (::/0) pointing to the 6to4 IPv6 anycast address.
- "6to4 border router" is an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network, where the IPv6 site uses 2002::/16 co-related to the IPv4 address used later on.
https://getipv6.info/display/IPv6/Cisco+6to4+Relay+Service
IPv4-Compatible IPv6 Tunnels (auto-tunnel)
Although they are simpler to configure, IPv4-compatible IPv6 tunnels have in fact been deprecated. These tunnels are described here for completeness in case they are encountered in existing configurations.
IPv4-compatible IPv6 tunnels are very similar to 6to4 tunnels: they both are used to connect IPv6 domains over an IPv4 network, they both are point-to-multipoint tunnels, and both embed an IPv4 address within the IPv6 address so that the tunnel destination IPv4 address is easily obtained by the router and it can therefore automatically create the tunnel. The difference is how the IPv4 address is embedded. The IPv4-compatible IPv6 address is simply an IPv6 address with 96 bits filled with 0s followed by the 32-bit IPv4 address in the lower 32 bits; the 32-bit portion is even written in dotted-decimal format.
For example, if the IPv4 address is 172.16.101.1, the IPv4-comaptible IPv6 address is ::172.16.101.1.
The limitations of IPv4-compatible IPv6 tunnels are the same as those for 6to4 tunnels, for the same reasons, including that only static routes or BGP can be used across them, and the limitation on the IPv6 addressing plan.
In automatic tunneling, the tunnel endpoint address is determined by the IPv4-compatible destination address of the IPv6 packet being tunneled.
Automatic tunneling allows IPv6/IPv4 nodes to communicate over IPv4 routing infrastructures without pre-configuring tunnels.
(http://www.ietf.org/rfc/rfc2893.txt)
| 96-bits | 32-bits |
+--------------------------------------+--------------+
| 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+
IPv4-Compatible IPv6 Address Format
IPv4-Compatible IPv6 Addresscan be written as:
::10.1.21.2
0:0:0:0:0:0:10.1.21.2
::0A01:1502
Only one new command is used: the tunnel mode ipv6ip auto-tunnel interface configuration command specifies IPv6 automatic tunneling mode using an IPv4-compatible IPv6 address
R1(config)#interface tunnel 12
R1(config-if)#no ip address
R1(config-if)#tunnel source loopback 101
R1(config-if)#tunnel mode ipv6ip auto-tunnel
R1(config-if)#
R1(config)# ipv6 route 24::/64 ::172.16.102.1
R2(config)#interface tunnel 12
R2(config-if)#no ip address
R2(config-if)#tunnel source loopback 102
R2(config-if)#tunnel mode ipv6ip auto-tunnel
debug tunnel
IPv6 ISATAP Tunnels
You can use ISATAP–the Intra-site Automatic Tunnel Addressing Protocol–to identify the IPv4 address of the remote site for the purposes of tunneling IPv6 packets. As a result, you can create dynamic multipoint tunnels using ISATAP, in general a concept much like the multipoint tunnels created using automatic 6to4 tunnels.
The goal of ISATAP is to provide connectivity for IPv6 hosts to a centralized IPv6-capable router, over an IPv4-only access network. ISATAP was designed to transport IPv6 packets within a site (hence the “intra-site” part of its name). It can still be used between sites, but its purpose is within sites.
Comparing ISATAP and Automatic 6to4 Concepts
ISATAP tunnels differ in some ways with automatic 6to4 tunnels. However, ISATAP IPv6 tunnels use concepts that closely match those used by automatic 6to4 tunnels when using global unicast addresses.
- ISATAP tunnels use global unicast prefixes for user subnets,
- ISATAP tunnel interfaces use IPv6 addresses that embed the tunnel’s destination IPv4 address inside the IPv6 address.
- The routers need static routes for the destination end-user IPv6 prefixes; the route must list a next-hop IPv6 address, which in turn embeds the tunnel destination IPv4 address.
- ISATAP tunnel interface IPv6 addresses embed the IPv4 address in the last two quartets.
- ISATAP tunnels do not use a special reserved range of IPv6 addresses at all, instead using just normal IPv6 unicast prefixes.
- ISATAP tunnels typically use a single prefix to which all tunnel interfaces connect, so all routers have a connected IPv6 route to that same subnet.
- ISATAP tunnels can automatically derive the tunnel interface’s interface ID by using modified EUI-64 rules.
ISATAP tunnels use IPv6 addresses in the format:
- The 64-bit IPv6 prefix can be any valid unicast prefix, including a global routable prefix, a link-local prefix, or even a 6to4 prefix. The prefix should be selected according to the address plan for the network.
- The upper 32 bits of the interface ID are 0000:5EFE, a reserved OUI value indicating an IPv6 ISATAP address.
- The lower (least significant) 32 bits of the interface ID contain the IPv4 address of the interface (written in hexadecimal). This embedded IPv4 address is
used to create the tunnel, similar to other mechanisms. For example, consider the IPv4 address 172.16.101.1, the hexadecimal equivalent of this address is AC10:6501. Therefore the 64-bit interface ID would be 0000:5EFE:AC10:6501.
ISATAP addresses use:
- the locally administered interface identifier ::0:5EFE:w.x.y.z, in which w.x.y.z is a private unicast IPv4 address,
- or ::200:5EFE:w.x.y.z, in which w.x.y.z is a public unicast IPv4 address.
The interface identifier portion of an ISATAP address contains an embedded IPv4 address that is used to determine the destination IPv4 address for the IPv4 header when ISATAP-addressed IPv6 traffic is tunneled across an IPv4 network.
As a transition strategy, ISATAP is an ideal, scalable solution for enterprise campus and branch sites because IPv6 connectivity can be automatically activated over an existing IPv4 network while the organization gradually migrates to an all-IPv6 network. Only the ISATAP router requires configuration.
ISATAP is supported in popular operating systems including Windows XP, Vista, Windows 7, and Linux. An ISATAP tunnel is typically created from a host, such as a PC, to an ISATAP router. The tunnel is established using the IPv4 addresses of both the host and the router, across the IPv4 campus. The host establishes the tunnel only when it needs to. Hosts can discover the tunnel destination address (the IPv4 address of the router) dynamically through DNS or via a local statically configured definition (on the host itself). Because both IPv4 and tunneled IPv6 packets are transported over a single common IPv4 infrastructure, IPv4-dependent applications can continue to use IPv4 while newer IPv6-capable applications can be deployed immediately.
The main limitation of ISATAP is that it does not support IPv6 multicast.
Another ISATAP issue is that it cannot operate across a NAT device.
 |
| ISATAP IPv6 tunnel |
- The three tunnel interfaces now have IPv6 addresses in common IPv6 subnet 2000:0:1:9::/64,
- The tunnel interfaces IPv6 addresses conform to modified EUI-64 rules,
- The routers no longer need a route for 2002::/16, instead relying on the connected route created for subnet 2000:0:1:9::/64.
R1
ipv6 unicast-routing
!
interface Loopback1
ip address 10.9.9.1 255.255.255.255
!
interface Tunnel0
no ip address
ipv6 address
ipv6 address 2000:0:1:9::/64 eui-64
tunnel source Loopback1
! Do NOT define a tunnel destination with the tunnel destination
tunnel mode ipv6ip isatap
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2000:0:1:1::1/64
!
! Define a static route for 2002::16, with outgoing interface of the tunnel interface
ipv6 route 2000:0:1:3::/64 2000:0:1:9:0:5EFE:A09:903
ipv6 route 2000:0:1:4::/64 2000:0:1:9:0:5EFE:A09:904
R3
ipv6 unicast-routing
!
interface Loopback3
ip address 10.9.9.3 255.255.255.255
!
interface Tunnel9
no ip address
ipv6 address 2000:0:1:9::/64 eui-64
tunnel source Loopback3
tunnel mode ipv6ip isatap
!
interface FastEthernet0/1
ip address 10.1.3.3 255.255.255.0
ipv6 address 2000:0:1:3::3/64
!
ipv6 route 2000:0:1:1::/64 2000:0:1:9:0:5EFE:A09:901
ipv6 route 2000:0:1:4::/64 2000:0:1:9:0:5EFE:A09:904