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

Versions: 00

NETLMM WG                                                    J. Korhonen
Internet-Draft                                               TeliaSonera
Intended status: Standards Track                              A. Muhanna
Expires: August 21, 2008                                 Nortel Networks
                                                       February 18, 2008


       Policy Profile and AAA Interfaces Requirements for PMIPv6
                draft-korhonen-netlmm-pp-aaa-reqs-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 August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This specification defines the Policy Profile and AAA interfaces
   requirements for the Proxy Mobile IPv6.  The Policy Profile
   information needed by the Proxy Mobile IPv6 may be statically
   provisioned in the mobile access gateway and in the local mobility
   anchor.  Alternatively, the Policy Profile information or a subset of
   its parameters can be dynamically downloaded to the mobile access
   gateway from the AAA server during the mobile node access



Korhonen & Muhanna       Expires August 21, 2008                [Page 1]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   authentication and authorization when the mobile node roams into a
   Proxy Mobile IPv6 domain.  The local mobility anchor may download the
   user policy profile parameters during the Proxy Mobile IPv6
   registration process.  This document describes the requirements for
   the Proxy Mobile IPv6 Policy Profile and the corresponding AAA
   interfaces.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Policy Profile . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Policy Profile and Storage Requirements  . . . . . . . . .  7
   5.  Mobility Service Setup . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Generic Service Setup Requirements . . . . . . . . . . . .  8
     5.2.  Initial Dynamic LMA Discovery Requirements . . . . . . . .  9
     5.3.  LMA Discovery After a Handover Requirements  . . . . . . .  9
     5.4.  MAG to LMA Security Association Setup Requirements . . . . 10
     5.5.  Generic LMA to AAA Requirements  . . . . . . . . . . . . . 10
     5.6.  Generic MAG to AAA Requirements  . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





















Korhonen & Muhanna       Expires August 21, 2008                [Page 2]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


1.  Introduction

   In the Proxy Mobile IPv6 (PMIPv6) protocol [1] and PMIPv6 IPv4
   support [2], a Mobile Access Gateway (MAG) performs a proxy
   registration with a Local Mobility Anchor (LMA) on behalf of the
   mobile node (MN).  In order to perform the proxy registration, the
   PMIPv6 MAG needs the address of the LMA, MN's home network prefix
   (MN-HNP), possibly MN's IPv4 home address (IPv4-HoA), DHCP server
   address and other PMIPv6 specific information such as allowed address
   configuration modes, bearer plane security requirements, and possible
   roaming related policies.  All this information is defined in MN's
   Policy Profile (PP) that could be downloaded from a remote Policy
   Store (PS) using the AAA infrastructure or statically configured in
   the MAG and/or the LMA.

   Dynamic assignment and downloading of PMIPv6 Policy Profile
   information is a desirable feature to ease the deployment and network
   maintenance of large PMIPv6 deployments.  For this purpose, the AAA
   infrastructure which is used for access authentication, can be
   leveraged to assign some or all of the necessary policy profile
   parameters.  The AAA server in the Mobility Service Authorizer's
   (MSA) or in the Mobility Service Provider's (MSP) network may return
   these parameters to the Network Access Server (NAS).  The NAS may be
   either co-located with MAGs or an integral part of a MAG.

   This specification defines the requirements for the PMIPv6 Policy
   Profile, the Policy Store and the AAA interfaces interactions.


2.  Terminology and Abbreviations

   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 RFC2119 [3].

   General mobility terminology can be found in [4] and [1].  The
   following additional or clarified terms are used in this document:

   Network Access Server (NAS):

      A device that provides an access service for a user to a network.
      In the context of this document the NAS may be integrated into or
      co-located with a MAG.  The NAS contains a Diameter client
      function.







Korhonen & Muhanna       Expires August 21, 2008                [Page 3]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   Home AAA (HAAA):

      An authentication, authorization and accounting server located in
      user's home network.  A HAAA is essentially a Diameter server.

   Policy Profile (PP)

      A user subscription policy profile contains the essential
      operational parameters that are required by the network entities
      for managing the mobile node's network-based mobility service.
      These policy profiles are stored in a local or a remote policy
      store.

   Policy Store (PS):

      A node that contains the policy profile of a subscriber.  The
      policy store may be co-located with the Mobile Access Gateway, the
      Local Mobility Anchor or the AAA server.  When the Policy Store is
      co-located with the HAAA server it can be queried by using an AAA
      infrastructure.


3.  Overview

   This document addresses the authentication, authorization, accounting
   and session management functionality needed by the PMIPv6 protocol.
   It also defines the requirements of a diameter based MAG to HAAA and
   LMA to HAAA interfaces.  The intention of this document is to define
   the requirements which may extend existing Mobile IPv6 specifications
   such as [5] and define needed additional AVPs and functionality to
   fulfill the needs of the PMIPv6 deployment.

   The policy profile download from the HAAA to the MAG is part of the
   network access authentication procedure when a MN roams into or
   within a PMIPv6 Domain.  Figure 1 shows the participating network
   entities.  This document, however, only concentrates on the MAG, LMA,
   possible local Diameter proxies and the home Diameter server.  When
   aligned with [5] the MAG acts as the NAS located in ASP, the HAAA
   acts as the Diameter server located in ASA/MSA/MSP and the LMA acts
   as the HA in ASP/MSP.











Korhonen & Muhanna       Expires August 21, 2008                [Page 4]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


       +--------+
       | HAAA & |   AAA    +-----+
       | Policy |<-------->| LMA |
       | Profile|          +-----+
       +--------+            | <--- LMA-Address
           ^                 |
           |               // \\
        +--|------------- //---\\----------------+
       (   |  IPv4/IPv6  //     \\                )
       (   |   Network  //       \\               )
        +--|-----------//---------\\-------------+
           |          //           \\
      AAA  |         // <- Tunnel1  \\ <- Tunnel2
           |        //               \\
           |        |- MAG-Address1   |- MAG-Address2
           |     +----+             +----+
           +---->|MAG1|             |MAG2|
                 +----+             +----+
                    |                 |
                    |                 |
                  [MN1]             [MN2]



    Figure 1: Proxy Mobile IPv6 Domain with MAG and LMA Interfaces with
                                   HAAA

   In a PMIPv6 access scenario a MN attaches to a PMIPv6-Domain and
   starts a network access authentication procedure.  The choice of
   authentication mechanism is specific to the access network
   deployment, but could be based on the Extensible Authentication
   Protocol (EAP) [6].  During the network access authentication
   procedure, the MAG acting as a NAS queries the HAAA through the AAA
   infrastructure using the Diameter protocol.  If the HAAA detects that
   the subscriber is also authorized for the PMIPv6 service, the
   subscriber policy is returned along with the successful network
   access authentication answer to the MAG.

   After the mobile node is successfully authenticated and the MAG
   receives the policy profile parameters during the access
   authentication procedure the MAG sends a PBU to the LMA.  Upon
   receiving the PBU the LMA may interact with the HAAA and fetches the
   relevant subscriber policy, authorization and security information
   related to the PMIPv6 session.  This specification assumes that the
   HAAA is the central node for managing all PMIPv6 subscription and
   session related activities which may even include the allocation of
   prefixes.




Korhonen & Muhanna       Expires August 21, 2008                [Page 5]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   Prior to sending the PBU there might be a need to dynamically setup
   the MAG to LMA Security Association (SA), for example using IKEv2/
   IPSec [7].  The dynamic SA setup procedure may be triggered by the MN
   attaching to the MAG that does not have existing SA with the
   correspondent LMA.  The details of the dynamic SA setup procedure is
   out of scope of this specification.  However, the SA is between the
   MAG and the corresponding LMA, thus it can be created using any
   security mechanism that is applicable for PMIPv6 security such as
   IKEv2 IPSec with an EAP-based authentication.  It should be noted
   that the identity used by MAG during the SA creation is the MAG's own
   identity and the credentials are for authenticating the MAG toward
   the LMA and the MAG authorization to send Proxy BU on behalf the
   mobile nodes.


4.  Policy Profile

   A MN's Policy Profile contains the essential operational parameters
   that are required by the network entities for managing the MN's
   mobility service.  In the context of this documents, we only address
   the Policy Profile parameters that are essential for PMIPv6.
   However, in live network deployments the Policy Profile may also be
   populated with parameters that are not directly related to PMIPv6
   operation but required by the operator.  This document makes an
   assumption that these Policy Profiles are stored in a remote Policy
   Store that could be co-located with the MN's home AAA server and
   accessed through an AAA interface.  The same AAA interface is also
   used for authenticating the MN when it attaches to the MAG and the
   PMIPv6 Domain.  The Policy Profile has both static and dynamically
   updated parameters.  The dynamic parameters may change per PMIPv6
   session basis or during the session to reflect the current status of
   the mobile node's PMIPv6 session.

   The MAG and the LMA obtain essential parameters of the MN's Policy
   Profile to their local copies of the Policy Store using the AAA
   interface.  The MAG and the LMA use the same AAA interfaces also to
   update the dynamic Policy Profile parameters in the remote Policy
   Store.  The Policy Profile may also be handed over to a serving MAG
   as part of a context transfer procedure during a handover.  However,
   the context transfer is out of scope of this document.  The local
   copy of the MN's Policy Profile may be slightly different in the MAG
   compared to one in the LMA.

   The following Policy Profile parameters are located in the MAG.
   These parameters may be statically configured or dynamically
   allocated using the MAG-AAA interface.  Dynamically assigned
   parameter values always override the statically configured ones:




Korhonen & Muhanna       Expires August 21, 2008                [Page 6]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   o  The MN's identifier (MN-ID).  This parameter may be obtained from
      the remote Policy Store, learned during mobile node access
      authentication, or generated locally in the MAG.  If inter-
      operator deployments are supported then the MD-ID parameter must
      be accompanied with MN's home realm parameter.

   o  The IPv6 address of the Local Mobility Anchor (LMAA).  This
      parameter may be configured dynamically using methods described in
      section .  If inter-operator deployments are supported then the
      LMAA parameter must be accompanied with corresponding realm

   o  The IPv4 address of the Local Mobility Anchor (LMAA).  This
      parameter may be configured dynamically using methods described in
      section .  If inter-operator deployments are supported then the
      LMAA parameter must be accompanied with corresponding realm.

   o  The MN's IPv6 home network prefix (MN-HNP).  The MN-HNP may be
      downloaded during the MN access authentication from the remote
      Policy Store.  If the MN-HNP is not provided during the access
      authentication time, it will be dynamically assigned to the MN
      during the proxy binding procedure.

   o  Supported address configuration procedures (Stateful, Stateless or
      both) on the access links in the PMIPv6 domain.  This parameter
      also defines whether IPv4 home address can be configured to the
      MN.

   o  The MN's IPv4 home address (IPv4-HoA).  The IPv4-HoA may be
      downloaded during the MN access authentication from the remote
      Policy Store.  If the IPv4-HoA is not provided during the access
      authentication time, it will be dynamically assigned to the MN
      during the proxy binding procedure.

   o  The MN's interface identifier.  The identifier may be MN's link
      layer interface identifier or generated locally based by the MAG.
      This identifies must be unique in all those PMIPv6 Domains the MN
      can attach to.

   o  The local routing option flag.  When this configuration option is
      set true, two MNs attached to the same MAG may directly
      communicate with each other without routing traffic via the LMA.


4.1.  Policy Profile and Storage Requirements

   As stated earlier there are local and remote copies of the Policy
   Profile.  The default local profile is usually coupled with the local
   administrative policies that must be taken into account during the



Korhonen & Muhanna       Expires August 21, 2008                [Page 7]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   Policy Profile retrieval from the remote Policy Store.

   R1.1:  There must be a mechanism for a capability negotiation between
      the MAG and the remote Policy Store.  For example, the MAG must be
      able to inform the remote Policy Store whether a local routing in
      a MAG is supported by the local administrative policy.


5.  Mobility Service Setup

   Setting up the mobility service refers to a procedure that takes
   place when a MN attaches to a MAG and to a PMIPv6 Domain.  Prior the
   attachment, the MAG may or may not have a security association set up
   with the LMA located in the MN's home realm.

   The discovery of the LMA corresponding to the MN's home realm is an
   essential part of the mobility service setup.  The discovery may be
   dynamic or static depending on the MAG configuration.  In the context
   of this document the dynamic discovery of the LMA is inherently tied
   to procedures that take place during the MN access authentication.

5.1.  Generic Service Setup Requirements

   The mobility service setup procedures must comply with the following
   deployment related requirements:

   R2.1:  The MN should provide at least its permanent id and home realm
      during the access authentication.  In the case the MN is not able
      to provide adequate home realm information, then the MN must
      provide the MAG with another identifier that the MAG can use
      either to generate or discover MN's home realm.  The home realm is
      used by the MAG/NAS and the AAA infrastructure to route AAA
      requests from the MAG/NAS to the MN's home AAA server.

   R2.2:  It must be possible to separate the MAG's proxy mobile agent
      functionality and the NAS functionality.  Thus allowing
      deployments, where a single NAS provides AAA services for a pool
      of MAGs.

   R2.3:  It must be possible for the LMA to return a temporary MN
      identity to the MAG during the access authentication.  This
      identity must be unique within the PMIPv6 domain and should hide
      MN's true identity even from the MAG.  The LMA provided temporary
      MN identity must remain unchanged during the lifetime of the
      mobility service session.  The MAG must use this identity, if
      available, in all subsequent AAA messages to identify the MN.





Korhonen & Muhanna       Expires August 21, 2008                [Page 8]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


5.2.  Initial Dynamic LMA Discovery Requirements

   This section describes the requirements for the initial LMA address
   discovery process.  The discovery process takes place when the MN
   attaches to the PMIPv6 Domain and starts the mobility service for the
   first time.

   R3.1:  Configuration of the LMA address must be possible per realm
      basis.  The configuration may be static or dynamic to the MAG.

   R3.2:  The LMA address must be provided either as an IP address or as
      a FQDN.  The FQDN may be generated by the MAG based on the MN's
      home realm or other identifier provided by the MN, or retrieved
      from the AAA server.

   R3.3:  It must be possible to return multiple LMA addresses and FQDNs
      simultaneously using the AAA interface between the MAG and the
      Policy Store.  Furthermore, grouping of LMA address and FQDN pairs
      must be possible.

   The MAG queries the DNS system in order to resolve the FQDN to the
   LMA IP address.  SRV, AAAA or A resource records may be queried
   depending on the deployment.

   The AAA interface between the MAG and the Policy Store may return
   both LMA IP address and the LMA FQDN at the same time.  In this case
   the MAG may skip the LMA address DNS resolving step.  It is possible,
   depending on the deployment, that the FQDN is also used to piggy-back
   service level information (e.g.  LMAs with dedicated roles).

5.3.  LMA Discovery After a Handover Requirements

   This section describes the requirements for the LMA address discovery
   process after a handover to a new MAG when the MN has an existing
   mobility session.  The discovery process takes place when the MN
   attaches to a new MAG either under the same or different PMIPv6
   Domain.

   R4.1:  During the MN access authentication procedure the remote
      Policy Store must be able to discover that the MN has an existing
      mobility service session and return the IP address or the FQDN of
      the LMA where the MN's mobility service session is anchored.

   R4.2:  During the MN access authentication procedure the remote
      Policy Store must return MN's temporary identity to the MAG, if
      the MAG does not have other mechanisms of learning it.  The remote
      Policy Store should also return other MN's Policy Profile
      information to the MAG.  This information may include e.g., MN-HNP



Korhonen & Muhanna       Expires August 21, 2008                [Page 9]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


      and IPv4-HoA.

   If the remote Policy Store (i.e. the home AAA server) is able to find
   an existing mobility service session for the authenticating MN, then
   the existing LMA IP address should be returned to the MAG/NAS.  If a
   FQDN is returned instead, then the MAG/NAS may not have a way to
   distinguish between a MN handover and a MN initial attachment.  If
   only a FQDN gets returned to the MAG/NAS for the existing mobility
   service session then the operator must ensure that the FQDN gets
   resolved to exactly one LMA where the MN's mobility service session
   is anchored.

5.4.  MAG to LMA Security Association Setup Requirements

   The SA between the MAG and each LMA may be 1) statically configured
   or 2) a MAG initiated using some dynamic security association and key
   exchange protocol.  An example of a security association and key
   exchange protocol is IKEv2 [7].  Credentials and identities used to
   authenticate and authorize the MAG towards the LMA must be decoupled
   from those used to authenticate and authorize the MN.  The dynamic
   creation of the MAG to LMA security association setup may be
   triggered by a MN roaming in and attaching to the PMIPv6 domain.

   R5.1:  Depending on the deployment, it must be possible to decouple
      the MAG to LMA Security Association Setup from the MN
      authentication and authorization.

   The MAG to LMA Security Association may be removed or disabled when
   there is not any active mobility service session towards the LMA.

5.5.  Generic LMA to AAA Requirements

   The LMA to AAA interface has five possible functions: 1) the MAG to
   LMA security association setup related AAA signaling that was
   discussed in Section 5.4, 2) authorization of the incoming PBU, 3)
   mobility service session management, 4) dynamic updating of MN's
   Policy profile in the remote Policy Store, and 5) accounting.

   R6.1:  Depending on the deployment, the LMA should be able to
      delegate the MN-HNP and IPv4-HoA management to the AAA server.

   R6.2:  AAA server must be able to initiate a mobility service session
      termination towards the LMA.








Korhonen & Muhanna       Expires August 21, 2008               [Page 10]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   R6.3:  Based on the deployment and trust relationship between the MAG
      and the LMA, the LMA MAY be able to validate the mobile node
      PMIPv6 service authorization upon receiving a PMIPv6 PBU from the
      specified MAG.

   R6.4:  The LMA must be able to send accounting data to the AAA
      server.

   The dynamic updating of MN's Policy Profile in the remote Policy
   Store is implicitly part of the above requirements.

5.6.  Generic MAG to AAA Requirements

   The MAG to AAA interface has several additional functions in addition
   to the authentication and authorization of the MN, and subsequent
   setting up the mobility service session.  These additional functions
   include e.g., accounting and the mobility service session management.

   R7.1:  AAA server must be able to initiate a mobility service session
      termination towards the MAG.

   R7.2:  The MAG must be able to send accounting data to the AAA
      server.


6.  IANA Considerations

   This document has no actions for IANA.


7.  Security Considerations

   TBD


8.  Acknowledgements

   TBD


9.  References

9.1.  Normative References

   [1]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
        B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10
        (work in progress), February 2008.




Korhonen & Muhanna       Expires August 21, 2008               [Page 11]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


   [2]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
        IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in
        progress), November 2007.

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

9.2.  Informative References

   [4]  Manner, J. and M. Kojo, "Mobility Related Terminology",
        RFC 3753, June 2004.

   [5]  Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K.
        Chowdhury, "Diameter Mobile IPv6: Support for Network Access
        Server to Diameter Server  Interaction",
        draft-ietf-dime-mip6-integrated-08 (work in progress),
        February 2008.

   [6]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
        Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
        June 2004.

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


Authors' Addresses

   Jouni Korhonen
   TeliaSonera
   Teollisuuskatu 13
   Sonera  FIN-00051
   Finland

   Email: jouni.korhonen@teliasonera.com


   Ahmad Muhanna
   Nortel Networks
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com







Korhonen & Muhanna       Expires August 21, 2008               [Page 12]


Internet-Draft     Policy Profile and AAA Requirements     February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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





Korhonen & Muhanna       Expires August 21, 2008               [Page 13]


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