Setup an IPv6 Tunnel through Hurricane Electric on a Cisco Router

I've setup my home network with an IPv6 tunnel through Hurricane Electric. The process is pretty straight forward and I'll share my learnings with you in this post.

How a Manual IPv6-in-IPv4 Tunnel Works
Using an IPv6-in-IPv4 tunnel through Hurricane Electric is useful when your current ISP doesn't offer native IPv6 service or tunneled 6rd service yet. In this case, you need to tunnel IPv6 traffic across an intermediate IPv4-only network (or the Internet). I setup my tunnel broker account through HE as an initial step in learning IPv6 prior to switching to the IPv6 service offered from my current ISP (CenturyLink). In a future post, I'll describe setting up the CenturyLink 6rd tunneling service, which will be slightly different.

The HE tunnel broker service uses a manually configured IPv6-in-IPv4 tunnel. It's pretty straightforward to understand how this works. You will define an IPv4 tunnel source (your local dual-stack router's WAN interface), an IPv4 tunnel destination (the HE dual-stack router), and a default route on your local router that directs all IPv6 traffic across the tunnel. All IPv6 traffic will be encapsulated inside an IPv4 packet and sent across the IPv4-only network. When the frame reaches the tunnel destination router the outer IPv4 header is stripped off and the IPv6 packet is forwarded to it's destination.

Manual IPv6-in-IPv4 Tunnel

There are a few things you'll need before you get started:

• A static IPv4 address from your ISP - preferred for a manual IPv6-in-IPv4 tunnel so the tunnel destination router can encapsulate return traffic back to your local router. You can use a dynamic IPv4 address, but it requires updating the tunnel definition every time it changes (see this FAQ).
  
• A dual-stack capable router - in my case, I'm using a Cisco router. 

Setting Up the Tunnel Broker Service
There are a few steps involved in setting up the tunnel broker service.

1. Create an account at http://tunnelbroker.net
   Enter a username and password in the login box and click the "Register" button. Fill in your information to complete the process.
   
   
2. Create a new tunnel
   Click the "Create Regular Tunnel" link in the User Functions section. You'll need to enter the IPv4 address of your local router's WAN interface, which must be a publicly routable Internet address (not a private RFC 1918 address). Then select a tunnel server from the list below. This will be the tunnel destination router that Hurricane Electric provides to terminate your tunnel service. I recommend selecting the closest server to your location for lowest latency performance. Click the "Create Tunnel" button on the bottom of the form.
   
   

   

   Hurricane Electric Regular Tunnel Creation

3. View your tunnel details
   You will need to take note of a few items that will be used when configuring your local router:
   - Server IPv4 Address - will be used as the IPv4 tunnel destination.
   - Server IPv6 Address - for reference only as the IPv6 tunnel endpoint.
   - Client IPv4 Address - will be used on your local router's WAN interface as the tunnel source.
   - Client IPv6 Address - will be used on your local router's tunnel interface to establish a neighbor relationship with the server's IPv6 address on the other end of the tunnel.
   - Routed /64 - this is the /64 network prefix that you can use internally on your local network for IPv6 capable hosts.
   - Available DNS Resolvers - you can use these ISP provided IPv6 DNS capable servers to lookup IPv6 resources on the Internet (such as web servers, mail servers, etc.). Or you could alternatively use any public IPv6 DNS servers (such as OpenDNS or Google).
   
   

   

   Hurricane Electric Tunnel Details

4. Optionally - assign a /48 prefix to your local network
   If you need more than one IPv6 routed prefix on your local network, Hurricane Electric can assign you an entire /48 prefix, which will be routed across the tunnel. You can then break into smaller network prefixes for use on multiple links in your local network. To assign a /48 prefix, click the "Assign /48" link.

Setting Up Your Cisco Router for IPv6
Next, we'll need to configure your local Cisco router.

First, enable IPv6 routing and Cisco Express Forwarding (CEF):

ipv6 unicast-routing
ipv6 cef

Second, you'll want to create a tunnel interface for the link to the Hurricane Electric tunnel broker service.

interface Tunnel0
 description Hurricane Electric IPv6 Tunnel Broker

 # No IPv4 address will be on the tunnel interface
 no ip address

 # Enable IPv6 on the interface
 ipv6 enable

 # Assign a Global Unicast Address to the Tunnel interface.
 # Use the Client IPv6 Address assigned to you by Hurricane
 # Electric. This will allow your router to establish a neighbor
 # relationship with the other tunnel endpoint router,
 # referenced as Server IPv6 Address.
 ipv6 address 2001:470:XXXX:XXXX::2/64

 # Set an IPv6 MTU that adjusts for the 20-byte IPv4
 # encapsulation caused by the tunnel. This prevents
 # dropping packets and sending back an ICMP 
 # Packet-too-Big error. I have a PPPoE link and reduce
 # the MTU another 8-bytes. 1500-20(IPv4)-8(PPPoE) = 1472.
 ipv6 mtu 1472

 # You may want to secure your local network using an
 # IPv6 ACL and traffic inspection. I'll cover these in 
 # a subsequent post.
 ipv6 inspect v6firewall in
 ipv6 inspect v6firewall out
 ipv6 traffic-filter v6Outside_ACL in

 # Configure the tunnel mode as a manual IPv6-in-IPv4 tunnel.
 tunnel mode ipv6ip

 # Configure the tunnel source and destination IPv4 endpoints.
 # The tunnel source is the IPv4 address on your local router's
 # WAN interface. The tunnel destination is Server IPv4 Address
 # provided by Hurricane Electric.
 tunnel source 63.224.XXX.XXX
 tunnel destination 184.105.253.14

Next, install a default route for all IPv6 traffic originating from your local network to traverse the tunnel.

ipv6 route ::/0 Tunnel0

Configure a stateless DHCPv6 server to assign IPv6 DNS servers and a domain suffix to clients so they can resolve hostnames to IP addresses. A stateless DHCPv6 server does not hand out IPv6 addresses to clients or maintain a binding database. In my setup, I'll be using SLAAC to allow clients to autoconfigure addresses on the local link based on the prefix(es) advertised by the router in ICMP Router Advertisements. You can use the ISP provided DNS servers or any public server as mentioned previously.

ipv6 dhcp pool DHCPv6
 dns-server 2001:470:20::2
 domain-name yourdomain.com

Configure a local LAN interface with the routed IPv6 network assigned to you by Hurricane Electric. This may be the /64 prefix originally assigned to your network or a smaller portion of a /48 if you requested one (break the /48 into smaller /64 prefixes for multiple internal network links). This interface is typically a dual-stack interface, meaning it will support both IPv4 and IPv6 clients. This is important to allow clients to continue to use IPv4 to access services which are not yet available over IPv6.

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in

 # Enable IPv6 on the interface
 ipv6 enable

 # Configure the assigned /64 prefix from Hurricane Electric
 # on the local LAN interface.
 ipv6 address 2001:470:XXXX:XXXX::1/64

 # Advertise a smaller IPv6 MTU than the default 1500 bytes
 # in order to account for tunnel overhead. The minimum IPv6
 # MTU is 1280 bytes and is a safe bet. This prevents dropping
 # packets due to IPv6 tunneling mechanisms.
 ipv6 mtu 1280

 # Advertise the ability for clients to configure other
 # parameters such as DNS by setting the other-config-flag
 # in Router Advertisements.
 ipv6 nd other-config-flag

 # Assign the previously defined DHCPv6 server to this interface.
 ipv6 dhcp server DHCPv6

The configuration of the IPv6 MTU on the local LAN interface is important because Path MTU discovery often does not work across the Internet when stateful security devices block ICMP Packet-too-Big error messages. Even if your tunnel supports a higher MTU than the minimum 1280 bytes, such as 1472 bytes, you may run into situations where some IPv6 Internet resources still require a smaller MTU because tunneling occurs elsewhere along the route.

Testing It All Out
Once you've got your tunnel established and local LAN configured, let's test it out.

Ping from your WAN interface across the tunnel. This will verify IPv6 reachability across the tunnel between the two tunnel endpoints.

cisco-router#ping 2001:470:XXXX:XXXX::1   
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:470:XXXX:XXXX::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms

Connect a client to your local LAN. This will verify that a client is properly receiving an IPv6 address from your router. Here is an example using an Apple MacBook Pro connected to an IPv6 network over Wi-Fi:

Apple MacBook Pro IPv6 Network Connection

You will notice that the Cisco router sends Router Advertisements (RA) using it's link-local address in the fe80::/16 address block. Embedded in the RA is information about the network prefixes configured for the link, whether or not clients should use auto-configuration (SLAAC) to obtain an address, and the other-config-flag related to stateless DHCPv6 for DNS and domain suffix assignment. Most modern clients will auto-configure two global IPv6 addresses: one using the EUI-64 format based on the Ethernet MAC address on their interface, and one using the auto-generated random method for security and privacy. Hosts will typically prefer the random address when initiating sessions with other hosts.

vonNagyMBP13:~ andrewvonnagy$ ifconfig en1
en1: flags=8863 mtu 1500
ether 68:xx:xx:xx:1b:f0 
inet6 fe80::6axx:xxff:fexx:1bf0%en1 prefixlen 64 scopeid 0x5 
inet6 2001:470:XXXX:XXXX:6axx:xxff:fexx:1bf0 prefixlen 64 autoconf 
inet6 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 prefixlen 64 autoconf temporary 
inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active

You can also check the DNS settings on the host to ensure stateless DHCPv6 worked properly.

Apple MacBook Pro IPv6 DNS Server(s) and Domain Suffix

Next, ping the remote tunnel endpoint from the local LAN host across the tunnel. This will verify the routing for your assigned network prefix is working properly across the tunnel. Tip: be sure to use the correct ping6 command on Mac OS X!

vonNagyMBP13:~ andrewvonnagy$ ping6 2001:470:XXXX:XXXX::1
PING6(56=40+8+8 bytes) 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 --> 2001:470:XXXX:XXXX::1
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=0 hlim=63 time=35.977 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=1 hlim=63 time=33.656 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=2 hlim=63 time=32.902 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=3 hlim=63 time=35.838 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=4 hlim=63 time=35.926 ms
^C
--- 2001:470:1F10:36::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.902/34.860/35.977/1.313 ms

You might want to try resolving a AAAA DNS record:

vonNagyMBP13:~ andrewvonnagy$ dig @2001:470:20::2 www.google.com AAAA

; <<>> DiG 9.8.1-P1 <<>> @2001:470:20::2 www.google.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 14297="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN AAAA

;; ANSWER SECTION:
www.google.com. 52 IN AAAA 2607:f8b0:4009:802::1010

;; Query time: 38 msec
;; SERVER: 2001:470:20::2#53(2001:470:20::2)
;; WHEN: Tue Aug 13 15:24:33 2013
;; MSG SIZE  rcvd: 60

Finally, try hitting an IPv6 test website. A good one for North America is the North American IPv6 Task Force website. Look for the image of a turtle in the right sidebar along with detection of the IPv6 address being used by your host. You can also try hitting the Google IPv6 test webpage or http://test-ipv6.com/.


Cheers,
Andrew



Additional IPv6 posts you might be interested in:

• IPv6 Refresher: The Need for IPv6 and Address Format
• IPv6 Refresher: Unicast Addressing
• IPv6 Unicast Address Allocation

IPv6 Unicast Address Allocation

Continuing in Chapter 2 of “Deploying IPv6 Networks” (Cisco Press, 2005)

In my last post, I provided an overview of IPv6 unicast addressing, which includes link-local addresses (LLAs), unique-local addresses (ULAs), and global unique addresses (GUAs). As previously described, GUAs must be globally unique and globally routable. GUA addresses are identified with the 3 high-order bits set to ‘001’ (2000::/3) with addresses ranging from 2000::/4 to 3000::/4.

In this post, we will dive a bit deeper on GUAs address allocation policies. Strong IPv6 address allocation and prefix aggregation policies must be implemented and enforced to prevent impact to routing process through longer lookups (remember that modern 64-bit processors require 4 cycles to process IPv6 SA and DA addresses, compared to 1 cycle for IPv4 addresses), reduce global routing table size (which is already becoming a problem with IPv4), and larger routing updates between peers because many more networks are possible with the increased addressing space.

Therefore, strong IPv6 allocation and prefix aggregation policies are meant to provide efficiencies by reducing the global routing table size and keeping routing updates to a manageable size. Cost of routing hardware also likely plays a large part in this equation, since routers with enough horsepower and memory to handle IPv6 routing updates and lookups without strong aggregation policies would come at such a huge cost that it would prohibit IPv6 adoption.

The IANA is responsible for managing and allocating the global IPv6 address space. Address allocation is strictly hierarchical from the IANA to Regional Internet Registries (RIRs), and subsequently to National Internet Registries (NIRs), Internet Service Providers (ISPs) or Local Internet Registries (LIRs), and finally individual organizations. At each step in allocation the larger address space is assigned in subsequently smaller pieces to customers. This allows hierarchical routing and prefix aggregation, which significantly reduces the size of the global routing table.

IPv6 Prefix Allocation Process

In Figure 1, you can see an example of this allocation process for the 2001::/3 prefix. The IANA allocates pieces of this prefix to RIRs and NIRs anywhere in size from /3 to /32 (however, it is typically /16 to /22 in size). These blocks are then subdivided and allocated to ISP and LIR customers, ranging in size from /32 to /35. Finally, individual organizations are allocated one or more /48 prefixes. This leaves 16-bits for use within the organization for internal subnetting and network design.

Using this allocation policy provides prefix aggregation capability at each organizational boundary (Organization, ISP, LIR, NIR, RIR, IANA). ISPs and LIRs must also allocate addresses to customers in a manner that prevents segmentation and allows for optimal use of aggregation (using the Host Density ratio defined in RFC 3194).

A complete list of IPv6 allocations by the IANA is available at the following link:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml

Such strict allocation and aggregation practices don’t come without detractions, however. Individual organizations no longer own their own address space directly from the RIRs (as they do with IPv4 prefixes today). Instead, IPv6 prefixes are acquired from specific ISPs or LIRs and represent a subset of their larger address allocation. Therefore, organizations will need to renumber their entire network when switching between ISPs. IPv6 does include features that make renumbering easier, but this results in an operational impact to organizations.

Renumbering can be made simpler by assigning multiple unique unicast addresses to each host interface during the transition period between ISPs, where both address spaces coexist within the organization. Additionally, the use of unique-local addressing (ULAs) within the organization can ensure internal communication is not disrupted during an ISP transition. However, IPv6 renumbering is still a major concern for medium-to-large size organizations.

Cheers,

Andrew

P.S. – Please follow or get involved in the discussion on IPv6 architecture, design, and implementation on Twitter with the #IPv6Mission hashtag.

IPv6 Refresher: Unicast Addressing

Continuing in Chapter 2 of “Deploying IPv6 Networks” (Cisco Press, 2005)

IPv6 provides hierarchical network segmentation and aggregation through variable length subnet masking (VLSM), which breaks the address into a network portion and a host portion. The network prefix identifies the number of bits in the network portion of the address, similar to CIDR notation (e.g. /24). VLSM is the same as what was eventually adopted with IPv4 after classful boundaries proved to be a bad design decision.

IPv6 prefers to reference interfaces on a host rather than the host itself, since a single device may have multiple interfaces with different addresses. Therefore, technically the host portion of the address is referred to as an “interface identifier” instead. Interface identifiers must be 64-bits in length, according to RFC 3513. I believe this is why most IPv6 best practice recommendations use a minimum subnet size of /64. However, I’ve heard that this may have changed since this book was written… but for now, let’s continue on.

The 64-bit interface identifier can be generated in three different ways (each of which underscores the desire to maintain a globally-unique address):

• Modified EUI-64 format, which builds an IP address based on the layer 2 address of the interface (Ethernet MAC address).
• Auto-generated random address (RFC 3041) to increase privacy and security
• Acquisition via a DHCPv6 server
• Manual configuration
• Cryptographically generated addresses (CGAs) based on RFC 3972 through a hash function with a private key. This provides added security and address authentication, particularly useful for the Neighbor Discovery process.

The network portion of the address also reflects the scope of a network domain. Three address scopes exist:

1. Link-Local Scope – identifies all hosts within a layer 2 domain (e.g. the local subnet). These are referred to as Link-Local Addresses (LLAs).
2. Unique-Local Scope – identifies all devices within an administrative domain, either physical or logical (e.g. all devices within an enterprise network). These are called Unique-Local Addresses (ULAs).
3. Global Scope – identifies all devices reachable across the Internet. These are called Global Unicast Addresses (GUAs).

The scopes are hierarchical, such that the link-local scope resides within a unique-local scope, which resides within the global scope. The unique-local scope was requested by organizations that wanted to continue the practice of having a “site-scope” and using private addressing only relevant within a local site, similar to IPv4 private addressing. However, the IETF working group felt it important to maintain globally unique addressing.

Individual hosts may or may not be aware of the address scope, but routers must be aware of scope information carried within the address for network segmentation and traffic forwarding. Since hosts typically communicate with multiple other hosts in different scopes, each host interface will typically have an address for each scope.

Personally, at this stage of my learning I find the concept of scopes completely logical, but the need for a host interface to have multiple addresses completely illogical and unnecessary. If a host interface has a globally unique address, why should it require a different address when it communicates with a host interface in another scope? Are network routing mechanisms and security controls sufficient to handle the interaction between host interfaces? Let’s table this question for later review and press on…

Link-Local Addresses (LLAs)

Each IPv6 interface is provided with a layer 3 IP address that allows it to communicate exclusively with other hosts on the same link (subnet). Packets with LLAs as either the SA or DA should never be routed off the local link. These addresses are used for discovering neighbors or routers, and for on-link communications.

LLA addresses have a fixed network prefix of FE80::/10, where the first 10 bits are 1111 1110 10, and the next 54 bits are all 0’s. This leave only the last 64 bits for the unique interface identifier, or host portion of the address, to be assigned. Therefore, the link-local network prefix of every subnet overlaps with every other link-local network prefix on other subnets. There is no hierarchy to LLAs; they are flat in nature. This also means that LLAs are constant since they are not meaningful outside of the local link, and are not affected by network re-numbering. For this reason, LLAs are typically used for Neighbor Discovery advertisement by routers, and by various protocols for next hop identification (e.g. BGP).

That also answers my question from three paragraphs back, since LLAs are not routable, although they may be globally unique if the interface identifier is chosen using the Modified EUI-64 format.

Figure 1 - Link Local Address Structure

Unique Local Addresses (ULAs)

The ULAs replaced the earlier attempt for an IPv6 site-local scope which was ambiguous and potentially allowed non-unique addressing. Because non-unique addressing such as private addresses in IPv4 introduce issues with applications (e.g. embedding IP addresses in data payloads) and routing (e.g. interconnecting discontiguous portions of a single site across intermediate networks), ULAs were created which maintain the globally unique structure of the Internet with IPv6.

ULA addresses have a fixed network prefix of FC00::/7, where the first 7 bits are 1111 110L, where ‘L’ identifies the assignment policy. Currently only a value of ‘1’ is specified designating a local assignment (FD00::/8).

Figure 2 - Unique Local Address Structure

The next 40 bits represent the Global ID that ensures global uniqueness of the address, which is pseudo-randomly generated but does not need to be sequential or follow any hierarchy since it will not be aggregated for routing globally. Hence, every “site” will have a unique Global ID. The 16 bit Subnet ID provides the local network administrator with for hierarchical addressing within the site. And the final 64 bits are the interface identifier as previously discussed.

Traffic that uses ULAs as either SA or DA in packets should not be allowed to leave the local site. ULAs prevent address collisions when interconnecting different “sites,” and make discontiguous site topologies easier to manage. For instance, this prevents issues such as the need to perform address translation when interconnecting IPv4 subnets with overlapping private IP addressing. Hooray! This definitely helps clarify the need for address scopes (from my earlier question), but I’m still questioning why GUAs can’t simply be used as both ULAs and GLAs.

Global Unicast Addresses (GUAs)

GUAs provide addressing that can be used to interconnect hosts across the IPv6 Internet. They are globally unique and globally routable. Since IPv6 addresses are 128 bits in length, they provide a much larger quantity of available addressing space than IPv4.

GUA addresses have a fixed network prefix of 2000::/3, where the first 3 bits are 001.

Figure 3 - Global Unicast Address Structure

The remaining address is broken down into the following structure:

• Global Routing Prefix – delegated hierarchically down from the IANA to Regional Internet Registries (RIRs) and subsequently to Internet Service Providers (ISPs) and individual Organizations. The global routing prefix uniquely identifies the RIR, ISP, and Organization to which it assigned, and is typically /48 or smaller.
  
• Subnet Identifier – used internally to identify the network structure within the organization. The subnet identifier is typically 16 bits or larger, depending the global prefix assigned to the organization. The minimum 16 bits provides equivalent internal addressing space as the previous 10.0.0.0/8 private addressing commonly used by organizations with IPv4.
  
•  Interface Identifier – the individual host interface identifier portion, as previously discussed.

A lot of effort has been put into developing this simple yet flexible structure for GUAs to provide easy aggregation when coupled with rigorous prefix-allocation policies by the IANA and RIRs, which will be discussed in the next post.

Unicast Addressing Summary

• LLAs – FE80::/10
• ULAs – FC00::/7 (with range FC00::/8 through FD00::/8)
• GUAs – 2000::/3 (with range 2000::/4 through 3000::/4)

Cheers,

Andrew

P.S. – Please follow or get involved in the discussion on IPv6 architecture, design, and implementation on Twitter with the #IPv6Mission hashtag.