Introduction

End hosts inside of the enterprise or home can be connected to the IPv6 internet using LISP’s powerful encapsulation mechanisms.

This article is structured in three sections exploring the utilization of LISP as means of IPv6 internet connectivity. The first section dives into IOS LISP IPv6 configuration and verification of the control-plane/data-plane. The use of SLAAC (RFC 4862) for configuration and addressing of hosts in the IPv6 EID space, with DHCPv6 extensions for DNS is covered in the second section. Additionally, basic Zone Based Firewall configuration in IOS relating to securing the newly exposed EID IPv6 LAN that is leveraged through LISP is covered in the third section.

LISP Configuration

The LISP Beta Network has provided a /48 of publicly routable IPv6 EID addresses for testing. Two /64 subnets out of the allocated /48 will be used in order to connect to the IPv6 internet for this demonstration. The PxTR (Proxy Ingress/Egress Tunnel Router) that the LISP encapsulated packets will forward towards plays a key role in providing IPv6 connectivity. The PxTR is advertising a coarse aggregate of the IPv6 space that it is responsible for into the BGP table with the purpose of attracting traffic destined for those prefixes. It will LISP encapsulate the attracted packets towards the LISP site that the packets are destined to. Additionally, the PxTR accepts LISP encapsulated packets from LISP sites destined to non-LISP sites, then it decapsulates and forwards the packets towards non-LISP sites.

Network Topology

In the following demonstration, the PxTR will be accepting LISP encapsulated packets transmitted over the IPv4 RLOC space provided by the upstream ISP.

The hostname of the edge router on the LISP site used in the examples is LUCENA-1841. This router connects to an ISP via the IPv4 cloud. This IPv4 connection will allow the router to reach the LISP infrastructure (including the PxTR) and tunnel a IPv6 EID prefix using a IPv4 RLOC.

From the configuration snippet below, take note of the following:

The locator-set is configured to use the router’s FastEthernet0/0 interface, which is connected to the ISP and has a IPv4 public non-static address. Setting the interface instead of an IP address is needed when the LISP router does not have static IP addresses provided by the ISP.

Two separate /64 database mappings have been configured. The :0:: prefix will be used locally on the router’s loopback for testing. The :A:: prefix will be used on the LAN interface connected towards the end hosts.

Entries for the MS (Map Server) and MR (Map Resolver) are configured accordingly. These are the IPv4 addresses of the LISP Beta Network mapping infrastructure that will be leveraged.

PETR (Proxy Egress Tunnel Router) is also part of the Beta Network and will serve the egress functions of the PxTR that was described earlier.

LISP Configuration

router lisp locator-set LUCENA IPv4-interface FastEthernet0/0 priority 1 weight 100 exit ! eid-table default instance-id 0 database-mapping 2610:D0:1139::/64 locator-set LUCENA database-mapping 2610:D0:1139:A::/64 locator-set LUCENA loc-reach-algorithm rloc-probing exit ! ipv6 use-petr 69.31.31.98 ipv6 use-petr 129.250.1.63 no ipv6 map-cache-persistent ipv6 itr map-resolver 173.36.254.164 ipv6 itr map-resolver 206.223.132.89 ipv6 itr ipv6 etr map-server 173.36.254.164 key LISP_KEY ipv6 etr map-server 206.223.132.89 key LISP_KEY ipv6 etr exit ! interface Loopback1 ipv6 address 2610:D0:1139:0::1:161/128

LISP Control-Plane Verification

Verification of the LISP control and data planes of the current configuration are depicted below. The “lig” utility is used to verify that a map entry exists for the IPv6 EID prefixes in the mapping system.

LUCENA-1841#lig self ipv6 Mapping information for EID 2610:D0:1139:: from 24.51.218.201 with RTT 452 msecs 2610:D0:1139::/64, uptime: 00:00:00, expires: 1d00h, via map-reply, self, complete Locator Uptime State Pri/Wgt 24.51.218.201 00:00:00 up, self 1/100

Successful “lig self” verifies that the mapping system has entries for the prefix. The LISP data-plane can be verified by pinging 2610:D0:110C:1::3, the IPv6 address of lisp.cisco.com, sourced from the loopback 1 interface which is configured with an address from the :0::/64 EID block.

LISP Data-Plane Verification

LUCENA-1841#ping 2610:D0:110C:1::3 source loopback 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2610:D0:110C:1::3, timeout is 2 seconds: Packet sent with a source address of 2610:D0:1139:0::1:161 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 96/104/112 ms

Perfect, the data-plane works. To recap, these were the steps taken for this ICMPv6 flow to work.

LUCENA-1841 pinged a IPv6 address sourced from an EID prefix. This triggered the LISP process to request from the mapping system the RLOCs associated with 2610:D0:110C:1::3. Regardless of whether this address belongs to another LISP site or not, the mapping system engages and responds. This IPv6 prefix is part of another LISP site, so a map reply is received giving the details on how to reach the associated RLOCs. One packet was lost during the time it took for the mapping system to reply.

Based on the reply, the LISP router encapsulates the ICMPv6 packet inside of a IPv4 IP and UDP header, followed by the LISP header, and forwards it towards the IPv4 RLOCs extracted from the map reply.

When the other LISP site receives the LISP encapsulated packets, it strips the header and forwards the native IPv6 packets towards its destination (2610:D0:110C:1::3).

The ICMPv6 reply messages follow the same procedure in the reverse direction.

Looking at the IPv6 LISP map-cache, the RLOCs that were just used for forwarding can be observed:

LUCENA-1841#show ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:00:05, expires: never, via static send map-request Negative cache entry, action: send-map-request 2610:D0:110C::/48, uptime: 00:00:03, expires: 23:59:56, via map-reply, complete Locator Uptime State Pri/Wgt 128.107.81.169 00:00:03 up 1/50 128.107.81.170 00:00:03 up 1/50

This demonstrates how LISP encapsulation can be leveraged to reach IPv6 hosts on the internet. The destination was a LISP site, thus the PxTR did not have to be utilized. On the next example, the IPv6 destination will be a non-LISP site, 2607:F8B0:4008:801::1003 (google.com) .

LUCENA-1841#ping 2607:F8B0:4008:801::1003 source loopback 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2607:F8B0:4008:801::1003, timeout is 2 seconds: Packet sent with a source address of 2610:D0:1139:0::1:161 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 160/166/176 ms

LUCENA-1841#show ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:01:35, expires: never, via static send map-request Negative cache entry, action: send-map-request 2606::/15, uptime: 00:01:23, expires: 00:13:36, via map-reply, forward-native Encapsulating to proxy ETR

In this example, 2607:F8B0:4008:801::1003 was pinged sourced from the loopback in the EID space. The LISP mapping system was engaged but this time the reply received from the mapping system is different. The map-reply received instructs the router to forward-native because it did not have a mapping entry for that prefix. In fact, the mapping system calculates the largest address block of non-LISP sites (2606::/15) and instructs with the map reply to forward natively to all destinations covered by this prefix. Since LUCENA-1841 is configured to use a PETR, it will LISP encapsulate towards the proxy instead of forwarding natively. In this case, the router cannot forward native IPv6 packets (with the exception of the local EID prefixes) because it does not have native IPv6 connections to the internet.

Receiving LISP encapsulated packets at the PETR

Once the LISP encapsulated packets are received by the PETR, they are decapsulated and forwarded natively. The PETR has native IPv4 and IPv6 connectivity.

When the native IPv6 packets are received at 2607:F8B0:4008:801::1003 (google.com), ICMPv6 replies are sent back to LUCENA-1841’s loopback address (EID space).

The PxTR “attracts” the returning traffic destined to this EID space by means of its coarse aggregate advertisement into BGP.

The traffic is received by the PxTR and is then LISP encapsulated towards LUCENA-1841. To be technically correct, a PxTR’s function to receive native packets destined towards a LISP site is called Proxy Ingress Tunnel Router (PITR), and it’s function to receive LISP packets from LISP sites to be forwarded to non-LISP sites is called Proxy Egress Tunnel Router (PETR). However, both functions of Ingress and Egress are collectively called PxTR.

Addressing hosts inside of the LAN using SLAAC

After configuring and verifying the tunneling of IPv6 inside of IPv4 by means of LISP, the attention will be turned to end host addressing and configuration. RFC 4862 has been widely implemented as a way to address and configure end hosts without the use of DHCP. Moreover, DNS, a key configuration factor of end hosts on the enterprise or home, has been left out SLAAC. There are several options for assigning DNS settings on end hosts using IPv6. Setting the “other-config-flag” in the router’s RA (Router Advertisement) messages will be the option used in this example. The end result is that the end hosts will use SLAAC to configure their EID space addresses and corresponding default gateway, but will use DHCPv6 for obtaining a DNS server.

SLAAC and DHCPv6 configuration on LUCENA-1841

ipv6 dhcp pool DNS_SERVER_POOL dns-server 2001:4860:4860::8888 dns-server 2001:4860:4860::8844 domain-name lucena.local ! ipv6 general-prefix LISP_BETA_LAN 2610:D0:1139:A::/64 ! interface FastEthernet0/1 description LOCAL_LUCENA_LAN speed 100 full-duplex ipv6 address FE80::90 link-local ipv6 address LISP_BETA_LAN ::90/64 ipv6 nd other-config-flag ipv6 dhcp server DNS_SERVER_POOL

From the configuration snippet above, take note of the following key points:

A DHCPv6 pool has been configured on the router with two public IPv6 DNS servers.

This pool has been bound to the FastEthernet0/1 interface which connects to the LAN where the end hosts are.

The second /64 subnet, 2610:D0:1139:A::/64, from the /48 EID is configured on the FastEthernet0/1 interface.

The interface has the “other-config-flag” set which will hint the recipients of the RA messages to use DHCPv6 for configuration options (such as DNS servers).

A packet capture performed on a host connected to this LAN confirms that the router is setting the “other-config-flag” in its RA messages. Another notable piece of information found in the RA message is the prefix that was configured on the interface, 2610:D0:1139:A::/64. The end host will utilize this message as a catalyst for its autoconfiguration.

Router Advertisement Packet Capture

Windows 7 ipconfig

C:UsersAdmin>ipconfig /all | more Windows IP Configuration Host Name . . . . . . . . . . . . : LUCENA DNS Suffix Search List. . . . . . : lucena.local Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : lucena.local Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller Physical Address. . . . . . . . . : 74-E5-0B-63-81-4C DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2610:d0:1139:a:c016:7f4d:41d9:83a4(Preferred) Temporary IPv6 Address. . . . . . : 2610:d0:1139:a:b41e:d5db:b7ce:8094(Preferred) Link-local IPv6 Address . . . . . : fe80::c016:7f4d:41d9:83a4%13(Preferred) Default Gateway . . . . . . . . . : fe80::90%13 DHCPv6 IAID . . . . . . . . . . . : 326427915 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-5E-86-49-08-2E-5F-80-D8-29 DNS Servers . . . . . . . . . . . : 2001:4860:4860::8888 2001:4860:4860::8844 NetBIOS over Tcpip. . . . . . . . : Enabled Connection-specific DNS Suffix Search List : lucena.local

This is the resulting configuration; an end host fully configured and ready to reach the public IPv6 internet. The following can be observed from this output:

The Windows 7 host properly obtained DNS servers (2001:4860:4860::8888 and 2001:4860:4860::8844) from DHCPv6.

The EID prefix that was advertised by the router in the RA messages was properly interpreted. From this prefix (2610:d0:1139:a), the host generated two separate addresses, a regular address as well as a temporary address.

The default gateway has been properly deduced from the RA messages.

Testing the data plane from the end host

IPV6 internet connectivity will be tested now that the Windows 7 machine is fully configured.

Ping to google.com From Windows 7 Host

C:UsersAdmin>ping google.com Pinging google.com [2607:f8b0:4005:802::1005] with 32 bytes of data: Reply from 2607:f8b0:4005:802::1005: time=208ms Reply from 2607:f8b0:4005:802::1005: time=208ms Reply from 2607:f8b0:4005:802::1005: time=200ms Reply from 2607:f8b0:4005:802::1005: time=202ms Ping statistics for 2607:f8b0:4005:802::1005: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 200ms, Maximum = 208ms, Average = 204ms

Traceroute to google.com From Windows 7 Host

C:UsersAdmin>tracert -d google.com Tracing route to google.com [2607:f8b0:4005:802::1005] over a maximum of 30 hops: 1 3 ms 4 ms 3 ms 2610:d0:1139:a::90 2 44 ms 58 ms 43 ms 2001:590::451f:1f62 3 43 ms 55 ms 46 ms 2001:590::451f:1f61 4 103 ms 101 ms 115 ms 2001:590:2:3::2 5 * 138 ms 149 ms 2001:504:0:2:0:1:5169:1 6 135 ms 130 ms 127 ms 2001:4860::1:0:9ff 7 149 ms 137 ms 137 ms 2001:4860::8:0:3cda 8 150 ms 142 ms 146 ms 2001:4860::8:0:3569 9 141 ms 149 ms 144 ms 2001:4860::8:0:52bb 10 195 ms 195 ms 194 ms 2001:4860::8:0:2995 11 201 ms 219 ms 203 ms 2001:4860::8:0:2cb6 12 206 ms 209 ms 216 ms 2001:4860::1:0:7ea 13 201 ms 202 ms 200 ms 2001:4860:0:1::693 14 205 ms 200 ms 206 ms 2607:f8b0:4005:802::1005 Trace complete.

There is end to end connectivity between the Windows 7 host and google.com over the IPv6 internet, leveraged thanks to LISP.

Checking for IPv6 connectivity using test-ipv6.com yields the following results, notice that IPv4 is completely disabled. Also, a full end to end session has been established using IPv6.

Router’s View of the Data Plane

The Embedded Packet Capture feature was used to get a glimpse of the CEF switched packets flowing through the router. The intercepted packet was from an icmpv6 flow destined to google.com. The following key items are seen on the packet capture:

IPv4 destination is the PETR’s address configured previously.

UDP header is using the lisp-data port 4341.

IPv6 payload is detected after the LISP header.

Securing the newly exposed IPv6 LAN

The hosts connected to the LAN behind LUCNA-1841 are now connected to the IPv6 internet. The issue that arises is security. End hosts are completely exposed to the rest of the IPv6 internet without any security mechanisms. Any IPv6 connected host on the internet can directly communicate with the Windows 7 host. This creates a threat for any enterprise or home. Security can be established effectively using existing tools such as IOS based firewall. Unrequested traffic that has no prior state created on the router/firewall will not be able to pass through and reach the hosts.

Traffic from another IPv6 LISP site on the internet reaching the Windows 7 host

v6ROUTER#ping 2610:d0:1139:a:c016:7f4d:41d9:83a4 source 2610:D0:1139:1::1:165 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2610:D0:1139:A:C016:7F4D:41D9:83A4, timeout is 2 seconds: Packet sent with a source address of 2610:D0:1139:1::1:165 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/32 ms v6ROUTER#traceroute 2610:d0:1139:a:c016:7f4d:41d9:83a4 Tracing the route to 2610:D0:1139:A:C016:7F4D:41D9:83A4 1 2610:D0:1219:64::3 24 msec 32 msec 24 msec 2 2610:D0:1139:A:C016:7F4D:41D9:83A4 28 msec * 28 msec

Cisco Zone Based Firewall will be used in this example to stop unrequested traffic from reaching hosts inside of the LAN.

Zone Based Firewall Configuration for LISP EID

policy-map type inspect IN_TO_OUT_PM class type inspect FTP inspect class type inspect GENERIC_PROTOCOLS inspect class class-default drop ! class-map type inspect match-any GENERIC_PROTOCOLS match protocol tcp match protocol udp match protocol icmp ! class-map type inspect match-all FTP match protocol ftp ! zone security IN description INTERNAL_NETWORK zone security OUT description EXTERNAL_NETWORK zone-pair security IN_TO_OUT_PAIR source IN destination OUT service-policy type inspect IN_TO_OUT_PM ! interface FastEthernet0/1 description LOCAL_LUCENA_LAN zone-member security IN ! interface FastEthernet0/0 description EXTERNAL_NETWORK_ISP zone-member security OUT ! interface LISP0 zone-member security OUT !

This Zone Based Firewall configuration establishes a basic firewall policy that matches on any TCP, UDP, ICMP and FTP flows originating on the LAN and destined to an external address, and creates state on the router that allows returning packets from each flow to reach the originating hosts. A key point to take note of is the zone that the LISP0 interface was placed in. Some interesting zone placement results for the LISP0 interface are listed below:

If the LISP0 interface is placed on the IN zone, no state will be created on the router, but returning traffic will be allowed back into the LAN !

! If the LISP0 interface not placed on any zone, no state will be created, and returning traffic will not be allowed back into the LAN.

If the LISP0 interface is placed on the OUT zone, state will properly be created and expected returning traffic will be allowed back in.

State From IPv6 Flows

LUCENA-1841#show policy-map type inspect zone-pair IN_TO_OUT_PAIR sessions …output cut… Session 68924BC0 [2610:D0:1139:A:C0E0:445:8FE9:2812]:62268=>[2001:4860:4860::8888]:53 udp SIS_OPEN Created 00:00:02, Last heard 00:00:02 Bytes sent (initiator:responder) [28:204] Session 689308C0 [2610:D0:1139:A:C0E0:445:8FE9:2812]:56944=>[2001:4860:4860::8888]:53 udp SIS_OPEN Created 00:00:02, Last heard 00:00:02 Bytes sent (initiator:responder) [28:56] Session 6892B140 [2610:D0:1139:A:C0E0:445:8FE9:2812]:128=>[2607:F8B0:4005:802::1008]:129 icmpv6 SIS_OPEN Created 00:00:02, Last heard 00:00:00 ECHO request Bytes sent (initiator:responder) [96:96]

Traffic from another IPv6 LISP site on the internet failing to reach the Windows 7 host

v6ROUTER#ping 2610:d0:1139:a:c016:7f4d:41d9:83a4 source 2610:D0:1139:1::1:165 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2610:D0:1139:A:C016:7F4D:41D9:83A4, timeout is 2 seconds: Packet sent with a source address of 2610:D0:1139:1::1:165 ….. Success rate is 0 percent (0/5)

Logs from Zone Based Firewall Dropping Traffic

LUCENA-1841# Sep 5 22:14:03.875: %FW-6-DROP_PKT: Dropping icmpv6 session [2610:D0:1139:1::1:165]:0 [2610:D0:1139:A:C016:7F4D:41D9:83A4]:0 due to policy match failure with ip ident 0

Final Thoughts

LISP has been used as means to connect to the v6 internet in these examples. Other tasks such as addressing the hosts and securing the LAN were accomplished by using well known procedures that are currently supported. Having these options allows for testing and exploring live IPv6 connectivity without involving the current ISP. The flexibility that LISP offers makes it a very promising technology yields immediate benefits for those that embrace it.