draft-ietf-dime-pmip6-03.txt   draft-ietf-dime-pmip6-04.txt 
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) Nokia Siemens Network Extensions (DIME) Nokia Siemens Network
Internet-Draft J. Bournelle Internet-Draft J. Bournelle
Intended status: Standards Track Orange Labs Intended status: Standards Track Orange Labs
Expires: February 25, 2010 K. Chowdhury Expires: March 26, 2010 K. Chowdhury
Starent Networks Starent Networks
A. Muhanna A. Muhanna
Nortel Nortel
U. Meyer U. Meyer
RWTH Aachen RWTH Aachen
August 24, 2009 September 22, 2009
Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility
Anchor Interaction with Diameter Server Anchor Interaction with Diameter Server
draft-ietf-dime-pmip6-03.txt draft-ietf-dime-pmip6-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2010. This Internet-Draft will expire on March 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 13 skipping to change at page 3, line 13
IPv6 entities and a remote policy store. IPv6 entities and a remote policy store.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Generic Application Support and Command Codes . . . . . . . . 7 4. Generic Application Support and Command Codes . . . . . . . . 7
4.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 7 4.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 7
4.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 7 4.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 7
5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 8 4.2.1. General Operation and Authorization of PBU . . . . . . 8
5.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 8 4.2.2. Updating LMA Address to HAAA . . . . . . . . . . . . . 9
5.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 9 4.2.3. Mobile Node Address Update and Assignment . . . . . . 9
5.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 9 5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 10
5.4. PMIP6-DHCP-Server-Address AVP . . . . . . . . . . . . . . 10 5.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 10
5.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 10 5.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 10
5.6. Mobile-Node-Identifier AVP . . . . . . . . . . . . . . . . 11 5.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 11
5.7. Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . 11 5.4. PMIP6-DHCP-Server-Address AVP . . . . . . . . . . . . . . 11
5.8. Service-Selection AVP . . . . . . . . . . . . . . . . . . 11 5.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 11
5.9. Service-Configuration AVP . . . . . . . . . . . . . . . . 12 5.6. Mobile-Node-Identifier AVP . . . . . . . . . . . . . . . . 12
6. Proxy Mobile IPv6 Session Management . . . . . . . . . . . . . 12 5.7. Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . 13
6.1. Session-Termination-Request . . . . . . . . . . . . . . . 13 5.8. Service-Selection AVP . . . . . . . . . . . . . . . . . . 13
6.2. Session-Termination-Answer . . . . . . . . . . . . . . . . 13 5.9. Service-Configuration AVP . . . . . . . . . . . . . . . . 14
6.3. Abort-Session-Request . . . . . . . . . . . . . . . . . . 13 6. Proxy Mobile IPv6 Session Management . . . . . . . . . . . . . 14
6.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . . . 13 6.1. Session-Termination-Request . . . . . . . . . . . . . . . 14
7. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 13 6.2. Session-Termination-Answer . . . . . . . . . . . . . . . . 15
7.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 14 6.3. Abort-Session-Request . . . . . . . . . . . . . . . . . . 15
7.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 14 6.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . . . 15
8. Example Signaling Flows . . . . . . . . . . . . . . . . . . . 14 7. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 15
9.1. Attribute Value Pair Codes . . . . . . . . . . . . . . . . 16 7.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 16
9.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Example Signaling Flows . . . . . . . . . . . . . . . . . . . 16
9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9.1. Attribute Value Pair Codes . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This specification defines Authentication, Authorization, and This specification defines Authentication, Authorization, and
Accounting (AAA) interactions between a Mobile Access Gateway (MAG) Accounting (AAA) interactions between a Mobile Access Gateway (MAG)
and an AAA server, and between a Local Mobility Anchor (LMA) and an and an AAA server, and between a Local Mobility Anchor (LMA) and an
AAA server within a Proxy Mobile IPv6 (PMIPv6) Domain [RFC5213]. AAA server within a Proxy Mobile IPv6 (PMIPv6) Domain [RFC5213].
These AAA interactions are primarily used to download and update These AAA interactions are primarily used to download and update
mobile node (MN) specific policy profile information between PMIPv6 mobile node (MN) specific policy profile information between PMIPv6
entities (a MAG and a LMA) and a remote policy store. entities (a MAG and a LMA) and a remote policy store.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
| +----+ +----+ | +----+ +----+
+---->|MAG1| |MAG2| +---->|MAG1| |MAG2|
+----+ +----+ +----+ +----+
| | | |
| | | |
[MN1] [MN2] [MN1] [MN2]
Legend: Legend:
(1): MAG-to-HAAA interaction is described (1): MAG-to-HAAA interaction is described
in Section 5.1 in Section 7.1
(2): LMA-to-HAAA interaction is described (2): LMA-to-HAAA interaction is described
in Section 5.2 in Section 7.2
Figure 1: Proxy Mobile IPv6 Domain Interaction with Diameter HAAA Figure 1: Proxy Mobile IPv6 Domain Interaction with Diameter HAAA
Server Server
When a MN attaches to a PMIPv6 Domain, a network access When a MN attaches to a PMIPv6 Domain, a network access
authentication procedure is usually started. The choice of the authentication procedure is usually started. The choice of the
authentication mechanism is specific to the access network authentication mechanism is specific to the access network
deployment, but could be based on the Extensible Authentication deployment, but could be based on the Extensible Authentication
Protocol (EAP) [RFC3748]. During the network access authentication Protocol (EAP) [RFC3748]. During the network access authentication
procedure, the MAG acting as a NAS queries the HAAA through the AAA procedure, the MAG acting as a NAS queries the HAAA through the AAA
skipping to change at page 7, line 46 skipping to change at page 7, line 46
MN's identities in Section 5.6 and in Section 4.2. MN's identities in Section 5.6 and in Section 4.2.
For the session management and service authorization purposes, For the session management and service authorization purposes,
session state SHOULD be maintained on the MAG-to-HAAA interface. See session state SHOULD be maintained on the MAG-to-HAAA interface. See
the discussion in Section 5.8. the discussion in Section 5.8.
4.2. LMA-to-HAAA Interface 4.2. LMA-to-HAAA Interface
The-LMA-to HAAA interface may be used for multiple purposes. These The-LMA-to HAAA interface may be used for multiple purposes. These
include the authorization of the incoming PBU, updating the LMA include the authorization of the incoming PBU, updating the LMA
address to the HAAA, delegating the assignment of the HNP or the address to the HAAA, delegating the assignment of the MN-HNP or the
IPv4-HoA to the HAAA, and for accounting and PMIPv6 session IPv4-HoA to the HAAA, and for accounting and PMIPv6 session
management. management. The primary purpose of this interface is to update the
HAAA with the LMA address information in case of dynamically assigned
LMA, and exchange the MN address assignment information between the
LMA and the HAAA.
The LMA-to-HAAA interface description is intended for different types
of deployments and architectures. Therefore, this specification only
outlines AVPs and considerations that the deployment specific
Diameter applications need to take into account from the PMIPv6 and
LMAs point of view.
4.2.1. General Operation and Authorization of PBU
Whenever the LMA sends a Diameter request message to the HAAA, the Whenever the LMA sends a Diameter request message to the HAAA, the
User-Name AVP SHOULD contain the MN's identity. The LMA MAY retrieve User-Name AVP SHOULD contain the MN's identity. The LMA provided
the MN's identity information from the PBU MN-ID [RFC4283][RFC5213] identity in the User-Name AVP is strongly RECOMMENDED to be the same
mobility option. The identity SHOULD be the same as used on the MAG- as the MN's identity information in the PBU MN-ID [RFC4283] [RFC5213]
to-HAAA interface, but in the case those identities differ the HAAA mobility option. The identity SHOULD also be the same as used on the
MUST have a mechanism of mapping the MN identity used on the MAG-to- MAG-to-HAAA interface, but in the case those identities differ the
HAAA interface to the identity used on the LMA-to-HAAA interface. HAAA MUST have a mechanism of mapping the MN identity used on the
MAG-to-HAAA interface to the identity used on the LMA-to-HAAA
interface.
If the PBU contains the MN Link-Layer Identifier option, the Calling- If the PBU contains the MN Link-Layer Identifier option, the Calling-
Station-Id AVP SHOULD be included in the request message containing Station-Id AVP SHOULD be included in the request message containing
the received Link-Layer Identifier. Furthermore, if the PBU contains the received Link-Layer Identifier. Furthermore, if the PBU contains
the Service Selection mobility option [RFC5149], the Service- the Service Selection mobility option [RFC5149], the Service-
Selection AVP SHOULD be included in the request message containing Selection AVP SHOULD be included in the request message containing
the received service identifier. the received service identifier. Both MN Link-Layer Identifier and
the Service selection can be used to provide more information for the
PBU authorization step in the HAAA.
The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY.
The Diameter session related aspects discussed in Section 6 need to
be taken into consideration when designing the Diameter application
for the LMA-to-HAAA interface. If the HAAA is not able to authorize
the subscriber's mobility service session, then the reply message to
the LMA MUST have the Result-Code AVP set to value
DIAMETER_AUTHORIZATION_REJECTED (5003) indicating a permanent
failure. A failed authorization obviously results to a rejection of
the PBU and a PBA with an appropriate error Status Value MUST be sent
back to the MAG.
The authorization step MUST be performed at least for the initial PBU
session up a mobility session, when the LMA-to-HAAA interface is
deployed. For the subsequent re-registration and handover PBUs, the
authorization step MAY be repeated (in this case, the LMA-to-HAAA
interface should also maintain an authorization session state).
4.2.2. Updating LMA Address to HAAA
In case of a dynamic LMA discovery and assignment
[I-D.ietf-netlmm-lma-discovery] the HAAA and the remote policy store
may need to be updated with the selected LMA address information.
The update can be done during the PBU authorization step using the
LMA-to-HAAA interface. This specification uses the MIP6-Agent-Info
AVP and its MIP-Home-Agent-Address and MIP-Home-Agent-Host sub-AVPs
for carrying the LMA's address information from the LMA to the HAAA.
The LMA address information in the request message MUST contain the
IP address of the LMA or the FQDN identifying uniquely the LMA, or
both. The LMA address information refers to PMIPv6 part of the LMA,
not necessarily the LMA part interfacing with the AAA infrastructure.
This specification does not define any HAAA initiated LMA relocation
functionality. Therefore, when the MIP6-Agent-Info AVP is included
in Diameter answer messages sent from the HAAA to the LMA, the HAAA
indicates this by setting the MIP-Home-Agent-Address AVP to all
zeroes address (e.g., 0::0) and not including the MIP-Home-Agent-Host
AVP.
4.2.3. Mobile Node Address Update and Assignment
The LMA and the HAAA use the MIP6-Home-Link-Prefix AVP to exchange The LMA and the HAAA use the MIP6-Home-Link-Prefix AVP to exchange
the MN-HNP when appropriate. Similarly, the LMA and the HAAA use the the MN-HNP when appropriate. Similarly, the LMA and the HAAA use the
PMIP6-IPv4-Home-Address AVP to exchange the IPv4-MN-HoA when PMIP6-IPv4-Home-Address AVP to exchange the IPv4-MN-HoA when
appropriate. Note that these AVPs are encapsulated inside the MIP6- appropriate. These AVPs are encapsulated inside the MIP6-Agent-Info
Agent-Info AVP. Which entity is actually responsible for the address AVP. The MN address information exchange is again done during the
management is a deployment specific within the PMIPv6 Domain and MUST PBU authorization step. The HAAA MAY also use the LMA provided MN
be pre-agreed on per deployment basis. address information as a part of the information used to authorize
the PBU.
The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY. Which entity is actually responsible for the address management is
If the HAAA is not able to authorize the subscriber's mobility deployment specific within the PMIPv6 Domain and MUST be pre-agreed
service session, then the reply message to the LMA MUST have the on per deployment basis. When the LMA is responsible for the address
Result-Code AVP set to value DIAMETER_PMIP6_AUTHORIZATION_FAILED management, the MIP6-Agent-Info AVP is used to inform the HAAA and
(TBD5) indicating a permanent failure. the remote policy store of the MN-HNP/IPv4-MN-HoA assigned to the MN.
The LMA-to-HAAA interface can also be used to update the selected LMA It is also possible that the LMA delegates the address management to
address to the HAAA and the remote policy store during the the HAAA. In this case, the MN-HNP/IPv4-MN-HoA are set to undefined
authorization step. This applies to the case where the MAG, for addresses (as described in Section 5.1) in the Diameter request
example, discovered the LMA address using the DNS. message sent from the LMA to the HAAA. The LMA expects to receive
the HAAA assigned HNP/IPv4-MN-HoA in the corresponding Diameter
answer message.
5. Attribute Value Pair Definitions 5. Attribute Value Pair Definitions
This section describes Attribute Value Pairs (AVPs) defined by this This section describes Attribute Value Pairs (AVPs) defined by this
specification or re-used from existing specifications in a PMIPv6 specification or re-used from existing specifications in a PMIPv6
specific way. Derived Diameter AVP Data Formats such as Address and specific way. Derived Diameter AVP Data Formats such as Address and
UTF8String are defined in Section 4.3 of RFC 3588. Grouped AVP UTF8String are defined in Section 4.3 of RFC 3588. Grouped AVP
values are defined in Section 4.4 of RFC 3588. values are defined in Section 4.4 of RFC 3588.
5.1. MIP6-Agent-Info AVP 5.1. MIP6-Agent-Info AVP
skipping to change at page 9, line 17 skipping to change at page 10, line 32
The extended MIP6-Agent-Info AVP results to the following grouped The extended MIP6-Agent-Info AVP results to the following grouped
AVP: AVP:
MIP6-Agent-Info ::= < AVP-Header: 486 > MIP6-Agent-Info ::= < AVP-Header: 486 >
*2[ MIP-Home-Agent-Address ] *2[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ] [ MIP-Home-Agent-Host ]
[ MIP6-Home-Link-Prefix ] [ MIP6-Home-Link-Prefix ]
[ PMIP6-IPv4-Home-Address ] [ PMIP6-IPv4-Home-Address ]
* [ AVP ] * [ AVP ]
If the MIP-Home-Agent-Address is set to all zeroes address (e.g.,
0::0), the receiver of the MIP6-Agent-Info AVP MUST ignore the MIP-
Home-Agent-Address AVP.
5.2. PMIP6-IPv4-Home-Address AVP 5.2. PMIP6-IPv4-Home-Address AVP
The PMIP6-IPv4-Home-Address AVP (AVP Code TBD2) is of type Address The PMIP6-IPv4-Home-Address AVP (AVP Code TBD2) is of type Address
and contains an IPv4 address. This AVP is used to carry the IPv4-MN- and contains an IPv4 address. This AVP is used to carry the IPv4-MN-
HoA, if available, from the HAAA to the MAG. This AVP SHOULD only be HoA, if available, from the HAAA to the MAG. This AVP SHOULD only be
present when the MN is statically provisioned with the IPv4-MN-HoA. present when the MN is statically provisioned with the IPv4-MN-HoA.
Note that proactive dynamic assignment of the IPv4-MN-HoA by the HAAA Note that proactive dynamic assignment of the IPv4-MN-HoA by the HAAA
may result in unnecessary reservation of IPv4 address resources, may result in unnecessary reservation of IPv4 address resources,
because the MN may considerably delay or completely bypass its IPv4 because the MN may considerably delay or completely bypass its IPv4
address configuration. address configuration.
skipping to change at page 11, line 39 skipping to change at page 13, line 10
MAG MUST use the received MN-Identifier, if it has not been able to MAG MUST use the received MN-Identifier, if it has not been able to
get the mobile node identifier through other means. If the MAG get the mobile node identifier through other means. If the MAG
already has a valid mobile node identifier, then the MAG MUST already has a valid mobile node identifier, then the MAG MUST
silently discard the received MN-identifier. silently discard the received MN-identifier.
5.7. Calling-Station-Id AVP 5.7. Calling-Station-Id AVP
The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
contains a Link-Layer Identifier of the MN. This identifier contains a Link-Layer Identifier of the MN. This identifier
corresponds to the Link-Layer Identifier as defined in RFC 5213 corresponds to the Link-Layer Identifier as defined in RFC 5213
Section 2.2. and 8.6. Section 2.2 and 8.6. The Link-Layer Identifier is encoded in ASCII
format (upper case only), with octet values separated by a "-".
Example: "00-23-32-C9-79-38". The encoding is actually the same as
the MAC address encoding in Section 3.21 of RFC 3580.
5.8. Service-Selection AVP 5.8. Service-Selection AVP
The Service-Selection AVP (AVP Code 493) is of type UTF8String and The Service-Selection AVP (AVP Code 493) is of type UTF8String and
contains a LMA provided service identifier on the LMA-to-HAAA contains a LMA provided service identifier on the LMA-to-HAAA
interface. This AVP is re-used from [I-D.ietf-dime-mip6-split]. The interface. This AVP is re-used from [I-D.ietf-dime-mip6-split]. The
service identifier may be used to assist the PBU authorization and service identifier may be used to assist the PBU authorization and
the assignment of the MN-HNP and the IPv4-MN-HoA as described in RFC the assignment of the MN-HNP and the IPv4-MN-HoA as described in RFC
5149 [RFC5149]. The identifier MUST be unique within the PMIPv6 5149 [RFC5149]. The identifier MUST be unique within the PMIPv6
Domain. In the absence of the Service-Selection AVP in the request Domain. In the absence of the Service-Selection AVP in the request
skipping to change at page 15, line 9 skipping to change at page 16, line 32
8. Example Signaling Flows 8. Example Signaling Flows
Figure 4 shows a signaling flow example during PMIPv6 bootstrapping Figure 4 shows a signaling flow example during PMIPv6 bootstrapping
using the AAA interactions defined in this specification. In step using the AAA interactions defined in this specification. In step
(1) of this example, the MN is authenticated to PMIPv6 Domain using (1) of this example, the MN is authenticated to PMIPv6 Domain using
EAP-based authentication. The MAG to the HAAA signaling uses the EAP-based authentication. The MAG to the HAAA signaling uses the
Diameter EAP Application. During step (2), the LMA uses Diameter Diameter EAP Application. During step (2), the LMA uses Diameter
NASREQ application to authorize the MN with the HAAA server. NASREQ application to authorize the MN with the HAAA server.
The MAG-to-HAAA AVPs, as listed in Section 7.1 are used during step The MAG-to-HAAA AVPs, as listed in Section 7.1 are used during step
(1). These AVPs are included only in the DER message which starts (1). These AVPs are included only in the Diameter EAP Request (DER)
the EAP exchange and in the corresponding DEA message which message which starts the EAP exchange and in the corresponding
successfully completes this EAP exchange. The LMA-to-HAAA AVPs, as Diameter EAP Answer (DEA) message which successfully completes this
listed in Section 7.2, are used during step (2). Step (2) is used to EAP exchange. The LMA-to-HAAA AVPs, as listed in Section 7.2, are
authorize the MN request for the mobility service and update the HAAA used during step (2). Step (2) is used to authorize the MN request
server with the assigned LMA information. In addition, this step may for the mobility service and update the HAAA server with the assigned
be used to dynamically assist in the assignment of the MN-HNP. LMA information. In addition, this step may be used to dynamically
assist in the assignment of the MN-HNP.
MN MAG/NAS LMA HAAA MN MAG/NAS LMA HAAA
| | | | | | | |
| L2 attach | | | | L2 attach | | |
|-------------------->| | | |-------------------->| | |
| EAP/req-identity | | | | EAP/req-identity | | |
|<--------------------| | | |<--------------------| | |
| EAP/res-identity | DER + MAG-to-HAAA AVPs | s | EAP/res-identity | DER + MAG-to-HAAA AVPs | s
|-------------------->|---------------------------------------->| t |-------------------->|---------------------------------------->| t
| EAP/req #1 | DEA (EAP request #1) | e | EAP/req #1 | DEA (EAP request #1) | e
skipping to change at page 17, line 16 skipping to change at page 18, line 16
This specification defines new values to the Mobility Capability This specification defines new values to the Mobility Capability
registry (see [RFC5447]) for use with the MIP6-Feature-Vector AVP: registry (see [RFC5447]) for use with the MIP6-Feature-Vector AVP:
Token | Value | Description Token | Value | Description
---------------------------------+----------------------+------------ ---------------------------------+----------------------+------------
PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD] PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD]
IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD] IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD]
LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD] LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD]
9.3. Result-Code AVP Values
This specification requests IANA to allocate a new value to the
Result-Code AVP (AVP Code 268) address space within the Permanent
Failures category (5xxx) defined in [RFC3588]:
DIAMETER_PMIP6_AUTHORIZATION_FAILED is set to TBD5
10. Security Considerations 10. Security Considerations
The security considerations of the Diameter Base protocol [RFC3588], The security considerations of the Diameter Base protocol [RFC3588],
Diameter EAP application [RFC4072], Diameter NASREQ application Diameter EAP application [RFC4072], Diameter NASREQ application
[RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping [RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping
[RFC5447] are applicable to this document. [RFC5447] are applicable to this document.
In general, the Diameter messages may be transported between the HA In general, the Diameter messages may be transported between the LMA
and the Diameter server via one or more AAA brokers or Diameter and the Diameter server via one or more AAA brokers or Diameter
agents. In this case the HA to the Diameter server AAA communication agents. In this case the LMA to the Diameter server AAA
rely on the security properties of the intermediate AAA brokers and communication rely on the security properties of the intermediate AAA
Diameter agents (such as proxies). brokers and Diameter agents (such as proxies).
11. Acknowledgements 11. Acknowledgements
Jouni Korhonen would like to thank the TEKES GIGA program MERCoNe- Jouni Korhonen would like to thank the TEKES GIGA program MERCoNe-
project for providing funding to work on this document while he was project for providing funding to work on this document while he was
with TeliaSonera. with TeliaSonera. The authors also thank Pasi Eronen, Peter McCann,
Spencer Dawkins and Marco Liebsch for their detailed reviews on this
document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dime-mip6-split] [I-D.ietf-dime-mip6-split]
Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
Agent to Diameter Server Interaction", Agent to Diameter Server Interaction",
draft-ietf-dime-mip6-split-17 (work in progress), draft-ietf-dime-mip6-split-17 (work in progress),
April 2009. April 2009.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-15
(work in progress), August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
skipping to change at page 18, line 43 skipping to change at page 19, line 32
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction", Network Access Server to Diameter Server Interaction",
RFC 5447, February 2009. RFC 5447, February 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mext-binding-revocation] [I-D.ietf-mext-binding-revocation]
Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility", and P. Yegani, "Binding Revocation for IPv6 Mobility",
draft-ietf-mext-binding-revocation-10 (work in progress), draft-ietf-mext-binding-revocation-12 (work in progress),
August 2009. September 2009.
[I-D.ietf-netlmm-lma-discovery]
Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy
Mobile IPv6", draft-ietf-netlmm-lma-discovery-02 (work in
progress), September 2009.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
(work in progress), September 2009.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
 End of changes. 24 change blocks. 
85 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/