Networking / Beginners

---

Site Multihoming

A multihomed site is a site that has multiple connections to the Internet. It can be multiple connections to the same ISP, links to different ISPs, or multiple connections in separate geographic locations.

There are many reasons to multihome, including the following:

• Redundancy
• Load sharing
• Policy

The most persuasive reason for multihoming is redundancy. A well-designed multihome solution should be able to handle most failures (from a failed link or failed router to a transit ISP being down).

When you have all those expensive redundant links, the next logical step (when the finance department is breathing down your neck) is to use that extra capacity for traffic. That is where load sharing comes in.

The IPv4 multihoming solution is to let the routing system sort it out. The customer's prefix is advertised using BGP to all the ISPs to which the customer connects. This works with both provider independent (PI) address space and provider aggregated (PA) address space. In the latter case, when the multihomed site has addresses from one of the ISPs, advertising that address block will punch a hole in that ISP's aggregate. Either the customer has its own ASN, or uses a private ASN. In the latter case, ISPs will rewrite it with their own.

For the multihomed site, this solution works well. Even existing transport sessions survive in the case of a "rehoming" event.

The problem with this way of multihoming is that it does not scale well. Each multihomed site requires a slot in the default Internet routing table. Not only does this require more memory and higher processing capabilities in the core routers, it also results in more routing churn, pushing the current routing protocols to the limit. Doomsayers keep insisting that the end is near. Even if they are wrong, it would be good to come up with a better solution, one that also allows smaller organizations to multihome. Today's solution requires that you have a fair-sized address block, because small advertisements are typically filtered out; it also requires that the multihomed site have its own ASN. Both of these prerequisites are unavailable to the typical home user.

The original IPv6 address-allocation plan was that a multihomed site would get an address block from each of its providers. Hosts would then have multiple addresses, one for each of its providers. Transport protocols such as TCP do not allow renumbering on-the-fly. IP addresses used as endpoints for an active TCP connection cannot be changed. So, if the link to one provider fails, and a host picks a source address from that provider, the transport connection fails.

A better solution was clearly needed. The multi6 working group was created in the IETF and charted with defining the requirements and looking at the solution space for scalable multihoming. Several interesting ideas came up. A basis for several of them was that there had to be a separation of the identifier and the locator of a node. The IP address currently serves as both. This is not a trivial thing to change, and the most promising solution is to insert a shim layer between the IP header and the transport header, which will handle multihoming. Note that this is a shift from multihoming being handled by the network to multihoming being handled by the hosts. There are some obvious deployment issues with this (for instance, all hosts you need to communicate with should support multihoming), but let's assume that these issues will be resolved.

There is hope that a scalable multihoming solution will be found. Until then, IPv6 multihoming is done just as it is for IPv4. Anyone who does IPv4 multihoming today will most likely qualify for doing multihoming in IPv6, too.