Diameter Maintenance and J. Korhonen (ed.) Extensions (DIME) TeliaSonera Internet-Draft J. Bournelle Intended status: Standards Track France Telecom R&D Expires: December 2, 2007 H. Tschofenig C. Perkins Nokia Siemens Networks K. Chowdhury Starent Networks May 31, 2007 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction draft-ietf-dime-mip6-integrated-04.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 December 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A Mobile IPv6 node requires a Home Agent address, a home address, and Korhonen (ed.), et al. Expires December 2, 2007 [Page 1] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Commands, AVPs and Advertising Application Support . . . . . . 6 4.1. Advertising Application Support . . . . . . . . . . . . . 6 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 6 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 7 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 7 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 4.7. Attribute Value Pair Definitions . . . . . . . . . . . . . 9 4.7.1. Mobility-Agent-Info . . . . . . . . . . . . . . . . . 9 4.7.2. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 9 4.7.3. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 9 4.7.4. Mobility-Capability AVP . . . . . . . . . . . . . . . 9 5. Example Message Flows . . . . . . . . . . . . . . . . . . . . 10 5.1. EAP-based Authentication . . . . . . . . . . . . . . . . . 10 5.2. Integrated Scenario and HA Allocation in MSP . . . . . . . 11 5.3. Integrated Scenario and HA Allocation in ASP . . . . . . . 13 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 14 6.1. AAR, AAA, DER and DEA Commands AVP Table . . . . . . . . . 14 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 15 8.2. New Registry: Mobility Capability . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Korhonen (ed.), et al. Expires December 2, 2007 [Page 2] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 1. Introduction The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) to perform registration with a Home Agent (HA) with information about its current point of attachment (Care-of Address). The HA creates and maintains binding between the MN's Home Address and the MN's Care-of Address. In order to register with a HA, the MN needs to know some information such as the Home Link prefix, the HA address, the Home Address(es), the Home Link prefix Length and security association related information. The aforementioned set of information may be statically provisioned in the MN. However, static provisioning of this information becomes an administrative burden for an operator. Moreover, static provisioning does not address load balancing, failover, opportunistic home link assignment and assignment of local home agents in close proximity to the MN. Also the ability to react on sudden environmental or topological changes is minimal. Static provisioning may not be desirable, in light of the mentioned limitations. Dynamic assignment of MIPv6 home registration information is a desirable feature for ease of deployment and network maintenance. For this purpose, the AAA infrastructure, which is used for access authentication, can be leveraged to assign some or all of the necessary parameters. The Diameter server in Access Service Provider's (ASP) or in Mobility Service Provider's (MSP) network may return these parameters to the AAA client. Regarding the bootstrapping procedures, the AAA client might either be the NAS, in case of the integrated scenario, or the HA, in case of the split scenario [6]. The terms integrated and split are described in the terminology section and were introduced in [7] and [8]. 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 [2]. General mobility terminology can be found in [9]. The following additional terms, as defined in [7], are used in this document: Korhonen (ed.), et al. Expires December 2, 2007 [Page 3] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 Access Service Authorizer (ASA): A network operator that authenticates a MN and establishes the MN's authorization to receive Internet service. Access Service Provider (ASP): A network operator that provides direct IP packet forwarding to and from the MN. Mobility Service Authorizer (MSA): A service provider that authorizes MIPv6 service. Mobility Service Provider (MSP): A service provider that provides MIPv6 service. In order to obtain such service, the MN must be authenticated and authorized to obtain the MIPv6 service. Split scenario: A scenario where the mobility service and the network access service are authorized by different entities. Integrated Scenario: A scenario where the mobility service and the network access service are authorized by the same entity. Network Access Server (NAS): A device that provides an access service for a user to a network. Home AAA (HAAA): An authentication, authorization and accounting server located in user's home network. 3. Overview This document addresses the authentication, authorization and accounting functionality required by for the MIPv6 bootstrapping as outlined in the MIPv6 bootstrapping problem statement document [7]. This document focuses on the Diameter based AAA functionality for the NAS to HAAA interface. Korhonen (ed.), et al. Expires December 2, 2007 [Page 4] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 In the integrated scenario MIPv6 bootstrapping is provided as part of the network access authentication procedure. Figure 1 shows the participating entities. This document, however, only concentrates on the NAS, possible local Diameter proxies and the home Diameter server. +---------------------------+ +-----------------+ |Access Service Provider | |ASA/MSA/(MSP) | |(Mobility Service Provider)| | | | | | | | +--------+ | | +--------+ | | |Local | Diameter | | |Home | | | |Diameter|<---------------------->|Diameter| | | |Proxy | | | |Server | | | +--------+ | | +--------+ | | ^ ^ | | ^ | | | | | | | | | | | | | | | | Diameter | | v | | | | +-------+ | | +-------+ | | | | |Home | | | |Home | | | | +-------->|Agent | | | |Agent | | | | |in ASP | | | |in MSP | | | v +-------+ | | +-------+ | +-------+ IEEE | +-----------+ +-------+ | +-----------------+ |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | |Node |------------|Diameter |---|Server | | | | PANA,... | |Client | | | | +-------+ DHCP | +-----------+ +-------+ | +---------------------------+ Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario In a typical MIPv6 access scenario the MN is attached to an ASP's network. During the network attachment procedure, the NAS/Diameter client interacts with the MN. During the time of authentication the Diameter server in the MSA detects that the user is also authorized for MIPv6 access. Based on the MSA's policy, the Diameter server may return several MIPv6 bootstrapping related parameters. Depending on the details of the bootstrapping solution interaction with the DHCPv6 server may be required, as described in [10]. However, the Diameter based NAS to HAAA interface described in this document is not tied to DHCPv6 as the only possible MIPv6 bootstrapping method. Korhonen (ed.), et al. Expires December 2, 2007 [Page 5] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 4. Commands, AVPs and Advertising Application Support This section describes command codes, defines AVPs and advertised application identifiers for the Diameter MIPv6 bootstrapping in the NAS to HAAA interface. 4.1. Advertising Application Support Diameter nodes conforming to this specification MUST include the value of 1 (NASREQ application) or 5 (EAP application) in the Auth- Application-Id and the Acct-Application-Id AVP of the Capabilities- Exchange-Request / Capabilities-Exchange-Answer commands [3]. 4.2. Command Codes This document re-uses the Diameter NASREQ application [4] and the EAP application commands [5]. The following commands are used to carry MIPv6 related bootstrapping AVPs: Command-Name Abbrev. Code Reference Application Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP AA-Request AAR 265 RFC 4005 NASREQ AA-Answer AAA 265 RFC 4005 NASREQ Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- Termination-Request (STR), Session-Termination-Answer (STA), Abort- Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules in the Diameter NASREQ [5], EAP [4] and RFC 3588 [3] applications. The accounting commands use the Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). 4.3. Diameter-EAP-Request (DER) The Diameter-EAP-Request (DER) message [4], indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access authentication and authorization procedure. The DER message format is the same as defined in [4]. The message MAY include Korhonen (ed.), et al. Expires December 2, 2007 [Page 6] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 optional MIPv6 bootstrapping AVPs: ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } * [ Mobility-Agent-Info ] [ Mobility-Capability ] [ Destination-Host ] ... * [ AVP ] 4.4. Diameter-EAP-Answer (DEA) The Diameter-EAP-Answer (DEA) message defined in [4], indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER). If the network access authentication procedure was successful then the response MAY include any set of bootstrapping AVPs. The DEA message format is the same as defined in [4] with an addition of optional MIPv6 bootstrapping AVPs: ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } * [ Mobility-Agent-Info ] [ Mobility-Capability ] [ User-Name ] ... * [ AVP ] 4.5. AA-Request (AAR) The AA-Request (AAR) message [5], indicated by the Command-Code field set to 265 and 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access Korhonen (ed.), et al. Expires December 2, 2007 [Page 7] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 authentication and authorization procedure. The AAR message format is the same as defined in [5]. The message MAY include optional MIPv6 bootstrapping AVPs: ::= < Diameter Header: 265, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } * [ Mobility-Agent-Info ] [ Mobility-Capability ] [ Destination-Host ] ... * [ AVP ] 4.6. AA-Answer (AAA) The AA-Answer (AAA) message, indicated by the Command-Code field set to 265 and 'R' bit cleared in the Command Flags field is sent in response to the AA-Request (AAR) message for confirmation of the result of MIPv6 HA bootstrapping. If the network access authentication procedure was successful then the response MAY include any set of bootstrapping AVPs. The AAA message format is the same as defined in [5] with an addition of optional MIPv6 bootstrapping AVPs: ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } * [ Mobility-Agent-Info ] [ Mobility-Capability ] [ User-Name ] ... * [ AVP ] Korhonen (ed.), et al. Expires December 2, 2007 [Page 8] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 4.7. Attribute Value Pair Definitions 4.7.1. Mobility-Agent-Info The Mobility-Agent-Info AVP (AVP code TBD) is type of Grouped and contains necessary information to assign a HA to the MN. When the Mobility-Agent-Info AVP is present in a message, it MUST contain either a MIP6-Home-Agent-Address AVP or a MIP6-Home-Agent-FQDN AVP, but not both. The grouped AVP has the following grammar: ::= < AVP Header: TBD > [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] * [ AVP ] 4.7.2. MIP6-Home-Agent-Address AVP The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type Address (see Section 4.3 in [3]) and contains the HA address. The Diameter server MAY decide to assign a HA to the MN that is in close proximity to the point of attachment (e.g., determined by the NAS-Identifier AVP). There may be other reasons for dynamically assigning HAs to the MN, for example to share the traffic load. This AVP MAY also be attached by the NAS when sent to the Diameter server in a request message as a hint of a locally assigned HA address. 4.7.3. MIP6-Home-Agent-FQDN AVP The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and contains the FQDN of a HA. The usage of this AVP is equivalent to the MIP6-Home-Agent-Address AVP but offers an additional level of indirection via the DNS infrastructure. 4.7.4. Mobility-Capability AVP The Mobility-Capability AVP (AVP Code TBD) is of type Unsigned64 and contains a 64 bits flags field of supported capabilities of the NAS/ ASP. Sending and receiving the Mobility-Capability AVP with value 0 MUST be supported. The NAS MAY include this AVP to indicate capabilities of the NAS/ASP to the Diameter server. For example, the NAS may indicate that a local home agent can be provided. Similarly, the Diameter server MAY include this AVP to inform the NAS/ASP about which of the NAS/ASP indicated capabilities are supported or authorized by the ASA/MSA(/ MSP). Korhonen (ed.), et al. Expires December 2, 2007 [Page 9] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 The following capabilities are defined in this document: MOBILITY_CAPABILITY (0x0000000000000000) The Mobility-Capability AVP MAY contain value 0 (zero) with the semantics that are defined in this document for the Mobile IPv6 bootstrapping functionality. This 'zero' flag is always implicitly set when the Mobility-Capability AVP is used. LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000001) This flag is set by the NAS/ASP when a local home agent can be assigned to the MN. This flag is set by the ASA/MSA(/MSP) when the use of a local HA is authorized. 5. Example Message Flows 5.1. EAP-based Authentication This section shows basic message flows of MIPv6 integrated scenario bootstrapping and dynamic HA assignment. In Figure 3 network access authentication is based on EAP (e.g., 802.11i/802.1X). The NAS informs the home Diameter server that it wishes to provide a locally assigned HA to the visiting MN. The Diameter server assigns the MN a HA in the home MSP but also authorizes the assignment of local HA for the ASP. The Diameter server then replies to the NAS with HA related bootstrapping information. Whether the NAS/ASP then offers a locally assigned HA or the MSP assigned HA to the MN is based on the local ASP policy. Korhonen (ed.), et al. Expires December 2, 2007 [Page 10] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 NAS Home server | | | Diameter-EAP-Request | | Mobility-Capability=LOCAL_HOME_AGENT_ASSIGNMENT | | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | | EAP-Payload(EAP Start) | |---------------------------------------------------------------->| | | | | : ...more EAP Request/Response pairs... : | | | | | Diameter-EAP-Answer | | Mobility-Agent-Info{ | | MIP6-Home-Agent-Address(IPv6 address) | | MIP6-Home-Agent-FQDN=ha.example.com } | | Mobility-Capability=LOCAL_HOME_AGENT_ASSIGNMENT | | Result-Code=DIAMETER_SUCCESS | | EAP-Payload(EAP Success) | | EAP-Master-Session-Key | | (authorization AVPs) | | ... | |<----------------------------------------------------------------| | | Figure 3: Diameter EAP Application with MIPv6 bootstrapping 5.2. Integrated Scenario and HA Allocation in MSP Diameter is used to authenticate and authorize the MN for the mobility service, and to send information about the allocated HA to the NAS. In this example scenario the MN uses DHCP for its IP address configuration. Korhonen (ed.), et al. Expires December 2, 2007 [Page 11] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 | --------------ASP------>|<--ASA/MSA/(MSP)-- | +----+ +--------+ +-------+ +--------+ | | |Diameter| | | | | | | | Client | | | | | | MN | | NAS/ | | DHCP | | Home | | | | DHCP | | Server| |Diameter| | | | Relay | | | | Server | +-+--+ +----+---+ +---+---+ +--------+ | | | | | 1 | 2 | | |<------------->|<----------------------->| | | | | | | | | | 3 | | | |-------------->| | | | | | | | | 4 | | | |------------>| | | | | | | | 5 | | | |<------------| | | | | | | 6 | | | |<--------------| | | | | | | Figure 4: Mobile IPv6 Integrated Scenario Bootstrapping and the allocation of HAs either in the ASP or in the MSP 1) The MN executes the normal network access authentication procedure (IEEE 802.11i/802.1X, PANA, ...) with the NAS. The NAS acts as an authenticator in "pass-through" mode. The other endpoint of the authentication dialogue is the MN's home Diameter server. This is a typical scenario for network access authentication using EAP methods. The NAS includes at least one of the NAS to HAAA interface AVPs in the DER or in the AAR messages to indicate MIPv6 bootstrapping capability. For example, the NAS could include the Mobility-Capability AVP with a value 0. 2) Depending on the Diameter server configuration and the user's subscription profile, the Mobility-Agent-Info AVP and/or the Mobility-Capability AVP may be carried in the DEA, assuming the home Diameter server has allocated a HA to the MN. In case the MIP6-Home-Agent-FQDN AVP was returned within the Mobility-Agent- Info grouped AVP the MN ultimately needs to perform a DNS query in order to discover the HA's IP address. For example, the home Korhonen (ed.), et al. Expires December 2, 2007 [Page 12] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 Diameter server could return the following AVPs: o Mobility-Agent-Info grouped AVP containing: * MIP6-Home-Agent-Address = 2001:db8:6000:302::1/64 * MIP6-Home-Agent-FQDN = ha.example.com 3) the MN sends a DHCPv6 Information Request message to all_DHCP_Relay_Agents_and_Servers address. In the OPTION_ORO, Option Code for the Home Network Identifier Option shall be included in that message [10]. The Home Network Identifier Option should have id-type of 1, the message is a request to discover home network information that pertains to the given realm, i.e., the user's home domain (identified by the NAI of the MN). The OPTION_CLIENTID is set by the MN to identify itself to the DHCP server. Steps 4 to 6 are not relevant from the NAS to HAAA Diameter interface point of view and are not described in this document. The reader should consult [10] for a detailed description about the rest of the integrated scenario bootstrapping procedure. 5.3. Integrated Scenario and HA Allocation in ASP This scenario is similar to the one described in Section 5.2 and illustrated in Figure 4. There are slight differences in steps 2) and 3). 2) The NAS/ASP wishes to allocate a local HA to the visiting MN. The NAS/ASP will also inform the Diameter server about the HA address it has assigned to the visiting MN (e.g., 2001:db8:1:c020::1). In this case the NAS includes the following AVPs in the DER or in the AAR messages: o Mobility-Capability = LOCAL_HOME_AGENT_ASSIGNMENT o Mobility-Agent-Info grouped AVP containing: * MIP6-Home-Agent-Address = 2001:db8:1:c020::1 Depending on the Diameter server configuration and user's subscription profile, the Diameter server either accepts or rejects the proposal of locally allocated HA in the NAS/ASP. If the Diameter server accepts the proposal then the Mobility- Capability AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit set is returned back to the NAS. On the other hand if the Diameter server does not accept locally assigned HA, the Diameter returns the Mobility-Capability AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit unset. The Diameter server assigns a HA to the MN (e.g., 2001: db8:6000::1) in the ASA/MSA/(MSP) and returns the IP address back to the NAS/ASP. In a case the home Diameter server accepted the Korhonen (ed.), et al. Expires December 2, 2007 [Page 13] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 NAS/ASP proposal of local HA the home Diameter server would return, for example, the following AVPs: o Mobility-Capability = LOCAL_HOME_AGENT_ASSIGNMENT o Mobility-Agent-Info grouped AVP containing: * MIP6-Home-Agent-Address = 2001:db8:6000::1 3) The type-id field in the Home Network Identifier Option is set to zero, indicating that a HA is requested in the ASP instead of in the MSP. Depending on the result of the phase 2) the DHCP relay agent places in the OPTION_MIP6-RELAY-Option either the locally allocated HA information or the HA information that was returned (proposed) by home Diameter server. The selection of local or home allocated HAs in based on the local policy in the ASP. It is also possible that both local and home allocated HAs are available for the MN. The policy and heuristics when to select the local HA and when the home HA are outside of this specification. 6. AVP Occurrence Tables 6.1. AAR, AAA, DER and DEA Commands AVP Table The following table lists the additional MIPv6 bootstrapping NAS to HAAA interface AVPs that may optionally be present in the AAR and AAA Commands [5] or in the DER and DEA Commands [4]. +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AAR | AAA | DER | DEA | -------------------------------|-----+-----|-----+-----+ Mobility-Agent-Info | 0+ | 0+ | 0+ | 0+ | Mobility-Capability | 0-1 | 0-1 | 0-1 | 0-1 | +-----+-----+-----+-----+ Figure 5: AAR, AAA, DER and DEA Commands AVP Table 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs This section defines AVPs that are specific to Diameter MIPv6 bootstrapping NAS to HAAA interface and MAY be included in the Diameter EAP [4] and the NASREQ [5] application messages. The Diameter AVP rules are defined in the Diameter Base [3], Section 4. These AVP rules are observed in AVPs defined in this section. Korhonen (ed.), et al. Expires December 2, 2007 [Page 14] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 The following table describes the Diameter AVPs, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [3] specifies the AVP Flag rules for AVPs in Section 4.5. +---------------------+ | AVP Flag rules | +----+-----+----+-----+----+ AVP Section | | |SHLD|MUST | | Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| ------------------------------------------+----+-----+----+-----+----+ Mobility- | | | | | | Agent-Info TBD 4.7.1 Grouped | | P | | M,V | Y | MIP6-Home-Agent- | | | | | | Address TBD 4.7.2 Address | | P | | M,V | Y | MIP6-Home-Agent- | | | | | | FQDN TBD 4.7.3 UTF8String | | P | | M,V | Y | Mobility- | | | | | | Capability TBD 4.7.4 Unsigned64 | | P | | M,V | Y | ------------------------------------------+----+-----+----+-----+----+ Figure 6: AVP Flag Rules Table 8. IANA Considerations 8.1. Registration of new AVPs This specification defines the following new AVPs: Mobility-Agent-Info is set to TBD MIP6-Home-Agent-Address is set to TBD MIP6-Home-Agent-FQDN is set to TBD Mobility-Capability is set to TBD 8.2. New Registry: Mobility Capability IANA is requested to create a new registry for the Mobility Capability as described in Section 4.7.4. Token | Value | Description ----------------------------------+----------------------+------------ MOBILITTY_CAPABILITY | 0x0000000000000000 | [RFC TBD] LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000001 | [RFC TBD] Available for Assignment via IANA | 2^x | Allocation rule: Only numeric values that are 2^x (power of two) are allowed based on the allocation policy described below. Korhonen (ed.), et al. Expires December 2, 2007 [Page 15] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 Following the policies outlined in [1] new values with a description of their semantic for usage with the Mobility-Capability AVP together with a Token will be assigned after Expert Review initiated by the O&M Area Directors in consultation with the DIME working group chairs or the working group chairs of a designated successor working group. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry. 9. Security Considerations The security considerations for the Diameter interaction required to accomplish the integrated scenario are described in [10]. Additionally, the security considerations of the Diameter base protocol [3], Diameter NASREQ application [5] / Diameter EAP [4] application (with respect to network access authentication and the transport of keying material) are applicable to this document. This document does not introduce new security vulnerabilities. 10. Acknowledgements This document is heavily based on the ongoing work for RADIUS MIPv6 interaction. Hence, credits go to respective authors for their work with draft-ietf-mip6-radius. Furthermore, the author would like to thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work in context of MIPv6 Diameter interworking. Their work influenced this document. Julien Bournelle would like to thank GET/INT since he began to work on this document while he was in their employ. Authors would also like to acknowledge Raymond Hsu for his valuable feedback on local HA assignment and Wolfgang Fritsche for his thorough review. 11. References 11.1. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Korhonen (ed.), et al. Expires December 2, 2007 [Page 16] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [5] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. 11.2. Informative References [6] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-04 (work in progress), December 2006. [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. [8] Giaretta, G., "AAA Goals for Mobile IPv6", draft-ietf-mip6-aaa-ha-goals-03 (work in progress), September 2006. [9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [10] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in progress), February 2007. Authors' Addresses Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland Email: jouni.korhonen@teliasonera.com Julien Bournelle France Telecom R&D 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France Email: julien.bournelle@orange-ftgroup.com Korhonen (ed.), et al. Expires December 2, 2007 [Page 17] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Charles E. Perkins Nokia Siemens Networks 313 Fairchild Drive Mountain View CA 94043 US Phone: +1 650 625-2986 Email: charliep@nsn.com Kuntal Chowdhury Starent Networks 30 International Place Tewksbury MA 01876 US Phone: +1 214 550 1416 Email: kchowdhury@starentnetworks.com Korhonen (ed.), et al. Expires December 2, 2007 [Page 18] Internet-Draft Diameter MIPv6 NAS to HAAA Interaction May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Korhonen (ed.), et al. Expires December 2, 2007 [Page 19]