draft-ietf-dime-mip6-integrated-10.txt   draft-ietf-dime-mip6-integrated-11.txt 
Diameter Maintenance and J. Korhonen Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera Extensions (DIME) TeliaSonera
Internet-Draft J. Bournelle Internet-Draft J. Bournelle
Intended status: Standards Track Orange Labs Intended status: Standards Track Orange Labs
Expires: March 9, 2009 H. Tschofenig Expires: May 22, 2009 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
C. Perkins C. Perkins
WiChorus WiChorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
September 5, 2008 November 18, 2008
Diameter Mobile IPv6: Support for Network Access Server to Diameter Diameter Mobile IPv6: Support for Network Access Server to Diameter
Server Interaction Server Interaction
draft-ietf-dime-mip6-integrated-10.txt draft-ietf-dime-mip6-integrated-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 March 9, 2009. This Internet-Draft will expire on May 22, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
A Mobile IPv6 node requires a home agent address, a home address, and A Mobile IPv6 node requires a home agent address, a home address, and
a security association with its home agent before it can start a security association with its home agent before it can start
utilizing Mobile IPv6. RFC 3775 requires that some or all of these utilizing Mobile IPv6. RFC 3775 requires that some or all of these
parameters are statically configured. Mobile IPv6 bootstrapping work parameters are statically configured. Mobile IPv6 bootstrapping work
aims to make this information dynamically available to the Mobile aims to make this information dynamically available to the Mobile
Node. An important aspect of the Mobile IPv6 bootstrapping solution Node. An important aspect of the Mobile IPv6 bootstrapping solution
is to support interworking with existing authentication, is to support interworking with existing authentication,
skipping to change at page 2, line 25 skipping to change at page 2, line 18
MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to
home Authentication, Authorization and Accounting server (HAAA) home Authentication, Authorization and Accounting server (HAAA)
interface. interface.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Commands, Attribute Value Pairs and Advertising 4. Commands, Attribute Value Pairs and Advertising
Application Support . . . . . . . . . . . . . . . . . . . . . 6 Application Support . . . . . . . . . . . . . . . . . . . . . 7
4.1. Advertising Application Support . . . . . . . . . . . . . 6 4.1. Advertising Application Support . . . . . . . . . . . . . 7
4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 6 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7
4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 6 4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7
4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 7 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8
4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 7 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8
4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 7 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 8
4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 8 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 9 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 10
5.2. Home Agent Assignment by the Diameter Server . . . . . . . 10 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 11
5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 11 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 12
6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 12 6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 13 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14
7.2. New Registry: Mobility Capability . . . . . . . . . . . . 13 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) The Mobile IPv6 (MIPv6) specification [RFC3775] requires a Mobile
to perform registration with a home agent (HA) with information about Node (MN) to perform registration with a home agent (HA) with
its current point of attachment (care-of address). The HA creates information about its current point of attachment (care-of address).
and maintains the binding between the MN's Home Address and the MN's The HA creates and maintains the binding between the MN's Home
Care-of Address. Address and the MN's Care-of Address.
In order to register with a HA, the MN needs to know some information 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), such as the Home Link prefix, the HA address, the Home Address(es),
the Home Link prefix length and security association related the Home Link prefix length and security association related
information. information.
The aforementioned information may be statically configured. The aforementioned information may be statically configured.
However, static provisioning becomes an administrative burden for an However, static provisioning becomes an administrative burden for an
operator. Moreover, it does not address load balancing, failover, operator. Moreover, it does not address load balancing, failover,
opportunistic home link assignment or assignment of local HAs in opportunistic home link assignment or assignment of local HAs in
skipping to change at page 3, line 35 skipping to change at page 3, line 35
Dynamic assignment of MIPv6 home registration information is a Dynamic assignment of MIPv6 home registration information is a
desirable feature for ease of deployment and network maintenance. desirable feature for ease of deployment and network maintenance.
For this purpose, the AAA infrastructure, which is used for access For this purpose, the AAA infrastructure, which is used for access
authentication, can be leveraged to assign some or all of the authentication, can be leveraged to assign some or all of the
necessary parameters. The Diameter server in the Access Service necessary parameters. The Diameter server in the Access Service
Provider's (ASP) or in the Mobility Service Provider's (MSP) network Provider's (ASP) or in the Mobility Service Provider's (MSP) network
may return these parameters to the AAA client. Regarding the may return these parameters to the AAA client. Regarding the
bootstrapping procedures, the AAA client might either be the NAS, in bootstrapping procedures, the AAA client might either be the NAS, in
case of the integrated scenario, or the HA, in case of the split case of the integrated scenario, or the HA, in case of the split
scenario [7]. The terms integrated and split are described in the scenario [RFC5026]. The terms integrated and split are described in
terminology section and were introduced in [8] and [9]. the terminology section and were introduced in [RFC4640] and
[I-D.ietf-mext-aaa-ha-goals].
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. document are to be interpreted as described in RFC2119 [RFC2119].
General mobility terminology can be found in [10]. The following General mobility terminology can be found in [RFC3753]. The
additional terms below are either borrowed from [8][7] or introduced following additional terms below are either borrowed from
in this document: [RFC4640][RFC5026] or introduced in this document:
Access Service Authorizer (ASA): Access Service Authorizer (ASA):
A network operator that authenticates a MN and establishes the A network operator that authenticates a MN and establishes the
MN's authorization to receive Internet service. MN's authorization to receive Internet service.
Access Service Provider (ASP): Access Service Provider (ASP):
A network operator that provides direct IP packet forwarding to A network operator that provides direct IP packet forwarding to
and from the MN. and from the MN.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
the local (ASP) network. the local (ASP) network.
Visited AAA (VAAA): Visited AAA (VAAA):
An authentication, authorization and accounting proxy located in a An authentication, authorization and accounting proxy located in a
visited network i.e., in the visited realm. In a roaming case, visited network i.e., in the visited realm. In a roaming case,
the local Diameter proxy has the VAAA role (see Figure 1). the local Diameter proxy has the VAAA role (see Figure 1).
3. Overview 3. Overview
This document addresses the authentication, authorization and This document addresses the Authentication, Authorization and
accounting functionality required for the MIPv6 bootstrapping Accounting (AAA) functionality required for the MIPv6 bootstrapping
solutions outlined in [8] and focuses on the Diameter based AAA solutions outlined in [RFC4640] and focuses on the Diameter based AAA
functionality for the NAS to HAAA communication. functionality for the NAS to HAAA communication.
In the integrated scenario MIPv6 bootstrapping is provided as part of In the integrated scenario MIPv6 bootstrapping is provided as part of
the network access authentication procedure. Figure 1 shows the the network access authentication procedure. Figure 1 shows the
participating entities. participating entities.
+---------------------------+ +-----------------+ +---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(MSP) | |Access Service Provider | |ASA/MSA/(MSP) |
|(Mobility Service Provider)| | | |(Mobility Service Provider)| | |
| | | | | | | |
skipping to change at page 5, line 43 skipping to change at page 6, line 26
| | | | | | | | | | | | | |
| Diameter | | v | | Diameter | | v |
| | |(+) +-------+ | | +-------+ | | | |(+) +-------+ | | +-------+ |
| | | |Home | | | |Home | | | | | |Home | | | |Home | |
| | +-------->|Agent | | | |Agent | | | | +-------->|Agent | | | |Agent | |
| (*)| |in ASP | | | |in MSP | | | (*)| |in ASP | | | |in MSP | |
| v +-------+ | | +-------+ | | v +-------+ | | +-------+ |
+-------+ IEEE | +-----------+ +-------+ | +-----------------+ +-------+ IEEE | +-----------+ +-------+ | +-----------------+
|Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | |
|Node |------------|Diameter |---|Server | | |Node |------------|Diameter |---|Server | |
| | PANA,... | |Client |(+)| | | | | PANA, | |Client |(+)| | |
+-------+ DHCP | +-----------+ +-------+ | +-------+ IKEv2, | +-----------+ +-------+ |
(+) +---------------------------+ DHCP,... +---------------------------+
(+)
Legend: Legend:
(*): Functionality in scope of this specification (*): Functionality in scope of this specification
(+): Extensions described in other documents. (+): Extensions described in other documents.
Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario
In a typical MIPv6 access scenario, a MN is attached to an ASP's In a typical MIPv6 access scenario, a MN is attached to an ASP's
network. During the network attachment procedure, the MN interacts network. During the network attachment procedure, the MN interacts
with the NAS/Diameter client. Subsequently, the NAS/Diameter client with the NAS/Diameter client. Subsequently, the NAS/Diameter client
skipping to change at page 6, line 21 skipping to change at page 6, line 51
When the Diameter server performs the authentication and When the Diameter server performs the authentication and
authorization for the network access it also determines whether the authorization for the network access it also determines whether the
user is authorized to the MIPv6 service. Based on the MIPv6 service user is authorized to the MIPv6 service. Based on the MIPv6 service
authorization and user's policy profile, the Diameter server may authorization and user's policy profile, the Diameter server may
return several MIPv6 bootstrapping related parameters to the NAS. return several MIPv6 bootstrapping related parameters to the NAS.
The NAS to HAAA interface described in this document is not tied to The NAS to HAAA interface described in this document is not tied to
DHCPv6 as the only mechanism to convey MIPv6 related configuration DHCPv6 as the only mechanism to convey MIPv6 related configuration
parameters from the NAS/Diameter client to the mobile node. parameters from the NAS/Diameter client to the mobile node.
While this specification addresses the bootstrapping of MIPv6 HA
information and possibly the assignment of the home link prefix, it
does not address how the Security Association (SA) between the MN and
the HA for MIPv6 purposes is created. The creation or the use of the
SA between the MN and the HA takes places after the procedures
described in this specification, and therefore are out of scope.
4. Commands, Attribute Value Pairs and Advertising Application Support 4. Commands, Attribute Value Pairs and Advertising Application Support
4.1. Advertising Application Support 4.1. Advertising Application Support
This document does not define a new application. On the other hand This document does not define a new application. On the other hand
it defines a number of AVPs used in the interface between NAS to HAAA it defines a number of AVPs used in the interface between NAS to HAAA
for the integrated scenario of MIPv6 bootstrapping. These AVPs can for the integrated scenario of MIPv6 bootstrapping. These AVPs can
be used with any present and future Diameter applications, where be used with any present and future Diameter applications, where
permitted by the command ABNF. The examples using existing permitted by the command ABNF. The examples using existing
applications and their commands in the following sections are for applications and their commands in the following sections are for
informational purposes only. The examples in this document reuse the informational purposes only. The examples in this document reuse the
EAP [3] application and its respective commands. EAP [RFC4072] application and its respective commands.
4.2. Attribute Value Pair Definitions 4.2. Attribute Value Pair Definitions
4.2.1. MIP6-Agent-Info 4.2.1. MIP6-Agent-Info
The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and
contains necessary information to assign a HA to the MN. When the contains necessary information to assign a HA to the MN. When the
MIP6-Agent-Info AVP is present in a message, it MUST contain either MIP6-Agent-Info AVP is present in a message, it MUST contain either
the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or
both AVPs. The grouped AVP has the following grammar: both AVPs. The grouped AVP has the following ABNF (as defined in
[RFC3588]):
<MIP6-Agent-Info> ::= < AVP Header: TBD > <MIP6-Agent-Info> ::= < AVP Header: TBD >
*2[ MIP-Home-Agent-Address ] *2[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ] [ MIP-Home-Agent-Host ]
* [ AVP ] * [ AVP ]
If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are
present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD
have a precedence over the MIP-Home-Agent-Host. The reason for this have a precedence over the MIP-Home-Agent-Host. The reason for this
recommendation is that the MIP-Home-Agent-Address points to a recommendation is that the MIP-Home-Agent-Address points to a
specific home agent, where as the MIP-Home-Agent-Host may point to a specific home agent, where as the MIP-Home-Agent-Host may point to a
group of HAs located at within the same realm. A Diameter client or group of HAs located at within the same realm. A Diameter client or
an agent may use the MIP-Home-Agent-Host AVP, for instance, to find an agent may use the MIP-Home-Agent-Host AVP, for instance, to find
out the realm where the HA is located. out the realm where the HA is located.
The ABNF allows returning up to two MIPv6 HA addresses. This is an
useful feature for deployments where the HA has both IPv6 and IPv4
addresses, and particularly addresses Dual Stack Mobile IPv6
(DSMIPv6) deployment scenarios [I-D.ietf-mext-nemo-v4traversal].
This AVP MAY also be attached by the NAS or by intermediating This AVP MAY also be attached by the NAS or by intermediating
Diameter proxies in a request message when sent to the Diameter Diameter proxies in a request message when sent to the Diameter
server as a hint of a locally assigned HA. This AVP MAY also be server as a hint of a locally assigned HA. This AVP MAY also be
attached by the intermediating Diameter proxies in a reply message attached by the intermediating Diameter proxies in a reply message
from the Diameter server, if locally assigned HAs are authorized by from the Diameter server, if locally assigned HAs are authorized by
the Diameter server. the Diameter server. There MAY be multiple instances of the MIP6-
Agent-Info AVPs in Diameter messages, for example in cases where the
NAS receives a HA information from MN's home network and a locally
allocated HA information from the visited network. See Section 4.2.5
for further discussion on possible scenarios.
4.2.2. MIP-Home-Agent-Address AVP 4.2.2. MIP-Home-Agent-Address AVP
The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address The MIP-Home-Agent-Address AVP (AVP Code 334 [RFC4004]) is of type
and contains IPv6 or IPv6 address of the HA. The Diameter server MAY Address and contains IPv6 or IPv4 address of the MIPv6 HA. The
decide to assign a HA to the MN that is in close proximity to the Diameter server MAY decide to assign a HA to the MN that is in close
point of attachment (e.g., determined by the NAS-Identifier AVP). proximity to the point of attachment (e.g., determined by the NAS-
There may be other reasons for dynamically assigning HAs to the MN, Identifier AVP). There may be other reasons for dynamically
for example to share the traffic load. assigning HAs to the MN, for example to share the traffic load.
4.2.3. MIP-Home-Agent-Host AVP 4.2.3. MIP-Home-Agent-Host AVP
The MIP-Home-Agent-Host AVP (AVP Code 348 [4]) is of type Grouped and The MIP-Home-Agent-Host AVP (AVP Code 348 [RFC4004]) is of type
contains the identity of the assigned HA. Both the Destination-Realm Grouped and contains the identity of the assigned MIPv6 HA. Both the
and the Destination-Host AVPs of the HA are included in the grouped Destination-Realm and the Destination-Host AVPs of the HA are
AVP. The usage of the MIP-Home-Agent-Host AVP is equivalent to the included in the grouped AVP. The usage of the MIP-Home-Agent-Host
MIP-Home-Agent-Address AVP but offers an additional level of AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an
indirection by using the DNS infrastructure. additional level of indirection by using the DNS infrastructure. The
Destination-Host AVP is used to identify a HA and the Destination-
Realm AVP is used to identify the realm where the HA is located.
Depending on the actual deployment and DNS configuration the Depending on the actual deployment and DNS configuration the
Destination-Host AVP MAY represent one or more home agents. It is Destination-Host AVP MAY represent one or more home agents. It is
RECOMMENDED that the Destination-Host AVP identifies exactly one HA. RECOMMENDED that the Destination-Host AVP identifies exactly one HA.
It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included
in the MIP6-Agent-Info AVP. In this way the HA address can be in the MIP6-Agent-Info AVP. In this way the HA IP address can be
associated with the corresponding realm the HA belongs to. associated with the corresponding realm the HA belongs to using the
Destination-Realm AVP included in the MIP-Home-Agent-Host AVP.
4.2.4. MIP6-Home-Link-Prefix AVP 4.2.4. MIP6-Home-Link-Prefix AVP
The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString
and contains the Mobile IPv6 home network prefix information in and contains the Mobile IPv6 home network prefix information in a
network byte order. The home network prefix MUST be encoded as the network byte order. The home network prefix MUST be encoded as the
8-bit prefix length information followed by the 128-bit field for the 8-bit prefix length information (one octet) followed by the 128-bit
available home network prefix. field (16 octets) for the available home network prefix. The
trailing bits of the IPv6 prefix after the prefix length bits MUST be
set to zero (e.g., if the prefix length is 60, then the remaining 68
bits MUST be set to zero).
The HAAA MAY act as a central entity managing prefixes for MNs. In
this case, the HAAA returns the prefix allocated for the MN and
returns it the NAS. The NAS/ASP uses then, for example, mechanisms
described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver
the home link prefix to the MN.
4.2.5. MIP6-Feature-Vector AVP 4.2.5. MIP6-Feature-Vector AVP
The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and
contains a 64 bit flags field of supported capabilities of the NAS/ contains a 64 bit flags field of supported capabilities of the NAS/
ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0
MUST be supported, although that does not provide much guidance about MUST be supported, although that does not provide much guidance about
specific needs of bootstrapping. specific needs of bootstrapping.
The NAS MAY include this AVP to indicate capabilities of the NAS/ASP The NAS MAY include this AVP to indicate capabilities of the NAS/ASP
skipping to change at page 9, line 11 skipping to change at page 10, line 20
0 L-HA Same as above. HA-Info must be ignored 0 L-HA Same as above. HA-Info must be ignored
1 - ASP or [LV]AAA can/wishes to assign a L-HA 1 - ASP or [LV]AAA can/wishes to assign a L-HA
1 L-HA Same as above but ASP or [LV]AAA also 1 L-HA Same as above but ASP or [LV]AAA also
provides a hint of the assigned L-HA provides a hint of the assigned L-HA
Then the same as above for an answer message combinations as seen by Then the same as above for an answer message combinations as seen by
the NAS: the NAS:
LOCAL-bit HA-Info Meaning LOCAL-bit HA-Info Meaning
0 - No HA allowed -> no mobility 0 - No HA assignment allowed for HAAA or [LV]AAA
0 H-HA L-HA is not allowed. HAAA assigns a H-HA 0 H-HA L-HA is not allowed. HAAA assigns a H-HA
1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA
1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA
1 H-HA L-HA is allowed. HAAA also assigns a HA 1 H-HA L-HA is allowed. HAAA also assigns a HA
1 H-HA L-HA is allowed. HAAA assigns a H-HA and 1 H-HA L-HA is allowed. HAAA assigns a H-HA and
+ L-HA [LV]AAA also assigns also a L-HA + L-HA [LV]AAA also assigns also a L-HA
A NAS should expect to possible receive multiple of the MIP6-Agent- A NAS should expect to possible receive multiple of the MIP6-Agent-
Info AVPs. Info AVPs.
skipping to change at page 11, line 20 skipping to change at page 12, line 20
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE | | Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | | EAP-Payload(EAP Start) |
|---------------------------------------------------------------->| |---------------------------------------------------------------->|
| | | |
| | | |
: ...more EAP Request/Response pairs... : : ...more EAP Request/Response pairs... :
| | | |
| | | |
| Diameter-EAP-Answer | | Diameter-EAP-Answer |
| MIP6-Agent-Info{ | | MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1/64) | | MIP-Home-Agent-Address(2001:db8:6000:302::1) |
| } | | } |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) | | MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS | | Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) | | EAP-Payload(EAP Success) |
| EAP-Master-Session-Key | | EAP-Master-Session-Key |
| (authorization AVPs) | | (authorization AVPs) |
| ... | | ... |
|<----------------------------------------------------------------| |<----------------------------------------------------------------|
| | | |
skipping to change at page 12, line 24 skipping to change at page 13, line 24
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE | | Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | | EAP-Payload(EAP Start) |
|---------------------------------------------------------------->| |---------------------------------------------------------------->|
| | | |
| | | |
: ...more EAP Request/Response pairs... : : ...more EAP Request/Response pairs... :
| | | |
| | | |
| Diameter-EAP-Answer | | Diameter-EAP-Answer |
| MIP6-Agent-Info{ | | MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} | | MIP-Home-Agent-Address(2001:db8:6000:302::1)} |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) | | | MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS | | Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) | | EAP-Payload(EAP Success) |
| EAP-Master-Session-Key | | EAP-Master-Session-Key |
| (authorization AVPs) | | (authorization AVPs) |
| ... | | ... |
|<----------------------------------------------------------------| |<----------------------------------------------------------------|
| | | |
skipping to change at page 13, line 21 skipping to change at page 14, line 21
MIP6-Feature-Vector | 0-1 | 0-1 | MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Home-Link-Prefix | 0+ | 0+ | MIP6-Home-Link-Prefix | 0+ | 0+ |
+-----+-----+ +-----+-----+
Figure 5: Generic Request and Answer Commands AVP Table Figure 5: Generic Request and Answer Commands AVP Table
7. IANA Considerations 7. IANA Considerations
7.1. Registration of new AVPs 7.1. Registration of new AVPs
This specification defines the following new AVPs: This specification defines the following new AVPs to be allocated
from a normal Diameter AVP Code space (values >= 256):
MIP6-Agent-Info is set to TBD MIP6-Agent-Info is set to TBD
The following new AVPs are to be allocated from RADIUS Type Code
[RFC2685] space so that they are RADIUS backward compatible (AVP Code
values between 0-255):
MIP6-Feature-Vector is set to TBD MIP6-Feature-Vector is set to TBD
MIP6-Home-Link-Prefix is set to TBD MIP6-Home-Link-Prefix is set to TBD
7.2. New Registry: Mobility Capability 7.2. New Registry: Mobility Capability
IANA is requested to create a new registry for the Mobility IANA is requested to create a new registry for the Mobility
Capability as described in Section 4.2.5. Capability as described in Section 4.2.5.
Token | Value | Description Token | Value | Description
----------------------------------+----------------------+------------ ----------------------------------+----------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD]
Available for Assignment via IANA | 2^x | Available for Assignment via IANA | 2^x |
Allocation rule: Only numeric values that are 2^x (power of two, Allocation rule: Only numeric values that are 2^x (power of two,
where x >= 2) are allowed based on the allocation policy described where x >= 2) are allowed based on the allocation policy described
below. below.
Following the example policies described in [11] new values for the Following the example policies described in [RFC5226] new values for
MIP6-Feature-Vector AVP will be assigned based on the "Specification the MIP6-Feature-Vector AVP will be assigned based on the
Required" policy. No mechanism to mark entries as "deprecated" is "Specification Required" policy. No mechanism to mark entries as
envisioned. "deprecated" is envisioned.
8. Security Considerations 8. Security Considerations
The security considerations for the Diameter interaction required to The security considerations for the Diameter interaction required to
accomplish the integrated scenario are described in [12]. accomplish the integrated scenario are described in
[I-D.ietf-mip6-bootstrapping-integrated-dhc]. Additionally, the
Additionally, the security considerations of the Diameter base security considerations of the Diameter base protocol [RFC3588],
protocol [5], Diameter NASREQ application [6] / Diameter EAP [3] Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072]
application (with respect to network access authentication and the application (with respect to network access authentication and the
transport of keying material) are applicable to this document. transport of keying material) are applicable to this document.
Developers should insure that special attention is paid to Developers should insure that special attention is paid to
configuring the security associations protecting the messages that configuring the security associations protecting the messages that
enables the global positioning and allocation of home agents, for enables the global positioning and allocation of home agents, for
instance, as outlined in section 5. instance, as outlined in section 5.
Furthermore, the Diameter messages may be transported between the NAS
and the RADIUS server via one or more AAA brokers or Diameter agents
(such as proxies). In this case the NAS to the Diameter server AAA
communication rely on the security properties of the intermediate AAA
brokers and Diameter agents.
9. Acknowledgements 9. Acknowledgements
This document is heavily based on the ongoing work for RADIUS MIPv6 This document is heavily based on the ongoing work for RADIUS MIPv6
interaction. Hence, credits go to respective authors for their work interaction. Hence, credits go to respective authors for their work
with draft-ietf-mip6-radius. Furthermore, the author would like to with draft-ietf-mip6-radius. Furthermore, the author would like to
thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le,
Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work
in context of MIPv6 Diameter interworking. Their work influenced in context of MIPv6 Diameter interworking. Their work influenced
this document. Jouni Korhonen would like to thank Academy of Finland this document. Jouni Korhonen would like to thank Academy of Finland
and TEKES MERCoNe Project for providing funding to work on this and TEKES MERCoNe Project for providing funding to work on this
skipping to change at page 14, line 37 skipping to change at page 15, line 48
on local HA assignment and Wolfgang Fritsche for his thorough review. on local HA assignment and Wolfgang Fritsche for his thorough review.
Finally, we would like to Domagoj Premec for his review comments. Finally, we would like to Domagoj Premec for his review comments.
We would like to thank Alper Yegin, Robert Marks, David Frascone for We would like to thank Alper Yegin, Robert Marks, David Frascone for
their comments at the second WGLC. their comments at the second WGLC.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
IPv6", RFC 3775, June 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Levels", BCP 14, RFC 2119, March 1997. Identifier", RFC 2685, September 1999.
[3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Authentication Protocol (EAP) Application", RFC 4072, Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
August 2005.
[4] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
McCann, "Diameter Mobile IPv4 Application", RFC 4004, in IPv6", RFC 3775, June 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005. August 2005.
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Network Access Server Application", RFC 4005,
August 2005.
[6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Network Access Server Application", RFC 4005, August 2005. Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
10.2. Informative References 10.2. Informative References
[7] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [I-D.ietf-mext-aaa-ha-goals]
Bootstrapping in Split Scenario", RFC 5026, October 2007. Giaretta, G., Guardini, I., Demaria, E., Bournelle, J.,
and R. Lopez, "AAA Goals for Mobile IPv6",
draft-ietf-mext-aaa-ha-goals-01 (work in progress),
May 2008.
[8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping [I-D.ietf-mext-nemo-v4traversal]
Mobile IPv6 (MIPv6)", RFC 4640, September 2006. Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-06 (work in
progress), November 2008.
[9] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. [I-D.ietf-mip6-bootstrapping-integrated-dhc]
Lopez, "AAA Goals for Mobile IPv6", Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
draft-ietf-mext-aaa-ha-goals-01 (work in progress), May 2008. Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006.
[12] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Integrated Scenario", Bootstrapping in Split Scenario", RFC 5026, October 2007.
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Jouni Korhonen Jouni Korhonen (editor)
TeliaSonera TeliaSonera
Teollisuuskatu 13 Teollisuuskatu 13
Sonera FIN-00051 Sonera FIN-00051
Finland Finland
Email: jouni.korhonen@teliasonera.com Email: jouni.nospam@gmail.com
Julien Bournelle Julien Bournelle
Orange Labs Orange Labs
38-4O rue du general Leclerc 38-4O rue du general Leclerc
Issy-Les-Moulineaux 92794 Issy-Les-Moulineaux 92794
France France
Email: julien.bournelle@orange-ftgroup.com Email: julien.bournelle@orange-ftgroup.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
skipping to change at page 17, line 44 skipping to change at line 785
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 45 change blocks. 
110 lines changed or deleted 164 lines changed or added

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