Multihoming is a technique used to increase the reliability of a client IP network. One example of a multihomed network is one that is served by more than one ISP (or pipe).
Multihoming costs include any kind of investments/costs incurred due to platform affiliation. It basically consists of three components:
- Upfront cost: search, initial investment, training
- Ongoing cost: membership fees, maintenance cost
- Exit cost: salvage value of hardware/ software, termination costs
Multihoming variants 
In the IP context, there are several ways to multihome, separate from the actual protocols used to do so, amongst which the most important are:
Single Link, Multiple IP address (spaces) 
Multiple Interfaces, Single IP address per interface 
The host has multiple interfaces and each interface has one, or more, IP addresses. If one of the links fails, then its IP address becomes unreachable, but the other IP addresses will still work. Hosts that have multiple IPv6 or IPv4 records enabled can then still be reachable at the penalty of having the client program time out and retry on the broken address. Existing connections can't be taken over by the other interface, as TCP does not support this. To remedy this, one could use SCTP which does allow this situation. However SCTP is not used very much in practice. A new protocol based on TCP, Multipath TCP, taking form as a TCP extension, is also being actively worked on at the IETF as of March 2012. It would also remedy this issue, as well as providing better performances by making use of every available network interface.
Multiple Links, Single IP address (space) 
This is what is generally meant by Multihoming. With the use of a routing protocol, in most cases BGP, the end-site announces this address space to its upstream links. When one of the links fails, the protocol notices this on both sides and traffic is not sent over the failing link any more. This method is usually employed to multihome a site and not for single hosts.
Multiple Links, Multiple IP address (spaces) 
This approach uses a specialized Link Load Balancer (or WAN Load Balancer) appliance between the firewall and the link routers. No special configuration is required in the ISP’s routers. It allows use of all links at the same time to increase the total available bandwidth and detects link saturation and failures in real time to redirect traffic. Algorithms allow traffic management. Incoming balancing is usually performed with a real time DNS resolution.
Another common use of this variant is to control routing between the separate address spaces used by each interface. This is often used for PC Server based firewalls.
Multihoming caveats 
While multihoming is generally used to eliminate network connectivity as a potential single point of failure (SPOF), certain implementation caveats apply which can affect the success of such a strategy.
In particular, each of the following items must be addressed in order to eliminate the network SPOF:
- Upstream connectivity: A given network operations center must have multiple upstream links to independent providers. Furthermore, to lessen the possibility of simultaneous damage to all upstream links, the physical location of each of these upstream links should be physically diverse: far enough apart that a piece of machinery (such as a backhoe) won't accidentally sever all connections at the same time.
- Routers: Routers and switches must be positioned such that no single piece of network hardware controls all network access to a given host. In particular, it is not uncommon to see multiple Internet uplinks all converge on a single edge router. In such a configuration, the loss of that single router disconnects the Internet uplink, despite the fact that multiple ISPs are otherwise in use.
- Host connectivity: A "reliable" host must be connected to the network over multiple network interfaces, each connected to a separate router or switch. Alternatively, and preferably, the function of a given host could be duplicated across multiple computers, each of which is connected to a different router or switch.
- Referencing Entities: Not only must a host be accessible, but in many cases it must also be "referenced" to be useful. For most servers, this means in particular that the name resolution to that server be functional. For example, if the failure of a single element blocks users from properly resolving the DNS name of that server, then the server is effectively inaccessible, despite its otherwise connected state.
The elimination of a single point of failure is achieved only when each component that could potentially fail is duplicated.
IPv4 multihoming 
In order to be multihomed to the Internet through the use of BGP, a network must have its own public IP address range and a public AS number. Then connections to two (or more) separate ISPs are established. The routing over these connections is normally controlled by a BGP enabled router.
In the case where one outgoing link from the multihomed network fails, outgoing traffic will automatically be routed via one of the remaining links. More importantly, other networks will be notified, through BGP updates of the multihomed network routes, of the need to route incoming traffic via another ISP and link.
A key pitfall in multihoming is that two apparently independent links, from completely different ISPs may actually share a common transmission line and/or edge router. This will form a single point of failure and considerably reduce the reliability benefits from multihoming.
Another problem to look out for is that multihoming too small a network may not be effective since route filtering is very common among BGP users and larger prefixes (smaller networks) may be filtered out. This will make multihoming fail.
IPv6 multihoming 
Current solutions 
- Provider Independent Address Space is available in IPv6. This technique has the advantage of working like IPv4, supporting traffic balancing across multiple providers, and maintaining existing TCP and UDP sessions through cut-overs. Critics say that the increased size of routing tables needed to handle multi-homing in this way will overwhelm current router hardware. Proponents say that new hardware will be able to handle the increase due to cheaper memory, which drops in price according to Moore's law. Proponents also say this is the only viable solution right now, and the worse is better philosophy supports the idea that it is better to deploy an imperfect solution now than a perfect solution after it's too late.
Because many ISPs filter out route announcements with small prefixes, this will generally require a large "ISP-sized" IP allocation, such as a /32, to ensure global reachability. Using such large prefixes is an inefficient use of IPv6's address space; there are only about 4 billion /32 prefixes. However, from a pragmatic perspective, allocating a /32 is equivalent in global address space cost to allocating a single IPv4 address, and this may be acceptable if, as seems to be likely for the foreseeable future, the number of multihomed sites can be numbered only in the millions, as opposed to the many billions of non-multihomed endpoints which are anticipated to comprise the vast majority of IPv6 endpoints. Some RIRs such as RIPE has started to allocate /48 from a specific prefix for this purpose. RIPE allocate IPv6 PI /48s or shorter from 2001:0678::/29.
Other current possibilities 
- Automated renumbering. If one uplink goes down, all addresses in the network will be renumbered into a new /48 subnet. DNS and firewall records must be updated to redirect traffic to a different /48 subnet. This renumbering will break live TCP and UDP sessions.
- Maintaining multiple simultaneous sets of host addresses, from different upstream /48's for each host, and using multiple AAAA records. This works in most cases, but has the disadvantage that DNS and firewall records must be updated to redirect traffic to the correct set of IP addresses if one of the links goes down. Since this also changes IP addresses on failure, it will still break live TCP and UDP sessions.
Mono-homing applies if users are affiliating with a single platform. From consumers’ perspective, using a single platform requires lower cost and effort – once an upfront and once an ongoing cost – compared to multiple platforms because using additional platforms lead to further expenses like additional adoption, training or even the opportunity cost of time. Hence, platform operators need to understand the needs of their users in order to position and price their products accordingly.
Potential future solutions 
- Site Multihoming by IPv6 Intermediation
- Host Identity Protocol
- Stream Control Transmission Protocol
- Locator/Identifier Separation Protocol
- Identifier/Locator Network Protocol
See also 
- The Media independent handover or vertical handover standard IEEE 802.21
- Mobile IP
- Load balancing
- Two-sided market
IPv4 multihoming 
- O'Reilly article on BGP Multihoming
- Elfiq Networks' introduction to multihoming though link balancer appliances without BGP
- Cisco multihoming configuration example
- Windows Multihoming example for Single Link, Multiple IP address (Link down as per 2009 Jan 28, see the internet archive for a cached version)
- XRoads Networks' methods for implementing non-routing protocol multihoming
IPv6 multihoming 
- Ecessa article on multihoming
- Old IETF IPv6 multihoming working group
- Current IETF IPv6 multihoming working group
- Internet-Draft: Analysis of IPv6 Multihoming Scenarios
Further reading 
- Akella, A.; Maggs, B.; Seshan, S.; Shaikh, A.; and Sitaraman, R. (2003). "A measurement-based analysis of multihoming". Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM '03): 353–364. doi:10.1145/863955.863995.
- De Launois, C.; Bagnulo, M. (2006). "The paths toward IPv6 multihoming". IEEE Communications Surveys & Tutorials 8 (2): 38–51. doi:10.1109/COMST.2006.315853.
- Hau, T.; Burghardt, D.; and Brenner, W. (2011). "Multihoming, content delivery networks, and the market for Internet connectivity". Telecommunications Policy 35 (6): 532–542. doi:10.1016/j.telpol.2011.04.002.