A Summary of Proposals to Support Multi-Homing for IPv6

The notes on various approaches are non-exclusive, i.e. solutions not reviewed or mentioned here are not ruled out of discussion. Also the review comments are not comprehensive, and the selection reflects the time constraints of the contributors to this section than any qualitative judgment on any of the approaches. The author is desirous, in future revisions of this draft, in augmenting this selection of reviewed approaches.

HIP is an ID/Locator separation mechanism intended to solve a much wider problem space than site multi-homing. HIP uses cryptographic identifiers termed Host Identity Tags (HITs) at the application layer, which are mapped to locators (IP Addresses) by a HIP protocol stack layer that interfaces between the transport layer and IP internetwork layer. The essential characteristic of HIP is its use of opportunistic identity generation, as it uses a cryptographic host identifier as the basis of the persistent identity. The transport session can be agile across locators, or even across IP protocol versions, as the HIT is used to determine session integrity, allowing the hosts to determine what packets legitimately form part of the session. HIP is proposed as a new protocol element, located at layer 3.5 (i.e. above the internetwork IP layer and below the transport layer). The presentation to the transport layer uses 128 bit hash values (the HIT) in place of IP addresses, while the presentation to the internet layer uses conventional IP addresses. Being opportunistic and unstructured, the HIT space is not an efficient search space, nor can a HIT be used as a unique search key. HITs are part of an equivalence function, to allow each host to determine that an incoming packet is part of an established session. HITs cannot be used as an identity value in a conventional referral sense (HostA wants to tell HostB to talk to HostC). While an application could pass a HIT to a third-party (and legacy applications would unknowingly do so), the third party would have no way to map that HIT to a locator (an IP address) as HIP does not include any global HIT->Locator mapping mechanism. Summary: New Protocol Stack Element Layer 3.5 (Above IP, below Transport Unstructured, opportunistic identity values (non-referential) DNS rendezvous No Locator exchange protocol Current IETF Documents: draft-moskowitz-hip-arch draft-moskowitz-hip draft-nikander-hip-mm draft-nikander-esp-beet-mode

NOID proposes an approach for endpoint identifier and locator separation where the endpoint identifier space is drawn from the locator space. Instead of creating a new namespace for endpoint identifiers, the endpoint identifier may be chosen from the set of locators that can be used to reach a given endpoint. Until an event occurs that modifies the list of usable locators, the initial endpoint identifier value can serve as a locator. NOID uses next-header values in the IPv6 header to indicate whether a given packet should be processed by the NOID layer. At a conceptual level, NOID adds a layer to the middle of IP above most IP processing, but below IPSec, fragmentation and reassembly functions. NOID makes use of the global DNS as a mapping system between IDs and Locators. A node who wishes to communicate with another node can use the FQDN to get a list of possible locators (IP Addresses). That node will then choose one of the locators to use as an Application-level ID (AID). NOID offers some support for application referrals. If Host A passes an AID to Host B that is supposed to point to Host C, Host B should be able to do a reverse DNS lookup to map the AID to an FQDN and then use the FQDN to get the complete set of locators. However, for this to be effective, nodes would need to have both forward and reverse DNS entries. There might also be a need to dynamically update the DNS as a node becomes reachable or unreachable at certain locators. Summary: New Protocol Stack Element Layer 3 (Inserted in the upper part of IP, below IPSEC and fragmentation / reassembly Identity values based on locator set DNS rendezvous Identity peering protocol Current IETF Documents: draft-nordmark-multi6-noid draft-templin-isnoid

CELP explores the concept of sharing information about locator reachability between transport-layer "multi-addressing" mechanisms (such as SCTP and DCCP) and Internet-layer multi-addressing mechanisms, referred to in the draft as "wedge-layer approaches" (such as NOID). (This concept was originally discussed on the MULTI6 mailing list under the name 'SLAP'.) The motivation behind CELP is that multiple multi-addressing mechanisms may be used (by different applications or for different connections) on a single endpoint, and that it would beneficial for those mechanisms to share information about the reachability of the IP addresses in a given locator pool. If a transport-layer mechanism, such as SCTP, could share its knowledge regarding the reachability of a certain locator, it might be possible to minimize or eliminate Internet-layer control packets that are used to maintain that information at the Internet layer. In some ways, this is similar to IPv6 Neighbor Discovery's use of upper layer advice regarding neighbor reachability to avoid sending unnecessary ND packets. This document offers a definition of the term "endpoint" that refers to a locator pool that may have a smaller scope than an entire IP node (i.e. a given locator pool may only contain a subset of the locators available on an IP node). The CELP document is more of a consideration of approach than an actual proposal for a solution. It doesn't specify in detail how it would work with any particular transport-layer or Internet-layer multiaddressing mechanisms. However, it is an approach that could be applied to many combinations of solutions. Summary: Considerations relating to sharing locator reachability information across session instances. Current IETF Documents: draft-crocker-celp

WIMP is an endpoint identifier / locator separation protocol that is heavily focused on mitigating the threats outlined in work in progress on security threats in multi-homing scenarios [draft-nordmark-multi6-threats-00.txt]. The WIMP approach uses divided secrets and hash chaining to ensure that new locators are supplied by the same node that supplied the original locator. WIMP uses a separate name space for 128-bit non-routable IDs that are never used in packets on the network. These IDs are locally generated for both local and remote nodes by hashing a nonce (for the initiator's endpoint identity) or the FQDN (for the responder's endpoint identity). (The approach assumes a requirement that all responders will have a FQDN.) The WIMP protocol introduces a WIMP layer that maps between IDs and locators based on internal state. The WIMP layer is conceptually located within the network layer, above most IP processing and below IPsec, fragmentation/reassembly and destination options, similar to NOID. Communication between two end-points requires establishment of a WIMP session. Once the session is established, it can be used for multiple simultaneous or sequential connections to the same end-point. During WIMP session establishment, WIMP introduces a separate header into the data packets, between the IP and TCP/UDP headers that contains information about the WIMP session. The WIMP session establishment packets can optionally be piggy-backed on data packets. WIMP does not introduce a separate header into all IPv6 packets. Instead, once a WIMP session is established, the IPv6 FlowID is used to hold an identifier for the WIMP host-pair context associated with a given packet. WIMP is intended to provide a solution to some of the security concerns, particularly regarding connection hijacking, that have been raised for some other endpoint identity / locator separation mechanisms. Reviewers of WIMP have raised some questions of this approach, particularly concerning the use of an optional header while operating below IP fragmentation. The piggy-backing mechanism requires that the packets not be fragmented, but it doesn't explain how upper layers will become aware of the MTU limitations on those packets and/or how this mechanism would interact with Path MTU discovery. Like HIP, WIMP makes no provision to handle application-level referrals and does not contain a mechanism for global endpoint identifier to locator mapping. It has also been pointed out that it is interesting to consider whether the WIMP approach to security, hash chaining, could be applied to other endpoint identity / locator separations mechanisms, such as NOID. Summary: New Protocol Stack Element Layer 3 (Inserted in the upper part of IP, below IPSEC and fragementation / reassembly Identity values based on hash of FQDN Identity peering protocol Current IETF Documents: draft-ylitalo-multi6-wimp

Host-Centric Multihoming is, in some ways, the simplest way to address the IPv6 site multihoming problem. The concept is that every host in the multihomed site is configured with multiple prefixes that correspond to different service providers. Each host configures addresses within those prefixes and selects among those addresses when connecting to a remote host. This configuration is automated using Router Renumbering and IPv6 Address Autoconfiguration. However, this simple solution Layer 3 (inserted in the upper part of IP, below IPSEC and fragementation / reassembly has several practical limitations and drawbacks, and this draft attempt to address them. In particular, the Host-Centric Multihoming proposal attempts to address the "site exit issue". Hosts cannot control the exit path that their packets will take from the local site, so hosts with multiple addresses may use a source IP address from one ISP on packets that end-up being routed through a different ISP. In many cases, the ISPs will run ingress filtering and will discard those packets. One solution to the site exit problem is to changes the ISP ingress filters to accept all of the source address prefixes that are used within the site. Other approaches are to perform source-based routing within the site, to deploy a single site-exit router or to structure the network so that all exit routers are connected to a single DMZ network that employs source-based routing. A virtual DMZ can be constructed by configuring a mesh of tunnels between all exit routers, tunneling packets to the correct exit router based on source address. Each of these solutions has operational drawbacks and/or introduces inefficiencies. This proposal suggests another solution to the site exit problem called "source address discovery". Based on Path MTU discovery, this mechanism involves adding extra information to the ICMP Destination Unreachable message that the packet was discarded due to an ingress filter. This extra information indicates what address prefix should be used to pass the ingress filter. Rather than adding a field to the ICMP message, this extra information is communicated via the source address that the route Layer 3 (Inserted in the upper part of IP, below IPSEC and fragementation / reassembly). It also proposes a "superior" alternative called "exit router discovery", which allows hosts to specify which exit router will be used for each packet. Instead of sending ICMP error messages when ingress filtering causes packets to be discarded, the exit router will send the equivalent of a redirect message and future packets with the same source/destination address pair will be tunneled to the indicated exit router. This mechanism involves tunneling to a site-exit anycast address that is derived from the sites' prefixes. The draft primary focuses on the specification of this "superior" approach, largely ignoring some pertinent questions such as: Will residential and enterprise-level IPv6 routers really support anycast routing? One important thing to note about the host-centric multihoming solution is that it doesn't appear to provide any ability for transport connections to survive a change in the topology that causes a host to become unreachable at an address that is currently used as a connection end-point. It also does not offer any support for legacy applications that do application-level referrals, requiring that a full set of locators be exchanged as part of the referral.

This section summarizes a set of selected ID/Loc separation documents. The selection includes documents that appear to be active, and this section provides a very short summary of each one. The first sub-section lists documents that are new or updated since IETF 58 and the second sub-section lists older documents that remain active. The documents in each sub-section are listed alphabetically by draft filename.

TLC-FM: Transport Layer Common Framework for Multihoming draft-arifumi-multi6-tlc-fm This draft proposes a transport-layer mechanism for ID /Locator mapping. There is a conceptual layer within the transport layer that provides support for common multihoming functions. It is compatible with the use of Mobile IPv6 (MIP6) to provide mobility support. In TLC-FM, like SCTP, the ID consists of a collection of locators that may be used to reach a given host. It employs transport-level clues (such as TCP retransmissions) to decide when to switch locators. For UDP connections, ICMP error messages or application-level hints are necessary. This mechanism is not well enough specified to fully evaluate it, but it doesn't appear to offer any support for application-level referrals. Multi-Homing Tunnel Broker (MHTB) draft-bagnulo-multi6-mhtb This document defines an enhancement to RFC 3178, IPv6 Multihoming Support at Site Exit Routers, to reduce the administrative overhead of maintaining a configured tunnel for each multihoming association. However, this draft does not address another major drawback of the RFC 3178 approach, that it does not protect against the complete failure of one or more connected ISPs. Framework for Common Endpoint Locator Pools (CELP) draft-crocker-celp Dave Crocker and Avri Doria's CELP draft, reviewed in the previous section. Multi-Homing: the SCTP Solution draft-coene-multi6-sctp This document does not form a complete proposal in that it consists of a number of answers to issues raised in the work-in-progress "Things MULTI6 Developers Should Think About" draft, and does not fully address how SCTP could be a complete approach for multi-homing. An interesting aspect of this approach is that it claims that SCTP is not an ID/Loc separation mechanism, although the state defined by the group of available IP addresses plays the role of an identity, and the locator is whichever address is currently being used for communication. SCTP also experiences the same complexities as other proposals (AKA NOID, CELP) that use a pool of locators as the ID -- How do you choose which locator to use? And how do you detect when a member of the pool becomes invalid for use as a locator? SCTP may provide some useful experiences and mechanisms that may apply to a class of possible solutions. Host Identity Protocol (HIP) Rendezvous Mechanisms draft-eggert-hip-rendezvous-00.txt This is an overview draft that discusses the concept of HIP rendezvous mechanisms to improve the applicability of HIP for mobility and multihoming. This is a survey document that outlines the problem and discusses different type of solutions to the problem. Host-Centric IPv6 Multihoming draft-huitema-multi6-hosts Draft by Christian Huitema and others, described above. Things MULTI6 Developers Should Think About draft-lear-multi6-things-to-think-about Eliot Lear's efforts to collect a set of practical questions that should be considered for all MULTI6 protocols. Host Identity Protocol (HIP) draft-moskowitz-hip This is the base protocol specification for HIP. Along with the HIP architecture, these documents form the basis of the HIP work. Consideration on HIP Based IPv6 Multi-Homing draft-nikander-multi6-hip Pekka Nikander's document that submits HIP as a solution for the MULTI6 problem space. 8+8 Addressing for IPv6 End to End Multihoming draft-ohta-multi6-8plus8 Threats Relating to Transport Layer Protocols Handling Multiple Addresses draft-ohta-multi6-threats Multihoming Using IPv6 Addressing Derived from AS Numbers draft-savola-multi6-asn-pi This draft provides a mechanism for organizations that have been assigned a 16-bit AS number to use that number to auto-generate a globally routable, provider-independent address prefix. Problem Statement: HIP Operation over Network Address Translators draft-stiemerling-hip-nat Summarizes the problems with running HIP and IPsec-based data transmission across NATs. Operational Approach to Achieve IPv6 Multihomed Network draft-toyama-multi6-operational-site-multihoming This document proposes to support site multihoming in IPv6 by assigning additional /32 prefixes and AS numbers to "groups" of providers who will provide multihomed /48 prefixes to their mutual customers. It is currently unclear to the reviewer how/if this proposal would work and/or scale since it seems to involve two different providers advertising the same /32 and the same AS number into the default free zone. It requires some type of peering "to share prefix assignments" between ISPs, and the diagram shows some type of connection between the ISPs, but I don't know what the details of that connection are. It also has the potential to more quickly exhaust the AS number space and to result in a substantially larger number of routes in default free routers, since the number of "groups" could scale exponentially with the number of providers. Crypto Based Host Identifiers (CBHI) draft-van-beijnum-multi6-cbhi This draft defines a crytographic mechanism for generating host identifiers. It is intended for use with other protocols that require host identifiers, such as ODT (see below). On Demand Tunneling for Multihoming (ODT) draft-van-beijnum-multi6-odt This draft discusses an automatic tunnelling-based solution for multihoming. Weak Identifier Multihoming Protocol (WIMP) draft-ylitalo-multi6-wimp WIMP proposal, described above.

RFC 3582: Goals for IPv6 Site-Multihoming Architectures Choices for Multiaddressing draft-crocker-mast-analysis What's In a Name: Thoughts from the NSRG draft-irtf-nsrg-report A Roadmap for Multihoming in IPv6 draft-kurtis-multi6-roadmap Host Identity Protocol (HIP) Architecture draft-moskowitz-hip-arch-05.txt End-Host Mobility and Multi-Homing with Host Identity Protocol (HIP) draft-nikander-hip-mm Threats Relating to IPv6 Multihoming Solutions draft-nordmark-multi6-threats-00.txt Multihoming without IP Identifiers (NOID) draft-nordmark-noid Erik Nordmark's NOID specification, described above.

This is a list of ID/Loc separation and/or MULTI6 documents, listed alphabetically by draft name. Extension Header for Site-Multi-homing Support draft-bagnulo-multi6-mhexthdr Application of the MIPv6 Protocol to the Multi-Homing Problem draft-bagnulo-multi6-mnm Multiple Address Service for Transport (MAST): An Extended Proposal draft-crocker-mast-proposal NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering draft-de-launois-multi6-naros Application and Use of the IPv6 Provider Independent Global Unicast Format draft-hain-ipv6-pi-addr-use Simple Dual Homing Experiment draft-huitema-multi6-experiment-00.txt Host-Centric IPv6 Multihoming draft-huitema-multi6-hosts IPv4 Multihoming draft-ietf-multi6-v4-multihoming This documents how multi-homing is supported at present in the IPv4 protocol domain. Multihoming in IPv6 by Multiple Announcement of Longer Prefixes draft-kurtis-multihoming-longprefix Multihoming using 64-bit Crypto-based IDs draft-nordmark-multi6-cb64 Strong Identity Multihoming using 128-bit Identifiers (SIM/CBID128) draft-nordmark-multi6-sim IPv6 Address Assignment and Route Selection for End-to-End Multihoming draft-ohira-assign-select-e2e-multihome Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site draft-ohira-multi6-multilink-auto-prefix-assign Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site draft-ohira-multi6-multilink-auto-prefix-assign The Architecture of End to End Multihoming draft-ohta-e2e-multihoming-05.txt 8+8 Addressing for IPv6 End to End Multihoming draft-ohta-multi6-8plus8-00.txt Threats Relating to Transport Layer Protocols Handling Multiple Addresses draft-ohta-multi6-threats-00.txt Multihomed ISPs and Policy Control draft-ohta-multihomed-isps-00.txt GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6 draft-py-multi6-gapi Multi Homing Translation Protocol (MHTP draft-py-multi6-mhtp-01.txt Multihoming Using IPv6 Addressing Derived from AS Numbers draft-savola-multi6-asn-pi-01.txt IPv6 Site Multihoming: Now What? draft-savola-multi6-nowwhat Operation of NOID Multihoming Protocol on ISATAP Nodes draft-templin-isnoid LIN6: A Solution to Multihoming and Mobility in IPv6 draft-teraoka-multi6-lin6 Operational Approach to achieve IPv6 multihomed network draft-toyama-multi6-operational-site-multihoming-00.txt Two Prefixes in One Address draft-van-beijnum-multi6-2pi1a-00.txt Crypto Based Host Identifiers draft-van-beijnum-multi6-cbhi-00.txt Provider-Internal Aggregation based on Geography to Support Multihoming in IPv6 draft-van-beijnum-multi6-isp-int-aggr-01.txt On Demand Tunneling For Multihoming draft-van-beijnum-multi6-odt-00.txt