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

Versions: 00

Shim6                                                          G. Huston
Internet-Draft                                                     APNIC
Expires: January 3, 2006                                    July 2, 2005


   Architectural Commentary on Site Multi-homing using a Level 3 Shim
                      draft-ietf-shim6-arch-00.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides an architectural description of the level 3
   shim approach to site Multi-homing in IPv6 as described in
   [ID.SHIM6], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a framework
   for this analysis the approach described in [ID.ARCH].

Notes

   This initial draft has been prepared as a commentary on the Shim6
   proposal as originally developed by a design team of the Multi6



Huston                   Expires January 3, 2006                [Page 1]

Internet-Draft             Multi6 Architecture                 July 2005


   Working Group, currently being further developed by the Shim6 Working
   Group.  The document provides am architectural description of the
   approach, using the framework described in the multi-homing
   architecture document.

   The Shim6 specification is at an initial state, and there are areas
   where the documentation is incomplete.  This architectural
   description is also incomplete at this stage, and will require
   further revision as the Shim6 approach is refined by the Shim6
   Working Group.

   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 will be included in future revisions of this document.




































Huston                   Expires January 3, 2006                [Page 2]

Internet-Draft             Multi6 Architecture                 July 2005


Table of Contents

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


































Huston                   Expires January 3, 2006                [Page 3]

Internet-Draft             Multi6 Architecture                 July 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 (Shim6) as described in [ID.SHIM6], [ID.REFER],
   [ID.FUNC], and [ID.HBA], using as a framework for this analysis the
   approach as described in [ID.ARCH].

2.  Summary of Shim6

   The approach used by "Level 3 Shim for IPv6" (Shim6) 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                                                     |
   |                                                                 |
   |   IP Endpoint     ------ ------- -------------- -------------   |
   |    sub-layer      | AH | | ESP | | Frag/reass | | Dest opts |   |
   |                   ------ ------- -------------- -------------   |
   |                                   |                             |
   |   Multi6                 =====================                  |
   |    sub-layer  ========> ||  shim6  insert    ||                 |
   |                          =====================                  |
   |                                   |                             |
   |   IP Routing                   -------                          |
   |   sub-layer                    | IP  |                          |
   |                                -------                          |
   |                                                                 |
   +-----------------------------------------------------------------+


   Shim6 Protocol Stack (From [ID.SHIM6])

                                 Figure 1



Huston                   Expires January 3, 2006                [Page 4]

Internet-Draft             Multi6 Architecture                 July 2005


   Above the Shim6 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 Shim6 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.

   Shim6 operates as a per-host header address mapping function.  When
   the Shim6 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
   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 Shim6 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



Huston                   Expires January 3, 2006                [Page 5]

Internet-Draft             Multi6 Architecture                 July 2005


   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                   |          |      |                   |
    |---Shim6-----------------|          |---Shim6-----------------|
    |      |                   |          |      ^                   |
    |      | src L(A)          |          |      | src L(A)          |
    |      | dst L(B)          |          |      | dst L(A)          |
    |      v                   |          |      |                   |
    |      IP                  |          |      IP                  |
    ----------------------------          ----------------------------
           |                                     ^
           --------------- network path -- -------

   Mapping with changed locators.(From [ID.SHIM6])

                                 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 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 Shim6 is a null mapping, as
   the ULID is also a viable locator.  The use of alternate locators by
   the Shim6 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



Huston                   Expires January 3, 2006                [Page 6]

Internet-Draft             Multi6 Architecture                 July 2005


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

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



Huston                   Expires January 3, 2006                [Page 7]

Internet-Draft             Multi6 Architecture                 July 2005


         address of the outbound interface that the IP protocol will use
         to send the packet towards the destination address.  In the
         case of an Shim6-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.

      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



Huston                   Expires January 3, 2006                [Page 8]

Internet-Draft             Multi6 Architecture                 July 2005


         identifiers are the same upper level identifiers.
         In looking at the interface between the transport and internet
         protocol stack elements, then the Shim6 element has to check if
         there is an already established Shim6 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 Shim6 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 Shim6 protocol via explicit negotiation.  The
         Shim6 protocol will continue to operate in a conventional mode
         if the capability negotiation fails for Shim6 support.  The
         nature of the communication exchange to determine the
         capability to use Shim6 support is not described in [ID.SHIM6].

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

         The mechanism is by explicit exchange of locator sets between
         the hosts.  The Shim6 description does not describe the precise
         mechanism.  Section 6 of [ID.SHIM6] 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].



Huston                   Expires January 3, 2006                [Page 9]

Internet-Draft             Multi6 Architecture                 July 2005


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


4.2  Rehoming Triggers

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

      The Shim6 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?

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





Huston                   Expires January 3, 2006               [Page 10]

Internet-Draft             Multi6 Architecture                 July 2005


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?

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


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

      The explicit Shim6 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 Shim6
      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?




Huston                   Expires January 3, 2006               [Page 11]

Internet-Draft             Multi6 Architecture                 July 2005


      The preconditions necessary is that there has been a successful
      establishment of packets between the two hosts, Shim6 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?

      As noted in [ID.FAIL], there is consideration that any locator
      change in the Shim6 state 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 Shim6 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 Shim6
      statement management module.


   What binding information is cached for possible future use?

      The Shim6 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



Huston                   Expires January 3, 2006               [Page 12]

Internet-Draft             Multi6 Architecture                 July 2005


      maintaining a Shim6 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 Shim6 documentation.  Some
   of these are listed here.

   The signalling interface between the Shim6 and the upper layers pf
   the protocol stack requires further consideration.  The decision to
   initiate a Shim6 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 able to query the L3 state for a particular
   remote host, to 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 Shim6 packet header mapping.  The Shim6
   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 Shim6 mapping
   state is mentioned in the Shim6 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 Shim6 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
   Shim6 documentation, need to use the locator pair as a lookup key



Huston                   Expires January 3, 2006               [Page 13]

Internet-Draft             Multi6 Architecture                 July 2005


   into the Shim6 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 Shim6 state to
   particular transport sessions, allowing each session to establish its
   preferred level of sensitivity to network events 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 Shim6 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-04.txt,
              February 2005.

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

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

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

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




Huston                   Expires January 3, 2006               [Page 14]

Internet-Draft             Multi6 Architecture                 July 2005


   [ID.SHIM6]
              Nordmark, E. and M. Bagnulo, "Multihoming Shim6 Approach",
              Work in progress: Internet
              Drafts draft-ietf-multi6-l3shim-00.txt, January 2005.

6.2  Informative References

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


Author's Address

   Geoff Huston
   APNIC




































Huston                   Expires January 3, 2006               [Page 15]

Internet-Draft             Multi6 Architecture                 July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Huston                   Expires January 3, 2006               [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/