< draft-ietf-mip6-radius-00.txt   draft-ietf-mip6-radius-01.txt >
Network Working Group K. Chowdhury Network Working Group K. Chowdhury
Internet-Draft Starent Networks Internet-Draft Starent Networks
Expires: April 8, 2007 A. Lior Intended status: Standards Track A. Lior
Bridgewater Systems Expires: April 28, 2007 Bridgewater Systems
H. Tschofenig H. Tschofenig
Siemens Siemens
October 5, 2006 October 25, 2006
RADIUS Mobile IPv6 Support RADIUS Mobile IPv6 Support
draft-ietf-mip6-radius-00.txt draft-ietf-mip6-radius-01.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 37 skipping to change at page 1, line 37
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 April 8, 2007. This Internet-Draft will expire on April 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
A Mobile IPv6 node requires a home agent address, a home address, and A Mobile IPv6 node requires a home agent(HA) address, a home
IPsec security association with its home agent before it can start address(HOA), and IPsec security association with its HA before it
utilizing Mobile IPv6 service. RFC 3775 requires that some or all of can start utilizing Mobile IPv6 service. RFC 3775 requires that some
these parameters are statically configured. Ongoing work aims to or all of these parameters are statically configured. Ongoing work
make this information dynamically available to the mobile node. An aims to make this information dynamically available to the mobile
important aspect of the Mobile IPv6 bootstrapping solution is to node. An important aspect of the Mobile IPv6 bootstrapping solution
support interworking with existing authentication, authorization and is to support interworking with existing authentication,
accounting infrastructure. This document defines the new attributes authorization and accounting (AAA) infrastructure. This document
to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. defines new attributes to facilitate Mobile IPv6 bootstrapping via a
This information exchange may take place as part of the initial RADIUS infrastructure. This information exchange may take place as
network access authentication procedure or as part of a separate part of the initial network access authentication procedure or as
protocol exchange between the mobile node, the home agent and the AAA part of a separate protocol exchange between the mobile node, the HA
infrastructure. and the AAA infrastructure.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Integrated Scenario . . . . . . . . . . . . . . . . . . . 6 3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6
3.2 Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7
4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9
4.1 Home Agent Address Attribute . . . . . . . . . . . . . . . 9 4.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9
4.2 Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 9 4.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9
4.3 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 9 4.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9
4.4 Home Address Attribute . . . . . . . . . . . . . . . . . . 9 4.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9
4.5 DNS Update Mobility Option Attribute . . . . . . . . . . . 9 4.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 9
5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 10 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Home Agent Address Attribute . . . . . . . . . . . . . . . 10 5.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 10
5.2 Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 11 5.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 11
5.3 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 11 5.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 11
5.4 Home Address Attribute . . . . . . . . . . . . . . . . . . 12 5.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 12
5.5 DNS Update Mobility Option Attribute . . . . . . . . . . . 13 5.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 13
6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 15 6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 16
6.1.1 Home Agent allocation in the MSP . . . . . . . . . . . 15 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 16
6.1.2 Home Agent allocation in the ASP (visited network) . . 16 6.1.2. HA allocation in the ASP (visited network) . . . . . . 17
6.2 Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 17 6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 18
6.2.1 Mobile Service Provider and Mobile Service 6.2.1. Mobile Service Provider and Mobile Service
Authorizer are the same entity. . . . . . . . . . . . 17 Authorizer are the same entity. . . . . . . . . . . . 18
6.2.2 Mobile Service Provider and Mobile Service 6.2.2. Mobile Service Provider and Mobile Service
Authorizer are different entities. . . . . . . . . . . 19 Authorizer are different entities. . . . . . . . . . . 20
7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 20 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 21
7.1 General Goals . . . . . . . . . . . . . . . . . . . . . . 20 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Service Authorization . . . . . . . . . . . . . . . . . . 20 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 21
7.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4 Mobile Node Authentication . . . . . . . . . . . . . . . . 21 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 22
7.5 Provisioning of Configuration Parameters . . . . . . . . . 21 7.5. Provisioning of Configuration Parameters . . . . . . . . . 22
8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 22 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12.1 Normative References . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.2 Informative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform
registration with a Home Agent with information about its current registration with a HA with information about its current point of
point of attachment (Care-of Address). The Home Agent creates and attachment (Care-of Address). The HA creates and maintains binding
maintains binding between the MN's Home Address and the MN's Care-of between the MN's HOA and the MN's Care-of Address.
Address.
In order to register with a Home Agent, the MN needs to know some In order to register with a HA, the MN needs to know some information
information such as, the Home Link prefix, the Home Agent Address, such as, the Home Link prefix, the HA Address, the HOA, the Home Link
the Home Address, the Home Link prefix Length and security related prefix Length and security related information in order to secure the
information in order to secure the Binding Update. Binding Update.
The aforementioned set of information may be statically provisioned The aforementioned set of information may be statically provisioned
in the MN. However, static provisioning of this information has its in the MN. However, static provisioning of this information has its
drawbacks. It increases provisioning and network maintenance burden drawbacks. It increases provisioning and network maintenance burden
for the operator. Moreover, static provisioning does not allow load for the operator. Moreover, static provisioning does not allow load
balancing, failover, opportunistic home link assignment etc. For balancing, failover, opportunistic home link assignment etc. For
example, the user may be accessing the network from a location that example, the user may be accessing the network from a location that
may be geographically far away from the preconfigured home link; the may be geographically far away from the preconfigured home link; the
administrative burden to configure the MN's with the respective administrative burden to configure the MN's with the respective
addresses is large and the ability to react on environmental changes addresses is large and the ability to react on environmental changes
is minimal. In these situations static provisioning may not be is minimal. In these situations static provisioning may not be
desirable. desirable.
Dynamic assignment of Mobile IPv6 home registration information is a Dynamic assignment of Mobile IPv6 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 RADIUS infrastructure, which is used for access For this purpose, the RADIUS 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 RADIUS server in the Access Service necessary parameters. The RADIUS server in the Access Service
Provider (ASP) or in the Mobility Service Provider's (MSP) network Provider (ASP) or in the Mobility Service Provider's (MSP) network
may return these parameters to the AAA client. The AAA client might may return these parameters to the AAA client. The AAA client might
either be the NAS, in case of the integrated scenario, or the home either be the NAS, in case of the integrated scenario, or the HA, in
agent, in case of the split scenario. The terms integrated and split case of the split scenario. The terms integrated and split are
are described in the terminology section and were introduced in [6]. described in the terminology section and were introduced in [6].
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "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 [1]. document are to be interpreted as described in [1].
General mobility terminology can be found in [7]. The following General mobility terminology can be found in [7]. The following
additional terms, as defined in [6], are used in this document: additional terms, as defined in [6], are used in this document:
Access Service Authorizer (ASA): Access Service Authorizer (ASA):
A network operator that authenticates a mobile node and A network operator that authenticates a MN and establishes the
establishes the mobile node's authorization to receive Internet MN's authorization to receive Internet service.
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 mobile node. and from the MN.
Mobility Service Authorizer (MSA): Mobility Service Authorizer (MSA):
A service provider that authorizes Mobile IPv6 service. A service provider that authorizes Mobile IPv6 service.
Mobility Service Provider (MSP): Mobility Service Provider (MSP):
A service provider that provides Mobile IPv6 service. In order to A service provider that provides Mobile IPv6 service. In order to
obtain such service, the mobile node must be authenticated and obtain such service, the MN must be authenticated and authorized
authorized to obtain the Mobile IPv6 service. to obtain the Mobile IPv6 service.
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.
3. Solution Overview 3. Solution Overview
This document addresses the authentication, authorization and This document addresses the authentication, authorization and
accounting functionality required by for the MIPv6 bootstrapping as accounting functionality required by for the MIPv6 bootstrapping as
outlined in the MIPv6 bootstrapping problem statement document (see outlined in the MIPv6 bootstrapping problem statement document (see
[6]). As such, the AAA functionality for the integrated and the [6]). As such, the AAA functionality for the integrated and the
split scenario needs to be defined. This requires the ability to split scenario needs to be defined. This requires the ability to
offer support for the home agent to AAA server and the network access offer support for the HA to AAA server and the network access server
server to AAA server communication. to AAA server communication.
To highlight the main use cases, we briefly describe the integrated To highlight the main use cases, we briefly describe the integrated
and the split scenarios in Section 3.1 and Section 3.2, respectively. and the split scenarios in Section 3.1 and Section 3.2, respectively.
3.1 Integrated Scenario 3.1. Integrated Scenario
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 entity. participating entity.
+---------------------------+ +-----------------+ +---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(/MSP) | |Access Service Provider | |ASA/MSA/(/MSP) |
|(Mobility Service Provider)| | | |(Mobility Service Provider)| | |
| | | +-------+ | | | | +-------+ |
| +-------+ | | |Remote | | | +-------+ | | |Remote | |
skipping to change at page 6, line 52 skipping to change at page 6, line 52
+-------+ IEEE | +-----------+ +-------+ | +-------+ IEEE | +-----------+ +-------+ |
|Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | |
|Node |----------+-|RADIUS |---|Server | | |Node |----------+-|RADIUS |---|Server | |
| | PANA,... | |Client | | | | | | PANA,... | |Client | | | |
+-------+ DHCP | +-----------+ +-------+ | +-------+ DHCP | +-----------+ +-------+ |
+---------------------------+ +---------------------------+
Figure 1: Mobile IPv6 Service Access in the Integrated Scenario Figure 1: Mobile IPv6 Service Access in the Integrated Scenario
In the typical Mobile IPv6 access scenario as shown above, the MN In the typical Mobile IPv6 access scenario as shown above, the MN
attaches in a Access Service Provider's network. During this network attaches in a ASP's network. During this network attachment
attachment procedure, the NAS/RADIUS client interacts with the mobile procedure, the NAS/RADIUS client interacts with the MN. As shown in
node. As shown in Figure 1, the authentication and authorization Figure 1, the authentication and authorization happens via a RADIUS
happens via a RADIUS infrastructure. infrastructure.
At the time of authorizing the user for IPv6 access, the RADIUS At the time of authorizing the user for IPv6 access, the RADIUS
server in the MSA detects that the user is authorized for Mobile IPv6 server in the MSA detects that the user is authorized for Mobile IPv6
access. Based on the MSA's policy, the RADIUS server may allocate access. Based on the MSA's policy, the RADIUS server may allocate
several parameters to the MN for use during the subsequent Mobile several parameters to the MN for use during the subsequent Mobile
IPv6 protocol interaction with the home agent. IPv6 protocol interaction with the HA.
Depending on the details of the solution interaction with the DHCPv6 Depending on the details of the solution interaction with the DHCPv6
server may be required, as described in [2]. server may be required, as described in [2].
3.2 Split Scenario 3.2. Split Scenario
In the split scenario, Mobile IPv6 bootstrapping is not provided as In the split scenario, Mobile IPv6 bootstrapping is not provided as
part of the network access authentication procedure. The Mobile IPv6 part of the network access authentication procedure. The Mobile IPv6
bootstrapping procedure is executed with the Mobility Service bootstrapping procedure is executed with the Mobility Service
Provider when desired by the mobile node. Two variations can be Provider when desired by the MN. Two variations can be considered:
considered:
1. the MSA and the MSP are the same entity. 1. the MSA and the MSP are the same entity.
2. the MSA and the MSP are different entities. 2. the MSA and the MSP are different entities.
Since scenario (1) is the more generic scenario we show it in Since scenario (1) is the more generic scenario we show it in
Figure 2. Figure 2.
+----------------------+ +----------------------+
| | | |
skipping to change at page 8, line 20 skipping to change at page 8, line 20
|(MSA) |Server | | |(MSA) |Server | |
| +-------+ | | +-------+ |
+---------------^------+ +---------------^------+
| |
|RADIUS |RADIUS
| |
| |
+---------------------------------|------+ +---------------------------------|------+
|Mobility Service Provider (MSP) v | |Mobility Service Provider (MSP) v |
+-------+ | +-----------+ +-------+ | +-------+ | +-----------+ +-------+ |
|Mobile | MIPv6 / | |Home Agent/| RADIUS |Local | | |Mobile | MIPv6 / | |HA/ | RADIUS |Local | |
|Node |-------------|RADIUS |-------------- |RADIUS | | |Node |-------------|RADIUS |-------------- |RADIUS | |
| | IKEv2 | |Client | |Proxy | | | | IKEv2 | |Client | |Proxy | |
+-------+ | +-----------+ +-------+ | +-------+ | +-----------+ +-------+ |
+----------------------------------------+ +----------------------------------------+
Figure 2: Mobile IPv6 service access in the split scenario (MSA != Figure 2: Mobile IPv6 service access in the split scenario (MSA !=
MSP) MSP)
As shown in Figure 2 the interaction between the RADIUS client and As shown in Figure 2 the interaction between the RADIUS client and
the RADIUS server is triggered by the protocol interaction between the RADIUS server is triggered by the protocol interaction between
the mobile node and the home agent/RADIUS client using IKEv2 (see [3] the MN and the HA/RADIUS client using IKEv2 (see [3] and [8]). The
and [8]). The home agent / RADIUS Client interacts with the RADIUS HA / RADIUS Client interacts with the RADIUS infrastructure to
infrastructure to perform authentication, authorization, accounting perform authentication, authorization, accounting and parameter
and parameter bootstrapping. The exchange is triggered by the home bootstrapping. The exchange is triggered by the home agent and an
agent and an interaction with the RADIUS infrastructure is initiated. interaction with the RADIUS infrastructure is initiated. When the
When the protocol exchange is completed then the home agent needs to protocol exchange is completed then the HA needs to possess the
possess the Mobile IPv6 specific parameters (see [6]). Mobile IPv6 specific parameters (see [6]).
Additionally, the mobile node might instruct the RADIUS server (via Additionally, the MN might instruct the RADIUS server (via the home
the home agent) to perform a dynamic DNS update. agent) to perform a dynamic DNS update.
4. RADIUS Attribute Overview 4. RADIUS Attribute Overview
4.1 Home Agent Address Attribute 4.1. MIP6-HA Attribute
The RADIUS server may decide to assign a Home Agent to the MN that is The RADIUS server may decide to assign a HA to the MN that is in
in close proximity to the point of attachment (e.g., determined by close proximity to the point of attachment (e.g., determined by the
the NAS-ID). There may be other reasons for dynamically assigning NAS-ID). There may be other reasons for dynamically assigning HAs to
Home Agents to the MN, for example to share the traffic load. The the MN, for example to share the traffic load. The attribute also
attribute also contains the prefix length so that the MN can easily contains the prefix length so that the MN can easily infer the Home
infer the Home Link prefix from the Home Agent address. Link prefix from the HA address.
4.2 Home Agent FQDN Attribute 4.2. MIP6-HA-FQDN Attribute
The RADIUS server may assign an FQDN of the home address to the MN. The RADIUS server may assign an FQDN of the HOA to the MN. The
The mobile node can perform DNS query with the FQDN to derive the mobile node can perform DNS query with the FQDN to derive the HA
home agent address. address.
4.3 Home Link Prefix Attribute 4.3. MIP6-HL-Prefix Attribute
For the same reason as the HA assignment, the RADIUS server may For the same reason as the HA assignment, the RADIUS server may
assign a Home Link that is in close proximity to the point of assign a Home Link that is in close proximity to the point of
attachment (NAS-ID). The MN can perform [5] specific procedures to attachment (NAS-ID). The MN can perform [5] specific procedures to
discover other information for Mobile IPv6 registration. discover other information for Mobile IPv6 registration.
4.4 Home Address Attribute 4.4. MIP6-HOA Attribute
The RADIUS server may assign a Home Address to the MN. This allows The RADIUS server may assign a HOA to the MN. This allows the
the network operator to support mobile devices that are not network operator to support mobile devices that are not configured
configured with static addresses. The attribute also contains the with static addresses. The attribute also contains the prefix length
prefix length so that the MN can easily infer the Home Link prefix so that the MN can easily infer the Home Link prefix from the HA
from the Home Agent address. address.
4.5 DNS Update Mobility Option Attribute 4.5. MIP6-DNS-MO Attribute
By using this payload the RADIUS client instructs the RADIUS server By using this payload the RADIUS client instructs the RADIUS server
to perform a dynamic DNS update. When this payload is included in to perform a dynamic DNS update. When this payload is included in
the reverse direction, i.e., from the RADIUS server to the RADIUS the reverse direction, i.e., from the RADIUS server to the RADIUS
client, it informs about the status of the dynamic DNS update. When client, it informs about the status of the dynamic DNS update. When
the payload is sent from the RADIUS client to the RADIUS server then the payload is sent from the RADIUS client to the RADIUS server then
the response MUST include the DNS Update Mobility Option attribute. the response MUST include the MIP6-DNS-MO attribute.
5. RADIUS attributes 5. RADIUS attributes
This section defines format and syntax for the attribute that carries This section defines format and syntax for the attribute that carries
the Mobile IPv6 parameters that are described in the previous the Mobile IPv6 parameters that are described in the previous
section. section.
The attributes MAY be present in Access-Accept, Accounting-Request. The attributes MAY be present in Access-Accept, Accounting-Request.
5.1 Home Agent Address Attribute 5.1. MIP6-HA Attribute
This attribute is sent by the RADIUS server to the NAS in an Access- This attribute is sent by the RADIUS server to the NAS in an Access-
Accept message. The attribute carries the assigned Home Agent Accept packet. The attribute carries the assigned HA address.
address.
This attribute MAY be sent by the NAS to the RADIUS server in an
Access-Request packet as a hint to suggest a dynamic HA that may be
assigned to the MN. The RADIUS server MAY use this value or may
ignore this suggestion.
If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA-
FQDN SHOULD appear in accounting packets to indicate the identity of
the serving HA for this session.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| IPv6 address of assigned Home Agent | | IPv6 address of assigned HA |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-HA-ADDR-TYPE to be defined by IANA. ASSIGNED-HA-ADDR-TYPE to be defined by IANA.
Length: Length:
= 20 octets = 20 octets
Reserved: Reserved:
Reserved for future use. All bits set to 0. Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the Home Link. This field indicates the prefix length of the Home Link.
IPv6 address of assigned Home Agent: IPv6 address of assigned HA:
128-bit IPv6 address of the assigned Home Agent. 128-bit IPv6 address of the assigned HA.
5.2 Home Agent FQDN Attribute 5.2. MIP6-HA-FQDN Attribute
This attribute is sent by the RADIUS server to the NAS in an Access- This attribute is sent by the RADIUS server to the NAS in an Access-
Accept message. The attribute carries the FQDN of the assigned home Accept packet. The attribute carries the FQDN of the assigned HA.
agent.
This attribute MAY be sent by the NAS to the RADIUS server in an
Access-Request packet as a hint to suggest a dynamic HA that may be
assigned to the MN. The RADIUS server MAY use this value or may
ignore this suggestion.
If available at the NAS, at least MIP6-HA-FQDN attribute and/or
MIP6-HA SHOULD appear in accounting packets to indicate the identity
of the serving HA for this session.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | FQDN of the assigned HA .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FQDN of the assigned home agent ... | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-HA-FQDN-TYPE to be defined by IANA. ASSIGNED-HA-FQDN-TYPE to be defined by IANA.
Length: Length:
Variable length. Variable length.
Reserved: FQDN of the assigned HA:
Reserved for future use. All bits set to 0.
FQDN of the assigned home agent:
The data field MUST contain a FQDN as described in [9]. The data field MUST contain a FQDN as described in [9].
5.3 Home Link Prefix Attribute 5.3. MIP6-HL-Prefix Attribute
This attribute is sent by the RADIUS-MIP server to the NAS in an This attribute is sent by the RADIUS-MIP server to the NAS in an
Access-Accept message. The attribute carries the assigned Home Link Access-Accept packet. The attribute carries the assigned Home Link
prefix. prefix.
This attribute MAY be sent by the NAS to the RADIUS server in an
Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN
attribute as a hint to suggest a Home Link prefix that may be
assigned to the MN. The RADIUS server MUST use this value if it
accepts the NAS's HA suggestion.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Home Link Prefix | | Home Link Prefix |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-HL-TYPE to be defined by IANA. ASSIGNED-HL-TYPE to be defined by IANA.
Length: Length:
>= 4 octets + the minimum length of a prefix. >= 4 octets + the minimum length of a prefix.
Reserved: Reserved:
Reserved for future use. All bits set to 0. Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Prefix-Length:
This field indicates the prefix length of the Home Link.
Home Link Prefix: Home Link Prefix:
Home Link prefix (upper order bits) of the assigned Home Link Home Link prefix (upper order bits) of the assigned Home Link
where the MN should send binding update. where the MN should send binding update.
5.4 Home Address Attribute 5.4. MIP6-HOA Attribute
This attribute is sent by the RADIUS server to the NAS in an Access- This attribute is sent by the RADIUS server to the NAS in an Access-
Accept message. The attribute carries the assigned Home IPv6 Address Accept packet. The attribute carries the assigned Home IPv6 Address
for the MN. for the MN.
This attribute MAY be sent by the NAS to the RADIUS server in an
Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN
attribute as a hint to suggest a Home Address that may be assigned to
the MN. The RADIUS server MUST use this value if it accepts the
NAS's HA suggestion.
If available at the NAS, this attribute SHOULD appear in the
accounting packets so that the IPv6 addressed used for this session
is known in the accounting stream.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Assigned IPv6 Home Address | | Assigned IPv6 HOA |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-HOA-TYPE to be defined by IANA. ASSIGNED-HOA-TYPE to be defined by IANA.
Length: Length:
= 20 octets. = 20 octets.
Reserved: Reserved:
Reserved for future use. All bits set to 0. Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the Home Link. This field indicates the prefix length of the Home Link.
Assigned IPv6 Home Address: Assigned IPv6 HOA:
IPv6 Home Address that is assigned to the MN. IPv6 HOA that is assigned to the MN.
5.5 DNS Update Mobility Option Attribute 5.5. MIP6-DNS-MO Attribute
The DNS Update Mobility Option attribute is used for triggering a DNS The MIP6-DNS-MO attribute is used for triggering a DNS update by the
update by the RADIUS server and to return the result to the RADIUS RADIUS server and to return the result to the RADIUS client. The
client. The request MUST carry the mobile node's FQDN but the request MUST carry the MN's FQDN but the attribute carried in
attribute carried in response to the request MAY not carry a FQDN response to the request MAY not carry a FQDN value.
value.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved-1 | Status | | Type | Length | Reserved-1 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved-2 | FQDN ... |R| Reserved-2 | FQDN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
DNS-UPDATE-TYPE to be defined by IANA. DNS-UPDATE-TYPE to be defined by IANA.
Length: Length:
Variable length. Variable length.
Reserved-1: Reserved-1:
Reserved for future use. All bits set to 0. Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver.
Status: Status:
This 8 bit unsigned integer field indicates the result of the This 8 bit unsigned integer field indicates the result of the
dynamic DNS update procedure. This field MUST be set to 0 and dynamic DNS update procedure as defined in [3]. This field
ignored by the RADIUS server when the DNS Update Mobility MUST be set to 0 and ignored by the RADIUS server when the
Option is sent from the RADIUS client to the RADIUS server. MIP6-DNS-MO is sent from the RADIUS client to the RADIUS
When the DNS Update Mobility Option is provided in the server. When the MIP6-DNS-MO is provided in the response,
response, values of the Status field less than 128 indicate values of the Status field less than 128 indicate that the
that the dynamic DNS update was performed successfully by the dynamic DNS update was performed successfully by the RADIUS
RADIUS server. Values greater than or equal to 128 indicate server. Values greater than or equal to 128 indicate that the
that the dynamic DNS update was not successfully completed. dynamic DNS update was not successfully completed. The
following values for the Status field are currently defined:
The following values for the Status field are currently
defined:
0 DNS update performed 0 DNS update performed
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 DNS Update Failed 130 DNS Update Failed
R flag: R flag:
skipping to change at page 14, line 28 skipping to change at page 15, line 10
If this bit for the R flag is set then the RADIUS client If this bit for the R flag is set then the RADIUS client
requests the RADIUS server to remove the DNS entry identified requests the RADIUS server to remove the DNS entry identified
by the FQDN included in this attribute. If not set, the RADIUS by the FQDN included in this attribute. If not set, the RADIUS
client is requesting the RADIUS server to create or update a client is requesting the RADIUS server to create or update a
DNS entry with the FQDN specified in this attribute and the DNS entry with the FQDN specified in this attribute and the
Home Address carried in another attribute specified in this Home Address carried in another attribute specified in this
document. document.
Reserved-2: Reserved-2:
Reserved for future use. All bits set to 0. Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver.
FQDN of the mobile node: FQDN of the MN:
The data field MUST contain a FQDN as described in [9]. In an Access-Request packet the data field MUST contain a FQDN.
In an Access-Accept packet the data field MAY contain an FQDN.
FQDN is described in [9].
6. Message Flows 6. Message Flows
6.1 Integrated Scenario (MSA=ASA) 6.1. Integrated Scenario (MSA=ASA)
This section is based on [2] and uses the previously defined RADIUS This section is based on [2] and uses the previously defined RADIUS
attributes. attributes.
6.1.1 Home Agent allocation in the MSP 6.1.1. HA allocation in the MSP
RADIUS is used to authenticate the mobile node, to authorize it for RADIUS is used to authenticate the MN, to authorize it for the
the mobility service and to send information about the assigned home mobility service and to send information about the assigned HA to the
agent to the NAS. NAS.
| |
--------------ASP------>|<--ASA+MSA-- --------------ASP------>|<--ASA+MSA--
| |
+----+ +------+ +-------+ +-------+ +----+ +------+ +-------+ +-------+
| | |RADIUS| | | | | | | |RADIUS| | | | |
| | |Client| | | | | | | |Client| | | | |
| MN | |NAS/ | | DHCP | |Home | | MN | |NAS/ | | DHCP | |Home |
| | |DHCP | | Server| |RADIUS | | | |DHCP | | Server| |RADIUS |
| | |Relay | | | |Server | | | |Relay | | | |Server |
skipping to change at page 15, line 46 skipping to change at page 16, line 46
| | 3 | | | | 3 | |
| |------------>| | | |------------>| |
| | | | | | | |
| | 4 | | | | 4 | |
| |<------------| | | |<------------| |
| | | | | | | |
| 5 | | | | 5 | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
HA allocation in the MSP
In step (1), the MN executes the normal network access authentication In step (1), the MN executes the normal network access authentication
procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS
acts as an authenticator in "pass-through" mode, i.e., the endpoint acts as an authenticator in "pass-through" mode, i.e., the endpoint
of the authentication dialogue is the MN's home RADIUS server. This of the authentication dialogue is the MN's home RADIUS server. This
is the typical scenario in case the messages involved in the is the typical scenario in case the messages involved in the
authentication protocol are transported in EAP. authentication protocol are transported in EAP.
The NAS encapsulates/decapsulates EAP packets into/from RADIUS As per [10], the NAS encapsulates/decapsulates EAP packets into/from
messages until an Access-Response (either an Access-Accept or an RADIUS packets until an Access-Response (either an Access-Accept or
Access/Reject packet is received by the NAS). This concludes the an Access/Reject packet is received by the NAS). This concludes the
network access authentication phase. network access authentication phase.
Depending on the RADIUS server configuration, the Home Agent Address Depending on the RADIUS server configuration, the MIP6-HA attribute
attribute or the the Home Agent FQDN attribute may be appended to the or the the MIP6-HA-FQDN attribute may be appended to the Access-
Access-Accept message. In the latter case the MN needs to perform a Accept packet. In the latter case the MN needs to perform a DNS
DNS query in order to discover the Home Agent address. query in order to discover the HA address.
The Home Agent Address or Home Agent FQDN attribute is appended to The MIP6-HA or MIP6-HA-FQDN attribute is appended to the Access-
the access accept in case the home RADIUS server knows or has Accept in case the home RADIUS server knows or has allocated a HA to
allocated a HA to the access request (this is assumed in this the Access-Request (this is assumed in this scenario).
scenario).
In step (2) the MN sends a DHCPv6 Information Request message to In step (2) the MN sends a DHCPv6 Information Request message to
all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code
for the Home Network Identifier Option shall be included in that for the Home Network Identifier Option shall be included in that
message. The Home Network Identifier Option should have id-type of message. The Home Network Identifier Option should have id-type of
1, the message is a request to discover home network information that 1, the message is a request to discover home network information that
pertains to the given realm, i.e., the user's home domain (identified pertains to the given realm, i.e., the user's home domain (identified
by the NAI of the MN). The OPTION_CLIENTID is set by the MN to by the NAI of the MN). The OPTION_CLIENTID is set by the MN to
identify itself to the DHCP server. identify itself to the DHCP server.
In step (3) the DHCP relay agent forwards this request to the DHCP In step (3) the DHCP relay agent forwards this request to the DHCP
server. The OPTION_MIP6-RELAY-Option is included in this forwarded server. The OPTION_MIP6-RELAY-Option is included in this forwarded
message. This option carries the RADIUS Home Agent Address Attribute message. This option carries the RADIUS MIP6-HA Attribute from the
from the access accept message. Access-Accept packet.
In step (4), the DHCP server identifies the client (by DUID) and In step (4), the DHCP server identifies the client (by DUID) and
finds out that it requests home agent information in the MSP (by the finds out that it requests HA information in the MSP (by the Home
Home Network Identifier Option = 1). The DHCP server extracts the Network Identifier Option = 1). The DHCP server extracts the HA
home agent address from OPTION_MIP6-RELAY-Option and places it into address from OPTION_MIP6-RELAY-Option and places it into Home Network
Home Network Information Option in the Reply message. Information Option in the Reply message.
In step (5), the Relay Agent forwards the Reply Message to the Mobile In step (5), the Relay Agent forwards the Reply Message to the MN.
Node. On reception of this message, the home agent address or the On reception of this message, the HA address or the FQDN of the home
FQDN of the home agent is available at the MN. agent is available at the MN.
6.1.2 Home Agent allocation in the ASP (visited network) 6.1.2. HA allocation in the ASP (visited network)
This scenario is similar to the one described in Section 6.1.1. The This scenario is similar to the one described in Section 6.1.1. The
difference is in step (2), where the type-id field in the Home difference is in step (2), where the type-id field in the Home
Network Identifier Option is set to zero, indicating that a Home Network Identifier Option is set to zero, indicating that a HA is
Agent is requested in the ASP instead of in the MSP. Thus, the requested in the ASP instead of in the MSP. Thus, the information
information received by the home RADIUS server, via the DHCP relay, received by the home RADIUS server, via the DHCP relay, in the
in the OPTION_MIP6-RELAY-Option (Information Request) is ignored. OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP
The DHCP server allocates a home agent from its list of possible home server allocates a HA from its list of possible HAs and returns it in
agents and returns it in the Reply message (Home Network Information the Reply message (Home Network Information Option).
Option).
6.2 Split Scenario (MSA!=ASA) 6.2. Split Scenario (MSA!=ASA)
6.2.1 Mobile Service Provider and Mobile Service Authorizer are the 6.2.1. Mobile Service Provider and Mobile Service Authorizer are the
same entity. same entity.
The assumption in this scenario is that the MN has the domain name of The assumption in this scenario is that the MN has the domain name of
the MSP preconfigured. the MSP preconfigured.
In this scenario there is no relationship between the network access In this scenario there is no relationship between the network access
authentication procedure and the MIPv6 bootstrapping procedure. authentication procedure and the MIPv6 bootstrapping procedure.
In order to learn the IP address of the home agent, the MN either In order to learn the IP address of the HA, the MN either performs a
performs a DNS lookup of the Home Agent Name or a DNS lookup by DNS lookup of the HA Name or a DNS lookup by service name. In the
service name. In the first case, the MN is preconfigured with the first case, the MN is preconfigured with the FQDN of the HA, and thus
FQDN of the HA, and thus sends a DNS request, where QNAME = name of sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request
HA, QTYPE='AAAA' (request for IPv6 address of HA). A DNS reply for IPv6 address of HA). A DNS reply message is returned by the DNS
message is returned by the DNS server with the HA address. server with the HA address.
The MN then runs IKEv2 with the HA in order to set up IPsec SAs The MN then runs IKEv2 [11] with the HA in order to set up IPsec SAs
(MN-HA). As part of this,the MN authenticates itself to the RADIUS (MN-HA). As part of this,the MN authenticates itself to the RADIUS
server in the MSA domain, and obtains authorization for mobility server in the MSA domain, and obtains authorization for mobility
service (including the Home Address). service (including the Home Address).
The MN shares credentials with the RADIUS server in the MSA domain. The MN shares credentials with the RADIUS server in the MSA domain.
The RADIUS communication between the HA and the this RADIUS server is The RADIUS communication between the HA and the this RADIUS server is
also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP
within IKEv2, the MN is authenticated and authorized for the IPv6 within IKEv2 [11], the MN is authenticated and authorized for the
mobility service and is also assigned a home address. IPv6 mobility service and is also assigned a HOA.
The setup of SAs and mutual authentication between MN and AAAH using The setup of SAs and mutual authentication between MN and AAAH using
RADIUS (and EAP) is similar to the one described for Diameter RADIUS (and EAP) is similar to the one described for Diameter
protocol in [10]. The described mechanism ensureas that common protocol in [12]. The described mechanism ensureas that common
keying material will be available at the MN and HA after successful keying material will be available at the MN and HA after successful
completion. completion.
----------------------------ASP--------->|<-----MSA/MSP ----------------------------ASP--------->|<-----MSA/MSP
+----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+
| MN |<----------->| HA |<-------------------->|Remote RADIUS Server| | MN |<----------->| HA |<-------------------->|Remote RADIUS Server|
+----+ +----+ +--------------------+ +----+ +----+ +--------------------+
MN HA Remote RADIUS server MN HA Remote RADIUS server
-- -- -------------------- -- -- --------------------
IKE_SA_INIT IKE_SA_INIT
<------------------------------> <------------------------------>
HDR, SK{IDi,[CERTREQ,] [IDr,] HDR, SK{IDi,[CERTREQ,] [IDr,]
SAi2, TSi, TSr} SAi2, TSi, TSr}
-------------------------------> ------------------------------->
RADIUS Access Request(EAP-Response) RADIUS Access-Request(EAP-Response)
----------------------------------> ---------------------------------->
RADIUS Access Challenge(EAP-Request) RADIUS Access-Challenge(EAP-Request)
<----------------------------------- <-----------------------------------
HDR, SK {IDr, [CERT,] AUTH, HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
<------------------------------- <-------------------------------
HDR, SK {EAP} HDR, SK {EAP}
--------------------------------> -------------------------------->
RADIUS Access Request(EAP-Response) RADIUS Access-Request(EAP-Response)
----------------------------------> ---------------------------------->
RADIUS Access Challenge(EAP-Request) RADIUS Access-Challenge(EAP-Request)
<----------------------------------- <-----------------------------------
HDR, SK{EAP-Request} HDR, SK{EAP-Request}
<------------------------------- <-------------------------------
HDR, SK{EAP-Response} HDR, SK{EAP-Response}
--------------------------------> -------------------------------->
RADIUS Access Request(EAP-Response) RADIUS Access-Request(EAP-Response)
----------------------------------> ---------------------------------->
... ... ... ...
RADIUS Access Accept(EAP-Success) RADIUS Access-Accept(EAP-Success)
<------------------------ <------------------------
HDR, SK{EAP-Success} HDR, SK{EAP-Success}
<------------------------------- <-------------------------------
HDR, SK{AUTH} HDR, SK{AUTH}
-------------------------------> ------------------------------->
HDR, SK {AUTH, SAr2, TSi, TSr } HDR, SK {AUTH, SAr2, TSi, TSr }
<------------------------------- <-------------------------------
Split Scenario Exchange
MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages
defined in the IKEv2 specification, negotiating crypto algorithms and defined in the IKEv2 specification [11], negotiating crypto
running DH key exchange). IKEv2 supports integration with EAP. The algorithms and running DH key exchange). IKEv2 supports integration
MN indicates its desire to use EAP by not including the AUTH payload with EAP. The MN indicates its desire to use EAP by not including
in the third message. However, it indicates its identity (NAI) by the AUTH payload in the third message. However, it indicates its
using the IDi field. If the HA supports EAP for authentication, it identity (NAI) by using the IDi field. If the HA supports EAP for
forwards the identity to the Remote RADIUS server by sending a RADIUS authentication, as per [10] it forwards the identity to the Remote
Access-Request message containing the identity in the EAP-Payload AVP RADIUS server by sending a RADIUS Access-Request packet containing
and in the RADIUS User-Name attribute. Based on this identity, the the identity in the EAP-Payload AVP and in the RADIUS User-Name
Remote RADIUS server chooses authentication method and sends the attribute. Based on this identity, the Remote RADIUS server chooses
first EAP-Request in the RADIUS Access-Challenge message. During the authentication method and sends the first EAP-Request in the RADIUS
EAP authentication phase, the HA relays EAP packets between the MN Access-Challenge packet. During the EAP authentication phase, the HA
and the Remote RADIUS server. If the authentication succeeds and if relays EAP packets between the MN and the Remote RADIUS server. If
the MN is authorized to use Mobile IPv6 service, the Remote RADIUS the authentication succeeds and if the MN is authorized to use Mobile
server sends a RADIUS Access Accept message containing the EAP- IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept
Success and the AAA-Key derived from the EAP authentication method. packet containing the EAP-Success and the AAA-Key derived from the
EAP authentication methods that do not derive keys are not EAP authentication method. EAP authentication methods that do not
recommended. This key is used by both MN and HA to generate the AUTH derive keys are not recommended. This key is used by both MN and HA
payload. In subsequent messages, MN and HA setup IPsec SAs for to generate the AUTH payload. In subsequent messages, MN and HA
Mobile IPv6. setup IPsec SAs for Mobile IPv6.
6.2.2 Mobile Service Provider and Mobile Service Authorizer are 6.2.2. Mobile Service Provider and Mobile Service Authorizer are
different entities. different entities.
The HA address discovery is performed as described in Section 6.2.1. The HA address discovery is performed as described in Section 6.2.1.
-----------ASP--------->|<-----MSP------------------->|<-----MSA-------- -----------ASP--------->|<-----MSP------------------->|<-----MSA--------
+----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+
| MN |<----------> | HA |<----------->|Local |<---------->|Remote| | MN |<----------> | HA |<----------->|Local |<---------->|Remote|
+----+ +----+ |RADIUS| |RADIUS| +----+ +----+ |RADIUS| |RADIUS|
|Proxy | |Server| |Proxy | |Server|
+------+ +------+ +------+ +------+
MSP#MSA Exchange
The scenario is similar to previously described scenarios with the The scenario is similar to previously described scenarios with the
difference of utilizing AAA roaming agreements between the MSP and difference of utilizing AAA roaming agreements between the MSP and
the MSA. the MSA.
7. Goals for the HA-AAA Interface 7. Goals for the HA-AAA Interface
Here, we follow the classification and labels listed in the MIPv6- Here, we follow the classification and labels listed in the MIPv6-
AAA-Goals document [11]. AAA-Goals document [13].
7.1 General Goals 7.1. General Goals
G1.1-G1.4 Security G1.1-G1.4 Security
These are standard requirements for a AAA protocol - mutual These are standard requirements for a AAA protocol - mutual
authentication, integrity, replay protection, confidentiality. IPsec authentication, integrity, replay protection, confidentiality. IPsec
can be used to achieve the goals. Goal G1.5 regarding inactive peer can be used to achieve the goals. Goal G1.5 regarding inactive peer
detection needs further investigations since heartbeat messages do detection needs further investigations since heartbeat messages do
not exist (like in the Diameter case, Watch-Dog-Request/Answer). not exist (like in the Diameter case, Watch-Dog-Request/Answer).
7.2 Service Authorization 7.2. Service Authorization
G2.1. The AAA-HA interface should allow the use of Network Access G2.1. The AAA-HA interface should allow the use of Network Access
Identifier (NAI) to identify the mobile node. The User-Name Identifier (NAI) to identify the MN. The User-Name attribute can be
attribute can be used for the purpose to carry the NAI. used for the purpose to carry the NAI.
G2.2 The HA should be able to query the AAAH server to verify Mobile G2.2 The HA should be able to query the AAAH server to verify Mobile
IPv6 service authorization for the mobile node. Any node IPv6 service authorization for the MN. Any node implementing RADIUS
implementing RADIUS functionality can possibly initiate a request functionality[4] can possibly initiate a request message. In
message. In combination with the ability of the RADIUS protocol to combination with the ability of the RADIUS protocol to carry EAP
carry EAP messages, our solution will enable an HA to query a RADIUS messages [10] , our solution will enable an HA to query a RADIUS
server and verify MIPv6 authorization for the MN. server and verify MIPv6 authorization for the MN.
G2.3 The AAAH server should be able to enforce explicit operational G2.3 The AAAH server should be able to enforce explicit operational
limitations and authorization restrictions on the HA (e.g., packet limitations and authorization restrictions on the HA (e.g., packet
filters, QoS parameters). Work in progress in the area, including filters, QoS parameters). Work in progress in the area, including
NAS-Filter-Rule, RADIUS quality of service support, prepaid NAS-Filter-Rule, RADIUS quality of service support, prepaid
extensions etc. is performed. The relevant attributes may be reused extensions etc. is performed. The relevant attributes may be reused
for providing required functionality over the AAAH-HA interface. for providing required functionality over the AAAH-HA interface.
G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6
session by the AAAH server, e.g., authorization lifetime, extension session by the AAAH server, e.g., authorization lifetime, extension
of the authorization lifetime and explicit session termination by the of the authorization lifetime and explicit session termination by the
AAAH server side. AAAH server side.
The attribute Session-Timeout may be sent in Access Challenge or The attribute Session-Timeout may be sent in Access-Challenge or
Access Accept message by the RADIUS server, thus limiting the Access-Accept packet by the RADIUS server, thus limiting the
authorization session duration. In order to reauthenticate/ authorization session duration. In order to reauthenticate/
reauthorize the user, the Termination-Action attribute can be reauthorize the user, the Termination-Action attribute can be
included, with value 1, meaning the NAS should send a new RADIUS- included, with value 1, meaning the NAS should send a new RADIUS-
Request packet. Additional AVPs for dealing with pre-paid sessions Request packet. Additional AVPs for dealing with pre-paid sessions
(e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are
specified in RADIUS prepaid extension. Exchanging of application specified in RADIUS prepaid extension. Exchanging of application
specific authorization request/answer messages provides extension of specific authorization request/answer messages provides extension of
the authorization session (e.g., Authorize Only Access Request sent the authorization session (e.g., Authorize Only Access-Request sent
by the HA (NAS) to the RADIUS server). Initiation of the re- by the HA (NAS) to the RADIUS server). Initiation of the re-
authorization by both sides could be supported. Both sides could authorization by both sides could be supported. Both sides could
initiate session termination - the RADIUS server by sending initiate session termination - the RADIUS server by sending
Disconnect message. Disconnect message [14].
7.3 Accounting 7.3. Accounting
G3.1 The AAA-HA interface must support the transfer of accounting G3.1 The AAA-HA interface must support the transfer of accounting
records needed for service control and charging. These include (but records needed for service control and charging. These include (but
may not be limited to): time of binding cache entry creation and may not be limited to): time of binding cache entry creation and
deletion, octets sent and received by the mobile node in bi- deletion, octets sent and received by the MN in bi-directional
directional tunneling, etc. tunneling, etc.
The requirements for accounting over the AAAH-HA interface does not The requirements for accounting over the AAAH-HA interface does not
require enhancements to the existing accounting functionality. require enhancements to the existing accounting functionality.
7.4 Mobile Node Authentication 7.4. MN Authentication
G4.1 The AAA-HA interface MUST support pass-through EAP G4.1 The AAA-HA interface MUST support pass-through EAP
authentication with the HA working as EAP authenticator operating in authentication with the HA working as EAP authenticator operating in
pass-through mode and the AAAH server working as back-end pass-through mode and the AAAH server working as back-end
authentication server. authentication server.
These issues require the functionality of AAAH server working as a These issues require the functionality of AAAH server working as a
back-end authentication server and HA working as NAS and EAP back-end authentication server and HA working as NAS and EAP
authenticator in pass-through mode for providing a mobile node authenticator in pass-through mode for providing a MN authentication.
authentication. This document suggests this mode of operation in the This document suggests this mode of operation in the context of the
context of the relevant scenarios. relevant scenarios.
7.5 Provisioning of Configuration Parameters 7.5. Provisioning of Configuration Parameters
G5.1 The HA should be able to communicate to the AAAH server the Home G5.1 The HA should be able to communicate to the AAAH server the HOA
Address allocated to the MN (e.g. for allowing the AAAH server to allocated to the MN (e.g. for allowing the AAAH server to perform DNS
perform DNS update on behalf of the MN). update on behalf of the MN).
This document describes needed AVPs for this purpose, see section This document describes needed AVPs for this purpose, see section
"DNS Update Mobility Option Attribute" "DNS Update Mobility Option Attribute"
8. Table of Attributes 8. Table of Attributes
The following table provides a guide to which attributes may be found The following tables provides a guide to which attributes may be
in RADIUS message and in what number. found in RADIUS packet and in what number.
Request Accept Reject Challenge Attribute The following defines the meaning of the notation used in the following
tables:
0-1 0-1 0 0 Home Agent Address Attribute 0 This attribute MUST NOT be present.
0-1 0-1 0 0 Home Agent FQDN Attribute 0-1 Zero or one instance of this attribute MAY be present.
0-1 0-1 0 0 Home Link Prefix Attribute
0-1 0-1 0 0 Home Address Attribute
0-1 0-1 0 0 DNS Update Mobility Option
Attribute
The following table defines the meaning of the above table entries. Request Accept Reject Challenge Type Attribute
0 This attribute MUST NOT be present. 0-1[a] 0-1[a] 0 0 MIP6-HA-TYPE MIP6-HA Attribute
0-1 Zero or one instance of this attribute MAY be present. 0-1[a] 0-1[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute
0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute
0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA Attribute
0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute
9. Security Considerations Notes:
[a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet.
[b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request
then these attributes MUST also be present in the Access-Request.
If the RADIUS server accepts the NAS suggestion for the HA, then
the RADIUS server MUST also include the values received for these
attributes in the Access-Accept.
As used in accounting packets:
Request Interim Stop Type Attribute
0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute
0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute
0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute
0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute
0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute
9. Diameter Considerations
When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the
attributes are as follows:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
MIP6-HA Address | M | P | | V | Y |
MIP6-HA-FQDN UTF8String | M | P | | V | Y |
MIP6-HL-Prefix OctetString| M | P | | V | Y |
MIP6-HOA Address | M | P | | V | Y |
MIP6-DNS-MO OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
Other than MIP6-HA and HOA-IPv6, the attributes in this specification
have no special translation requirements for Diameter to RADIUS or
RADIUS to Diameter gateways; they are copied as is, except for
changes relating to headers, alignment, and padding. See also [15]
Section 4.1 and [16] Section 9. MIP6-HA and HOA-IPv6 must be
translated between their RADIUS representation of String to a
Diameter Address format which requires that the AddressType field be
set to 2 for IP6 (IP version 6)
What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [16] or Diameter-EAP-Request [17]. What is said about
Access-Challenge applies in Diameter to AA-Answer [16] or Diameter-
EAP-Answer [17] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.
What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure.
What is said about Accounting-Request applies to Diameter Accounting-
Request [16] as well.
10. Security Considerations
Assignment of these values to a user should be based on successful Assignment of these values to a user should be based on successful
authentication of the user at the NAS and/or at the home agent. The authentication of the user at the NAS and/or at the HA. The RADIUS
RADIUS server should only assign these values to a user who is server should only assign these values to a user who is authorized
authorized for Mobile IPv6 service (this check could be performed for Mobile IPv6 service (this check could be performed with the
with the user's subscription profile in the Home Network). user's subscription profile in the Home Network).
The NAS and the home agent to the RADIUS server transactions must be The NAS and the HA to the RADIUS server transactions must be
adequately secured. Otherwise there is a possibility that the user adequately secured. Otherwise there is a possibility that the user
may receive fraudulent values from a rogue RADIUS server potentially may receive fraudulent values from a rogue RADIUS server potentially
hijacking the user's Mobile IPv6 session. hijacking the user's Mobile IPv6 session.
These new attributes do not introduce additional security These new attributes do not introduce additional security
considerations besides the ones identified in [4]. considerations besides the ones identified in [4].
10. IANA Considerations 11. IANA Considerations
The following RADIUS attribute Type values MUST be assigned by IANA. The following RADIUS attribute Type values MUST be assigned by IANA.
ASSIGNED-HA-ADDR-TYPE MIP6-HA-TYPE
ASSIGNED-HA-FQDN-TYPE MIP6-HA-FQDN-TYPE
ASSIGNED-HL-TYPE MIP6-HL-PREFIX-TYPE
ASSIGNED-HOA-TYPE MIP6-HOA-TYPE
DNS-UPDATE-TYPE MIP6-DNS-MO-TYPE
11. Acknowledgements 12. Acknowledgements
We would like to thank the following individuals for their review and We would like to thank the following individuals for their review and
constructive comments during the development of this document: constructive comments during the development of this document:
Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev,
Andreas Pashalidis, Rafa Marin Lopez. Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen.
12. References 13. References
12.1 Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario", the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
progress), June 2006. progress), June 2006.
[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress), draft-ietf-mip6-bootstrapping-split-03 (work in progress),
March 2006. October 2006.
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
12.2 Informative References 13.2. Informative References
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping [6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
progress), May 2006. progress), May 2006.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", [7] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with [8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", IKEv2 and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006.
[9] Mockapetris, P., "Domain names - implementation and [9] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[10] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", [10] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
[11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[12] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter",
draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress),
October 2005. October 2005.
[11] Giaretta, G., "AAA Goals for Mobile IPv6", [13] Giaretta, G., "AAA Goals for Mobile IPv6",
draft-ietf-mip6-aaa-ha-goals-03 (work in progress), draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
September 2006. September 2006.
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [14] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial
In User Service (RADIUS)", RFC 3576, July 2003.
[15] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[16] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[17] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [19] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[14] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic [20] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
Authors' Addresses Authors' Addresses
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
US US
skipping to change at page 28, line 5 skipping to change at page 31, line 5
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 29 skipping to change at page 31, line 45
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 133 change blocks. 
349 lines changed or deleted 473 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/