"SiMIA" - Multihoming using IPv6

  Development
"SiMIA" (Site Multihoming and Provider-Independent Addressing) is an approach to ease administation, to avoid renumbering on ISP changes, and to allow flexible multihoming in IPv6 networks.

Motivation

As long as provider-independent addresses are deprecated to ensure scalability, the required site renumbering on the change of an Internet service provider (ISP) is an integral problem in IPv6 adaptation. Second, site multihoming is a required feature for today's companies and organisations to ensure highly-available Internet connectivity.

Both multihoming and Internet service provider migration are not satisfactorily solved for IPv6. These are reasons for the delay in the adaptation of the protocol version. The "SiMIA" concept addresses both of the two stated problems while retaining the advantages of strictly hierarchical addressing and therewith route aggregation.

Description

Using IPv6, a company or organisation ("site" in the following) gets address space from each of its ISPs. This means that each host in the network has multiple addresses: at least a link local address and one address out of the address space of each ISP. This leads to several issues:

  1. Administrators have to configure access lists and firewall rules for all these different addresses. Complexity is increased and troubleshooting becomes more difficult.
  2. If a site wants to migrate to a new ISP, IP addresses within the whole site network need to be changed. Despite auto configuration features, such a renumbering is a complex and laborious task. Thus, such tasks tend to be avoided which leads to lock-in effects.
  3. When an ISP is no longer available, existing TCP connections break, and each host needs to detect the problem and reestablish a connection using another source address. There is no multihoming transparent to hosts.
  4. Centrally managed traffic engineering for distributing the traffic amongst the available ISPs is not possible easily.
Multihoming example

The proposed solution works as follows:

So called "Unique Local Addresses" that are intended to be used instead of the deprecated IPv6 site local addresses are employed as globally unique, provider-independent host identifiers. Each host has several IPv6 addresses associated in the domain name system: such a unique local address and a globally routable address from each ISP. These addresses only differ in the prefix - the host part can and should be identical.

Within the site's network, only the unique local addresses are assigned to the interfaces of the hosts. Access lists and firewalls also just use unique local addresses; globally routable addresses are not configured on them.

At the edge of the site, the so called site-exit routers map unique local address from the inside to corresponding globally routable addresses on the ISP side. This mapping makes the packets routable in the Internet.

If a hosts wants to connect to another host, it queries the DNS for the peer's address. The source address for the connection will be the unique local address of the connecting host. The destination address will be the unique local address of the peer host (address selection based on longest matching prefix). Thus the packet originating from the host has unique local addresses for source and destination.

When the packet reaches the site exit router, both addresses are mapped to corresponding globally routable addresses. The packet is routed normally through the Internet to the destination site. There, the site exit router maps the globally routable addresses back to the corresponding unique local addresses. Within the destination site, again only unique local addresses are used. The destination host gets the packet with the same addresses that have been present when the source host sent it. Thus the mappings done are transparent to the hosts so that the end-to-end model is not broken.

The mappings that need to be performed by the site exit routers are just mappings of the network prefix. This is a very simple form of network address translation. But in contrast to other proposals, the translation is done on both sites here so that the communicating hosts do not take notice of it. Even better, no changes at all are required on hosts to use the "SiMIA" concept.

As the mapping is done at site exit routers, traffic engineering can be performed there, e.g. routing VoIP traffic via one ISP and other traffic via another. Adding and removing an ISP just requires changing DNS entries and configuring the ISP at the site exit routers. Within a site, globally routable ISP addresses are not used so that there is no need for renumbering and configuring multiple addresses in access lists and firewalls. Further more, the "SiMIA" concept is compatible to current Internet standards and simple compared to other IPv6 multihoming proposals.

The prefix mapping at the site exit routers is scalable. Security is a concern there to avoid the possibility of redirecting traffic to other networks by poisoning the mapping tables with invalid data. This can be done by querying the mappings from the domain name system (DNSsec is preferred). Client puzzles can be used as a measure to counteract denial-of-service attacks. Some further considerations are required on how compatibility to sites that do not employ the concept is guaranteed without sacrificing the end-to-end concept. In sum, "SiMIA" is a very promising approach that just needs some more refinement to become applicable on a large scale.

Implementation

A student of mine created a demonstrator to prove the applicability of the concept. He implemented the prefix mappings on top of the Linux Netfilter architecture and simulated a real network using a number of communicating virtual machines.

References

Update (2011)

The SiMIA concept uses "Network Prefix Translation" of source and destination IPv6 addresses on the edges of both involved sites. Due to the dual translation, the translation becomes completely transparent to the communication endpoints. The needed Network Prefix Translation for IPv6 ("NPT6"; a special form of a generic "NAT66") is now published in RFC 6296: IPv6-to-IPv6 Network Prefix Translation