[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Individual Submission                                          G. Huston
Internet-Draft                                                     APNIC
Expires: August 12, 2005                               February 11, 2005


      Architectural Commentary on Site Multi-homing using Level 3
                                  Shim
                    draft-huston-l3shim-arch-00.txt

Status of this Memo

         This document is an Internet-Draft and is subject to all
         provisions of section 3 of RFC 3667.  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 become
         aware will be disclosed, in accordance with RFC 3668.

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

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

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

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

         This Internet-Draft will expire on August 12, 2005.

Copyright Notice

         Copyright (C) The Internet Society (2005).

Abstract

         This document provides a commentary of the Level 3 Shim
         approach to site Multi-homing (L3Shim) as described in
         [ID.L3SHIM], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a
         framework for this analysis the approach described in
         [ID.ARCH].




Huston                  Expires August 12, 2005                 [Page 1]


Internet-Draft            Multi6 Architecture              February 2005


Notes

         This initial draft has been prepared as a commentary on the L3
         Shim proposal as developed by a Design Team of the Multi6
         Working Group.  The document attempts to provide a commentary
         on the proposal according to the framework described in the
         multi-homing architecture document.

         The L3 Shim specification is an initial pass, and there are
         areas where the documentation is incomplete.  This commentary
         is also incomplete, and will require further revision as the L3
         Shim approach is refined.

         In addition this initial draft does not analyze the properties
         of the HBA and CGA address types, and their role in providing
         some resilience against various forms of third party attacks.
         This analysis should be included in future revisions of this
         document.

































Huston                  Expires August 12, 2005                 [Page 2]


Internet-Draft            Multi6 Architecture              February 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Summary of L3Shim  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Endpoint Identity  . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Functional Decomposition . . . . . . . . . . . . . . . . . . .  8
     4.1   Establishing Session State . . . . . . . . . . . . . . . .  8
     4.2   Rehoming Triggers  . . . . . . . . . . . . . . . . . . . . 10
     4.3   Rehoming Locator Pair Selection  . . . . . . . . . . . . . 11
     4.4   Locator Change . . . . . . . . . . . . . . . . . . . . . . 12
     4.5   Removal of Session State . . . . . . . . . . . . . . . . . 13
   5.  Additional Comments  . . . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   6.1   Normative References . . . . . . . . . . . . . . . . . . . . 15
   6.2   Informative References . . . . . . . . . . . . . . . . . . . 15
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 17


































Huston                  Expires August 12, 2005                 [Page 3]


Internet-Draft            Multi6 Architecture              February 2005


      1.  Introduction

         As noted in the general architectural overview of approached to
         Multi-homing in IPv6 [ID.ARCH] document, there are a number of
         general approaches to supporting site Multi-homing.  These
         include the use of the routing system, use of mobility
         mechanisms, modification of existing elements in the protocol
         stack, or the introduction of a new protocol stack element, and
         the modification of behaviours of hosts and site-exit routers.

         This document provides an commentary of the Level 3 Shim
         approach to site Multi-homing (L3Shim) as described in
         [ID.L3SHIM], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a
         framework for this analysis the approach as described in
         [ID.ARCH].

      2.  Summary of L3Shim

         The approach used by "Level 3 Shim" (L3Shim) is, as the name
         suggests, one that is based on the modification of the Internet
         Protocol stack element within the protocol stack of the
         endpoint.  The modification is in the form of an additional
         functionality block, as indicated in Figure 1.


   +-----------------------------------------------------------------+
   | Transport Protocols                                             |
   +-----------------------------------------------------------------+
   +-----------------------------------------------------------------+
   | IP Protocol                                                s     |
   |                                                                 |
   |   IP Endpoint     ------ ------- -------------- -------------   |
   |    sub-layer      | AH | | ESP | | Frag/reass | | Dest opts |   |
   |                   ------ ------- -------------- -------------   |
   |                                   |                             |
   |   Multi6                 =====================                  |
   |    sub-layer  ========> || multi6 shim layer ||                |
   |                          =====================                  |
   |                                   |                             |
   |   IP Routing                   -------                          |
   |   sub-layer                    | IP  |                          |
   |                                -------                          |
   |                                                                 |
   +-----------------------------------------------------------------+


         L3 Shim Protocol Stack (From [ID.L3SHIM]




Huston                  Expires August 12, 2005                 [Page 4]


Internet-Draft            Multi6 Architecture              February 2005


                                Figure 1

         Above the L3Shim protocol element the protocol stack uses
         constant endpoint identities to refer to both itself and to the
         remote protocol stack.  The shim layer provider a set of
         associations between endpoint identity pairs and locator sets.

         As packets are passed from the IP Endpoint sub-layer to the IP
         Routing sub-layer, the endpoint identities are mapped to a
         current pair of locators.  The reverse mapping is applied to
         incoming packets, where the incoming locator pair is stripped
         off the packet, and the associated endpoint identity pair is
         associated with the packet which is then passed to the IP
         Endpoint sub-layer.  Demultiplexing the IP packet to the
         appropriate transport session is based on the endpoint
         identities.  In this L3Shim approach the endpoint identities
         and the locators are both IP addresses.  The endpoint
         identities are the initial addresses used between the two
         hosts.  The locators are the set of IP addresses that are
         associated with the endpoint.

         The intention of this approach is to minimise the amount of
         change required to support dynamic locator agility in the
         protocol stack, and support dynamic locator agility as a
         negotiated endpoint-to-endpoint capability.  An application can
         initiate a session with a remote host by using an entirely
         conventional lookup of the host's domain name in the DNS, and
         open up a session with the remote endpoint using one of its
         addresses as the destination address.  The application can
         continue to exchange packets with this remote host for the
         duration of the session by continuing to use this destination
         address.  If the local host subsequently opens up a new session
         with the same remote host, the same destination address may be
         used, or if the local host passes a reference to a third party
         as a referral, the same destination address may be used.  In
         terms of semantics and functionality this represented no change
         to the use of addresses as endpoint identifiers in the IPv6
         architecture.

         The Layer 3 shim operates as a per-host header address mapping
         function.  When the shim locator mapping function is activated
         for a remote endpoint packets passed from the IP endpoint
         sub-layer to the shim sub-layer have the packet's headers
         source and destination addresses rewritten with the currently
         selected locator pair.  Incoming packets passed from the IP
         Routing sub-layer undergo a similar lookup using the locator
         pair.  The packet header is rewritten with the mapped endpoint
         identifier pair is there is an active mapping entry.  This



Huston                  Expires August 12, 2005                 [Page 5]


Internet-Draft            Multi6 Architecture              February 2005


         functionality is indicated in Figure 2.  Here the endpoint
         identities are referred to as Upper Layer Identifiers (ULIDs),
         and the packet header addresses are referred to as Locators
         (L).  The L3Shim element contains a context state, associating
         a ULID pair (in this case the pair [ULID(A),ULID(B)] with a set
         of locators for A and a set of locators for B.  The shim
         elements are synchronised such that complementary mappings are
         performed at each end of the connection.


         ----------------------------          ----------------------------
         | Sender A                 |          | Receiver B               |
         |                          |          |                          |
         |     ULP                  |          |     ULP                  |
         |      |                   |          |      ^                   |
         |      | src ULID(A)       |          |      | src ULID(A)       |
         |      | dst ULID(B)       |          |      | dst ULID(B)       |
         |      v                   |          |      |                   |
         |---L3Shim-----------------|          |---L3Shim-----------------|
         |      |                   |          |      ^                   |
         |      | src L(A)          |          |      | src L(A)          |         |
         |      | dst L(B)          |          |      | dst L(A)          |
         |      v                   |          |      |                   |
         |      IP                  |          |      IP                  |
         ----------------------------          ----------------------------
                |                                     ^
                --------------- network path -- -------


         Mapping with changed locators.(From [ID.L3SHIM]

                                Figure 2

         The implication of the decision to place the endpoint
         identity-to-locator mapping protocol element within the IP
         element is that this mapping function is not implicitly aware
         of session start and tear down.  At this level of the protocol
         stack there is no information to indicate wither this packet is
         a single datagram, or the start of an extended packet exchange
         with a remote entity.  Similarly there is no explicit
         information provided to the shim protocol element to indicate
         when a session is complete, at which point the mapping state
         information could be discarded and the associated host
         resources reclaimed.  This is offset by the advantages of this
         approach in that there is no explicit need to alter the
         function of any transport protocol, as the shim element
         continues to present constant endpoint identities to the upper
         protocol levels, irrespective of the current endpoint/locator



Huston                  Expires August 12, 2005                 [Page 6]


Internet-Draft            Multi6 Architecture              February 2005


         mapping being used between the two hosts.

         Assuming that the initial choice of a ULID corresponds to a
         viable network path, the initial state of the L3Shim is a null
         mapping, as the ULID is also a viable locator.  The use of
         alternate locators by the L3Shim is a triggered response, based
         on a network path unreachability signal.

      3.  Endpoint Identity

         There are a number of options in the choice of an endpoint
         identity realm, including the use of existing addresses as an
         identity tokens, the use of distinguished (possibly
         non-routeable) addresses as tokens, or the use of tokens drawn
         from a different realm (such as use of a fully qualified domain
         name).

         L3Shim uses the first of these options, and the endpoint
         identity for a host is one of the locator addresses that are
         normally associated with the host.  The particular locator
         address selected to be the endpoint identity (or ULID) is
         specified in [RFC3484].  L3Shim does not mandate the use of
         distinguished addresses as identities, although the use
         non-routeable distinguished addresses in this context is
         described as an option in this approach.

         The L3Shim approach defines the initial selector of the locator
         addresses pair is to be the same as the ULID pair.
         Accordingly, the initial state of the multi6 shim element is a
         null transform.  This allows the initial establishment of a
         transport session without the requirement to perform a multi6
         capability negotiation.

         The choice of a locator as the endpoint identity for the upper
         protocol layers implies there is no impact in terms of implied
         changes to transport protocols or the upper level applications.
         Applications can continue to resolve fully qualified domain
         names to a set of addresses, and then open a session with the
         remote party specifying a selected address as the address of
         the remote party.  The addresses used as source and destination
         identifiers can continue to be used in the context of
         pseudo-header checksums, session demultiplexing, packet
         reassembly contexts following fragmentation, IPSEC security
         associations, callbacks and referrals, all without alteration.
         The use in callbacks and referrals can be further generalised
         to the use of these address in the application payload.
         Irrespective of any subsequent change in the locator pair, the
         protocol stack above the Level 3 shim element will continue to



Huston                  Expires August 12, 2005                 [Page 7]


Internet-Draft            Multi6 Architecture              February 2005


         use the original ULID pair, and any use of these values in
         payloads will continue to match the endpoint identities.

      4.  Functional Decomposition

      4.1  Establishing Session State

            What form of token is passed to the IP layer from the upper
            level protocol element as an identification of the local
            protocol stack?

               There is no requirement to change the conventional
               behaviour of the protocol stack.  The upper protocol
               level may use a specified address as a source address, or
               the upper level may explicitly defer the selection of a
               source address to the IP level.  Conventionally, the
               selected source address is the IP address of the outbound
               interface that the IP protocol will use to send the
               packet towards the destination address.  In the case of
               an L3Shim-enabled stack, the source address selection
               function would need to consult a local state as to
               whether the destination address is associated with a
               currently active M6 state (interpreting the destination
               address as a ULID).  In this case the selected source
               address, as seen by the upper level protocol stack
               element is the ULID of the stored state associated with
               the destination ULID.  Otherwise the selected source
               address is a selected IP address from the set of
               addresses associated with the particular host interface
               that will be used to send the packet, as happens in a
               conventional IPv6 protocol stack.

            What form of token is passed to the IP layer from the upper
            level protocol element as an identification of the remote
            session target?

               The token passed to the IP layer as the ULID of the
               destination is the address of the destination host.  If
               the initial identification of the remote host is via a
               domain name, then this approach assumes that there are a
               one or more locators held in the DNS.  The local host to
               performs a name-to-address DNS lookup to obtain a set of
               locators (recorded in the DNS using AAAA resource
               records).  The host then performs a selection from this
               set of locators and uses the selected address as the
               identification of the remote host.  This implies no
               change to the conventional behaviour of the IP protocol
               stack element.



Huston                  Expires August 12, 2005                 [Page 8]


            What form of token is used by the upper level protocol
            element as a endpoint identification mechanism for use
            within the application payload?

               There is no change to the existing behaviour in this
               approach.  The upper level protocol element may use a
               domain name, or an IP address as an identification token.

            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?

               In looking at the interface between the application level
               and the transport level of the protocol stack, there is
               no requirement to create a mapping between the upper
               level identifiers and the session identifiers, as the
               session identifiers are the same upper level identifiers.
               In looking at the interface between the transport and
               internet protocol stack elements, then the L3 Shim
               element has to check if there is an already established
               L3 Shim state that is associated with the ULIDs of the
               packet being sent.  If so, then the translation from the
               ULID pair to the currently active locator pair is
               performed by the L3Shim protocol element.  If not, then
               no state is created and no mapping is performed.  This
               infers that an initial session packet exchange handshake
               is supported without the requirement to establish an
               identity to locator mapping state.

            How does the session initiator establish that the remote end
            of the session can support the multi-homing capabilities in
            its protocol stack? If not, 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?

               The session initiator determines the ability of the
               remote end to support the L3Shim protocol via explicit
               negotiation.  The L3Shim protocol will continue to
               operate in a conventional mode if the capability
               negotiation fails for L3Shim support.  The nature of the
               communication exchange to determine the capability to use
               L3Shim support is not described in [ID.L3SHIM].

            How do the endpoints discover the locator set available for
            each other endpoint (locator discovery)?





Huston                  Expires August 12, 2005                 [Page 9]


Internet-Draft            Multi6 Architecture              February 2005


               The mechanism is by explicit exchange of locator sets
               between the hosts.  The L3Shim description does not
               describe the precise mechanism.  Section 6 of [ID.L3SHIM]
               notes that once the initial capability exchange has
               completed "both ends know a set of locators for the peer
               that are acceptable as the source in received packets."
               This explicit exchange of locators is not necessarily
               aligned to multiple AAAA Resource records in the DNS.

            What mechanisms are used to perform locator selection at
            each end for the local selection of source and destination
            locators?

               The initial choice of source and destination locators
               matches the initial choice of upper level identifiers,
               namely the initial addresses used as the upper level
               identifiers.  The remote address is obtained using
               conventional DNS lookup.  The local address is based on
               an address selection from the addresses associated with
               the outbound interface, using the procedure described in
               [RFC3484].

            What form of mechanism is used to ensure that the selected
            site exit path matches the selected packet source locator?

               This is not described in the current L3Shim description.


      4.2  Rehoming Triggers

         What triggers are used to identify that a switch of locators is
         desirable?

            The L3Shim documentation covers a number of options, but
            does not provide definitive answers to this question.  The
            [ID.FAIL] notes four approaches: namely positive feedback
            from the upper level sessions, negative feedback from the
            upper level sessions, explicit reachability tests and ICMP
            error messages.
            From the discussion in this draft it appears that negative
            feedback from upper layer transport sessions in the form of
            ACK timeouts is the preferred locator change trigger
            mechanism.


         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?



Huston                  Expires August 12, 2005                [Page 10]


Internet-Draft            Multi6 Architecture              February 2005


            [ID.FAIL] argues that network path-based triggers, in the
            form of received ICMP errors messages are prone to spoofing,
            and should only be used "as a hint to perform an explicit
            reachability test".  Triggers are based on explicit negative
            information being passed from an active transport session
            (ACK timeouts).  There is also the possibility of using
            positive feedback from the transport sessions, where a
            timeout of positive indication is an indication of a
            reachability problem.  In this case, as with ICMP, an
            explicit reachability test is required to confirm the
            indication of locator failure.


         What triggers can be used to indicate the direction of the
         failed path in order to trigger the appropriate locator repair
         function?

            The [ID.FAIL] description does not provide a description of
            detection of the failed path.  The L3Shim approach attempts
            to treat path failure as a failure of the locator pair,
            rather than failure of a single locator, so the direction of
            the failure is not necessarily critical information in the
            search for a new functional pair.


      4.3  Rehoming Locator Pair Selection

         What parameters are used to determine the selection of a
         locator to use to reference the local endpoint?

            The selection of a locator is based on the application of
            the tables as described in RFC 3484 [RFC3484].  The approach
            also allows local policy settings to place a preference for
            particular locator pairs.  Selection of a specific locator
            pair is based on the successful outcome of a return
            reachability test between the two endpoints.


         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?

            Same as the previous response.


         Must a change of an egress site exit router be accompanied by a
         change in source and / or destination locators?




Huston                  Expires August 12, 2005                [Page 11]


Internet-Draft            Multi6 Architecture              February 2005


            This appears to be an area for further study.  The situation
            is not explicitly addressed in the L3Shim documentation.


         How can new locators be added to the locator pool of an
         existing session?

            The explicit L3Shim capability negotiation allows the two
            endpoints to exchange a set of locators as part of the
            initial setup.  This set is then tested, as required, using
            explicitly reachability tests when the endpoints are
            searching for a viable locator pair.  The outcome of locator
            pair reachability tests are stored in an ageing local cache.
            This allows recently tested pairs that passed the
            reachability test to be used in preference to untested
            locator pairs.
            [ID.FAIL] describes a set of abstract message exchanges for
            L3Shim locator set maintenance that includes explicit "add"
            and Delete" commands to allow a host to instruct the remote
            end to add or remove locators from its locator set.


      4.4  Locator Change

         What are the preconditions that are necessary for a locator
         change?

            The preconditions necessary is that there has been a
            successful establishment of packets between the two hosts,
            L3Shim capabilities have been successfully negotiated and
            locator sets have been exchanged, and there is an explicit
            trigger for a locator change that has been generated by an
            active transport session.  IN addition reception of a packet
            where the locator par is a member of the locator set for
            this host pair implies a remotely-triggered locator change.


         How can the locator change be confirmed by both ends?

            The approach proposed here is by using a return reachability
            test, where a host searches through locator pair selections
            until it receives an explicit acknowledgement of a poll.


         What interactions are necessary for synchronisation of locator
         change and transport session behaviour?





Huston                  Expires August 12, 2005                [Page 12]


Internet-Draft            Multi6 Architecture              February 2005


            As noted in [ID.FAIL], there is consideration that any
            locator change in the Layer 3 shim should trigger a
            notification to the transport layer protocol.  In the case
            of TCP this notification would be used to trigger a
            resetting of the TCP congestion state to slow start,
            corresponding to the selection of a new network path.


      4.5  Removal of Session State

         How is identity / locator binding state removal synchronised
         with session closure?

            As this is a layer 3 function there is no explicit concept
            of sessions.  A L3 Shim mapping state needs to be maintained
            for as long as there is packet activity in either direction.
            The removal of state would most likely be associated with a
            removal eligibility condition associated with a packet
            activity timeout, and an eligible state removal pass being
            undertaken by the L3 Shim statement management module.


         What binding information is cached for possible future use?

            The L3 Shim state information is the association of a ULID
            pair with a set of local and remote locators.  This
            information may require periodic refreshing with the
            exchange of locator sets with the remote host in order to
            ensure that the remote host is also maintaining a L3 Shim
            state, and the locator sets are synchronised.


      5.  Additional Comments

         The approach of using a IP layer mapping between upper level
         endpoint identity and lower level locators has a number of
         specific issues that have yet to be fully specified in the
         L3Shim documentation.  Some of these are listed here.

         The signalling interface between the L3 Shim and the upper
         layers pf the protocol stack requires further consideration.
         The decision to initiate a L3Shim capability negotiation with a
         remote host may benefit from an explicit upper layer signal to
         the shim protocol element.  In turn this could allow
         applications to signal a desire to initiate this capability
         negotiation at the start of an extended communication session.
         Equally, it may be of benefit for the upper level protocol to
         be ab;e to query the L3 state for a particular remote host, to



Huston                  Expires August 12, 2005                [Page 13]


Internet-Draft            Multi6 Architecture              February 2005


         establish whether there has been a capability negotiation
         performed, and if successful, the current active locator and
         the full locator set.

         It may also be useful to allow the upper level protocol to
         explicitly indicate that any form of L3 functionality should
         not be applied to this session.  The implication of this
         functionality is that incoming packets need to provide some
         form of positive indication that the incoming locator pair
         should be mapped to an equivalent ULID pair, while packets
         without this indication should be processed in a conventional
         fashion with any L3 Shim packet header mapping.  The L3
         documentation suggests that some form of explicit tagging
         should be performed in the IPv6 Flow Id field, but further
         details have not been provided.

         The potential use of unreachable ULIDs as the initial choice of
         ULIDs and the consequent requirement to undertake a reachable
         locator search, capability negotiation and establishment of a
         L3 Shim mapping state is mentioned in the L3 Shim documents,
         but at a relatively abstract level.  This requires further
         consideration in terms of the potential failures, and the
         appropriate signalling to be passed back to the ULP in such
         cases.

         The issue of ambiguity of demultiplexing may require further
         consideration.  If there are multiple AAAA resource records in
         the DNS, or the resource records change over the lifetime of
         active communication, it is possible to have multiple L3 Shim
         states set up for the same remote host, with distinct ULIDs for
         the remote host.  An incoming packet with a given locator pair
         will, according to the L3Shim documentation, need to use the
         locator pair as a lookup key into the L3 Shim state information
         to establish the associated ULID pair.  In the case of multiple
         active ULIDs for the same remote host this lookup will result
         in multiple ULIDs.

         The treatment of trigger conditions for locator change also
         requires further consideration.  As noted in [ID.ARCH],
         different upper level transports may have different sensitivity
         requirements to locator triggers.  When the mapping is
         performed on a host=-by-host basis rather than per transport
         session, there is a consequent requirement to balance the
         relative levels of sensitivity to locator change across all
         concurrently active transport session.  It may be necessary to
         explore the concept of associating a L3 Shim state to
         particular transport sessions, allowing each session to
         establish its preferred level of sensitivity to network events



Huston                  Expires August 12, 2005                [Page 14]


Internet-Draft            Multi6 Architecture              February 2005


         that may trigger a locator change.

         The interaction between locator pair selection, local
         forwarding decision, site exit routers and packet ingress
         filters on the immediately adjacent upstream provider routers
         does not appear to be considered in the current l3 Shim
         documentation.

      6.  References

      6.1  Normative References

         [ID.ARCH]  Huston, G., "Architectural Approaches to
                    Multi-Homing for IPv6", Work in progress: Internet
                    Drafts draft-ietf-multi6-architecture-03.txt,
                    January 2005.

         [ID.FAIL]  , J., "", Work in progress: Internet Drafts
                    draft-arkko-multi6dt-failure-detection-00.txt, 2004.

         [ID.FUNC]  , M. and J. , "Functional Decomposition of the M6
                    protocol", Work in progress: Internet Drafts
                    draft-ietf-multi6-functional-dec-00.txt, 2005.

         [ID.HBA]   , M., "Hash Based Addresses (HBA)", Work in
                    progress: Internet Drafts
                    draft-ietf-multi6-hba-00.txt, 2004.

         [ID.L3SHIM]
                    , E. and M. , "Multihoming L3 Shim Approach", Work
                    in progress: Internet Drafts
                    draft-ietf-multi6-l3shim-00.txt, 2005.

         [ID.REFER]
                    , E., "Multi6 Application Referral Issues", Work in
                    progress: Internet Drafts
                    draft-ietf-multi6-app-refer-00.txt, 2005.

      6.2  Informative References

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









Huston                  Expires August 12, 2005                [Page 15]


Internet-Draft            Multi6 Architecture              February 2005


Author's Address

   Geoff Huston
   APNIC















































Huston                  Expires August 12, 2005                [Page 16]


Internet-Draft            Multi6 Architecture              February 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.







Huston                  Expires August 12, 2005                [Page 17]


Internet-Draft            Multi6 Architecture              February 2005


Acknowledgment

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















































Huston                  Expires August 12, 2005                [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/