MIP6 Working Group                                        V. Devarapalli
Internet-Draft                                           Azaire Networks
Intended status: Informational                                  A. Patel
Expires: March 20, 2008                                         K. Leung
                                                                   Cisco
                                                            K. Chowdhury
                                                                 Starent
                                                      September 17, 2007


    Mobile IPv6 Bootstrapping for the Authentication Option Protocol
          draft-devarapalli-mip6-authprotocol-bootstrap-03.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 March 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The current Mobile IPv6 bootstrapping mechanisms require the use of
   IKEv2 between the mobile node and the home agent.  If the Mobile IPv6
   signaling messages are protected by the mobility option
   authentication protocol, then the bootstrapping mechanism based on



Devarapalli, et al.      Expires March 20, 2008                 [Page 1]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   IKEv2 cannot be used.  This document describes bootstrapping
   mechanisms for Mobile IPv6 when the mobility option authentication
   protocol is used.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Home Address Configuration . . . . . . . . . . . . . . . . . .  3
     3.1.  Assigned Home Address  . . . . . . . . . . . . . . . . . .  3
     3.2.  Home Address Auto-configuration  . . . . . . . . . . . . .  4
     3.3.  Home Address Request Option  . . . . . . . . . . . . . . .  4
     3.4.  Assigned Home Address Option . . . . . . . . . . . . . . .  5
   4.  Security Association Setup . . . . . . . . . . . . . . . . . .  6
     4.1.  Key Generation Mobility Options  . . . . . . . . . . . . .  7
       4.1.1.  Key Generation Nonce Request . . . . . . . . . . . . .  7
       4.1.2.  Key Generation Nonce Reply . . . . . . . . . . . . . .  8
     4.2.  Key Generation Nonce Creation and Key Derivation . . . . .  9
   5.  Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 14























Devarapalli, et al.      Expires March 20, 2008                 [Page 2]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


1.  Introduction

   The default mechanism for protecting Mobile IPv6 [2] signaling
   messages is through IKEv2 and IPsec [6].  Mobile IPv6 signaling
   messages can also be protected by using the mobility option
   authentication protocol as described in [3].  This mechanism is not a
   general authentication mechanism for Mobile IPv6, but is useful in
   certain deployments as described in the applicability section of [3].

   Mobile IPv6 bootstrap mechanisms enable a mobile node to dynamically
   configure a home agent, acquire a home address and setup security
   associations with the home agent.  Such a mechanism is defined in
   [7].  However, this mechanism uses IKEv2 to configure a home address
   and setup IPsec security associations.  This bootstrap mechanism
   cannot be used if the mobility option authentication protocol is used
   for protecting Mobile IPv6 signaling messages.

   In this document we define a bootstrap mechanism that will work when
   the mobility option authentication protocol is used.  With this
   mechanism a mobile node will be able to configure a home address and
   dynamically setup security associations with the home agent which can
   be used as specified in [3].

   This document does not define a new home agent discovery mechanism.
   Home agent discovery based in DNS lookup, as described in [7] should
   be used by the mobile node to discover a home agent.  A DHCPv6 based
   mechanism as described in [10] can also be used to discover a home
   agent.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].


3.  Home Address Configuration

3.1.  Assigned Home Address

   When the mobile node sends a Binding Update to a home agent protected
   by the mobility message authentication option and does not have a
   valid home address, it sets the home address to 0::0 in the Home
   Address Option.  The mobile node should include the Home Address
   Request Option, described in Section 3.3, in the Binding Update.  The
   mobile node MUST also include the Mobile Node Identifier option [5].
   The identity presented in the Mobile Node Identifier option is used



Devarapalli, et al.      Expires March 20, 2008                 [Page 3]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   for identifying the mobile node.

   When the home agent processes the Binding Update and notices the 0::0
   home address and the Home Address Request option, it allocates a new
   home address for the mobile node and responds with the home address
   in the Binding Acknowledgement.  The home address is carried in a new
   mobility option, the Home Address option defined in Section 3.4.

   For allocating a home address for a mobile node, the home agent could
   either locally manage an address space and allocate a home address
   from that address space, contact a DHCPv6 server on the home link for
   the home address, or obtain the home address from a AAA server.  If
   the home agent is unable to allocate a home address for the mobile
   node, it should reject the Binding Update and sent a Binding
   Acknowledgement with the status code '144' (unable to allocate a home
   address).

3.2.  Home Address Auto-configuration

   There may be a need for the mobile node to auto-configure a home
   address instead of the home agent allocating a home address.  For
   example, the mobile node may want to use privacy extensions for
   stateless address autoconfiguration as described in [8].  When the
   mobile node sends a Binding Update it is not aware of the home prefix
   to be able to configure a home address.  Instead the mobile node
   derives a 64-bit interface ID and sends it in the binding update.
   The home agent combines the home prefix and interface ID from the
   mobile node and constructs a 128-bit home address.

   For sending the interface ID to the home agent, the mobile node sets
   the home address field in the Home Address option to the 64-bit
   interface ID.  This mechanism assumes that the prefix length of the
   home prefix is 64.  This may not be a valid assumption in all
   deployments.  The auto-configuration mechanism described here will
   fail if the prefix length is anything other than 64.

3.3.  Home Address Request Option

   This option is included by the mobile node in the Binding Update to
   request for a new home address to be allocated.  This option is only
   valid in a Binding Update and has no alignment requirements.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type        |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Devarapalli, et al.      Expires March 20, 2008                 [Page 4]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   Type

      A 8-bit field indicating the type of the mobility option.

   Length

      A 8-bit field indicating the length of the option.  Set to 0.

3.4.  Assigned Home Address Option

   This option is included by the home agent in the Binding
   Acknowledgement to carry the newly allocated home address for the
   mobile node.  This option is valid only in a Binding Acknowledgement
   and has an alignment requirement of 8n + 3.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |   Type        |    Length     | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Home Address                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      A 8-bit field indicating the type of the mobility option.

   Length

      A 8-bit field indicating the length of the option.  Set to 17.

   Prefix Length

      A 8-bit field indicating the prefix length of the IPv6 prefix from
      which the home address was allocated.

   Home Address

      Set to the home address allocated by the home agent.





Devarapalli, et al.      Expires March 20, 2008                 [Page 5]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


4.  Security Association Setup

   RFC 4285 [3] decribes how to protect Mobile IPv6 signaling messages
   using pre-shared keys between the mobile and the home agent.  It
   would be useful to specify a mechanism that would dynamically create
   a shared key between the mobile node and the home agent.  In this
   document, we describe a mechanism, similar to Mobile IPv4 key
   generation [4], which allows the AAA server to generate a key that is
   delivered to the home agent and also computed by the mobile node
   using the information carried in the Binding Update and Binding
   Acknowledgement messages.

   The mechanism described here assumes that the mobile node depends on
   an AAA infrastructure to obtain authorization for mobility service
   and that there is a long lived AAA Security Association (SA) between
   the mobile node and the AAA home (AAAH) server.  This document
   specifies extensions to Binding Update and binding acknowledgement
   messages to derive a MN-HA SA from the AAA SA.  Please refer to [4]
   for a definition of security association when used in the context of
   this document.

   When the mobile node needs to send a Binding Update to its home agent
   and realizes that it does not have a security association with the
   home agent, it includes the Key Generation Nonce Request option,
   illustrated in Section 4.1.1, in the Binding Update.  The mobile node
   MUST also include MN-AAA Mobility Message Authentication option as
   described in section 5.2 of [3] and protect the Binding Update using
   the MN-AAA SA.

   When the home agent receives a Binding Update with the MN-AAA
   Mobility Message Authentication and the Key Generation Nonce Request
   options, it forwards this information to the AAAH server.  The AAAH
   server authenticates the Binding Update as described in [3].  The
   AAAH server, when it processes the Key Generation Nonce Request
   option, generates a 128 bit random value [11] to be used as the nonce
   and derives a MN-HA SA.  The AAAH server then sends this information
   to the home agent.  The AAA protocol extensions between the home
   agent and the AAAH server are out of scope for this document.

   The home agent then sends a Binding Acknowledgement to the mobile
   node.  The Binding Acknowledgement is protected by the MN-HA Mobility
   Message Authentication option using the newly created MN-HA SA.  The
   home agent also includes the Key Generation Nonce Reply option,
   illustrated in Section 4.1.2, with the information that was sent by
   the AAAH.  When the mobile node receives the Binding Acknowledgement,
   it derives the MN-HA SA using the information present in the Key
   Generation Nonce Reply option and authenticates the Binding
   Acknowledgement with the newly created MN-HA SA.



Devarapalli, et al.      Expires March 20, 2008                 [Page 6]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   The following figure illustrates the security association setup
   mechanism.


    MN                         HA               AAA Infrastructure
     |                          |                          |
     |                          |                          |
     |-----Binding Update------>|                          |
     |  (MN-ID option)          |                          |
     |  (MN-AAA auth option)    |                          |
     |  (Key Gen Nonce req)     |                          |
     |                          |--------AAA message------>|
     |                          |    (MN-AAA auth option)  |
     |                          |    (Key Gen Nonce req)   |
     |                          |                          |
     |                          |<------AAA message--------|
     |                          |    (Nonce)               |
     |                          |    (MN-HA SA)            |
     |                          |                          |
     |<----Binding Ack----------|                          |
     |  (MN-HA auth option)     |                          |
     |  (Key Gen Nonce reply)   |                          |
     |                          |                          |

   The following sections describe new mobility options to carry the key
   generation material, Key Generation Nonce creation and the actual
   MN-HA SA derivation.

4.1.  Key Generation Mobility Options

   Two new mobility options are defined in this document for the purpose
   of key generation.

4.1.1.  Key Generation Nonce Request

   The Key Generation Nonce Request is a new mobility option that is
   included in the Binding Update when the mobile node does not have a
   security association with its home agent.  This option is valid only
   in a Binding Update message and has an alignment requirement of 4n+2.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |    Type       |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Mobile Node SPI                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Devarapalli, et al.      Expires March 20, 2008                 [Page 7]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   Type

      A 8-bit field indicating the type of the mobility option.

   Length

      A 8-bit field indicating the length of the option.  Set to 4.

   Mobile Node SPI

      A 4-byte field set to the SPI that the mobile node will assign for
      the security association created for use with binding
      registration.

4.1.2.  Key Generation Nonce Reply

   The Key Generation Nonce Reply option is a new mobility option that
   is used to carry the keying material for generating the MN-HA SA.  It
   is valid only in a binding acknowledgement.  The MN-HA Key Generation
   Nonce Reply option MUST appear before the MN-HA Mobility Message
   Authentication Option.  The alignment requirement for this option is
   4n+2.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |    Type       |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Lifetime                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AAA SPI                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           HA SPI                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Algorithm Identifier      |          Replay Method        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Key Generation Nonce ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      A 8-bit field indicating the type of the mobility option.








Devarapalli, et al.      Expires March 20, 2008                 [Page 8]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   Length

      A 8-bit field indicating the length of the option excluding the
      Type and Length fields.

   Lifetime

      Indicates the duration of time (in seconds) for which the MN-HA SA
      is valid.

   AAA SPI

      A 32-bit value indicating the SPI that the mobile node must use to
      determine the transform to use for establishing the MN-HA SA.

   HA SPI

      The SPI that the home agent assigns for the MN-HA SA.

   Algorithm Identifier

      This field indicates the authentication algorithm to be used for
      calculating the authentication data in subsequent Binding Updates.
      For the different authentication algorithms, please refer to
      "Transform Type 3 (Integrity Algorithm)" at
      http://www.iana.org/assignments/ikev2-parameters.

   Replay Method

      This field contains the replay method to be used for subsequent
      Binding Updates.  For the different replay protection mechanisms,
      please refer to [9].

   Key Generation Nonce

      A random value of at least 128 bits [11].

4.2.  Key Generation Nonce Creation and Key Derivation

   The section describes how the AAAH generates the Key Generation Nonce
   and how the MN-HA SA is derived.  The AAAH server generates a random
   [11] value of 128 bits to be used as the Key Generation Nonce.  The
   AAAH server sends this nonce via the home agent through the Key
   Generation Nonce Reply option.

   The following example uses HMAC-SHA1 [12].  Other message
   authentication codes or keyed hash functions MAY also be used.  The
   particular algorithm used is configured as part of the MN-AAA



Devarapalli, et al.      Expires March 20, 2008                 [Page 9]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   Security Association between the MN and the AAAH server.

   The AAAH server and the mobile node derive the new shared key for use
   with the MN-HA SA as described below.

           key = HMAC-SHA1 (MN-AAA key, {Key Generation Nonce ||
                 mobile node identifier))

   The Key Generation Nonce is from the Key Generation Nonce Reply
   option in the Binding Acknowledgement, and the mobile node identifier
   is the identifier used by the mobile node in the MN Identifier option
   in the Binding Update [5].  The MN-AAA key is the secret key stored
   in the MN-AAA SA.

   The mobile node then creates the MN-HA SA using the resulting key and
   the other relevant information in the Key Generation Nonce Reply
   option.


5.  Mobile Node's DNS Entry Update

   If the mobile node has a DNS entry that maps its FQDN to its home
   address, the DNS entry becomes invalid if the mobile node bootstraps
   a new home address.  In order to be reachable at its new home
   address, the DNS entry of the mobile node needs to be updated.  This
   document proposes to use the DNS update mechanism described in
   section 6 of [7] to update the mobile node's FQDN with the newly
   configured home address.


6.  Security Considerations

   The home agent is required by RFC 3775 [2] to check if a mobile node
   is authorized to use a certain home address when it processes the
   Binding Update from the mobile node.  When the home agent allocates a
   home address for a mobile node it should set up some authorization
   state so that in the future it can verify if the mobile node is
   allowed to a certain home address.

   Security considerations regarding setting up the shared key between
   the mobile node and the home agent are TBD.


7.  IANA Considerations

   This document defines four new mobility options, the Home Address
   Request option, described in Section 3.3, the Home Address option,
   described in Section 3.4, the Key Generation Nonce Request option,



Devarapalli, et al.      Expires March 20, 2008                [Page 10]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   described in Section 4.1.1 and the Key Generation Nonce Reply option,
   described in Section 4.1.2.  These four options should be allocated
   from the same space used by the mobility options defined in [2].

   This document also defines a new Binding Acknowledgement status code
   to indicate that the home agent is unable to allocate a new home
   address for the mobile node.  A new Binding Acknowledgement status
   code should be defined from the same space used by the Binding
   Acknowledgement status codes in [2].


8.  Acknowledgements

   Some of the mechanisms described in this document appeared in the
   early versions of [3].  Therefore we would like to thank the authors
   of that document.

   Most of the mechanisms described in this document are based on
   solutions developed for Mobile IPv4 [9] [4].  We would like to
   acknowledge the earlier work and thank the authors of respective
   Mobile IPv4 documents.


9.  References

9.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [3]   Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
         "Authentication Protocol for Mobile IPv6", RFC 4285,
         January 2006.

9.2.  Informative References

   [4]   Perkins, C. and P. Calhoun, "Authentication, Authorization, and
         Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
         March 2005.

   [5]   Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
         "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
         RFC 4283, November 2005.

   [6]   Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with



Devarapalli, et al.      Expires March 20, 2008                [Page 11]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


         IKEv2 and the Revised IPsec Architecture", RFC 4877,
         April 2007.

   [7]   Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-07 (work in progress),
         July 2007.

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

   [9]   Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
         August 2002.

   [10]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
         progress), July 2007.

   [11]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [12]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.


Authors' Addresses

   Vijay Devarapalli
   Azaire Networks
   3121 Jay Street
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com


   Alpesh Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: alpesh@cisco.com








Devarapalli, et al.      Expires March 20, 2008                [Page 12]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


   Kent Leung
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: kleung@cisco.com


   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   USA

   Email: kchowdhury@starentnetworks.com



































Devarapalli, et al.      Expires March 20, 2008                [Page 13]


Internet-Draft    MIP6 Bootstrapping for Auth Protocol    September 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Devarapalli, et al.      Expires March 20, 2008                [Page 14]