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

Versions: 00

Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Expires: January 16, 2006                                       J. Arkko
                                                                Ericsson
                                                           July 15, 2005


          Functional decomposition of the multihoming protocol
                   draft-ietf-shim6-functional-dec-00

Status of this Memo

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

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

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

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

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

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

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   In this note we will present a functional decomposition of the
   multihomig protocol i.e. the protocol for preserving established
   communications in multihomed environments.  We will do so by
   describing a protocol walkthrough, presenting which functions have to
   be performed at each stage and the messages required to accomplish
   them.  The functional decomposition presented in this draft is based
   on the general functional analysis of multihoming approaches



Bagnulo & Arkko         Expires January 16, 2006                [Page 1]


Internet-Draft          Functional decomposition               July 2005


   presented in [3].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Initial contact  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Initial contact  . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Failure during startup . . . . . . . . . . . . . . . . . .  4
   3.  Capabilities detection and shim host-pair context
       establishment  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Capabilities detection . . . . . . . . . . . . . . . . . .  6
       3.1.1   Node Configuration . . . . . . . . . . . . . . . . . .  6
       3.1.2   DNS Configuration  . . . . . . . . . . . . . . . . . .  6
       3.1.3   Host-Based Dynamic Discovery . . . . . . . . . . . . .  7
       3.1.4   Timing . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2   Shim host-pair context establishment . . . . . . . . . . .  8
       3.2.1   Security Information . . . . . . . . . . . . . . . . .  9
       3.2.2   DoS protection.  . . . . . . . . . . . . . . . . . . .  9
       3.2.3   Resulting shim host-pair context establishement
               exchange . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Locator set management . . . . . . . . . . . . . . . . . . . . 11
     4.1   Security of the exchange for adding locators . . . . . . . 11
     4.2   Security of the exchange for deleting locators . . . . . . 11
   5.  Re-homing procedure  . . . . . . . . . . . . . . . . . . . . . 13
     5.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Removal of shim session state  . . . . . . . . . . . . . . . . 15
     6.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2   Informative References . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19

















Bagnulo & Arkko         Expires January 16, 2006                [Page 2]


Internet-Draft          Functional decomposition               July 2005


1.  Introduction

   In this note we will present a functional decomposition of the
   multihoming protocol i.e. the protocol for preserving established
   communications in multihomed environments.  We will do so by
   describing a protocol walkthrough, presenting which functions have to
   be performed at each stage and the messages required to accomplish
   them.  The functional decomposition presented in this draft is based
   on the general functional analysis of multihoming approaches
   presented in [3].

   We will first present some possible procedures for the initial
   contact and session state establishment.  Next, we will consider the
   management of the available locator set.  Then, we will consider the
   re-homing of an ongoing communication and finally we will deal with
   session state removal.

   This note is agnostic to the security mechanism used in protecting
   the control messages related to multihoming.  However, when it is
   deemed necessary, a security analysis that attempts to understand the
   security required for the message exchange will be included.






























Bagnulo & Arkko         Expires January 16, 2006                [Page 3]


Internet-Draft          Functional decomposition               July 2005


2.  Initial contact

2.1  Initial contact

   During the initial contact, the minimum information that has to be
   exchanged by the two communicating nodes is: the identifiers that
   have to be presented to the upper layers, and a reachable locator for
   each node.  In the case that the the identifier presented to the
   upper layers is a valid reachable locator, then only this address
   that will perform both roles has to be exchanged.  If this is the
   case, no special multihoming features are required.  This means that
   as long as the identifier and the locator used are the same IPv6
   address, there is no need to perform any special multihoming exchange
   for the initial contact and regular IPv6 can be used.  However, if an
   identifier that is different from the locator used for exchanging the
   initial packet is used, then the multihoming protocol has to be used
   even to perform the initial contact between the two nodes, starting
   by the capabilities detection procedure described in section 2.1.2.

2.2  Failure during startup

   In the case that the locator used for initial contact is unreachable,
   there are two possible approaches that can be followed:



      One approach is to simply retry the initial contact using a
      different locator.  This means that the initial contact procedure
      is started all over again, using a different locator.  This
      approach is likely to be the one required when the shim-capable
      host is establishing communications with legacy hosts that don't
      support the multihoming protocol.  In this case, the address
      included in the initial packet is both the locator and the
      identifier and if it is not reachable, an alternative address has
      to be used.  Such retrying would by default occur at the
      application layer, which is aware of the multiple addresses.  It
      might be possible to optimize this should the transport protocol
      be made aware of the multiple addresses.



      Another approach is to change locator while preserving the
      identifier.  This approach is not supported by legacy IPv6 nodes,
      so the multihoming protocol has to be used in this approach.
      However, this scheme would allow to recover from failures on
      locators used for initial contact in a upper layer transparent
      fashion.  However, if this is the case, the full multihoming
      protocol has to be used for initial contact, starting by the



Bagnulo & Arkko         Expires January 16, 2006                [Page 4]


Internet-Draft          Functional decomposition               July 2005


      capabilities detection procedure described next.


















































Bagnulo & Arkko         Expires January 16, 2006                [Page 5]


Internet-Draft          Functional decomposition               July 2005


3.  Capabilities detection and shim host-pair context establishment

   When a shim capable host desires to obtain the enhanced features
   provided by the multihoming protocol in the communications
   established with a given peer node, it has to first determine if shim
   capabilities are available in the peer node and second establish a
   shim host-pair context, as defined in [5].In this section we will
   analyze the different mechanisms to perform both actions.

3.1  Capabilities detection

   This section presents a number of possible approaches for the
   capability detection, and analyzes their properties.

3.1.1  Node Configuration

   A simplistic approach would be to require the shim capability from
   peers, if a node supports the shim and has been configured to use it.
   However, this would severely limit the ability of the node to
   communicate until the feature is widely supported.

3.1.2  DNS Configuration

   A better configuration-based approach would be to add some
   information to the DNS to tell the peers whether the target node
   supports the shim or not.  For instance, a new RR record could be
   used.  This way each node could dynamically decide whether it can run
   the shim with the peer or not.  This could often be known before
   actually attempting to communicate.

   This approach requires that every node that wishes to use the shim
   must have a DNS entry.  In addition, the ability to use shim and the
   information stored to the DNS may not always be synchronized.  For
   instance, changing the operating system might remove shim capability
   from a particular user's machine, leading to a need for updating DNS.
   This synchronization problem could be avoided by the use of Dynamic
   DNS updates -- with the implied requirements for setting up a
   security association between the DNS servers and client machines.

   Similarly, the manually updated DNS approach requires support for
   Dynamic DNS [2] where RFC 3041  [1] or other dynamically changing
   addresses are used.

   Finally, all DNS-based approaches suffer from an an administrative
   split between the actual nodes and the ones storing data about them;
   establishing Dynamic DNS or manual updates may be hard for a private
   subscriber of a large operator, for instance.




Bagnulo & Arkko         Expires January 16, 2006                [Page 6]


Internet-Draft          Functional decomposition               July 2005


   On the other hand, a DNS-based mechanism may work well if the chosen
   Multi6 protocol is based on the use of DNS, such as in NOID [4].

3.1.3  Host-Based Dynamic Discovery

   A host-based mechanism discovers the shim-capability directly between
   the communicating nodes.  Two variants of this mechanism exist:

   Independent



      This mechanism adds a message pair for the discovery.  If the peer
      responds to the message that the initiator sends, then both nodes
      know that they support the shim.

   Integrated



      This mechanism uses the rest of the shim signaling, doing both
      actual shim work and capability detection at the same time.

   In the interest of reducing number of initial communications latency,
   the second approach would be preferrable.  We also argue that a
   multihoming protocol MUST do an initial (or at least an early)
   signaling exchange in any case.  This is because the nodes need to
   discover alternate locators PRIOR to a multihoming event disabling
   the current ones.  For instance, lets assume hosts A and B
   communicate over two separate links without going through the
   Internet.  Lets further assume the nodes use plain IPv6 at the
   beginning without shim, and use one of the links and its prefix P for
   communication, with addresses P::A and P::B. If this link goes down,
   the obvious multihoming solution would be to switch to Q::A and Q::B,
   the other link and its prefix.  However, neither side is aware that
   the other node is available under the Q prefix, so communications can
   not continue.

   On the other hand, the integrated approach makes the initial packets
   larger which is a disadvantage when the peer does not support
   multihoming.  However, we do not expect the shim part of the initial
   packets to be large or contain many addresses on the average, so this
   seems like a good engineering tradeoff.

3.1.4  Timing

   Capability detection needs to occurr prior to or at the same time as
   Multi6 state is created between peers.  If the capabilities are



Bagnulo & Arkko         Expires January 16, 2006                [Page 7]


Internet-Draft          Functional decomposition               July 2005


   stored in DNS, a convenient time to look this information is at the
   time a DNS query is made (even if it may not always lead to an actual
   communication attempt later).  If host-based discovery is used, the
   best time to perform it is in the initial Multi6 exchange packets.

   The capabilities of the peer must be remembered while the shim state
   exists; the state persistence is discussed in Section 5 of [4].  The
   capabilities should preferrably be cached even beyond this, in order
   to avoid discovering the capabilities and/or locators of peers when
   they are contacted again within a small time frame.

   Negative caching should be used to remember the peers which do not
   support multihoming.  Depending on the type of the chosen capability
   detection mechanisms, this state is indexed either by an IP address
   or by both IP addresses and identifiers.  The latter becomes
   necessary if DNS configuration indicates an identifier and Multi6
   cabability, but the node refuses to communicate using the shim.

3.2  Shim host-pair context establishment

   Once that the the shim protocol support is confirmed, the ULP
   identifiers associated to the shim host-pair context need to be
   defined.

   With respect to locator exchange, it is clear that at least one
   locator (the one included in the source address field of the packet)
   is exchanged in the initial contact.  The question would be if
   additional locators are needed to be exchanged during the shim host-
   pair context  establishment phase.  Several considerations should be
   taken into account at this point: On one hand, the capability of
   recovering from an outage may depend on knowing alternative locators
   of the other node.  It is clear that a node is aware of its own
   locators, so a possible approach would be that if a failure is
   detected, the node simply tries to communicate using an alternative
   source locator.  Since  both nodes behave this way, a failure in any
   single locator used in the communication can be recovered.  However,
   in the case that both locators used in the communication fail
   simultaneously, the approach of trying different source addresses
   will not be enough to restore the communication.  This is basically
   because retrying with a different source address assumes that at
   least on of the original locators is working.  So, in order to be
   able to provide fault tolerance support in the situations when both
   locators fail simultaneously, it is required that at least one of the
   nodes is aware of multiple locators of its correspondent node.  On
   the other hand, exchanging alternative locator information imposes an
   additional overhead in the communication, which is only useful if an
   outage occurs (which is supposed not to be so frequent).




Bagnulo & Arkko         Expires January 16, 2006                [Page 8]


Internet-Draft          Functional decomposition               July 2005


   In conclusion, adding additional locators in the shim host-pair
   context establishment exchange provides enhanced fault tolerance but
   it imposes an additional cost.  A reasonable approach would be that
   the shim host-pair context establishment exchange should support the
   exchange of additional locators, but should not mandate it.  In
   addition, the multihoming protocol should support the exchange
   additional locators during the lifetime of the session.

   Besides the identifiers and locators associated to the shim session,
   it may be required to negotiate Context Tags that allow to identify
   data packets that belong to that shim host-pair context.  The need of
   such Context Tags depends on the demultiplexing mechanism used, as
   described in [5]

3.2.1  Security Information

   In addition, it seems that security related information needs to be
   exchanged during the shim host-pair context establishment exchange.

   Including a sort of cookie/key/hash chain anchor in the exchange,
   limits the potential attackers to those present in the path during
   this initial exchange.  It also implies that in order to complete the
   exchange, the other node must be receiving the reply packets.  In
   addition, such key would be useful to secure future exchanges.  So,
   it seems a good option to exchange a shared secret during the shim
   host-pair context establishment exchange.

   The exchange of additional security information may be required to
   provide protection against future attacks, depending on the security
   scheme used.

3.2.2  DoS protection.

   Depending on the mechanism used to provide protection against future
   attacks, the shim host-pair context establishment exchange may more
   or less susceptible to DoS attacks.  If the security mechanism used
   requires a considerable amount of processing, it may be used to
   launch a DoS attack consuming the processing power of the receiver.
   In addition, after the exchange is completed, a state is created in
   each node, storing information about identifiers, multiple locators,
   keys and so on.  Such state requires memory, so it can be used by a
   malicious node to generate a DoS attack based in memory consumption.
   In order to provide some protection from these attacks, the receiver
   node should not create any state until the initiating node has done
   so.  This can be achieved by using a 4 way exchange, where the
   receiver does not create any state until the third packet and the
   initiator has to prove that it has some state created after receiving
   the second packet.  This can be done by the initiator by showing some



Bagnulo & Arkko         Expires January 16, 2006                [Page 9]


Internet-Draft          Functional decomposition               July 2005


   information received in the second packet and that the receiver can
   regenerate without requiring some specific information (like hashing
   a key and the initiator address).  The result is not a complete
   protection from such attacks, since the resulting state in the
   receiver is long lived, and the attacker can discard its state after
   finishing the 4 way handshake.  However, after the 4 way handshake,
   the receiver will know a valid locator of the attacker, which can be
   used to track the attacker.

3.2.3  Resulting shim host-pair context establishement exchange


   Initiator                  Receiver
     |        P1                 |
     |-------------------------->|
     |        P2                 |
     |<--------------------------|
     |        P3                 |
     |-------------------------->|
     |        P4                 |
     |<--------------------------|


   P1 is essentially a request to initiate an exchange.  It will also be
   used to detect the shim capability of the receiver.

   P2 will provide the information needed by the initiator to prove that
   he has some state about this communication.  So, P2 will contain
   something like a Hash of a secret key of the receiver (common to all
   initiators) and the initiator's address.  The receiver will receive
   P1 and generate P2 without creating any state specific to this
   communication.  It would be possible to also include the alternative
   locators of the receiver in P2.  The question about this if this
   couldn't be used as an amplifier to launch other DoS attacks to third
   parties.

   P3 will contain the Hash obtained in P2.  In addition, it will
   contain the identifier used for this communication and it may contain
   alternative locator information.  In addition, information to
   validate the locator set may be included.  Finally, the key/cookie/
   hash chain anchor related information is also included.

   P4 serves as an acknowledgment of the information received in P3 and
   it also includes information about alternative locators, identifier
   and key/cookie/hash chain anchor related information that hasn't been
   exchanged yet.





Bagnulo & Arkko         Expires January 16, 2006               [Page 10]


Internet-Draft          Functional decomposition               July 2005


4.  Locator set management

   The management of the locator set involves adding new locators and
   removing existing locators.

   The reasons for adding a new locator are pretty straightforward:
   there is an additional locator that the holder node wants to add to
   the available set.  The reasons for that may be that a new locator is
   available in the node (e.g. a mobile node) or simply that the node
   wants to obtain enhanced fault tolerance by adding additional
   locators to the available set.

   The reasons for deleting an existing locator are essentially local.
   Nodes have local information about the status of their own locators.
   In case that one of the locators becomes unavailable for some reason
   (e.g. it is deprecated through Router Advertisement) it would make
   sense to inform the other nodes that this locator should no longer be
   used.

   There are two possible approaches to the addition and removal of
   locators: atomic and differential approaches.  Atomic approaches
   essentially send the complete locators set each time that a variation
   in the locator set occurs.  In this case, there is only one message
   exchange defined i.e. a message that informs about the new locator
   set and an acknowledgment message.  Differential messages send the
   differences between the existing locator set and the new one.  In
   this case, a message for adding a new locator and another message for
   deleting locators have to be defined.  Both messages can be
   acknowledged.  The atomic approach imposes additional overhead, since
   all the locator set has to be exchanged each time while the
   differential approach requires re-synchronization of both ends
   through changes i.e. that both ends have the same idea about what the
   current locator set is.

4.1  Security of the exchange for adding locators

   The additional locators conveyed through this mechanism should belong
   to the node that performed the initial exchange.  Security
   information must be included in this messages to prove that.  One
   possibility is to include information about the key/cookie/hash chain
   defined in the initial exchange.  This is not enough to prevent
   future attacks.  In order to provide future attack protection,
   alternative schemes like HBA or CGAs has to be used.

4.2  Security of the exchange for deleting locators

   The security required for the message for removing a locator may be
   achieved using the key/cookie/hash chain information created during



Bagnulo & Arkko         Expires January 16, 2006               [Page 11]


Internet-Draft          Functional decomposition               July 2005


   the initial contact exchange.


















































Bagnulo & Arkko         Expires January 16, 2006               [Page 12]


Internet-Draft          Functional decomposition               July 2005


5.  Re-homing procedure

   The re-homing procedure occurs when a new locator pair is to be used
   for the communication.  The reason for a re-homing is essentially
   that the current locator pair is no longer working.  The re-homing
   procedure involves detecting that the locator pair currently in use
   is no longer working, exploring alternative locator pairs and re-
   homing the communication to the reachable locator pair.

   In order to verify that a locator pair is working, a Reachability
   Test exchange is needed.  This can be used to check if the locator
   pair that is being used is working properly or to explore if
   potential locator pairs are working.  In addition, in the last case,
   the Reachability Test is also a mechanism to prevent thrid-party
   flooding attacks.

   The Reachability Test exchange includes the following packets:

      Reachability Test (RT) packet: including the random nonce and
      maybe information related to the initial key/cookie/hash chain



      Reachability Test Reply (RTR) packet: include the nonce of the RT
      packet and maybe information related to the initial key/cookie/
      hash chain

   In the case that a bidirectional path is available, the pair of
   locators contained in the RT and RTR packets will be the same.
   However, if only two disjoints unidirectional paths are available,
   the locators contained in the RT will differ from the ones included
   in the RTR.  Additional discussion on this topic can be found in [6].

5.1  Security

   In any case, it is required to know if there is a node replying at
   the other end.  The messages should include a nonce in order to match
   the replies with original messages.  In addition, the nonce should be
   randomly selected, imposing the reception of the initial message to
   be able to properly generate the reply.  Finally, including
   information related to the key/cookie/hash chain defined in the
   initial exchange would guarantee that only the node involved in the
   initial exchange can participate in the reachability exchange
   (depending on the particular mechanism, this may be more or less
   expensive) In the case that the mechanism is used to prevent third-
   party flooding attacks additional security measures are needed, since
   any shim capable host would reply to a Reachability Test request,
   precluding its usage as flooding attack prevention.  So, in order to



Bagnulo & Arkko         Expires January 16, 2006               [Page 13]


Internet-Draft          Functional decomposition               July 2005


   use this mechanism to prevent flooding, additional checks are needed.
   One option would be to include information related to the key/cookie/
   hash chain defined in the initial exchange as described above.
   Another option would be to require that nodes only reply Reachability
   Test requests coming from nodes that they are already communicating
   with.













































Bagnulo & Arkko         Expires January 16, 2006               [Page 14]


Internet-Draft          Functional decomposition               July 2005


6.  Removal of shim session state

   There are essentially two approaches for discarding an existing state
   about locators, keys and identifiers of a correspondent node: a
   coordinated approach and an unilateral approach.

   In the unilateral approach, each node discards the information about
   the other node without coordination with the other node based on some
   local timers and heuristics.  No packet exchange is required for
   this.  In this case, it would be possible that one of the nodes has
   discarded the state while the other node still hasn't.  In this case,
   an error message may be required to inform about the situation.

   In the coordinated approach, there is a closing exchange that is
   performed in order to coordinate the process, in order to make sure
   that both nodes discard the state related to the previous
   communication.  This would require a pair of messages Close and
   Close-ACK.

6.1  Security

   The Close message has to be secured using the key/cookie/hash chain
   information created during the initial contact exchange.




























Bagnulo & Arkko         Expires January 16, 2006               [Page 15]


Internet-Draft          Functional decomposition               July 2005


7.  Security considerations

   The security requirements of each message exchange considered in this
   note are detailed in the same section where the message exchange is
   analyzed.














































Bagnulo & Arkko         Expires January 16, 2006               [Page 16]


Internet-Draft          Functional decomposition               July 2005


8.  Contributors

   This document was originally produced of a MULTI6 design team
   consisting of (in alphabetical order):  Jari Arkko, Marcelo Bagnulo
   Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret
   Wasserman, and Jukka Ylitalo.













































Bagnulo & Arkko         Expires January 16, 2006               [Page 17]


Internet-Draft          Functional decomposition               July 2005


9.  References

9.1  Normative References

   [1]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [2]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
        Update", RFC 3007, November 2000.

9.2  Informative References

   [3]  Huston, G., "Architectural Approaches to Multi-Homing for IPv6",
        draft-huston-multi6-architectures-01 (work in progress),
        June 2004.

   [4]  Nordmark, E., "Multihoming without IP Identifiers",
        draft-nordmark-multi6-noid-02 (work in progress), July 2004.

   [5]  Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
        draft-nordmark-multi6dt-shim-00.txt (work in progress),
        October 2004.

   [6]  Arkko, J., "Failure Detection and Locator Selection in Multi6",
        draft-multi6dt-failure-detection-00 (work in progress),
        October 2004.


Authors' Addresses

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

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


   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@ericsson.com




Bagnulo & Arkko         Expires January 16, 2006               [Page 18]


Internet-Draft          Functional decomposition               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.




Bagnulo & Arkko         Expires January 16, 2006               [Page 19]


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