draft-ietf-dime-mip6-integrated-12.txt   rfc5447.txt 
Diameter Maintenance and J. Korhonen, Ed. Network Working Group J. Korhonen, Ed.
Extensions (DIME) Nokia Siemens Networks Request for Comments: 5447 Nokia Siemens Networks
Internet-Draft J. Bournelle Category: Standards Track J. Bournelle
Intended status: Standards Track Orange Labs Orange Labs
Expires: July 13, 2009 H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
C. Perkins C. Perkins
WiChorus WiChorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
January 9, 2009 February 2009
Diameter Mobile IPv6: Support for Network Access Server to Diameter
Server Interaction
draft-ietf-dime-mip6-integrated-12.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 Diameter Mobile IPv6:
http://www.ietf.org/ietf/1id-abstracts.txt. Support for Network Access Server to Diameter Server Interaction
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 13, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 be 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,
authorization and accounting infrastructure. This document describes Authorization, and Accounting (AAA) infrastructures. This document
MIPv6 bootstrapping using the Diameter Network Access Server to home describes MIPv6 bootstrapping using the Diameter Network Access
Authentication, Authorization and Accounting server interface. Server to home AAA server interface.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Commands, Attribute Value Pairs and Advertising 4. Commands, Attribute-Value Pairs, and Advertising
Application Support . . . . . . . . . . . . . . . . . . . . . 7 Application Support . . . . . . . . . . . . . . . . . . . . . 6
4.1. Advertising Application Support . . . . . . . . . . . . . 7 4.1. Advertising Application Support . . . . . . . . . . . . . 6
4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7 4.2. Attribute-Value Pair Definitions . . . . . . . . . . . . . 6
4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7 4.2.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . 6
4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 7
4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 7
4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 9 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 8
4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 11 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 10
5.2. Home Agent Assignment by the Diameter Server . . . . . . . 12 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 11
5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 13 5.3. Home Agent Assignment by the NAS or Diameter Server . . . 11
6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 14 6. Attribute-Value Pair Occurrence Tables . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14 7.1. Registration of New AVPs . . . . . . . . . . . . . . . . . 13
7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Mobile IPv6 (MIPv6) specification [RFC3775] requires a Mobile The Mobile IPv6 (MIPv6) specification [RFC3775] requires a mobile
Node (MN) to perform registration with a home agent (HA) with node (MN) to perform registration with a home agent (HA) with
information about its current point of attachment (care-of address). information about its current point of attachment (care-of address).
The HA creates and maintains the binding between the MN's Home The HA creates and maintains the binding between the MN's home
Address and the MN's 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 an HA, the MN needs to know some
such as the Home Link prefix, the HA address, the Home Address(es), information, such as the home link prefix, the HA address, the home
the Home Link prefix length and security association related address(es), the home link prefix length, and security-association-
information. related 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
close proximity to the MN. Also the ability to react to sudden close proximity to the MN. Also, the ability to react to sudden
environmental or topological changes is minimal. Static provisioning environmental or topological changes is minimal. Static provisioning
may not be desirable, in light of these limitations. may not be desirable, in light of these limitations.
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's) or Mobility Service Provider's (MSP's) network may
may return these parameters to the AAA client. Regarding the return these parameters to the AAA client. Regarding the
bootstrapping procedures, the AAA client might either be the Network bootstrapping procedures, the AAA client might either be the Network
Access Server, in case of the integrated scenario, or the HA, in case Access Server, in case of the integrated scenario, or the HA, in case
of the split scenario [RFC5026]. The terms integrated and split are of the split scenario [RFC5026]. The terms "integrated" and "split"
described in the terminology section and were introduced in [RFC4640] are described in the following terminology section and were
and [I-D.ietf-mext-aaa-ha-goals]. introduced in [RFC4640] and [AAA].
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 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
General mobility terminology can be found in [RFC3753]. The General mobility terminology can be found in [RFC3753]. The
following additional terms below are either borrowed from following additional terms are either borrowed from [RFC4640] or
[RFC4640][RFC5026] or introduced in this document: [RFC5026] or are 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 an 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.
Mobility Service Authorizer (MSA): Mobility Service Authorizer (MSA):
A service provider that authorizes MIPv6 service. A service provider that authorizes MIPv6 service.
Mobility Service Provider (MSP): Mobility Service Provider (MSP):
A service provider that provides MIPv6 service. In order to A service provider that provides MIPv6 service. In order to
obtain such service, the MN must be authenticated and authorized obtain such service, the MN must be authenticated and authorized
to obtain the MIPv6 service. to do so.
Split scenario: Split Scenario:
A scenario where the mobility service and the network access A scenario where the mobility service and the network access
service are authorized by different entities. service are authorized by different entities.
Integrated Scenario: Integrated Scenario:
A scenario where the mobility service and the network access A scenario where the mobility service and the network access
service are authorized by the same entity. service are authorized by the same entity.
Network Access Server (NAS): Network Access Server (NAS):
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
Home AAA (HAAA): Home AAA (HAAA):
An authentication, authorization and accounting server located in An Authentication, Authorization, and Accounting server located in
user's home network i.e., in the home realm. the user's home network, i.e., in the home realm.
Local AAA (LAAA): Local AAA (LAAA):
An authentication, authorization and accounting proxy located in An Authentication, Authorization, and Accounting proxy located in
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
visited network i.e., in the visited realm. In a roaming case, a 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 (AAA) functionality required for the MIPv6 bootstrapping Accounting (AAA) functionality required for the MIPv6 bootstrapping
solutions outlined in [RFC4640] and focuses on the Diameter based AAA solutions outlined in [RFC4640], and focuses on the Diameter-based
functionality for the NAS to home AAA server (HAAA) communication. AAA functionality for the NAS-to-HAAA (home AAA) server
communication.
In the integrated scenario MIPv6 bootstrapping is provided as part of In the integrated scenario, MIPv6 bootstrapping is provided as part
the network access authentication procedure. Figure 1 shows the of 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)| | |
| | | | | | | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| |Local | Diameter | | |Home | | | |Local | Diameter | | |Home | |
| |Diameter|<---------------------->|Diameter| | | |Diameter|<---------------------->|Diameter| |
| |Proxy | (*) | | |Server | | | |Proxy | (*) | | |Server | |
skipping to change at page 6, line 49 skipping to change at page 5, line 44
| 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 |(+)| | |
+-------+ IKEv2, | +-----------+ +-------+ | +-------+ IKEv2, | +-----------+ +-------+ |
DHCP,... +---------------------------+ 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, an 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
interacts with the Diameter server over the NAS to HAAA interface. interacts with the Diameter server over the NAS-to-HAAA interface.
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 network access, it also determines whether the user
user is authorized to the MIPv6 service. Based on the MIPv6 service is authorized for the MIPv6 service. Based on the MIPv6 service
authorization and user's policy profile, the Diameter server may authorization and the 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 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) as the only
parameters from the NAS/Diameter client to the mobile node. mechanism to convey MIPv6-related configuration parameters from the
NAS/Diameter client to the mobile node.
While this specification addresses the bootstrapping of MIPv6 HA While this specification addresses the bootstrapping of MIPv6 HA
information and possibly the assignment of the home link prefix, it information and possibly the assignment of the home link prefix, it
does not address how the Security Association (SA) between the MN and 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 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 SA between the MN and the HA takes places after the procedures
described in this specification, and therefore are out of scope. 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 attribute-value pairs (AVPs) used in the
for the integrated scenario of MIPv6 bootstrapping. These AVPs can interface between NAS to HAAA for the integrated scenario of MIPv6
be used with any present and future Diameter applications, where bootstrapping. These AVPs can be used with any present and future
permitted by the command ABNF. The examples using existing Diameter applications, where permitted by the command ABNF. The
applications and their commands in the following sections are for examples using existing applications and their commands in the
informational purposes only. The examples in this document reuse the following sections are for informational purposes only. The examples
EAP [RFC4072] application and its respective commands. in this document reuse the Extensible Authentication Protocol (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 AVP
The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and The MIP6-Agent-Info AVP (AVP code 486) is of type Grouped and
contains necessary information to assign a HA to the MN. When the contains necessary information to assign an 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, the MIP-Home-Agent-Host AVP, or both
both AVPs. The grouped AVP has the following ABNF (as defined in AVPs. The grouped AVP has the following modified ABNF (as defined in
[RFC3588]): [RFC3588]):
<MIP6-Agent-Info> ::= < AVP Header: TBD > 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 ]
* [ AVP ] * [ AVP ]
If both the 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 within the same realm. A Diameter client or
an agent may use the MIP-Home-Agent-Host AVP, for instance, to find agent may use the MIP-Home-Agent-Host AVP, for instance, to find out
out the realm where the HA is located. in which realm the HA is located.
The ABNF allows returning up to two MIPv6 HA addresses. This is an The ABNF allows returning up to two MIPv6 HA addresses. This is a
useful feature for deployments where the HA has both IPv6 and IPv4 useful feature for deployments where the HA has both IPv6 and IPv4
addresses, and particularly addresses Dual Stack Mobile IPv6 addresses, and particularly addresses Dual Stack Mobile IPv6
(DSMIPv6) deployment scenarios [I-D.ietf-mext-nemo-v4traversal]. (DSMIPv6) deployment scenarios [DSMIPv6].
This AVP MAY also be attached by the NAS or by intermediating The MIP6-Agent-Info AVP MAY also be attached by the NAS or by the
Diameter proxies in a request message when sent to the Diameter intermediating Diameter proxies in a request message when sent to the
server as a hint of a locally assigned HA. This AVP MAY also be Diameter server as a hint of a locally assigned HA. This AVP MAY
attached by the intermediating Diameter proxies in a reply message also be attached by the intermediating Diameter proxies in a reply
from the Diameter server, if locally assigned HAs are authorized by message from the Diameter server, if locally assigned HAs are
the Diameter server. There MAY be multiple instances of the MIP6- authorized by the Diameter server. There MAY be multiple instances
Agent-Info AVPs in Diameter messages, for example in cases where the of the MIP6-Agent-Info AVP in Diameter messages, for example, in
NAS receives a HA information from MN's home network and a locally cases where the NAS receives HA information from an MN's home network
allocated HA information from the visited network. See Section 4.2.5 and locally allocated HA information from the visited network. See
for further discussion on possible scenarios. 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 [RFC4004]) is of type The MIP-Home-Agent-Address AVP (AVP Code 334 [RFC4004]) is of type
Address and contains IPv6 or IPv4 address of the MIPv6 HA. The Address and contains the IPv6 or IPv4 address of the MIPv6 HA. The
Diameter server MAY decide to assign a HA to the MN that is in close Diameter server MAY decide to assign an HA to the MN that is in close
proximity to the point of attachment (e.g., determined by the NAS- proximity to the point of attachment (e.g., determined by the NAS-
Identifier AVP). There may be other reasons for dynamically Identifier AVP). There may be other reasons for dynamically
assigning HAs to the MN, 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 [RFC4004]) is of type The MIP-Home-Agent-Host AVP (AVP Code 348 [RFC4004]) is of type
Grouped and contains the identity of the assigned MIPv6 HA. Both the Grouped and contains the identity of the assigned MIPv6 HA. Both the
Destination-Realm and the Destination-Host AVPs of the HA are Destination-Realm and the Destination-Host AVPs of the HA are
included in the grouped AVP. The usage of the MIP-Home-Agent-Host included in the grouped AVP. The usage of the MIP-Home-Agent-Host
AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an
additional level of indirection by using the DNS infrastructure. The additional level of indirection by using the DNS infrastructure. The
Destination-Host AVP is used to identify a HA and the Destination- Destination-Host AVP is used to identify an HA, and the Destination-
Realm AVP is used to identify the realm where the HA is located. 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 can be associated in the MIP6-Agent-Info AVP. In this way, the HA can be associated
with the corresponding realm of the Diameter entity that added the with the corresponding realm of the Diameter entity that added the
MIP6-Agent-Info AVP using the Destination-Realm AVP included in the MIP6-Agent-Info AVP using the Destination-Realm AVP, which is
MIP-Home-Agent-Host 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 125) is of type OctetString
and contains the Mobile IPv6 home network prefix information in a 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 (one octet) followed by the 128-bit 8-bit prefix length information (one octet) followed by the 128-bit
field (16 octets) for the available home network prefix. The field (16 octets) for the available home network prefix. The
trailing bits of the IPv6 prefix after the prefix length bits MUST be 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 set to zero (e.g., if the prefix length is 60, then the remaining 68
bits MUST be set to zero). bits MUST be set to zero).
The HAAA MAY act as a central entity managing prefixes for MNs. In The HAAA MAY act as a central entity managing prefixes for MNs. In
this case, the HAAA returns to the NAS the prefix allocated to the this case, the HAAA returns to the NAS the prefix allocated to the
MN. The NAS/ASP delivers then the home link prefix to the MN using MN. The NAS/ASP then delivers the home link prefix to the MN using,
e.g. mechanisms described in e.g., mechanisms described in [INTEGRATED]. The NAS/ASP MAY propose
[I-D.ietf-mip6-bootstrapping-integrated-dhc]. The NAS/ASP MAY to the HAAA a specific prefix to allocate to the MN by including the
propose to the HAAA a specific prefix to allocate to the MN by MIP6-Home-Link-Prefix AVP in the request message. However, the HAAA
including the MIP6-Home-Link-Prefix AVP in the request message. MAY override the prefix allocation hint proposed by the NAS/ASP and
However, the HAAA MAY override the prefix allocation hint proposed by return a different prefix in the response message.
the NAS/ASP and return a different prefix in the response message.
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 124) 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
to the Diameter server. For example, the NAS may indicate that a to the Diameter server. For example, the NAS may indicate that a
local HA can be provided. Similarly, the Diameter server MAY include local HA can be provided. Similarly, the Diameter server MAY include
this AVP to inform the NAS/ASP about which of the NAS/ASP indicated this AVP to inform the NAS/ASP about which of the NAS/ASP indicated
capabilities are supported or authorized by the ASA/MSA(/MSP). capabilities are supported or authorized by the ASA/MSA(/MSP).
The following capabilities are defined in this document: The following capabilities are defined in this document:
MIP6_INTEGRATED (0x0000000000000001) MIP6_INTEGRATED (0x0000000000000001)
When this flag is set by the NAS then it means that the Mobile When this flag is set by the NAS, it means that the Mobile IPv6
IPv6 integrated scenario bootstrapping functionality is supported integrated scenario bootstrapping functionality is supported by
by the NAS. When this flag is set by the Diameter server then the the NAS. When this flag is set by the Diameter server, then the
Mobile IPv6 integrated scenario bootstrapping is supported by the Mobile IPv6 integrated scenario bootstrapping is supported by the
Diameter server. Diameter server.
LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002)
When this flag is set in the request message, a local home agent When this flag is set in the request message, a local home agent
outside the home realm is requested and may be assigned to the MN. outside the home realm is requested and may be assigned to the MN.
When this flag is set by the Diameter server in the answer When this flag is set by the Diameter server in the answer
message, then the assignment of local HAs is authorized by the message, then the assignment of local HAs is authorized by the
Diameter server. Diameter server.
A local HA may be assigned by the NAS, LAAA or VAAA depending on A local HA may be assigned by the NAS, LAAA, or VAAA depending on
the network architecture and the deployment. the network architecture and the deployment.
The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT
(referred as LOCAL-bit in the examples) capability and the MIP-Agent- (referred to as LOCAL-bit in the examples) capability and the MIP-
Info AVP (referred as HA-Info in the examples) are used to assign Agent-Info AVP (referred to as HA-Info in the examples) are used to
HAs, either a local HA (L-HA) or a home network HA (H-HA). Below is assign HAs -- either a local HA (L-HA) or a home network HA (H-HA).
an example of a request message combinations as seen by the HAAA: Below are examples of request message combinations as seen by the
HAAA:
LOCAL-bit HA-Info Meaning LOCAL-bit HA-Info Meaning
0 - ASP or [LV]AAA is not able to assign a L-HA 0 - ASP or [LV]AAA is not able to assign an L-HA.
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 an L-HA.
1 L-HA Same as above but ASP or [LV]AAA also 1 L-HA Same as above but the 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 The same as above but for answer message combinations as seen by the
the NAS: NAS:
LOCAL-bit HA-Info Meaning LOCAL-bit HA-Info Meaning
0 - No HA assignment allowed for HAAA or [LV]AAA 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 an 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 an L-HA.
1 H-HA L-HA is allowed. HAAA also assigns a HA 1 H-HA L-HA is allowed. HAAA also assigns an HA.
1 H-HA L-HA is allowed. HAAA assigns a H-HA and 1 H-HA L-HA is allowed. HAAA assigns an H-HA and
+ L-HA [LV]AAA also assigns also a L-HA + L-HA [LV]AAA also assigns an L-HA.
A NAS should expect to possible receive multiple of the MIP6-Agent-
Info AVPs. An NAS should expect to receive multiple MIP6-Agent-Info AVPs.
5. Examples 5. Examples
5.1. Home Agent Assignment by the NAS 5.1. Home Agent Assignment by the NAS
In this scenario we consider the case where the NAS wishes to In this scenario, we consider the case where the NAS wishes to
allocate a local HA to the MN. The NAS will also inform the Diameter allocate a local HA to the MN. The NAS will also inform the Diameter
server about the HA address it has assigned to the visiting MN (e.g., server about the HA address it has assigned to the visiting MN (e.g.,
2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 2001:db8:1:c020::1). The Diameter-EAP-Request message, therefore,
the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the has the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and
MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- the MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-
Agent-Address AVP with the address of the proposed HA. Home-Agent-Address AVP with the address of the proposed HA.
Diameter Diameter
NAS/VAAA Server NAS/VAAA Server
| | | |
| Diameter-EAP-Request | | Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) | | | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ | | MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} | | MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } | | } |
skipping to change at page 11, line 47 skipping to change at page 10, line 45
| 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) |
| ... | | ... |
|<----------------------------------------------------------------| |<----------------------------------------------------------------|
| | | |
Figure 2: Home Agent Assignment by NAS Figure 2: Home Agent Assignment by the NAS
Depending on the Diameter server configuration and user's Depending on the Diameter server's configuration and the user's
subscription profile, the Diameter server either accepts or rejects subscription profile, the Diameter server either accepts or rejects
the local HA allocated by the NAS. In our example, the Diameter the local HA allocated by the NAS. In our example, the Diameter
server accepts the proposal and the the MIP6-Feature-Vector AVP with server accepts the proposal, and the MIP6-Feature-Vector AVP with
LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED
flag) is set and returned to the NAS. flag) is set and returned to the NAS.
5.2. Home Agent Assignment by the Diameter Server 5.2. Home Agent Assignment by the Diameter Server
In this scenario we consider the case where the NAS supports the In this scenario, we consider the case where the NAS supports the
Diameter MIPv6 integrated scenario as defined in this document but Diameter MIPv6 integrated scenario as defined in this document, but
does not offer local HA assignment. Hence, the MIP6-Feature-Vector does not offer local HA assignment. Hence, the MIP6-Feature-Vector
AVP only has the MIP6_INTEGRATED flag set. The Diameter server AVP only has the MIP6_INTEGRATED flag set. The Diameter server
allocates a HA to the mobile node and conveys the address in the MIP- allocates an HA to the mobile node and conveys the address in the
Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info MIP-Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-
AVP. Additionally, the MIP6-Feature-Vector AVP has the Info AVP. Additionally, the MIP6-Feature-Vector AVP has the
MIP6_INTEGRATED flag set. MIP6_INTEGRATED flag set.
Diameter Diameter
NAS Server NAS Server
| | | |
| Diameter-EAP-Request | | Diameter-EAP-Request |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) | | MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE | | Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | | EAP-Payload(EAP Start) |
|---------------------------------------------------------------->| |---------------------------------------------------------------->|
skipping to change at page 12, line 47 skipping to change at page 11, line 42
| } | | } |
| 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) |
| ... | | ... |
|<----------------------------------------------------------------| |<----------------------------------------------------------------|
| | | |
Figure 3: Home Agent Assignment by Diameter Server Figure 3: Home Agent Assignment by the Diameter Server
5.3. Home Agent Assignment by NAS or Diameter Server 5.3. Home Agent Assignment by the NAS or Diameter Server
This section shows another message flow for the MIPv6 integrated This section shows another message flow for the MIPv6 integrated
scenario bootstrapping where the NAS informs the Diameter server that scenario bootstrapping where the NAS informs the Diameter server that
it is able to locally assign a HA to the MN. The Diameter server is it is able to locally assign an HA to the MN. The Diameter server is
able to provide a HA to the MN but also authorizes the assignment of able to provide an HA to the MN but also authorizes the assignment of
local HA. The Diameter server then replies to the NAS with HA the local HA. The Diameter server then replies to the NAS with
related bootstrapping information. HA-related bootstrapping information.
Whether the NAS/ASP then offers a locally assigned HA or the Diameter Whether the NAS/ASP then offers a locally assigned HA or the
server assigned HA to the MN is, in this example, based on the local Diameter-server-assigned HA to the MN is, in this example, based on
ASP policy. the local ASP policy.
Diameter Diameter
NAS/VAAA Server NAS/VAAA Server
| | | |
| Diameter-EAP-Request | | Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) | | | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ | | MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} | | MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } | | } |
skipping to change at page 13, line 48 skipping to change at page 12, line 39
| 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) |
| ... | | ... |
|<----------------------------------------------------------------| |<----------------------------------------------------------------|
| | | |
Figure 4: Home Agent Assignment by NAS or Diameter Server Figure 4: Home Agent Assignment by the NAS or Diameter Server
If the Diameter server does not allow the MN to use a locally If the Diameter server does not allow the MN to use a locally
assigned HA, the Diameter returns the MIP6-Feature-Vector AVP with assigned HA, the Diameter server returns to the MN the MIP6-Feature-
the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it allocated Vector AVP with the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and the HA
to the MN. address it allocated.
6. Attribute Value Pair Occurrence Tables 6. Attribute-Value Pair Occurrence Tables
Figure 5 lists the MIPv6 bootstrapping NAS to HAAA interface AVPs, Figure 5 lists the MIPv6 bootstrapping NAS-to-HAAA interface AVPs
along with a specification determining how many of each new AVP may along with a specification determining how many of each new AVP may
be included in a Diameter command. They may be present in any be included in a Diameter command. They may be present in any
Diameter application request and answer commands, where permitted by Diameter application request and answer commands, where permitted by
the command ABNF. the command ABNF.
+-----------+ +-----------+
| Command | | Command |
|-----+-----+ |-----+-----+
Attribute Name | Req | Ans | Attribute Name | Req | Ans |
-------------------------------|-----+-----| -------------------------------|-----+-----|
MIP6-Agent-Info | 0+ | 0+ | MIP6-Agent-Info | 0+ | 0+ |
MIP6-Feature-Vector | 0-1 | 0-1 | MIP6-Feature-Vector | 0-1 | 0-1 |
+-----+-----+ +-----+-----+
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 to be allocated This specification defines the following AVPs that have been
from a normal Diameter AVP Code space (values >= 256): allocated from a normal Diameter AVP Code space (values >= 256):
MIP6-Agent-Info is set to TBD MIP6-Agent-Info is set to 486
The following new AVPs are to be allocated from RADIUS Type Code The following new AVPs are to be allocated from RADIUS Attribute Type
[RFC2865] space so that they are RADIUS backward compatible (AVP Code space [RFC2865] so that they are RADIUS backward-compatible (AVP Code
values between 0-255): values between 0-255):
MIP6-Feature-Vector is set to TBD MIP6-Feature-Vector is set to 124
MIP6-Home-Link-Prefix is set to TBD MIP6-Home-Link-Prefix is set to 125
7.2. New Registry: Mobility Capability 7.2. New Registry: Mobility Capability
IANA is requested to create a new registry for the Mobility IANA has created a new registry for the Mobility Capability as
Capability as described in Section 4.2.5. described in Section 4.2.5.
Token | Value | Description Token | Value | Description
----------------------------------+---------------------+------------ ----------------------------------+---------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] MIP6_INTEGRATED | 0x0000000000000001 | [RFC5447]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC5447]
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 [RFC5226] new values for Following the example policies described in [RFC5226], new values for
the MIP6-Feature-Vector AVP will be assigned based on the the Mobility Capability Registry will be assigned based on the
"Specification Required" policy. No mechanism to mark entries as "Specification Required" policy. No mechanism to mark entries as
"deprecated" is 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 accomplish the integrated scenario are described in [INTEGRATED].
[I-D.ietf-mip6-bootstrapping-integrated-dhc]. Additionally, the Additionally, the security considerations for the Diameter base
security considerations of the Diameter base protocol [RFC3588], protocol [RFC3588], the Diameter NASREQ application [RFC4005], and
Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] the Diameter EAP application (with respect to network access
application (with respect to network access authentication and the authentication and the transport of keying material) [RFC4072] are
transport of keying material) are applicable to this document. applicable to this document. Developers should insure that special
Developers should insure that special attention is paid to attention is paid to configuring the security associations protecting
configuring the security associations protecting the messages that the messages that enable the global positioning and allocation of
enables the global positioning and allocation of home agents, for 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 Furthermore, the Diameter messages may be transported between the NAS
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 (such as proxies). In this case the NAS to the Diameter agents (such as proxies). In this case, the AAA communication from
server AAA communication rely on the security properties of the the NAS to the Diameter server relies on the security properties of
intermediate AAA brokers and Diameter agents. the intermediate AAA brokers and Diameter agents.
9. Acknowledgements 9. Acknowledgments
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 "RADIUS Mobile IPv6 Support" (November 2008). Furthermore, the
thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, authors of this document would like to thank the authors of "Diameter
Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work Mobile IPv6 Application" (November 2004) -- Franck Le, Basavaraj
in context of MIPv6 Diameter interworking. Their work influenced Patil, Charles E. Perkins, and Stefano Faccin -- for their work in
this document. Jouni Korhonen would like to thank Academy of Finland the context of MIPv6 Diameter interworking. Their work influenced
and TEKES MERCoNe Project for providing funding to work on this this document. Jouni Korhonen would like to thank the Academy of
document while he was with TeliaSonera. Julien Bournelle would like Finland and TEKES MERCoNe Project for providing funding to work on
to thank GET/INT since he began to work on this document while he was this document while he was with TeliaSonera. Julien Bournelle would
in their employ. Authors would also like to acknowledge Raymond Hsu like to thank GET/INT since he began to work on this document while
for his valuable feedback on local HA assignment and Wolfgang he was in their employ. Authors would also like to acknowledge
Fritsche for his thorough review. Finally, we would like to Domagoj Raymond Hsu for his valuable feedback on local HA assignment and
Premec for his review comments. Wolfgang Fritsche for his thorough review. Additionally, we would
like to Domagoj Premec for his review comments.
We would like to thank Alper Yegin, Robert Marks, David Frascone for Finally, we would like to thank Alper Yegin, Robert Marks, and David
their comments at the second WGLC. Frascone for their comments at the second WG Last Call.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
in IPv6", RFC 3775, June 2004. Support in IPv6", RFC 3775, June 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, and P. McCann, "Diameter Mobile IPv4 Application",
August 2005. RFC 4004, August 2005.
[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.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Authentication Protocol (EAP) Application", RFC 4072, Extensible Authentication Protocol (EAP) Application",
August 2005. RFC 4072, August 2005.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mext-aaa-ha-goals] [AAA] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J.,
Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. Lopez, "AAA Goals for Mobile IPv6", Work
and R. Lopez, "AAA Goals for Mobile IPv6", in Progress, May 2008.
draft-ietf-mext-aaa-ha-goals-01 (work in progress),
May 2008.
[I-D.ietf-mext-nemo-v4traversal] [DSMIPv6] Solimand, H., "Mobile IPv6 Support for Dual Stack Hosts
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and and Routers (DSMIPv6)", Work in Progress,
Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 December 2008.
(work in progress), December 2008.
[I-D.ietf-mip6-bootstrapping-integrated-dhc] [INTEGRATED] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[RFC3753] 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.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006. September 2006.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile
Bootstrapping in Split Scenario", RFC 5026, October 2007. IPv6 Bootstrapping in Split Scenario", RFC 5026,
October 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo FIN-02600 Espoo FIN-02600
Finland Finland
Email: jouni.nospam@gmail.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
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Email: Hannes.Tschofenig@nsn.com EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Charles E. Perkins Charles E. Perkins
WiChorus WiChorus Inc.
3590 North First St., Suite 300
San Jose, CA 95134
US
Email: charliep@wichorus.com EMail: charliep@wichorus.com
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place 30 International Place
Tewksbury MA 01876 Tewksbury, MA 01876
US US
Email: kchowdhury@starentnetworks.com EMail: kchowdhury@starentnetworks.com
 End of changes. 101 change blocks. 
290 lines changed or deleted 274 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/