IPv6 Internet Security for Your Network

This chapter covers how to secure your network when it is connected to the IPv6 Internet.

This chapter covers the following subjects:

• Large-Scale Internet Threats: Reviews IPv6 worms, DDoS attacks, and botnets
• Ingress/Egress Filtering: Describes filtering at network perimeters to prevent spoofed packets
• Securing BGP Sessions: Describes securing the Internet routing protocol
• IPv6 over MPLS Security: Explains security in IPv6 service provider networks
• Customer Premises Equipment: Describes security of IPv6-capable end-user devices
• Prefix Delegation Threats: Describes issues related to providing IPv6 addresses to service provider customers
• Multihoming Issues: Explains connecting to multiple service providers

Many people are surprised to learn that IPv6 is already running on the Internet. The Internet can run both IPv4 and IPv6 simultaneously because the protocols are independent of each other. Those who do not have IPv6 connectivity cannot access IPv6 services provided over the Internet.

There are many large-scale threats on the current IPv4 Internet, and IPv6 will be evaluated to improve this situation. These threats have the potential to deny service to critical services and spread malware. IPv6 can reduce many of the attacks that are so prevalent on the IPv4 Internet. Attackers can forge packets, so filtering based on IP address is a requirement. One of the key security measures when connecting to the Internet is to perform ingress and egress filtering of IPv6 packets. Because the IPv6 addresses are quite different than IPv4 addresses, filtering IPv6 addresses is also unique.

Security within a service provider's environment is also a focus area. How a service provider secures its network directly impacts the security of the Internet at large. Service providers use Border Gateway Protocol (BGP) extensively, so the secure use of this routing protocol is a fundamental practice. Service providers make use of Multiprotocol Label Switching (MPLS) in their core networks. This chapter covers the security of this protocol with respect to IPv6.

Service providers must connect millions of customers and their customer premises equipment (CPE) to the Internet. This must be done securely to provide worry-free Internet access to the general public. Because IPv6 addresses are assigned hierarchically, the assignment of addresses to customers must also be done safely.

Many enterprise customers want to be connected to multiple service providers for added assurance that their networks will remain operational if a single service provider's network has problems. However, this provides challenges for IPv6, so there are some emerging solutions to this conundrum.

This book starts out covering IPv6 security from the outside inward, so it is logical to start by looking at the Internet-facing network components. This chapter covers how to secure your network when it is connected to the IPv6 Internet.

Large-Scale Internet Threats

The Internet is not a safe place anymore. Back in the late 1980s, the cooperative organizations that made up the Internet were primarily universities, research institutions, and military organizations. However, this changed on November 2, 1988, when the Morris Internet worm was unintentionally released. The Morris worm was the first large-scale Internet denial of service (DoS) attack. Until that time, the Internet was a communication tool for sharing information between collaborative and friendly organizations. After that event and as the Internet grew, the Internet started to have a sinister shadow that meant organizations connecting to the Internet needed to protect themselves.

Now that the Internet has evolved to use both IPv4 and IPv6, the threats have also evolved. Packet-flooding attacks are possible using either IP version. Internet worms operate differently in IPv6 networks because of the large address space. Distributed denial of service (DDoS) attacks are still possible on the IPv6 Internet, but there are some new ways to track them. This involves the use of tracing back an attack toward its source to stop the attack or find the identity of the attacker. The following sections cover each of these large-scale Internet threats and discuss prevention methods.

Packet Flooding

IPv4 networks are susceptible to "Smurf" attacks, where a packet is forged from a victim's address and then sent to the subnet broadcast of an IPv4 LAN segment (for example, 192.168.1.255/24). All hosts on that LAN segment receive that packet (icmp-echo with a large payload) and send back an echo reply to the spoofed victim address. This overloads the victim's IP address with lots of traffic and causes a DoS. Many DoS attacks are easy to disable by simply entering no ip directed broadcasts to every Cisco Layer 3 interface within an organization. However, the default router behavior has been changed so now disabling directed broadcast forwarding is the default setting. This mitigation technique is documented in BCP 34/RFC 2504, "User's Security Handbook."

Because IPv6 does not use broadcasts as a form of communication, you might assume that these types of attacks are limited. However, IPv6 relies heavily on multicast, and these multicast addresses might be used for traffic amplification. An attacker on a subnet could try to send traffic to the link-local all nodes multicast address (FF02::1) and the link-local all routers multicast address (FF02::2).

One such example of using multicast to leverage an amplification attack is demonstrated with The Hacker's Choice (THC) IPv6 Attack Toolkit. It contains two utilities named smurf6 and rsmurf6. They operate much the same as the original IPv4 Smurf attacks but instead use multicast to amplify the attack. The smurf6 tool sends locally initiated Internet Control Message Protocol version 6 (ICMPv6) echo request packets toward the multicast address FF02::1, and then the hosts on that LAN that are vulnerable to the attack generate ICMPv6 echo response packets back to the source, which is the unknowing victim. The smurf6 victim can be on the local subnet with the attacker or on a remote subnet.

Example 3-1 shows how smurf6 can be used to affect a computer on the same subnet as the attacker. If the victim is on a different segment, the systems on this segment send the echo replies to the remote victim's system. The first parameter is the local attacker's interface, and the second parameter is the victim's IPv6 address.

Example 3-1. Smurf6 Attack

[root@fez thc-ipv6-0.7]# ./smurf6 eth0 2001:db8:11:0:b0f7:dd82:220:498b
Starting smurf6 attack against 2001:db8:11:0:b0f7:dd82:220:498b (Press Control-C to
 end) ...

[root@fez thc-ipv6-0.7]#

The rsmurf6 tool is coded a little differently. It sends ICMPv6 echo reply packets that are sourced from ff02::1 and destined for remote computers. If the destination computer (victim) is a Linux distribution that can respond to packets sourced from a multicast address, it responds to the source, which causes a traffic flood on the remote LAN. This form of amplification is particularly dangerous because each packet generated by rsmurf6 would translate into numerous packets on the remote LAN. Rsmurf6 is like a reverse smurf6 and only works on incorrectly coded implementations of the IPv6 stack. Therefore, it is not as effective as it once was when more vulnerable operating systems were in existence.

Example 3-2 shows how the rsmurf6 tool can be used. The first part of the example targets a victim's computer on a remote subnet. The second part of the example is destined for the link-local all nodes multicast address FF02::1 and essentially denies service to the entire local LAN that the attacker is connected to. Even the smallest systems can generate 25,000 pps, which is about 25 Mbps of traffic to all hosts.

Example 3-2. Rsmurf6 Attack

[root@fez thc-ipv6-0.7]# ./rsmurf6 -r eth0 2001:db8:12:0:a00:46ff:fe51:9e46
Starting rsmurf6 against 2001:db8:12:0:a00:46ff:fe51:9e46 (Press Control-C to end)
 ...

[root@fez thc-ipv6-0.7]# ./rsmurf6 -r eth0 ff02::1
Starting rsmurf6 against ff02::1 (Press Control-C to end) ...

[root@fez thc-ipv6-0.7]#

It should be mentioned that these rsmurf6 attacks are only effective on computers that have IPv6 stacks that allow them to respond to an ICMPv6 packet that was sourced from a multicast address. Most modern IPv6 implementations are intelligent enough to recognize that this is not a valid condition, and they simply drop the packets. In other words, IPv6 hosts should not be responding to echo request packets destined to a multicast group address.

In Chapter 2, "IPv6 Protocol Security Vulnerabilities," you learned that it is a good practice to limit who can send to multicast groups. Because IPv6 does not have broadcast as a form of communications, multicast is the method for one-to-many communications. For this reason, multicast can be leveraged by attackers for packet amplification attacks. Therefore, the solution is to tightly control who can send to multicast groups and when it is appropriate to respond to a multicast packet. Service providers can also consider rate-limiting user connections and particularly rate-limit IPv6 multicast traffic. Most multicasts should be confined to the LAN, so if an attacker is already on your LAN, you need to use other means to protect against that. Physical security, disabling unused switch ports, enabling Ethernet port security, and using an 802.1X or Network Admission Control (NAC) technology are options to prevent unauthorized access to the internal networks.

DoS attacks can be performed using a feedback loop to consume resources or amplify the packets sent to a victim. In Chapter 2, you saw how RH0 packets could be created with a list of embedded IPv6 addresses. The packet would be forwarded to every system in the list before finally being sent to the destination address. If the embedded IPv6 addresses in an RH0 packet were two systems on the Internet listed numerous times, it could cause a type of feedback loop.

Figure 3-1 shows how this type of ping-pong attack would work. The attacker would first send the crafted packet to a network device on the Internet that is susceptible. That system would forward it onto the next system in the list. The two systems could continue to do so until they ran out of bandwidth or resources. However, sometime soon, this type of attack will have limited success because RFC 5095 has deprecated the use of Type 0 routing headers in IPv6 implementations.

DoS attacks might not just be about flooding traffic. With IPv6, there are going to be a wider variety of nodes attached to the network. IPv6-enabled appliances, mobile devices, sensors, automobiles, and many others can all be networked and addressable. DoS attacks could simply target a specific model of device and render it inoperable. The results could be far more tragic if your IPv6-enabled automobile suddenly stops while on the autobahn. The benefits of using IPv6 are great but so are the consequences if the communication is not secured properly.

Internet Worms

Worms are a type of attack that requires no human interaction. This is different than a virus, which usually requires some form of human interaction to activate. Worms spread by themselves, infect vulnerable computers, and then spread further. Worms perform the entire attack life cycle in one small amount of code. That small amount of code contains the instructions for reconnaissance of new systems, scanning for vulnerabilities, attacking a computer, securing its access, covering its tracks, and spreading further.

Worms can be affected by the introduction of IPv6. This new protocol can affect a worm's ability to spread. It can also affect the techniques that worm developers use to make their code propagate. There are already examples of worms that leverage IPv6. The following sections cover these topics and discuss ways to help prevent worms.

Worm Propagation

Many of the widespread worms in the past eight years have leveraged some vulnerability in software running on a computer. Worms such as Code Red, NIMDA, MS/SQL Slammer, W32/Blaster, W32/Sobig, W32/MyDoom, W32/Bagel, Sasser, and Zotob all took advantage of some Microsoft service vulnerability. Some of them spread over the Internet, and some used email as the medium for reaching other systems. Many worms now spread through email (executable attachments, address books), peer-to-peer, instant message, or file sharing. These types of worm propagation techniques are unaffected by IPv6's introduction.

In the past, worms have used network scanning or random guessing to find other systems to spread to. Worms that spread to random IPv6 addresses cannot spread as fast as in IPv4 networks because IPv6 addresses are sparsely populated while IPv4 addresses are densely populated. Worms have been successful at scanning other IPv4 systems to infect because of the density of the current IPv4 space. Some worms have spread randomly (Code Red, Slammer), while others have spread sequentially (Blaster). It could be postulated that the Sapphire/SQL Slammer worm would not have been as successful on an IPv6 Internet because the size of the IPv6 address space is so large compared to IPv4. The Sapphire/SQL Slammer worm would take many thousands of years to reach its maximum potential on the IPv6 Internet. Given IPv6's immense address space, these types of worms will not be able to guess the addresses of other victims to spread to and infect. Random scanning will not be an option for worms on IPv6 networks. However, if IPv6 addresses are allocated sequentially or are otherwise densely packed, scanning can be just as fast as with IPv4.

Speeding Worm Propagation in IPv6

As worms get smarter, they can overcome many of the issues related to scanning a large IPv6 address space. Worms can increase their scan rate to try to reach more hosts each second. IPv6 worms need to overcome the problems with performing reconnaissance on IPv6 networks. As discussed in Chapter 2, there are many places for a worm to look to help the worm find other hosts to spread to. Worms can also improve their knowledge of the population. This could be done by recognizing only the currently allocated IPv6 address blocks or by seeding their code with several vulnerable systems. Worms could also work to find new targets by looking at other sources of IPv6 addresses.

Worms could consult the infected computer's neighbor cache to find other local systems. The worms would also look anywhere IPv6 addresses are stored to help them identify new targets. Domain Name System (DNS) lookups, local DNS files, /etc/hosts, registries, SSH known_hosts, and other lists of hosts could be consulted. Worms might also listen to the LAN traffic to find other hosts. Sniffing neighbor solicitation packets, Duplicate Address Detection (DAD) packets, and routing updates would help them target specific populations of hosts rather than randomly scanning. Even information about IPv6 addresses stored in logs like syslog, /var/log/messages, and search engine logs would be valuable to a worm.

Worm developers will likely adjust their strategy for IPv6 networks. A worm could infect a single host, and then the worm could use that host's ability to send IPv6 multicast packets within the organization (for example, FF02::1, FF05::1, FF08::1). An example of this can be seen in "Windows Kernel TCP/IP/IGMPv3 and MLDv2 Vulnerability" (MS08-001, CVE-2007-0069), which was discovered early in 2008 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0069). This vulnerability leveraged a bug in the Windows multicast code using malformed Internet Group Management Protocol version 3 (IGMPv3) packets. A worm could leverage this vulnerability to attack nearby IPv6 hosts and spread to those infected computers. Therefore, a method for mitigating worm attacks could leverage the practice of constraining communication with IPv6 multicast addresses.

It is predicted that worms that check for routable address space can spread even faster. A worm could contain all the routable IP prefixes, and that list would help it eliminate "black" unallocated space. A worm could also look at a host's routing table or passively listen for routing updates (FF01::1 all routers multicast group) on a LAN to learn about other local networks to start scanning. For example, scanning could also be accelerated if the worm could perform a MAC address flood (CAM overflow attack) of the local LAN switch and then listen to all the packets.

Dual-stack worms could leverage either IPv4 or IPv6 protocols to spread in even faster ways than previously using only IPv4. However, with the density of the population using IPv4, worms could spread quickly over only IPv4. Some worms can use a dual-stack approach to infect systems rapidly over IPv4. The worms can check whether the system is dual-stacked and then perform a multicast probe. The systems that respond to the link-local multicast (FF02::1) are then attacked using IPv6. This technique could even accelerate worm propagation in the short term. However, eventually as more IPv6-only hosts exist, this technique will lose its effectiveness.

IPv6 worms must have more advanced techniques to overcome the problem of scanning IPv6 addresses to spread. As these worms are made more sophisticated, more code is required, and the size of the worm increases. This makes it more difficult for the worm to spread because the transmission of the worm requires multiple packets and slows the spread.

Current IPv6 Worms

A few worms have already leveraged IPv6, and unfortunately there will be more in the future. The Slapper worm was released in 2002. It targeted Apache web servers on TCP port 80. After the worm attacked an Apache server, it would then create a copy and spread to other Apache web servers by randomly finding IPv4 servers. It had a sophisticated command and control channel that would allow a hacker to create send commands to the infected servers. One command would send a flood of IPv6 packets toward a victim. Slapper was the first worm that had any type of IPv6 component to it.

W32/Sdbot-VJ is a spyware worm that tries to use the popularity of IPv6 to disguise itself. It does not use IPv6 to spread to other machines; however, it installs the program wipv6.exe and installs several registry entries. The user might be hesitant to delete the file because it might have something to do with the Windows IPv6 drivers. Therefore, it was less likely to be deleted from a computer.

Preventing IPv6 Worms

A few techniques can help contain IPv6 worms. You must keep your antivirus and intrusion prevention system (IPS) signatures up to date so that they can identify new threats. Many worms leverage recent vulnerabilities that have been patched by the manufacturer, but not all customers have implemented the patch. Therefore, keeping software patched on computers and servers is a must. You can also use anomaly detection systems to identify an abnormal spike in traffic of any single protocol type. This would be one way to detect a problem, but the quicker you can detect a rapidly spreading worm and respond to block the propagation, the easier your remediation.

Distributed Denial of Service and Botnets

Sophisticated hackers try to strive for elegant attacks that satisfy their need to prove their superiority. However, many times an advanced attack is not possible and an attacker might still want to perform some type of disruption. Oftentimes it is the less-experienced attackers that simply try to negatively impact a site after they fail at a more sophisticated attack. When their attempts are thwarted, they fall back to trying to cause damage by simply breaking the system and taking it offline. This attack performs a DoS and makes the system unable to provide service to the legitimate users. Attacks of this style that involve a large number of geographically disperse computers are called distributed denial of service (DDoS) attacks.

DDoS attacks are performed by a large set of many Internet-connected computers that have been compromised. These large numbers of computers are controlled by other compromised systems called handlers. The hacker that controls all these computers can send commands to their vast army of "zombies" to send traffic to a victim. These zombie computers are typically Internet-user PCs that have been turned into robots (bots for short) through malicious software. When the "bot herder" directs the botnet to send the large volume of traffic toward the victim, it prevents the victim from being able to communicate. Thus the attack denies the victim Internet access or denies the user's access to the victim's website.

DDoS on IPv6 Networks

DDoS attacks can exist on an IPv6 Internet just like they exist on the current IPv4 Internet. Botnets, which are large networks of zombie infected computers, can be created, and their attacks can be focused on a victim. The use of IPv6 will not change the way that botnets are created and operated. DDoS botnets will unfortunately still exist on IPv6 networks. Botnets can also be used to send email spam and conduct other types of mischief. IPv6 will allow the Internet to contain many more devices than the IPv4 Internet. Imagine if many of these devices were to launch a DDoS attack. The results could be more devastating than today's attacks on the IPv4 Internet.

Attack Filtering

Because an IPv6 address is allocated in a fully hierarchical manner, it would be easier to track down where the traffic is coming from and going to than on the IPv4 Internet, where addresses are not hierarchical. Because of fully hierarchical addressing, inbound/outbound source IP address filtering and unicast Reverse Path Forwarding (RFP) checks will be possible. Viruses and worms that spread using spoofed source addresses will be limited in an IPv6 network if Unicast RPF checks are deployed. Ingress and egress filtering will also limit these types of attacks.

Figure 3-2 shows how two Internet service providers (ISP) have assigned address space to two organizations. If one organization connected to ISP1 sends a large volume of traffic to the victim's host, it could be filtered by ISP1. The traffic could be validated to have legitimate source addresses coming from its assigned address space. Packets with spoofed source addresses would not be allowed to leave the organization. Therefore, if the victim saw attack traffic coming from the 2001:db8:1000::/48 address space, it could be traced back to its source. If an attacking host was using privacy addressing for the network ID portion of the address, the attack could only be traced back as far as the organization.

The hope is that if all ISPs and end-user organizations were to implement full ingress and egress address-spoofing filtering, this would help with tracking down the DDoS attacks. The infected computers could then be quickly determined, and the malicious software could be remediated more quickly.

Attacker Traceback

In the unfortunate circumstance where you have fallen victim to a DoS attack, your first instinct is to look upstream for assistance. The goal is to try to identify the source of the traffic that is coming your way and stop it as close to the source as possible. You must coordinate with your ISP to help contain a DoS attack. Your organization should not wait until this happens to work out procedures with your ISP to help you handle this. An organization should know ahead of time the contact information and procedures to follow to perform last-hop traceback.

Traceback in IPv6 networks involves finding the source address of the offending packets and then tracking down the offending host to a subnet. Then, tracking down the IPv6 address and the binding to the Layer 2 address (or asymmetric digital subscriber line [ADSL] port) of the host can be done at that site. Then, one could find out what Ethernet port the user is connected to and then investigate further. This procedure should be documented ahead of time so that it can be used quickly during an attack.

This process is time consuming and takes coordination between your own ISP and many others, and it is not applicable if the attack is a DDoS because there are literally thousands of attack sources. If you are trying to stop an attack by a botnet that could potentially contain thousands of bots, the task is overwhelming. Each of these bots is not sending traffic sourced from its own IP address, so tracing back to this many systems seems futile. The zombie hosts create traffic that looks like normal web traffic, so finding out which connections are legitimate is nearly impossible. The traffic patterns that these botnets create can be observed by using NetFlow to track statistics about each protocol flow. The flow records can be checked for traffic coming to or from an organization or service provider network. The collected NetFlow data can help trace the source of the traffic back to the source organization's network. However, the act of reaching out to that many users to have them remediate their systems is not feasible in most situations.

Your organization probably has a firewall, and you might have an IPS. Those two systems can try to stop the attack by filtering out traffic. However, the web requests will not match any known "signature," but either system can easily be configured to simply drop all traffic. That can stop the attack, but it would also stop all other valid users from reaching your servers. Furthermore, your Internet connection can be so saturated with traffic that blocking at your site has limited value.

If the attack that is hitting your network is a SYN-Flood attack, a solution is available. A SYN-Flood attack is where the packets with spoofed source addresses are sent to the web servers and they have the SYN TCP flag set. The server tries the second part of the three-way TCP handshake by sending back a SYN-ACK TCP flag packet to the spoofed source address. Because that packet never reaches the spoofed source, the three-way handshake never takes place and the web server retains the state of the connection for some time. Meanwhile the web server is hit with many of these false connections, and they drive up its CPU and memory utilization.

A technique that would help in this instance is to leverage an application front-end system or server load-balancing system that can terminate those SYN packets and send back the SYN-ACK on behalf of the server. The SYN cookie technique can also be used to verify the initial sequence number (ISN) of the client connection. If the client sends back the legitimate final ACK to complete the three-way handshake, the connection is legitimate. The server load balancer can then make the connection to the web server on behalf of the client, and the HTTP request can take place normally. False SYN-Flood traffic does not reach the server, but legitimate connections are served.

Black Holes and Dark Nets

During any type of attack or for other reasons an ISP can create a situation where traffic destined for a site can be dropped. The traffic is routed into a black hole, where it is simply discarded. To do this, the service provider creates a route to Null 0 on its routers and redistributes that route to the other peering routers in its infrastructure. The route can be for an entire prefix or for a specific IP address. All the routers with this null route simply drop the packets destined for that prefix. This technique was defined in RFC 3882, "Configuring BGP to Block Denial-of-Service Attacks," and is also known as a Remotely Triggered Black Hole (RTBH). The problem with this technique is that it is crude and can block legitimate traffic as well as the malicious traffic from the attack. However, this same technique can be applied to the IPv6 Internet.

ISPs also can use the RTBH technique to trace the source of the malicious traffic. When the traffic is routed to the black hole, ICMP error messages are created. Monitoring the ICMP error messages gives an indication of where the traffic entered the service provider's network. There are many different versions of this same technique. Different ISPs use different solutions to help them track down where the malicious traffic is entering their network. The goal is to identify where the traffic is coming from and then work back toward the source. This usually involves cooperation with other ISPs.

Another technique for learning about Internet threats involves the creation of a darknet for some portion of public address space. A public prefix is advertised by a service provider to the Internet, but that prefix has no services within it. Instead that network contains a computer that is monitoring all traffic coming into that network. Any packets that are on the service provider's network destined for that address space end up being monitored. Because that prefix has never been used, there is no legitimate reason for any packets to be going to it. Therefore, the only things going to the darknet network are transient packets that can be the results of scanning attacks.

Darknets, or network telescopes as they are also known, help researchers understand hacker behavior. They are similar to a honeynet, but there is no interaction with the hacker. No packets leave the darknet, but anything that enters the darknet is seen by a protocol sniffer. The sniffer can archive the data for future analysis and it can also pick up trends. However, few packets enter an IPv6 darknet, so it can be difficult to interpret results. However, there is a lot of public IPv6 address space available to perform these types of experiments.

Ingress/Egress Filtering

One of the important aspects of perimeter security is filtering at an organization's borders. If you are a service provider, your network borders are customers and other service providers. If you are an enterprise, your network borders are ISPs and other business partner organizations. There are commonalities in the filtering of route advertisements done by service providers and the route filtering done by their customers. One key difference involves the way IPv6 routes are filtered at the Internet's edge. One commonality is the filtering of bogus addresses that should not be used in either the source address or the destination address header field. The following sections describe the different methods of filtering routes and give example of how to filter allocated and bogus IPv6 address prefixes.

Filtering IPv6 Traffic

Service providers typically do not filter individual customer packets traversing their networks based on the packet's contents. However, they should help protect the Internet and their own infrastructure by performing filtering at their perimeters. BCP 84/RFC 3704, "Ingress Filtering for Multihomed Networks," (Best Current Practice [BCP] 84) covers the practice for IPv4 networks. Now these same principles can be extended to IPv6 networks.

Performing IPv6 traffic filtering for high-speed links would require systems that can perform filtering in hardware. Service providers could also filter packets that do not conform to the IPv6 specifications. The points where a service provider network touches customers and other providers are locations where the filtering should occur. This type of filtering is not done by firewalls on the traffic itself but rather on the routing update exchanges.

Filtering on Allocated Addresses

With IPv4, customers can get address allocations from their provider and also obtain their own address space. In IPv6, the intent is to require all customers to get their allocations from their service provider. The service providers receive their addresses from the Regional Internet Registries (RIR), who in turn receive their allocations from the Internet Assigned Numbers Authority (IANA). This creates a fully hierarchical addressing structure that maximizes the use of aggregation and is sure to reduce the size of the Internet routing table. RIRs can also assign provider independent (PI) address blocks to customers. However, these blocks might not be allowed to be routed on the Internet, even if it can be expected that more and more ISPs will have to allow the transit traffic destined to PI addresses.

ISPs need to be careful about the address space that they are using and assigning to customers. Filtering what you are advertising and what you are receiving over peers also helps prevent many types of BGP threats. Receiving more-specific routes, less specific routes, routes for unallocated space, and malicious routes are threats that can all be prevented through careful filtering of routes. Receiving many of these different types of routes can either be accidental or malicious on the customer's part, and you might not know which. Being overly permissive on the types of routes allowed to be advertised to the ISP from customers is not wise. Distribute lists, prefix lists, and route maps can all be used to control what routes are being sent and received.

You might not want to accept more specific routes from customers or peers because that could be one way that an attack takes place. Because the minimum allocation size is a /48, service providers might also want to simply reject any /49 or longer prefix. Therefore, you might not want to accept a BGP advertisement with anything smaller than a /48, regardless of the prefix. BGP also makes the assumption that a peer has the authority to advertise the prefix and autonomous system (AS) paths. If these are falsified, all types of routing instability can occur.

ISPs have the responsibility to perform careful filtering of customer routes. There are many address blocks that a service provider should not receive from a customer or a peer. The ISP must also allow the customer to be able to route its traffic to and from the Internet. These customer routes must be filtered at the point where the two networks meet. It is also a good practice for the service provider to check the regional registry to make sure that the customer is the rightful owner of the prefix. This can be done with whois information from the Shared WHOIS Project (SWIP). For example, if a customer is assigned the address block 2001:db8:100::/48, the inbound prefix list permitting this advertised route would look like the configuration shown in Example 3-3. This example shows a prefix list that would allow only the customer's block and nothing else.

Example 3-3. Filtering Customer Address Assignment

ipv6 prefix-list v6-cust-routes permit 2001:db8:100:100::/48
ipv6 prefix-list v6-cust-routes deny ::/0 le 128
!
route-map CUSTROUTES permit 10
 match ipv6 address prefix-list v6-cust-routes
!
router bgp 100
 neighbor 2001:db8:100:100::1 remote-as 200
 neighbor 2001:db8:100:100::1 route-map CUSTROUTES in

You should disallow overly specific prefixes and disallow any prefix greater than /48. The more-specific /64 route for the customer network is quelled while the aggregate /48 is advertised. Some ISPs can elect to allow more-specific routes from customers, but they should not be smaller than a /48.

Bogon Filtering

Bogons are the IP address ranges that either have not been allocated or are reserved. The word bogon is a derivative of the word bogus, which means illegitimate or fake and is similar to terms for subatomic particles used in quantum mechanics. The bogons list originated from RFC 3330's list of "Special-Use IPv4 Addresses," and now a similar list of "Special-Use IPv6 Addresses" is documented in RFC 5156. Packets with these addresses, either used as source addresses or destination addresses, should not be routed on the Internet. These are often blocked at IPv4 routers explicitly because there are a finite number of these. Lists are maintained that contain the IPv4 address space, and service providers and other organizations use these bogon lists. The bogon lists help to craft filters to prevent these packets from traversing network perimeters.

The list of valid IPv6 address blocks is maintained by the IANA. This list shows the address space allocations and the organizations responsible for maintaining that address space. At the time that this book is written, the current allocations are listed at the following URL:

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

The IANA has also made special registrations of address spaces for specific purposes. This is done because there are times when addresses are required for a specific purpose, but these addresses will not be allocated to an organization. The IANA Special Purpose Address Registry is defined by RFC 4773, "Administration of the IANA Special Purpose IPv6 Address Block," and is available at http://www.iana.org/assignments/iana-ipv6-special-registry.

In general, you should always filter packets coming to you that are sourced from bogon addresses. This is a good goal, but it also means that you need to stay on top of the allocations as they are made and adjust the filter lists accordingly. These bogon lists can change several times each year.

You should also take into consideration the address space that you have been allocated as a service provider. Service providers have out-of-band management networks. Filtering these internal addresses at the borders of the service provider can help prevent attacks against the back-office/internal systems (that is, billing, management, and so on). You should filter the infrastructure addresses that are used by your network equipment and router interfaces. Therefore, you must filter packets coming to you from your own allocated address space. This can be done at your network perimeters with the use of Unicast Reverse Path Forwarding (Unicast RPF) checks. You should also deny your own allocated address space from being advertised to you from a customer or any peer. You know about your addresses, and you should not let anyone tell you any differently. That should protect anyone from trying to destabilize your routing.

Many other prefixes should be denied inbound and outbound at your network perimeters. Table 3-1 gives the list of the routes that should be filtered from entering or leaving your network. These should not be advertised to you from any customer or peer, and you should also prevent yourself from advertising these.

Table 3-1. Prefixes That Should Be Blocked

Routes to Block	Prefixes
Default route	::/0
Unspecified address	::/128
Loopback address	::1/128
IPv4-compatible addresses	::/96
IPv4-mapped addresses	::ffff:0.0.0.0/96
Link-local addresses	fe80::/10 or longer
Site-local addresses (deprecated)	fec0::/10 or longer
Unique-local addresses	fc00::/7 or longer
Multicast addresses	ff00::/8 or longer
Documentation addresses	2001:db8::/32 or longer
6Bone addresses (deprecated)	3ffe::/16

Some of the entries in Table 3-1 can be covered with a single prefix. For example, unspecified routes, loopbacks, and IPv4-mapped addresses can all be matched with 0000::/8 or longer.

Because so little of the IPv6 address space has been allocated, it is easier to permit the legitimate route addresses than to try to deny all the routes that should be blocked. Therefore, route filters have permit statements for the legitimate prefixes, and all other routes are blocked by the implicit deny-all at the end of the list. Therefore, the list of allocated IPv6 addresses can be specified within an IOS prefix list and applied to the external interface of an Internet router. Example 3-4 shows an example of this prefix list and indicates how it can be applied to a BGP peer. This filter list comes from the Team Cymru IPv6 bogon filter list for Cisco IOS routers: http://www.cymru.com/Bogons/v6ios.html.

Example 3-4. Bogon Prefix Filter List

ipv6 prefix-list ipv6-global-route deny   2001:0DB8::/32 le 128
IPv6 prefix-list IPv6-global-route deny   <your own allocated addresses>/32
ipv6 prefix-list ipv6-global-route permit 2001:0000::/32
ipv6 prefix-list ipv6-global-route permit 2001:0200::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0400::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0600::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0800::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0A00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0C00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:0E00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1200::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1400::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1600::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1800::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1A00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:1C00::/22 ge 22 le 64
ipv6 prefix-list ipv6-global-route permit 2001:2000::/20 ge 20 le 64
ipv6 prefix-list ipv6-global-route permit 2001:3000::/21 ge 21 le 64
ipv6 prefix-list ipv6-global-route permit 2001:3800::/22 ge 22 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4000::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4200::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4400::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4600::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4800::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4A00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:4C00::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2001:5000::/20 ge 20 le 64
ipv6 prefix-list ipv6-global-route permit 2001:8000::/19 ge 19 le 64
ipv6 prefix-list ipv6-global-route permit 2001:A000::/20 ge 20 le 64
ipv6 prefix-list ipv6-global-route permit 2001:B000::/20 ge 20 le 64
ipv6 prefix-list ipv6-global-route permit 2002:0000::/16 ge 16 le 64
ipv6 prefix-list ipv6-global-route permit 2003:0000::/18 ge 18 le 64
ipv6 prefix-list ipv6-global-route permit 2400:0000::/12 ge 12 le 64
ipv6 prefix-list ipv6-global-route permit 2600:0000::/12 ge 12 le 64
ipv6 prefix-list ipv6-global-route permit 2610:0000::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2620:0000::/23 ge 23 le 64
ipv6 prefix-list ipv6-global-route permit 2800:0000::/12 ge 12 le 64
ipv6 prefix-list ipv6-global-route permit 2A00:0000::/12 ge 12 le 64
ipv6 prefix-list ipv6-global-route permit 2C00:0000::/12 ge 12 le 64
!
router bgp 64500
 neighbor 2001:db8:1::2 route-map ACCEPT-ROUTES in
!
route-map ACCEPT-ROUTES permit 10
 match ip address prefix-list ipv6-global-route

Bogon Filtering Challenges and Automation

Filtering what prefixes are advertised by an end-user organization is a best practice. It is also a best practice to filter prefixes from a service provider's other service provider peers. Most peers just permit the /32s that other peers have been allocated. Many service providers trust the peers they connect to and do not perform the necessary filtering to protect the Internet from dramatic problems. These service providers know that filtering bogons from being advertised to them is the right thing to do. However, many service providers cite the fact that bogon filtering can be hard to maintain because it is likely to change. Some service providers manually configure bogon filters, but the updating of the configurations can be automated with some form of script. In fact, when new address space is allocated by the IANA or the registries, the address space is usually given to Tier 1 ISPs because they will start to route the traffic appropriately for their customers.

There are techniques that service providers can use to help alleviate the burden of maintaining peer filters. It is easy to set up an automated method of updating the bogon list on all peering routers. After the filter is updated, you do not need to reset the peer to have the filter activate. When the peers are reset softly or the route flaps, the updates show up in the routing table.

Another technique for filtering routes to a peer is to leverage an Internet Routing Registry (IRR). These databases contain the registered address allocations for other ISPs, and they can help you create the prefix list applied to that peer. Routing Policy Specification Language (RPSL) is defined in RFC 2622 as a language to send and receive information from a registry. Recently, RPSLng (RFC 4012) added IPv6 and multicast support to its set of classes of objects. For example, one of the RPSL classes is called the ROUTE6 object, which contains the identification of the /32 addresses that service providers have been allocated. With objects like this, an IRR can be used to create a specific import or export route filter for the prefixes that should be sent or received from a peer. This would add to the security of IPv6 because filters could be automated and based on accurate sources of allocated and assigned prefixes. For these reasons, the IRRs must be secured, and the validity of the data must be regularly checked.

The historical challenges with IRRs were that the information was not accurate. Because the IPv6 Internet is in its early stages and the current Internet IPv6 routing table has few entries, the data will be easy to validate. Currently the set of IPv6 information in the IRRs would be small and easy to start a clean slate and maintain it. IRRs can help avoid mistakes made by humans and speed deployment through automation. Automation tools exist for IRRs (IRRToolSet, IRR Power Tools) to help create filters for peers and customer connections.

Securing BGP Sessions

The Border Gateway Protocol version 4 (BGP4) protocol has been in existence since 1994 and has been updated several times over the past 15 years. BGP4, defined in RFC 4271, is the routing protocol used between autonomous systems that make up the Internet. External BGP (EBGP) is used between autonomous systems, and Internal BGP (IBGP) is used within an autonomous system. BGP is a path-vector routing protocol, where the paths are the list of autonomous systems that must be traversed to reach the destination prefix. Through the years, BGP has been extended to carry different types of routing information. RFC 4760, "Multiprotocol Extensions for BGP-4," allows BGP to operate over IPv4 or IPv6 and carry either type of routing information.

BGP is the central nervous system with which virtually all service providers are wired. Because BGP is the critical routing protocol of the Internet, it is a target of attacks. Attackers know that if they can find a weakness in BGP and exploit it, they could potentially destabilize the entire Internet. RFC 4272, "BGP Security Vulnerabilities Analysis," showed the weaknesses in BGP that service providers should try to prevent. Therefore, it is important that you work to secure BGP by focusing on the following areas:

• Authentication: Who are you talking to?
• Confidentiality: How do we communicate?
• Integrity: What is being said?
• Availability: Are you there?

Conventionally there are several approaches to securing BGP sessions, including the following:

• Explicitly configured BGP peers
• Using BGP session shared secrets
• Leveraging an IPsec tunnel
• Using loopback addresses on BGP peers
• Controlling the Time-to-Live (TTL) on BGP packets
• Filtering on the peering interface
• Using link-local peering
• Preventing long AS paths
• Limiting the number of prefixes received
• Preventing BGP updates that contain private AS numbers
• Maximizing BGP peer availability
• Logging BGP neighbor activity
• Securing IGP
• Extreme measures for securing communications between BGP peers

The following sections briefly describe each of these methods. More extreme measures that are not frequently used are also briefly mentioned later in this chapter.

Explicitly Configured BGP Peers

One technique for securing BGP sessions is the concept that BGP sessions must be configured on each peering router. Peering is done explicitly by both BGP speakers. Therefore, a router will not form a peering session with another router that it has not been configured to peer with, and both peers mutually agree upon the BGP settings. A BGP peering session is not established if only one router is configured. There must be complementary configurations on each side for communications to take place. BGP communications take place over TCP, so the protocol must rely on a properly configured IP-layer foundation. BGP uses TCP port 179, so it has some inherent security in the fact that it is a connection-oriented protocol. TCP session state is maintained between the two peers.

The fact that BGP is a stateful transport layer routing protocol would normally provide some level of security, but it is also one of BGP's weaknesses. Attackers can spoof BGP packets and send them toward one of the BGP routers, or they could attack the TCP peering session between two BGP routers. Threats against long-lived TCP sessions involve TCP session hijacking using sequence number predication to reset one of the peers. One solution to this problem is to have BGP implementations use strong sequence number randomization. Therefore guessing the next sequence number or acknowledgment (ACK) number would be difficult and improbable.

Using BGP Session Shared Secrets

One of the most widely used methods of securing BGP communications is to use a shared secret (password). RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option," defines how a simple password can be used with a message digest algorithm 5 (MD5) digest inserted into the BGP packets. This digest adds authentication to BGP and helps prevent an attacker from spoofing a BGP peer.

Even though it is a best practice to use a different password for every peering session, this can be difficult to maintain. Regardless, it is unwise to use the same secret password for all peering sessions. As they say, it is not a secret if you tell a bunch of people. RFC 3562, "Key Management Considerations for the TCP MD5 Signature Option," defines how a centralized system can maintain the security of the keys for all organizations. On a Cisco router, the password is assigned at the time that the neighbor is configured. Following is the router configuration command to enable MD5 authentication for a BGP peer:

   neighbor neighbor-ipv6-address password P@ssw0rd

Leveraging an IPsec Tunnel

Another technique for securing BGP communications is to leverage the security of an IPsec tunnel. IPsec is a strong way to secure BGP peers, protect the integrity of updates, and assist in preventing DoS attacks that target BGP peers. Using IPsec is better than MD5 because it keeps the keys refreshed over time. Because BGP is a TCP protocol, it can use IPsec with no modification. However, an IPsec connection must be created for the peering to form. This can add significant overhead to the routers, so it might be prohibitive in terms of CPU resources. Configuring and troubleshooting the IPsec tunnel can add significant burden to maintaining a service provider network. Furthermore, the IPsec tunnel that is used for sending routing information is thus used to forward traffic. The added packet-size overhead that IPsec adds would negatively impact throughput performance. Even though using IPsec is a secure method, it is not widely used.

Even still, an attacker who knows that a router is using authentication can simply create a large number of spoofed packets with fake authentication parameters and send them toward that router. This would cause the router to process these fake packets (even if they are quickly rejected) and artificially consume router resources. The CPU spike on the target router could delay legitimate routing traffic, thus accomplishing the attacker's goal of disrupting a network. Attackers could launch many authentication failures at the BGP router to potentially crash it. Therefore, authentication cannot be the only method of securing BGP communications.

Other methods of preventing unwanted traffic coming toward a router from causing problems involves filtering with access control lists (ACL). Control Plane Policing (CoPP) or Control Plane Protection (CPPr) can filter packets on the control plane of the router. Infrastructure ACLs (iACL) and receive ACLs can prevent the undesirable packets from reaching the router in the first place. Both of these concepts are covered fully in Chapter 6, "Hardening IPv6 Network Devices."

Using Loopback Addresses on BGP Peers

By using loopback addresses to peer BGP routers, it is more difficult for an attacker to know the source address of the TCP 179 peering session if the IP address could not be determined through the use of traceroute. Because loopbacks are logical interfaces, peering with loopbacks makes the BGP peers less physically connected and requires an Interior Gateway Protocol (IGP). Loopback interfaces are always up and operational, so they are very stable interfaces for the router to source many types of communications such as authentication, authorization, and accounting (AAA) or management traffic. Peering between loopback addresses is more popular on IBGP peers than EBGP peers because IBGP connections rely on an IGP. EBGP peers typically use the directly connected IP addresses on each end of the physical link, but these addresses can be easily discovered by attackers. Regardless, having a loopback IPv4 address as the router ID (RID) for the BGP process is a best practice.

Controlling the Time-to-Live (TTL) on BGP Packets

Another technique involves controlling the TTL value that is set in the IP header on the TCP port 179 packets. EBGP routers send updates with a TTL typically set to 255, and EBGP routers typically accept packets that have a TTL set to 0 or greater. The problem is that an EBGP router can accept BGP packets that could have surreptitiously come from a network many hops away. If the TTL is constrained so that the TCP packets cannot travel beyond the direct physical connection between two peers, some security is gained. IBGP routers typically peer over many physical hops, so this technique is not necessarily applicable in all situations.

To secure EBGP peers and create a better TTL algorithm, the Internet Engineering Task Force (IETF) devised BGP TTL Security Hack (BTSH), which is also known as the Generalized TTL-based Security Mechanism (GTSM) (RFC 3682). This technique makes the EBGP router send TCP 179 packets to its peer with the TTL set to 255. The remote peer receives the BGP packet, and the router decrements the TTL to 254. That remote EBGP peer can then only accept BGP packets that have a TTL set to 254 or higher. This enforces the rule that EBGP peers only accept BGP packets from the directly connected peers that are only one hop away. If a spoofed BGP peer sending BGP packets comes from two hops away, the targeted router receives a TTL of 253. Because this TTL value of the forged packet is not greater than 254, that packet fails the test and is silently discarded. Therefore, packets with TTL values lower than 254 have originated more than one hop away. The TTL settings need to be configured on both peers to be effective. BTSH was first available in Cisco IOS Releases 12.0(27)S, 12.3(7)T, and 12.2(25)S. This technique is also affectionately referred to as the TTL-Hack. Following is the command that is used on each neighbor:

   neighbor neighbor-ipv6-address ttl-security hops 1

BTSH helps with attacks against BGP, but it is not a complete solution within itself. For example, BTSH is not available to use on IBGP sessions. In addition to several other combinations, the TTL-Hack is a stronger strategy. It should also be mentioned that MD5 passwords and the TTL checking are both handled by the router CPU. These might be stronger techniques if routers start to support these security measures in hardware.

You can configure a reasonably secure IPv6 EBGP router with several of these techniques configured together. Figure 3-3 shows an example of two ISP routers that are peering with each other. Both ISPs have customer connections and their own backbone connections. The routers peer with both IPv4 and IPv6.

Example 3-5 shows the configuration of ISP1's R1 in this scenario. Router R1 peers with R2 over its Serial 1/0 interface. Each BGP speaker expects the TTL value in the IPv6 header to be 254. The multiprotocol BGP configuration uses the TTL-Hack and uses different passwords for the IPv4 peer and the IPv6 peer. R1 connects to the Customer 1 router over its Serial 1/1 interface. R1 uses prefix filters to limit what it learns from the customer network and what it sends and receives from the other ISP. The goal of the customer prefix list is to only allow the customer to advertise its own /48. The ISP prefix lists restrict routes more specific than a /48 and permits Teredo and 6to4 routes. Teredo and 6to4 are IPv6 transition mechanisms that are covered in more detail in Chapter 10, "Securing the Transition Mechanisms."

Example 3-5. Sample EBGP Router Configuration

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ipv6 address 2001:DB8::1:1:1:1/128
!
interface FastEthernet0/0
 ip address 2.2.2.1 255.255.255.0
 ipv6 address 2001:DB8:100::1/64
!
interface Serial1/0
 description ISP interconnect
 ip address 192.168.12.1 255.255.255.0
 ip access-group 100 in
 ipv6 address 2001:DB8:12::1/64
 ipv6 traffic-filter ALLOWBGP in
!
interface Serial1/1
 description Customer 1
 ip address 1.1.0.1 255.255.255.0
 ipv6 address 2001:DB8:1:1::1/64
!
router bgp 100
 bgp router-id 1.1.1.1
 no bgp fast-external-fallover
 bgp log-neighbor-changes
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360
 bgp graceful-restart
 bgp maxas-limit 50
 neighbor 1.1.0.11 remote-as 1000
 neighbor 1.1.0.11 ttl-security hops 1
 neighbor 1.1.0.11 password cisco321
 neighbor 2001:DB8:1:1::11 remote-as 1000
 neighbor 2001:DB8:1:1::11 ttl-security hops 1
 neighbor 2001:DB8:1:1::11 password cisco123
 neighbor 2001:DB8:12::2 remote-as 200
 neighbor 2001:DB8:12::2 ttl-security hops 1
 neighbor 2001:DB8:12::2 password cisco123
 neighbor 192.168.12.2 remote-as 200
 neighbor 192.168.12.2 ttl-security hops 1
 neighbor 192.168.12.2 password cisco321
 !
 address-family ipv4
  neighbor 1.1.0.11 activate
  neighbor 1.1.0.11 maximum-prefix 250000
  no neighbor 2001:DB8:1:1::11 activate
  no neighbor 2001:DB8:12::2 activate
  neighbor 192.168.12.2 activate
  neighbor 192.168.12.2 maximum-prefix 250000
  no auto-summary
  no synchronization
  network 1.1.0.0 mask 255.255.255.0
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:DB8:1:1::11 activate
  neighbor 2001:DB8:1:1::11 remove-private-as
  neighbor 2001:DB8:1:1::11 prefix-list FILTERV6CUSTIN in
  neighbor 2001:DB8:1:1::11 maximum-prefix 250000
  neighbor 2001:DB8:12::2 activate
  neighbor 2001:DB8:12::2 remove-private-as
  neighbor 2001:DB8:12::2 prefix-list FILTERV6ISPIN in
  neighbor 2001:DB8:12::2 prefix-list FILTERV6ISPOUT out
  neighbor 2001:DB8:12::2 maximum-prefix 250000
  network 2001:DB8:1::/48
  network 2001:DB8:1:1::/64
  no synchronization
 exit-address-family
!
access-list 100 permit tcp host 192.168.12.2 host 192.168.12.1 eq bgp
access-list 100 deny   tcp any any eq bgp
access-list 100 permit ip any any
!
ipv6 route 2001:DB8:1::/48 Null0
!
ipv6 prefix-list FILTERV6CUSTIN seq 10 permit 2001:DB8:11::/48
ipv6 prefix-list FILTERV6CUSTIN seq 20 deny ::/0 le 128
!
ipv6 prefix-list FILTERV6ISPIN seq 10 deny 2001:DB8:1::/48
ipv6 prefix-list FILTERV6ISPIN seq 20 permit 2001:DB8::/32 le 64
ipv6 prefix-list FILTERV6ISPIN seq 30 permit 2002::/16
ipv6 prefix-list FILTERV6ISPIN seq 40 permit 2001::/32
ipv6 prefix-list FILTERV6ISPIN seq 50 deny ::/0 le 128
!
ipv6 prefix-list FILTERV6ISPOUT seq 10 deny 2001:DB8::/32 ge 49
ipv6 prefix-list FILTERV6ISPOUT seq 20 permit ::/0 le 128
!
ipv6 access-list ALLOWBGP
 permit tcp host 2001:DB8:12::2 host 2001:DB8:12::1 eq bgp
 deny tcp any any eq bgp
 permit ipv6 any any

Filtering on the Peering Interface

It is a best practice to perform filtering on the interface that is used to form a BGP peering relationship. In addition to permitting transit IPv6 traffic, you should permit the BGP (TCP port 179) packets that are sourced from the directly connected BGP neighbor's address. As shown earlier in Example 3-5, both routers use ACLs to permit TCP port 179 peers from only those addresses desired. The Serial 1/0 interface has an IPv4 access list and IPv6 traffic filter that permit only BGP communications with the peer R2.

Using Link-Local Peering

You have already seen a secure BGP peering configuration using unicast addresses in Example 3-5. You can also configure BGP peers to use link-local addresses, but there are both benefits and drawbacks. The concept of link-local peering involves using the link-local address of the directly connected neighbor router as the IPv6 address configured for the BGP neighbor. The concept is that if link-local addresses are used, there would be no way for any other attacker to try to create a peering session with the routers. The attacker could not communicate with either peer in the first place. Furthermore, the attacker would not know the IPv6 addresses of either peer and, as shown in Chapter 2, the reconnaissance of these addresses would not be feasible. Because many organizations might question whether to use global addresses or link-local addresses for BGP peering, it is important to cover this in more detail. The following sections review the positive and negative aspects of using link-local addresses instead of global addresses.

When using link-local addresses for BGP peers, you must explicitly configure the link-local address of the neighbor. Because DNS is not used for link-local addresses, you must manually enter these addresses. As a result, you could easily make a mistake that might take some time to troubleshoot.

Also be aware that the link-local address of a router can be shared among multiple interfaces. Therefore, you must configure the router for the neighbor's link-local address and specify the interface that is being used for the directly connected addresses. There are two ways of doing this. In earlier software versions, you would specify the interface identifier following the link-local address (for example, FE80::C800:17FF:FE88:0%Serial1/0). Another newer technique uses the update-source neighbor parameter to specify the interface. Example 3-6 shows how this configuration can appear.

Example 3-6. BGP Peering Using Link-Local Addresses

hostname R1
!
interface Serial1/0
 description ISP interconnect
 ipv6 address 2001:DB8:12::1/64
 ipv6 traffic-filter ALLOWBGP in
!
router bgp 100
 bgp router-id 1.1.1.1
 neighbor FE80::C801:15FF:FE44:0 remote-as 200
 neighbor FE80::C801:15FF:FE44:0 ttl-security hops 1
 neighbor FE80::C801:15FF:FE44:0 password cisco123
 neighbor FE80::C801:15FF:FE44:0 update-source Serial1/0
 !
 address-family ipv4
  no neighbor FE80::C801:15FF:FE44:0 activate
 exit-address-family
 !
 address-family ipv6
  neighbor FE80::C801:15FF:FE44:0 activate
  neighbor FE80::C801:15FF:FE44:0 prefix-list FILTERV6ISPIN in
  neighbor FE80::C801:15FF:FE44:0 prefix-list FILTERV6ISPOUT out
  neighbor FE80::C801:15FF:FE44:0 route-map SETNEXTHOP out
  neighbor FE80::C801:15FF:FE44:0 maximum-prefix 250000
  network 2001:DB8:1::/48
  network 2001:DB8:1:1::/64
  no synchronization
 exit-address-family
!
route-map SETNEXTHOP permit 10
 set ipv6 next-hop 2001:DB8:12::1
!
ipv6 access-list ALLOWBGP
 permit tcp host FE80::C801:15FF:FE44:0 host FE80::C800:15FF:FE44:0 eq bgp
 deny tcp any any eq bgp
 permit ipv6 any any

In Example 3-6, the EBGP neighbor is configured using the link-local address of the peer. The traffic filter ALLOWBGP permits communication between the peers. The interface name/number is required to be added to link-local neighbor commands because the link-local addresses are not necessarily unique to each router interface. This example uses the update-source method of configuring the interface for the peering session. The interface that is used is the physical serial interface that the two routers share. You should not use the loopback's link-local address as the update source when using link-local peering. This can cause confusion when troubleshooting because many of a router's interfaces share the same link-local address.

Link-Local Addresses and the BGP Next-Hop Address

Another consideration is how BGP routers use the link-local addresses as the next hop address. A good description of how this is done is contained in the RFC 2545, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing." Section 3 of this RFC states that a global IPv6 address should be used as the next-hop address even though the peer can be configured to use a link-local address. This is important to consider because link-local addresses could be used on any interface and are not deterministic on which interface should be used for the communications. Because link-local addresses are local only to that subnet, they can be used across multiple interfaces without issue. However, for BGP routing, there needs to be a valid global IPv6 address that can be used for the BGP next-hop verification process.

There are situations where the next-hop attribute (MP_REACH_NLRI) can contain a single global IPv6 address or both a global address and a link-local address. The latter occurs when the two BGP peers share a common subnet, which is typically the case in EBGP. However, for IBGP, peers that might not share interfaces on a common subnet should use a global IPv6 address for their next-hop attribute.

For these reasons, a route map is required to set the next-hop address as a global address so that other routers can reach the next hop and keep this route valid. If the route map is not configured, the router will advertise one of its own global addresses as the next-hop address. If this is not reachable by the peer, the routes will be invalid and will be dropped. Most ISPs set the next hop manually to help speed convergence, so this should be an easy practice to maintain. Example 3-6 shows the configuration of the route map to explicitly set the next address.

Example 3-7 shows what the routes look like on the other EBGP router R2. The IPv6 routing table shows the route learned from R1 and the interface that the route came across on. You can also see the next-hop address in the BGP IPv6 unicast table. When you look explicitly at the route, you see the peer router's global and link-local addresses.

Example 3-7. Next-Hop Address for Link-Local Peers

R2# show ipv6 route
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
LC  2001:DB8::2:2:2:2/128 [0/0]
     via ::, Loopback0
B   2001:DB8:1::/48 [20/0]
     via FE80::C800:15FF:FE44:0, Serial1/0
S   2001:DB8:2::/48 [1/0]
     via ::, Null0
C   2001:DB8:2:2::/64 [0/0]
     via ::, Serial1/1
L   2001:DB8:2:2::1/128 [0/0]
     via ::, Serial1/1
B   2001:DB8:11::/48 [20/0]
     via FE80::C800:15FF:FE44:0, Serial1/0
C   2001:DB8:12::/64 [0/0]
     via ::, Serial1/0
L   2001:DB8:12::2/128 [0/0]
     via ::, Serial1/0
B   2001:DB8:22::/48 [20/0]
     via 2001:DB8:2:2::22
C   2001:DB8:100::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:DB8:100::2/128 [0/0]
     via ::, FastEthernet0/0
L   FF00::/8 [0/0]
     via ::, Null0
R2# show bgp ipv6 unicast
BGP table version is 6, local router ID is 1.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2001:DB8:1::/48  2001:DB8:12::1           0             0 100 i
*> 2001:DB8:2::/48  ::                       0         32768 i
*> 2001:DB8:2:2::/64
                    ::                       0         32768 i
*> 2001:DB8:11::/48 2001:DB8:12::1                         0 100 1000 i
*> 2001:DB8:22::/48 2001:DB8:2:2::22
                                             0             0 2000 i
R2# show bgp ipv6 unicast 2001:db8:11::/48
BGP routing table entry for 2001:DB8:11::/48, version 2
Paths: (1 available, best #1, table Global-IPv6-Table)
  Advertised to update-groups:
        2
  100 1000
    2001:DB8:12::1 (FE80::C800:15FF:FE44:0) from FE80::C800:15FF:FE44:0 (1.1.1.1
)
      Origin IGP, localpref 100, valid, external, best
R2#

Drawbacks of Using Link-Local Addresses

As you can see, there are several security benefits of using link-local addresses for BGP peering. However, there are also some drawbacks. It is important to have identical configurations on both BGP peers, and if a change is made on one peer, the peering session can fail, causing routes to flap. If the global address changes on the interface of the EBGP peer, the BGP configuration of the EBGP peer also needs to change. As mentioned previously, BGP can carry both the link-local and global addresses in updates, so if two BGP peers share a common subnet, the MP_REACH_NLRI attribute contains both the link-local and global address. The global address is used to readvertise to other peers so that the next-hop test passes.

If the hardware changes on either BGP peer router, the corresponding addresses used in the configuration must change. The MAC address of the router's interface would be different, and the link-local address is derived partly from the MAC address. This could be a latent problem that could be difficult to troubleshoot, and it would take a small amount of effort to correct. Ironing out the details of exactly what IPv6 addresses are to be used for the BGP peer should be performed during the turn-up and provisioning procedures and also as part of the procedures for hardware replacement because of an upgrade or a failure.

It can be common practice to filter link-local addresses at the network's perimeter because link-local addresses should not be used as either the source or destination address for Internet traffic. However, filtering these packets could adversely affect EBGP, depending on how it is configured. Because there are plenty of global addresses, there is no need for peering using link-local addresses to conserve addresses.

The use of global addresses for peering keeps the configuration pretty simple. The next-hop address is simplified and global addresses are required for IBGP and EBGP multihop. There is a consistency of configuration if global addresses are used. Access lists should be used to filter BGP speakers, BTSH (TTL Hack) should be used to check the TTL value in the IP header, and the TCP MD5 signature option should be enabled. These techniques will mitigate the risk of spoofed BGP packets affecting the peering session. Therefore, these techniques can achieve the same security that using link-local addresses for peering provides.

For many, the use of link-local addresses can be overly complex. Therefore, many organizations might prefer to use global unicast addresses for EBGP peering rather than link-local addresses. Depending on your preferences, the additional work to use link-local addresses might not yield sufficient security to make it worthwhile.

Preventing Long AS Paths

Another technique that an attacker might use against BGP is to create updates that contain unusually long AS paths. These falsified updates could put a burden on the router receiving such an update. It is not typical to have an AS path that is longer than a specific size. To prevent these paths, you can use the following BGP configuration command to limit the number of AS path hops:

   bgp maxas-limit number-of-AS-Hops

This command limits the number of autonomous system (AS) numbers listed in the path of a BGP message. Typically the length of the AS path should not be more than 50 hops.

On IOS XR, you can use a configuration like the one shown in Example 3-8 to limit the number of ASNs in the path.

Example 3-8. IOS XR BGP Policy to Limit the AS Path Length

(config)# route-policy STOPLONGPATHS
(config-rpl)# if as-path length ge 50 then
(config-rpl-if)# drop
(config-rpl-if)# endif
(config-rpl)# exit
(config)# router bgp 100
(config-bgp)# neighbor 2001:db8:100:100::1
(config-bgp-nbr)# address-family ipv6 unicast
(config-bgp-nbr-af)# route-policy STOPLONGPATHS in

Limiting the Number of Prefixes Received

A similar type of attack would involve sending an extremely large number of prefixes to a peer in an effort to consume excessive amounts of memory and cause the BGP router harm. Thankfully, there are options that allow you to prevent this from happening. The following command limits the number of prefixes learned from a neighbor. This command would not only restrict the number of prefixes received from a peer, but it would also shut down the BGP peering session as a defensive mechanism if the peer sends more than 250,000 prefixes. This command was also used in Example 3-5, earlier in this chapter.

   neighbor neighbor-ipv6-address maximum-prefix 250000

Preventing BGP Updates Containing Private AS Numbers

The AS numbers in the range of 64512 to 65534 have been set aside by the IANA for private use. Therefore, these private AS numbers should not be used on the Internet or within any Internet BGP update. Therefore, you should filter any bogus paths that contain a private AS number. This is difficult to achieve using the ip as-path access-list commands. The following command helps make the configuration simpler and works to prevent BGP updates containing private AS numbers:

   neighbor neighbor-ipv6-address remove-private-as

This command can be used on EBGP peers. This command causes the BGP router to filter out any update that has only private AS numbers. However, if the update has a mix of both private and public AS numbers, the update is allowed. Furthermore, if the update contains a list of confederated AS numbers, the private AS numbers that appear after the confederation part of the AS path list will be removed.

Maximizing BGP Peer Availability

BGP is used as the foundation routing protocol for the Internet. Because so many organizations worldwide rely on the stability of Internet routes, attackers would want to destabilize BGP routing if possible. BGP has several techniques to help provide stability for the Internet and help prevent attacks. However, attackers might want to get around these or even use these BGP techniques against the routers themselves to cause a DoS condition. Therefore, you should maximize the availability of your BGP peers by using these techniques.

Disabling Route-Flap Dampening

There are attacks that target the BGP connections between peers. Even if an attacker cannot falsely inject updates, he could cause a disruption between two peers. BGP route-flap dampening was defined in IETF RFC 2439 as a way to disconnect routers from the Internet if they flapped too many times over a given period. If a router had faulty hardware, it could cause many Internet routers to add/remove routes and consume resources. An attacker can use the fact that a router is using BGP route-flap dampening against itself. Even just a few flaps could cause a neighbor to be dampened and cause an even larger outage. Some organizations can elect to not use route-flap dampening because of the DoS risks. Therefore, if you are going to use route-flap dampening, you should use the recommended parameters (RFC 2439 and RIPE-229). If you want to disable route-flap dampening, use the no bgp dampening BGP configuration command to turn it off.

Disabling Fast External Fallover

One BGP optimization technique involves resetting the peer if the physical link used for that peering session failed. This is an attempt to prevent the peer from remaining up if there is an alternate path that would allow the TCP port 179 connection to remain active. Even though this feature is enabled by default, the command used to enable this feature is bgp fast-external-fallover. Many feel that this technique is too harsh and could cause more damage than it prevents during BGP attacks. An attack could affect the directly connected link between two peers and cause the session to fail if those routers did not have another path for communicating BGP. Therefore, you might want to disable this feature with the no bgp fast-external-fallover command. Disabling fast fallover means that the peer waits for the hold timer to expire before resetting the peer. You can also disable this feature on an interface basis with the ip bgp fast-external-fallover command. By disabling this feature, the routers are more forgiving of small outages because of an attack to prevent the BGP peering session from failing and causing a reconvergence event.

Enabling Graceful Restart and Route Refresh or Soft Reconfiguration

If the peer does fail, you should have BGP Graceful Restart configured to speed the recovery of the peer. Graceful Restart capabilities are exchanged between peers during the OPEN message exchange. If both routers support Graceful Restart and one router comes under a short-duration attack, the other router does not discard all the routes associated with the peer but waits for the peer to recover. If the peering session is reestablished quickly, no packets are lost during the failure event. Therefore BGP Graceful Restart has security and performance benefits, but both sides of the BGP peering session must support this feature. To enable this feature, you can enter the following command within the BGP configuration block:

   bgp graceful-restart

BGP Connection Resets

If the BGP peering session fails between two routers, the routes each router has for the neighbor are eliminated. BGP peering connection resets can occur as part of standard configuration maintenance or as a result of a hardware failure or even a targeted BGP attack. You should understand the ways that the BGP routers recover from a failure.

There are two types of failures that can occur between BGP peers:

• A hard reset is when there is a complete failure, the entire TCP session is taken down, and all the routes are removed for that peer.
• A soft reset is gentler, and the peer stores prefix information until the peer is restored.

RFC 2918, "Route Refresh Capability for BGP-4," adds a route refresh capability that is exchanged when the peer is formed. Routes can be dynamically updated without having to store the updates. If you are performing normal BGP maintenance and need to reset a peer, it is better to do it with a soft reset to aid in recovery. You can see whether the BGP neighbor supports the route refresh capability by looking at the output of the show bgp ipv6 unicast neighbor command. Example 3-9 shows the route refresh status and the Graceful Restart capability.

Example 3-9. Viewing the BGP Peer Status

R1# show bgp ipv6 unicast neighbor
BGP neighbor is 2001:DB8:12::2,  remote AS 200, external link
  BGP version 4, remote router ID 1.1.1.2
  BGP state = Established, up for 00:02:11
  Last read 00:00:11, last write 00:00:11, hold time is 180, keepalive interval
is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)                          
    Address family IPv6 Unicast: advertised and received
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families preserved by peer:
        none
...

If the route refresh capability is not available on either peer, you can configure soft reconfiguration. This can be done with the following two commands:

   bgp soft-reconfig-backup
   neighbor neighbor-ipv6-address soft-reconfiguration [inbound]

Logging BGP Neighbor Activity

It is also a best practice to log all BGP neighbor activity. If an attacker is targeting your BGP routers, you should log all BGP neighbor changes. This is a good practice for typical operational reasons besides the security-monitoring aspects. Following is the command that needs to be configured under the router bgp stanza:

   bgp log-neighbor-changes

Securing IGP

Because BGP is a TCP layer routing protocol, it relies on a stable IP foundation. In fact, BGP oftentimes relies on a stable IGP to be able to reach the next hop or a distant IBGP peer. Therefore, the security of the IGP routing protocol is important. Chapter 6 shows several configurations on how to secure various IGPs. If you are using Intermediate System–to–Intermediate System (IS-IS) as your IGP, be sure to use the optional password-protected checksums defined in RFC 3358. Within the service provider's network, use Open Shortest Path First version 3 (OSPFv3) with IPsec instead of just MD5 authentication. These practices can help prevent attackers from making your BGP architecture fail.

Extreme Measures for Securing Communications Between BGP Peers

Other techniques for securing communications between BGP peers are outside the configuration of BGP but can help support the security of the BGP communications. Drastic measures for securing peering can include turning off the Neighbor Discovery Protocols (NDP). Because of the IPv6 risks on LANs that are similar to the risks found in IPv4 Address Resolution Protocol (ARP), you can elect to statically define the IPv6 addresses on the interfaces.

If there are no hosts on the Ethernet interface between the two BGP routers, there is little use for NDP to operate. Disabling NDP would be synonymous with using static ARP entries in an IPv4 LAN for Ethernet peering. On IPv6 networks, this means configuring static MAC addresses and binding them manually to link-local addresses, thereby creating static neighbor cache entries. This would take the guesswork out of configuration of the neighbor, and the NDP would not be required for normal operations. Furthermore, you could consider using static content-addressable memory (CAM) entries in any Ethernet switches between the BGP peers. These techniques are only for the extremely paranoid and for those network administrators with lots of time on their hands. These techniques could have additional side effects that require more configuration commands, additional troubleshooting, and higher operational costs that do not justify a small gain in additional security.

IPv6 over MPLS Security

When service providers consider their IPv6 deployment plans, they look at what services their customers want and what the customers are willing to pay for. They then consider how difficult it would be to provide these services with the infrastructure they already have. Because service providers might not be charging extra for IPv6 connectivity, the budget for the deployment is extremely low. Therefore, the simplest methods of deploying IPv6 are often preferred.

RFC 4029, "Scenarios and Analysis for Introducing IPv6 into ISP Networks," describes the steps of IPv6 deployment that most service providers take into consideration. Service providers start by creating a dual-stack backbone and connecting to an IPv6 exchange. Service providers initially create connections using tunnels. As their migration progresses, customers can be connected with native dual-stack connections. This involves the use of an IPv6-capable IGP such as IS-IS or OSPFv3. Eventually their entire infrastructure is fully dual-stack capable. However, this takes considerable time and can require investment in new equipment that is dual-stack capable.

Some service providers use IPv6 tunnels over their existing IPv4 infrastructure to provide IPv6 services to their customers. They find that despite the scalability issues of maintaining multiple manually configured tunnels, it is easy to configure. The downsides are that troubleshooting is more difficult because IPv6 connectivity is based on the underlying IPv4 network stability. Tunnels can also route traffic in awkward ways that can be suboptimal and increase latency. The other concern is that ultimately these tunnels will have to be taken down as the network becomes fully dual-stack capable.

Many service providers have already deployed IPv4 Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPN) (RFC 4364). Figure 3-4 shows a service provider's MPLS network that supports customers that use different IP versions. Customers use customer edge (CE) routers at their sites to communicate with the service provider's provider edge (PE) router. PE routers use Virtual Routing and Forwarding (VRF) instances to separate customers into their own VPNs. Inside the service provider's core provider (P), routers create label switched paths (LSP) to connect customer sites but prevent customers' networks from communicating with other customers. As customer packets traverse the MPLS, core network labels are used at each hop to help forward the packets. MPLS networks can be leveraged for providing IPv6 services to customers. There are several models of adding IPv6 to an existing IPv4 MPLS network, including the following:

• Use static IPv6 over IPv4 tunnels between PE routers
• Use 6PE (simpler PE routers that are IPv6-aware) to use the IPv4 MPLS core to send IPv6 packets between PE routers
• Use 6VPE (MPLS VPN dual-protocol PE routers) to create separate IPv6-aware VRFs

Service providers can offer several types of IPv6 services. Every flavor has its advantages and disadvantages for the service provider and the customer. You should know which one you are purchasing from the service provider. This can help you determine the risks that exist and know how to mitigate them. The following sections provide an overview of each model. In-depth coverage of how to configure each of these types of networks is outside the scope of this book. However, Deploying IPv6 Networks, by Ciprian P. Popoviciu, Eric Levy-Abegnoli, and Patrick Grossetete (Cisco Press, 2006), covers the configuration details of setting up these different types of MPLS environments for IPv6.

Using Static IPv6 over IPv4 Tunnels Between PE Routers

The first technique mentioned uses statically configured tunnels between PE routers. The tunnel interfaces have a tunnel destination of the remote PE router's IPv4 address. The IBGP between PE routers and the LSPs created over the IPv4 P routers allow the tunnel endpoints to communicate. The security issues related to static tunnels apply to this solution. You should make sure that you are protecting the tunnel endpoints and filtering traffic entering and leaving the tunnel at both ends. The goal is to prevent spoofed packets from entering the tunnel or escaping the tunnel.

Using 6PE

The second technique involves enabling IPv6 on the PE routers and using the IBGP advertisements of the IPv6 routes to form LSPs that can carry the IPv6 packets. A two-label stack is typically used. The inner label is the BGP label for the IPv6 route. The outer label is based on the P routers forwarding the traffic based on their IPv4 IGP routing protocols. This technique is called 6PE.

The advantage of using 6PE is that the core can remain IPv4-only for the near term, and the LSPs are constructed between dual-stack PE routers. The signaling of the LSPs still uses IPv4. Although 6PE does not support IPv6 multicast, it is one of the easiest ways to leverage an existing IPv4 MPLS core infrastructure. This can give the service provider time to upgrade its MPLS core to IPv6 while still providing basic dual-protocol services to customers.

Similar to the tunneling methods, 6PE will eventually need to be migrated away from IPv4 as the core gets migrated to IPv6. Because 6PE is not the final solution, it is considered by some to be just an incremental step toward a fully IPv6-aware core network. The work to migrate to IPv6 is tough enough without having to go through many intermediary steps that can become migrations in and of themselves. As they say, "If you don't have time to do it right, you certainly don't have time to do it over." For this reason, some aggressive service providers might bypass the 6PE step and strive for an IPv6-aware core directly.

Another disadvantage of the 6PE technique is that 6PE is like having one large single routing table. There is no differentiation of customer traffic across the core. Customers are not separated from each other as with Layer 3 MPLS-based VPNs. 6PE is more like having a big MPLS Internet service with global IPv6 routes. This technique can be used for commodity IPv6 Internet connectivity for customers. If you are using an MPLS service for Internet connectivity, you need to protect your perimeter accordingly. If you are using a 6PE service for site-to-site connectivity, you should be filtering traffic going between sites and filtering the routes being advertised and received from the service provider. You might also want to consider using encryption between your sites as an extra measure of security.

The security implication of using 6PE services is that there is no inherent security built into the service. Customers should be aware of the type of service they are selecting from the provider and protect their traffic accordingly. Just because the service provider says that the IPv6 is being provided over an MPLS network, do not assume that a Layer 3 MPLS-based VPN service is being used.

Using 6VPE to Create IPv6-Aware VRFs

The third solution is an IPv6 MPLS VPN service. 6VPE is more like the MPLS-based VPNs that are currently popular for IPv4 connectivity. Using a Layer 3 MPLS VPN service for IPv6 networks gives the security benefits of separating customer traffic into different VRFs. 6VPE networks use a two-label stack, with the internal label being the VPN label identifier and the outer label being assigned as a result of the IGP. The P routers only look at the label and swap labels. They do not care whether it is an IPv4 or IPv6 packet inside. At the same time, 6VPE should fit the operational models that many service providers have already adopted. However, there currently are limited solutions for creating native IPv6 LSPs using Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP). While LDPv6 has been defined, it is not widely implemented. The Cisco 6VPE solution is an implementation of RFC 4659. 6VPE can work on top of a core infrastructure that uses either or both IP versions. That can mean infrastructure upgrades and the deployment of an IGP that is capable of both IPv4 and IPv6 routing.

6VPE provides the same level of security as IPv4 BGP-based Layer 3 MPLS VPNs, which is discussed in RFC 4381, "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)." As long as the 6VPE PE routers are configured properly, the system can provide the same security as traditional ATM or Frame Relay links. Because the service provider isolates its core network from customers, malicious customer traffic cannot impact the control plane of the service provider's out-of-band management network. Therefore, 6VPE can be safer than many other forms of WAN services.

Customer Premises Equipment

Service provider networks need to connect to many orders of magnitude more remote devices than enterprise networks do. Whereas a typical enterprise might have fewer than a hundred remote sites, a service provider could have thousands if not millions of subscribers. That means that scalability is of the utmost importance, and the reliability of the network must be maintained. IPv6 can uniquely support the addressing requirements for these types of networks.

No matter what type of physical medium the customer connection uses (xDSL, Cable/HFC, Fiber to the Home [FTTH], wireless), networking equipment called customer premises equipment (CPE) terminates service at the customer site. This equipment terminates the type of service provided by the Network Access Provider (NAP) and contains the Layer 3 address provided by the Network Service Provider (NSP). Each type of broadband access has its own way of connecting the customer to the NSP's routed infrastructure. Broadband access connections can use a direct connection or some form of tunneled protocol such as PPP or L2TP to connect the CPE to the Internet.

The service provider must secure its own network infrastructure when providing IPv6 services. Figure 3-5 shows several broadband access provider network topologies.

Regardless of whether DSL Access Multiplexer (DSLAM)/Broadband Remote Access Server (BRAS) or Cable Modem Termination System (CMTS) devices are used, the edge router (ER) is the device that connects the customer's connection to the IPv6 Internet. These devices, and particularly the ER, must be hardened from a security perspective. The NAP and NSP should be able to keep track of which user's CPE has been allocated to which address or address block. This is typically done with RADIUS servers that authenticate the user's connection before allowing them on the network.

CPE for small offices/home offices (SOHO) or residential broadband access needs to be easy to configure, administer, and secure. This is a requirement because the users are not necessarily knowledgeable about IPv6 or even networking. If the device has advanced settings that give more control over the IPv6 connectivity and security, the default settings should be set to make it easy and yet secure. Otherwise, the service provider can have substantial support calls from customers to help them configure their CPE devices. Even though the end user should be concerned about the security of his connection to the Internet, he does not necessarily need to be bogged down in the details. Service providers must consider the customer's security and their end-user experience when selecting CPE devices on their behalf.

These home-user-grade products are the simplest form of routers. They have a single default route, and they provide DHCP services to the computers on their wired or wireless LAN. They gain a single public IP address and perform Port Address Translation (PAT) for the private addresses used behind the public IP. The security functions they provide involve simply preventing inbound connections from being made. Simple dual-stack residential devices have similar features for both protocols. However, for the IPv6 protocol, PAT is not necessary because global unicast addresses are used for the CPE device's external and internal interfaces.

Residential and SOHO security devices should perform some of the same functions as commercial-grade firewall products. Residential gateways need to be able to statefully permit outbound connections and only allow inbound packets that result from an outbound connection. If a CPE product does allow more advanced configuration of the firewall policy, the default settings should be used to prevent Internet traffic from reaching the internal LAN.

Consumer-grade CPE best practices include the following:

• Do not forward packets that have a multicast source address.
• Block packets destined for multicast destinations in the outbound direction.
• Do not allow RH0 packets inbound or outbound.
• Block packets sourced from Unique Local Address (ULA) space (that is, FC00::/7).
• Block other bogon addresses from entering and leaving the interior LAN (difficult to do because this list changes several times each year).
• Block packets that are not sourced from the global unicast prefix assigned on the LAN interface. This prevents spoofed packets from leaving the user LAN.
• Deny packets sourced from the internal LAN prefix from coming in the external interface. This prevents spoofed packets from entering from the Internet.

IPv6-capable CPE routers should also prevent Teredo tunnels from forming from internal clients to Teredo servers. Teredo is only a transition mechanism for IPv6-capable hosts behind IPv4 NATs. Teredo is not used if the client has native IPv6 connectivity through the CPE router to an IPv6-capable service provider. The risk is that Teredo tunnels can be used as a back door into the client computer. However, preventing Teredo tunnels from being established can be difficult to accomplish. More information on this subject appears in Chapter 10.

If consumer-grade CPE devices are constructed with IPv6 security measures enabled by default, the customer's Internet connection will be more secure. The end user does not have to be so worried about these details, and the device can provide the required security features right out of the box.

More advanced users, like those reading this book, might want to have a more sophisticated device at their homes. For more advanced users that require more power, CPE devices such as the Cisco ASA5505, the Cisco 871, or the newer Cisco 880/860 routers perform nicely. These devices have full IPv6 capabilities and the ability to filter IPv6 packets based on a wide variety of header fields and extension headers. These devices might not have these default security settings. Therefore, the more advanced users need to be able to configure these same settings to secure their own Internet connections.

Prefix Delegation Threats

Service providers need to connect numerous customers to the IPv6 Internet. Most ISPs will connect larger customers with dedicated interfaces. These could either be T1s, Metro Ethernet, fiber, SONET, wireless, or any of a variety of media types. These directly connected customers will receive address assignments from the allocations that the service provider received from the regional registry. These assignments are performed manually and require coordination between the customer and the service provider. This method of allocating addresses is possible but does require the customer to be savvy at configuring his CPE.

For service providers that must connect millions of IPv6 Internet subscribers, there is no feasible way to coordinate direct assignments to that many customers manually. There needs to be an automated way of allocating IPv6 prefixes to customers and reclaiming those assignments if the customer disconnects. Current IPv4 broadband providers give customers a single IPv4 address and let the customer's device perform NAT. IPv6 will allow customers to acquire much more public address space. Broadband customers could be allocated a /48, /56, or /64 network prefix depending on the provider's policies, and then their CPE would allow the customers' hosts to perform Stateless Address Auto-configuration (SLAAC).

The following sections describe the use of SLAAC and indicate why some service providers prefer to use DHCPv6 instead.

SLAAC

Provisioning of new customer connections must be automated in some way to have a scalable system for the broadband service providers to maintain. One technique is to leverage SLAAC to allow the CPE device or hosts to acquire public IPv6 addresses. SLAAC can be used to uniquely allocate the addresses, and the Neighbor Discovery Protocol (NDP) function Duplicate Address Detection (DAD) can be used to avoid addressing conflicts. SLAAC might not be the best option for allocating IPv6 addresses to customers because there are no security features within the NDP. Furthermore, SLAAC can be a simple way to have nodes determine their address, but it does not provide them with other necessary information for communications, such as a DNS server for the node to use.

DHCPv6

Because SLAAC does not do everything that a service provider wants, the provider can elect to use DHCP version 6 (DHCPv6). The service provider's Layer 3 edge router can send a router advertisement (RA) message to inform customers that DHCPv6 is in use. The RA sends the A/M/O bits to tell the node that DHCPv6 is available. There can still be concern that the RA messages could be spoofed by an attacker. Because of the security issue of spoofed RA messages, service providers might want to make use of DHCPv6 instead of SLAAC. That way, they can know exactly who is turning up on the network.

Service providers might want some type of authentication to take place to verify a customer's legitimacy before allowing the customer on the network. If the subscriber has not paid his bill, he will not be allowed on the Internet. To gain more control over the subscriber, a service provider might want to use DHCPv6 rather than SLAAC. There can also be a concern that attackers could spoof DHCPv6 servers or DHCPv6 relays. Rogue DHCPv6 servers could give out false information. Therefore, the security of DHCPv6 is a serious concern.

There are some solutions to the security vulnerabilities within DHCPv6. Hackers could also try to see whether DHCPv6 servers are allocating sequential lease addresses. That would lead to much easier network reconnaissance. Cisco Network Registrar gives out pseudorandom leases, so this would prevent easy guessing of the client assigned addresses.

Another risk is that a single system could consume DHCPv6 resources similar to the way that the hacker utility Gobbler can eat up all the available IPv4 DHCP addresses. One possible solution to the resource consumption attack is to rate limit messages sent to FF02::1:2 (All DHCPv6 Relay Agents and Servers) and FF05::1:3 (All DHCPv6 Servers).

If attackers can observe the information between the client and the server, many problems would result. DHCPv6 offers a mechanism to secure communication from the client and the DHCPv6 server with the use of authentication algorithms. This authentication mechanism does not provide confidentially but merely helps prevent theft of service. Within the DHCPv6 protocol itself, there is no current way to secure communications between the DHCPv6 relay agent and server. Separate IPsec configurations could be used to secure these communications.

DHCPv6 can provide a prefix to a device in addition to providing individual IPv6 addresses to hosts on a LAN. This is an extension to the DHCPv6 specification called DHCPv6 Prefix Delegation (DHCPv6-PD). The client device acts as a DHCPv6 client, and the DHCPv6 delegating router acts like the DHCPv6 server. It is relatively simple to have one router be a DHCP server for other access routers. The delegating router can be preconfigured with a pool of addresses that prefixes will be allocated from. The client router configuration is equally simple.

Example 3-10 shows what a delegating router configuration might look like. The DHCPv6 configuration on the router is tied to a specific interface. A pool is created that defines the block of addresses to allocate from and the prefix length to give to the client. In this case, /48 blocks are delegated to the clients out of a /40 pool. A DHCPv6 pool is created and assigned to an interface.

Example 3-10. Delegating Router Configuration

hostname R1
!
ipv6 unicast-routing
ipv6 dhcp pool CUSTPOOL
 prefix-delegation pool PREFIX
 dns-server 2001:DB8:1::1
!
interface FastEthernet1/0
 description Link to customers for DHCP prefix delegation
 no ip address
 ipv6 address 2001:DB8::1/64
 ipv6 dhcp server CUSTPOOL
!
ipv6 local pool PREFIX 2001:DB8:FF00::/40 48

The configuration of the DHCPv6 client is simple. Example 3-11 shows that DHCPv6-PD is tied to an interface and the allocated prefix is assigned to a general prefix variable. Router R2 is connected to R1 with interface Fast Ethernet 1/0. This general prefix variable can be used on other downstream interfaces.

Example 3-11. Client Router Configuration

hostname R2
!
interface FastEthernet1/0
 description Link to ISP for DHCP prefix delegation
 no ip address
 ipv6 address autoconfig default
 ipv6 enable
 ipv6 dhcp client pd PREFIX
!
interface FastEthernet1/1
 description LAN Link that will inherit prefix
 no ip address
 ipv6 address PREFIX ::1:0:0:0:1/64
 no keepalive

After these routers are configured and the Fast Ethernet 1/0 interface comes up, the delegating router can see the DHCPv6 requests and allocate the block. Example 3-12 shows the status of the delegating router. You can see the /48 block allocated to the client and the identity of the client device.

Example 3-12. Delegating Router Status

R1# show ipv6 local pool PREFIX
Prefix is 2001:DB8:FF00::/40 assign /48 prefix
1 entries in use, 255 available, 0 rejected
0 entries cached, 1000 maximum
User                Prefix                                       Interface
00030001CA0117DC000000050001
                    2001:DB8:FF00::/48
R1# show ipv6 dhcp bind
Client: FE80::C801:17FF:FEDC:1C
  DUID: 00030001CA0117DC0000
  Interface : FastEthernet1/0
  IA PD: IA ID 0x00050001, T1 302400, T2 483840
    Prefix: 2001:DB8:FF00::/48
            preferred lifetime 604800, valid lifetime 2592000
            expires at Sep 12 2008 08:09 AM (2590587 seconds)
R1# show ipv6 dhcp interface
FastEthernet1/0 is in server mode
  Using pool: CUSTPOOL
  Preference value: 0
  Hint from client: ignored
  Rapid-Commit: disabled
R1# show ipv6 dhcp pool
DHCPv6 pool: CUSTPOOL
  Prefix pool: PREFIX
               preferred lifetime 604800, valid lifetime 2592000
  DNS server: 2001:DB8:1::1
  Active clients: 1
R1#

The client router now has the allocated address assigned to its interfaces. Example 3-13 shows the status of the client router after the DHCPv6-PD allocation has been made. The show ipv6 dhcp command shows the client's DHCP Unique Identifier (DUID). The DUID can be unique to the client device, and DUIDs are assigned by the client router automatically and are based on the lowest MAC address on the device.

Example 3-13. Client Router Status

R2# show ipv6 dhcp
This device's DHCPv6 unique identifier(DUID): 00030001CA0117DC0000
R2# show ipv6 dhcp interface FastEthernet 1/0
FastEthernet1/0 is in client mode
  State is OPEN
  Renew will be sent in 3d11h
  List of known servers:
    Reachable via address: FE80::C800:17FF:FEDC:1C
    DUID: 00030001CA0017DC0000
    Preference: 0
    Configuration parameters:
      IA PD: IA ID 0x00050001, T1 302400, T2 483840
        Prefix: 2001:DB8:FF00::/48
                preferred lifetime 604800, valid lifetime 2592000
                expires at Sep 12 2008 08:09 AM (2590412 seconds)
      DNS server: 2001:DB8:1::1
      Information refresh time: 0
  Prefix name: PREFIX
  Rapid-Commit: disabled
R2#

The DUID can be used to provide some minor form of security for the DHCPv6-PD communications. DUIDs can be assigned statically, and the DUID could be assigned by the service provider. This might be slightly more secure, but it would eliminate any efficiency gained by using an automated address assignment method. If the DUID needs to be configured manually on the CPE, DHCP-PD might not be of much benefit compared to manually assigning a block to a customer.

Example 3-14 shows how the DUID can be statically configured on the delegating router R1. In this example, the prefix is granted only to the client router R2 with the preconfigured DUID.

Example 3-14. Delegating Router with Static DUID

ipv6 dhcp pool CUSTPOOL
 prefix-delegation 2001:DB8:1234::/48 00030001CA0117DC0000
 dns-server 2001:DB8:1::1

When this change is made on R1 and R2 reconnects to the service provider network, R2 receives a unique delegation based on its DUID. Example 3-15 shows the new address that R2 has been given. Because R2 is using a general prefix, it is passing along the use of that prefix to its Fast Ethernet 1/1 interface address.

Example 3-15. Client Router with Static DUID

R2# show ipv6 dhcp interface FastEthernet 1/0
FastEthernet1/0 is in client mode
  State is OPEN
  Renew will be sent in 00:00:46
  List of known servers:
    Reachable via address: FE80::C800:17FF:FEDC:1C
    DUID: 00030001CA0017DC0000
    Preference: 0
    Configuration parameters:
      IA PD: IA ID 0x00050001, T1 60, T2 120
        Prefix: 2001:DB8:1234::/48
                preferred lifetime 604800, valid lifetime 2592000
                expires at Sep 12 2008 08:38 AM (2591987 seconds)
      DNS server: 2001:DB8:1::1
      Information refresh time: 0
  Prefix name: PREFIX
  Rapid-Commit: disabled
R2# show ipv6 interface brief
FastEthernet1/0            [up/up]
    FE80::C801:17FF:FEDC:1C
    2001:DB8::C801:17FF:FEDC:1C
FastEthernet1/1            [up/up]
    FE80::C801:17FF:FEDC:1D
    2001:DB8:1234:1::1
R2#

Even with statically defined DUIDs, there can still be risks to DHCP-PD that could make this type of addressing problematic. An attacker could spoof a DUID or somehow try to impersonate another customer connection. This could either cause a misdirection of traffic or cause a DoS situation for the legitimate user. The same threats against traditional DHCP are the same as the threats against DHCPv6-PD.

If you wanted to make your address allocation system more secure, you could use a RADIUS server to authenticate the prefix delegation. You could create other ways to secure the DHCPv6 messages, but that would require more preconfiguration on the customer's equipment. The purpose of DHCPv6-PD is to make addressing simpler. If more coordination and expectations are placed on the skill of the broadband subscriber, the efficiency benefits will be lost.

Multihoming Issues

IPv6 addresses are allocated by service providers to end-user organizations. IPv6 addresses are intended to be fully hierarchical to help reduce the size of the core Internet routing table. Because IPv6 has the ability to have far more address blocks than IPv4, it would be impossible to have a large number of routes in the Internet backbone routers. With the increasing size of today's IPv4 Internet routing table, many devices struggle to handle the storage and the workload of processing the changes. Both memory and processor capacity are factors in the maximum size of the IP routing table. The size of the Forwarding Information Base (FIB) and the Routing Information Base (RIB) increases with the number of routes. As the FIB gets larger, so does the lookup time, which affects the forwarding rate. As the size of the routing table increases, so does the time of convergence. If Internet routers contain both IPv4 and IPv6, the problem gets worse.

Because IPv6 addresses are fully hierarchical, you probably do not need to use BGP, except in the default-free zone of the Internet backbone. An ISP could simply use a static route to point to the address block that has been allocated to the customer. In turn, the customer could simply use a default route to point toward the ISP for routing traffic to all unknown prefixes. This would simplify device configurations and also reduce the need for BGP, which would reduce the number of protocols the routers needed to run.

Many large organizations that connect to today's IPv4 Internet enjoy the redundancy that comes from connecting to two or more ISPs. This is part of an enterprise organization's disaster recovery and business continuity plan. The organization takes in routes from these providers (full routes, partial routes, or just the default route) and advertises its own address space from its own Autonomous System Number (ASN). Therefore, if one ISP connection were to fail, the BGP routing tables would converge and the customer would maintain its Internet connectivity.

If the rules of IPv6 addressing hierarchy were relaxed, many organizations could advertise their prefixes to the Internet. The address space would become fragmented, and the size of the Internet routing tables would expand out of control. Because of this fear, the addressing hierarchy has been enforced by the IANA, the IETF, the regional registries, and the ISPs. However, various registries (notably ARIN) have started to allow customers to obtain provider independent (PI) address space. This address space is not likely to be routed by service providers, but it does give customers additional addresses should they need them.

Many larger organizations still have a desire to have redundant connections to the Internet. Multinational organizations want to have Internet connections on the different continents they operate, for example. This is a requirement to reduce the latency that would result in back-hauling their Internet traffic to one central Internet attachment point. The redundancy and availability needs of customers must be addressed in some way. Customers must be allowed to be multihomed to the Internet. However, problems arise when sites have multiple address assignments from multiple ISPs. If one ISP link goes down, the other ISP does not readvertise the other ISP's address space. The customer addresses its web servers in one ISP's address space, and if that ISP fails, the web servers cannot be reached through the other ISP link. Therefore, alternatives must exist to allow the redundancy and failover between service providers without violating the address hierarchy rule.

The IETF has performed much work on the subject of multihoming. This early work is documented in RFC 3582, "Goals for IPv6 Site-Multihoming Architectures." Now the Site Multihoming by IPv6 Intermediation working group (shim6) is developing solutions to address sites that are multihomed. The primary solution that exists today is to use a "shim" that can be a new layer between the network layer and the transport layer. Above the shim are stable routable IPv6 addresses that allow applications to work as they have before and do not disrupt DNS information. The addresses above the shim are called Upper Layer IDs (ULID). Below the shim, IPv6 addresses can be used from either assigned blocks to get the packets forwarded to the destination.

Two hosts that want to communicate reliably both need to support the shim layer, and an initial shim protocol exchange needs to take place. During this exchange, both shim hosts share their available addresses with each other. This exchange shares the locator IDs between the two hosts. After this protocol exchange, both hosts are communicating with each other. If one of the address blocks loses connectivity because of an ISP failure, it can simply switch to using the other address space.

Figure 3-6 shows an example of how shim6 might work. Two sites have connections to two ISPs each, and each site has been allocated two /48 prefixes each. The two hosts need to communicate with each other, regardless of which ISP is available. They first communicate over whichever address space is available and then perform their shim protocol exchange. During this exchange, they share with each other their list of locator IDs, which are the address blocks the sites have been assigned by their ISPs. They are then able to communicate by using the shim header that contains the ULIDs. If host 2 loses its ISP2 connection, host 1 can use the locator ID for the remaining available prefix for host 2 that is still operational. Notice that the ULIDs did not change and thus the applications maintained state.

If an attacker could spoof packets with the shim header, several types of vulnerabilities would exist. One possible set of attacks comes from an attacker that is in the middle of the communication between two shim6 hosts. That attacker could perform redirection attacks to try to hijack the session. If the attacker could impersonate the locator IDs and the ULIDs, he could take over the communications. If the attacker could get a host to cache a locator ID, the attacker could redirect traffic to another network for an extended period of time.

Another type of attack would be a flooding attack, where an attacker would use its own locator ID to redirect a large volume of traffic to the victim. However, shim6 hosts perform a reachability probe-and-reply process to determine that the locator ID belongs to the remote host.

One solution to these security issues is for both hosts to use Hash Based Addresses (HBA) to ensure authenticity of the two hosts' locator IDs. These HBAs are a cryptographic one-way hash of the set of prefixes available for communications. This provides hijack protection because the HBAs cannot be tampered with in transit without detection. Performing the hash using nonces also helps prevent against replay attacks. Some form of public-key infrastructure (PKI) mechanism could also be used to secure the exchange between hosts.

There are additional security implications of using a shim between the IPv6 header and the upper-layer headers. Firewalls need to keep track of multiple sets of address space from different providers. This means that the firewall policies will grow, and the complexity of maintaining the rules and the management overhead will also grow. This is because hosts will have multiple addresses that could be used to source packets that can make it difficult to create granular firewall policies. Firewalls need to be shim-aware and parse the packets carefully, and they need to be able to handle sessions that start out without a shim and then transition to using a shim. Packet filters also need to be aware of session state when the ULIDs change within the shim.

Currently discussions are ongoing within the IETF about the use of shim6 and how it impacts other aspects of the IPv6 protocol and the operations of an IPv6 network. There are only a couple of implementations for hosts. There are discussions about integrating this functionality into routers so that they can perform this process on behalf of devices that do not have sufficient resources to create the shim themselves. There is also discussion about how the shim could be used for traffic engineering purposes instead of a simple multihoming solution. For the most updated information on this topic, you can go to the shim6 IETF working group site at http://www.ietf.org/html.charters/shim6-charter.html.

Summary

There will be many large-scale Internet threats that plague the IPv6 Internet in just the same way as DoS attacks disrupt today's Internet. Hopefully the larger address space of IPv6 will make scanning worms a thing of the past; however, other types of worms are likely to evolve. If service providers and customer organizations are performing ingress and egress filtering, tracebacks will be easier. The more research done on these IPv6 Internet threats, the more secure the IPv6 Internet will be in the future.

Service providers might be hesitant to add IPv6 functionality to their production IPv4 networks. They have a fear that new IPv6 vulnerabilities will lead to instability of their revenue-generating IPv4 networks. Network service providers can leverage secure BGP peering to help make the Internet a safer place for all. If service providers perform the proper filtering, they can mitigate many of these risks. Many organizations are connecting to dual-stack services today, and service providers can leverage their existing MPLS infrastructures to create secure IPv6 services.

The key is to make the customers' experience transparent, which means making it easy for them to configure their devices and securely automate address assignments. However, customers will have the same demands of IPv6 Internet connectivity as they have with IPv4 Internet connectivity. That means that solutions to IPv6 multihoming will need to be developed and secured.

References

AfriNIC. ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest.

APNIC. http://ftp.apnic.net/stats/apnic/delegated-apnic-latest.

ARIN. ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest.

Asadullah, S., A. Ahmed, C. Popoviciu, P. Savola, and J. Palet. RFC 4779, "ISP IPv6 Deployment Scenarios in Broadband Access Networks." http://tools.ietf.org/html/rfc4779. January 2007.

Baker, F. and P. Savola. BCP 84, RFC 3704, "Ingress Filtering for Multihomed Networks." http://tools.ietf.org/html/rfc3704. March 2004.

Bellovin, Steven M., Bill Cheswick, and Angelos D. Keromytis. "Worm Propagation Strategies in an IPv6 Internet." http://www.cs.columbia.edu/~smb/papers/v6worms.pdf. February 2006.

Blunk, L., J. Damas, F. Parent, and A. Robachevsky. RFC 4012, "Routing Policy Specification Language next generation (RPSLng)." http://tools.ietf.org/html/rfc4012. March 2005.

Cisco. "BGP Support for TTL Security Check." http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008020b982.html.

De Clercq, J., D. Ooms, S. Prevost, and F. Le Faucheur. RFC 4798, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)." http://tools.ietf.org/html/rfc4798. February 2007.

De Clercq, J., D. Ooms, M. Carugi, and F. Le Faucheur. RFC 4659, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN." http://tools.ietf.org/html/rfc4659. September 2006.

Döring, Greg. "IPv6 BGP filter recommendations." http://www.space.net/~gert/RIPE/ipv6-filters.html. August 17, 2008.

Droms, R. (Ed.), J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney. RFC 3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)." http://tools.ietf.org/html/rfc3315. July 2003.

Gill, V., J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. RFC 5082, "The Generalized TTL Security Mechanism (GTSM)." http://tools.ietf.org/html/rfc5082. October 2007 (obsoletes 3682).

Ford, Matthew, Jonathan Stevens, and John Ronan. "Initial Results from an IPv6 Darknet," International Conference on Internet Surveillance and Protection (ICISP'06). August 2006.

Huston, G. RFC 4147, "Proposed Changes to the Format of the IANA IPv6 Registry." http://tools.ietf.org/html/rfc4147. August 2005.

Huston, G. RFC 4177, "Architectural Approaches to Multi-homing for IPv6." http://tools.ietf.org/html/rfc4177. September 2005.

IANA. "IPv6 Global Unicast Address Assignments." http://www.iana.org/assignments/ipv6-unicast-address-assignments.

IANA. "IANA IPv6 Special Purpose Address Registry." http://www.iana.org/assignments/iana-ipv6-special-registry.

Ishihara, K., M. Mukai, R. Hiromi, and M. Mawatari. "Packet Filter and Route Filter Recommendation for IPv6 at xSP routers." http://www.cymru.com/Bogons/ipv6.txt. 2007/06/26.

LACNIC. ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest.

Lind, M., V. Ksinant, S. Park, A. Baudot, and P. Savola. RFC 4029, "Scenarios and Analysis for Introducing IPv6 into ISP Networks." http://tools.ietf.org/html/rfc4029. March 2005.

McArtor, Gary. "Secure Cisco IOS BGP Template Version 5.5," June 25, 2008. http://www.cymru.com/Documents/secure-bgp-template.html.

Nordmark, E. and T. Li. RFC 4218, "Threats Relating to IPv6 Multihoming Solutions." http://tools.ietf.org/html/rfc4218. October 2005.

RIPE/NCC. ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest.

Yang, Xinyu, Ting Ma, and Yi Shi. "Typical DoS/DDoS Threats under IPv6," International Multi-Conference on Computing in the Global Information Technology (ICCGI'07). March 2007, pp. 55.