Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: January 14, 2010 Huawei USA
July 13, 2009
BU/BA Based Prefix Delegation Support for Mobile Networks
draft-sarikaya-mext-bu-prefixdelegation-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
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
Sarikaya & Xia Expires January 14, 2010 [Page 1]
Internet-Draft Prefix Delegation Support July 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Sarikaya & Xia Expires January 14, 2010 [Page 2]
Internet-Draft Prefix Delegation Support July 2009
Abstract
This document defines prefix delegation support for mobile networks.
Mobile Router dynamically requests its Mobile Network Prefixes from
its Home Agents using Binding Update both at the home link and at the
visited links. Home agents get the prefixes delegated using DHCPv6
Prefix Delegation or by other means and reply to the Mobile Router
with Binding Acknowledgement.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Nemo Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . 6
3.1. Home Link Support . . . . . . . . . . . . . . . . . . . . 7
3.2. Prefix Renew Procedure . . . . . . . . . . . . . . . . . . 9
3.3. Prefix Release Procedure . . . . . . . . . . . . . . . . . 9
4. Nemo Prefix Delegation Using Other Means . . . . . . . . . . . 10
5. Prefix to Interface Mapping at the MR . . . . . . . . . . . . 10
6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 11
6.1. Rapid Commit Option . . . . . . . . . . . . . . . . . . . 11
6.2. Implicit/Explicit Modes . . . . . . . . . . . . . . . . . 11
6.3. Advertising Delegated Prefixes . . . . . . . . . . . . . . 11
6.4. DHCP Server Issues . . . . . . . . . . . . . . . . . . . . 11
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Home Network Prefix Option . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative references . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Sarikaya & Xia Expires January 14, 2010 [Page 3]
Internet-Draft Prefix Delegation Support July 2009
1. Introduction
Nemo Basic Support Protocol requires that IPv6 prefixes called Mobile
Network Prefix(es) delegated to a Mobile Router and be advertized in
the Mobile Network [RFC3963]. However the protocol does not provide
any means of provisioning Mobile Network Prefixes (MNPs) dynamically.
Prefix delegation is widely discussed in IETF 16NG, MEXT, and NETLMM
Working Groups. Corresponding solutions are also introduced. NEMO
deals with synchronization of Mobile Network prefixes between a
Mobile Router and a Home Agent, while the method is agnostic to the
way that a Home Agent gets prefixes from back end servers.
[RFC3633] defines Prefix Delegation options and procedures to provide
a mechanism for automated delegation of IPv6 prefixes using the
Dynamic Host Configuration Protocol (DHCP).
In Proxy Mobile IPv6 [RFC5213] home network prefix (HNP) is used by
MN to assign a home address. Mobile access gateway (MAG) needs to
emulate MN's home network on the access link and therefore needs to
learn HNP. The design decision was made to learn this from the proxy
binding acknowledgement message sent by the local mobility agent
(LMA) (See Section 6.7 in [RFC5213]). For this purpose, proxy
binding update and acknowledgement messages are extended with Home
Network Prefix Option to carry HNP and its length. However, how LMA
gets prefixes is not currently defined yet.
In Nemo MNP provisioning problem, MR, like MAG needs to get MNP, like
HNP from HA, like LMA in order for MR to advertise MNP on its
downstream link(s). Because of this similarity, this document
proposes to use the binding update/acknowledgement exchanged with HA
to carry MNPs similar to proxy binding update/acknowledgement
messages of Proxy Mobile IPv6.
NEMO home agents may be provisioned in different ways to provide MNPs
to MRs. In one deployment scenario, DHCPv6 prefix delegation (PD) is
proposed to be used for HA to get prefixes from DHCP server with HA
as the requesting router (RR) and DHCP server as the delegating
router (DR) [RFC3633]. AAA based deployment scenarios are also
possible. AAA server can assign and authorize prefixes to the MRs.
When MR is on the home link, MR gets authenticated first and then
gets the configuration settings including MNPs from the policy store.
This document describes an IKEv2 and EAP authentication based home
link configuration but other solutions are also possible. MR uses
IKEv2 exchanges to receive prefixes for its home link only and not
for MNPs.
Sarikaya & Xia Expires January 14, 2010 [Page 4]
Internet-Draft Prefix Delegation Support July 2009
MR requests MNP from HA using the binding update message as in the
visited link. A successful EAP authentication can trigger MR to send
BU with Home Link Exchange flag set to HA. HA MAY then use DHCPv6 PD
interactions to get MNPs and send them to MR using BA. HA has other
options such as AAA provisioning.
BU/BA based prefix delegation support differs from the solution
described in [I-D.ietf-nemo-dhcpv6-pd] in several aspects:
1. In [I-D.ietf-nemo-dhcpv6-pd] DHCPv6 PD is executed between MR as
Requesting Router (RR) and HA as Delegating Router (DR). BU/BA
based prefix delegation support offers different deployment
choices where DHCPv6 PD executed between HA as Requesting Router
(RR) and DHCP Server as Delegating Router (DR) is one choice and
AAA based prefix assignment and authorization is another choice.
2. Prefix(es) are exchanged in BU/BA using HNP Option in BU/BA based
prefix delegation support which is already used in Proxy Mobile
IPv6 [RFC5213]. In [I-D.ietf-nemo-dhcpv6-pd], prefix(es) are
carried in DHCP messages as defined in [RFC3633].
3. Because of (1) the MR in [I-D.ietf-nemo-dhcpv6-pd] becomes more
complicated as it needs to support DHCP on its upstream
interface.
4. Because of (2) visited link operation in
[I-D.ietf-nemo-dhcpv6-pd] is much more complicated.
[I-D.ietf-nemo-dhcpv6-pd] requires that DHCPv6 Relay agent
implemented on MR's upstream interface.
5. In terms of deployment, BU/BA based prefix delegation support
offers more flexibility and it is much simpler since DHCP server
could be on the same link as HA in which case HA only needs to
have DHCP Client. In case DHCP server is located on a different
network, HA can accomodate this having a DHCP Relay on the same
link or colocated with HA. MR does not have any requirement to
support DHCP on its upstream interface. HA may even be
provisioned by AAA in which case no DHCPv6 prefix delegation
server is needed.
6. In terms of deployment, the solution described in
[I-D.ietf-nemo-dhcpv6-pd] requires MR to support both DHCPv6
Client and Relay on its upstream interface. Also since DHCP
Relays can not be chained, HA has to support DHCPv6 Prefix
Delegation Server.
7. BU/BA based provisoning of MNPs offers another advantage compared
with the approach in [I-D.ietf-nemo-dhcpv6-pd] because it also
integrates the movement, i.e. when MR moves it registers its new
care-of address with BU/BA exchange and at the same time MR
receives the new MNPs.
Sarikaya & Xia Expires January 14, 2010 [Page 5]
Internet-Draft Prefix Delegation Support July 2009
2. Terminology
This document uses the terminology defined in [RFC3315], [RFC3633],
[RFC4886], [RFC3775], [RFC4306] and [RFC5213].
3. Nemo Prefix Delegation Using DHCPv6
We assume that the prefixes are managed by an authority that owns the
Home Network and subnets it into MNPs that it assigns to the MRs. An
MNP can be preassigned to the associated MR (e.g. manually or
automatically with a provisioning system), or assigned dynamically by
a server such as a DHCP Prefix Delegation server. In this
architecture, HA is the requesting router and the DHCP Server is the
delegating router. HA needs to be collocated with a DHCP Client to
solicit/request prefixes from the DHCP Server. The delegating router
could be a backend DHCP Server.
In a visited link, Mobile Router(MR) requests its Mobile Network
Prefixes from its Home Agents dynamically using Binding Update
message. When BU message contains one or more Home Network Prefix
Options, this triggers HA to start DHCPv6 PD with DHCP Server.
Figure 1 shows the process that a Mobile Router requests prefixes
from a Home Agent.
MR HA DHCP Server
| | |
|------->| | 1. BU with Home Network Prefix Option
| |------->| 2. DHCP Solicit
| |<-------| 3. DHCP Advertise
| |------->| 4. DHCP Request (MNP)
| |<-------| 5. DHCP Reply (MNP)
|<-------| | 6. BA with Home Network Prefix Option
Figure 1: Prefix Delegation in NEMO
1. Home Network Prefix option defined in [RFC5213] included in the
Binding Update(BU) and R flag in the binding update are used to
indicate to the Home Agent (HA) that the MR wishes to get new
prefixes assigned to it for use as Mobile Network Prefixes. MR
MUST set the R bit in Home Network Prefix option Section 7.1 to
indicate a prefix request.
2. DHCP Client at the HA initiates DHCP Solicit procedure to request
prefixes for the MN. HA creates and transmits a Solicit message
as described in sections 17.1.1, "Creation of Solicit Messages"
and 17.1.2, "Transmission of Solicit Messages" of RFC 3315. HA
Sarikaya & Xia Expires January 14, 2010 [Page 6]
Internet-Draft Prefix Delegation Support July 2009
creates an IA_PD and assigns it an IAID. HA assigns a different
IAID for each Home Network Prefix option it receives in a BU. HA
MUST include the IA_PD option in the Solicit message.
3. The DHCP server sends an Advertise message to HA in the same way
as described in section 17.2.2, "Creation and transmission of
Advertise messages" of RFC 3315.
4. HA uses the same message exchanges as described in section 18,
"DHCP Client-Initiated Configuration Exchange" of RFC 3315 to
obtain or update prefixes from a DHCP server. HA and the DHCP
server use the IA_PD Prefix option to exchange information about
prefixes in much the same way as IA Address options are used for
assigned addresses.
5. HA stores the prefix information including prefix lifetime it
received in the Reply message in the Prefix Table [RFC3963].
6. HA sends the prefixes received to MR in a Binding Acknowledgement
message. Home Network Prefix option defined in [RFC5213] is
included in the Binding Acknowledgement. One Home Network Prefix
option is included for each prefix received.
MR sets prefix length and home network prefix values to ALL_ZERO in
Home Network Prefix option of BU MR sends to HA. If MR bootstrapped
in the home link MR sets prefix length and home network prefix values
to the values received in the BA with Home Link Exchange Flag (C
flag) defined in [I-D.devarapalli-mext-mipv6-home-link] set as in
Section 3.1. In subsequent BUs, MR sets these fields to the values
received in the previous BA from HA.
When advertizing MNPs in Router Advertisement messages, MR MAY set
the prefix lifetime value to any value chosen at its own discretion.
The value may be bound to the lifetime of MR's binding with HA. The
value may also be set by a value taken from MR's policy profile.
Prefixes MUST be renewed by MR sending a BU that contains one or more
Home Link Prefix Options, see Section 3.2.
The specification requires that MNPs received in BUs be advertized
using RAs at the MR. The details of how the MNPs MR receives will be
sent in Router Advertisements will not be described in this document,
it is left out as an implementation detail.
3.1. Home Link Support
If MR boots in the home link, DHCPv6 prefix delegation operation is
as shown in Figure 2.
1. An MR boots up in the network. DHCP Server in Figure 2 is not
involved in the network entry procedures.
Sarikaya & Xia Expires January 14, 2010 [Page 7]
Internet-Draft Prefix Delegation Support July 2009
2. MR starts IKEv2 procedures [RFC4306] to establish a security
association with the HA [I-D.ietf-dime-mip6-split].
3. MR requests prefix(es) to configure its home link using
CFG_REQUEST payload in the message. MR includes a zero length
INTERNAL_IP6_SUBNET attribute in the CFG_REQUEST payload to
request a prefix. MR MUST include multiple instances of
INTERNAL_IP6_SUBNET attribute to request multiple prefixes to be
assigned by HA.
4. MR and HA authenticate each other using EAP.
5. If authentication succeeds HA is ready to assign prefix(es)
using DHCP PD.
6. HA includes the prefixes for MR's home link in the payload in
CFG_REPLY. CFG_REPLY contains more than one instances of
INTERNAL_IP6_SUBNET attribute each containing home link prefix
and its length. MR uses these prefixes for its home link.
7. MR sends BU with Home Link Exchange (C) Flag on and includes
Home Network Prefix Option in order to get MNPs from HA.
8. HA as the requesting router starts DHCPv6 Prefix Delegation
exchange with the Delegating Router. Step 2 in Figure 1.
9. Step 3 in Figure 1.
10. Step 4 in Figure 1.
11. Step 5 in Figure 1.
12. HA sends BA back to MR. BA has Home Link Exchange (C) Flag set
and it contains Home Network Prefix Option containing MNPs for
the mobile devices in the NEMO.
After Step 5, HA MAY execute DHCP PD procedures with DHCP Server to
request prefixes for MR's home link configuration. At Step 6, HA
sets CFG_REPLY INTERNAL_IP6_SUBNET attribute values to the prefixes
obtained from DHCP Server. HA MUST use a different IA_ID for the
prefixes to be used in home link configuration of MR.
MR HA DHCP Server AAA Server
|--------|----------------------| 1. Network Entry
|<-------|--------------------->| 2. SA establishment
|------->| | 3. Config Request
|<-------|--------------------->| 4. EAP Authentication
|<-------|----------------------| 5. EAP Success
|<-------| | 6. Config Reply
|------->| | | 7. BU with C flag and Q bit set
| |------->| | 8. DHCP Solicit
| |<-------| | 9. DHCP Advertise
| |------->| | 10. DHCP Request (MNP)
| |<-------| | 11. DHCP Reply (MNP)
|<-------| | | 12. BA with C flag and Q bit set
Sarikaya & Xia Expires January 14, 2010 [Page 8]
Internet-Draft Prefix Delegation Support July 2009
Figure 2: Home Link Prefix Delegation
IKEv2 based EAP authentication described above is informational. The
description serves to demonstrate a method of obtaining home network
prefixes for MR to HA link.
3.2. Prefix Renew Procedure
To extend MNP lifetimes, HA sends a Renew message to the DHCP server.
The server determines new lifetimes for the prefixes and returns the
prefix to HA in a Reply message. The DHCP server MAY add new
prefixes to the MR for renumbering in its Reply message.
Prefix renew request can also be received from MR. MR sends BU with
HNP set to the prefix already assigned to HA. The Release (R) bit
MUST not be set in HNP Option. If this happens, HA sends a Renew
message to the DHCP server to renew the MNP. After receiving the
Reply message, HA sends a BA with HNP set to the prefix assigned and
with Q bit set to 1. Setting Q bit in BA indicates reception of a
renewed prefix.
3.3. Prefix Release Procedure
Prefixes can be released in two ways, prefix aging or DHCP release
procedure. In the former way, a prefix SHOULD not be used by an MR
when the prefix ages, and the DHCP Server can delegate it to another
MR. A prefix lifetime is delivered from the DHCPv6 server to the
requesting router (HA) through DHCP IA_PD Prefix option [RFC3633] and
RA Prefix Information option [RFC4861].
Mobile Router can initiate the prefix release procedure based on
deregistration of the nodes in the mobile network. Figure 3 can be
used to release prefixes.
MR HA DHCPS
-->| | | 1. Deregistration event
|------->| | 2. BU with R bit set
| |------->| 3. DHCP Release (MNP)
| |<-------| 4. DHCP Reply
|<-------| | 2. BA with R bit set
| | |
Figure 3: Prefix release
HA MUST release the mobile network prefix when MR signals to do so.
The prefix release signaling is as shown in Figure 3.
Sarikaya & Xia Expires January 14, 2010 [Page 9]
Internet-Draft Prefix Delegation Support July 2009
1. A local mobile node (LMN) or visiting mobile node (VMN) leaves
the mobile network. If such a node was the only user for MNP or
if all LMNs/VMNs left the mobile network then MR starts MNP
release procedure.
2. MR sends a BU with HNP option to HA. In the HNP option, MR MUST
set the R bit to one.
3. HA receives BU and checks the R bit. If R bit is set, HA as the
requesting router sends DHCPv6 Release message to the delegating
router. HA MUST include the mobile network prefix to be released
in IA_PD by copying it from the home network prefix option of BU
it received from MR.
4. DR sends back DHCPv6 Rely message confirming the release.
5. HA sends BA to confirm the prefix release. MR MUST stop
advertizing the MNP in the mobile network.
4. Nemo Prefix Delegation Using Other Means
Prefixes may be assigned and authorized to MR using means other than
DHCPv6 Prefix Delegation. AAA server techniques may provision
prefixes at the home agent.
If other means are used the scenarios similar to the ones described
in Section 3 can be used. In the scenarios, DHCP interactions MUST
be replaced by AAA interactions if AAA based prefix authorization is
used. If the prefixes are provisioned at the HA then DHCP
interactions MUST be replaced by corresponding internal home agent
operations on the prefixes.
5. Prefix to Interface Mapping at the MR
This section describes management of multiple prefixes corresponding
to multiple downstream interfaces of MR.
This specification requires a separate BU/BA exchange for each set of
MNPs assigned to a given downstream interface of MR in order to
facilitate mapping of MNPs to MR interfaces. MR can track BUs and
their corresponding BAs using the mechanisms described in [RFC3775].
In order to allow better synchronization between MR and HA, A bit
defined in Figure 4 in home network prefix mobility option can be
used. MR MUST set the A-bit if MR wants to receive all MNPs
delegated to MR in the same BA message. HA MUST send all MNPs
delegated to this MR in the BA message. HA MUST set A-bit in the BA.
If A-bit is not set, HA MUST look at the other bits and reply to
prefix requests or release requests. If A-bit is set the other bits
Sarikaya & Xia Expires January 14, 2010 [Page 10]
Internet-Draft Prefix Delegation Support July 2009
are ignored.
6. Miscellaneous Considerations
6.1. Rapid Commit Option
4-way exchange between HA as requesting router (RR) and DHCP server
as delegating router (DR) in Figure 1 and Figure 2 MAY be reduced
into a two message exchange using the Rapid Commit option [RFC3315].
HA includes a Rapid Commit option in the Solicit message. DR then
sends a Reply message containing one or more prefixes.
6.2. Implicit/Explicit Modes
If MRs operate in implicit mode then MR MUST not include Mobile
Network Prefix option in BUs nor Home Network Prefix Option. This is
because MR and HA will run a dynamic routing protocol to manage
prefixes. HA MAY use DHCPv6 prefix delegation as requesting router
to request prefixes for the mobile network from the DHCP server
acting as delegating router.
NEMO explicit mode is recommended to use all aspects of the protocol
defined in this document.
6.3. Advertising Delegated Prefixes
HA should broadcast the prefix(es) dynamically upstream as the route
information of all the MRs connected to this HA. This might cause
high routing protocol traffic (IGMP, OSPF, etc.) due to large number
of prefixes. To solve the problem, route aggregation SHOULD be used.
For example, each HA can be assigned a /48 or /32 prefix (aggregate
prefix) while each interface of MR can be assigned a /64 prefix. The
/64 prefix is an extension of /48 one, for example, an HA's /48
prefix is 3FFE:FFFF:0::/48, an interface of MR is assigned 3FFE:FFFF:
0:2::/64 prefix. The HA only broadcasts it's /48 or /32 prefix
information to Internet.
6.4. DHCP Server Issues
The delegating router should normally be located in Home Agent's
network. In that case HA needs only a DHCP Client to communicate
with DHCP server.
If the delegating router is not local HA needs DHCP Relay Agent to
forward multicast packets to DHCP server. DHCP Relay Agent should be
located in the same link as HA and it needs to be configured with the
address of DHCP server.
Sarikaya & Xia Expires January 14, 2010 [Page 11]
Internet-Draft Prefix Delegation Support July 2009
7. Message Formats
This document requires CFG_REQUEST and CFG_REPLY defined in [RFC4306]
contain one or more INTERNAL_IP6_SUBNET attributes.
This document requires Binding Update and Binding Acknowledgement
messages defined in [RFC3775] to contain one or more Home Network
Prefix Options defined in [RFC5213].
This document requires Binding Update and Binding Acknowledgement
messages defined in [RFC3775] to contain the Home Link Exchange (C)
flag defined in [I-D.devarapalli-mext-mipv6-home-link] when BU and
BAs are exchanged at the home link. C flag MUST be set to one when
MR is at the home link. C flag MUST be set to zero when BU and BAs
are exchanged at the visited links.
7.1. Home Network Prefix Option
This section defines modifications to Home Network Prefix Option
defined in [RFC5213].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved |A|Q|R| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Home Network Prefix Option
Sarikaya & Xia Expires January 14, 2010 [Page 12]
Internet-Draft Prefix Delegation Support July 2009
Type 22
Length, Prefix Length and Home Network Prefix as defined in RFC 5213
Reserved This is a 5-bit field which is unused
Release (R) The R bit is set to release a prefix
Request (Q) The Q bit is set to request a prefix
A bit is used to request all the MNPs delegated to MR from HA.
8. Security Considerations
This document does not by itself introduce any security issues.
9. IANA Considerations
This specification defines 3 flags in the reserved field of Home
Network Prefix mobility option defined in [RFC5213].
10. Acknowledgements
This revision (-02) was made based on the comments by Arnaud Ebalard
and communicated to us in French. Many thanks Arnaud.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Sarikaya & Xia Expires January 14, 2010 [Page 13]
Internet-Draft Prefix Delegation Support July 2009
[RFC4886] Ernst, T., "Network Mobility Support Goals and
Requirements", RFC 4886, July 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[I-D.ietf-dime-mip6-split]
Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
Agent to Diameter Server Interaction",
draft-ietf-dime-mip6-split-17 (work in progress),
April 2009.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[I-D.devarapalli-mext-mipv6-home-link]
Devarapalli, V., Kant, N., and H. Lim, "Mobile IPv6 Home
Link Operation over SDO point-to-point links",
draft-devarapalli-mext-mipv6-home-link-01 (work in
progress), February 2008.
[I-D.ietf-nemo-dhcpv6-pd]
Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for
NEMO", draft-ietf-nemo-dhcpv6-pd-03 (work in progress),
December 2007.
11.2. Informative references
Sarikaya & Xia Expires January 14, 2010 [Page 14]
Internet-Draft Prefix Delegation Support July 2009
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires January 14, 2010 [Page 15]