Internet DRAFT - draft-bagnulo-shim6-addr-selection

draft-bagnulo-shim6-addr-selection







Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Expires: April 5, 2006                                   October 2, 2005


              Address selection in multihomed environments
                 draft-bagnulo-shim6-addr-selection-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This note describes mechanisms for address selection in hosts within
   a multihomed site.  The goal of these mechanisms is to allow hosts
   within the multihomed site to establish new communications after an
   outage.  The presented mechanisms are not by themselves a complete
   multihoming solution but rather a component of such solution.







Bagnulo                   Expires April 5, 2006                 [Page 1]

Internet-Draft      Address selection for multihoming       October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Reference topology . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The problem: address selection after failures  . . . . . . . .  5
   4.  Goals and non-goals  . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Goal . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Non goals  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Proposed mechanisms  . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Proactive mechanisms . . . . . . . . . . . . . . . . . . .  8
       5.1.1.  Direct link failures . . . . . . . . . . . . . . . . .  8
       5.1.2.  Other failure modes  . . . . . . . . . . . . . . . . .  9
     5.2.  Reactive mechanisms  . . . . . . . . . . . . . . . . . . . 11
   6.  Future steps . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

































Bagnulo                   Expires April 5, 2006                 [Page 2]

Internet-Draft      Address selection for multihoming       October 2005


1.  Introduction

   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 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, that have to
   be addressed in order to provide a multihoming solution compatible
   with such addressing scheme.

   In this memo we will present a set of mechanisms that enable the
   hosts within the multihomed site to select the addresses in order to
   be able to establish new communications after an outage.  The
   presented mechanisms are not by themselves a complete multihoming
   solution but rather a component of such solution.



































Bagnulo                   Expires April 5, 2006                 [Page 3]

Internet-Draft      Address selection for multihoming       October 2005


2.  Reference topology

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



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



   The topology features two hosts, X and Y. The site of X is multihomed
   while the site of Y is single 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. Y has only one address "C:Y".

   We assume that Y, when it starts engaging communication with X, has
   learned the addresses A:X and B:X, 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 A:X and B:X are published,
   while in fact only one is reachable.  We assume that X, when it
   receives packets from Y, has only access to information contained in
   the packet coming from Y, e.g. the source address; we do not assume
   that X can retrieve by external means the set of addresses associated
   to Y. similar assumptions are made when X is initiating the
   communication, only that in this case, a single address i.e.  C:Y is
   published in the DNS

   In this scenario, both ISPA and ISPB are performing ingress filtering
   and have not relaxed the source address checks.  So, we assume that
   an ingress filtering compatibility mechanism [7] is available in the
   multihomed site (Site X) so that packets are forwarded through the
   ISP that corresponds to the source address prefix included in the
   packet by the host.















Bagnulo                   Expires April 5, 2006                 [Page 4]

Internet-Draft      Address selection for multihoming       October 2005


3.  The problem: address selection after failures

   In case that a failure occurs in one of the ISPs of the multihomed
   site, it may not be possible to establish a new communication towards
   a destination outside the site using the addresses derived from the
   prefix of the ISP affected by the failure.  For instance, in the case
   that the link between ISPA and the Internet fails, it will not be
   possible to establish a communication between X and Y using address
   A:X. In this case, any communication involving this address will fail
   because:

   - If Y tries to establish a communication with X using A:X as a
   destination address, packets would be discarded because there is no
   path available from the Internet to ISPA.

   - If X tries to communicate with Y using A:X as a source address,
   packets will be routed through ISPA in order to comply with ingress
   filters, and because ISPA has no link available wit the rest of the
   Internet, the packet will be discarded (it should be noted that even
   if the packet could make it to Y, reply packets from Y to X would
   contain A:X as a destination address, which is unreachable from Y).

   So, in order to establish a communication between X and Y when a
   failure has occurred in ISPA, the address derived from ISPA block
   i.e.  A:X, must not be used for the communication.

   The solution for this problem has to be provided by the address
   selection mechanisms.  In particular, when the communication is
   established from the host Y to the host X, the solution has to be
   provided by the destination address selection mechanism at host Y and
   when the communication is established from the host X to the host Y,
   the solution has to be provided by the source address selection
   mechanism at host X. Default address selection for IPv6 hosts is
   specified in RFC 3484 [5]

   We will next analyze the support provided by RFC 3484 when the
   communication is established from host Y to host X. In this case,
   host Y has two possible destination addresses A:X and B:X. Without
   any additional knowledge, both addresses are equivalent to host Y, so
   the default destination address selection mechanism will return a
   list of the two addresses ordered as they were returned by the
   resolver.  It may occur that A:X is first.  In this case, host Y will
   use A:X to reach host X and it will fail.  At this point, RFC 3484
   states that if there are other destination addresses available, the
   application should retry to establish the communication, using the
   next address in the list.  If the application retries with address
   B:X, the communication will be established successfully.




Bagnulo                   Expires April 5, 2006                 [Page 5]

Internet-Draft      Address selection for multihoming       October 2005


   In conclusion, the current destination address selection mechanism is
   enough to deal with this situation (as long as applications retry
   with all the addresses).

   Next, we will analyze the support provided by RFC 3484 when the
   communication is established from host X to host Y. In this case,
   destination address selection performed in host X is trivial, since
   there is only one address available for Y (C:Y).  Source address
   selection mechanism as specified in RFC 3484 will not prefer any of
   the two source addresses if no additional information is available,
   so any of the addresses can be selected as source address.  In the
   case that address A:X is selected, the communication will fail.  In
   this case there are no alternative destination address to retry with,
   so the communication will definitely fail.

   In conclusion, the source address selection mechanism defined in RFC
   3484 is not enough to support this scenario.  This memo defines
   mechanisms to provide a solution for this case.

































Bagnulo                   Expires April 5, 2006                 [Page 6]

Internet-Draft      Address selection for multihoming       October 2005


4.  Goals and non-goals

4.1.  Goal

   The goal of this memo is to provide mechanisms to complement the
   source address selection of the host within the multihomed that allow
   it to succesfully establish new communications after an outage,
   without requiring any modification to the hosts outside the
   multihomed site.

4.2.  Non goals

   It is not a goal of this memo to modify hosts located outside the
   multihomed site.

   It is not the goal of this memo to define a complete multihoming
   solution, but rather to define a component of such solution.


































Bagnulo                   Expires April 5, 2006                 [Page 7]

Internet-Draft      Address selection for multihoming       October 2005


5.  Proposed mechanisms

   There are two types of mechanisms that can be used to enable the host
   within the multihomed site to select the appropriate source address:
   proactive mechanisms, where the host is notified about which source
   address prefixes should be used for the different destinations and
   reactive mechanisms, which are based on the trial and error approach,
   where the hosts try with different source address prefixes and detect
   which one is available.

5.1.  Proactive mechanisms

   In this case, two mechanisms are needed: first, a mechanism to detect
   the outage and then a mechanisms to inform the host about which
   prefixes should be used in the source address for the different
   destinations.  While this may seem a lot of information to be stored
   in the host, it should be noted that in the default case, when no
   outage has occurred, all prefixes can be used to reach all the
   destinations, so no information is needed.  When an outage occurs,
   the host must be informed of which source address prefix should not
   be used to reach a certain set of destinations.  Depending on the
   type of outage, the amount of information may vary.

   We will first present mechanisms that can be used when the outage
   occurs in the direct link between the multihomed site and the ISP and
   then we will present a more general approach.

5.1.1.  Direct link failures

   In the case that the failure has occurred affecting the direct link
   between the multihomed site and one of its ISP (let's say ISPA), the
   prefix associated with that ISP should not be used for any new
   external communication, since the prefix is unreachable from any
   other part of the Internet.

   There are several mechanisms that can be used to detect the outage.
   For instance, if any routing protocol is used between the ISP and the
   multihomed site, such protocol can be used to detect the outage.  In
   any case, it is possible to use a periodic ICMP echo request for
   detecting the outage on direct links.

   In addition, 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.



Bagnulo                   Expires April 5, 2006                 [Page 8]

Internet-Draft      Address selection for multihoming       October 2005


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


   * an address prefix value,
   * 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 [1] , 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.

   This solution is sufficient when the site is composed of a single
   link; for more complex sites with multiple subnets, we need a
   mechanism with a broader scope than Router Advertisement.  There are
   two available candidates that provide the required fucntionality: the
   Router Renumbering protocol [3] and the prefix delegation option
   defined for DHCP [8].

   In order to advertise a null preferred lifetime for a specific
   prefix, the sites routers must be able to learn about that prefix.
   Any of the two proposed protocols, Router Renumbering or DHCP Prefix
   Delegation can be used to pass this information.  These protocols
   allow an authorized agent, in that case the egress site, to update
   the list of prefixes advertised by the site's routers.  The protocols
   can be used to change parameters associated to a prefix, such as the
   preferred lifetime.

5.1.2.  Other failure modes

   There are other failures modes where there are some parts of the
   Internet reachable using one prefix and other parts of the Internet
   are reachable using a different prefix.  For instance, in the next
   figure, when a failure occurs in the link between ISPA and the rest
   of the Internet, host X should use address B:X to reach host C:Y, but
   host X should use address A:X to reach D:Z.




Bagnulo                   Expires April 5, 2006                 [Page 9]

Internet-Draft      Address selection for multihoming       October 2005


                       Z
                   ( Site Z)
                       |
                    ( ISPD )
                       |
                /-- ( ISPA ) ---(      )
      X (site X)                ( IPv6 ) ---( ISPC )---(site Y) Y
                \-- ( ISPB ) ---(      )


   In this scenario, ISPD has its own prefix Prefix D and it obtains
   Internet connectivity through ISPA.  So, in this case, deprecating
   the prefix associated with ISPA would preclude communication with
   Site Z.

   In this scenario a mechanism like NAROS [6] can be used.  In this
   mechanism, a server acquires the reachability information available
   in the inter-domain routing system using BGP.  This means that there
   are BGP sessions established between each site exit router and the
   border router of the correspondent ISP, through which the site exit
   router obtains interdomain routing information.  The server
   establishes IBGP sessions with each site exit router, so it discovers
   which destinations are reachable through each ISP.  In the case there
   is no outage, all destinations are reachable through all the ISPs, so
   no information has to be propagated to the hosts.  In case of a
   failure, a set of destinations will become unreachable through one (o
   more) ISP(s).  In this case, the server has to inform the hosts about
   which prefix to use for the different destinations.  The host can
   store this information in the policy table defined in RFC 3484.  This
   policy table allows the host to prefer a certain source address for a
   given set of destinations.

   The missing part is a mechanism to convey the information from the
   server to the host.  A possible option is to define a new DHCP option
   to transmit policy table information.

   In the example above, the mechanism would work as follows.  Before
   the outage, the site exit router of site X are obtaining a default
   route from both ISPs.  The hosts have the default policy table
   configured.

   When an outage occurs in the link between ISPA and the Internet, ISPB
   still announces a default route, while ISPA will announce only a
   route to prefix A and to prefix D (and not a default route).  This
   information is transmitted to the server that will craft the new
   policy table.  Because of the longest prefix match rule of source
   address selection algorithm defined in RFC 3484, A:X will be the
   preferred source address when sending packet to destinations



Bagnulo                   Expires April 5, 2006                [Page 10]

Internet-Draft      Address selection for multihoming       October 2005


   containing prefix A. So, the new policy table must inform that for
   destinations containing prefix D the prefix A should be used in the
   source address.  Additionally the policy table must reflect that for
   the rest of destinations prefix B should be preferred.  This is
   achieved by adding the following entries to the policy table:



   Prefix     Precedence   Label
   Prefix A        10        11
   Prefix D        10        11
   ::/0            10        12
   Prefix B        10        12

   Because both entries have the same Label, Rule 6 (Prefer matching
   label) of the source address selection algorithm will select the
   source address containing prefix A when sending packets to
   destinations containing Prefix D. Also because rule 6, for the rest
   of the destinations, the source address containing Prefix B will be
   preferred.  The new policy table is transmitted to the hosts using
   the new DHCP option.

   It is also possible to enable the multihomed host to query the server
   to obtain the source address prefix information as proposed in [6] .
   In this case, each time the multihomed node initiates a communication
   with a new destiantion, it would query the server for the proper
   prefix to include in the source address.  The server, would reply
   based on the routing information it has gathered through BGP.

5.2.  Reactive mechanisms

   In this approach, the host will try with different source addresses
   until the communication is established.  After the communication is
   established, the information about which source address to use for a
   given destination is stored in a Source Address Cache.  Each entry of
   the cache contains for a Destination Address, information about the
   corresponding Source Address and its lifetime.

   The source address cache entry creation process is the following:

   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.



Bagnulo                   Expires April 5, 2006                [Page 11]

Internet-Draft      Address selection for multihoming       October 2005


   -- 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.

   - 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 period of Tb (TBD) seconds to avoid that
   multiple answers produce suboptimal behavior.

   There are different retrial strategies that can be used in this
   approach.

   The first option is to simply let the upper layers to handle
   retrials.  In this case, the IP layer only has to make sure that a
   different source address is used in each retrial as long as there is
   not a preferred source address in the source address cache.  So, in
   this approach, when the IP layer receives a packet, it searches the
   Source Address Cache for a preferred source address associated to the
   selected destination.  If no entry exists for that destination
   address, one of the available source addresses is selected randomly.
   If reply packets arrive, an entry will be created in the Source
   Address Cache for that destination address.  If no reply packets
   arrive, no entry will be created, so when the upper layer protocol
   resends the packet, a new source address will be used.

   The second option would be that the IP layer handles retrials.  In
   this case, the IP layer stores the packet and retries until a Source
   Address Cache entry is created for that destination.  This approach
   imposes that the IP layer has to store the packets sent to
   destinations that still don't have a Source Address Cache entry
   created.  It should be noted that the IP layer is incapable of
   recognizing if incoming packets are actually replies to the packets
   sent, since the IP layer knowledge is limited to the source and
   destination address pair.  This means that the retransmission service
   provided by the IP layer won't be reliable.  Additionally, this
   approach requires the definition of timeouts after which the IP layer
   will resend the packets.  Since the IP layer has no information about
   the round trip times or reply time of the involved applications, the
   selection of this timer will be arbitrary.

   The third option would be to try with all possible source address
   simultaneously.  In this approach, when the IP layer receives a
   packet from the upper layer, it searches the Source Address Cache for
   the destination of the packet.  If an entry is found for that
   destination, the source address contained in the Source Address Cache
   is used.  If no entry is found for that destination, the IP layer
   sends as many packets as different source address are available, each
   one with a different address.  In this case, the IP layer doesn't



Bagnulo                   Expires April 5, 2006                [Page 12]

Internet-Draft      Address selection for multihoming       October 2005


   need to store any packets and it doesn't rely retransmission by upper
   layer protocols.  What is more, this approach would provide the
   selection of the "best path" (under certain criteria), since the
   destination address of the first reply packet could be used as source
   address, selecting the fastest path available.  The main drawback of
   this approach is the additional load imposed by duplicated packets.













































Bagnulo                   Expires April 5, 2006                [Page 13]

Internet-Draft      Address selection for multihoming       October 2005


6.  Future steps

   This memo presents multiple possible approaches to select address for
   initiating new communications after an outage in multihomed
   environments.  At this point, the goal of the memo is to foster
   discussion about the benefits and drawbacks of each approach, so that
   eventually a set of mechanisms can be selected.












































Bagnulo                   Expires April 5, 2006                [Page 14]

Internet-Draft      Address selection for multihoming       October 2005


7.  Acknowledgments

   This memo contains parts of a previous work entitled "Host-Centric
   IPv6 Multihoming" that benefited from comments from Alberto Garcia
   Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei
   Yang and Erik Nordmark.

8.  References

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

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

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

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

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

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

   [7]  Huitema, C. and R. Draves, "Ingress Filtering compatibility for
        IPv6 multihomed sites",
        ID draft-huitema-shim6-ingress-filtering-00.txt, October 2005.

   [8]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
        Configuration Protocol (DHCP) version 6", RFC 3633,
        December 2003.
















Bagnulo                   Expires April 5, 2006                [Page 15]

Internet-Draft      Address selection for multihoming       October 2005


Author's Address

   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








































Bagnulo                   Expires April 5, 2006                [Page 16]

Internet-Draft      Address selection for multihoming       October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Bagnulo                   Expires April 5, 2006                [Page 17]