Multihoming refers to a computer or device connected to more than one
computer network. It can be used, for example, to increase the reliability of
an Internet Protocol network, such as a user served by more than one Internet
service provider. 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 = The host has multiple IP addresses, but
only one physical upstream link. When the single link fails, connectivity is
down for all addresses. = Multiple Interfaces, Single IP address
per interface = The host has multiple network interface
controllers 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
may 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
Stream Control Transmission Protocol 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 performance by making use of every available network interface.
= Multiple Links, Single IP address = This is what is generally meant by
multihoming. With the use of a routing protocol, in most cases Border Gateway
Protocol, the end-site announces this address space to its upstream links.
When one of the links fail, 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 = This approach uses a specialized Link
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.
Caveats While multihoming is generally used to
eliminate network connectivity as a potential single point of failure,
certain implementation caveats apply which can affect the success of such a
strategy. In particular, to eliminate the network
single point of failure: 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 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. Multihoming can complicate interface
administration. One technology that helps is the Consistent Network Device
Naming convention of Linux. IPv4 multihoming
To be multihomed to the Internet using BGP, a network must have its own public
IP address range and a public Autonomous System number. Then connections to two
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 may be filtered out.
IPv6 multihoming As of 6 February 2010, multihoming in
the next-generation Internet Protocol was not yet standardized.
= 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 regional Internet registrys such as RIPE
have started to allocate /48 from a specific prefix for this purpose. RIPE
allocates IPv6 provider-independent address spaces /48 or shorter from
2001:0678::/29. = Other 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 solutions = Site Multihoming by IPv6 Intermediation
Host Identity Protocol Stream Control Transmission Protocol
Locator/Identifier Separation Protocol Identifier/Locator Network Protocol
See also Dual-homed
The media independent handover or vertical handover standard IEEE 802.21
Mobile IP Load balancing
Two-sided market References
External links = 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 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.. "A
measurement-based analysis of multihoming". Proceedings of the 2003
conference on Applications, technologies, architectures, and
protocols for computer communications: 353–364. doi:10.1145/863955.863995.
De Launois, C.; Bagnulo, M.. "The paths toward IPv6 multihoming". IEEE
Communications Surveys & Tutorials 8: 38–51. doi:10.1109/COMST.2006.315853.
Hau, T.; Burghardt, D.; and Brenner, W.. "Multihoming, content delivery networks,
and the market for Internet connectivity". Telecommunications Policy
35: 532–542. doi:10.1016/j.telpol.2011.04.002.