Network Working Group F. Xia Internet-Draft B. Sarikaya Intended status: Standards Track Huawei USA Expires: August 28, 2008 J. Korhonen TeliaSonera S. Gundavelli Cisco February 25, 2008 RADIUS Proxy Mobile IPv6 draft-xia-netlmm-radius-02 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 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Xia, et al. Expires August 28, 2008 [Page 1] Internet-Draft RADIUS-PMIPv6 February 2008 Abstract Proxy Mobile IPv6 (PMIPv6) is network based mobility management protocol which allows IP session continuity for a mobile node (MN) without its involvement in mobility management. A mobile access gateway (MAG) is authorized to send Mobile IPv6 signaling messages on behalf of mobile nodes. The MAG requires a local mobility anchor address (LMAA), mobile node's identifier (MN-Identifier),and IPSec security association (SA) with it's LMA before it sends signaling messages. Interworking with existing authentication, authorization and accounting (AAA) infrastructure, MAG acquires the LMAA (directly or indirectly) and MN-Identifier. Local mobility anchor (LMA) also uses AAA infrastructure to authenticate MAG and build SA between MAG when IKEv2 IPSec is used for security between MAG and LMA . This document defines new RADIUS attributes and reasonably reuses existing attributes to serve the purpose. This information exchange takes place as part of the initial network access authentication procedure. Address configuration modes and others can also be obtained from AAA infrastructure to emulate MN's home link on access links. Xia, et al. Expires August 28, 2008 [Page 2] Internet-Draft RADIUS-PMIPv6 February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Mobile IPv6 Bootstrapping Overview . . . . . . . . . . . . 5 3.2. Proxy Mobile IPv6 Bootstrapping Procedure . . . . . . . . 6 3.2.1. Security Association Setup . . . . . . . . . . . . . . 6 3.2.2. Mobility Capability Negotiation . . . . . . . . . . . 7 3.2.3. Dynamic LMA Assignment . . . . . . . . . . . . . . . . 7 3.2.4. DNS Update . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Home Link Emulation . . . . . . . . . . . . . . . . . 9 3.2.6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10 3.2.7. Mobile Node Identity . . . . . . . . . . . . . . . . . 10 3.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Accounting at LMA . . . . . . . . . . . . . . . . . . 10 3.3.2. Accounting at MAG . . . . . . . . . . . . . . . . . . 10 4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 11 4.1. PMIPv6 MN-HoA configuration mode . . . . . . . . . . . . . 11 4.2. Use of existing RADIUS Attributes . . . . . . . . . . . . 12 4.2.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . 12 4.2.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . 12 4.2.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . 13 4.2.4. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . 13 4.2.5. MIP-MN-HoA Attribute . . . . . . . . . . . . . . . . . 13 4.2.6. MIP-HA-IP Attribute . . . . . . . . . . . . . . . . . 13 4.2.7. Service-Type . . . . . . . . . . . . . . . . . . . . . 13 4.2.8. Chargeable User Id . . . . . . . . . . . . . . . . . . 13 4.2.9. Calling-Station-Id . . . . . . . . . . . . . . . . . . 13 4.2.10. Callback-Id . . . . . . . . . . . . . . . . . . . . . 13 4.2.11. MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . . 14 4.3. Table of Attributes . . . . . . . . . . . . . . . . . . . 14 5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Xia, et al. Expires August 28, 2008 [Page 3] Internet-Draft RADIUS-PMIPv6 February 2008 1. Introduction It is possible to support mobility for IPv6 nodes by extending Mobile IPv6 [RFC3775] signaling and reusing the home agent via a proxy mobility agent in the network. [I-D.ietf-netlmm-proxymip6] describes the approach to supporting mobility without requiring the mobile node to be involved in mobility management signaling. The proxy mobility agent in the network performs the signaling and does the mobility management on behalf of the mobile node. From AAA perspective, the operation of Proxy Mobile IPv6 includes the following parts: Access Authentication: When a MN roams into a PMIPv6 domain and attaches to an access link connected to the MAG, the MN may present its identity and home realm, as part of the access authentication procedure. Upon a successful access authentication, MAG acting as an RADIUS client obtains the MN's policy profile from AAA server using RADIUS protocol. The policy profile contains for example the following information: LMAA, Home Network Prefix (MN-HNP) and an AAA assigned MN's temporary identity. Security Association Establishment: After a successful access authentication and authorization, the MAG MUST send a Proxy Binding Update (PBU) message to the LMA assigned to the MN. The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement SHOULD be protected using IPSec. In PMIPv6, a security association (SA) between a LMA and a MAG are shared by multiple MNs. Before sending a PBU message, the MAG checks if there is an existing SA established between the MAG and the LMA. The MAG initiates a SA establishment procedure if there is no existing SA. IKEv2 [RFC4306] SHOULD be used for a dynamic SA setup between the MAG and the LMA. The MAG and the LMA can use any available mechanisms for a mutual authentication (i.e., shared secret/certificate/EAP) and IKEv2 initiator identity used during the SA setup is the MAG's identity. The MAG and LMA message exchange in SA setup is outside of scope of this document. In this specification, only AAA interfaces related to the SA setup are discussed. MN home address configuration: An important function of PMIPv6 is the emulation of the MN's home link on the access link. The MN can operate in an IPv4-only mode, IPv6-only mode or in dual IPv4/IPv6 mode. The MN can obtain IPv6 address through DHCPv6 or stateless auto-configuration. In the DHCPv6 case, the MAG can have DHCPv6 relay functionality and relay Xia, et al. Expires August 28, 2008 [Page 4] Internet-Draft RADIUS-PMIPv6 February 2008 DHCPv6 messages between the MN and a DHCPv6 server. Alternatively the MAG may act as a DHCPv6 server. In the latter case, the MAG can obtain MN-HoA from AAA server, or from LMA through PBU/PBA exchange. In the stateless address auto-configuration case, the MN can also use the prefix advertised in a Router Advertisement sent by the MAG to configure an IPv6 address. The MN-HNP can be obtained from the AAA server or from the LMA. Once the MN-HoA configuration is finished, the MAG may send Access-Request to trigger a dynamic DNS update for MN-HoA. 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 in [I-D.ietf-netlmm-proxymip6]. 3. Solution Overview 3.1. Mobile IPv6 Bootstrapping Overview [RFC4640] is problem statement for bootstrapping Mobile IPv6 (MIPv6). In MIPv6 scenario, a MN needs at least the following information: a home address, a home agent address, and a security association with home agent to register. The process to obtain this information is called bootstrapping. [RFC4640] discusses issues involved in how the MN can be bootstrapped and various potential deployment scenarios for the MN's bootstrapping. Two deployments scenarios are defined in [RFC4640]: a split scenario and an integrated scenario. The essential difference between the two scenarios is that in the split scenario, the mobility service and the network access service are authorized by different entities while in integrated scenario, the two services are authorized by the same entity. [RFC5026] details bootstrapping solution for the split scenario, while [I-D.ietf-mip6-bootstrapping-integrated-dhc] describes the solution for the integrated scenario. Furthermore, [I-D.ietf-mip6-hiopt] defines new DHCP options to be used for dynamic home information discovery in the integrated scenario. To facilitate these solutions, the AAA functionality for the integrated and the split scenarios need to be defined. Xia, et al. Expires August 28, 2008 [Page 5] Internet-Draft RADIUS-PMIPv6 February 2008 [I-D.ietf-mip6-radius] defines new RADIUS attributes to facilitate Mobile IPv6 bootstrapping in both integrated and split scenarios. [I-D.ietf-dime-mip6-integrated] describes Diameter interface between a network access server and a home AAA server in the integrated scenario. [I-D.ietf-dime-mip6-split] specifies Diameter interface between a home agent and a home AAA server in the split scenario. The integrated scenario seems more suitable for PMIPv6 because the bootstrapping is a part of the access authentication procedure. Therefore, we will not present all details of PMIPv6 bootstrapping but instead we will only highlight special considerations that apply to PMIPv6. 3.2. Proxy Mobile IPv6 Bootstrapping Procedure PMIPv6 offloads mobility management to the network. The MAG needs at least the following information during the PMIPv6 bootstrapping: the LMAA , a MN-HNP or a MN-HoA, a MN-Identifier, and a MAG to LMA SA. The MN-Identifier may also be the MN-HoA. The process of obtaining this information is called PMIPv6 bootstrapping in this document. 3.2.1. Security Association Setup The LMA MUST allow only authorized MAGs to create binding cache entries on behalf of the mobile nodes. Security Associations should be setup before sending the first PBU. There MAY be a separate security association for each different Realm mobile nodes have. However, this is up to the deployment and operators to decide. In [I-D.ietf-netlmm-proxymip6], the example Peer Authorization Database (PAD) entries are illustrated as following. mobile access gateway PAD: - IF remote_identity = lma_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address lma_addres_1 local mobility anchor PAD: - IF remote_identity = mag_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address mag_address_1 For example, a MAG inspects destination address of each packet, and initiates a SA setup process if the destination address matches an entry in the PAD. Xia, et al. Expires August 28, 2008 [Page 6] Internet-Draft RADIUS-PMIPv6 February 2008 IKEv2 SHOULD be used to setup a SA between the MAG and the LMA to protect the PBU and PBA messages, and user plane traffic. These SAs are shared by multiple MNs between the MAG and LMA pair . The MAG and the LMA can use any of the authentication mechanisms (shared secret/certificate/EAP) described in [RFC4306] for mutual authentication and the security association setup. When EAP is used, the MAG acts as a supplicant and the LMA as an authenticator. The LMA must follow the procedures defined in [RFC3579]. The LMA gets session key material from the RADIUS server through RADIUS Access- Accept message. The key material is used for further SA establishment between the MAG and the LMA. 3.2.2. Mobility Capability Negotiation Different network entities may have different mobility management capabilities. A MN may support IPv6 or IPv4, MIPv4 or MIPv6. A MAG may support IPv4 or IPv6, MIPv4, MIPv6, PMIPv4 or PMIPv6. AAA servers may provide support for IPv4, IPv6, MIPv4, MIPv6, PMIPv4 and PMIPv6 subscriptions. Negotiation mechanism may be necessary among MN, MAG, and AAA servers. In this document, only mobility capability negotiation between a MAG and an AAA server is dealt with. In [I-D.korhonen-dime-pmip6], the MIP6-Feature-Vector AVP is used for the negotiation. Same attribute is also available for RADIUS [I-D.ietf-mip6-radius] that can be reused for PMIPv6 purposes. The assigned values are defined in [I-D.korhonen-dime-pmip6]. The MAG sends Access-Request message with MIP6-Feature-Vector attribute to announce its capabilities and the AAA server returns mutually supported capabilities in the MIP6-Feature-Vector attribute in the Access-Accept reply message. The mutually agreed on capability set may also be affected by the MN subscription and operator policy. 3.2.3. Dynamic LMA Assignment [I-D.ietf-mip6-hiopt] defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home agent FQDN and home network prefix. Similarly, a MAG can act as a DHCP client to dynamically request a LMAA, or a LMA FQDN. A MAG may also receive the LMAA or the LMA FQDN as a part of the MN access authentication. Xia, et al. Expires August 28, 2008 [Page 7] Internet-Draft RADIUS-PMIPv6 February 2008 MN MAG AAA DHCP-S or DHCP-R | | | | | 1 Access Authentication | | |<----------->|<----------------->| | | | | | | | 2 Access-Accept | | | |<------------------| | | | | | | | | | | | 3 DHCP Information-Request | | |----------------------------------->| | | | | | | 4 DHCP reply | | |<-----------------------------------| | | | | Figure 2: Dynamic LMA Using DHCP 1. An MN initiates authentication when the MN accesses the networks. 2. After successful authentication, the LMAA or the LMA's FQDN can be included in RADIUS Access-Accept message. The LMAA MUST be used if it is present. The LMA's FQDN can be used to retrieve LMAA from either a DHCP server or a DNS server if the LMAA is not present in a RADIUS Access-Accept message. It is out of the scope for the MAG to get a LMAA from a DHCP server or a DNS server. The following DHCP exchanges are listed as an example. 3. The MAG as a DHCP client sends Information-Request for LMAA information according to [I-D.ietf-mip6-hiopt]. In the referred document, even there isn't any LMA's information in RADIUS Access-Accept, MAG can still dynamically find a LMAA from it's a DHCP server. 4. A DHCP relay or a DHCP server sends LMAA information through a DHCP Reply message. For further details, please refer to [I-D.ietf-mip6-hiopt]. 3.2.4. DNS Update In order that the MN is reachable through its dynamically assigned Home Address, the DNS needs to be updated with the new Home Address. Since the DNS update must be performed securely in order to prevent attacks or modifications from malicious nodes, the node performing this update must share a security association with the DNS server. In this case the MAG may not share a security association with the DNS server and the DNS entry update can be performed by the AAA server. In order to accomplish this, the MAG sends to the AAA server the FQDN-HoA pair using the RADIUS protocol. Xia, et al. Expires August 28, 2008 [Page 8] Internet-Draft RADIUS-PMIPv6 February 2008 LMA MAG AAA DNS server | | | | | 1 PBU | | | |<------------| | | | | | | | 2 PBA | | | |------------>| | | | | | | | Address Configuration | | | | | | | | 3 Access-Request | | | |------------------>| | | | | 4 DNS Update | | | |<-------------->| | | | | | | 5 Access-Accept | | | |<------------------| | | | | | Figure 3: DNS Update through AAA Figure 3 illustrates a typical MN-HoA DNS Update procedure 1. After successful access authentication and authorization, the MAG MUST send a Proxy Binding Update message to the LMA. The Proxy Binding Update message MUST have the Home Network Prefix option. MAG can learn the prefix from AAA server or from other means, and include the prefix in the Home Network Prefix option for requesting it from the local mobility anchor. If the specified value is 0::/0, then the LMA will allocate a prefix to the mobile node. 2. Successful PBA includes confirmed prefix which is advertised in Router Advertisement message by MAG to MN for stateless address auto-configuration. 3. Once address configuration finishes, the MAG sends Access-Request with MIP6-DNS-MO Attribute defined in [I-D.ietf-mip6-radius]. 4. The AAA server performs the DNS update based on [RFC2136]. 5. MIP6-DNS-MO attribute SHOULD be included in Access-Accept to confirm the DNS update. 3.2.5. Home Link Emulation In PMIPv6, MAG is also responsible for emulating the MN's home link on the access link. The characteristics of links are prefix, address configuration mode, MTU, link layer address of the default address and so on. To keep the consistency of link characteristics, MN's prefix is allocated from LMA or AAA server. MN's address configuration mode SHOULD be conveyed in Access-Accept in PMIP6-HL- Xia, et al. Expires August 28, 2008 [Page 9] Internet-Draft RADIUS-PMIPv6 February 2008 Feature attribute defined in Section 4.1 . The other parameters have limited impact on MN's behavior, so we offer no further discussion. 3.2.6. IPv4 Support [I-D.ietf-netlmm-pmip6-ipv4-support] specifies extensions to the Proxy Mobile IPv6 protocol for supporting IPv4. IPv4 support in Proxy Mobile IPv6 includes the support for the mobile node's IPv4 home address mobility and for supporting the scenario where the local mobility anchor and the mobile access gateway are separated by an IPv4 transport network. The IPv4 Local Mobility Anchor Address and MN's IPv4 Home Address SHOULD be included in RADIUS Access-Accept message. 3.2.7. Mobile Node Identity During the access authentication the MN needs to provide at least its home realm to the MAG. The MAG uses the realm information to route the subsequent RADIUS requests to MN's home AAA server. Furthermore, the MAG needs to know the MN Identity when sending a Proxy binding update to the LMA. However, depending on the used authentication mechanism the MAG may not be able to learn the MN identity. For example various EAP-methods provide identity hiding functionality. In this case the home AAA server MUST provide a temporary identity to the MAG to be used in subsequent proxy binding updates. The Chargeable User Id attribute [RFC4372] should be used to for conveying the temporary MN Identity from the AAA server to the MAG. The MAG announces its capability to handle identities provided by the Chargeable User Identity using the capability negotiation as defined in [RFC4372]. 3.3. Accounting 3.3.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. 3.3.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 Xia, et al. Expires August 28, 2008 [Page 10] Internet-Draft RADIUS-PMIPv6 February 2008 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 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. 4. RADIUS Attributes This section describes the RADIUS Proxy Mobile IPv6 support attributes. 4.1. PMIPv6 MN-HoA configuration mode The new defined attribute (MN-HoA configuration) is included in Access-Accept message for MAG to emulate MN's home link. Xia, et al. Expires August 28, 2008 [Page 11] Internet-Draft RADIUS-PMIPv6 February 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 |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | DHCP server address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to be defined by IANA. Length: The length of the attribute. M bit: 1-bit "Managed address configuration" flag. When set, MN uses and DHCP server's address is included in the attribute. When M bit is not set, MN uses stateless address configuration. Reserved: Reserved for future use. DHCP server address: When M bit is set, the field holds DHCP server's address. 4.2. Use of existing RADIUS Attributes This specification reuses RADIUS Mobile IPv6 support attributes defined in [I-D.ietf-mip6-radius] for PMIPv6 purposes. 4.2.1. MIP6-HA Attribute The RADIUS server may dynamically assign a LMA to the MN based on the LMA location, current load or a local policy. 4.2.2. MIP6-HA-FQDN Attribute The RADIUS server may assign an FQDN of the LMA to the MAG. The MAG can perform DNS query or DHCP request with the FQDN to discover the Xia, et al. Expires August 28, 2008 [Page 12] Internet-Draft RADIUS-PMIPv6 February 2008 LMA IP address. 4.2.3. MIP6-HL-Prefix Attribute The RADIUS server may assign a Home Link that is in close proximity to the MAG. The MN can use this prefix to configure a MN-HoA. 4.2.4. MIP6-DNS-MO Attribute By using this payload the MAG as a RADIUS client instructs the RADIUS server to perform a dynamic DNS update. 4.2.5. MIP-MN-HoA Attribute The attribute and the following are defined in [I-D.nakhjiri-radius-mip4] . In this document, these attributes are properly reused in PMIPv6 scenario. By using this payload a RADIUS server deliver MN's MIPv4 Home Address. 4.2.6. MIP-HA-IP Attribute By using this payload a RADIUS server deliver MN's Home Agent Address. 4.2.7. Service-Type The attribute and the following are defined in [RFC2865] . In this document, these attributes are properly reused in PMIPv6 scenario. Service-Type (6) SHALL set its value to "Framed" (2). 4.2.8. Chargeable User Id This attribute MAY be used to convey a temporary MN Identifier that was assigned by the AAA server. The use of this attribute is defined in [RFC4372]. 4.2.9. Calling-Station-Id This attribute MAY be present in Access-Request message and contains the MN Interface identifier. 4.2.10. Callback-Id This attribute MAY be present in Access-Accept message and contains the MN interface identifies assigned by the AAA server. Xia, et al. Expires August 28, 2008 [Page 13] Internet-Draft RADIUS-PMIPv6 February 2008 4.2.11. MS-MPPE-Recv-Key and MS-MPPE-Send-Key When EAP is used in IKEv2 SA establishment, the RADIUS server SHOULD transport the MSK from to LMA or MAG. The MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [RFC2548] are used for the transportation. The first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, and the next up to 32 octets are stored into the MS-MPPE-Send-Key. The encryption of these attributes is described in [RFC2548]. 4.3. Table of Attributes The following table provides a guide to which attributes may be found in authentication and authorization process. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 TBD MN-HoA configuration 0-1 0-1 0 0 TBD MIP6-HA 0-1 0-1 0 0 TBD MIP6-HA-FQDN 0-1 0-1 0 0 TBD MIP6-HL-Prefix 0-1 0-1 0 0 TBD MIP6-DNS-MO 0-1 0-1 0 0 TBD MIP-MN-HoA 0-1 0-1 0 0 TBD MIP-HA-IP 0-1 0-1 0 0 TBD MIP6-Feature-Vector 0-1 0-1 0 0 89 Chargeable-User-Id 0-1 0 0 0 31 Calling-Station-Id 0 0-1 0 0 20 Callback-Id 0 0-1 0 0 VSA MS-MPPE-Recv-Key 0 0-1 0 0 VSA MS-MPPE-Send-Key The following table provides a guide to which attributes may be found in accounting process. Request Interim Stop Attribute 0 0 0 MN-HoA configuration 0-1 0-1 0 MIP6-HA 0 0 0 MIP6-HA-FQDN 0-1 0-1 0 MIP6-HL-Prefix 0 0 0 MIP6-DNS-MO 0-1 0-1 0 MIP-MN-HoA 0-1 0-1 0 MIP-HA-IP 0-1 0-1 0 Service-Type 0-1 0-1 0 MIP6-Feature-Vector 0-1 0-1 0-1 Chargeable-User-Id Xia, et al. Expires August 28, 2008 [Page 14] Internet-Draft RADIUS-PMIPv6 February 2008 5. Diameter Considerations When used in Diameter, the attributes defined in this specification can be used as Diameter AVPs from the Code space 1-255 (RADIUS attribute compatibility space). Diameter PMIPv6 support is defined in [I-D.korhonen-dime-pmip6]. 6. Security Considerations The MAG and the LMA to the RADIUS server transactions must be adequately secured. Otherwise there is a possibility that fraudulent values are received from a rogue RADIUS server. The new attributes defined in this document do not introduce additional security considerations. 7. IANA consideration The type of attribute PMIPv6 MN-HoA configuration mode MUST be assigned by IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. Xia, et al. Expires August 28, 2008 [Page 15] Internet-Draft RADIUS-PMIPv6 February 2008 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. [I-D.ietf-mip6-radius] Chowdhury, K., "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-04 (work in progress), February 2008. 8.2. Informative references [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11 (work in progress), February 2008. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in progress), November 2007. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. [I-D.ietf-dime-mip6-split] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", draft-ietf-dime-mip6-split-07 (work in progress), February 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-08 (work in progress), February 2008. Xia, et al. Expires August 28, 2008 [Page 16] Internet-Draft RADIUS-PMIPv6 February 2008 [I-D.ietf-mip6-hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-11 (work in progress), February 2008. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [I-D.korhonen-dime-pmip6] Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., and U. Meyer, "Diameter Proxy Mobile IPv6: Support For Mobility Access Gateway and Local Mobility Anchor to Diameter Server Interaction", draft-korhonen-dime-pmip6-03 (work in progress), February 2008. [I-D.nakhjiri-radius-mip4] Nakhjiri, M., "RADIUS Mobile IPv4 extensions", draft-nakhjiri-radius-mip4-02 (work in progress), October 2005. Xia, et al. Expires August 28, 2008 [Page 17] Internet-Draft RADIUS-PMIPv6 February 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 TeliaSonera P.O.Box 970 FI-00051 Sonera, FINLAND Email: Jouni.korhonen@teliasonera.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sgundave@cisco.com Xia, et al. Expires August 28, 2008 [Page 18] Internet-Draft RADIUS-PMIPv6 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). Xia, et al. Expires August 28, 2008 [Page 19]