IPv6 in an EN2018-02-22
IPv6 Packet Header
- Version - A 4-bit field, the same as in IPv4. For IPv6, this field contains the number 6. For IPv4, this field contains the number 4.
- Traffic class - An 8-bit field similar to the Type of Service (ToS) field in IPv4. This field tags the packet with a traffic class that it uses in differentiated services (DiffServ) quality of service (QoS). These functionalities are the same for IPv6 and IPv4.
- Flow label - This 20-bit field is new in IPv6. It can be used by the source of the packet to tag the packet as being part of a specific flow, allowing multilayer switches and routers to handle traffic on a per-flow basis rather than per-packet, for faster packet-switching performance. This field can also be used to provide QoS.
- Payload length - This 16-bit field, allowing payloads of up to 64 kilobytes (kB), is similar to the IPv4 total length field.
- Next header - The value of this 8-bit field determines the type of information that follows the basic IPv6 header. It can be a transport-layer packet, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), or it can be an extension header. The next header field is similar to the protocol field of IPv4.
- Hop limit - This 8-bit field specifies the maximum number of hops that an IP packet can traverse. Similar to the Time To Live (TTL) field in IPv4, each router decreases this field by one. Because there is no checksum in the IPv6 header, an IPv6 router can decrease the field without recomputing the checksum, whereas in IPv4 routers, the recomputation uses processing time. If this field ever reaches zero, a message is sent back to the source of the packet and the packet is discarded.
- Source address - This field has 16 octets or 128 bits. It identifies the source of thepacket.
- Destination address - This field has 16 octets or 128 bits. It identifies the destination of the packet.
- Extension headers - The extension headers, if any, and the data portion of the packet follow the other eight fields. The Next header field defines the type of the next extension header. The number of extension headers is not fixed, so the total length of the extension header chain is variable.
Most extension headers are not examined or processed by any node other than the node to which the packet is destined. The destination node examines the first extension header (if there is one). The contents of an extension header determine whether or not the node should examine the next header. Therefore, extension headers must be processed in the order they appear in the packet.
There are many types of extension headers. Only a hop-by-hop options header, if it is present, must be examined by every node along the path. This hop-by-hop options header, if present, must immediately follow the IPv6 header, and is indicated by a value of zero in the next-header field.
- IPv6 header: This is the basic IPv6 header.
- Hop-by-hop options header: When this header is used, it is processed by all hops (routers) in the path of the packet. Example uses are for a Router Alert, including for Resource Reservation Protocol (RSVP) and Multicast Listener Discovery (MLD) messages (as defined in RFC 2711, IPv6 Router Alert Option), and for IPv6 Jumbograms (as defined in RFC 2675, IPv6 Jumbograms).
- Destination options header (when a routing header is used): This header (with a next-header value = 60) follows any hop-by-hop options header, in which case the destination options header is processed at the final destination and also at each destination specified by a routing header. Alternatively, the destination options header can follow any Encapsulating Security Payload (ESP) header, in which case the destination options header is processed only at the final destination. Mobile IPv6 is an example of when this header is used. (The destination options header should occur at most twice, once before a routing header and once before the upper-layer header).
- Routing header: This header (with a next-header value = 43) is used for source routing and mobile IPv6. An IPv6 source lists one or more intermediate nodes that are to be visited on the way to a packet’s destination in this header.
- Fragment header: This header (with a next-header value = 44) is used when a source must fragment a packet that is larger than the maximum transmission unit (MTU) for the path between itself and a destination device. The fragment header is used in each fragmented packet. (This header cannot be used in combination with the jumbo payload hop-by-hop option.)
- Authentication header and Encapsulating Security Payload header: The Authentication Header (AH) (with a next-header value = 51) and the ESP header (with a next-header value = 50) are used within IPsec to provide authentication, integrity, and confidentiality of a packet. These headers are identical for both IPv4 and IPv6.
- Upper-layer header: The upper-layer (transport) headers are the typical headers used inside a packet to transport the data. The two main transport protocols are TCP (with a next-header value = 6) and UDP (with a next-header value = 17).
In IPv4, routers handle fragmentation, causing a variety of processing issues. IPv6 routers no longer perform fragmentation; instead, a discovery process is used by the source IPv6 device to determine the optimum MTU to use during a given session. In this discovery process, the source IPv6 device attempts to send a packet at the size that is specified by the upper IP layers, for example, the transport and application layers. If the source IPv6 device receives an Internet Control Message Protocol for IPv6 (ICMPv6) “packet too big” message, it retransmits the MTU discover packet with a smaller MTU. This process is repeated until the device receives a response that the discover packet arrived intact.
The device then sets the MTU for the session. (Note that the device may still fragment IPv6 packets, as noted in the earlier discussion of fragment header.) Devices perform an MTU discovery every 5 minutes to see whether the MTU has increased along the path. Application and transport layers for IPv6 accept MTU reduction notifications from the IPv6 layer.
EUI-64 Format IPv6 Interface Identifier
R1(config-if)#ipv6 address 2001:8:85a3:4289::/64 eui-64 <output omitted> R1#show ipv6 interface loopback 100 Loopback100 is up, line protocol is up IPv6 is enabled, link-local address is FE80::21B:D5FF:FE5B:A408 Global unicast address(es): 2001:8:85A3:4289:21B:D5FF:FE5B:A408, subnet is 2001:8:85A3:4289::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::1:FF5B:A408 MTU is 1514 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds
IPv6 Address Types
- Unicast - Similar to an IPv4 unicast address, an IPv6 unicast address is for a single interface. A packet that is sent to a unicast address goes to the interface identified by that address. As in IPv4, a subnet prefix in IPv6 is associated with one link. The IPv6 unicast address space encompasses the entire IPv6 address range, with the exception of the FF00::/8 range (addresses starting with binary 1111 1111), which is used for multicast addresses.
- Multicast - An IPv6 multicast address identifies a set of interfaces on different devices. Just as in IPv4, a acket sent to a multicast address is delivered to all the interfaces identified by the multicast address. The range of multicast addresses in IPv6 is larger than in IPv4, and for the foreseeable future, allocation of IPv6 multicast groups is not being limited.
- Anycast - An IPv6 anycast address is a new type of address that is assigned to a set of interfaces on different devices; an anycast address identifies multiple interfaces. A packet that is sent to an anycast address goes to the closest interface (as determined by the routing protocol being used) identified by the anycast address. Therefore, all nodes with the same anycast address should provide the same (uniform) service. Examples of when anycast addresses could be used are load balancing and content delivery services.
Global Unicast Addresses
Link-Local Unicast Addresses
Link-local addresses have a scope limited to the local link and are dynamically created on all IPv6 interfaces by using a specific link-local prefix FE80::/10 and a 64-bit interface identifier.
Site-Local Unicast Addresses: Deprecated
Site-local addresses were originally created to be similar to IPv4 private addresses. Note that this address type has since been deprecated (it is no longer supported). Because of the huge IPv6 address space, private addresses are not needed and using them would mean that NAT would be required and that addresses would again not be end-to-end. Site-local addresses are mentioned here only for legacy reasons.
IPv6 Multicast Addresses
A multicast address identifies a group of interfaces; traffic sent to a multicast address travels to multiple destinations at the same time. An interface may belong to any number of multicast groups. Multicasting is extremely important to IPv6, because it is at the core of many IPv6 functions and it is a replacement for broadcast.
- The transient (T) flag parameter is equal to 0 for a permanent, or well-known, multicast address. The flag is equal to 1 for a temporary (also known as a transient or dynamically assigned) multicast address.
- The prefix (P) flag parameter indicates a prefix. This flag allows part of the multicast group address to include the unicast prefix of the source network.
- The 4-bit scope parameter values include 1 for the node scope (for loopback transmission), 2 for the link scope (similar to unicast link-local scope), 5 for the site-local scope, 8 for the organizational scope (for multiple sites), and E for the global scope.
For example, a multicast address starting with FF02::/16 is a permanent multicast address with a link-local scope. There is no TTL field in IPv6 multicast packets because the scoping is defined inside the address. The multicast addresses FF00:: to FF0F:: have the T flag set to 0 and are reserved. Within that range, the following are some example assigned addresses. (Many more assignments are made, and assignments are tracked by IANA.)
- FF02::1 - “All nodes” on a link (link-local scope). Note The FF02::1 multicast address is similar to a broadcast on a link.
- FF02::2 - “All routers” on a link.
- FF02::9 - “All routing information protocol (RIP) routers” on a link.
- FF02::1:FFXX:XXXX - Solicited-node multicast on a link, where the XX:XXXX is the far right 24 bits of the corresponding unicast or anycast address of the node. Solicited-node multicast addresses are used in neighbor solicitation (NS) messages, which are sent on a local link when a node wants to determine the link-layer address of another node on the same local link, similar to the Address Resolution Protocol (ARP) in IPv4.
- FF05::101 - “All Network Time Protocol (NTP) servers” in the site (site-local scope). (The site-local multicast scope has an administratively assigned radius and has no direct correlation to the now deprecated site-local unicast prefix of FEC0::/10.
- Node A has IPv6 address 2001:DB8:200:300:400:500:1234:5678.
- Node B has IPv6 address 2001:DB8:200:300:400:500:AAAA:BBBB, and would therefore have solicited-node multicast address FF02:0:0:0:0:1:FFAA:BBBB, which can also be written as FF02::1:FFAA:BBBB.
- Node C has IPv6 address 2001:DB8:200:300:400:501:AAAA:BBBB, and would therefore have solicited-node multicast address FF02::1:FFAA:BBBB. Note that this is the same as node B’s solicited-node multicast address.
The neighbor discovery process uses these solicited-node multicast addresses. When node A desires to exchange packets with node B, node A sends an NS message to the solicited-node multicast address of node B, FF02::1:FFAA:BBBB. This message contains, in addition to other data, the full IPv6 address that node A is looking for, 2001:DB8:200:300:400:500:AAAA:BBBB. This is called the target address.
An IPv6 anycast address is a global unicast address that is assigned to more than one interface. For IPv6, anycast is defined as a way to send a packet to the nearest (or closest) interface that is a member of the anycast group, thus providing a discovery mechanism to the nearest point.
For directly connected neighbors, the nearest interface is found according to the first neighbor that is learned about. Otherwise, the nearest interface is found according to the measure of the metric of the routing protocol.
Note. On a Cisco router, an IPv6 address becomes an anycast address when the anycast keyword is added to the end of the ipv6 address command.
An example use in a Border Gateway Protocol (BGP) multihomed network would be when a customer has multiple ISPs and multiple connections to each one. Each ISP could have a different anycast address. The same anycast address would be used for all routers of a given ISP. A customer device chooses which ISP to send the packet to the routers along the path determine the closest router by which that ISP can be reached using the IPv6 anycast address. Another use for an anycast address is when multiple routers are attached to a LAN. These routers can have the same IPv6 anycast address so that distant devices only need to identify the anycast address. Intermediate devices choose the best path to reach the closest entry point to that LAN.
Configuring Unicast Addresses
IPv6 Unnumbered Interfaces
A loopback interface is created and configured with an IPv6 address. The Serial 0/0/0 interface is then configured to use the IPv6 address of the loopback interface, with the ipv6 unnumbered loopback 10 command.
R1(config-if)#exit R1(config)#interface loopback 10 R1(config-if)#ipv6 address 2003:1::10/64 R1(config-if)#interface s0/0/0 R1(config-if)#ipv6 unnumbered loopback 10 R1(config-if)#
Stateless Autoconfiguration of IPv6 Addresses
Stateless Autoconfiguration Uses Router Solicitations and Router Advertisements
DAD is used during the autoconfiguration process to ensure that no other device is using the autoconfiguration address.
Stateless autoconfiguration can also be used for renumbering devices easily, to renumber an entire site you only need renumber the routers.
Notice the difference between when routers generate RS and RA messages:
- Routers configured with the ipv6 unicast-routing command generate ICMPv6 RA messages. They do not generate RS messages.
- Routers configured with the ipv6 address auto-config command, and not configured with the ipv6 unicast-routing command, generate RS messages only. They do not generate RA messages.
The STALE state occurs when the specified address that was formerly in the REACH state has not been heard from within the time specified in the ipv6 nd reachable-time milliseconds command. The STALE state means that entry has not been used within in the reachable time. The REACH state means that the entry has been used in the reachable time.
R1#show ipv6 neighbors IPv6 Address Age Link-layer Addr State 2001:1::2 0 0019.55df.ad22 REACH FE80::219:55FF:FEDF:AD22 0 0019.55df.ad22 STALE
- Static routes
- RIP new generation (RIPng) (defined in RFC 2080, RIPng for IPv6)
- OSPFv3 (defined in RFC 5340, OSPF for IPv6)
- Intermediate System-Intermediate System (IS-IS) for IPv6
- Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6
- Multiprotocol Border Gateway Protocol Version 4 (MP-BGP4 or MBGP) (defined in RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and RFC 4760, Multiprotocol Extensions for BGP-4)
- A directly attached static route is created using only the interface-type and interface-number parameters. The specified interface must be up and have IPv6 enabled. The destination prefix is assumed to be reachable out of the specified interface; the packet’s destination address is used as the next-hop address.
- A recursive static route is created using only the next-hop address parameter. An example is ipv6 route 2001:CC1E::/32 2001:12::1, which specifies that 2001:CC1E::/32 is reachable via the neighbor with address 2001:12::1. The router uses its routing table to determine the appropriate interface to use, which is the interface used to reach the next-hop address, so there must be such a route in the routing table. IPv6 recursive static routes are checked at 1-minute intervals. Therefore a recursive static route may take up to one minute to be inserted into the routing table once its next hop becomes valid. Likewise, it may take a minute or so for the route to disappear from the table if the next hop becomes invalid.
- A fully specified static route includes both the outgoing interface and the next hop address. An example is ipv6 route 2001:CC1E::/32 serial 0/0/0 2001:12::1
- A floating static route can also be configured, which again operates similar to its IPv4 counterpart. The administrative distance of the static route is set to a value higher than the administrative distance of any dynamic routing protocol or other method used to reach a particular destination. The static routes function as a backup to the routes discovered by the dynamic routing protocol and will not be installed inthe routing table unless the entry for the dynamic routing protocol is deleted, for example because of a link failure.
- RIPng is based on IPv4 RIP Version 2 (RIPv2).
- RIPng uses IPv6 for transport.
- RIPng uses link-local addresses as source addresses.
- RIPng uses an IPv6 prefix and a next-hop IPv6 address.
- RIPng uses the multicast address FF02::9, the all RIPng routers multicast address, as the destination address for RIPng updates.
- The RIPng administrative distance is 120.
- RIPng updates are sent on UDP port 521.
To segregate the RIPng domains, the port number and or the multicast group address parameters must be changed. Notice that the multicast group address was left as the default FF02::9. After the process has been changed, the routing tables on R1 and R3 are cleared and then checked; there are no longer any RIPng routes on either router. Therefore, R1 and R3 are no longer listening to the updates from R2, because they are using different ports.
R3(config)#ipv6 router rip R1R3 R3(config-rtr)#port 1013 multicast-group FF02::9 R3#clear ipv6 route * R1(config)#ipv6 router rip R1R3 R1(config-rtr)#port 1013 multicast-group FF02::9 R1#clear ipv6 route *
Changing the port and or multicast group addresses separates the processes. Redistribution must be configured to share information between these separate processes.
- Every OSPFv2 IPv4-specific semantic is removed.
- Uses 128-bit IPv6 addresses.
- Uses link-local addresses as source addresses.
- Multiple addresses and OSPF instances per interface are permitted.
- Supports authentication (using IPsec).
- Runs over a link rather than a subnet.
OSPFv3 uses IPv6 for transport and uses link-local addresses as source address. OSPFv3 has explicit support for multiple instances per link through the instance ID field in the packet header.
The multicast addresses used by OSPFv3 are as follows:
- FF02::5 - This address represents all OSPFv3 routers on the link-local scope. It is equivalent to 188.8.131.52 in OSPFv2.
- FF02::6 - This address represents all designated routers (DRs) on the link-local scope. It is equivalent to 184.108.40.206 in OSPFv2.
- IPv6 addresses are not present in the OSPFv3 packet header (rather they are part of payload information).
- OSPFv3 router LSAs and network LSAs do not carry IPv6 addresses.
- The router ID, area ID, and link-state ID remain at 32 bits and are written in an IPv4-address format (dotted decimal).
- The DR and backup designated router (BDR) are now identified by their router ID, not by their IP address.
EIGRP for IPv6 uses the same protocol number (88) as EIGRP for IPv4 does, and it includes all the same features, including keeping neighbor routing table information in a topology table, and using queries if no feasible successors are available.
A router ID is required for EIGRP for IPv6 configuration. Similar to OSPFv3, the router ID is a 32-bit IPv4 address. In an IPv6-only environment, there are no IPv4 addressesassigned, so the router ID must be configured manually.
EIGRP for IPv6 is configured on a per-interface basis, similar to OSPFv3, the network command is not used. And, also similar to OSPFv3, link-local addressing is used for establishing neighbor adjacencies. Therefore, for EIGRP for IPv6, it is possible for routers to become neighbors even if they do not have global unicast addresses assigned.
The EIGRP for IPv6 routing protocol has a shutdown feature, and in fact it starts in this state. EIGRP for IPv4 automatically summarizes on classful network boundaries. This is not the case with EIGRP for IPv6, it does not automatically summarize.
IPv6-specific extensions incorporated into MBGP include the following:
- A new identifier for the IPv6 address family.
- Scoped addresses - The NEXT_HOP attribute contains a global IPv6 address and potentially a link-local address (only when there is link-local reachability with the peer).
- The NEXT_HOP and Network Layer Reachability Information (NLRI) attributes are expressed as IPv6 addresses and prefixes. (The NLRI field in a BGP update message lists the networks reachable on the BGP path described by the update message.)
In an all-IPv4 environment, BGP establishes sessions using IPv4 (using TCP port 179), IPv4 is the carrier protocol. The routes that BGP advertises are also IPv4. Therefore, IPv4 is also the passenger protocol.
Protocols other than IPv4, including MPLS VPN, multicast, and IPv6, also need to advertise reachability information. MBGP extensions to allow these other protocols to be carried using BGP. An analogy is that BGP is a truck that can transport multiple payloads. For example, the BGP “truck” could be IPv4 and it could be used to transport IPv6 (or other protocol) “payloads.” In this case, the carrier protocol is IPv4 and the passenger protocol is IPv6, the IPv6 prefixes being advertised.
Transitioning IPv4 to IPv6
These techniques can be grouped into the following three categories:
- Dual-stack techniques - Hosts and network devices run both IPv4 and IPv6 at the same time. This technique is useful as a temporary transition, but it adds overhead and uses many resources.
- Tunneling techniques - Isolated IPv6 networks are connected over an IPv4 infrastructure using tunnels. The edge devices are the only ones that need to be dualstacked. Scalability may be an issue if many tunnels need to be created.
- Translation techniques - A translation device converts IPv6 packets into IPv4 packets and vise versa, allowing IPv6-only devices to communicate with IPv4-only devices. Scalability may again be an issue because of the resources required on the translator device.
R1(config)#interface fa0/0 R1(config-if)#ip address 10.10.10.1 255.255.255.0 R1(config-if)#ipv6 address 2001:12::1/64
- IPv4 is the transport protocol, the protocol over which the tunnel is created.
- IPv6 is the passenger protocol, the protocol encapsulated in the tunnel and carried through the tunnel.
- Another protocol is used to create the tunnel, and is known as the tunneling protocol. It is also called the encapsulation protocol or the carrier protocol. An example of such a protocol is the Cisco generic routing encapsulation (GRE) protocol. It encapsulates the passenger protocol.
R1(config)#interface tunnel 12 R1(config-if)#no ip address R1(config-if)#ipv6 address 12::1/64 R1(config-if)#tunnel source loopback 101 R1(config-if)#tunnel destination 10.2.2.2 R1(config-if)#tunnel mode ipv6ip R2(config)#interface tunnel 12 R2(config-if)#no ip address R2(config-if)#ipv6 address 12::2/64 R2(config-if)#tunnel source loopback 102 R2(config-if)#tunnel destination 10.1.1.1 R2(config-if)#tunnel mode ipv6ip
Network Used for End-to-End Connectivity Through a Manual Tunnel
R1(config)#ipv6 unicast-routing R1(config)#interface tunnel 12 R1(config-if)#ipv6 rip RIPoTU enable R1(config-if)#interface fa0/0 R1(config-if)#ipv6 rip RIPoTU enable R2(config)#ipv6 unicast-routing R2(config)#interface tunnel 12 R2(config-if)#ipv6 rip RIPoTU enable R2(config-if)#interface fa0/0 R2(config-if)#ipv6 rip RIPoTU enable R3(config)#ipv6 unicast-routing R3(config)#interface fa0/0 R3(config-if)#ipv6 rip RIPoTU enable R4(config)#ipv6 unicast-routing R4(config)#interface fa0/0 R4(config-if)#ipv6 rip RIPoTU enable
GRE IPv6 Tunnels
R3(config)#interface tunnel 34 R3(config-if)#no ip address R3(config-if)#ipv6 address 34::34:3/64 R3(config-if)#tunnel source fa0/0 R3(config-if)#tunnel destination 24::4 R3(config-if)#tunnel mode gre ipv6 R3(config)#ipv6 router ospf 1 R3(config-rtr)#router-id 220.127.116.11 R3(config-rtr)#exit R3(config)#interface loopback 103 R3(config-if)#ipv6 ospf 1 area 33 R3(config-if)#exit R3(config)#interface tunnel 34 R3(config-if)#ipv6 ospf 1 area 0 R4(config)#interface tunnel 34 R4(config-if)#no ip address R4(config-if)#ipv6 address 34::34:4/64 R4(config-if)#tunnel source fa0/0 R4(config-if)#tunnel destination 13::3 R4(config-if)#tunnel mode gre ipv6 R4(config)#ipv6 router ospf 1 R4(config-rtr)#router-id 18.104.22.168 R4(config-rtr)#exit R4(config)#interface loopback 104 R4(config-if)#ipv6 ospf 1 area 44 R4(config-if)#exit R4(config)#interface tunnel 34 R4(config-if)#ipv6 ospf 1 area 0
The edge routers automatically build the tunnel using the IPv4 addresses that are embedded in the IPv6 addresses. For example, if the IPv4 address of an edge router is 192.168.99.1, the prefix of its IPv6 address is 2002:c0a8:6301::/48, because c0a86301 is the hexadecimal representation of 192.168.99.1.
- The tunnel mode ipv6ip 6to4 interface configuration command specifies IPv6 automatic tunneling mode using a 6to4 address.
- The debug ipv6 packet detail EXEC command enables the display of details about IPv6 packets traversing the router.
R1(config)#interface tunnel 12 R1(config-if)#no ip address R1(config-if)#ipv6 address 2002:AC10:6501::/128 R1(config-if)#tunnel source loopback 101 R1(config-if)#tunnel mode ipv6ip 6to4 R1(config)#ipv6 route 2002::/16 tunnel 12 R2(config)#interface tunnel 12 R2(config-if)#no ip address R2(config-if)#ipv6 address 2002:AC10:6601::/128 R2(config-if)#tunnel source loopback 102 R2(config-if)#tunnel mode ipv6ip 6to4 R2(config)#ipv6 route 2002::/16 tunnel 12
To reach destinations beyond the tunnel, more static routes must be added. Example illustrates the use of the ipv6 route 24::/64 tunnel 12 command, however, as the example also shows, this does not work. The problem is that tunneling is not being triggered. R1 does not have enough information to encapsulate the IPv6 packets because it does not know the IPv4 address to use for the tunnel destination.
R1(config)#ipv6 route 24::/64 tunnel 12 R1(config)#do ping 24::4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 24::4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R1(config)# R1(config)#no ipv6 route 24::/64 tunnel 12 R1(config)#ipv6 route 24::/64 2002:AC10:6601:: R1(config)#do ping 24::4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 24::4, timeout is 2 seconds: !!!!!
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)#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
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.
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). For example, consider the IPv4 address 172.16.101.1. From the earlier Figure 8-52, the hexadecimal equivalent of this address is AC10:6501. Therefore the 64-bit interface ID would be 0000:5EFE:AC10:6501.
R1(config)#interface tunnel 12 R1(config-if)#no ip address R1(config-if)#ipv6 address 12:12::/64 eui-64 R1(config-if)#tunnel source loopback 101 R1(config-if)#tunnel mode ipv6ip isatap R1(config)# ipv6 route 24::/64 tunnel12 FE80::5EFE:AC10:6601 R2(config)#interface tunnel 12 R2(config-if)#no ip address R2(config-if)#ipv6 address 12:12::/64 eui-64 R2(config-if)#tunnel source loopback 102 R2(config-if)#tunnel mode ipv6ip isatap
Translation Using NAT-PT
DNS is crucial in real-life NAT-PT architectures, because applications initiate traffic from hosts, and DNS translates domain names to IP addresses. Because DNS requests may cross the NAT-PT router, a DNS application layer gateway (ALG) is typically implemented in NAT-PT routers to facilitate the name-to-address mapping. The DNS-ALG translates IPv6 addresses in DNS queries and responses into their IPv4 address bindings, and vice versa, as DNS packets traverse between IPv6 and IPv4 domains.
Static NAT-PT Operation
R4 and R2 need to communicate; R4 only has an IPv6 address and R2 only has an IPv4 address. Two static NAT-PT translations are configured on router R1 to allow bidirectional traffic between the two devices. Both the source and destination addresses in both directions will be translated.
R1(config)#interface s0/0/0 R1(config-if)#ipv6 nat R1(config-if)#interface s0/1/0 R1(config-if)#ipv6 nat R1(config-if)#exit 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(config)#exit R1# R1#debug ipv6 routing IPv6 routing table events debugging is on R1#config t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ipv6 nat prefix 1144::/64 % Invalid prefix length R1(config)#ipv6 nat prefix 1144::/32 % Invalid prefix length R1(config)#ipv6 nat prefix 1144::/96
The ipv6 nat prefix command is entered, to define the NAT-PT prefix. Traffic destined to this prefix received on R1 will be translated. In this example, 1144::/64 is the NAT-PT prefix selected; it identifies all destinations on the IPv4-only network. As the example shows, you must configure a 96-bit prefix length. This is because 32-bit IPv4 addresses are translated into 128-bit IPv6 addresses; the difference is 128-32 = 96 bits, so this is the required number of bits in the prefix. Notice that this ipv6 nat prefix com- mand creates a connected route in R1’s routing table.
Dynamic NAT-PT for IPv6
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-if)#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-acl)#ipv6 access-list PHYSICAL R1(config-ipv6-acl)#permit ipv6 13::/64 any R1(config-ipv6-acl)#permit ipv6 14::/64 any R1(config-ipv6-acl)#exit R1(config)# R1(config)#ipv6 nat prefix 1144::/96 R1(config)#ipv6 router rip NAT-PT R1(config-rtr)#redistribute connected metric 1 R1(config-rtr)#exit R1(config)#
IPv4-to-IPv6 Dynamic NAT-PT Configuration and Verification Example
R1(config)#ipv6 nat v6v4 source 13::3 172.16.101.100 R1(config)#ipv6 nat v4v6 source list IPV4 pool POOL_1144 R1(config)#ipv6 nat v4v6 pool POOL_1144 1144::1 1144::2 prefix-length 96 R1(config)#ip access-list standard IPV4 R1(config-std-nacl)#permit 172.16.123.0 0.0.0.255 R1(config-std-nacl)#permit 172.16.12.0 0.0.0.255 R1(config-std-nacl)#ipv6 nat prefix 1144::/96 R1(config)#ipv6 router rip NAT-PT R1(config-rtr)#redistribute connected metric 1 R1(config-rtr)#