GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4177

Network Working Group G. Huston Request for Comments: 4177 APNIC Category: Informational September 2005

         Architectural Approaches to Multi-homing for IPv6

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This memo provides an analysis of the architectural aspects of
 multi-homing support for the IPv6 protocol suite.  The purpose of
 this analysis is to provide a taxonomy for classification of various
 proposed approaches to multi-homing.  It is also an objective of this
 exercise to identify common aspects of this domain of study, and also
 to provide a framework that can allow exploration of some of the
 further implications of various architectural extensions that are
 intended to support multi-homing.

Huston Informational [Page 1] RFC 4177 Multi6 Architecture September 2005

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  The Multi-Homing Space . . . . . . . . . . . . . . . . . . . .  5
 4.  Functional Goals and Considerations  . . . . . . . . . . . . .  7
 5.  Approaches to Multi-Homing . . . . . . . . . . . . . . . . . .  7
     5.1.  Multi-Homing: Routing  . . . . . . . . . . . . . . . . .  8
     5.2.  Multi-Homing: Mobility . . . . . . . . . . . . . . . . .  9
     5.3.  Multi-homing: Identity Considerations  . . . . . . . . . 12
     5.4.  Multi-homing: Identity Protocol Element  . . . . . . . . 14
     5.5.  Multi-homing: Modified Protocol Element  . . . . . . . . 15
     5.6.  Modified Site-Exit and Host Behaviors  . . . . . . . . . 16
 6.  Approaches to Endpoint Identity  . . . . . . . . . . . . . . . 17
     6.1.  Endpoint Identity Structure  . . . . . . . . . . . . . . 18
     6.2.  Persistent, Opportunistic, and Ephemeral Identities  . . 20
     6.3.  Common Issues for Multi-Homing Approaches  . . . . . . . 23
           6.3.1.  Triggering Locator Switches  . . . . . . . . . . 23
           6.3.2.  Locator Selection  . . . . . . . . . . . . . . . 26
           6.3.3.  Layering Identity  . . . . . . . . . . . . . . . 27
           6.3.4.  Session Startup and Maintenance  . . . . . . . . 29
           6.3.5.  Dynamic Capability Negotiation . . . . . . . . . 31
           6.3.6.  Identity Uniqueness and Stability  . . . . . . . 31
 7.  Functional Decomposition of Multi-Homing Approaches  . . . . . 32
     7.1.  Establishing Session State . . . . . . . . . . . . . . . 32
     7.2.  Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
     7.3.  Re-homing Locator Pair Selection . . . . . . . . . . . . 33
     7.4.  Locator Change . . . . . . . . . . . . . . . . . . . . . 34
     7.5.  Removal of Session State . . . . . . . . . . . . . . . . 34
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
 9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
 10. Informative References . . . . . . . . . . . . . . . . . . . . 34

Huston Informational [Page 2] RFC 4177 Multi6 Architecture September 2005

1. Introduction

 The objective of this analysis is to allow various technical
 proposals relating to the support of multi-homing environment in IPv6
 to be placed within an architectural taxonomy.  This is intended to
 allow these proposals to be classified and compared in a structured
 fashion.  It is also an objective of this exercise to identify common
 aspects across all proposals within this domain of study, and also to
 provide a framework that can allow exploration of some of the further
 implications of various architectural extensions that are intended to
 support multi-homing.  The scope of this study is limited to the IPv6
 protocol suite architecture, although reference is made to IPv4
 approaches as required.

2. Terminology

 Care-of Address (CoA)
    A unicast routeable address associated with a mobile node while
    visiting a foreign link; the subnet prefix of this IP address is a
    foreign subnet prefix.  Among the multiple care-of addresses that
    a mobile node may have at any given time (e.g., with different
    subnet prefixes), the one registered with the mobile node's home
    agent for a given home address is called its "primary" care-of
    address.
 Correspondent Node (CN)
    A peer node with which a mobile node is communicating.  The
    correspondent node may be either mobile or stationary.
 Endpoint
    A term for the identity for a network host.  This is normally
    assumed to be a constant or long-lived association.
 Endpoint Identity Protocol Stack Element (EIP)
    An added element in a protocol stack model that explicitly manages
    the association of locators to endpoints.
 Home Address (HoA)
    A unicast routeable address assigned to a mobile node, used as the
    permanent address of the mobile node.  This address is within the
    mobile node's home link.  Standard IP routing mechanisms will
    deliver packets destined for a mobile node's home address to its
    home link.  Mobile nodes can have multiple home addresses, for
    instance, when there are multiple home prefixes on the home link.

Huston Informational [Page 3] RFC 4177 Multi6 Architecture September 2005

 Lower Layer Protocol (LLP)
    The lower-level protocol in the protocol stack model relative to
    the protocol layer being considered.  In the Internet
    architecture, the LLP of the transport protocol is the Internet
    Protocol, and the LLP of the application protocol is the transport
    protocol.
 Locator
    The term "locator" is used as the location token for a network
    host.  This is a network-level address that can be used as a
    destination field for IP packets.
 Mobile Node
    A node that can change its point of attachment from one link to
    another, while still being reachable via its home address.
 Multi-Homed Site
    A site with more than one transit provider.  "Site multi-homing"
    is the practice of arranging a site to be multi-homed such that
    the site may use any of its transit providers for connectivity
    services.
 Re-homing
    The transition of a site between two states of connectedness, due
    to a change in the connectivity between the site and its transit
    providers.
 Site
    An entity autonomously operating a network using IP.
 Site-Exit Router
    A boundary router of the site that provides the site's interface
    to one or more transit providers.
 Transit Provider
    A provider that operates a site that directly provides
    connectivity to the Internet to one or more external sites.  The
    connectivity provided extends beyond the transit provider's own
    site.  A transit provider's site is directly connected to the
    sites for which it provides transit.
 Upper Layer Protocol (ULP)
    The upper-level protocol in the protocol stack model relative to
    the protocol layer being considered.  In the Internet
    architecture, the ULP of the Internet Protocol is the transport
    protocol, and the ULP of the transport protocol is the application
    protocol.

Huston Informational [Page 4] RFC 4177 Multi6 Architecture September 2005

3. The Multi-Homing Space

 A simple formulation of the site multi-homing environment is
 indicated in Figure 1.
                         +------+
                         |remote|
                         | host |
                         |  R   |
                         +------+
                            |
                  + - - - - - - - - - - - +
                  | Internet Connectivity |
                  + - - - - - - - - - - - +
                       /            \
                 +---------+    +---------+
                 | ISP A   |    |  ISP B  |
                 +---------+    +---------+
                     | Path A        | Path B
       + - - - - - - - - - - - - - - - - - - - - +
       | multi-      |               |           |
         homed   +------+         +------+
       | site    | site-|         | site-|       |
                 | exit |         | exit |
       |         |router|         |router|       |
                 |  A   |         |  B   |
       |         +------+         +------+       |
                    |                |
       |         local site connectivity         |
                         |
       |           +-----------+                 |
                   |multi-homed|
       |           |   host    |                 |
                   +-----------+
       + - - - - - - - - - - - - - - - - - - - - +
            Figure 1: The Multi-Homed Domain
 The environment of multi-homing is intended to provide sufficient
 support to local hosts so as to allow local hosts to exchange IP
 packets with remote hosts, such that this exchange of packets is
 transparently supported across dynamic changes in connectivity.
 Session resilience implies that if a local multi-homed-aware host
 establishes an application session with the remote host using "Path

Huston Informational [Page 5] RFC 4177 Multi6 Architecture September 2005

 A", and this path fails, the application session should be mapped
 across to "Path B" without requiring any application-visible
 re-establishment of the session.  In other words, the application
 session should not be required to be explicitly aware of underlying
 path changes at the level of packet forwarding paths chosen by the
 network.  Established sessions should survive dynamic changes in
 network-level reachability.
 There are also considerations of providing mechanisms to support
 sustained site visibility to support session establishment.
 Sustained site visibility implies that external attempts to initiate
 a communication with hosts within the site will succeed as long as
 there is at least one viable path between the external host and the
 multi-homed site.  This also implies that local attempts to initiate
 a communication with remote hosts should take into account the
 current connectivity state in undertaking locator selection and
 setting up initial locator sets.
 In addition, there is the potential consideration of being able to
 distribute the total traffic load across a number of network paths
 according to some predetermined policy objective.  This may be to
 achieve a form of traffic engineering, support for particular
 quality-of-service requirements, or localized load balancing across
 multiple viable links.
 This simple multi-homing scenario also includes "site-exit" routers,
 where the local site interfaces to the upstream Internet transit
 providers.  The interactions between the external routing system and
 the site-exit routers, the interactions between the site-exit routers
 and the local multi-homed host, and the interactions between local
 connectivity forwarding and the local host and site exit routers are
 not defined a priori in this scenario, as they form part of the
 framework of interaction between the various multi-homing components.
 The major characteristic of this simple site multi-homing scenario is
 that the address space used by, and advertised as reachable by, ISP A
 is distinct from the address space used by ISP B.
 This simple scenario is intended to illustrate the basic multi-homing
 environment.  Variations may include additional external providers of
 transit connectivity to the local site; complex site requirements and
 constraints, where the site may not interface uniformly to all
 external transit providers; sequential rather than simultaneous
 external transit reachability; communication with remote multi-homed
 hosts; multiway communications; use of host addresses in a
 referential context (third-party referrals); and the imposition of
 policy constraints on path selection.  However, the basic simple site
 multi-homing scenario is sufficient to illustrate the major

Huston Informational [Page 6] RFC 4177 Multi6 Architecture September 2005

 architectural aspects of support for multi-homing, so this simple
 scenario will be used as the reference model for this analysis.

4. Functional Goals and Considerations

 RFC 3582 [RFC3582] documents some goals that a multi-homing approach
 should attempt to address.  These goals include:
  • redundancy
  • load sharing
  • traffic engineering
  • policy constraints
  • simplicity of approach
  • transport-layer survivability
  • DNS compatibility
  • packet filtering capability
  • scaleability
  • legacy compatibility
 The reader is referred to [RFC3582] for a complete description of
 each of these goals.
 In addition, [thinks] documents further considerations for IPv6
 multi-homing.  Again, the reader is referred to this document for the
 detailed enumeration of these considerations.  The general topic
 areas considered in this study include:
  • interaction with routing systems,
  • aspects of a split between endpoint-identifier and forwarding

locator,

  • changes to packets on the wire, and
  • the interaction between names, endpoints, and the DNS.
 In evaluating various approaches, further considerations also
 include:
  • the role of helpers and agents in the approach,
  • modifications to host behaviours,
  • the required trust model to support the interactions, and
  • the nature of potential vulnerabilities in the approach.

5. Approaches to Multi-Homing

 There appear to be five generic forms of architectural approaches to
 this problem, namely:

Huston Informational [Page 7] RFC 4177 Multi6 Architecture September 2005

    Routing
       Use the IPv4 multi-homing approach
    Mobility
       Use the IPv6 Mobility approach
    New Protocol Element
       Insert a new element in the protocol stack that manages a
       persistent identity for the session
    Modify a Protocol Element
       Modify the transport or IP protocol stack element in the host
       in order to support dynamic changes to the forwarding locator
    Modified Site-Exit Router/Local Host interaction
       Modify the site-exit router and local forwarding system to
       allow various behaviours including source-based forwarding,
       site-exit hand-offs, and address rewriting by site-exit routers
 These approaches will be described in detail in the following
 sections.

5.1. Multi-Homing: Routing

 The approach used in IPv4 for multi-homing support is to preserve the
 semantics of the IPv4 address as both an endpoint identifier and a
 forwarding locator.  For this to work in a multi-homing context, it
 is necessary for the transit ISPs to announce the local site's
 address prefix as a distinct routing entry in the inter-domain
 routing system.  This approach could be used in an IPv6 context, and,
 as with IPv4, no modifications to the IPv6 architecture are required
 to support this approach.
 The local site's address prefix may be a more specific address prefix
 drawn from the address space advertised by one of the transit
 providers, or from some third-party provider not currently connected
 directly to the local site.  Alternatively, the address space may be
 a distinct address block obtained by direct assignment from a
 Regional Internet Registry as Provider Independent space.  Each host
 within the local site is uniquely addressed from the site's address
 prefix.
 All transit providers for the site accept a prefix advertisement from
 the multi-homed site and advertise this prefix globally in the
 inter-domain routing table.  When connectivity between the local site
 and an individual transit provider is lost, normal operation of the
 routing protocol will ensure that the routing advertisement

Huston Informational [Page 8] RFC 4177 Multi6 Architecture September 2005

 corresponding to this particular path will be withdrawn from the
 routing system; those remote domains that had selected this path as
 the best available will select another candidate path as the best
 path.  Upon restoration of the path, the path is re-advertised in the
 inter-domain routing system.  Remote domains will undertake a further
 selection of the best path based on this re-advertised reachability
 information.  Neither the local nor the remote host need to have
 multiple addresses or to undertake any form of address selection.
 The path chosen for forward and reverse direction path flows is a
 decision made by the routing system.
 This approach generally meets all the goals for multi-homing
 approaches with one notable exception: scaleability.  Each site that
 multi-homes in this fashion adds a further entry in the global
 inter-domain routing table.  Within the constraints of current
 routing and forwarding technologies, it is not clearly evident that
 this approach can scale to encompass a population of multi-homed
 sites of the order of, for example, 10**7 such sites.  The
 implication here is that this would add a similar number of unique
 prefixes into the inter-domain routing environment, which in turn
 would add to the storage and computational load imposed on
 inter-domain routing elements within the network.  This scale of
 additional load is not supportable within the current capabilities of
 the IPv4 global Internet, nor is it clear at present that the routing
 capabilities of the entire network could be expanded to manage this
 load in a cost-effective fashion, within the bounds of the current
 inter-domain routing protocol architecture.
 One other goal, transport-layer surviveability, is potentially at
 risk in this approach.  Dynamic changes within the network trigger
 the routing system to converge to a new stable distributed forwarding
 state.  This process of convergence within the distributed routing
 system may include the network generating unstable transient
 forwarding paths, as well as taking an indeterminate time to
 complete.  This in term may trigger upper-level protocol timeouts and
 possible session resets.

5.2. Multi-Homing: Mobility

 Preserving established communications through movement is similar to
 preserving established communications through outages in multi-homed
 sites as both scenarios require the capability of dynamically
 changing the locators used during the communication while
 maintaining, unchanged, the endpoint identifier used by Upper Layer
 Protocol (ULP).  Since MIPv6 protocol [RFC3775] already provides the
 required support to preserve established communications through
 movement, it seems worthwhile to explore whether it could also be
 used to provide session survivability in multi-homed environments.

Huston Informational [Page 9] RFC 4177 Multi6 Architecture September 2005

 MIPv6 uses a preferred IP address, the Home Address (HoA), as a
 stable identifier for the mobile node (MN).  This identifier is then
 dynamically mapped to a valid locator (Care-of Address, or CoA) that
 corresponds to the current attachment point within the network
 topology.  When the MN is at the Home Network, the HoA is used both
 as locator and as identifier.  When the MN is not at the Home
 Network, the HoA is used as an identifier, and the CoA is used as
 locator.  A relaying agent (Home Agent) placed in the Home Network is
 used to forward packets addressed to the HoA to the current location,
 specified by the CoA.  After each movement, the MN must inform its
 Home Agent of the new CoA and optionally inform those entities with
 which it has established communications (Correspondent Nodes, or
 CNs).  The mapping between the HoA and the current CoA is conveyed
 using Binding Update (BU) messages.
 When the BU message is exchanged between the MN and the Home Agent,
 it is possible to assume the existence of a pre-established Security
 Association that can be used to protect the binding information.
 However, when the BU message is exchanged between the MN and the CN,
 it is not possible to assume the existence of such a Security
 Association.  In this case, it is necessary to adopt an alternative
 mechanism to protect the binding information contained in the
 message.  The selected mechanism is called the Return Routeability
 procedure, and the background for its design is detailed in [rosec].
 The goal of the mechanism is to allow the CN to verify that the MN
 that is claiming that an HoA is currently located at a CoA is
 entitled to make such claim; this essentially means that the HoA was
 assigned to the MN, and that the MN is currently located at the CoA.
 In order to verify these updates, the CN sends two different secrets,
 one to the claimed HoA and another one to the claimed CoA.  If the MN
 receives both secrets, this means that the Home Agent located at the
 Home Network has a trust relationship with the MN, that it has
 forwarded the secret sent to the HoA, and that the MN is receiving
 packets sent to the CoA.  By including authorisation information
 derived from both secrets within the BU message, the MN will be able
 to prove to the CN that the claimed binding between the HoA and the
 CoA is valid.
 The lifetime of the binding that is created in the CN using
 authorisation information obtained through the Return Routeability
 procedure is limited to 7 minutes, in order to prevent time-shifted
 attacks [rosec].  In a time-shifted attack, an attacker located along
 the path between the CN and the MN forges the Return Routeability
 packet exchange.  The result of such an attack is that the CN will
 forward all the traffic addressed to the HoA to the CoA selected by
 the attacker.  The attacker can then leave the position along the
 path, but the effects of the attack will remain until the binding is
 deleted, shifting in time the effect of the attack.  By limiting the

Huston Informational [Page 10] RFC 4177 Multi6 Architecture September 2005

 lifetime of the binding in the CN, the effect of this attack is
 reduced to 7 minutes, because after that period a new Return
 Routeability procedure is needed to extend the binding lifetime.  It
 should be noted that the Return Routeability procedure is vulnerable
 to "man-in-the-middle" attacks, since an attacker located along the
 path between the CN and the MN can forge the periodic Return
 Routeability packet exchange.
 The possible application of the MIPv6 protocol to the multi-homing
 problem would be to use BU messages to convey information in advance
 about alternative addresses that could be used following an outage in
 the path associated with the currently used address.
 In this scenario, the multi-homed host adopts the MN role and the
 host outside the multi-homed site adopts the CN role.  When a
 communication is established between the multi-homed host and the
 external host, the address used for initiating the communication is
 used as an HoA.  The communication continues using this address as
 long as no outage occurs.  If an outage occurs and the HoA becomes
 unreachable, an alternative address of the multi-homed node is used
 as a CoA.  In this case, the multi-homed node sends a BU message to
 the external host, informing it about the new CoA to be used for the
 HoA, so that the established communication can be preserved using the
 alternative address.  However, such a BU message has to be validated
 using authorisation information obtained through the Return
 Routeability procedure, which implies that the binding lifetime will
 be limited to a fixed period of no more than 7 minutes.  The result
 is that the binding between the HoA and the new CoA will expire after
 this interval has elapsed, and then the HoA will be used for the
 communication.  Since the HoA is unreachable because of the outage,
 the communication will be interrupted.  It should be noted that it is
 not possible to acquire new authorisation information by performing a
 new Return Routeability procedure, because it requires communication
 through the HoA, which is no longer reachable.  Consequently, a
 mechanism based on the MIPv6 BU messages to convey information about
 alternative addresses will preserve communications only for 7
 minutes.
 The aspect of MIPv6 that appears to present issues in the context of
 multi-homing is the Return Routeability procedure.  In MIPv6,
 identity validity is periodically tested by return routeability of
 the identity address.  This regular use of a distinguished locator as
 the identity token cannot support return reachability in the
 multi-homing context, in the event of extended failure of the path
 that is associated with the identity locator.

Huston Informational [Page 11] RFC 4177 Multi6 Architecture September 2005

5.3. Multi-homing: Identity Considerations

 The intent of multi-homing in the IPv6 domain is to achieve an
 outcome that is comparable to that of multi-homed IPv4 sites using
 routing to support multi-homing, without an associated additional
 load being imposed on the IPv6 routing system.  The overall intent of
 IPv6 is to provide a scalable protocol framework to support the
 deployment of communications services for an extended period of time,
 and this implies that the scaling properties of the deployment
 environment remain tractable within projections of size of deployment
 and underlying technology capabilities.  Within the inter-domain
 routing space, the basic approach used in IPv4 and IPv6 is to attempt
 to align address deployment with network topology, so that address
 aggregation can be used to create a structured hierarchy of the
 routing space.
 Within this constraint of topological-based address deployment and
 provider-aggregateable addressing architectures, the local site that
 is connected to multiple providers is delegated addresses from each
 of these providers' address blocks.  In the example network in
 Figure 1, the local multi-homed host will conceivably be addressed in
 two ways: one using transit provider A's address prefix and the other
 using transit provider B's address prefix.
 If remote host R is to initiate a communication with the local
 multi-homed host, it would normally query the DNS for an address for
 the local host.  In this context, the DNS would return two addresses.
 one using the A prefix and the other using the B prefix.  The remote
 host would select one of these addresses and send a packet to this
 destination address.  This would direct the packet to the local host
 along a path through A or B, depending on the selected address.  If
 the path between the local site and the transit provider fails, then
 the address prefix announced by the transit provider to the
 inter-domain routing system will continue to be the provider's
 address prefix.  The remote host will not see any change in routing,
 yet packets sent to the local host will now fail to be delivered.
 The question posed by the multi-homing problem is: "If the remote
 host is aware of multi-homing, how could it switch over to using the
 equivalent address for the local multi-homed host that transits the
 other provider?"
 If the local multi-homed host wishes to initiate a session with
 remote host R, it needs to send a packet to R with a valid source and
 destination address.  While the destination address is that of R,
 what source address should the local host use?  There are two
 implications for this choice.  Firstly, the remote host will, by
 default use this source address as the destination address in its
 response, and hence this choice of source address will direct the

Huston Informational [Page 12] RFC 4177 Multi6 Architecture September 2005

 reverse path from R to the local host.  Secondly, ISPs A and B may be
 using some form of reverse unicast address filtering on source
 addresses of packets passed to the ISP, as a means of preventing
 source address spoofing.  This implies that if the multi-homed
 address selects a source address from address prefix A, and the local
 routing to R selects a best path via ISP B, then ISP B's ingress
 filters will discard the packet.
 Within this addressing structure there is no form of routing-based
 repair of certain network failures.  If the link between the local
 site and ISP A fails, there is no change in the route advertisements
 made by ISP A to its external routing peers.  Even though the
 multi-homed site continues to be reachable via ISP B, packets
 directed to the site using ISP A's prefix will be discarded by ISP A,
 as the destination is unreachable.  The implication here is that, if
 the local host wishes to maintain a session across such events, it
 needs to communicate to remote host R that it is possible to switch
 to a destination address for the multi-homed host that is based on
 ISP B's address prefix.  In the event that the local host wishes to
 initiate a session at this point, then it may need to use an initial
 source locator that reflects the situation that the only viable
 destination address to use is the one that is based on ISP B's
 address prefix.  It may be the case that the local host is not aware
 of this return routeability constraint, or it may not be able to
 communicate this information directly to R, in which case R needs to
 discover or be passed this information in other ways.
 In an aggregated routing environment, multiple transit paths to a
 host imply multiple address prefixes for the host, where each
 possible transit path is identified by an address for the host.  The
 implication of this constraint on multi-homing is that paths being
 passed to the local multi-homed site via transit provider ISP A must
 use a forwarding-level destination IP address drawn from ISP A's
 advertised address prefix set that maps to the multi-homed host.
 Equally, packets being passed via the transit of ISP B must use a
 destination address drawn from ISP B's address prefix set.  The
 further implication here is that path selection (ISP A vs. ISP B
 transit for incoming packets) is an outcome of the process of
 selecting an address for the destination host.
 The architectural consideration here is that, in the conventional IP
 protocol architecture, the assumption is made that the
 transport-layer endpoint identity is the same identity used by the
 internet forwarding layer, namely the IP address.
 If multiple forwarding paths are to be supported for a single
 transport session and if path selection is to be decoupled from the
 functions of transport session initiation and maintenance, then the

Huston Informational [Page 13] RFC 4177 Multi6 Architecture September 2005

 corollary in architectural terms appears to be that some changes are
 required in the protocol architecture to decouple the concepts of
 identification of the endpoint and identification of the location and
 associated path selection for the endpoint.  This is a fundamental
 change in the semantics of an IP address in the context of the role
 of the endpoint address within the end-to-end architectural model
 [e2e].  This change in the protocol architecture would permit a
 transport session to use an invariant endpoint identity value to
 initiate and maintain a session, while allowing the forwarding layer
 to dynamically change paths and associated endpoint locator
 identities without impacting on the operation of the session.  Such a
 decoupling of the concepts of identities and locators would not add
 any incremental load to the inter-domain routing system.
 Some generic approaches to this form of separation of endpoint
 identity and locator value are described in the following sections.

5.4. Multi-homing: Identity Protocol Element

 One approach to this objective is to add a new element into the model
 of the protocol stack.
 The presentation to the upper-level protocol stack element (ULP)
 would be endpoint identifiers to uniquely identify both the local
 stack and the remote stack.  This will provide the ULP with stable
 identifiers for the duration of the ULP session.
 The presentation to the lower-level protocol stack element (LLP)
 would be of the form of a locator.  This implies that the protocol
 stack element would need to maintain a mapping of endpoint identifier
 values to locator values.  In a multi-homing context, one of the
 essential characteristics of this mapping is that it needs to be
 dynamic, in that environmental triggers should be able to trigger a
 change in mappings.  This in turn would correspond to a change in the
 paths (forward and/or reverse) used by the endpoints to traverse the
 network.  In this way, the ULP session is defined by a peering of
 endpoint identifiers that remain constant throughout the lifetime of
 the ULP session, while the locators may change to maintain end-to-end
 reachability for the session.
 The operation of the new protocol stack element (termed here the
 "endpoint identity protocol stack element", or EIP) will establish a
 synchronised state with its remote counterpart.  This will allow the
 stack elements to exchange a set of locators that may be used within
 the context of the session.  A change in the local binding between
 the current endpoint identity value and a locator will change the
 source locator value used in the forwarding-level packet header.  The
 actions of the remote EIP upon receipt of this packet with the new

Huston Informational [Page 14] RFC 4177 Multi6 Architecture September 2005

 locator is to recognise this locator as part of an existing session
 and, upon some trigger condition, to change its session view of the
 mapping of the remote endpoint identity to the corresponding locator
 and use this locator as the destination locator in subsequent packets
 passed to the LLP.
 From the perspective of the IP protocol architecture, there are two
 possible locations to insert the EIP into the protocol stack.
 One possible location is at the upper level of the transport
 protocol.  Here the application program interface (API) of the
 application-level protocols would interface to the EIP element, and
 use endpoint identifiers to refer to the remote entity.  The EIP
 would pass locators to the API of the transport layer.
 The second approach is to insert the EIP between the transport and
 internet protocol stack elements, so that the transport layer would
 function using endpoint identifiers and maintain a transport session
 using these endpoint identifiers.  The IP or internetwork layer would
 function using locators, and the mapping from endpoint identifier to
 locator is undertaken within the EIP stack element.

5.5. Multi-homing: Modified Protocol Element

 As an alternative to insertion of a new protocol stack element into
 the protocol architecture, an existing protocol stack element could
 be modified to include the functionality performed by the EIP
 element.  This modification could be undertaken within the transport
 protocol stack element or within the internet protocol stack element.
 The functional outcome from these modifications would be to create a
 mechanism to support the use of multiple locators within the context
 of single-endpoint-to-single-endpoint communication.
 Within the transport layer, this functionality could be achieved, for
 example, by binding a set of locators to a single session and then
 communicating this locator set to the remote transport entity.  This
 would allow the local transport entity to switch the mapping to a
 different locator for either the local endpoint or the remote
 endpoint, while maintaining the integrity of the ULP session.
 Within the IP level, this functionality could be supported by a form
 of dynamic rewriting of the packet header as it is processed by the
 protocol element.  Incoming packets with the source and destination
 locators in the packet header are mapped to packets with the
 equivalent endpoint identifiers in both fields, and the reverse
 mapping is performed to outgoing packets passed from the transport
 layer.  Mechanisms that support direct rewriting of the packet header
 are potential candidates in this approach.  Other potential

Huston Informational [Page 15] RFC 4177 Multi6 Architecture September 2005

 candidates are various forms of packet header transformations using
 encapsulation, where the original endpoint identifier packet header
 is preserved in the packet and an outer-level locator packet header
 is wrapped around the packet as it is passed through the internet
 protocol stack element.
 There are common issues in all these scenarios: what state is kept,
 which part of the protocol stack keeps this state, how state is
 maintained with additions and removals of locator bindings, and
 whether only one piece of code is aware of the endpoint/locator split
 or do multiple protocol elements have to be modified?  For example,
 if the functionality is added at the internetworking (IP) layer,
 there is no context of an active transport session, so that removal
 of identity/locator state information for terminated sessions needs
 to be triggered by some additional mechanism from the transport layer
 to the internetworking layer.

5.6. Modified Site-Exit and Host Behaviors

 The above approaches all assume that the hosts are explicitly aware
 of the multi-homed environment and use modified protocol behaviour to
 support multi-homing functionality.  A further approach to this
 objective is to split this functionality across a number of network
 elements and potentially perform packet header rewriting from a
 persistent endpoint identity value to a locator value at a remote
 point.
 One possible approach uses site-exit routers to perform some form of
 packet header manipulation as packets are passed from the local
 multi-homed site to a particular transit provider.  The local site
 routing system will select the best path to a destination host based
 on the remote host's locator value.  The local host will write its
 endpoint identity as the source address of the packet.  When the
 packet reaches a site-exit router, the site-exit router will rewrite
 the source field of the packet to a corresponding locator that
 selects a reverse path through the same transit ISP when the locator
 is used as a destination locator by the remote host.  In order to
 preserve session integrity, a corresponding reverse transformation
 must be undertaken on incoming packets: the destination locator has
 to be mapped back to the host's endpoint identifier.  There are a
 number of considerations whether this is best performed at the
 site-exit router when the packet is passed into the site, or by the
 local host.
 Packet header rewriting by remote network elements has a large number
 of associated security considerations.  Any packet rewriting
 mechanism has to provide proper protection against the attacks
 described in [threats], in particular against redirection attacks.

Huston Informational [Page 16] RFC 4177 Multi6 Architecture September 2005

 An alternative for packet header rewriting at the site-exit point is
 for the host to undertake the endpoint-to-locator mapping, using one
 of the approaches outlined above.  The consideration here is that
 there is a significant deployment of unicast reverse-path filtering
 in Internet environments as a counter-measure to source address
 spoofing.  Using the example in Figure 1, if a host selects a locator
 drawn from the ISP B address prefix and local routing directs that
 packet to site-exit router A, then a packet passed to ISP A would be
 discarded by such filters.  Various approaches have been proposed to
 modify the behaviour of the site forwarding environment, all with the
 end effect that packets using a source locator drawn from the ISP B
 address prefix are passed to site-exit router B.  These approaches
 include forms of source address routing and site-exit router
 hand-over mechanisms, as well as augmentation of the routing
 information between site-exit routers and local multi-homed hosts, so
 that the choice of locator by the local host for the remote host is
 consistent with the current local routing state for the local site to
 reach the remote host.

6. Approaches to Endpoint Identity

 Both the approach of the addition of an identity protocol element and
 the approach of modification of an existing protocol element assume
 some form of exchange of information that allows both parties to the
 communication to be aware of the other party's endpoint identity and
 the associated mapping to locators.  There are a number of possible
 approaches for implementing this information exchange.
 The first such possible approach, termed here a "conventional"
 approach, encapsulates the protocol data unit (PDU) passed from the
 ULP with additional data elements that specifically refer to the
 function of the EIP.  The compound data element is passed to the LLP
 as its PDU.  The corresponding actions on receipt of a PDU from a LLP
 is to extract the fields of the data unit that correspond to the EIP
 function, and pass the remainder of the PDU to the ULP.  The EIP
 operates in an "in-band" mode, communicating with its remote peer
 entity through additional information wrapped around the ULP PDU.
 This is equivalent to generic tunnelling approaches where the outer
 encapsulation of the transmitted packet contains location address
 information, while the next-level packet header contains information
 that is to be exposed and used at the location endpoints and, in this
 case, is identity information.
 Another approach is to allow the EIP to communicate using a separate
 communications channel, where an EIP generates dedicated messages
 that are directed to its peer EIP, and it passes these PDUs to the
 LLP independently of the PDUs that are passed to the EIP from the

Huston Informational [Page 17] RFC 4177 Multi6 Architecture September 2005

 ULP.  This allows an EIP to exchange information and synchronise
 state with the remote EIP semi-independently of the ULP protocol
 exchange.  As one part of the EIP function is to transform the ULP
 PDU to include locator information, there is an associated
 requirement to ensure that the EIP peering state remains synchronised
 to the exchange of ULP PDUs, so that the remote EIP can correctly
 recognise the locator-to-endpoint mapping for each active session.
 Another potential approach here is to allow the endpoint-to-locator
 mappings to be held by a third party.  This model is already used for
 supporting the name-to-IP address mappings performed by the Domain
 Name System (DNS), where the mapping is obtained by reference to a
 third party, namely, a DNS resolver.  A similar form of third-party
 mapping between endpoints and a locator set could be supported
 through the use of the DNS or a similar third party referential
 mechanism.  Rather than have each party exchange endpoint-to-locator
 mappings, this approach would obtain this mapping as a result of a
 lookup for a DNS Endpoint-to-Locator set map contained as DNS
 Resource Records, for example.

6.1. Endpoint Identity Structure

 The previous section has used the term "endpoint identity" without
 examining what form this identity may take.  A number of salient
 considerations regarding the structure and form of this identity
 should be enumerated within an architectural overview of this space.
 One possible form of an identity is the use of identity tokens lifted
 from the underlying protocol's "address space".  In other words an
 endpoint identity is a special case instance of an IPv6 protocol
 address.  There are a number of advantages in using this form of
 endpoint identity, since the suite of IP protocols and associated
 applications already manipulates IP addresses.  The essential
 difference in a domain that distinguishes between endpoint identity
 and locator is that the endpoint identity parts of the protocol would
 operate on those addresses that assume the role of endpoint
 identities, and the endpoint identity/locator mapping function would
 undertake a mapping from an endpoint "address" to a set of potential
 locator "addresses".  It would also undertake a reverse mapping from
 a locator "address" to the distinguished endpoint identifier
 "address".  The IP address space is hierarchically structured,
 permitting a suitably efficient mapping to be performed in both
 directions.  The underlying semantics of addresses in the context of
 public networking includes the necessary considerations of global
 uniqueness of endpoint identity token values.

Huston Informational [Page 18] RFC 4177 Multi6 Architecture September 2005

 It is possible to take this approach further and allow the endpoint
 identifier to also be a valid locator.  This would imply the
 existence of a "distinguished" or "home" locator, and other locators
 could be dynamically mapped to this initial locator peering as
 required.  The drawback of this approach is that the endpoint
 identifier is now based on one of the transit provider's address
 prefixes, and a change of transit provider would necessarily require
 a change of endpoint identifier values within the multi-homed site.
 An alternative approach for address-formatted identifiers is to use
 distinguished identity address values that are not part of the global
 unicast locator space, allowing applications and protocol elements to
 distinguish between endpoint identity values and locators based on
 address prefix value.
 It is also possible to allow the endpoint identity and locator spaces
 to overlap, and to distinguish between the two realms by the context
 of usage rather than by a prefix comparison.  However, this reuse of
 the locator token space for identity tokens has the potential to
 create the anomalous situation where a particular locator value is
 used as an identity value by a different endpoint.  It is not clear
 that the identity and locator contexts can be clearly disambiguated
 in every case, which is a major drawback to this particular approach.
 If identity values are to be drawn from the protocol's address space,
 it would appear that the basic choice is to either draw these
 identity values from a different part of the address space or to use
 a distinguished or home address as both a locator and an identity.
 This latter option, that of using a locator as the basis of an
 endpoint identity on a locator, when coupled with a provider-
 aggregated address distribution architecture, leads to a multi-homed
 site using a provider-based address prefix as a common identity
 prefix.  As with locator addresses in the context of a single-homed
 network, a change of provider connectivity implies a consequent
 renumbering of identity across the multi-homed site.  If avoiding
 such forced renumbering is a goal here, there would be a preference
 in drawing identity tokens from a pool that is not aligned with
 network topology.  This may point to a preference from this sector
 for using identity token values that are not drawn from the locator
 address space.
 It is also feasible to use the fully qualified domain name (FQDN) as
 an endpoint identity, undertaking a similar mapping as described
 above, using the FQDN as the lookup "key".  The implication is that
 there is no default "address" associated with the endpoint
 identifier, as the FQDN can be used in the context of session
 establishment and a DNS query can be used to establish a set of
 initial locators.  Of course, it is also the case that there may not

Huston Informational [Page 19] RFC 4177 Multi6 Architecture September 2005

 necessarily be a unique endpoint associated with a FQDN, and in such
 cases, if there were multiple locator addresses associated with the
 FQDN via DNS RRs, shifting between locators may imply directing the
 packet to a different endpoint where there is no knowledge of the
 active session on the original endpoint.
 The syntactic properties of these two different identity realms have
 obvious considerations in terms of the manner in which these
 identities may be used within PDUs.
 It is also an option to consider a new structured identity space that
 is neither generated through the reuse of IPv6 address values nor
 drawn from the FQDN.  Given that the address space would need to be
 structured to permit its use as a lookup key to obtain the
 corresponding locator set, the obvious question is what additional or
 altered characteristics would be used in such an endpoint identity
 space that would distinguish it from either of the above approaches?
 Instead of structured tokens that double as lookup keys to obtain
 mappings from endpoint identities to locator sets, the alternative is
 to use an unstructured token space, where individual token values are
 drawn opportunistically for use within a multi-homed session context.
 If such unstructured tokens are used in a limited context, then the
 semantics of the endpoint identity are subtly changed.  The endpoint
 identity is not a persistent alias or reference to the identity of
 the endpoint, but it is a means to allow the identity protocol
 element to confirm that two locators are part of the same mapped
 locator set for a remote endpoint.  In this context, the unstructured
 opportunistic endpoint identifier values are used in determining
 locator equivalence rather than in some form of lookup function.

6.2. Persistent, Opportunistic, and Ephemeral Identities

 The considerations in the previous section highlight one of the major
 aspects of variance in the method of supporting a split between
 identity and location information.
 One form uses a persistent identity field, by which it is inferred
 that the same identity value is used in all contexts in which this
 form of identity is required, in support of concurrent sessions as
 well as sequential sessions.  This form of identity is intended to
 remain constant over time and over changes in the underlying
 connectivity.  It may also be the case that this identity is
 completely distinct from network topology, so that the same identity
 is used irrespective of the current connectivity and locator
 addressing used by the site and the host.  In this case, the identity
 is persistent, and the identity value can be used as a reference to
 the endpoint stack.  This supports multi-party referrals, where, if

Huston Informational [Page 20] RFC 4177 Multi6 Architecture September 2005

 parties A and B establish a communication, B can pass A's identity to
 a third party C, who can then use this identity value to be the
 active party in establishing communication to A.
 If persistent identifiers are to be used to initiate a session, then
 the identity is used as a lookup key to establish a set of locators
 that are associated with the identified endpoint.  It is desirable
 that this lookup function be deterministic, reliable, robust,
 efficient, and trustable.  The implication of this is that such
 identities must be uniquely assigned, and experience in identity
 systems points to a strong preference for a structured identity token
 space that has an internal hierarchy of token components.  These
 identity properties have significant commonality with those of
 unicast addresses and domain names.  The further implication here is
 that persistent structured identities also rely on the adoption of
 well-ordered distribution and management mechanisms to preserve their
 integrity and utility.  Such mechanisms generally imply a significant
 overhead in terms of administrative tasks.
 As noted in the previous section, an alternative form of identity is
 an unstructured identity space, where specific values are drawn from
 the space opportunistically.  In this case, the uniqueness of any
 particular identity value is not ensured.  The use of such identities
 as a lookup key to establish locators is also altered, as the
 unstructured nature of the space has implications relating to the
 efficiency of the lookup, and the authenticity of the lookup is
 weakened due to the inability to assure uniqueness of the identity
 key value.  A conservative approach to unstructured identities limits
 their scope of utility, such as per-session identity keys.  In this
 scenario, the scope of the selected identity is limited to the
 parties that are communicating, and the scope is limited to the
 duration of the communication session.  The implication of this
 limitation is that the identity is a session-level binding point to
 allow multiple locators to be bound to the session, and the identity
 cannot be used as a reference to an endpoint beyond the context of
 the session.  Such opportunistic identities with explicitly limited
 scope do not require the adoption of any well-ordered mechanisms of
 token distribution and management.
 Another form of identity is an ephemeral form, where a session
 identity is a shared state between the endpoints, established without
 the exchange of particular token values that take the role of
 identity keys.  This could take the form of a defined locator set or
 the form of a session key derived from some set of shared attributes
 of the session, for example.  In this situation, there is no form of
 reference to or use of an identifier as a means of initiating a
 session.  The ephemeral identity value has a very limited role in
 terms of allowing each end to reliably determine the semantic

Huston Informational [Page 21] RFC 4177 Multi6 Architecture September 2005

 equivalence of a set of locators within the context of membership of
 a particular session.
 The latter two forms of identity represent an approach to identity
 that minimises management overhead and provides mechanisms that are
 limited in scope to supporting session integrity.  This implies that
 support for identity functions in other contexts and at other levels
 of the protocol stack, such as within referrals, within an
 application's data payload, or as a key to initiate a communication
 session with a remote endpoint, would need to be supported by some
 other identity function.  Such per-session limited scope identities
 imply that the associated multi-homing approaches must use existing
 mechanisms for session startup, and the adoption of a session-based
 identity and associated locator switch agility becomes a negotiated
 session capability.
 On the other hand, the use of a persistent identity as a session
 initiation key implies that identity is part of the established
 session state, and locator agility can be an associated attribute of
 the session rather than a subsequent negotiated capability.  In a
 heterogeneous environment where such identity capability is not
 uniformly deployed, this would imply that if a session cannot be
 established with a split identity/locator binding, the application
 should be able to back off to a conventional session startup by
 mapping the identity to a specific locator value and initiating a
 session using such a value.  The reason why the application may want
 to be aware of this distinction is that if the application wishes to
 use self-referential mechanisms within the application payload, it
 would appear to be appropriate to use an identity-based self-
 reference only in the context of a session where the remote party was
 aware of the semantic properties of this referential tag.
 In terms of functionality and semantics, opportunistic identities
 form a superset of ephemeral identities, although their
 implementation is significantly different.  Persistent identities
 support a superset of the functionality of opportunistic identities,
 and again the implementations will differ.
 In the context of support for multi-homing configurations, use of
 ephemeral identities in the context of locator equivalence appears to
 represent a viable approach that allows a negotiated use of multiple
 locators within the context of communication between a pair of hosts
 in most contexts of multi-homing.  However, ephemeral identities
 offer little more in terms of functionality.  They cannot be used in
 referential contexts, cannot be used to initiate communications,
 provide limited means of support for various forms of mobility, and
 impose some constraints on the class of multi-homed scenarios that
 can be supported.  Ephemeral identities are generated in the context

Huston Informational [Page 22] RFC 4177 Multi6 Architecture September 2005

 of an established communication state, and the implication in terms
 of multi-homing is that the two end points need to have discovered
 through existing mechanisms a viable pair of locators prior to
 generating an ephemeral identity binding.  The implication is that
 there is some form of static "home" for the end points that is
 discovered by conventional referential lookup.
 The use of a persistent identity space that supports dynamic
 translation between an equivalent set of locators and one or more
 equivalent identity values offers the potential for greater
 flexibility in applications.  Depending on how the mapping between
 identities and locators is managed, this may extend beyond
 multi-homing configuration to various contexts of nomadism and
 mobility as well as service-specific functions.  However, it remains
 an open question as to the nature of secure mapping mechanisms that
 would be needed in the more general context of identity-to-locator
 mapping, and it is also an open question as to how the mapping
 function would relate to viable endpoint-to-endpoint connectivity.
 It is a common aspect of identity realms that the most critical
 aspect of the realm is the nature of the resolution of the identity
 into some other attribute space.
 It appears reasonable to observe that, within certain constraints,
 multi-homing does not generically require the overhead of a fully
 distinct persistent identity space and the associated identity
 resolution functionality, and, if the nature of the multi-homing
 space in this context is to use a token to allow efficient detection
 of locator equivalence for session surviveability, then ephemeral
 identities appear to be an adequate mechanism.

6.3. Common Issues for Multi-Homing Approaches

 The above overview encompasses a very wide range of potential
 approaches to multi-homing, and each particular approach necessarily
 has an associated set of considerations regarding its applicability.
 There is, however, a set of considerations that appear to be common
 across all approaches.  They are examined in further detail in this
 section.

6.3.1. Triggering Locator Switches

 Ultimately, regardless of the method of generation, a packet
 generated from a local multi-homed host to a remote host must carry a
 source locator when it is passed into the transit network.  In a
 multi-homed situation, the local multi-homed host has a number of
 self-referential locators that are equivalent aliases in almost every
 respect.  The difference between locators is the inference that, at

Huston Informational [Page 23] RFC 4177 Multi6 Architecture September 2005

 the remote end, the choice of locator may determine the path used to
 send a packet back to the local multi-homed host.  The issue here is:
 how does the local host make a selection of the "best" source locator
 to use?  Obviously, an objective is to select a locator that
 represents a currently viable path from the remote host to the local
 multi-homed host.  Local routing information for the multi-homed host
 does not include this reverse path information.  Equally, the local
 host does not necessarily know any additional policy constraints that
 apply to the remote host and that may result in a remote host's
 preference to use one locator over another for the local host.
 Considerations of unicast reverse-path forwarding filters also
 indicate that the selection of a source locator should result in the
 packet being passed to a site-exit router that is connected to the
 associated ISP transit provider, and that the site-exit router passes
 the packet to the associated ISP.
 If the local multi-homed host is communicating with a remote
 multi-homed host, the local host may have some discretion in the
 choice of a destination locator.  The considerations relating to the
 selection of a destination locator include considerations of local
 routing state (to ensure that the chosen destination locator reflects
 a viable path to the remote endpoint) and policy constraints that may
 determine a "best" path to the remote endpoint.  It may also be the
 case that the source address selection should be considered in
 relation to the destination locator selection.
 Another common issue is the point when a locator is not considered to
 be viable and the consequences to the transport session state.
 o  Transport Layer Triggers
    A change in state for a currently-used path to another path could
    be triggered by indications of packet loss along the current path
    by transport-level signalling or by transport session timeouts,
    assuming an internal signalling mechanism between the transport
    stack element and the locator pool management stack element.
 o  ICMP Triggers
    Path failure within the network may generate an ICMP Destination
    Unreachable packet being directed back to the sender.  Rather than
    sending this signal to the transport level as an indicator of
    session failure, the IP layer should redirect the notification
    identity module as a trigger for a locator switch.

Huston Informational [Page 24] RFC 4177 Multi6 Architecture September 2005

 o  Routing Triggers
    Alternatively, in the absence of local transport triggers, the
    site-exit router could communicate failure of the outbound
    forwarding path in the case that the remote host is multi-homed
    with an associated locator set.  Conventional routing would be
    incapable of detecting a failure in the inbound forwarding path,
    so there are some limitations in the approach of using routing
    triggers to change locator bindings.
 o  Heartbeat Triggers
    An alternative to these approaches is the use of a session
    heartbeat protocol, where failure of the heartbeat would cause the
    session to seek a new locator binding that would reestablish the
    heartbeat.
 o  Link Layer Triggers
    Where supported, link layer triggers could be used as a direct and
    immediate signal of link availability, where a "Link Down"
    indication indicates the unavailability of a particular link
    [iab-link].  The limitation of this approach is that a link level
    indication is not a network broadcast event, and only the link's
    immediately-connected devices receive the link transition signal.
    While this approach may be relevant to the degenerate case of a
    multi-homed site composed of a single host, in the case of a
    multi-host site the link indication would need to be used by the
    site-exit router to generate one of the above indications for the
    host to be triggered for a locator change.  In this case this is a
    conventional form of router detection of link status.
 The sensitivity of the locator switch trigger is a consideration
 here.  A very fine-grained sensitivity of the locator switch trigger
 may generate false triggers arising from short-term transient path
 congestion, while coarse-grained triggers may impose an undue
 performance penalty on the session due to an extended time to detect
 a path failure.  The objectives for sensitivity to triggers may be
 very different depending on the transport session being used.  There
 is no doubt that any session would need a trigger to re-home if its
 path to the locator fails, but for some transports, moving, and
 triggering transport-related changes, may be far less desirable than
 reducing the sensitivity of the trigger and waiting to see if the
 triggering stimulus achieves a threshold level.
 This problem is only partly solved by models with an internal
 signalling mechanism between the transport stack element and the
 locator pool management stack element, because of non-failure

Huston Informational [Page 25] RFC 4177 Multi6 Architecture September 2005

 triggers coming from other stacks, and because of transport issues
 such as use of resource reservation.  As an example, consider the
 case of a session with reservations established by RSVP or NSIS, when
 a routing change has just caused adaptive updates to the reservation
 state in a number of elements along its path.  The transport protocol
 using the path is likely to see some delays or timeouts, and its
 reaction to these events may be a trigger for a locator change, which
 is likely to mean another reservation update.  This chaining of
 reservation updates may represent a high overhead.  The implication
 here is that individual transport protocols may have to tune any
 feedback they give as a locator change trigger, so that they don't
 respond to certain forms of transient routing change delays (not
 knowing their cause) with a locator change trigger.  It should also
 be noted that different transport protocols have rather different
 behaviors and hooks for management.

6.3.2. Locator Selection

 The selection of a locator to use for the remote end is obviously
 constrained by the current state of the topology of the network, and
 the primary objective of the selection process is to choose a viable
 locator that allows the packet to reach the intended destination
 point.  The selection of a source locator can be considered as an
 indication of preference to the remote end of a preferred locator to
 use for the local end.  However, where there are two or more viable
 locators that could be used, the selection of a particular locator
 may be influenced by a set of additional considerations.
 The selection of a particular locator from a viable locator set
 implies a selection of one particular network path in preference to
 other viable paths.  An implication of this host-based locator
 selection process is that path selection and, by inference, traffic
 engineering functions are not constrained to a network-based
 operation of path manipulation through adjustment of forwarding state
 within network elements.  There is a consequent interaction between
 the locator selection process and traffic engineering functions.  The
 use of an address selection policy table, as described in RFC 3484
 [RFC3484], is relevant to the selection process.
 The element that performs the locator selection, either as a protocol
 element within the host or as a selection undertaken at a site-exit
 router, also determines traffic policy, so the choice of using remote
 packet locator rewriting or host based locator selection shifts the
 policy capability from one element to the other.
 If hosts perform this policy determination, then a more fine-grained
 outcome may be achievable, particularly if the anticipated traffic
 characteristics of the application can be signalled to the locator

Huston Informational [Page 26] RFC 4177 Multi6 Architecture September 2005

 selection process.  A further consideration appears to be that hosts
 may require additional information if they are to make locator
 address selection decisions based on some form of metric of relative
 load currently being imposed on select components of a number of
 end-to-end network paths.  These considerations raise the broader
 issue of traffic engineering being a network function entirely
 independent of host function or an outcome of host interaction with
 the network.
 In the latter case, there is also the consideration of whether the
 host is to interact with the network, and, if so, how this
 interaction is to be signalled to hosts.

6.3.3. Layering Identity

 The consideration of triggering locator switch highlights the
 observation that differing information and context are present in
 each layer of the protocol stack.  This impacts on how
 identity/locator bindings are established, maintained, and expired.
 These impacts include questions of what amount of state is kept, by
 which element of the protocol stack, and at what level of context
 (dynamic or fixed, and per session or per host).  It also includes
 considerations of state maintenance, such as how stale or superfluous
 state information is detected and removed.  Does only one piece of
 code have to be aware of this identity/locator binding, or do
 multiple transport protocols have to be altered to support this
 functionality?  If so, are such changes common across all transport
 protocols, or do different protocols require different considerations
 in their treatment of this functionality?
 It is noted that the approaches considered here include proposals to
 place this functionality within the IP layer, with the end-to-end
 transport protocol layer and as a shim between the IP and transport
 protocol layers.
 Placing this identity functionality at the transport protocol layer
 implies that the identity function can be tightly associated with a
 transport session.  In this approach, session startup can trigger the
 identity/locator initial binding actions and transport protocol
 timeouts can be used as triggers for locator switch actions.  Session
 termination can trigger expiration of local identity/locator binding
 state.  Where per-session opportunistic identity token values are
 being used, the identity information can be held within the overall
 session state.  In the case of persistent identity token values, the
 implementation of the identity can also choose to use per-session
 state, or it may choose to pool this information across multiple
 sessions in order to reduce overheads of dynamic discovery of

Huston Informational [Page 27] RFC 4177 Multi6 Architecture September 2005

 identity/locator bindings for remote identities in the case of
 multiple sessions to the same remote endpoint.
 One of the potential drawbacks of placing this functionality within
 the transport protocol layer is that it is possible that each
 transport protocol will require a distinct implementation of identity
 functionality.  This is a considerable constraint in the case of UDP,
 where the UDP transport protocol has no inherent notion of a session
 state.
 An alternative approach is to use a distinct protocol element placed
 between the transport and internet layers of the protocol stack.  The
 advantage of this approach is that it would offer a consistent
 mapping between identities and locators for all forms of transport
 protocols.  However this protocol element would not be explicitly
 aware of sessions and would either have to discover the appropriate
 identity/locator mapping for all identity-addressed packets passed
 from the transport protocol later, irrespective of whether such a
 mapping exists and whether this is part of a session context, or have
 an additional mechanism of signalling to determine when such a
 mapping is to be discovered and applied.  At this level, there is
 also no explicit knowledge of when identity/locator mapping state is
 no longer required, as there is no explicit signalling of when all
 flows to and from a particular destination have stopped and resources
 consumed in supporting state can be released.  Also, such a protocol
 element would not be aware of transport-level timeouts, so that
 additional functionality would need to be added to the transport
 protocol to trigger a locator switch at the identity protocol level.
 Support of per-session opportunistic identity structure is more
 challenging in this environment, as the transport protocol layer is
 used to store and manipulate per-session state.  In constructing an
 identity element at this level of the protocol stack, it would appear
 necessary to ensure that an adequate amount of information is being
 passed between the transport protocol, internet protocol, and
 identity protocol elements, to ensure that the identity protocol
 element is not forced into making possibly inaccurate assumptions
 about the current state of active sessions or end-to-end network
 paths.
 It is also possible to embed this identity function within the
 internet protocol layer of the protocol stack.  As noted in the
 previous section, per-session information is not readily available to
 the identity module, so that opportunistic per-session identity
 values would be challenging to support in this approach.  It is also
 challenging to determine when identity/locator state information
 should be set up and released.  It would also appear necessary to
 signal transport-level timeouts to the identity module as a locator
 switch trigger.  Some attention needs to be given in this case to

Huston Informational [Page 28] RFC 4177 Multi6 Architecture September 2005

 synchronising locator switches and IP packet fragmentation.
 Consideration of IPSec is also necessary in this case, in order to
 avoid making changes to the address field in the IP packet header
 that trigger a condition at the remote end where the packet is not
 recognisable in the correct context.

6.3.4. Session Startup and Maintenance

 The next issue is the difference between the initial session startup
 mode of operation and the maintenance of the session state.
 In a split endpoint identifier/locator environment, there needs to be
 at least one initial locator associated with an endpoint identifier
 in order to establish an initial connection between the two hosts.
 This locator could be loaded into the DNS in a conventional fashion,
 or, if the endpoint identifier is a distinguished address value, the
 initial communication could be established using the endpoint
 identifier in the role of a locator (i.e., using this as a
 conventional address).
 The initial actions in establishing a session would be similar.  If
 the session is based on specification of a FQDN, the FQDN is first
 mapped to an endpoint identity value, and this endpoint identity
 value could then be mapped to a locator set.  The locators in this
 set are then candidate locators for use in establishing an initial
 synchronised state between the two hosts.  Once the state is
 established, it is possible to update the initial locator set with
 the current set of useable locators.  This update could be part of
 the initial synchronisation actions, or deferred until required.
 This leads to the concept of a "distinguished" locator that acts as
 the endpoint identifier, and a pool of alternative locators that are
 associated with this "home" locator.  This association may be
 statically defined, using referential pointers in a third-party
 referral structure (such as the DNS), or dynamically added to the
 session through the actions of the EIP, or both.
 If opportunistic identities are used where the identity is not a
 fixed discoverable value but one that is generated in the context of
 a session, then additional actions must be performed at session
 startup.  In this case, there is still the need for defined locators
 that are used to establish a session, but then an additional step is
 required to generate session keys and exchange these values in order
 to support the identity equivalence of multiple locators within the
 ensuing session.  This may take the form of a capability exchange and
 an additional handshake and associated token value exchange within
 the transport protocol if an in-band approach is being used, or it
 may take the form of a distinct protocol exchange at the level of the

Huston Informational [Page 29] RFC 4177 Multi6 Architecture September 2005

 identity protocol element, performed out-of-band from the transport
 session.
 Some approaches are capable of a further distinction, namely, that of
 initial session establishment and that of establishment of additional
 shared state within the session to allow multiple locators to be
 treated as being bound to a common endpoint identity.  It is not
 strictly necessary that such additional actions be performed at
 session startup, but it appears that such actions need to be
 performed prior to any loss of end-to-end connectivity on the
 selected initial locator, so that any delay in this additional state
 exchange does increase the risk of session disruption due to
 connectivity changes.
 This raises a further question of whether the identity/locator split
 is a capability negotiation performed per session or per remote end,
 or whether the use of a distinguished identity value by the upper
 level application to identify the remote end triggers the
 identity/locator mapping functionality further down in the protocol
 stack at the transport level, without any further capability
 negotiation within the session.
 Within the steps related to session startup, there is also the
 consideration that the passive end of the connection follows a
 process where it may need to verify the proposed new address
 contained in the source address of incoming packets before using it
 as a destination address for outgoing packets.  It is not necessarily
 the case that the sender's choice of source address reflects a valid
 path from the receiver back to the source.  While using this offered
 address appears to offer a low-overhead response to connection
 attempts, if this response fails the receiver may need to discover
 the full locator set of the remote end through some locator discovery
 mechanism, to establish whether there is a viable locator that can
 use a forwarding path that reaches the remote end.
 Alternatively, the passive end would use the initially offered
 locator and, if this is successful, leave it to the identity modules
 in each stack to exchange information to establish the current
 complete locator set for each end.  This approach implies that the
 active end of a communication needs to cycle through all of its
 associated locators as source addresses until it receives a response
 or exhausts its locator set.  If the other end is also multi-homed
 (and therefore has multiple locators), then the active end may need
 to cycle through all possible destination locators for each source
 locator.  While this may extend the time to confirm that no path
 exists to the remote end, it has the potential to improve the

Huston Informational [Page 30] RFC 4177 Multi6 Architecture September 2005

 characteristics of the initial exchange against denial-of-service
 attacks that could force the remote end to engage in a high volume of
 spurious locator lookups.

6.3.5. Dynamic Capability Negotiation

 The common aspect of these approaches is that they all involve
 changes to the end-to-end interaction, as both ends of the
 communication need to be aware of this separation.  The implication
 is that this form of support for multi-homing is relatively sweeping
 in its scope, as the necessary changes to support multi-homing extend
 beyond changes to the hosts and/or routers within the multi-homed
 site and encompass changes to the IPv6 protocol itself.  It would be
 prudent when considering these changes to evaluate associated
 mechanisms that allow the communicating endpoints to discover each
 other's capabilities and only enable this form of split
 identity/locator functionality when it is established that both ends
 can support it.
 It is a corollary of this form of negotiated capability that it is
 not strictly necessary that only one form of functionality can be
 negotiated in this way.  If the adoption of a particular endpoint
 identity/locator mapping scheme is the outcome of a negotiation
 between the endpoints, then it would be possible to negotiate to use
 one of a number of possible approaches.  There is some interaction
 between the approach used and the form of endpoint identity, and some
 care needs to be taken that any form of acceptable outcome of the
 endpoint identity capability negotiation is one that allows the
 upper-level application to continue to operate.

6.3.6. Identity Uniqueness and Stability

 When considering the properties of long-lived identities, it is
 reasonable to assume that the identity assignation is not necessarily
 one that is permanent and unchangeable.  In the case of structured
 identity spaces, the identity value reflects a distribution
 hierarchy.  There are a number of circumstances where a change of
 identity value is appropriate.  For example, if an endpoint device is
 moved across administrative realms of this distribution hierarchy it
 is likely that the endpoint's identity value will be reassigned to
 reflect the new realm.  It is also reasonable to assume that an
 endpoint may have more than one identity at any point in time.  RFC
 3014 [RFC3041] provides a rationale for such a use of multiple
 identities.
 If an endpoint's identity can change over time and if an endpoint can
 be identified by more than one identity at any single point in time,
 then some further characteristics of endpoint identifiers should be

Huston Informational [Page 31] RFC 4177 Multi6 Architecture September 2005

 defined.  These relate to the constancy of an endpoint identity
 within an application, and the question of whether a transport
 session relies on a single endpoint identity value, and, if so,
 whether an endpoint identity can be changed within a transport
 session, and under what conditions the old identity can continue to
 be used following any such change.  If the endpoint identity is a
 long-lived reference to a remote endpoint, and if multiple identities
 can exist for a single unique endpoint, then the question arises as
 to whether applications can compare identities for equivalence, and
 whether it is necessary for applications to recognise the condition
 where different identities refer to the same endpoint.  These
 identities may be used within applications on a single host, or they
 may be identifies within applications on different hosts.

7. Functional Decomposition of Multi-Homing Approaches

 The following sections provide a framework for the characterisation
 of multi-homing approaches through a decomposition of the functions
 associated with session establishment, maintenance, and completion in
 the context of a multi-homed environment.

7.1. Establishing Session State

 What form of token is passed to the transport layer from the
 upper-level protocol element as an identification of the local
 protocol stack?
 What form of token is passed to the transport layer from the
 upper-level protocol element as an identification of the remote
 session target?
 What form of token is used by the upper-level protocol element as a
 self-identification mechanism for use within the application payload?
 Does the identity protocol element need to create a mapping from the
 upper-level protocol's local and remote identity tokens into an
 identity token that identifies the session?  If so, then is this
 translation performed before or after the initial session packet
 exchange handshake?
 How does the session initiator establish that the remote end of the
 session can support the multi-homing capabilities in its protocol
 stack?  If the remote end cannot, does the multi-homing capable
 protocol element report a session establishment failure to the
 upper-level protocol or silently fall back to a non-multi-homed
 protocol operation?

Huston Informational [Page 32] RFC 4177 Multi6 Architecture September 2005

 How do the endpoints discover the locator set available for each
 other endpoint (locator discovery)?
 What mechanisms are used to perform locator selection at each end,
 for the local selection of source and destination locators?
 What form of mechanism is used to ensure that the selected site exit
 path matches the selected packet source locator?

7.2. Re-homing Triggers

 What are common denominator goals of re-homing triggers?  What are
 the objectives that triggers conservatively should meet across all
 types of sessions?
 Are there transport session-specific triggers?  If so, then what
 state changes within the network path should be triggers for all
 transport sessions, and what state changes are triggers only for
 selected transport sessions?
 What triggers are used to identify that a switch of locators is
 desirable?
 Are the triggers based on the end-to-end transport session and/or on
 notification of state changes within the network path from the
 network?
 What triggers can be used to indicate the direction of the failed
 path in order to trigger the appropriate locator repair function?

7.3. Re-homing Locator Pair Selection

 What parameters are used to determine the selection of a locator to
 use to reference the local endpoint?
 If the remote endpoint is multi-homed, what parameters are used to
 determine the selection of a locator to use to reference the remote
 endpoint?
 Must a change of an egress site-exit router be accompanied by a
 change in source and/or destination locators?
 How can new locators be added to the locator pool of an existing
 session?

Huston Informational [Page 33] RFC 4177 Multi6 Architecture September 2005

7.4. Locator Change

 What are the preconditions that are necessary for a locator change?
 How can the locator change be confirmed by both ends?
 What interactions are necessary for synchronisation of locator change
 and transport session behaviour?

7.5. Removal of Session State

 How is identity/locator binding state removal synchronised with
 session closure?
 What binding information is cached for possible future use?

8. Security Considerations

 There are a significant number of security considerations that result
 from the action of distinguishing within the protocol suite endpoint
 identity and locator identity.
 It is not proposed to enumerate these considerations in detail within
 this document, but to reference a distinct document that describes
 the security considerations of this domain [threats].

9. Acknowledgements

 The author acknowledges the assistance from the following reviewers:
 Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van
 Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch,
 Michael Patton, Ted Hardie, and Allison Mankin.

10. Informative References

 [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
            Stateless Address Autoconfiguration in IPv6", RFC 3041,
            January 2001.
 [RFC3484]  Draves, R., "Default Address Selection for Internet
            Protocol version 6 (IPv6)", RFC 3484, February 2003.
 [RFC3582]  Abley, J., Black, B., and V. Gill, "Goals for IPv6
            Site-Multihoming Architectures", RFC 3582, August 2003.
 [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
            in IPv6", RFC 3775, June 2004.

Huston Informational [Page 34] RFC 4177 Multi6 Architecture September 2005

 [iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer
            Indications", Work in Progress, January 2005.
 [e2e]      Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
            in System Design", ACM TOCS Vol 2, Number 4, pp 277-288,
            November 1984, <http://web.mit.edu/Saltzer/www/
            publications/endtoend/endtoend.txt>.
 [rosec]    Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
            Nordmark, "Mobile IP version 6 Route Optimization Security
            Design Background", Work in Progress, October 2004.
 [thinks]   Lear, E., "Things MULTI6 Developers should think about",
            Work in Progress, January 2005.
 [threats]  Nordmark, E. and T. Li, "Threats relating to IPv6
            multi-homing solutions", Work in Progress, January 2005.

Author's Address

 Geoff Huston
 APNIC
 EMail: gih@apnic.net

Huston Informational [Page 35] RFC 4177 Multi6 Architecture September 2005

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

Intellectual Property

 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.

Acknowledgement

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

Huston Informational [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4177.txt · Last modified: 2005/09/29 21:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki