[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-tschofenig-dime-mip6-split) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 5778

Diameter Maintenance and                              J. Bournelle (Ed.)
Extensions (DIME)                                                GET/INT
Internet-Draft                                               G. Giaretta
Expires: December 21, 2006                                Telecom Italia
                                                           H. Tschofenig
                                                                 Siemens
                                                           June 19, 2006


     Mobile IPv6 Bootstrapping using Diameter in the Split Scenario
                     draft-ietf-dime-mip6-split-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 December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In Mobile IPv6 deployment a need for an interaction between the Home
   Agent, the AAA infrastructure of the Mobile Service Provider (MSP)
   and the Mobility Service Authorizer (MSA) has been identified.  This
   document describes how Diameter can be used to perform AAA
   functionalities for the Mobile IPv6 service in the "split" scenario.



Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 1]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


   For this, it describes two possible approaches.  It also explains how
   Diameter meet the goals outlined in the MIPv6 AAA goals document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Bootstrapping Mobile IPv6 in the Split Scenario  . . . . . . .  3
   4.  Use of Diameter EAP for the Mobile IPv6 Split Scenario . . . .  5
     4.1.  NAS-Port-Type AVP  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  A new Application ID . . . . . . . . . . . . . . . . . . .  6
     4.3.  Accounting for the Mobile IPv6 Service . . . . . . . . . .  6
   5.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  General goals  . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  G1.1 - G1.4 Security . . . . . . . . . . . . . . . . .  7
       5.1.2.  Dead peer detection - the HA-AAA interface SHOULD
               support inactive peer detection. . . . . . . . . . . .  7
     5.2.  Service Authorization  . . . . . . . . . . . . . . . . . .  8
       5.2.1.  G2.1. The HA-AAA interface SHOULD allow the use of
               Network Access Identifier (NAI) to identify the
               mobile node. . . . . . . . . . . . . . . . . . . . . .  8
       5.2.2.  G2.2. The HA SHOULD be able to query the AAAH
               server to verify Mobile IPv6 service authorization
               for the mobile node. . . . . . . . . . . . . . . . . .  8
       5.2.3.  G2.3. The AAAH server SHOULD be able to enforce
               explicit operational limitations and authorization
               restrictions on the HA.( e.g. packet filters, QoS
               parameters). . . . . . . . . . . . . . . . . . . . . .  8
       5.2.4.  G2.4 - G2.6. Issues addressing the maintenance of
               a Mobile IPv6 session by the AAAH server, e.g.
               authorization lifetime, extension of the
               authorization lifetime and explicit  session
               termination by the AAAH server side. . . . . . . . . .  8
     5.3.  Accounting - G3.1. The HA-AAA interface MUST support
           the transfer of accounting records needed for service
           control and charging . . . . . . . . . . . . . . . . . . .  9
     5.4.  Mobile Node Authentication (G4.1.) . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 2]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


1.  Introduction

   In Mobile IPv6 deployment, authentication, authorization and
   accounting issues in the protocol operations are approached by using
   the AAA infrastructure. [9] presents a number of bootstrapping
   scenarios using the HA-AAA interface and defines a list of
   requirements that have to be fulfilled.  This document deals with the
   functional capabilities of the Diameter protocol as a AAA protocol
   applicable for the split scenario.

   This document focuses only on the split scenario.  A separate
   document [10] describes a Diameter application for bootstrapping
   MIPv6 for the integrated scenario.


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 RFC 2119 [1].

   The MIPv6 bootstrapping terminology is taken from [2].


3.  Bootstrapping Mobile IPv6 in the Split Scenario

   In the split scenario for bootstrapping Mobile IPv6 [3], the Mobile
   Node (MN) discovers a Home Agent (belonging to the Mobility Service
   Provider (MSP)) through DNS.  Then, the Mobile Node uses IKEv2 [4] to
   setup IPsec SAs.  Use of IKEv2 also provides a way to authenticate
   the MN by the Mobility Service Authorizer (MSA).  Note that in the
   same time, the Mobile Node can authenticate the Home Agent.  IKEv2
   supports the Extensible Authentication Protocol (EAP) to run an EAP
   method between the MN and the EAP server that is often separated from
   the IKEv2 responder, i.e., the HA in our scenario.  As such, the MN
   can reuse its credentials (obtained from the MSA) to be authenticated
   for the IPv6 mobility service.  As outlined in [4] a HA-AAA interface
   is needed.  Since, EAP is used to authenticate the MN, the interface
   between the Home Agent and the AAA server will be based on the
   Diameter EAP application [5].  Figure 1 represents the architecture
   of the split scenario.

   +-------+    IKEv2    +----------------+    Diameter EAP      +----+
   | Mobile|             |  Home Agent/   |                      |    |
   |  Node |<----------->| Diameter Client|<-------------------->|AAAH|
   +-------+             +----------------+                      +----+

   Figure 1: Diameter EAP for HA-AAA in the Split Scenario



Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 3]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


   The Mobile Node acts as the EAP client and IKEv2 Initiator.  The Home
   agent is the IKEv2 Responder and acts a Diameter client from a AAA
   perspective.  The AAAH is the home AAA server of the MN (i.e.  AAA
   server of the MSA) and relies on a EAP server to authenticate the
   Mobile Node.  If MSP is different from the MSA, the Home Agent may
   directly contact the AAAH or a local AAA server which will act as a
   AAA proxy (cf. [5]).

   Figure 2 shows the message flow.


   Mobile Node              HA/Diameter Client       Home AAA/EAP Server
   ----------                -----------------       -------------------
            IKE_SA_INIT     (1,2)
   <------------------------------>

    HDR, SK{IDi,[CERTREQ,] [IDr,]
            SAi2, TSi, TSr}  (3)
   ------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
                                       DEA (EAP-Request)
                                    <------------------------
    HDR, SK {IDr, [CERT,] AUTH,
             EAP }
   <-------------------------------
    HDR, SK {EAP}
   -------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
                                       DEA (EAP-Request)
                                    <------------------------
    HDR, SK{EAP-Request}
   <-------------------------------
    HDR, SK{EAP-Response}
   -------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
             ...                           ...

                                       DEA (EAP-Success)
                                    <------------------------
    HDR, SK{EAP-Success}
   <-------------------------------
    HDR, SK{AUTH}
   ------------------------------->
    HDR, SK {AUTH, SAr2, TSi, TSr }
   <-------------------------------



Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 4]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


   Figure 2: IKEv2 Diameter EAP Message Flow

   The interaction between the MN and the HA starts with an IKE_SA_INIT
   to setup the IKE SA.  The MN indicates its desire to use EAP by not
   including the AUTH payload in the third message.  The MN indicates
   its identity (e.g Network Access Identitifer) using the IDi field.
   If the Home Agent, acting as an IKEv2 Responder, supports EAP for
   authentication and relies on a remote AAA server, the Diameter client
   part of the Home Agent sends a Diameter-EAP-Request (DER) message
   containing the identity in the EAP-Payload AVP and in the User-Name
   AVP.  The AAAH chooses an authentication method and sends the first
   EAP-Request in the Diameter-EAP-Answer message.  During the EAP
   authentication phase, the HA relays EAP packets between the MN (EAP
   client) and the AAAH (Home EAP server).  If the authentication
   succeeds and if the MN is authorized to use Mobile IPv6 service, the
   AAAH sends a DEA message containing the EAP-success and the AAA-Key
   derived from the Master Session Key (MSK) exported by the EAP method.
   Some specific configuration elements may also be sent in AVPs.  Note
   that EAP methods that do not derive keys are not recommended since
   they cannot bind the EAP method authentication to the IKEv2
   authentication.  In the latter message, the MN and the HA finalize
   the IPsec SAs setup to protect Mobile IPv6 signalling.


4.  Use of Diameter EAP for the Mobile IPv6 Split Scenario

   In the split scenario, the Home Agent uses the AAA infrastructure in
   order to perform authentication, authorization and accounting for the
   Mobile IPv6 service.  This document proposes to reuse the Diameter
   EAP application [5] since EAP is used by the HA to authenticate the
   MN inside IKEv2.

   However, the Diameter EAP application has been designed to perform
   AAA for the network access service.  As the Mobile IPv6 service is
   different from the network access service, it appears that a Diameter
   server needs a way to make this distinction.  Indeed, even if the
   authentication is provided by the EAP method, authorization and
   accounting for network access and IPv6 mobility might be different.
   The AAA server needs to explicitly authorize the Mobile IPv6 service.
   It may also need to configure specific parameters for the Mobile IPv6
   service such as the type of Home Address to provide to the MN.
   Accounting may also require other parameters than those defined for
   network access.

   [Editor's Note: It is not clear at this point of time which approach
   is the best to handle this.  For this reason, this document explains
   two possible approaches.]




Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 5]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


4.1.  NAS-Port-Type AVP

   As explained below, the AAA server needs a way to identify that it is
   performing AAA operations for the Mobile IPv6 service.  One way to do
   this is to require that the Home Agent puts the NAS-Port-Type AVP
   indicating that it is a Mobile IPv6 Home Agent in the first DER
   message.  This would be formulated as: "The Home Agent MUST include
   the NAS-Port-Type AVP".  This requires a change in the current ABNF
   definition of this message.  The AAA server would have to check the
   presence of this AVP in the first received DER message and would have
   to recognize the new type defined for the Home Agent.

   [Editor's Note: It is not clear at this point of time if this change
   in the ABNF definition would require a new Application-Id.]

   Moreover, the NAS-Port-Type AVP is defined as: "The NAS-Port-Type AVP
   (AVP Code 61) is of type Enumerated and contains the type of the port
   on which the NAS is authenticating the user.  This AVP SHOULD be
   present if the NAS uses the same NAS-Port number ranges for different
   service types concurrently" (see [6]).  Hence, if the DIME WG decides
   to use this approach, it is necessary to define a new type for Home-
   Agent.

   If an operator wants to use one AAA server for network access and
   another one for IPv6 mobility service then the some messages may be
   routed to the wrong AAA server since routing is also based on the
   Application-ID.

4.2.  A new Application ID

   The second approach is to require a new application ID for the Mobile
   IPv6 service.  In this case, all messages will be correctly routed to
   the right Diameter Application.  This specific application will
   specifically handle all AAA Operations for the Mobile IPv6 service as
   it is done for Mobile IPv4 (cf. [7]).  However, the protocol
   description requires that the new application needs to copy the
   Diameter messages from the Diameter EAP application.

   The problem with defining a new Application ID is that every proxies
   on the path would need a new code to understand this application.

4.3.  Accounting for the Mobile IPv6 Service

   Concerning Accounting, the Diameter Mobile IPv4 Application [7]
   defines the following AVPs: Accounting-Input-Octets (Number of octets
   in IP packets received from the user), Accounting-Output-Octets
   (Number of octets in IP packets sent by the user, Accounting-Input-
   Packets (Number of IP packets received from the user), Accounting-



Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 6]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


   Output-Packets (Number of IP packets sent by the user).

   These AVPs may be re-used for the Mobile IPv6 service.  However, due
   to some optimizations for Mobile IPv6, the HA may not see all the IP
   traffic resulting from the activation of this service.

   [Editor's Note: As the document describing goals for this interface
   is not finalized, other parameters may be needed in the future.]


5.  Goals

   In this section, we present how the goals for a HA-AAA interface
   presented in [9] are met by this proposal.  Note that the two
   approaches presented above does not affect what is described here.

   [Editor's Note: the goals presented here are those described in [9].
   Future revision of the mentionned document will affect this section.]

5.1.  General goals

5.1.1.  G1.1 - G1.4 Security

   As design goals for an AAA interface, G1.1 - G1.4 goals specify
   standard requirements for a AAA protocol - mutual authentication of
   the peers, integrity, replay protection and confidentiality.  The
   Diameter Base Protocol requires IPsec or TLS to provide hop-by-hop
   security.

5.1.2.  Dead peer detection - the HA-AAA interface SHOULD support
        inactive peer detection.

   Two possible approaches might be considered here:

   o  The AAAH server and the Home Agent establish a transport
      connection between each other.  It is the case if the Diameter
      Client of the HA has a direct route to its AAA server.  In this
      case Diameter heartbeat messages called Device-Watchdog-Request/
      Answer [8], which are exchanged over this connection to test for
      its aliveness, can be used to detect inactivity between the two
      Diameter peers.

   o  The AAAH server and the Home Agent do not have transport
      connection.  In this case inactive peer detection functionality
      should be provided into the Diameter session - service stateless
      Diameter sessions might be established between the AAAH server and
      the range of MSP's Home Agents for detecting HAs availability.




Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 7]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


5.2.  Service Authorization

5.2.1.  G2.1. The HA-AAA interface SHOULD allow the use of Network
        Access Identifier (NAI) to identify the mobile node.

   Identification by the User-Name AVP [8], which has a format
   consistent with the NAI specifications, is common for Diameter
   applications.  Diameter provides functionality for routing of
   Diameter requests based on the information included in the User-Name
   AVP.

   The Mobile Node provides its NAI using the IDi field during the IKEv2
   exchange with the HA.

5.2.2.  G2.2. The HA SHOULD be able to query the AAAH server to verify
        Mobile IPv6 service authorization for the mobile node.

   The goal of this document is to explain how to use Diameter to
   perform AAA operations for the Mobile IPv6 service.  The
   Authentication is done through the use of EAP.  The Mobile IPv6
   service Authorization is an explicit goal of this document.

   [Editor's note: As explained above, how the AAA server know that it
   is for Mobile IPv6 service has not yet been decided by the DIME WG.]

5.2.3.  G2.3. The AAAH server SHOULD be able to enforce explicit
        operational limitations and authorization restrictions on the
        HA.( e.g. packet filters, QoS parameters).

   Several present Diameter applications, standardized or under work-in-
   progress address an operation and authorization control for specific
   services and have defined appropriate AVPs.  The NAS-Filter-Rule AVP,
   defined by Diameter NASREQ application [6], provides IP packet filter
   description.  QoS-Filter-Rule AVP defined by Diameter NASREQ
   application and by the Diameter QoS application [11] provide QoS
   parameter description.  The Credit Control application [12] provides
   support for prepaid services, tariff switching, cost control over
   requested services.  The available funcationalities might be re-used
   in this document.

5.2.4.  G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6
        session by the AAAH server, e.g. authorization lifetime,
        extension of the authorization lifetime and explicit  session
        termination by the AAAH server side.

   Diameter base protocol provides a powerful set of commands and AVPs
   for management of the authorization and accounting sessions.  A
   number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout-



Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 8]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


   AVP) handle the duration (in time) of an authorization session [8].
   Additional AVPs for measuring the authorization duration in units
   different that time are specified too [12].  Exchanging of
   application specific authorization request/answer messages provides
   extension of the authorization session.  Initiation of the re-
   authorization by both sides could be supported.  Both sides could
   initiate session termination, by using Diameter Session Termination
   and Abort Session messages.

   All these are applied to the Diameter session used for authorization
   of a Mobile IPv6 session and need to be applied appropriately to this
   Mobile IPv6 session too.

5.3.  Accounting - G3.1. The HA-AAA interface MUST support the transfer
      of accounting records needed for service control and charging

   Diameter accounting protocol provides a variety of options - real-
   time accounting, event/session-type accounting records, fault
   resilience, correlation of accounting records.  Requirements for the
   accounting services over AAAH-HA interface are standard.  Definition
   or re-used of AVPs for the specific accounting records combined with
   the functionality of the Diameter accounting protocol should provide
   desired accounting services.

5.4.  Mobile Node Authentication (G4.1.)

   These issues require the functionality of AAAH server working as a
   back-end authentication server and HA working as NAS and EAP
   authenticator in pass-through mode for providing a mobile node
   authentication.  This functionality is provided by the Diameter
   NASREQ [6] and the Diameter EAP applications [5] application, and
   will be re-used in this document.


6.  Security Considerations

   [Editor's Note: Since the document is not complete it is necessary to
   state that the security consideration section is incomplete as well.
   Hence, it is only possible to refer to the security issues raised in
   the Mobile IPv6 and Diameter protocol related documents mentioned
   here, such as [9] and [8].]


7.  IANA Considerations

   [Editor's note: Since the document is not complete, the IANA
   considerations is incomplete as well.]




Bournelle (Ed.), et al.  Expires December 21, 2006              [Page 9]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


8.  Acknowledgements

   The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi
   Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen,
   Avi Lior, John Loughney, Lionel Morand and Yoshihiro Ohba for their
   inputs to the "Application-ID for the Mobile IPv6 split scenario ?"
   discussion.


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]  Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
        Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
        progress), May 2006.

   [3]  Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
        draft-ietf-mip6-bootstrapping-split-02 (work in progress),
        March 2006.

   [4]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

   [5]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
        Authentication Protocol (EAP) Application", RFC 4072,
        August 2005.

   [6]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
        Network Access Server Application", RFC 4005, August 2005.

   [7]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P.
        McCann, "Diameter Mobile IPv4 Application", RFC 4004,
        August 2005.

   [8]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

9.2.  Informative References

   [9]   Giaretta, G., "Goals for AAA-HA interface",
         draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
         January 2006.

   [10]  Tschofenig, H., "Diameter MIPv6 Application for the Integrated



Bournelle (Ed.), et al.  Expires December 21, 2006             [Page 10]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


         Scenario", draft-tschofenig-dime-mip6-integrated-00 (work in
         progress), March 2006.

   [11]  Alfano, F., "Diameter Quality of Service Application",
         draft-tschofenig-dime-diameter-qos-00 (work in progress),
         March 2006.

   [12]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
         Loughney, "Diameter Credit-Control Application", RFC 4006,
         August 2005.

   [13]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
         the Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
         progress), June 2006.




































Bournelle (Ed.), et al.  Expires December 21, 2006             [Page 11]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


Authors' Addresses

   Julien Bournelle
   GET/INT
   9 rue Charles Fourier
   Evry  91011
   France

   Email: julien.bournelle@int-evry.fr


   Gerardo Giaretta
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   TORINO,   10148
   Italy

   Email: gerardo.giaretta@telecomitalia.it


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com























Bournelle (Ed.), et al.  Expires December 21, 2006             [Page 12]

Internet-Draft      MIP6 Bootstrapping with Diameter           June 2006


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




Bournelle (Ed.), et al.  Expires December 21, 2006             [Page 13]


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