< draft-ietf-dime-mip6-integrated-11.txt   draft-ietf-dime-mip6-integrated-12.txt >
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera Extensions (DIME) Nokia Siemens Networks
Internet-Draft J. Bournelle Internet-Draft J. Bournelle
Intended status: Standards Track Orange Labs Intended status: Standards Track Orange Labs
Expires: May 22, 2009 H. Tschofenig Expires: July 13, 2009 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
C. Perkins C. Perkins
WiChorus WiChorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
November 18, 2008 January 9, 2009
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-11.txt draft-ietf-dime-mip6-integrated-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 22, 2009. This Internet-Draft will expire on July 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 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,
authorization and accounting infrastructure. This document describes authorization and accounting infrastructure. This document describes
MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to MIPv6 bootstrapping using the Diameter Network Access Server to home
home Authentication, Authorization and Accounting server (HAAA) Authentication, Authorization and Accounting server interface.
interface.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Commands, Attribute Value Pairs and Advertising 4. Commands, Attribute Value Pairs and Advertising
Application Support . . . . . . . . . . . . . . . . . . . . . 7 Application Support . . . . . . . . . . . . . . . . . . . . . 7
4.1. Advertising Application Support . . . . . . . . . . . . . 7 4.1. Advertising Application Support . . . . . . . . . . . . . 7
4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7
4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7 4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7
4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8
4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8
4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 8 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 9
4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 10 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 11
5.2. Home Agent Assignment by the Diameter Server . . . . . . . 11 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 12
5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 12 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 13
6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 13 6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14
7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
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 a HA, the MN needs to know some information
skipping to change at page 3, line 33 skipping to change at page 4, line 33
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) 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 Network
case of the integrated scenario, or the HA, in case of the split Access Server, in case of the integrated scenario, or the HA, in case
scenario [RFC5026]. The terms integrated and split are described in of the split scenario [RFC5026]. The terms integrated and split are
the terminology section and were introduced in [RFC4640] and described in the terminology section and were introduced in [RFC4640]
[I-D.ietf-mext-aaa-ha-goals]. 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 [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 below are either borrowed from
[RFC4640][RFC5026] or introduced in this document: [RFC4640][RFC5026] or introduced in this document:
skipping to change at page 5, line 16 skipping to change at page 6, line 16
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 (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 AAA
functionality for the NAS to HAAA communication. functionality for the NAS to home AAA server (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 7, line 36 skipping to change at page 8, line 8
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 ABNF (as defined in both AVPs. The grouped AVP has the following ABNF (as defined in
[RFC3588]): [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 ]
[ MIP6-Home-Link-Prefix ]
* [ 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.
skipping to change at page 8, line 41 skipping to change at page 9, line 12
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 a 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 IP address can be in the MIP6-Agent-Info AVP. In this way the HA can be associated
associated with the corresponding realm the HA belongs to using the with the corresponding realm of the Diameter entity that added the
Destination-Realm AVP included in the MIP-Home-Agent-Host AVP. MIP6-Agent-Info AVP 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 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 the prefix allocated for the MN and this case, the HAAA returns to the NAS the prefix allocated to the
returns it the NAS. The NAS/ASP uses then, for example, mechanisms MN. The NAS/ASP delivers then the home link prefix to the MN using
described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver e.g. mechanisms described in
the home link prefix to the MN. [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The NAS/ASP MAY
propose to the HAAA a specific prefix to allocate to the MN by
including the MIP6-Home-Link-Prefix AVP in the request message.
However, the HAAA MAY override the prefix allocation hint proposed by
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 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 14, line 12 skipping to change at page 14, line 22
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 |
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 to be allocated This specification defines the following new AVPs to be allocated
from a normal Diameter AVP Code space (values >= 256): 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 The following new AVPs are to be allocated from RADIUS Type Code
[RFC2685] space so that they are RADIUS backward compatible (AVP Code [RFC2865] space 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 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 [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 MIP6-Feature-Vector AVP 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.
skipping to change at page 15, line 20 skipping to change at page 15, line 35
security considerations of the Diameter base protocol [RFC3588], security considerations of the Diameter base protocol [RFC3588],
Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] 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 Furthermore, the Diameter messages may be transported between the NAS
and the RADIUS server via one or more AAA brokers or Diameter agents and the Diameter server via one or more AAA brokers or Diameter
(such as proxies). In this case the NAS to the Diameter server AAA agents (such as proxies). In this case the NAS to the Diameter
communication rely on the security properties of the intermediate AAA server AAA communication rely on the security properties of the
brokers and Diameter agents. 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
document. Julien Bournelle would like to thank GET/INT since he document while he was with TeliaSonera. Julien Bournelle would like
began to work on this document while he was in their employ. Authors to thank GET/INT since he began to work on this document while he was
would also like to acknowledge Raymond Hsu for his valuable feedback in their employ. Authors would also like to acknowledge Raymond Hsu
on local HA assignment and Wolfgang Fritsche for his thorough review. for his valuable feedback on local HA assignment and Wolfgang
Finally, we would like to Domagoj Premec for his review comments. Fritsche for his thorough review. 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
[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.
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Identifier", RFC 2685, September 1999. "Remote Authentication Dial In User Service (RADIUS)",
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 J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 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 Support
in IPv6", RFC 3775, June 2004. 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., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005. August 2005.
skipping to change at page 16, line 36 skipping to change at page 17, line 5
10.2. Informative References 10.2. Informative References
[I-D.ietf-mext-aaa-ha-goals] [I-D.ietf-mext-aaa-ha-goals]
Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Giaretta, G., Guardini, I., Demaria, E., Bournelle, J.,
and R. Lopez, "AAA Goals for Mobile IPv6", and R. Lopez, "AAA Goals for Mobile IPv6",
draft-ietf-mext-aaa-ha-goals-01 (work in progress), draft-ietf-mext-aaa-ha-goals-01 (work in progress),
May 2008. May 2008.
[I-D.ietf-mext-nemo-v4traversal] [I-D.ietf-mext-nemo-v4traversal]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-06 (work in Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07
progress), November 2008. (work in progress), December 2008.
[I-D.ietf-mip6-bootstrapping-integrated-dhc] [I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. 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.
skipping to change at page 17, line 13 skipping to change at page 17, line 31
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. 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 an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
TeliaSonera Nokia Siemens Networks
Teollisuuskatu 13 Linnoitustie 6
Sonera FIN-00051 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
skipping to change at page 17, line 27 skipping to change at page 18, line 4
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
Phone: +358 (50) 4871445
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
Phone: +1-650-496-4402
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
Phone: +1 214 550 1416
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 31 change blocks. 
64 lines changed or deleted 76 lines changed or added

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