[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                         C. Huitema
Internet-Draft                                                 R. Draves
Expires: August 10, 2004                                       Microsoft
                                                              M. Bagnulo
                                                                    UC3M
                                                       February 10, 2004


                     Host-Centric IPv6 Multihoming
                     draft-huitema-multi6-hosts-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 10, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   A way to solve the issue of site multihoming is to have a separate
   site prefix for each connection of the site, and to derive as many
   addresses for each hosts. This approach to multi-homing, which we
   call Host-Centric IPv6 Multihoming, has the advantage of minimal
   impact on the inter-domain routing fabric, since each site prefix can
   be aggregated within the larger prefix of a specific provider;
   however, it opens a number of issues, which we will discuss in this
   memo, including the problem created by the interaction between
   ingress filtering and multihoming. We then propose a set of specific
   solutions that enable host centric multihoming, and we review how



Huitema, et al.         Expires August 10, 2004                 [Page 1]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   these solutions meet the goals of IPv6 site multihoming.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Notations  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1   Requirements language  . . . . . . . . . . . . . . . . . . .  5
   2.2   Reference topology . . . . . . . . . . . . . . . . . . . . .  5
   2.3   Site exit router . . . . . . . . . . . . . . . . . . . . . .  5
   2.4   Ingress filtering  . . . . . . . . . . . . . . . . . . . . .  5
   2.5   Site exit anycast identifier . . . . . . . . . . . . . . . .  6
   2.6   Site exit anycast address  . . . . . . . . . . . . . . . . .  6
   3.    Host-Centric IPv6 Multihoming issues . . . . . . . . . . . .  7
   3.1   Destination address selection  . . . . . . . . . . . . . . .  7
   3.2   Source address selection . . . . . . . . . . . . . . . . . .  7
   3.3   The site exit issue  . . . . . . . . . . . . . . . . . . . .  8
   3.4   Rapid reaction to topology changes . . . . . . . . . . . . .  9
   4.    Analysis of solutions to the site exit issue . . . . . . . . 10
   4.1   Relaxing the source address checks . . . . . . . . . . . . . 10
   4.2   Source address dependent routing . . . . . . . . . . . . . . 11
   4.3   Source address selection by the host . . . . . . . . . . . . 13
   4.4   Packet rewriting at exit router  . . . . . . . . . . . . . . 15
   4.5   Comparison of the site exit solutions  . . . . . . . . . . . 16
   5.    Analysis of solutions to provide rapid reaction to
         topology changes . . . . . . . . . . . . . . . . . . . . . . 18
   5.1   Path selection when establishing a new communication . . . . 18
   5.1.1 Externally initiated communications  . . . . . . . . . . . . 18
   5.1.2 Internally initiated communications  . . . . . . . . . . . . 18
   5.2   Preserving established communications  . . . . . . . . . . . 23
   6.    Integrating Solutions  . . . . . . . . . . . . . . . . . . . 24
   6.1   Solution 1: Relaxing source address checks + Intra site
         routing system based exit path selection . . . . . . . . . . 24
   6.2   Solution 2: Source address Discovery + Intra site
         routing system based exit path selection . . . . . . . . . . 24
   6.3   Solution 3: Packet Rewriting at site exit + Intra site
         routing system based exit path selection . . . . . . . . . . 25
   6.4   Solution 4: Host based exit path selection + source
         address based routing  . . . . . . . . . . . . . . . . . . . 26
   6.5   Solution 5: Host based exit path selection + site exit
         discovery  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   6.6   Solution 6: Hybrid approach + source address dependent
         routing  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   6.7   Solution 7: Hybrid approach + source address selection
         by the host  . . . . . . . . . . . . . . . . . . . . . . . . 27
   6.8   Remaining combinations . . . . . . . . . . . . . . . . . . . 28
   7.    Proposed solution  . . . . . . . . . . . . . . . . . . . . . 29
   7.1   Multihoming solutions for small sites  . . . . . . . . . . . 29
   7.1.1 Step 1: preserving functionality for legacy hosts when



Huitema, et al.         Expires August 10, 2004                 [Page 2]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


         becoming multihomed. . . . . . . . . . . . . . . . . . . . . 29
   7.1.2 Step 2: Optimizations to enhance the multihoming support . . 31
   7.2   Multihoming solution for medium sites  . . . . . . . . . . . 36
   7.2.1 Reaction to topology changes . . . . . . . . . . . . . . . . 36
   7.3   Multihoming solution for big sites . . . . . . . . . . . . . 37
   8.    Evaluation of Host centric solution and Multihoming Goals  . 39
   8.1   Capabilities of IPv4 Multihoming . . . . . . . . . . . . . . 39
   8.1.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 39
   8.1.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 40
   8.1.3 Performance  . . . . . . . . . . . . . . . . . . . . . . . . 40
   8.1.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
   8.1.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 40
   8.1.6 Transport-Layer Survivability  . . . . . . . . . . . . . . . 40
   8.2   Additional Goals . . . . . . . . . . . . . . . . . . . . . . 40
   8.2.1 Scalability  . . . . . . . . . . . . . . . . . . . . . . . . 40
   8.2.2 Impact on Routers  . . . . . . . . . . . . . . . . . . . . . 41
   8.2.3 Impact on Hosts  . . . . . . . . . . . . . . . . . . . . . . 41
   8.2.4 Interaction between Hosts and the Routing System . . . . . . 41
   8.2.5 Operations and Management  . . . . . . . . . . . . . . . . . 41
   9.    Things MULTI6 Developers should think about  . . . . . . . . 42
   9.1   The Answers  . . . . . . . . . . . . . . . . . . . . . . . . 42
   9.1.1 Routing  . . . . . . . . . . . . . . . . . . . . . . . . . . 42
   9.1.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 42
   9.1.3 On The Wire  . . . . . . . . . . . . . . . . . . . . . . . . 42
   9.1.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 44
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 49
   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 50
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
         References . . . . . . . . . . . . . . . . . . . . . . . . . 52
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
         Intellectual Property and Copyright Statements . . . . . . . 54




















Huitema, et al.         Expires August 10, 2004                 [Page 3]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


1. Introduction

   There are two basic forms of multihoming, multiple interfaces per
   host and multiple site connections shared by many hosts. This working
   group is specifically concerned with site multi-homing. A way to
   solve the issue of site multihoming is to have a separate site prefix
   for each connection of the site, and to derive as many addresses for
   each hosts; this can in fact be supported by a combination of router
   renumbering (RFC2894) and Stateless Address Autoconfiguration
   (RFC2462). This approach to multi-homing, which we call Host-Centric
   IPv6 Multihoming, has the advantage of minimal impact on the inter-
   domain routing fabric, since each site prefix can be aggregated
   within the larger prefix of a specific provider; however, it opens a
   number of issues, which we will discuss in this memo, including the
   problem created by the interaction between ingress filtering and
   multihoming. We then propose a set of specific solutions that enable
   host centric multihoming, and we review how these solutions meet the
   goals of IPv6 site multihoming.

































Huitema, et al.         Expires August 10, 2004                 [Page 4]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


2. Notations

2.1 Requirements language

   In this document, the key words "MAY", "MUST", "MUST  NOT",
   "optional", "recommended",  "SHOULD",  and "SHOULD  NOT",  are to be
   interpreted as described in [13].

2.2 Reference topology

   In the following discussion, we will use this reference topology:

             /-- ( A ) ---(      ) --- ( C ) --\
   X (site X)             ( IPv6 )              (Site Y) Y
             \-- ( B ) ---(      ) --- ( D ) --/


   The topology features two hosts, X and Y, whose respective sites are
   both multi-homed. Host X has to global IPv6 addresses, which we will
   note "A:X" and "B:X", formed by combined the prefixes allocated by
   ISP A and B to "site X" with the host identifier of X. Similarly, Y
   has two addresses "C:Y" and "D:Y".

   We assume that X, when it starts engaging communication with Y, has
   learned the addresses C:Y and D:Y, for example because they were
   published in the DNS. We do not assume that the DNS is dynamic: there
   will be situations in which both C:Y and D:Y are published, while in
   fact only one is reachable. We assume that Y, when it receives
   packets from X, has only access to information contained in the
   packet coming from X, e.g. the source address; we do not assume that
   Y can retrieve by external means the set of addresses associated to
   X.

2.3 Site exit router

   A site exit router is an IPv6 router managing at least one of the
   connections between a site and the Internet.

2.4 Ingress filtering

   Ingress filtering refers to the verification of the source address of
   the IP packets at the periphery of the Internet, typically at the
   link between a customer and an ISP. This process, which is described
   in [9] is intended to thwart a class of denial of service attacks in
   which attackers hide their identity by using a "spoofed" source
   address.





Huitema, et al.         Expires August 10, 2004                 [Page 5]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


2.5 Site exit anycast identifier

   A 7 bit anycast identifier whose value is XX. [TBD IANA]

2.6 Site exit anycast address

   An IPv6 anycast address built by combining an IPv6 address prefix
   allocated to the site with the site exit anycast identifier,
   according to the rules specified in [RFC2526]. The proposed used of
   this anycast address is detailed in section 5.









































Huitema, et al.         Expires August 10, 2004                 [Page 6]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


3. Host-Centric IPv6 Multihoming issues

   Host-Centric IPv6 Multihoming forces hosts to choose the source and
   the destination address of the IPv6 packets, in a way that makes the
   best usage, or at least a reasonable usage, of the network resource.
   Hosts must first select a destination address, and will then perform
   source address selection. Source address selection must be consistent
   with ingress filtering, which is sometime implemented at network
   interfaces: we call this the "site exit" issue. Destination address
   selection is often based on incomplete or obsolete information, which
   can be harmful if, for example, hosts fail to notice that one of the
   site's connections is suddenly made unavailable. In any case, we must
   also consider "low budget" hosts, and make sure that these hosts can
   get some benefits from multihoming without enduring too much cost.

3.1 Destination address selection

   It is fairly common for hosts to have to choose between multiple
   destination addresses for a peer. TCP performs this choice when the
   connection is instantiated; SCTP may perform similar choices through
   the life-time of the connection; UDP may perform this choice either
   for each packet, or at the beginning of an association. We may debate
   whether hosts have sufficient information to perform a valid choice,
   and it is a complex debate. Some very simple appliances probably
   never will have any information; large servers potentially have tons
   of information available; personal computers are somewhere in
   between. It is not unrealistic to expect progress in this area,
   either by communication between the hosts and the routers, by sharing
   of experience between hosts, or maybe by innovative application
   design that would for example implement a file transfer by parallel
   retrieval of fraction of the file from multiple sources. At worst, a
   host can always try the proposed addresses one by one, and pick the
   first one that actually works -- not very elegant, but definitely
   workable.

3.2 Source address selection

   The source address selection in most hosts immediately follows the
   destination address selection. When a host has multiple interfaces,
   the normal procedure is to select the destination address, then
   identify the interface over which packets bound to that address will
   be routed, and finally select a source address associated to that
   interface. When the host has multiple addresses attached to an
   interface, which is the case with host centric IPv6 multihoming, the
   host could in theory pick any of these addresses, or at least any of
   those that have an appropriate scope. In our example topology,
   supposing that X has selected the destination address "C:Y", it can
   choose as source address either "A:X" or "B:X".



Huitema, et al.         Expires August 10, 2004                 [Page 7]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   Choosing the source address will affect the reverse path of the
   connection, as the source address of the message will become the
   destination address of the responses. This may be a serious matter in
   asymmetric applications like web access, in which the bulk of the
   data is sent by the server to the client. If the multiple addresses
   correspond to different ISP, the hosts should normally pick the
   source address that will provide the best performances. As for
   destination address selection, we may expect that the host will have
   some knowledge of the effect of choosing one or the other address,
   for example by observing that web pages are served faster through one
   address than through the other.

3.3 The site exit issue

   A special complication appears when the ISPs who serve the multihomed
   site perform "source address selection." In our generic
   configuration, we assume that X is served by ISP A and B, and thus
   can be reached by the addresses A:X and B:X. We also we assume that Y
   is served by ISP C and D, and thus can be reached by the addresses
   C:Y and D:Y. To communicate with Y, X will choose the destination
   address that appears to be easier to reach, for example D:Y; then, it
   will choose the source address that provides the most efficient
   reverse path, say A:X.

   Suppose now that the ISP connections at Site X are managed by two
   different site exit routers, RXA and RXB, and that there is a similar
   configuration at Site Y, with routers RYC and RYD.


             /-- ( A ) ---(      ) --- ( C ) --\
           (RXA)          (      )            (RYC)
   X (site X)             ( IPv6 )              (Site Y) Y
           (RXB)          (      )            (RYD)
             \-- ( B ) ---(      ) --- ( D ) --/


   Within Site X, the interior routing will decide which of RXA or RXB
   is the preferred exit router for the destination "D:Y"; similarly,
   within Site Y, the interior routing will decide which of RYC or RYD
   is the preferred exit for destination A:X. If the chosen exit router
   at Site X is RXA, the packet will flow freely to RYD; If the chosen
   exit router at Site Y is RYD, the response will also flow freely.
   However, if the exit routers are RXB or RYC, and if the ISPs perform
   ingress filtering, we have a problem: ISP B sees a packet coming from
   RXB, whose source address does not match the prefix assigned by B to
   X; ISP C, similarly, sees a packet whose source address does not
   match the prefix assigned by that ISP to Y. If either of these ISPs
   decides to drop the packet, the communication will be broken.



Huitema, et al.         Expires August 10, 2004                 [Page 8]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


3.4 Rapid reaction to topology changes

   Network conditions change over time. In order to meet the performance
   requirement, we must allow the use of the best path at any time; In
   order to meet the "redundancy" requirement, we have to make sure that
   if a network connection breaks, the corresponding prefix is not used
   as either a source or a destination address.

   We may assume that the destination address selection algorithm
   mentioned in 3.1 will naturally result in the selection by X of an
   appropriate address for Y; X may for example try in turn the
   addresses C:Y and D:Y, and retain the address for which a response
   comes back. However, we must make sure that X selects a source
   address that will be reachable: for example, if the link to ISP A
   fails, X must make sure that it uses as source address B:X, not A:X.




































Huitema, et al.         Expires August 10, 2004                 [Page 9]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


4. Analysis of solutions to the site exit issue

   The site exit issue is caused by ingress filtering at the site
   egress. In this section, we will analyse four ways to solve the
   issue: somehow relax the source address check, implement source
   address dependent routing, ask hosts to pick "the right" source
   address, or ask routers to somehow rewrite the packets so that it can
   pass the source address checks. We will then compare the proposed
   solutions, in order to prepare a recommendation.

4.1 Relaxing the source address checks

   An obvious way to avoid failures due to ingress filtering is to
   simply make sure that all the addresses used by the hosts of a given
   site will be considered acceptable by each of the site's providers.
   In our site X example, that would mean that provider A would accept
   addresses of the form "B:X" as valid, and that provider B will in
   turn accept addresses of the form "A:X" as valid.

   One way to achieve this is simply to ask the service provider to turn
   off source address checks on the site connection. This requires a
   substantial amount of trust between the provider and the site, as
   source address checks are in effect delegated to the site routers.
   One possible way to achieve this trust is to make sure that the site
   routers, or possibly the site firewalls, meet a quality level
   specified by the provider.

   Another way to achieve this relaxed level of checking is to check
   source addresses against a list of "authorized prefixes" for the site
   connection, rather than simply the single prefix delegated by the
   provider. This solution requires that the site communicates the
   authorized prefixes to the provider, either through a management
   interface or through a routing protocol. This is obviously more
   complex than simply lifting the controls, and in fact ends up with a
   very similar requirement of trust: the provider has to believe that
   the site will transmit the right prefixes.

   A special case occurs when the site exit is an "automatic tunnel"
   interface, such as 6to4 or Teredo. Source address control for
   automatic tunnels is delegated to the "other side" of the tunnel, in
   practice to a very large number of relay routers located across the
   Internet. Checks are based on the correlation between the IPv6 source
   address and the IPv4 source address used in the tunneling protocol.
   Asking each potential end of the tunnel to relax its checks is not
   realistic; in practice, this means that the exit routers will have to
   obtain the right to use as source address a privileged IPv4 address,
   such as the 6to4 anycast address; this will imply a negotiation with
   the provider of the IPv4 service.



Huitema, et al.         Expires August 10, 2004                [Page 10]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   In conclusion, relaxing the source address checks requires some form
   of explicit trust between the site and its providers. There is no
   doubt that this level of trust will exist in many cases; there is
   also no doubt that there will be many cases in which the provider is
   unwilling to grant this trust, particularly in the case of small
   sites, such as for example home networks dual-homes to a DSL provider
   and a cable network provider.

4.2 Source address dependent routing

   Another solution to the site exit problem is to perform some kind of
   source routing within the site, so that the site exit is effectively
   a function of the source address in the packet. Current routers
   generally do not implement any kind of source address dependent
   routing; this implies that this solution would have to be "rolled in"
   progressively in the site, following a generic schema such as:


                 Multiple site exits
                 |     |     |     |
            -----+-----+-----+-----+-----
           (                             )
           ( Source based routing domain )
           (                             )
            ----+----+----+----+----+----
           (                             )
           (   Generic routing domain    )
           (                             )
            -----------------------------

   In this schema, all site exit routers are connected to a source based
   routing domain. Packets initiated in the generic routing domain and
   bound to an "out of site" address are passed to the nearest access
   point to the source based routing domain, using classic "hot potato"
   routing. The routers in the source based routing domain maintain as
   many parallel routing tables as there are valid source prefixes, and
   would choose a route that is a function of both the source and the
   destination address; the packets exit the site through the "right"
   router. There are multiple possible implementations of this general
   concept.

   The simplest implementation is to have only one exit router for the
   site; this exit router chooses the exit link on the basis of the
   source address in the packet. This simple implementation might be
   adequate for very small sites, but introduces a single point of
   failure, and thus fails to meet the "redundancy" requirement of
   multihoming.




Huitema, et al.         Expires August 10, 2004                [Page 11]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   In the most complex set up, each router of the site would maintain as
   many parallel routing tables as there are valid source prefixes, and
   would choose a route that is a function of both the source and the
   destination address. This solution enables "shortest path" routing
   and can provide an arbitrary level of redundancy. However,
   maintaining parallel routing tables requires a massive re-engineering
   of routers and routing protocols, and thus would be hard to deploy in
   the short term.

   A slightly less complex implementation is to connect all exit routers
   to the same link, e.g. to what is often referred to as the "DMZ" for
   the site. This solution requires that all routers connected to the
   DMZ are upgraded to perform source address based routing. This
   configuration is less fragile than a single router solution; however,
   the single link requirement seems to preclude "geographic redundancy"
   between the site exits. It does requires the re-engineering of some
   routers, but not necessarily all routers of the site. In practice, it
   could be a way to "phase in" the most complex setup described in the
   previous paragraph.

   A much simpler alternative is to establish a mesh of "tunnels"
   between the site exit routers. A site exit router that receives a
   packet bound for an out-of-site address would perform a source
   address check before forwarding the packet on one of its outgoing
   interfaces; if the source address check is positive, the packet will
   effectively be sent on the interface; if it is not, the packet would
   be "tunneled" to a more adequate router.

   The main requirement of the tunneling alternative is that site-exit
   routers be able to perform address checks, and that each site exit
   router be able to associate to each valid site prefix the address of
   a corresponding site exit router. An obvious possibility is to
   configure prefixes and corresponding addresses in each router; it
   would however be preferable to derive these addresses automatically.
   A strong assumption of the IPv6 architecture is that all prefixes of
   a site will have the same length; it is thus possible to derive a
   prefix from the source address of a "misdirected" packet, by
   combining this prefix with a conventional suffix. The suffix should
   be chosen to not collide with the subnet numbers used in the site; a
   null value will be inadequate, since it could be matched by any
   router with knowledge of the prefix, not just the site exit router; a
   value of "all ones" could be adequate.

   In order to enable tunneling, each router managing a site prefix will
   then inject a "host route" for its locally managed prefixes in the
   interior routing protocol. Site exit routers performing automatic
   tunneling can then use the standard routing procedures to detect
   whether the anycast address corresponding to the prefix in use is



Huitema, et al.         Expires August 10, 2004                [Page 12]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   reachable; they can automatically reject, rather than tunnel, packets
   whose source address does not correspond to a reachable anycast
   address.

   An inconvenience of the set-up is that some packet will follow a less
   than direct path; we will see in the next section how that could be
   palliated by host based processing.

   Source based routing allows for a large diversity between the site
   exits; it also allows for host based policy decision, since a host
   can influence the routing of a packet by choosing the appropriate
   source address. There is however one drawback of any source address
   based scheme, the impossibility to use "asymmetric" path between two
   sites:


             ..................................>
            ./-- ( A ) ---(      ) --- ( C ) --\...
     .....>(RXA)          (      )            (RYC)....>
   X (site X)             ( IPv6 )              (Site Y) Y
     <.....(RXB)          (      )            (RYD)<....
           . \-- ( B ) ---(      ) --- ( D ) --/...
            <...................................


   Using source based routing implies that if the host X chooses the
   source address B:X, then its packets will exit through router RXB,
   never through RXA. This may provide lesser performances if a link is
   congested in one direction but not in the other. However, source
   based routing would allow four paths, A-C, A-D, B-C and B-D, thus
   providing an adequate redundancy and allowing a great deal of
   performance optimization.

4.3 Source address selection by the host

   The site exit issue would be mitigated if the hosts chose a source
   address that would be compatible with the exit point chosen by the
   routing protocol, or alternatively if the host tunneled the packet
   directly to an adequate exit router.

   The first alternative could be called "source address discovery". In
   many ways, source address discovery is similar to path MTU discovery.
   The two issues are similar: packets that do not meet some criteria
   fixed by the network are dropped; the host has to find the cause of
   the loss, and to take action in order to make sure that these packets
   will be accepted. In the path MTU case, the action is to use shorter
   packets; in the ingress filtering case, the action is to present a
   different source address.



Huitema, et al.         Expires August 10, 2004                [Page 13]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   To implement source address discovery, the hosts would have to
   introduce a "preferred source address" parameter in the "destination
   cache" mentioned in the Neighbor Discovery standard [3]. The primary
   purpose of the cache is to link a destination address to a next hop
   neighbor; it is also the repository of per-destination parameters
   such as the path MTU; it is the natural repository for the new
   parameter. The source prefix in the destination cache would be used
   during source address selection, to select an available interface
   address that matches the prefix.

   As for path MTU discovery, source address discovery requires that the
   hosts receive some information from the network. Such information can
   be conveyed in an ICMP Destination Unreachable error message with
   code 5 which means source address failed ingress policy [18]. The
   router is supposed to send such message when the packet is discarded
   because of ingress filtering issues. The error message contains
   information about the packet that triggered the error. However, the
   host will also need information about the source address prefix that
   should be used to pass the source address check. The proposed format
   of the error message does not includes such information. However, a
   proper choice of the source address by the router that generates the
   message can provide a good substitute. This means that the router
   that generates the error message will have to include the prefix that
   complies with the ingress filtering in the source address of the
   packet that carries the error message. The host will then select the
   source address to be used for the selected destination by performing
   a longest prefix match between the source address contained in the
   error message and the potential source addresses. In the absence of
   an explicit ICMP message, the hosts would have to rely on a trial an
   error process, noticing that packets get dropped and trying
   retransmissions with alternate source addresses; the experience of
   path MTU discovery shows that such processes are awkward and error
   prone.

   An alternative to source address discovery is "exit router
   discovery", i.e. the discovery by the source of the preferred exit
   router for a given source address. This requires a slightly different
   change to the caches used in neighbor discovery, specifically the
   management of a "source exit cache" that associates a specific source
   address with an exit router, or maybe the combination of a
   destination address and a source address with an exit router. As with
   source address discovery, this would be learned through an ICMP
   message; this message would not be an error message, but rather a
   variation of the redirect message. After receiving such messages, the
   host will tunnel to the specified exit point the packets sent from
   the source address to the destination; the exit point will
   decapsulate these packets and send them over the appropriate exit
   link.



Huitema, et al.         Expires August 10, 2004                [Page 14]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   The "exit router discovery" procedure appears to be superior to the
   "source address discovery." Both solutions require approximately the
   same amount of resource in the host, but the exit router discovery
   has two advantages: it enables hosts to actually specify the point of
   exit from the site, thus giving them a greater amount of "policy
   control".

   We should note that neither "source address discovery" nor "exit
   router discovery" are implemented in current hosts. In order to
   accomplish the goal expressed in [7] that hosts implementing the
   current version of IPv6 can continue to operate in a multi-homed
   site, even if they would not take advantage of multihoming; in
   consequence, these procedures can only be used as an optional
   optimization.

4.4 Packet rewriting at exit router

   In section 4.2, we explained how a site exit router that discovers
   that a packet bound out of the site has the "wrong" source address
   can route the packet to an alternative exit. Another way to pass the
   source the source address check is to modify the packet, which could
   in theory be done by replacing the source address or by encapsulating
   the packet using "IPv6 in IPv6".

   In fact, replacing the source address is not necessarily a good idea,
   since this will remove information from the packet; it also requires
   some level of cooperation between the exit router and the host, if
   only to understand what alternative source addresses can be used by
   the host, if any.

   One could preserve the information by encapsulating the packet in a
   new IPv6 header, using "IP in IP". The source address of the new
   header will be the address used by the router on the exit interface,
   the destination address will be the original destination, and the
   payload type will be set to "IPv6." After the insertion of the
   option, the outgoing packet will have the following values:

   * outer IPv6 header source address: address of the site egress
   interface,

   * outer IPv6 header destination address: from initial packet,

   * outer IPv6 header payload type: "IPv6",

   * inner IPv6 header source address: source address of initial packet,

   * inner IPv6 header destination address: from initial packet,




Huitema, et al.         Expires August 10, 2004                [Page 15]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   * inner IPv6 header payload type: payload type of initial packet,

4.5 Comparison of the site exit solutions

   The four solutions that we have reviewed have different advantages
   and inconveniences. The may differences are in terms of
   deployability, generality, redundancy, policy control, and impact on
   existing hosts, i.e. minimal implementations of IPv6 that would use
   only one of the available prefix for the site, that would not perform
   any more sophisticated logic than picking a destination address at
   random among multiple alternatives, and that would not understand any
   additional IPv6 option or any additional ICMP message.

   The relaxation of source address checks detailed in 4.1 is easy to
   deploy, and would not affect minimal hosts. It is a perfectly
   reasonable solution for large sites, i.e. the sites that benefit of
   IPv4 multihoming today: it should not be more complex to convince a
   provider to relax address checks for a particular customer tomorrow,
   than to convince today a similar provider to advertise in its routing
   table the global IPv4 address of the site. If we choose this
   solution, we should choose its simplest implementation, i.e. one in
   which the provider completely delegates source address checks to the
   site's router or firewalls. This is however not a general solution,
   since we cannot expect all sites to convince every provider to relax
   their checks.

   The rewriting at exit routers appears to be an inferior solution. It
   is not really easier to implement than the "tunneling" variation of
   source routing at the exit sites: if a router can detect that a
   source address does not pass the checks for a proposed interface, and
   if it can encapsulate the packet before forwarding it, then it could
   just as well tunnel the packet to the "correct" exit router for the
   site. Tunneling the packet to its final destination actually has a
   larger impact on the existing hosts than simply tunneling the packet
   to another router: we have to assume that the destination host is
   willing to accept tunneled packets, which is not an obvious
   proposition. Since the packet is tunneled, the destination host has
   to trust that the source address in the encapsulated packet is
   genuine; in the absence of an authentication header, this is risky
   proposition.

   When the source address checks cannot be relaxed, the best solution
   is probably to perform some kind of source address based routing to
   the adequate exit router. In the long term, the IETF may develop
   internal routing protocols that take into account the source address
   as part of the "reachability information" for a set of destinations;
   in the short term, there are no such protocols, and we have to rely
   on a tunneling mechanism between site exit routers.



Huitema, et al.         Expires August 10, 2004                [Page 16]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   Exit router discovery is a natural complement of the tunneling
   mechanism between site exit routers. When an exit router tunnels a
   misdirected packet towards another exit, it may send an appropriate
   "exit redirection" ICMP message. If the host is a minimal IPv6 host,
   the ICMP message will be ignored; further packets will continue using
   the same slightly sub-optimal path. On the other hand, if the host
   has been upgraded to take advantage of multi-homing, the packets will
   be tunneled to the appropriate exit router; they will follow a direct
   path to this router.










































Huitema, et al.         Expires August 10, 2004                [Page 17]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


5. Analysis of solutions to provide rapid reaction to topology changes

   In order to fulfill the "redundancy" requirement, a multihoming
   solution has to provide the means to identify the available exit
   paths towards a given destination and carry packets through it. In
   other words, a mechanism to detect unavailable exit paths is
   required, so that they are not used. We will analyze the different
   mechanisms to perform the path selection in two situations: path
   selection when establishing a new communication and path selection
   during the lifetime of a communication. These two problems are quite
   different, since the timing requirements are different in the two
   situations and also requirements imposed in the addresses to be used
   are different.

5.1 Path selection when establishing a new communication

5.1.1 Externally initiated communications

   We will first analyze the mechanism used by hosts outside the
   multihomed site to select among the paths to the multi-homed site. We
   have already assumed that the multihomed site will have as many
   prefixes as ISPs, and that it will assign multiple addresses to every
   host that will benefit from multihoming. It is also assumed that
   those addresses will be announced through the DNS.

   So, when an external host tries to establish a communication, it will
   first obtain all the host's addresses from the DNS. Then it will try
   to use one of them and if it succeeds the communication is
   established; and if not, it will try with the next address.
   Considering that each address is routed through one and only one
   provider, the selection of an address implies the selection of a
   provider, then it implies the selection of a incoming path to the
   multihomed site. So, for external hosts, incoming path failure
   detection and incoming path selection is already being performed by
   the external host itself and the provided capabilities are enough to
   provide support to the multihomed environments. When the host within
   the multihomed site replies to the incoming packet, both the
   destination and the source addresses are already determined, so no
   selection has to be performed by the host in the multi-homed site.
   Moreover, since the incoming packet has reached the host within the
   multihomed site, and assuming that some mechanism to guarantee
   ingress filtering compatibility mechanism is being used, the exit
   path will be the same than the ingress path, so it is likely to be
   working properly.

5.1.2 Internally initiated communications

   We will next analyze the mechanisms required within the multihomed



Huitema, et al.         Expires August 10, 2004                [Page 18]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   site to select among the multiple path connecting the site to the
   Internet. When a host within the multihomed site sends a packet to a
   given external destination address, the exit path through which the
   packet will be routed has to be selected. In order to select a path
   two mechanisms are needed: a mechanism to discover the available
   paths and a mechanism to route the packets through the path
   identified as available. We have two elements that may perform these
   tasks: the routing system and the host itself.

   We will analyze the following possibilities:

   The first possibility is to let the intra-site routing system perform
   both tasks.

   The second possibility presented is to let the host do both tasks.

   The third possibility is to use the routing system to identify the
   available paths and to use a mechanism in the host to force the
   routing of packets through the identified path.

   The fourth possibility where the host identifies the available path
   and the routing system routes the packet through the path identified
   by the host doesn't seems a reasonable approach to us, so it will not
   be included in our analysis.

5.1.2.1 Exit path selection by the intra-site routing system

   One possibility is to let the intra-site routing system perform the
   complete exit path selection mechanism. In order to do that,
   intra-site routing system requires information about which
   destinations are reachable through each one of the exit paths. This
   means that each one of the providers has to inform the multi-homed
   site which destinations are reachable through him. Normally, the BGP
   protocol is used for this task. From the multihomed site perspective,
   there are two difficulties with this approach: first, the amount of
   information that is to be injected in the intra-site routing system
   is important and second, running the BGP protocol is more than a
   trivial task. While there are some medium-big multihomed sites that
   certainly can deal easily with these two issues, other smaller
   multi-homed sites may not deal with them so easily (imagine for
   instance a site consisting a few PCs on a single Ethernet and a
   single router connected to the Internet through a DSL access and a
   cable access).

   We can explore approaches to try to reduce the amount of routing
   information to be injected to the multi-homed site. The most
   aggressive approach would be to inject only a default route through
   each of the ISPs. This case works fine when one of the direct links



Huitema, et al.         Expires August 10, 2004                [Page 19]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   between the multihomed site and ISP fails, but, if we only want to
   provide protection for this specific case, RFC 3178 provides a
   solution that it is simpler overall since it deals with all the
   problems for this particular case (like ingress filtering, transport
   survivability, etc). So, since we are looking for a solution that
   provides better fault tolerance capabilities than RFC 3178, we need
   more information to be injected to the intra-site routing system.

   We need then alternatives that allow us to obtain better fault
   tolerance. A possible approach is to filter the accepted routes based
   on the AS path length, as proposed in [12]. By this mechanisms, the
   multihomed site would only accept routes with an AS path attribute
   whose length is no longer than x ASes. This approach allows reducing
   the amount of routing information while still achieving a high level
   of fault tolerance. The value of x is a trade-off between the two of
   them. As more routing information is injected into the site (higher
   x), better path selection will be performed and better fault tolerant
   capabilities will be provided by the solution, but at the same time
   more resources will be needed within the multihomed site. However,
   configuring filters raises the difficulty of running BGP, requiring
   additional BGP expertise in the end-site, making the adoption of this
   solution harder for small unmanaged sites.

5.1.2.2 Host based exit path selection

   An alternative to intra-site routing system exit path selection is to
   move exit path selection to the host itself. In order to enable the
   host to perform the exit path selection, two mechanisms are needed: a
   mechanism to discover available paths and a mechanism to enable the
   host to force the routing of packets through the selected exit path,
   overruling intra-site routing system routing.

5.1.2.2.1 Mechanisms to force the routing of packets.

   A possible mechanism to let the host force the path of the packets is
   to make a tunnel directly to the exit router. In order to do that,
   the host must be able to discover the address of the exit router.
   Using an "Exit Router Discovery" ICMP message as presented in section
   4.3 would be an option. An alternative to tunnels could be the usage
   of routing headers. However this is considered an inferior solution
   since the routing header would be carried all along the path to the
   final destination even if it were not needed.

   Another mechanism to enable the host to select the exit path is
   available when some form of source address dependent routing is used
   within the multihomed site. As it has been presented in section 4.2,
   if each exit ISP is associated with one of the available prefixes,
   and source address dependent routing is used, selecting the prefix to



Huitema, et al.         Expires August 10, 2004                [Page 20]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   be included in the source address implies the selection of the exit
   ISP through which the packet will be carried. So, source address
   dependent routing can be considered as an option to allow the host to
   select the exit path.

5.1.2.2.2 Mechanism to discover available and unavailable paths

   A mechanism to identify available paths is just to let the host do
   trial and error procedure. That is, in order to reach a certain
   destination, the host tries every possible exit path. The procedure
   can be carried out either sequentially or in parallel, that is, the
   host can try with every path simultaneously or it can try with one
   path and if the chosen path fails then it tries with the next one.
   The benefits and drawbacks of these two approaches are clear: the
   sequential procedure may take longer to find the available path, but
   the parallel procedure consumes more resources since multiple packets
   are sent every time an available path has to be discovered.

   However, the implementation of a failure detection mechanism based on
   sending packets may be trickier than what it may seem. A possible
   approach could be to define a new protocol for detecting available
   paths that sends probe packets end to end. However, a solution that
   doesn't impose changes in hosts outside the multihomed site is
   preferred because it is easier to deploy. So, we have to use already
   available mechanisms. Among the available choices, we could use ICMP
   echo packets to detect path availability. The problem here is the
   wide adoption of ICMP filtering because security issues.

   The other available option is to use data packets as probes. The main
   problem here is that not all applications are bi-directional, so
   there may be cases when no packets will return but the path is
   available. However, we consider that an important number of
   applications are bi-directional, so we will explore this possibility
   (Note that we are not considering the multicast case here, where the
   unidirectional flows are more common). So, a path failure detection
   mechanism based on data packets stores the exit path information
   corresponding to a destination address in a cache, the Exit Path
   Cache. The information contained in this cache depends on the
   mechanism that is used to force the routing of the packet by the
   host. If the tunnel mechanism is used, the address of the exit router
   and the source address to be included are cached. If source address
   based routing is used, only the source address to be used is cached.

   So, when a packet is to be sent to a certain destination address, the
   Exit Path Cache is searched for an exit path corresponding to the
   destination address. If no exit path is found in the cache, the host
   has no knowledge about the available paths, so it has to start the
   failure detection procedure by sending packets through all the



Huitema, et al.         Expires August 10, 2004                [Page 21]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   available paths. As we have seen, such procedure can be performed
   sequentially or in parallel, but in any case packets will be sent
   through the available paths and the host will wait for replies. When
   the first reply is received (whether because packets through all
   available paths have been sent simultaneously or because packets
   through different exit paths have been sent and a timeout has
   occurred, so the packet has been retransmitted through an alternative
   destination), the exit path used is stored in the Exit Path Cache and
   following packets are sent through the same exit path. Exit Path
   Cache entries have a finite lifetime. An Exit Path Cache entry
   lifetime is extended every time that a packet is received coming from
   the corresponding exit path. When an Exit Path Cache entry lifetime
   expires, the failure detection procedure is performed when new
   packets arrive for such destination.

   A case that has to be considered is when no reply packets for a given
   destination are received from any exit path. Such behavior may have
   two causes: the application generates unidirectional traffic, so no
   packets are supposed to arrive or all the paths are down. In any of
   the two cases the mechanism can't do anything to select the exit
   path, so when such situation is detected, a random exit path has to
   be selected and used. So, an Exit Path Cache entry is generated with
   a random path and with a certain lifetime. When the lifetime expires,
   the failure detection mechanism is performed again, so that if the
   case was that all exit paths were down, the mechanism can detect when
   one of the paths is up again. Note that this would cause additional
   overhead for unidirectional applications, so the failure detection
   mechanism should not be performed very often i.e. the lifetime should
   not be very low.

5.1.2.3 Hybrid approach: Routing system based failure detection and host
        based exit path selection

   An alternative approach is to obtain the information about available
   paths from the routing system but let the host to force the routing
   of packets through the identified exit path. The benefit of this
   approach is that the routing information injection into the
   intra-site routing system is not required because the exit path is
   selected by the host.

   This hybrid approach requires a mechanism to convey the path
   availability information from the routing system to the hosts.
   Considering the amount of information involved, we consider that it
   is better to limit the path information stored in the hosts to the
   information concerning the paths that the host is currently using.
   There are two approaches that can be used at this point.

   One possible approach is to define a new protocol to let the host to



Huitema, et al.         Expires August 10, 2004                [Page 22]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   query a server for the correct exit path to be used to reach a
   certain destination, for example as defined in [16]. The server would
   have to be configured with enough information to answer those
   queries. For instance the server has to know all the BGP information
   that is received from each one of the ISPs, the associated prefix and
   the address of the corresponding exit router. So, when a host wants
   to initiate a communication with an unknown destination address, it
   queries the server and obtains the exit path to be used. Then the
   host itself forces the packet to be routed through the exit path.

   An alternative option is to let the exit routers to inform the host
   about the correct exit path to be used. In this case, only the exit
   routers are running BGP. So, when a host sends a packet to a new
   destination, it randomly selects the exit path. More likely, the host
   will randomly select a source address and won't tunnel the packet, so
   that the packet is carried to the default route. In case that the
   destination contained in the packet is not reachable through the ISP
   whose prefix has been included as source address, but the exit router
   knows because of BGP that it is reachable through an alternative exit
   router, the exit router will send an ICMP error message containing
   the exit path information back to the host.

   A particular case of this approach can be used when the failure has
   occurred in the direct link. In this case, the exit router can detect
   the outage and considering that no destination is reachable through
   this ISP, simply deprecate the prefix. This approach is only an
   optimization since it does not address the general case.

5.2 Preserving established communications

   Multiple solutions for preserving established communications have
   been proposed such as HIP, SIM, ODT, LIN6, MAST, NOID, CB64. Many of
   these approaches mainly focus on how to present an unchanged IP
   address to the upper layers through changes in the address used to
   actually reach the host. However, not only such mechanism is required
   in order to preserve established communications, but a mechanism to
   perform path selection is also required (both a mechanism to identify
   available paths and a mechanism to force the routing of packets
   through the identified path are required). Additionally, a mechanism
   to solve the site exit issue may be needed in those solutions.

   Next versions of this document will include an analysis of which
   mechanism can be used to select paths during the lifetime of a
   communication and how such mechanisms can interoperate with the
   proposed solutions.






Huitema, et al.         Expires August 10, 2004                [Page 23]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


6. Integrating Solutions

   In this section we will integrate solutions, combining a site exit
   issue solution with a path selection solution. Next, we will present
   what we consider to be the most natural combinations of a solution
   for the site exit issue and an exit path selection mechanism. Other
   combinations may be possible but they don't seem very natural so far.
   Perhaps future versions of this document will consider them if it
   seems appropriate.

6.1 Solution 1: Relaxing source address checks + Intra site routing
    system based exit path selection

   The site exit issue is addressed relaxing the source address checks
   at the ISP, since the required level of trust exists between the site
   and the ISPs. The exit path selection is addressed using BGP and
   injecting some of the information into the intra-site routing system.
   Since BGP expertise is available, appropriate filters can be
   configured.

   Requirements:

   - enough level of trust between the site and the ISPs in order to
   relax the source address check

   - enough expertise to run BGP and configure appropriate filters

   - enough resources to import part of the global routing table into
   intra-site routing system

   Suitable for: big/medium sites. The solution is not deemed suitable
   for small sites because of the required level of expertise and
   resources.

6.2 Solution 2: Source address Discovery + Intra site routing system
    based exit path selection

   The host generates packet with one if its source address and then the
   packet is routed according the information available at the
   intra-site routing. When the packet reaches the site border router,
   it verifies the source address. If the source address is compatible
   with the selected ISP, the packet is forwarded as it is, if not, the
   exit router discards the packet and sends an ICMP Destination
   Unreachable error message (code 5) back to host informing the
   appropriate source address for the selected destination.

   Requirements:




Huitema, et al.         Expires August 10, 2004                [Page 24]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   - enough expertise to run BGP and configure appropriate filters

   - enough resources to import part of the global routing table into
   intra-site routing system

   - Required modifications: all hosts within the multihomed site have
   to be modified to implement the processing of the ICMP error in order
   to work properly. Communications initiated by hosts within the
   multihomed not implementing such processing will fail when selecting
   the wrong source address. Those hosts will not obtain even the level
   of service they would obtain in a single homed site.

   Suitable for: big/medium sites The solution is not deemed suitable
   for small sites because of the required level of expertise and
   resources.

6.3 Solution 3: Packet Rewriting at site exit + Intra site routing
    system based exit path selection

   The host generates packet with one of its source address and then the
   packet is routed according the information available at the
   intra-site routing. When the packet reaches the site border router,
   it verifies the source address. If the source address is compatible
   with the selected ISP, the packet is forwarded as it is, if not, the
   exit router rewrites the source address of the packet with a new
   prefix compatible with the exit ISP.

   Requirements:

   - enough expertise to run BGP and configure appropriate filters

   - enough resources to import part of the global routing table into
   intra-site routing system

   - Required modifications: all hosts within the multihomed site have
   to be modified to implement a mechanism to recognize reply packets
   with modified destination address as valid replies to the initial
   packet. Communications initiated by hosts within the multihomed site
   not implementing such mechanism will fail when using a source address
   that is rewritten at site exit. Those hosts will not obtain even the
   level of service they would obtain in a single homed site. Additional
   modification in applications and/or external hosts may be required.

   Suitable for: big/medium sites The solution is not deemed suitable
   for small sites because of the required level of expertise and
   resources.





Huitema, et al.         Expires August 10, 2004                [Page 25]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


6.4 Solution 4: Host based exit path selection + source address based
    routing

   In this case, an exit path is determined by the source address
   selected included in the packet. So, the host can force the routing
   of a packet through an exit path just by selecting the source
   address. So, the host determines which paths are available by sending
   packets with different source addresses. If reply packets arrive, the
   path associated with the destination address included in the reply
   packet is available, so the address is introduced in the site exit
   path cache.

   Requirements:

   - Configuration of source address dependent routing. This can be
   configured site wide or just at the site exit routers. In the second
   case, a mesh of tunnels between of the site exit router has also to
   be configured

   - Required modifications: implementation of the path discovery
   mechanism in the hosts of the multihomed site in order to benefit
   from multihoming. Hosts not implementing such mechanism can configure
   a single source address and behave as they were in a single homed
   site. Source address dependent routing is supported by some router
   vendor.

   Suitable for: small sites While this solution may be adopted by
   medium and big sites, those sites may prefer other type of solutions
   based on BGP because policy issues. This solutions relies on hosts to
   implement policing, since the hosts themselves perform the path
   selection. Other solutions based on BGP enable policy configuration
   on router or in central servers. This last option is considered to be
   more scalable with respect to the number of hosts within the site,
   making it more attractive for medium and big sites.

6.5 Solution 5: Host based exit path selection + site exit discovery

   In this case, hosts within the multihomed site tries to discover the
   available exit path by generating packets with different source
   address. In the case that the exit ISP corresponds to the selected
   source address, the packet is forwarded through the ISP. If not, the
   packet is discarded and an ICMP error message containing the
   appropriate exit router is sent back to the host. The host then
   retries forcing the routing of the packet, tunneling it directly to
   the exit router. The host identifies available paths when it receives
   reply packets. The host then stores the information about the source
   address and optionally about the exit router to be used in the site
   exit path cache.



Huitema, et al.         Expires August 10, 2004                [Page 26]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   Requirements:

   - Required modifications: implementation of the ICMP error generation
   mechanism in the routers. Implementation of the path discovery
   mechanism and the processing of the ICMP error in the hosts.
   Communications initiated by hosts within the multihomed not
   implementing such mechanism will fail when using an incompatible
   source address. Those hosts will not obtain even the level of service
   they would obtain in a single homed site.

   Suitable for: small sites While this solution may be adopted by
   medium and big sites, those sites may prefer other type of solutions
   based on BGP because policy issues. This solutions relies on hosts to
   implement policing, since the hosts themselves perform the path
   selection. Other solutions based on BGP enable policy configuration
   on router or in central servers. This last option is considered to be
   more scalable with respect to the number of hosts within the site,
   making it more attractive for medium and big sites.

6.6 Solution 6: Hybrid approach + source address dependent routing

   In this case, a server or the exit router has the information about
   the correct site exit router and source address to be used for a
   given destination. So, the host within the multihomed site contacts
   the server and obtains the correct site exit router and the
   appropriate source address. Then the hosts sends packets with the
   appropriate source address so that it routed trough the correct exit
   router,

   Requirements:

   - enough expertise to run BGP and configure appropriate filters

   - enough resources to import part of the global routing table into
   intra-site routing system

   - Required Modifications: the exit router or a server has to inform
   the host about the correct source address. So both the router and
   hosts has to be modified to implement the mechanism

   Suitable for: medium and big sites The solution is not deemed
   suitable for small sites because of the required level of expertise.

6.7 Solution 7: Hybrid approach + source address selection by the host

   In this case, a server or the exit router has the information about
   the correct site exit router and source address to be used for a
   given destination. So, the host within the multihomed site contacts



Huitema, et al.         Expires August 10, 2004                [Page 27]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   the server and obtains the correct site exit router and the
   appropriate source address. Then the host sends packets with the
   appropriate source address tunneling it to the correct exit router,

   Requirements:

   - enough expertise to run BGP and configure appropriate filters

   - enough resources to import part of the global routing table into
   intra-site routing system

   - Required Modifications: the exit router or a server has to inform
   the host about the correct exit path. So both the router and hosts
   has to be modified to implement the mechanism

   Suitable for: medium and big sites The solution is not deemed
   suitable for small sites because of the required level of expertise
   and resources.

6.8 Remaining combinations

   The remaining combinations of site exit issue solutions with site
   exit path selections mechanism are considered no to naturally match
   together.

   For instance, it is considered that sites that obtain the level of
   trust required from its provider to relax the source address checks
   will prefer to run BGP to obtain the available path information
   rather than using a host based or hybrid approach.

   In source address dependent routing and in site exit discovery
   approaches to the site exit issue, it is the host itself who selects
   the exit path (using the source address or tunneling). This type of
   mechanism seems hardly compatible with intra-site routing system exit
   path selection, since it is no longer the intra-site routing system
   that selects the exit path but it is the host through the source
   address who performs that selection.














Huitema, et al.         Expires August 10, 2004                [Page 28]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


7. Proposed solution

   In order to implement the host centric multihoming solution, we must
   solve the issues presented in the previous section. In this section,
   we will present the recommended ways to solve the site exit issue and
   how to trigger rapid reactions to failures.

   We will next present different solutions for different scenarios. As
   we have concluded from our analysis presented above, different
   solutions have different requirements and are then suitable for
   different type of scenarios. We will consider three different
   scenarios:

   - multihoming for small sites

   - multihoming for medium sites

   - multihoming for big sites

7.1 Multihoming solutions for small sites

   It is not likely that small sites can obtain some form of source
   address check relaxation from their IPSs, so an alternative solution
   to deal with the site exit issue is to be used. It is also considered
   that in general, small sites don't have neither the expertise nor the
   resources required to run BGP, so an alternative mechanism to react
   to topology changes is required. We think that the host based
   approach is the mechanism that better suits the requirements of the
   small sites.

   We will next present a set of mechanism and tools to enable
   multihoming is small sites.

   The goal is to propose a roadmap to adopt multihoming that preserves
   existent functionalities and adds new functionalities progressively.
   This would allow legacy systems to keep on working exactly the same
   way they did before multihoming adoption and then add new features to
   enable multihoming benefits

7.1.1 Step 1: preserving functionality for legacy hosts when becoming
      multihomed.

   Suppose that a single homed site becomes multihomed. The problem here
   is that the site exit issue will affect communications of the newly
   multihomed site. So, the first step is to deploy a solution for the
   site exit issue as simple as possible that does not require updating
   the hosts of the site, and if possible does not requires updating
   other equipment. Using such solution, legacy hosts within the



Huitema, et al.         Expires August 10, 2004                [Page 29]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   multihomed site will work as if they were in a singlehomed site. That
   is, they will not obtain multihoming benefits, but at least they will
   not fail because of multihoming. This solution also allows then
   attaching legacy hosts to the site and they will work as if they were
   in a singlehomed site.

   In line with the analysis presented in the previous section, our
   recommendation is to enable multihoming by establishing tunnels
   between the site exit routers. In order to implement this solution,
   we must define a way to convey the site exit addresses to the various
   routers in the site; the simplest solution, which we propose here,
   uses an anycast address that is arithmetically derived from the
   sites' prefixes.

7.1.1.1 Site exit anycast address

   The site exit anycast address solution assumes that all of the sites
   prefixes have the same length L; it also assume that we can define a
   conventional "subnet" associated to the prefix. The proposed solution
   is to compose the anycast address by appending an "all 1" suffix to
   the site prefix:


            <----- L bits -----> <---- 128 - L bits ----->
            +-------------------+-------------------------+
            | Valid site prefix | 1111...............1111 |
            +-------------------+-------------------------+

                  -- Site exit anycast address --


   Each site exit router that can forward to the outside packets whose
   source address is derived from a specific site prefix will advertise
   reachability of the corresponding site exit anycast address through
   the routing mechanism.

7.1.1.2 Tunneling to the appropriate exit

   Site exit routers are expected to perform necessary source address
   checks before forwarding any packet on a site exit link. The site
   exit router must check the source address first, in order to avoid
   local packets being routed to a black hole. If the result of the
   check is positive, the packet will be forwarded. If the result is
   negative, the router will derive a "site exit anycast address" from
   the source address of the incoming packet. If the anycast address is
   unreachable, the incoming packet will have to be discarded. If the
   anycast address is reachable, the incoming packet will be tunneled
   towards that address.



Huitema, et al.         Expires August 10, 2004                [Page 30]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   It is accepted that tunneling mechanism introduces additional
   overhead, but it is recommended because its fast deployability.
   However, in the long run, a mechanism based on source address
   dependent routing will provide better performance. Such mechanism can
   be gradually deployed as presented in section 4.2

7.1.2 Step 2: Optimizations to enhance the multihoming support

7.1.2.1 Site exit router discovery

   A problem with the approach presented in the previous section is that
   packets may be routed through a suboptimal path, because they are
   initially routed towards a site exit router and if the source address
   doesn't match, this site exit will send the packet through a tunnel
   to an alternative exit router. This problem can be solved using a
   Site Exit Redirection ICMP message. This ICMP error would be
   generated by the site exit routers when they receive a packet whose
   source address doesn't match with the exit ISP. So, after forwarding
   the packet through a tunnel to the appropriate site exit, the router
   generates a Site Exit Redirection ICMP message to inform the
   originating host about the correct site exit router for this
   destination and source address combination.

7.1.2.1.1 Site Exit Redirection ICMP message

   Routers send site exit redirect packets to inform a host of a better
   exit path on the path to a destination.



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source prefix length      |     Redirection life time     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                     Site Exit Address                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-




Huitema, et al.         Expires August 10, 2004                [Page 31]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   IP Fields:

   Source Address: An address assigned to the router from which this
   message is sent.

   Destination Address: The Source Address of the packet that triggered
   the redirect.

   Hop Limit: 255

   Authentication Header: If a Security Association for the IP
   Authentication Header exists between the sender and the destination
   address, then the sender SHOULD include this header.

   ICMP Fields:

   Type: TBD, IANA

   Code: 0

   Checksum: The ICMP checksum.  See [14].

   Prefix length:  The length of the source address prefix, in bits,
   expressed as a 16 bit integer, transmitted in network order, i.e.
   most significant byte first.

   Redirection lifetime: The number of seconds during which the
   redirection should remain in effect, expressed as a 16 bit integer,
   in network byte order.

   Site Exit Address: An IP address of the preferred exit router to use
   for packets sent using as source address the IPv6 destination of this
   packet, or using any source address whose prefix matches the first
   "prefix length" bits of this packet's IPv6 destination.

   Possible options:

   Redirected Header: As much as possible of the IP packet that
   triggered the sending of the Redirect without making the redirect
   packet exceed 1280 octets.

7.1.2.1.2 Host behavior

   Hosts can be programmed to perform "exit router discovery", i.e.
   associate to a source and destination address pair the address of the
   preferred exit router, and then tunnel packets directly to that exit
   router. Hosts will learn the address of the exit router through ICMP
   "Site Exit Redirection" messages.



Huitema, et al.         Expires August 10, 2004                [Page 32]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   Any redirection message poses a potential threat, since it can be
   used by third parties to misdirect and possibly capture traffic. In a
   secure set-up, hosts will establish a security association with the
   exit routers, and will only accept Site Exit Redirection messages
   that are properly secured by an authentication header. In the absence
   of a security association, the host may perform a number of checks
   before accepting a Site Exit Redirection ICMP message:

   * check that the IPv6 source address corresponds to a local prefix;

   * check that the prefix length has a realistic value, e.g. at least
   48 bits;

   * check that the Site Exit Address matches the site prefix being
   redirected;

   * select a redirection life time that is the minimum of the ICMP
   value and a locally selected maximum duration.

   Since site exit discovery is a routing optimization, hosts should
   balance the routing gain with the possible security risk.

7.1.2.2 Rapid reaction to failures

7.1.2.2.1 Direct link failures

   In order to react to local failures, we must establish a
   communication channel that quickly signals these failures to the
   hosts. The logical channel to use is the "router advertisement"
   message, which the routers use to communicate to hosts the list of
   available prefixes. We propose here to use the "preferred" and
   "valid" flags in these prefixes to signal to hosts the addresses that
   should, or should not, be used as source address at any given time.

   This solution is sufficient when the site is composed of a single
   link; for more complex site, we propose to use the "router
   renumbering" mechanism to maintain an up-to-date list of available
   prefixes.

7.1.2.2.1.1 Use of Router advertisements

   The router advertisement messages are defined in [3]; their use for
   address configuration is defined in [4]. As specified in [3], the
   router advertisements include a variable number of Prefix Information
   parameters. Each Prefix Information parameter specifies:

   * an address prefix value,




Huitema, et al.         Expires August 10, 2004                [Page 33]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   * an "on-link" flag, used in neighbor discovery,

   * an "autonomous" flag, used for autonomous address configuration,

   * the "valid" lifetime,

   * the "preferred" lifetime.

   We propose to use the "preferred" lifetime to indicate whether
   addresses derived from the prefix can be used as source address in
   multihomed networks. When a prefix is temporarily not available
   routers MUST advertise a null preferred lifetime for that prefix.

   In conformance with section 5.5.4 of [3], the hosts will notice that
   the formerly preferred address becomes deprecated when its preferred
   lifetime expires. They will not use the deprecated addresses in new
   communications if an alternate (non-deprecated) address is available
   and has sufficient scope.

   Manipulating the preferred lifetime only solves part of our problem,
   since according to [3] the hosts should continue to use the "valid"
   source address in existing communications. To actually maintain the
   transport sessions that used the now unavailable link, we will need
   additional host improvements.

7.1.2.2.1.2 Use of Router Renumbering

   In order to advertise a null preferred lifetime for a specific
   prefix, the sites routers must be able to learn about that prefix. A
   possibility is to use the "Router renumbering" protocol [6][RFC2894]
   to pass this information. The protocol allows an authorized agent, in
   that case the egress site, to update the list of prefixes advertised
   by the site's routers. The protocol can be used to change parameters
   associated to a prefix, such as the preferred lifetime.

7.1.2.2.2 Reaction to other failures modes

   Based on the analysis presented in section 5 and 6, we recommend the
   adoption of a host based exit path selection mechanism to enable the
   hosts within the multihoming site to react to topology changes.

   Considering that we are recommending a solution for the site exit
   issue based on source address dependent routing, we can assume that
   the exit ISP is determined by the source address included in the
   packet. So, in order to force the routing of a packet through a
   particular ISP, the host only has to set the appropriate source
   address. As described in section 5, the proposed mechanism to
   identify available paths will be based on the trial and error



Huitema, et al.         Expires August 10, 2004                [Page 34]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   procedure.

   The following mechanism is to be implemented in host in order to
   react to topology changes.

7.1.2.2.2.1 Exit Path Cache

   An Exit Path Cache is created in the hosts. Each entry contain for a
   Destination Address, information about the corresponding Source
   Address and a lifetime.

   Exit Path Cache entry creation process:

   When the host receives a packet containing a Source Address SA and a
   Destination Address DA, the Exit Path Cache is searched for an entry
   that contains SA Destination Address field.

   - If such entry is found, the Source Address is verified.

   -- If the Source Address contains DA, then the lifetime of the entry
   is extended.

   -- If the Source Address is other than DA, then the cache entry is
   updated and DA is stored in the Source Address field. The lifetime of
   the entry is extended. (would this break some apps?)

   - If the entry is not found, the entry is created, with SA as the
   Destination Address and DA as the Source Address. The entry is
   blocked from changes for a certain period to avoid that multiple
   answers used in the next section produce suboptimal behavior. (the
   other option would be not to modify existent (valid) cache entries
   when packets with a different DA are received)

7.1.2.2.2.2 Initiating new communications

   When a host attempts to initiate a communication with a certain
   destination address D, it first verifies if an Exit Path Cache entry
   exists for that destination address D. If it does exists, the host
   obtains the source address to be used form it.

   If no entry exists for that destination address D, the host generates
   multiple packets, one per available source address, sends them and
   sets a timer.

   If a reply packet is received, the cache entry is created as
   described in the previous section. Following packets addressed to
   that destination will use the discovered source address if the
   applications does not sets the source address to be used.



Huitema, et al.         Expires August 10, 2004                [Page 35]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   If the timer expires before any packets containing D as source
   address are received, this may mean that there is no exit path
   available to reach destination D or that the application generates an
   unidirectional flow, so no packets are to be received. In any case,
   the issue cannot be addressed at this level, so the recommended
   behavior is that the host simply selects one source address S and use
   it for the packets addressed to destination D. In order to avoid the
   procedure to restart, a Exit Path Cache entry has to be created for
   this destination address, containing the selected source address.

7.1.2.2.2.3 Preserving established communications

   TBD

7.2 Multihoming solution for medium sites

   Medium sites are likely to be capable of running BGP but they may not
   be able to obtain enough trust from their ISP to relax the source
   address checks. So, medium sites could use the mechanisms proposed
   for small sites, but they are likely to benefit by integrating BGP in
   the multihoming solution.

   So, the recommended integration of BGP capabilities in the proposed
   small site solution basically affects the mechanism used to react to
   topology changes affecting non-direct links.

   This means that the solution for the site exit issue recommended for
   medium sites is also a mesh of tunnels as presented in section 7.2.1
   allowing a smooth transition to multihoming without interfering with
   the installed base within the multihomed site. Also, we recommend the
   usage of Neighbor Advertisement and Neighbor Renumbering to convey
   information about direct link outages by deprecating the
   correspondent prefix, as presented in section 7.2.2.1.1.

7.2.1 Reaction to topology changes

   The proposed solution requires that the site exit routers run BGP
   with their correspondent providers. By doing so, exit router have
   information about reachable destinations through their directly
   connected ISP. Moreover, through IBGP sessions with the other site
   exit routers, they have information about reachable destination
   through the other ISPs.

   An Exit Path Cache is created in the hosts. Each entry contains for
   each Destination Address, information about the corresponding Source
   Address and a lifetime.

   Exit path Cache entries are created when the host receives a packet



Huitema, et al.         Expires August 10, 2004                [Page 36]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   as described in section 7.2.2.1.2.1

   So when a host attempts to initiate a communication with a certain
   destination address D, it first verifies if an Exit Path Cache entry
   exists for that destination address D. If it does exist, the host
   obtains the source address to be used from it.

   If no entry exists for that destination address D, the host just
   selects one of the possible source addresses and includes it in the
   packet.

   When the packet reaches the site exit router the following situations
   are possible:

   1. The destination is reachable through this site exit router and its
   directly connected ISP and the source address contains the prefix
   corresponding to the connected ISP. In this case, the site router
   forwards the packet through its directly connected ISP.

   2. The source address contained in the packet corresponds to another
   exit router and the destination is reachable through the other site
   exit router (the one that corresponds to the source address). In this
   case, the router tunnels the packet to the correct site exit router
   and sends a Site Exit Redirection ICMP message (as defined in
   7.2.2.1.1) back to the host, so that the host can send following
   packets directly to the correct exit router.

   3. The destination is not reachable through the ISP that corresponds
   to the source address included in the packet, but it is reachable
   through another ISP. In this case, this packet has to be discarded
   and the host has to be informed that an alternative source address
   has to be used. The router then sends an ICMP Destination Unreachable
   Error message with code 5 (meaning source address failed ingress
   policy) back to the host, carrying in the source address the prefix
   that has to be used to reach the selected destination. A new Exit
   Path Cache entry is created containing the source and destination
   address.

   4. The destination is unreachable through any of the ISPs, so the
   packet is discarded and an ICMP Destination Unreachable error message
   is sent back to the host.

7.3 Multihoming solution for big sites

   A big site is likely to have enough expertise and resources available
   to run BGP. Also, it seems likely that a big site can obtain the
   required level of trust from its providers to relax the source
   address checks. So, big sites are likely to adopt a multihoming



Huitema, et al.         Expires August 10, 2004                [Page 37]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   solution based on these two mechanisms, the relaxation of source
   address checks and the usage of BGP and the intra-site routing system
   to select the exit path.

   Source address check relaxation allows a big site to become
   multi-homing without prejudice to legacy hosts within the multi-homed
   site. Those hosts can still work properly as if they were in a single
   homed site.

   BGP provides information about what path reaches the selected
   destination. However, in case that one of the ISPs is down, the
   corresponding address is unreachable, meaning that such address is
   not to be used as a source address by hosts within the multihomed
   site that establish new communications, because there is no route
   available for return packets. In this case, a similar (but
   simplified) mechanism to the one proposed in the previous section
   about reaction to topology changes for medium sites is to be used.
   This mechanism is simpler because no ingress filtering considerations
   are involved, so the situation described in point 2 in the section
   above is no longer relevant.































Huitema, et al.         Expires August 10, 2004                [Page 38]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


8. Evaluation of Host centric solution and Multihoming Goals

   The MULTI6 working group has elaborated a list of goals for a
   multi-homing solution that is detailed in [7]. In this section, we
   will review how the host centric approach to IPv6 multihoming meets
   these goals, which are distributed in two subsections: matching the
   capabilities of IPv4 multihoming, and meeting additional goals.

8.1 Capabilities of IPv4 Multihoming

8.1.1 Redundancy

   The solution presented here can provide protection against:

   o  Physical link failure,

   o  Logical link failure,

   o  Routing protocol failure,

   o  Transit provider failure, and

   o  Exchange failure.

   Basic redundancy is provided by the availability of multiple
   addresses, that can be tried in turn, and by a reliance on classic
   destination based routing protocols. We assume that if an address is
   reachable, the routing protocol will find a path that leads to it; at
   worst, the host will have to perform several transmission trials,
   using different addresses, until the destination is reached.

   On the reverse path, redundancy is based on the selection of an
   appropriate source address. The "preferred lifetime" mechanism allows
   even the simplest hosts to learn which addresses are robust enough to
   be used.

   Destination and source selection provide a protection against a
   failure of the site access link, which is catalogued in the goals as
   Physical link failure, or Logical link failure. The availability of
   multiple destination addresses provides a protection against Routing
   protocol failure, Transit provider failure, and Exchange failure on
   the forward path: the communication will succeed if at least one of
   the destination addresses can be routed. The protection against such
   failures on the reverse path is provided if multiple source addresses
   are tried.






Huitema, et al.         Expires August 10, 2004                [Page 39]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


8.1.2 Load Sharing

   An enterprise can distribute the inbound traffic by manipulating the
   "preference" associated to various addresses in the DNS, e.g. by
   using mechanisms such as MX records or SRV records.

8.1.3 Performance

   Performance enhancements can be obtained by appropriate development
   of destination address selection and source address selection
   algorithms.

8.1.4 Policy

   Classes of applications may be shifted to a specific provider by
   appropriate use of DNS records associated to specific services. For
   example, the NNTP traffic could be directed to the specific server
   "nntp.example.com", and the enterprise could decide to only advertise
   for that server an address provided by one of its providers.

   The Policy table defined in [15] allows to prefer a certain source
   address rather than others. Considering that the source address
   determines the exit path, the policy table allows to express the
   preferred exit path.

8.1.5 Simplicity

   Host centric multihoming is simple to deploy, since it does not
   require any cooperation between the site and its providers, or in
   fact between the various providers. The main requirement is to
   advertise an up-to-date list of prefixes in the router
   advertisements; this can be automated using the router renumbering
   protocol.

8.1.6 Transport-Layer Survivability

   TBD

8.2 Additional Goals

8.2.1 Scalability

   The host centric multihoming system does not impose any unreasonable
   requirements on the routing system: the sites use multiple addresses,
   but each of these addresses can be aggregated under the prefixes of
   their respective providers.





Huitema, et al.         Expires August 10, 2004                [Page 40]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


8.2.2 Impact on Routers

   In order to quickly signal to hosts any change in the sites'
   connectivity, the site routers should implement the "router
   renumbering" procedures, and the exit routers should be able to use
   that procedure if a physical or logical link becomes unavailable.
   Additionally, routers have to implement the new Site Exit redirection
   ICMP message and the proposed processing of the ICMP destination
   unreachable error message with code 5 (source address failed ingress
   policy).

8.2.3 Impact on Hosts

   The solution does not destroy IPv6 connectivity for a legacy host
   implementing [1], [2], [5] and other basic IPv6 specifications
   current in January 2004. Such hosts may not be taking the full
   benefit from multihoming; in particular, their transport connections
   may not survive the failure of a site connection. However, the
   preferred lifetime mechanism guarantees that after a re- homing
   event, the new connections of these basic hosts will follow an
   available path.

   Hosts will take better advantage of multi-homing if they implement
   better destination address and source address selection algorithms,
   exit router discovery. Each of these is a logically separate function
   that can be added to existing functions.

   The solution does not require changes to the socket API and/or the
   transport layer; such changes may however be required if the host
   wants to implement a combined selection of the source and destination
   addresses, which is an optional additional function. The solution
   allows host or application change to enhance session survivability.

8.2.4 Interaction between Hosts and the Routing System

   The interaction between a site's hosts and its routing system is
   limited to the normal processing of router advertisements.

   Upgraded host will be able to obtain additional information from the
   routing system through the newly defined ICMP messages.

8.2.5 Operations and Management

   It is possible to monitor and configure the multihoming system.







Huitema, et al.         Expires August 10, 2004                [Page 41]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


9. Things MULTI6 Developers should think about

   This section contains the answers to the questions contained in [17].

9.1 The Answers

9.1.1 Routing

9.1.1.1 How will your solution solve the multihoming problem?

   The Host-Centric Multihomig proposal addresses multiple of the
   multihoming issues. In particular, Host Centric multihoming proposal
   includes mechanisms to:

   - Solve the site exit issue

   - Select proper (reachable) addresses when establishing a
   communication

   - Perform policing

   The Host Centric multihoming proposal does not includes a proposal to
   preserve established communications through outages. However, The
   compatibility of Host Centric multihoming mechanisms with proposed
   solution to provide transport layer connection survivability will be
   analysed in future versions of the document.

9.1.1.2 Uniqueness

9.1.1.2.1 Does your solution address mobility?

   No.

9.1.2 Identifiers and locators

9.1.2.1 Does your solution provide for a split between identifiers and
        locators?

   No.

9.1.3 On The Wire

9.1.3.1 At what layer is your solution applied, and how?

   All the proposed mechanisms work at the IP layer.

   Is it applied in every packet?




Huitema, et al.         Expires August 10, 2004                [Page 42]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   No.

   If so, what fields are used?

   Some packets may require to be tunneled to the correct exit router,
   so an additional IPv6 header may be required.

9.1.3.2 Why is the layer you chose the correct one?

   Host Centric Multihoming basically uses tools that are already
   available in some form in current implementations. While some
   modifications are required, the goal is to reuse as much of the
   existent mechanisms as possible. So, the layer used is the layer
   where these mechanisms already reside.

9.1.3.3 Does your solution expand the size of an IP packet?

   The solution does not expand the size of the packet but is uses
   tunnels in some occasions, so we will analyze the impact of tunnels
   in fragmentation in this section.

   Some packets require to be tunneled to the correct tunnel. Two type
   of tunneling is used:

   - Tunnels between the site exit routers: when packets reach the exit
   router selected by the intra-site routing system, the exit router
   verifies whether the source address is compatible with ingress
   filtering defined by the directly connected provider. If not, the
   packet will be tunneled to the appropriate exit router. Such
   tunnelling imposes a reduced MTU. There are two was this can be
   handled. One option could be to announce a reduced MTU within the
   site, so that hosts just assume a 20 bytes smaller MTUs always and
   tunnel overhead doesn't impose additional fragmentation. The other
   option would be just to let the tunnel endpoint to fragment when
   needed.

   - Tunnels between the host and the site exit router: when the host
   learns the appropriate exit router through the ICMP Site exit
   redirection message, the host will tunnel packet directly to the exit
   router. Again, in this case the host may need to fragment the packets
   because of the tunnel overhead. It should be noted that packets will
   only be tunnelled once, whether between exit router or from the host
   to the exit router. In no case a packet will be tunneled twice
   because of the multihoming solution. Now, if the option to announce a
   20  byte smaller MTU within the site is adopted, it would be
   desirable that also the tunnels between the host and the exit router
   can use this reserved space. So an option could be to present the
   smaller MTU to the upper layers, but allow the tunnel interface to



Huitema, et al.         Expires August 10, 2004                [Page 43]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   send 20 bytes larger packets.

   Summarizing, the solution will imply a 20 byte MTU reduction within
   the multihomed site.

   This overhead can be eliminated by adopting a source address
   dependent routing within the site.

9.1.3.4 Will your solution add additional latency?

   Small sites: two strategies for detecting available path when
   initiating communications are presented: sequential retrial of paths
   or path retrial in parallel. The first approach would impose and
   additional latency in the case that the first path is not available.
   The second option would introduce packet overhead but would not
   increase the latency.

   Medium and Big sites: in this case, site exit router will have the
   information about destination address reachability. In the case that
   the destination address is not reachable through the ISP
   corresponding to the selected source address, the packet will be
   discarded and an increased latency will be generated. However, the
   introduced latency will reduced since the packet is discarded within
   the site.

9.1.3.5 Do you change the way fragmenting is handled?

   No, see above.

9.1.3.6 Are there any changes to ICMP error semantics?

   A new Site Exit redirection ICMP message is defined. see section
   7.2.2.1

   The processing of the ICMP destination unreachable error message with
   code 5 (source address failed ingress policy) will be modified
   according to the procedure described in section 4.3

9.1.4 Names, Hosts, Endpoints, or none of the above?

9.1.4.1 Please explain the relationship of your solution to DNS

   Host Centric Multihoming does not introduce a new namespace nor
   separates locators from identifiers. No changes to the DNS are
   introduced.






Huitema, et al.         Expires August 10, 2004                [Page 44]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


9.1.4.2 If you are not using DNS...

   No other mechanism is used.

9.1.4.3 Please explain interactions with 2-faced DNS

   No changes are introduced to the DNS.

9.1.4.4 Does your solution require centralized registration?

   No.

9.1.4.5 Have you checked for DNS circular dependencies?

   No changes are introduced to the DNS.

9.1.4.6 How does a host know its identity?

   No new identity is defined. The host learns its IP address by
   existent mechanisms.

9.1.4.7 What if a DNS server itself is multihomed?

   Host Centric Multihomed can be used to provide multihoming benefits
   DNS. In order to benefit from multihoming, the DNS server has to
   implement the host mechanisms, just as any other host within the
   multihomed site that benefits from Host Centric Multihoming.

9.1.4.8 What additional load will be placed on DNS servers?

   None.

9.1.4.9 Any upstream provider support required?

   for small sites: none

   For medium sites: running BGP with the site

   For big sites: relaxing ingress filtering, running BGP with the site

9.1.4.10 What application/API changes are needed?

   None. It is assumed that current applications are RFC 3484 compliant

9.1.4.11 Is this solution backward compatible with old IP version 6?

   Yes.




Huitema, et al.         Expires August 10, 2004                [Page 45]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   Can it be deployed incrementally?  Please describe how.

   Incremental deployment is the major goal of the Host Centric
   Multihoming proposal. In order to enable incremental deployment, the
   following roadmap is proposed:

   1- The first step is to preserve at least single homing
   functionalities when a single homed host that becomes multihomed.
   When a single site becomes multihomed, the site exit issue affects
   the communications of the hosts of the newly multihomed site.
   Establishing a mesh of tunnels between the site exit router in the
   case of the small and medium sites and relaxing the source address
   checks in the big sites overcomes this problems without imposing a
   general equipment upgrade. Moreover, the proposed solution only
   requires configuration of the specific devices. After this step, all
   the hosts within the multihomed site will work at least as if they
   were in a single homed site.

   2- The second step is to enable some of the multihoming benefits with
   minor modifications. This would provide some degree of fault
   tolerance when the direct link between the site and its direct
   providers fails.

   3- The third step is to enable most of the fault tolerance
   capabilities by upgrading the hosts to select the proper path. This
   step requires the upgrade of the hosts within the multihomed site.

   Does your solution impose requirements on non-multihomed/non-mobile
   hosts?

   No. The changes required by the solution are limited to the
   multihomed site.

   What happens if someone plugs in a normal IPv6 node?

   The normal IPv6 would work normally in the multihomed site as if it
   were in a single homed site and it will also obtain some multihomed
   benefits.

9.1.4.12 Is your solution backward compatible with IPv4?

   No. The proposed solution only works with IPv6.

9.1.4.13 Can IPv4 devices take advantage of this solution?

   No.





Huitema, et al.         Expires August 10, 2004                [Page 46]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


9.1.4.14 What is the impact of your solution on different types of
         sites?

   How are single homed sites impacted?

   No impact.

   How are small multihomed sites impacted?

   The proposed solution for small sites is customized for their special
   needs. It doesn't requires complex management (like BGP) nor lot of
   resources. It is basically host based and does not requires much
   configuration.

   How does it scale for large multihomed sites?

   For large sites a different solution is presented that requires
   additional expertise and resources but enables a higher degree of
   centralized control.

   What about ad-hoc sites such as an IETF event?

   If the hosts are upgraded to support the mechanism used in the
   multihomed site, they would obtain the multihomed benefits. If
   non-upgraded hosts are connected, they will obtain a service slightly
   better than the one offered in a single homed site.

9.1.4.15 How will your solution interact with other middleboxes?

   Just as regular IPv6 does.

9.1.4.16 Are there any implications for scoped addressing?

   No changes are introduce to the address architecture, so it is
   expected that the proposed architecture will interact with scoped
   addressing just as regular IPv6.

9.1.4.17 Are there any layer 2 implications to your proposal?

   No changes to the interaction with layer two are required. However,
   depending on how easily outages are detected, the performance of the
   solution may vary. For instance if direct link outages are rapidly
   detected, the correspondent prefix will be sooner deprecated and the
   performance of the solution will increase.

9.1.4.18 Referrals

   Referrals can be handled just as in regular IPv6. However, if



Huitema, et al.         Expires August 10, 2004                [Page 47]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   multihoming benefits are expected, the referral should include all of
   the IP addresses assigned to the host within the multihomed site, so
   that the receiver of the referral can try with the different
   addresses in case of failure.

9.1.4.19 What new information should applications be aware of?

   None

9.1.4.20 Legal Stuff

   None







































Huitema, et al.         Expires August 10, 2004                [Page 48]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


10. Security Considerations

   The use of a site exit redirection ICMP message could potentially be
   used to redirect and intercept traffic; secure hosts should only
   accept such messages if they are properly authenticated.














































Huitema, et al.         Expires August 10, 2004                [Page 49]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


11. IANA Considerations

   This document requests allocation by IANA of 2 new ICMPv6 message
   types.















































Huitema, et al.         Expires August 10, 2004                [Page 50]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


12. Acknowledgements

   This memo incorporates text from a previous draft submitted by
   Richard Draves.

   We acknowledge Alberto Garcia Martinez, Cedric de Launois, Brian
   Carpenter, Dave Crocker and Xiaowei Yang for their reviews and
   comments.











































Huitema, et al.         Expires August 10, 2004                [Page 51]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


References

   [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

   [2]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [3]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [4]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [5]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
         Socket Interface Extensions for IPv6", RFC 2553, March 1999.

   [6]   Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
         2000.

   [7]   Abley, J., Black, B. and V. Gill, "Goals for IPv6
         Site-Multihoming Architectures", RFC 3582, August 2003.

   [8]   Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
         Address Aggregation and Renumbering", RFC 2874, July 2000.

   [9]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", RFC 2267, January 1998.

   [10]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
         version 6", RFC 1886, December 1995.

   [11]  Johnson, D., "Mobility support in IPv6", Internet Draft , June
         2003.

   [12]  van Beijnum, I., "BGP", OReilly , 2002.

   [13]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [14]  Conta, A. and S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 2463, December 1998.

   [15]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.




Huitema, et al.         Expires August 10, 2004                [Page 52]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   [16]  de Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6
         Multihoming with Traffic Engineering", ID
         draft-de-launois-multi6-naros-00.txt, May 2003.

   [17]  Lear, E., "Things MULTI6 Developers should think about", ID
         draft-lear-multi6-things-to-think-about-01, December 2003.

   [18]  Gupta, M., "Message about new ICMP code points", IPv6 list
         message http://www1.ietf.org/mail-archive/working-groups/ipv6/
         current/msg01431.html, February 2004.


Authors' Addresses

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone:
   EMail: huitema@microsoft.com
   URI:


   Richard Draves
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone:
   EMail: richdr@microsoft.com
   URI:


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   EMail: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es






Huitema, et al.         Expires August 10, 2004                [Page 53]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Huitema, et al.         Expires August 10, 2004                [Page 54]


Internet-Draft       Host-Centric IPv6 Multihoming         February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Huitema, et al.         Expires August 10, 2004                [Page 55]