Cis185 route-lecture8-i pv6-part3

CIS 185 CCNP ROUTECh. 8 Implementing IPv6 – Part 3

Rick GrazianiCabrillo [email protected]

Last Updated: Fall 2010

2

Materials Book:

Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: Foundation learning for the ROUTE 642-902 Exam

By Diane Teare Book

ISBN-10: 1-58705-882-0 ISBN-13: 978-1-58705-882-0

eBook ISBN-10: 0-13-255033-4 ISBN-13: 978-0-13-255033-8

Fortunately, the transition from IPv4 to IPv6 does not require upgrades on all nodes at the same time

IPv4 and IPv6 will coexist for some time. There are many RFCs that relate to this transition

3

Techniques for the period of transition between IPv4 and IPv6:

Dual-stack techniques: Hosts and network devices run both IPv4 and IPv6 at the same time. Useful as a temporary transition But has a lot of 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 dual-stacked. Scalability may be an issue if many tunnels need to be created.

Translation techniques: A translator converts IPv6 packets into IPv4 packets and vise versa Allows IPv6-only devices to communicate with IPv4-only devices. Scalability may again be an issue because of the resources required on

the translator device.

4

Transition methods between IPv4 and IPv6

Dual-stack Tunneling

Manual Manual IPv6 Tunnel GRE IPv6 Tunnel

Dynamic 6to4 Tunnel IPv4-Compatible IPv6 Tunnel (deprecated) ISATAP Tunnel

Translation Static NAT-PT for IPv6 Dynamic NAT-PT for IPv6

5

Dual Stack

Integration method in which a node has connectivity to both an IPv4 and IPv6 network

Node has two protocol stacks. A dual-stack node chooses which stack to use based on destination

address: Prefers IPv6 when available

6

R1 is configured as dual-stacked. FastEthernet 0/0 interface has two addresses on it:

IPv4 IPv6

For both protocols the addresses on R1 and R2 are on the same network. 7

IPv4: 10.10.10.1/24 IPv4: 10.10.10.2/24

IPv6: 2001:12::1/64 IPv6: 2001:12::2/64

R1(config)# inter fa 0/0R1(config-if)# ip add 10.10.10.1 255.255.255.0R1(config-if)# ipv6 add 2001:12::1/64

R1(config)# show ip interface fa 0/0FastEthernet0/0 is up, line protocol is up Internet address is 10.10.10.1/25 Broadcast address is 255.255.255.255 <output omitted>

R1(config)# show ipv6 interface fa 0/0FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::219:56FF:FE2C:9F60 Global unicast address(es): 2001:12::1, subnet is 2001:12::/64 Joined group address(es): FF02::1 FF02::2 <output omitted>

R1 R2

A drawback of dual stacking is the resources required within each device configured with both protocols.

The device must keep dual routing tables, routing protocol topology tables, etc.

8

IPv4: 10.10.10.1/24 IPv4: 10.10.10.2/24

IPv6: 2001:12::1/64 IPv6: 2001:12::2/64R1 R2

Tunneling

Tunneling IPv6 Inside IPv4 Packets This enables the connection of IPv6 islands without the need to convert the

intermediary network to IPv6. Tunnels can be either manually or automatically configured.

9

Isolated Dual-Stack Tunneling can also be done between a host and a router, The encapsulated tunnel connects the host to the edge router of the IPv6

network.

10

Some tunneling terminology can be explained using this example: 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. An example of such a protocol is Cisco’s Generic Routing Encapsulation

(GRE) protocol. Encapsulates the passenger protocol. 11

PacketIPv6 Header

IPv4 Header

GRE

Translation

NAT-PT is a translation mechanism that sits between an IPv6 network and an IPv4 network.

The job of the translator (which of course can be a Cisco IOS router) is to: Translate IPv6 packets into IPv4 packets and vice versa

More than an address translator: it is really a protocol translator.

12

AR1

D

NAT-PT

IPv6Network

192.168.2.1 IPv4 Network

2001:DB8:FFFF:1::1 192.168.30.1

Source Address: 2001:DB8:FFFF:1::1 Destination address: 2001:DB8:FFFF:FFFF::A

Source Address: 192.168.2.2 Destination address: 192.168.30.1

Tunneling IPv6 Traffic

13






14

Manual IPv6 Tunnels

Simulates a permanent link between two IPv6 domains over an IPv4 backbone.

Physical interfaces may also be used as the tunnel source and destination interfaces, which also have IPv4 addresses. Best practice is to use loopback interfaces

The end routers implementing a manual tunnel must be dual-stacked

15

Manually tunneling IPv6 inside of IPv4 uses IPv4 protocol 41 and adds a 20-byte IPv4 header (if there are not any options in the header) before the IPv6 header and payload (data).

16

IPv6 DataIPv6 Header

IPv4 Header

Protocol 41


20 bytesIPv6 Manual Tunnel


The IPv6 communication can be made secure with the use of IPsec: Confidentiality Integrity Authentication

17


IPv4 Header

Protocol 41

20 bytes

There are two IPv6 networks:, 13::/64 and 24::/64

Separated by an IPv4-only network. IPv4 RIP is running between R1 and R2 to provide connectivity between the

loopback interface networks. Successful ping and a display of R1’s IPv4 routing table. 18

Objective is to provide full connectivity between the IPv6 islands over the IPv4-only infrastructure.

Since the tunnel does not have an IPv4 address, the no ip address command is used.

The appropriate loopback address is used as the tunnel source Its IPv4 address will be the source address for the tunnel.

IPv4 is functioning here as the encapsulation protocol and as the transport protocol.

The tunnel destination is the IPv4 address of the other router. The tunnel mode command defines the encapsulation;

Manual IPv6 tunnel with IPv6 as the passenger protocol 19

R1(config)# inter tunnel 12R1(config-if)# no ip addressR1(config-if)# ipv6 address 12::1/64R1(config-if)# tunnel source loopback 101R1(config-if)# tunnel destination 10.2.2.2R1(config-if)# tunnel mode ipv6ip

R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address 12::2/64R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destination 10.1.1.1R2(config-if)# tunnel mode ipv6ip

Shows the tunnel interface encapsulating the outgoing IPv6 traffic and decapsulating the return traffic.

The debug also indicates that an additional 20 bytes are being added to the packet; this is the IPv4 packet header.

20

The tunnel mode is indicated in the “Tunnel protocol/transport IPv6/IP” line

21

R1# show interface tunnel 12Tunnel12 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set, Keepalive not set Tunnel source 10.1.1.1 (Loopback101, destination 10.2.2.2 Tunnel protocol/transport IPv6/IP

The RIPng process RIPoTU will be enabled between: R3 and R1 R2 and R4 IPv6 tunnel between R1 and R2

The tunnel interface can participate in routing just like any other IPv6 link. Notice that:

RIPng will run across the tunnel while IPv4 RIP is running across the physical interfaces: to provide connectivity

between the IPv4 addresses on the loopback interfaces. 22

IPv4 RIP is running across the physical interfaces On R1 and R2, RIPng is enabled on the tunnel

interface and on the FastEthernet interface. On R3 and R4, RIPng is only enabled on the

FastEthernet interfaces. 23

R1(config)# ipv6 unicast-routingR1(config)# interface tunnel 12R1(config-if)# no ip addressR1(config-if)# ipv6 address 12::1/64R1(config-if)# tunnel source loopback 101R1(config-if)# tunnel destination 10.2.2.2R1(config-if)# tunnel mode ipv6ipR1(config-if)# ipv6 rip RIPoTU enable

R1(config)# interface fa 0/0R1(config-if)# ipv6 add 13::1/64R1(config-if)# ipv6 rip RIPoTU enable

R1(config)# ipv6 router rip RIPoTUR1(config)# router ripR1(config-router)# network 172.16.0.0

R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address 12::2/64R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destination 10.1.1.1R2(config-if)# tunnel mode ipv6ipR2(config-if)# ipv6 rip RIPoTU enable



R3(config)# ipv6 unicast-routingR3(config)# interface fa 0/0R3(config-if)# ipv6 add 13::3/64R3(config-if)# ipv6 rip RIPoTU enable

R3(config)# ipv6 router rip RIPoTU



To verify full connectivity across the tunnel, a ping from R3 to R4 is performed; as shown in the example it is successful.

24

R2# show ipv6 route rip

R 13::/64 [120/3] via FE80::A01:101, Tunnel12


R 12::/64 [120/2] via FE80::2, FastEthernet0/0R 13::/64 [120/3] via FE80::2, FastEthernet0/0

R3# ping 24::4

!!!!!R3#






25

GRE IPv6 Tunnels

GRE IPv6 tunnels are very similar to manual tunnels. GRE tunnels were developed by Cisco; GRE encapsulation is the default tunneling protocol (configured with the

tunnel mode command) on Cisco routers.

26

The communication can be made secure with the use IPsec. GRE itself does not provide these security features; it is only an

encapsulation protocol.

27

Objective provide full connectivity between the IPv6 islands over the IPv4-only infrastructure.

The first step is to create a GRE tunnel between routers R1 and R2 Notice that the configuration is identical to the manual tunnel configuration, with one

exception: tunnel mode command is not required since GRE is the default encapsulation

(mode). As before, as soon as the tunnel has been created, the tunnel interface comes

up.

28

R1(config)# ipv6 unicast-routingR1(config)# interface tunnel 12R1(config-if)# no ip addressR1(config-if)# ipv6 address 12::1/64R1(config-if)# tunnel source loopback 101R1(config-if)# tunnel destination 10.2.2.2

R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address 12::2/64R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destination 10.1.1.1

The encapsulation, source address, and destination address can all be verified with this command.

Confirmed that the tunnel mode is GRE (default).

29

R1# show interface tunnel 12Tunnel12 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set, Keepalive not set Tunnel source 10.1.1.1 (Loopback101, destination 10.2.2.2 Tunnel protocol/transport GRE/IP

To verify the tunnel operation, on R2: debug ip packet detail enabled Ping R1’s IPv6 address on the tunnel

The protocol of 47 is also displayed; this is the protocol number for GRE.

30

This is the same configuration used for the manual tunnel example, except: no tunnel mode ipv6ip

31

R1(config)# ipv6 unicast-routingR1(config)# interface tunnel 12R1(config-if)# no ip addressR1(config-if)# ipv6 address 12::1/64R1(config-if)# tunnel source loopback 101R1(config-if)# tunnel destination 10.2.2.2R1(config-if)# tunnel mode R1(config-if)# ipv6 rip RIPoTU enable



R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address 12::2/64R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destination 10.1.1.1R2(config-if)# tunnel mode R2(config-if)# ipv6 rip RIPoTU enable







NOT configured for GRE

The trace confirms the path is via the IPv6 tunnel network 12::/64.

32

We now configure another tunnel, IPv6 GRE tunnel over IPv6. Now - IPv6 is both the transport protocol and the passenger protocol

GRE is still the carrier protocol. IPv6 packets are encapsulated in IPv6 packets. This new tunnel is created between the physical interfaces on R3 and R4 OSPFv3 is configured as the routing protocol over the tunnel R3 and R4 (new) loopback interfaces are in separate OSPFv3 areas. Notice that there is no direct physical connection between R3 and R4; The GRE IPv6 tunnel is configured between R3 and R4,

but the physical path between these routers is still via R1 and R2 (and in the IPv6 world, this path includes the GRE IPv4 tunnel). 33

IPV6 GRE Tunnel over IPv6 Tunnels – Read on your own

Tunnel is created between R3 and R4, as shown in Example 8-110. This configuration is very similar to the previous tunnel configuration. The tunnel destination address is an IPv6 address instead of an IPv4 address One difference is that instead of using the loopback interfaces as tunnel source and

destination, the physical FastEthernet 0/0 interfaces are used Although using loopback interfaces is a best practice (this was done to

demonstrate that it can be done). Another difference is that the tunnel mode gre ipv6 command is added, indicating that

the GRE tunnel is over IPv6 as the transport protocol. 34

R3(config)# ipv6 unicast-routingR3(config)# interface tunnel 34R3(config-if)# no ip addressR3(config-if)# ipv6 address 34::34:4/64R3(config-if)# tunnel source fa0/0R3(config-if)# tunnel destination 24::4R3(config-if)# tunnel mode gre ipv6

R4(config)# ipv6 unicast-routingR4(config)# interface tunnel 34R4(config-if)# no ip addressR4(config-if)# ipv6 address 34::34:4/64R4(config-if)# tunnel source fa0/0R4(config-if)# tunnel destination 24::4R4(config-if)# tunnel mode gre ipv6

Configure OSPFv3 on R3 and R4 Notice that area 0 is between the

routers on the tunnel interface the loopback interfaces are in

different areas (R3’s loopback is in area 33 and R4’s loopback is in area 44).

When the configuration is complete, the adjacency between the two routers goes to full state.

35

R3(config)# ipv6 unicast-routingR3(config)# interface tunnel 34R3(config-if)# no ip addressR3(config-if)# ipv6 address 34::34:4/64R3(config-if)# tunnel source fa0/0R3(config-if)# tunnel destination 24::4R3(config-if)# tunnel mode gre ipv6R3(config-if)# ipv6 ospf 1 area 0

R3(config)# interface loopback 103R3(config-if)# ipv6 address 103::1/64R3(config-if)# ipv6 ospf 1 area 33

R3(config)# ipv6 router ospf 1R3(config-router)# router-id 3.3.3.3

R4(config)# ipv6 unicast-routingR4(config)# interface tunnel 34R4(config-if)# no ip addressR4(config-if)# ipv6 address 34::34:4/64R4(config-if)# tunnel source fa0/0R4(config-if)# tunnel destination 24::4R4(config-if)# tunnel mode gre ipv6R4(config-if)# ipv6 ospf 1 area 0

R4(config)# interface loopback 104R4(config-if)# ipv6 address 104::1/64R4(config-if)# ipv6 ospf 1 area 44

R4(config)# ipv6 router ospf 1R4(config-router)# router-id 4.4.4.4




Dynamic 6to4 Tunnel – Suggested Lab IPv4-Compatible IPv6 Tunnel (deprecated) ISATAP Tunnel


36

Please read about Translation at the end of this chapter

6to4 Tunnels

One of three automatic tunneling methods. 6to4 tunnels are again used to connect IPv6 domains over an IPv4 network They are point-to-multipoint, rather than the point-to-point tunnels discussed

so far. The 6to4 tunnels are built automatically by the edge routers, based on

embedded IPv4 address within the IPv6 addresses of the tunnel interfaces on the edge routers.

37

Some slides temporarily removed

38

The tunnel addresses are the concatenation of: 2002 Converted IPv4 address (172.16.101.1, 172.16.102.1)

A /128 prefix length was chosen in this example network. These addresses will be configured as the IPv6 tunnel interface addresses They embed the IPv4 addresses needed to establish the tunnel.

39

Decimal 172 16 101 1

Binary 1010 1100 0001 0000

0110 0011

0000 0001

Hex A C 1 0 6 5 0 1

Decimal 172 16 102 1

Binary 1010 1100 0001 0000

0110 0110

0000 0001

Hex A C 1 0 6 6 0 1

Objective - provide full connectivity between the IPv6 islands over the IPv4-only infrastructure.

First step - Configure routers R1 and R2 so they establish the 6to4 tunnel between them. Configuration is similar to the manual and GRE tunnel configurations. One difference: tunnel destination is not specified

Because the destination IPv4 address is embedded in the IPv6 address. Another difference is the tunnel mode ipv6ip 6to4 command is specified on each tunnel

interface. As before, as soon as the tunnel has been created, the tunnel interface comes up. 40

R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address

2002:AC10:6601::/128R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destinationR2(config-if)# tunnel mode ipv6 6to4


2002:AC10:6501::/128R1(config-if)# tunnel source loopback 101R1(config-if)# tunnel destinationR1(config-if)# tunnel mode ipv6 6to4

NOT configured

NOT configured

To verify the tunnel operation: debug ipv6 packet detail and debug tunnel on R2

R2: Ping R1’s IPv6 tunnel address shows that the route is not found.

41

Failed

Look at R2’s IPv6 routing table. Notice that R2’s own tunnel address, 2002:AC10:6601::/128 is in the routing

table, but R1’s address is not. This is because the addresses assigned to the each end of the tunnel are

on different subnets (recall that a /128 prefix length was used).

42

Failed?

To resolve this issue, a static route is configured on R2 to R1; on R1 to R2. Since there is only one tunnel, the prefix length used on the static route is /16

Results in any packets with a 2002 prefix being accessible via the tunnel.

43


2002:AC10:6601::/128R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel mode ipv6 6to4

R2(config)# ipv6 route 2002::/16 tunnel12



R1(config)# ipv6 route 2002::/16 tunnel12

The ping is tried again, and it is successful

This time the route is found, via the tunnel interfaces.

The debug output also shows the IPv4 addresses used for tunnel creation, extracted from the IPv6 addresses.

44

To reach destinations beyond the tunnel, more static routes must be added.

Notice that R1 gets to the 24 network via 2002:AC10:6601::, which is R2’s address.

On R2 A static default route can also be configured, to route for all destinations.

45



R1(config)# ipv6 route 2002::/16 tunnel12R1(config)# ipv6 route 24::/16

2002:AC10:6601::



R2(config)# ipv6 route 2002::/16 tunnel12R2(config)# ipv6 route ::/0

2002:AC10:6501::

As the routing table shows, it gets to anything that starts with 2002 via the Tunnel 12 interface.

Thus, R1 can reach network 24 via R2, which it reaches via the tunnel. 46

R1# show ipv6 route static

S 24::/64 [1/0] via 2002:AC10:6601::S 2002::/16 [1/0] via ::; Tunnel12

R1# ping 24::4

!!!!!R1



R1(config)# ipv6 route 2002::/16 tunnel12R1(config)# ipv6 route 24::/16

2002:AC10:6601::






47






48

ISATAP Tunnels

ISATAP tunnels are very similar to 6to4 and IPv4-compatible IPv6 tunnels: they all are used to connect IPv6 domains over an IPv4 network, all embed an IPv4 address within the IPv6 address so that the tunnel

destination IPv4 address is easily obtained by the devices at the end of the tunnel and it can therefore automatically create the tunnel.

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 main limitation of ISATAP is that it does not support IPv6 multicast. This is not an issue for static routing or BGP (like 6to4 tunnels) 49

ISATAP tunnels use IPv6 addresses in the format shown in Figure 8-54; a 64-bit prefix is concatenated to a 64-bit interface ID in EUI-64 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). T his embedded IPv4 address is used to create the tunnel, similar to other

mechanisms. 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. 50

Instead of a host-to-router scenario, this is a router-to-router scenario, using the same network as in Figure 8-53, with the same IPv4 addresses on the loopback interfaces.

Of course, the difference is that now an ISATAP tunnel will be created over the IPv4 network so the tunnel IPv6 addresses will be created automatically.

Recall that there are two IPv6 networks, 13::/64 and 24::/64, separated by an IPv4-only network, and IPv4 RIP is running between R1 and R2 to provide connectivity between the loopback interface networks.

RIPng is running between R1 and R3, and between R2 and R4. 51

Notice that the IPv6 tunnel addresses, on network 12:12::, are derived from the loopback IPv4 addresses.

R1’s loopback address is 172.16.101.1; as discussed earlier, the hexadecimal equivalent of this address is AC10:6501, and therefore its 64-bit interface ID is 0000:5EFE:AC10:6501.

Thus, its IPv6 address is 12:12::0000:5EFE:AC10:6501, which can also be written as 12:12::5EFE:AC10:6501.

Similarly, R2’s loopback address is 172.16.102.1; the hexadecimal equivalent of this address is AC10:6601, and therefore its 64-bit interface ID is 0000:5EFE:AC10:6601.

Thus, its IPv6 address is 12:12::0000:5EFE:AC10:6601, which can also be written as 12:12::5EFE:AC10:6601 52

Configure routers R1 and R2 so that they can establish the ISATAP tunnel Configuration is similar to the previous automatic tunnel configurations. Again, the tunnel destination is not specified, because the destination IPv4 address is

embedded in the IPv6 address. This time an IPv6 address is assigned to the tunnel interface, but only the 64-bit

prefix is specified; the eui-64 keyword is entered, so that the router selects the correct 64-bit interface ID.

The tunnel mode ipv6ip isatap command is specified on each tunnel interface; it is at this point that the router calculates the IPv6 ISATAP address, using the

specified 64-bit prefix, the ISATAP OUI, and the IPv4 address of the tunnel source (in hexadecimal format of course).

53

R2(config)# ipv6 unicast-routingR2(config)# interface tunnel 12R2(config-if)# no ip addressR2(config-if)# ipv6 address 12:12::/64 eui-64R2(config-if)# tunnel source loopback 102R2(config-if)# tunnel destinationR2(config-if)# tunnel mode ipv6 isatap


NOT configured

NOT configured

54

To verify connectivity, debugging is enabled and R2’s tunnel IPv6 address is pinged from R1, as shown in Example 8-123.

The ping is successful. The debug output confirms that the IPv4 addresses are being extracted from the

ISATAP addresses to establish the tunnel across the network when IPv6 packets need to be sent.

The ping is repeated, this time using R2’s tunnel IPv6 link-local address; recall that the interface must be specified when a link-local address is used. The ping is successful.

Unlike the previous tunneling mechanisms we discussed, ISATAP tunnels have predictable link-local addresses that are automatically created and use the tunnel mechanism.

ISATAP is designed for traffic within a site, so that for hosts the tunnel appears as a connection to a normal Ethernet interface. 55

R1# ping 12:12::5EFE:AC10:6601

!!!!!R1#R1# ping FE80::5EFE:AC10:6601

!!!!!R1#

To reach destinations beyond the tunnel, a static route must be added. Example 8-124 illustrates the use of a static route on R1, using R2’s link-

local address. Note that the outgoing interface must again be specified in the static route

command when using a link-local address. This static route points to R2’s link-local address as the way to get to the

24::/64 network between R2 and R4. Since this IPv6 address has the IPv4 address embedded within it, the tunnel

is created, and a ping from R1 to R4 works, as also shown in the example. 56


R1(config)# ipv6 route 24::/64 tunnel12 FE80::5EFE:AC10:6601

NOT configured

R1# ping 24::4

!!!!!R1#






57

NAT-PT is another powerful transition technique, but is not a replacement for the other techniques, such as dual-stack and tunneling, discussed so far in this chapter.

Used in situations where direct communication between IPv6-only and IPv4-only networks is desired.

It would not be appropriate in situations where connectivity between two IPv6 networks is required, since two points of translation would be necessary, which would not be efficient or effective.

With NAT-PT, all configuration and translation is performed on the NAT-PT router; the other devices in the network are not aware of the existence of the other protocol’s network, nor that translations are occurring. 58

DNS is crucial in real-life NAT-PT architectures, because applications initiate traffic from hosts, and DNS translates domain names to IP addresses.

Since 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.

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. 59

Static NAT-PT for IPv6

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. 60

the ipv6 nat v6v4 source command is used to configure the mapping between R4’s IPv6 source address (14::4) and the IPv4 address that R4 appears as in the IPv4 world (172.16.123.100).

Notice that 172.16.123.100 is a valid address on the subnet between R1 and R2; it is an unused IP address on the destination subnet, so R1 does not need to advertise a new subnet to R2.

Traffic coming from R4 will therefore look like it is coming from this R1-R2 subnet.

shows the ipv6 nat v4v6 source command, used to configure the mapping for return traffic— between R2’s IPv4 source address (172.16.123.2) and the IPv6 address that R2 appears as in the IPv6 world (1144::1).

This IPv6 address does not exist in the IPv6 world; it is an unused address selected to represent IPv4 devices in the IPv6 world;

it is on the NAT-PT prefix, which is configured next. 61

R1(config)# interface serial 0/0/0R1(config-if)# ipv6 add 14::1/64R1(config-if)# ipv6 nat

R1(config)# interface serial 0/1/0R1(config-if)# ip add 172.16.123.1 255.255.255.0R1(config-if)# ipv6 nat

R1(config)# ipv6 nat v6v4 source 14::4 172.16.123.100R1(config)# ipv6 nat v4v6 source 172.16.123.2 1144::1R1(config)# ipv6 nat prefix 1144::/96

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 command creates a connected route in R1’s

routing table. 62




displays the output of the show ipv6 route connected command, confirming that the NAT-PT 96-bit prefix is there.

Notice that this prefix is directly connected to the interface NVI0;

NVI is a NAT virtual interface and exists to allow NAT traffic flows.

63

R1# show ipv6 route static

C 13::/64 [1/0] via FastEthernet0/0, directly connectedC 14::/64 [1/0] via Serial0/0/0, directly connectedC 1144::/96 [0/0] via NV10, directly connected

R1#

So, on R1, the redistribute connected command (with a seed metric of 3) is entered under the RIPng process.

R4 now has a route to the 1144 prefix and can forward traffic to it. 64




R1(config)# ipv6 router rip NAT-PTR1(config-rtr)# redistribute connected metric 3


R 13::/64[120/2] via FE80::1, Serial 1/1.7R 1144::/96 [120/4] via FE80::1, Serial 1/1.7

R4#

Successful ping is sent from R4 to 1144::1, the IPv6 address representing R2; two static translation entries: 172.16.123.100 to 14::4, and 172.16.123.2 to 1144::1, as

well as the ICMP entry created for the ping. 65




R1(config)# ipv6 router rip NAT-PTR1(config-rtr)# redistribute connected metric 3

R1# show ipv6 nat translationsProt 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

R4# ping 1144::1!!!!!R4#

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. 66

67

we want to dynamically translate traffic coming from the R3 and R4 loopback interface addresses to a pool of IPv4 addresses, and to dynamically translate traffic sourced from the R3 and R4 physical interfaces to be dynamically translated to a different pool of IPv4 addresses.

R2’s two interface addresses are destination addresses in this scenario and will be represented by (translated to) two different IPv6 addresses.

This scenario simulates multiple IPv6 host devices being translated to different address pools as they communicate with multiple IPv4 hosts.

68

displays the translations that will occur in this example. For traffic sourced from the R3 and R4 physical interfaces (14::4 and 14::3),

a pool on the 172.16.123.0 subnet is used, specifically the 172.16.123.100 and 172.16.123.101 addresses.

For traffic sourced from the R3 and R4 loopback interfaces (104::1 and 103::1), a pool on the 172.16.12.0 subnet is used, specifically the 172.16.12.100 and 172.16.12.101 addresses.

The destination address 1144::1 represents R2’s 172.16.123.2 interface in the IPv6 world, and the destination address 1144::2 represents R2’s 172.16.12.2 interface in the IPv6 world 69

70

R1(config)# interface fa0/0R1(config-if)# ipv6 add 13::1/64R1(config-if)# ipv6 natR1(config)# interface serial 0/0/0.2R1(config-if)# ip add 172.16.12.1 255.255.255.0R1(config-if)# ipv6 natR1(config)# interface serial 0/0/0.4R1(config-if)# ipv6 add 14::1/64R1(config-if)# ipv6 natR1(config)# interface serial 0/1/0R1(config-if)# ip add 172.16.123.1 255.255.255.0R1(config-if)# ipv6 nat

R1(config)# ipv6 nat v4v6 source 172.16.12.2 1144::2R1(config)# ipv6 nat v4v6 source 172.16.123.2 1144::1

R1(config)# ipv6 nat v4v6 source list LOOPBACK pool POOL_12

R1(config)# ipv6 nat v4v6 source list PHYSICAL pool POOL_123

R1(config)# ipv6 nat v4v6 pool POOL_12 172.16.12.100 172.16.12.101 prefix-length 24

R1(config)# ipv6 nat v4v6 pool POOL_123 172.16.123.100 172.16.12.101 prefix-length 24

CIS 185 CCNP ROUTECh. 8 Implementing IPv6 – Part 3

Rick GrazianiCabrillo [email protected]

Last Updated: Fall 2010

Documents

Cis185 route-lecture8-i pv6-part3