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.
)
Figure 3-6 Shim6
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.