Network Working Group F. Xia Internet-Draft B. Sarikaya Intended status: Standards Track Huawei USA Expires: May 7, 2009 J. Korhonen, Ed. TeliaSonera S. Gundavelli Cisco November 3, 2008 RADIUS Proxy Mobile IPv6 draft-xia-netlmm-radius-03 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 May 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Xia, et al. Expires May 7, 2009 [Page 1] Internet-Draft RADIUS-PMIPv6 November 2008 Abstract This document defines a RADIUS based interface between the Mobile Access Gateway and the RADIUS server that is used to download the per Mobile Node Policy Profile from the remote Policy Store. The RADIUS interactions take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document also defines a RADIUS based interface between the Local Mobility Anchor and the RADIUS server for authorizing received initial Proxy Binding Update messages for the mobility service session. In addition to the mobility session setup related RADIUS interaction, this document defines the baseline for both the Mobile Access Gateway and the Local Mobility Anchor generated accounting. Xia, et al. Expires May 7, 2009 [Page 2] Internet-Draft RADIUS-PMIPv6 November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. MIP6-Feature-Vector . . . . . . . . . . . . . . . . . . . 5 4.2. Mobile-Node-Identifier . . . . . . . . . . . . . . . . . . 6 4.3. Service-Selection . . . . . . . . . . . . . . . . . . . . 7 4.4. MIP6-HA . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. MIP6-HA-FQDN . . . . . . . . . . . . . . . . . . . . . . . 8 4.6. MIP6-HL-Prefix . . . . . . . . . . . . . . . . . . . . . . 8 4.7. MIP6-IPv4-Home-Address . . . . . . . . . . . . . . . . . . 9 4.8. PMIP6-MAG-Address . . . . . . . . . . . . . . . . . . . . 9 5. MAG to RADIUS server interface . . . . . . . . . . . . . . . . 10 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Table of Attributes . . . . . . . . . . . . . . . . . . . 11 6. LMA to RADIUS server interface . . . . . . . . . . . . . . . . 11 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Table of Attributes . . . . . . . . . . . . . . . . . . . 12 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Accounting at LMA . . . . . . . . . . . . . . . . . . . . 12 7.2. Accounting at MAG . . . . . . . . . . . . . . . . . . . . 12 7.3. Table of Attributes . . . . . . . . . . . . . . . . . . . 13 8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Attribute Type Codes . . . . . . . . . . . . . . . . . . . 14 10.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Xia, et al. Expires May 7, 2009 [Page 3] Internet-Draft RADIUS-PMIPv6 November 2008 1. Introduction Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility management protocol which allows IP mobility session continuity for a Mobile Node (MN) without its involvement in mobility management signaling. A Mobile Access Gateway (MAG) represents the MN and is authorized to send mobility management signaling messages on behalf of the MN. Before the MAG is able to perform the required mobility management signaling, it needs to know at minimum a Local Mobility Anchor (LMA) address and the MN Identifier (MN-ID). This per MN Policy Profile (PP) information is stored in a Policy Store (PS), which may be local to the MAG or accessible remotely, for example, through an authentication, authorization and accounting (AAA) infrastructure. This document defines a RADIUS [RFC2865] based profile and corresponding attributes to be used on the AAA interface between the MAG and the RADIUS server. The interface that is used to download the per MN Policy Profile from the remote Policy Store. The RADIUS interactions take place when the MN attaches, authenticates and authorizes to a PMIPv6 domain. Furthermore, this document also defines a RADIUS based interface between the LMA and the RADIUS server for authorizing received initial Proxy Binding Update (PBU) messages for the mobility service session. In addition to the mobility session setup related RADIUS interaction, this document defines the baseline for both the MAG and the LMA generated accounting. 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 [RFC2119]. The terminology in this document is based on the definitions found in [RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support]. 3. Solution Overview The interface between the MAG and the RADIUS server is used to download a Policy Profile (PP) from the RADIUS server to the MAG. The downloading of the Policy Profile is part of the network access authentication and authorization procedure that takes place when a MN roams into or within a PMIPv6 domain. In this solution the MAG acts as the Network Access Server (NAS). Xia, et al. Expires May 7, 2009 [Page 4] Internet-Draft RADIUS-PMIPv6 November 2008 The choice of the authentication mechanism is specific to an access system, but could be based on the Extensible Authentication Protocol (EAP) [RFC3748]. During the network access authentication procedure, the MAG acting as a NAS queries the RADIUS server through the AAA infrastructure. If the RADIUS server detects that the subscriber is also authorized for the PMIPv6 mobility service, the subscriber policy profile is returned along with the successful network access authentication answer to the MAG. After the MN has successfully been authenticated and authorized to the network access, the MAG sends a PBU to the LMA in order to setup or update the mobility service session for the MN. Upon receiving the PBU the LMA interacts with the RADIUS server and fetches the relevant subscriber policy, authorization and security information related to the PMIPv6 mobility session. This specification assumes that the RADIUS server is the central entity for managing everything related to PMIPv6 subscription and mobility session, possibly even including the allocation of Home Network Prefixes (HPN). This specification also assumes that the Security Association (SA) between the MAG and the LMA is already in place. How the SA is established is outside of scope of this specification. Due the obvious similarities between the PMIPv6 Policy Profile download and Mobile IPv6 integrated scenario bootstrapping [I-D.ietf-mip6-bootstrapping-integrated-dhc] this specification can re-use several RADIUS attributes defined for Mobile IPv6 purposes [I-D.ietf-mip6-radius]. However, some additional PMIPv6 specific attributes and functionality is needed. 4. Attributes 4.1. MIP6-Feature-Vector The MIP6-Feature-Vector attribute is defined in [I-D.ietf-mip6-radius]. This document only reserves new capability bits according to the rules in [I-D.ietf-dime-mip6-integrated]. The following capability flag bits are defined in this document: PMIP6_SUPPORTED (0x0000010000000000) When the MAG/NAS sets this bit in the MIP6-Feature-Vector attribute, it is an indication to the RADIUS server that the NAS supports PMIPv6. When the RADIUS server sets this bit in the response MIP6-Feature-Vector AVP, it indicates that the RADIUS server also has PMIPv6 support. This capability flag bit can also be used to allow PMIPv6 mobility support in a subscription granularity. Xia, et al. Expires May 7, 2009 [Page 5] Internet-Draft RADIUS-PMIPv6 November 2008 IP4_HOA_SUPPORTED (0x0000020000000000) Assignment of the IPv4-HoA is supported [I-D.ietf-netlmm-pmip6-ipv4-support]. When the MAG sets this bit in the MIP6-Feature-Vector attribute, it indicates that the MAG implements a minimal functionality of a DHCP server (and a relay) and is able to deliver IPv4-HoA to the MN. When the RADIUS server sets this flag bit in the response MIP6-Feature-Vector attribute, it indicates that the RADIUS server has authorized the use of IPv4-HoA for the MN. If this bit is unset in the returned MIP6- Feature-Vector attribute, the RADIUS server does not authorize the configuration of IPv4 address. LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000) Direct routing of IP packets between MNs anchored to the same MAG is supported. When a MAG sets this flag bit in the MIP6-Feature- Vector, it indicates that routing IP packets between MNs anchored to the same MAG is supported, without reverse tunneling packets via the LMA or requiring any Route Optimization related signaling (e.g. the Return Routability Procedure in [RFC3775]) prior direct routing. If this flag bit is unset in the returned MIP6-Feature- Vector AVP, the RADIUS server does not authorize direct routing of packets between MNs anchored to the same MAG. This policy feature MUST be supported per MN and subscription basis. The MIP6-Feature-Vector attribute is also used on the LMA to the RADIUS server interface. Using the capability announcement attribute it is possible to perform a simple capability negotiation between the LMA and the RADIUS server. Those capabilities that are announced by both parties are also known to be mutually supported. 4.2. Mobile-Node-Identifier The Mobile-Node-Identifier attribute is of type String and contains the mobile node identifier (MN-Identifier, see [RFC5213]) in a NAI [RFC4282] format. This AVP is used on the MAG to the RADIUS server interface. The Mobile-Node-Identifier attribute is returned in the Access-Accept message that ends a successful authentication (and possibly an authorization) exchange between the MAG and the RADIUS server, assuming the RADIUS server is also able to provide the MAG with a MN- Identifier that guarantees mobility session continuity in the first place. The MAG SHOULD use the received MN-Identifier as the MN-ID in the subsequent PBUs. The MAG is allowed to discard the RADIUS server provided identity if it has other means of finding out a MN-ID that Xia, et al. Expires May 7, 2009 [Page 6] Internet-Draft RADIUS-PMIPv6 November 2008 guarantees mobility session continuity. 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 Identifier... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: MOBILE-NODE-IDENTIFIER-TYPE to be defined by IANA. Length: >= 3 octets Mobile Node Identifier: This field is of type String and contains the MN-ID of the MN to be used in the PBUs. Editor's note: 4.3. Service-Selection The Service-Selection attribute is of type String, encoded as UTF-8 [RFC3629], and contains the name of the service or the external network that the mobility service should be associated with. The RADIUS server MAY return the Service-Selection attribute to the MAG and in that way indicate the default service to the MAG. Between the LMA to the RADIUS server interface, the LMA MAY populate the Service- Selection attribute with the service information found from the received PBU, if such information is available [RFC5149]. Xia, et al. Expires May 7, 2009 [Page 7] Internet-Draft RADIUS-PMIPv6 November 2008 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 | Service Identifier... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: SERVICE-SELECTION-TYPE to be defined by IANA. Length: >= 3 octets Service Identifier: This field is of type String and contains the Service Identifier the MN MUST be associated with. This specification allows international identifier strings that are based on the use of Unicode characters, encoded as UTF-8 [RFC3629]. Editor's note: we might need to address normalization here. 4.4. MIP6-HA The MIP6-HA attribute is defined in [I-D.ietf-mip6-radius]. In the scope of this specification the attribute contains an IPv6 address of the LMA in the network byte order. Editor's note: we probably should also define an attribute to carry IPv4 address of the LMA. Or then we could always use "IPv4- compatible IPv6 address" to carry the IPv4 address of the LMA. 4.5. MIP6-HA-FQDN The MIP6-HA-FQDN attribute is defined in [I-D.ietf-mip6-radius]. In the scope of this specification the attribute contains a Fully Qualified Domain Name (FQDN) of the LMA. 4.6. MIP6-HL-Prefix The MIP6-HL-Prefix attribute is defined in [I-D.ietf-mip6-radius]. In the scope of this specification the attribute contains the MN-HNP of the MN in the network byte order. The low 64 bits of the IPv6 address MUST be all zeroes. The high 64 bits of the IPv6 address are used as the MN-HNP. The primary use of this AVP is to carry the IPv6 Home Network Prefix, if available, from the RADIUS server to the MAG. Xia, et al. Expires May 7, 2009 [Page 8] Internet-Draft RADIUS-PMIPv6 November 2008 4.7. MIP6-IPv4-Home-Address The MIP6-IPv4-Home-Address attribute is of type Address and contains the IPv4-HoA of the MN in the network byte order. The primary use of this attribute is to carry the IPv4-HoA [I-D.ietf-netlmm-pmip6-ipv4-support], if available, from the RADIUS server to the MAG. 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: MIP6-IPV4-HOME-ADDRESS-TYPE to be defined by IANA. Length: = 6 octets Address: This field is of type Address and contains the IPv4 Home Address of the MN. 4.8. PMIP6-MAG-Address The PMIP6-MAG-Address attribute is of type String and contains the IPv6 address of the MAG in the network byte order. This attribute is mainly useful for collecting statistics information about MN's movement. Xia, et al. Expires May 7, 2009 [Page 9] Internet-Draft RADIUS-PMIPv6 November 2008 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-MAG-ADDRESS-TYPE to be defined by IANA. Length: = 18 octets Address: This field is of type String and contains the IPv6 Address of the MAG in network byte order. 5. MAG to RADIUS server interface 5.1. General The MAG to the RADIUS server interface is primarily used for downloading the Policy Profile (i.e., to bootstrap the PMIPv6 mobility service session) when a MN attaches, authenticates and authorizes to a PMIPv6 domain. Whenever the MAG sends a RADIUS request message to the RADIUS server, the User-Name attribute SHOULD contain the MN identity. At minimum the home network realm of the MN MUST be available at the MAG when the network access authentication takes place. Otherwise the MAG is not able to route the RADIUS request messages towards the correct RADIUS server. The MN identity MUST be in Network Access Identifier (NAI) [RFC4282] format. Xia, et al. Expires May 7, 2009 [Page 10] Internet-Draft RADIUS-PMIPv6 November 2008 5.2. Table of Attributes The following table provides a guide to which PMIPv6 specific attributes SHOULD be included in RADIUS messages during the authentication and authorization process. Request Accept Reject Challenge # Attribute 0 0-1 0 0 TBD MIP6-HA 0 0-1 0 0 TBD MIP6-HA-FQDN 0 0-1 0 0 TBD MIP6-HL-Prefix 0 0-1 0 0 TBD MIP6-IPv4-Home-Address 0-1 0-1 0 0 TBD MIP6-Feature-Vector 0-1 0-1 0 0 TBD Service-Selection 0 1 0 0 TBD Mobile-Node-Identifier 6. LMA to RADIUS server interface 6.1. General The LMA to the RADIUS server interface may be used for multiple purposes. These include the authorization of the incoming PBU, dynamic allocation of the MN-HNP from address pools managed by the RADIUS server, updating the RADIUS server with the LMA address in the case the LMA was dynamically allocated by the MAG, possible MAG to LMA Security Association security related information retrieval, accounting and PMIPv6 session management. Whenever the LMA sends a RADIUS request message to the RADIUS server, the User-Name attribute MUST contain the MN identity. The identity MUST be in a NAI format. The LMA MAY retrieve the MN identity information from the PBU MN-ID mobility option. If the PBU contains the MN Link-Layer Identifier option, the Calling- Station-Id attribute SHOULD be included in the request message containing the received Link-Layer Identifier. Furthermore, if the PBU contains the Service Selection mobility option [RFC5149], the Service-Selection attribute SHOULD be included in the request message containing the received service identifier. The LMA and the RADIUS server use the MIP6-HL-Prefix attribute to exchange the MN-HNP when appropriate. The low 64 bits of the prefix must be all zeroes. Similarly, the LMA and the RADIUS server use the MIP6-IPv4-Home-Address attribute to exchange the MN IPv4-HoA when appropriate. If the MIP6-HL-Prefix is set to an all zeroes address (i.e., 0::0) in the request message, it is an indication that the Xia, et al. Expires May 7, 2009 [Page 11] Internet-Draft RADIUS-PMIPv6 November 2008 RADIUS server needs to assign the MN-HNP and return it to the LMA in the response message. If the MIP6-IPv4-Home-Address is set to all zeroes (i.e., 0.0.0.0) in the request message, it is an indication that the RADIUS server needs to assign the MN IPv4-HoA and return it to the LMA in the response message. 6.2. Table of Attributes The following table provides a guide to which PMIPv6 specific attributes SHOULD be included in the RADIUS messages during the authorization process. Request Accept Reject Challenge # Attribute 1 0 0 0 TBD MIP6-HA 0-1 0 0 0 TBD MIP6-HL-Prefix 0-1 0 0 0 TBD MIP6-IPv4-Home-Address 0-1 0-1 0 0 TBD MIP6-Feature-Vector 0-1 0 0 0 TBD Service-Selection 1 0 0 0 TBD Mobile-Node-Identifier 1 0 0 0 TBD PMIP6-MAG-Address 0-1 0 0 0 31 Calling-Station-Id 7. Accounting Editor's note: these sections will be revised. 7.1. Accounting at LMA The accounting at the LMA to AAA server interface is based on [RFC2865] and [RFC2866]. The interface must support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the MN in bi- directional tunneling, etc. 7.2. Accounting at MAG The accounting at the MAG to AAA server interface is based on [RFC2865] and [RFC2866]. The interface must also support the transfer of accounting records which include: time of binding cache entry creation and deletion, octets sent and received by the MN in bi-directional tunneling, etc. If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link Xia, et al. Expires May 7, 2009 [Page 12] Internet-Draft RADIUS-PMIPv6 November 2008 connected to the mobile access gateway, the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor. In this case, local data traffic MUST be reported to AAA servers through RADIUS protocol. 7.3. Table of Attributes The following table provides a guide to which attributes may be found in accounting messages. Request Interim Stop Attribute 0-1 0 0-1 MIP6-HA 0-1 0 0-1 MIP6-HL-Prefix 0-1 0 0-1 MIP6-IPv4-Home-Address 0-1 0 0-1 Service-Selection 0-1 0 0-1 MIP6-Feature-Vector 0-1 0-1 0-1 Mobile-Node-Identifier 0-1 0 0-1 Calling-Station-Id 0-1 0-1 0-1 PMIP6-MAG-Address 8. Diameter Considerations Editor's note: The Diameter compatibility requires further work. It needs to be evaluated, which attributes could be used as-is in Diameter specification for equivalent purposes. Such alignment could ease the possible RADIUS-Diameter translation agent functionality considerably. 9. Security Considerations The security considerations of the RADIUS protocol [RFC2865], are applicable to this document. The RADIUS messages may be transported between the MAG and/or the LMA to the RADIUS server via one or more AAA brokers or RADIUS proxies. In this case the HA to the RADIUS server AAA communication rely on the security properties of the intermediate AAA brokers and RADIUS proxies. This document does not introduce any new security vulnerabilities that would not already have been identified in Mobile IPv6 integrated scenario bootstrapping [I-D.ietf-mip6-bootstrapping-integrated-dhc] and its use of AAA [I-D.ietf-dime-mip6-integrated]. Xia, et al. Expires May 7, 2009 [Page 13] Internet-Draft RADIUS-PMIPv6 November 2008 10. IANA consideration 10.1. Attribute Type Codes This specification defines the following new RADIUS attribute type codes: MIP6-IPV4-HOME-ADDRESS-TYPE is set to TBD SERVICE-SELECTION-TYPE is set to TBD MOBILE-NODE-IDENTIFIER-TYPE is set to TBD PMIP6-MAG-ADDRESS-TYPE is set to TBD 10.2. Namespaces This specification defines new values to the Mobility Capability registry (see [I-D.ietf-dime-mip6-integrated]) for use with the MIP6- Feature-Vector AVP: Token | Value | Description ----------------------------------+----------------------+------------ PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD] IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD] LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD] Xia, et al. Expires May 7, 2009 [Page 14] Internet-Draft RADIUS-PMIPv6 November 2008 11. Acknowledgements The authors would like to thank the authors of [I-D.ietf-mip6-radius], [I-D.ietf-dime-mip6-integrated] and [I-D.korhonen-dime-pmip6] as this specification re-uses attributes and some procedural ideas of the mentioned specifications. Xia, et al. Expires May 7, 2009 [Page 15] Internet-Draft RADIUS-PMIPv6 November 2008 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [I-D.ietf-mip6-radius] Lior, A., Chowdhury, K., and H. Tschofenig, "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-05 (work in progress), July 2008. [I-D.ietf-dime-mip6-integrated] 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-10 (work in progress), September 2008. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 12.2. Informative references [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Xia, et al. Expires May 7, 2009 [Page 16] Internet-Draft RADIUS-PMIPv6 November 2008 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 (work in progress), September 2008. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), April 2008. [I-D.korhonen-dime-pmip6] Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., and U. Meyer, "Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction", draft-korhonen-dime-pmip6-04 (work in progress), September 2008. Xia, et al. Expires May 7, 2009 [Page 17] Internet-Draft RADIUS-PMIPv6 November 2008 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Jouni Korhonen (editor) TeliaSonera Email: jouni.nospam@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sgundave@cisco.com Xia, et al. Expires May 7, 2009 [Page 18] Internet-Draft RADIUS-PMIPv6 November 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). Xia, et al. Expires May 7, 2009 [Page 19]