draft-ietf-mext-nemo-pd-04.txt   draft-ietf-mext-nemo-pd-05.txt 
Mobility Extensions for IPv6 R. Droms Mobility Extensions for IPv6 R. Droms
(MEXT) P. Thubert (MEXT) P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track F. Dupont Intended status: Standards Track F. Dupont
Expires: September 9, 2010 ISC Expires: December 30, 2010 ISC
W. Haddad W. Haddad
Ericsson Ericsson
CJ. Bernardos CJ. Bernardos
UC3M UC3M
March 8, 2010 June 28, 2010
DHCPv6 Prefix Delegation for NEMO DHCPv6 Prefix Delegation for NEMO
draft-ietf-mext-nemo-pd-04 draft-ietf-mext-nemo-pd-05
Abstract Abstract
One aspect of network mobility support is the assignment of a prefix One aspect of network mobility support is the assignment of a prefix
or prefixes to a Mobile Router (MR) for use on the links in the or prefixes to a Mobile Router (MR) for use on the links in the NEMO.
Mobile Network. DHCPv6 prefix delegation can be used for this DHCPv6 prefix delegation can be used for this configuration task.
configuration task.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 30, 2010.
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 September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Application of DHCPv6 prefix delegation to mobile networks 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4
for delegation of home prefixes . . . . . . . . . . . . . . . 4 3.1. Exchanging DHCPv6 messages when MR is not at home . . . . 5
3.1. When the MR uses DHCPv6 . . . . . . . . . . . . . . . . . 5 3.1.1. Relay agent configuration . . . . . . . . . . . . . . 6
3.2. Use of MR-HA tunnel for DHCPv6 messages . . . . . . . . . 6 3.1.2. Transmission of DHCPv6 messages . . . . . . . . . . . 7
3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages . . 7 3.1.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 7
3.3.1. Relay agent configuration . . . . . . . . . . . . . . 8 3.2. Exchanging DHCPv6 messages when MR is at home . . . . . . 7
3.3.2. Transmission of DHCPv6 messages . . . . . . . . . . . 9 3.3. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 8
3.3.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 9 3.4. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 9
3.4. Exchanging DHCPv6 messages when MR is at home . . . . . . 9 3.5. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 9
3.5. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
3.6. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
3.7. Location of DHCPv6PD Delegating Router function . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
3.8. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 12 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 11
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Revision -05 . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
One aspect of network mobility support is the assignment of a prefix One aspect of network mobility support is the assignment of a prefix
or prefixes to a Mobile Router for use on the links in the Mobile or prefixes to a Mobile Router for use on the links in the NEMO.
Network. DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used for this
for this configuration task. configuration task.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
The following terms used in this document are defined in the IPv6 The following terms used in this document are defined in the IPv6
Addressing Architecture document [RFC4291]: Addressing Architecture document [RFC4291]:
link-local unicast address Link-Local Unicast address
link-local scope multicast address Link-Local Scope Multicast address
The following terms used in this document are defined in the mobile The following terms used in this document are defined in the mobile
IPv6 specification [RFC3775]: IPv6 specification [I-D.ietf-mext-rfc3775bis]:
home agent (HA) Home Agent (HA)
home link Home Link
The following terms used in this document are defined in the Mobile The following terms used in this document are defined in the Mobile
Network terminology document [RFC4885]: Network terminology document [RFC4885]:
Mobile Router (MR) Mobile Router (MR)
Mobile Network (NEMO) Mobile Network (NEMO)
Mobile Network Prefix (MNP) Mobile Network Prefix (MNP)
The following terms used in this document are defined in the DHCPv6 The following terms used in this document are defined in the DHCPv6
[RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications:
delegating router (DR; acts as a DHCPv6 server) Delegating Router (DR; acts as a DHCPv6 server)
requesting router (RR; acts as a DHCPv6 client) Requesting Router (RR; acts as a DHCPv6 client)
DHCPv6 relay agent (DRA) DHCPv6 Relay Agent (DRA)
The following acronym is used in this document: The following acronym is used in this document:
DHCPv6PD: DHCPv6 prefix delegation DHCPv6PD: DHCPv6 Prefix Delegation
3. Application of DHCPv6 prefix delegation to mobile networks for 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes
delegation of home prefixes
The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol
[RFC3775] to enable network mobility. In this extension, an MR uses [I-D.ietf-mext-rfc3775bis] to enable network mobility. In this
the mobile IPv6 protocol to establish and maintain a session with its extension, an MR uses the mobile IPv6 protocol to establish and
HA, and uses bidirectional tunneling between the MR and HA to provide maintain a session with its HA, and uses bidirectional tunneling
a path through which nodes attached to links in the Mobile Network between the MR and HA to provide a path through which nodes attached
can maintain connectivity with nodes not in the Mobile Network. to links in the NEMO can maintain connectivity with nodes not in the
NEMO.
The requirements for NEMO [RFC4885] include the ability of the MR to The requirements for NEMO [RFC4885] include the ability of the MR to
receive delegated prefixes that can then be assigned to links in the receive delegated prefixes that can then be assigned to links in the
Mobile Network. DHCPv6PD can be used to meet this requirement for NEMO. DHCPv6PD can be used to meet this requirement for prefix
prefix delegation. delegation.
To use DHCPv6PD for Mobile Networks, the HA assumes the role of
either the DR or a DHCPv6 relay agent and the MR assumes the role of
the RR. Throughout the remainder of this document, the HA will be
assumed to be acting as a DHCPv6PD DR or relay agent and the MR will
be assumed to be acting as a RR.
If the HA is acting as relay agent, some other device acts as the DR.
For example, the server providing DHCPv6 service in the home network
might also provide NEMO DHCPv6PD service. Or, a home network with
several HAs might configure one of those HAs as a DHCPv6PD server
while the other HAs act as relay agents.
The HA and MR exchange DHCPv6PD protocol messages through the tunnel To use DHCPv6PD for NEMOs, the HA assumes the role of the DR, and the
connecting them (as specified in RFC3775). The tunnel acts as the MR assumes the role of the RR when located at home, and the role of a
link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD DRA co-located with the RR function, when the MR is away from home.
specification. See Figure 1 for different possible deployment
topologies.
---- /-----------\ ---- When the MR is not at home, the HA and MR exchange DHCPv6PD protocol
| MR |-----| Internet |-----| HA | messages as specified in RFC3775bis. This means that messages sent
|(RR)| \-----------/ |(DR)| by the MR include the Home Address destination option and messages
---- ---- sent by the HA make use of a Routing Header type 2. See Figure 1 for
the deployment topologies when the MR is at home and when it is
visiting a foreign network.
---- /-----------\ ----- ------ ---- ----
| MR |-----| Internet |-----| HA |-----|DHCPv6| | MR |----------------| HA |
|(RR)| \-----------/ |(DRA)| |Server| |(RR)| (home network) |(DR)|
---- ----- ------ ---- ----
----- /-----------\ ----- ----- /-----------\ ----
| MR |----| Internet |-----| HA | | MR |----| Internet |-----| HA |
|(RR) | \-----------/ |(DR) | |(RR) | \-----------/ |(DR)|
|(DRA)| ----- |(DRA)| ----
----- -----
(visited network)
Figure 1: Different topologies of the application of DHCPv6PD to NEMO Figure 1: Deployment topologies of the use of DHCPv6PD for delegation
for delegation of MNPs of MNPs
The DHCPv6PD server is provisioned with prefixes to be assigned using The DHCPv6PD server is provisioned with prefixes to be assigned using
any of the prefix assignment mechanisms described in the DHCPv6PD any of the prefix assignment mechanisms described in the DHCPv6PD
specifications. Other updates to the HA data structures required as specifications. Other updates to the HA data structures required as
a side effect of prefix delegation are specified by the particular a side effect of prefix delegation are specified by the particular
network mobility protocol. For example, in the case of Basic Network network mobility protocol. For example, in the case of Basic Network
Mobility Support [RFC3963], the HA would add an entry in its binding Mobility Support [RFC3963], the HA would add an entry in its binding
cache registering the delegated prefix to the MR to which the prefix cache registering the delegated prefix to the MR to which the prefix
was delegated. was delegated.
3.1. When the MR uses DHCPv6 3.1. Exchanging DHCPv6 messages when MR is not at home
The MR initiates a DHCPv6 message exchange for prefix delegation
whenever it establishes an MR-HA tunnel to its HA. If the MR does
not have any active delegated prefixes (with unexpired leases), the
MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message
as described in section 17 of RFC 3315 and section 12.1 of RFC 3633.
Once the MR has been delegated a set of prefixes from the HA, the MR
sends a new Binding Update including the delegated prefixes, carried
in Mobile Network Prefix options (see Figure 2). Note that this
requires a minor modification to the NEMO Basic Support protocol as
described in RFC 3963. RFC 3963 does not assume the MR can change
from implicit to explicit BU signaling mode, while this specification
requires the MR to first perform a MIPv6 registration to the HA
providing DHCPv6PD services (via implicit signaling, no MNP carried
in the BU), then obtain a set of delegated prefixes via DHCPv6PD, and
then send a new BU to the Home Agent, now carrying the delegated
prefixes as Mobile Network Prefixes (explicit signaling mode).
In case the MR has one or more active delegated prefixes, the MR
initiates a DHCPv6 message exchange with a DHCPv6 Rebind message as
described in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633.
In this case, only one BU signaling sequence is required.
MR HA
(RR) (DR)
| Binding Update |
|------------------------>|
| (HoA, CoA) |
| |
| Binding Ack |
|<------------------------|
| |
| DHCPv6 Solicit |
|--=====================->|
| |
| DHCPv6 Advertise |
|<-=====================--|
| |
| DHCPv6 Request |
|--=====================->|
| |
| DHCPv6 Reply |
|<-=====================--|
| (Mobile Network Prefix) |
| |
| Binding Update |
|------------------------>|
| (HoA, CoA, MNP) |
| |
| Binding Ack |
|<------------------------|
| |
Figure 2: Signaling sequence for the case the HA acts as DHCPv6PD
Delegating Router
3.2. Use of MR-HA tunnel for DHCPv6 messages
The DHCPv6 specification requires the use of link-local unicast and
link-local scope multicast addresses in DHCPv6 messages (except in
certain cases as defined in section 22.12 of the DHCPv6
specification). Section 10.4.2 of the mobile IPv6 specification
describes forwarding of intercepted packets, and the third paragraph
of that section begins:
However, packets addressed to the mobile node's link-local address The case when the MR is away from home is described in this section.
MUST NOT be tunneled to the mobile node. Section 3.2 describes the protocol operation for the case the MR is
attached to its home link.
The DHCPv6 messages exchanged between the HA and the MR originate The MR MUST register at the HA (i.e. by sending a Binding Update to
only with the HA and the MR, and therefore are not "intercepted the HA) before initiating a DHCPv6 message exchange for prefix
packets" (i.e. the sender of the packets is a third node on the home delegation. Since the MR may not have yet requested any prefixes,
link) and may be sent between the HA and the MR through the tunnel. implicit BU signaling MUST be used. While using the NEMO Basic
Support protocol with DHCPv6PD, implicit BU signaling is the default
mode of operation.
Even though the MR-HA tunnel is a point to point connection, the MR If the MR does not have any active delegated prefixes (with unexpired
SHOULD use multicast DHCPv6 messages as described in RFC 3315 over leases), the MR initiates a DHCPv6 message exchange with a DHCPv6
that tunnel. Solicit message as described in section 17 of RFC 3315 and section
11.1 of RFC 3633. The Delegating Router at the HA responds with an
Advertise message. Then, the MR requests a set of prefixes by
sending a Request message. The DR includes the delegated prefixes in
a Reply message. Note that in this case, the MR has previously sent
a BU to the HA without knowing yet the set of prefixes that it can
use as MNPs. The HA, upon reception of the implicit BU from the MR,
selects (in case this was not pre-configured already) the prefixes
that would then be delegated to the MR via DHCPv6PD. The HA, once
the DHCPv6 signaling has been completed, adds an entry in its binding
cache including the delegated prefixes.
3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages In case the MR has one or more active delegated prefixes -- as for
example if the MR reboots or the MNP(s) currently used by the is
about to expire -- the MR initiates a DHCPv6 message exchange with a
DHCPv6 Rebind message as described in section 18.1.2 of RFC 3315 and
section 12.1 of RFC 3633. In this case, only one BU signaling
sequence is required.
A DHPCv6 relay agent function [RFC3315] can be used as an alternative A DHPCv6 relay agent function [RFC3315] is used at the MR. This
to multicast DHCPv6 messages over the tunnel between the MR and the relay agent function is co-located in the MR with the DHCPv6 client
HA. In this configuration, the relay agent function is co-located in function (see Figure 2). The DHCPv6 signaling between the MR and the
the MR with the DHCPv6 client function (see Figure 3. Rather than HA are exchanged between the DHCPv6 relay agent in the MR and the
using multicast to send DHCPv6 messages through the tunnel to the DHCPv6 server on the HA. DHCPv6 messages from the MR to the HA are
DHCPv6 server, the DHCPv6 client in the MR hands any outbound DHCPv6 unicast packets sent from the global unicast HoA of the MR to the
messages to the co-located relay agent. Responses from the DHCPv6 global unicast address of the HA, and therefore the Home Address
server are delivered to the relay agent function in the MR, which destination option is. DHCPv6 replies from the HA to the MR are sent
extracts the encapsulated message and delivers it to the DHCPv6 using the Routing Header type 2, as specified in RFC3775bis. The
client in the MR. DHCPv6 client in the MR hands any outbound DHCPv6 messages to the co-
located relay agent. Responses from the DHCPv6 server are delivered
to the relay agent function in the MR, which extracts the
encapsulated message and delivers it to the DHCPv6 client in the MR.
MR MR
(RR) HA (RR) HA
(DRA) (DR) (DRA) (DR)
| Binding Update | | Binding Update |
|------------------------>| |------------------------>|
| (HoA, CoA) | | (HoA, CoA) |
| | | |
| Binding Ack | | Binding Ack |
|<------------------------| |<------------------------|
-- | | -- | |
/ \ | | / \ | |
skipping to change at page 8, line 30 skipping to change at page 6, line 34
| DHCPv6 Advertise | | DHCPv6 Advertise |
-- |<-=====================--| -- |<-=====================--|
/ \ | | / \ | |
\ *| DHCPv6 Request | \ *| DHCPv6 Request |
DHCPv6 -- >|--=====================->| DHCPv6 -- >|--=====================->|
Request | | Request | |
| DHCPv6 Reply | | DHCPv6 Reply |
|<-=====================--| |<-=====================--|
| (Mobile Network Prefix) | | (Mobile Network Prefix) |
| | | |
| Binding Update |
|------------------------>|
| (HoA, CoA, MNP) |
| |
| Binding Ack |
|<------------------------|
| |
Figure 3: Signaling sequence for the case a DHCPv6 relay agent is co- Figure 2: Signaling sequence when the MR is not at home
located in the MR
3.3.1. Relay agent configuration Note that an MR using DHCPv6PD to obtain the set of prefixes to be
used as MNPs cannot derive its HoA from an MNP (as the MR does not
know them before registering to the HA), unless it obtains the
prefixes while at attached to the home link. Therefore, the MR is
assigned its HoA from the prefix on its Home Link.
3.1.1. Relay agent configuration
The use of the relay agent function in the MR allows the MR to The use of the relay agent function in the MR allows the MR to
unicast DHCPv6 messages to the DHCPv6 server. The relay agent must unicast DHCPv6 messages to the DHCPv6 server. The relay agent MUST
be configured with the address of the DHCPv6 server or another DHCPv6 be configured with the address of the DHCPv6 server. For the
relay agent that will forward message on to a DHCPv6 server. For the
purposes of NEMO, the relay agent assumes that the HA for the MR purposes of NEMO, the relay agent assumes that the HA for the MR
hosts the next hop in the path the to the DHCPv6 server: either the hosts the DHCPv6 server. Therefore, the MR MUST configure the DHCPv6
DHCPv6 server or a relay agent that will forward message to the relay agent to forward DHCPv6 messages to the HA.
DHCPv6 server. Therefore, if the MR acts as a DHCPv6 relay agent,
the MR MUST configure the DHCPv6 relay agent to forward DHCPv6
messages to the HA.
3.3.2. Transmission of DHCPv6 messages 3.1.2. Transmission of DHCPv6 messages
In this configuration, i.e., a DHCPv6 relay agent is used and co- When the DHCPv6 client in the MR sends a message, it hands the
located in the MR, when the DHCPv6 client in the MR sends a message, message to the DHCPv6 relay agent in the MR. The way in which the
it hands the message to the DHCPv6 relay agent in the MR. The way in message is passed to the DHCP relay agent is beyond the scope of this
which the message is passed to the DHCP relay agent is beyond the document. The relay agent encapsulates the message from the client
scope of this document. The relay agent encapsulates the message according to RFC 3315 in a Relay-forward message and sends the
from the client according to RFC 3315 in a Relay-forward message and resulting DHCPv6 message to the HA. The relay agent sets the fields
sends the resulting DHCPv6 message to the HA. The relay agent sets in the Relay-forward message as follows:
the fields in the Relay-forward message as follows:
msg-type RELAY-FORW msg-type RELAY-FORW
hop-count 1 hop-count 1
link-address A non-link-local address from the MR interface (e.g., link-address A non-link-local address from the MR egress interface
home address or, in case the HoA belongs to the MNP, (e.g., home address) used to send packets between the
the address of the MR's egress interface of the MR HA and the MR
when attached to the Home Link) of the tunnel between
the HA and MR
peer-address A non-link-local address from the MR interface (e.g., peer-address A non-link-local address from the MR egress interface
home address or, in case the HoA belongs to the MNP, (e.g., home address) used to send packets between the
the address of the MR's egress interface of the MR HA and the MR
when attached to the Home Link) of the tunnel between
the HA and MR
options MUST include a "Relay Message option" [RFC3315]; MAY options MUST include a "Relay Message option" [RFC3315]; MAY
include other options added by the relay agent. include other options added by the relay agent.
3.3.3. Receipt of DHCPv6 messages 3.1.3. Receipt of DHCPv6 messages
In this configuration, messages from the DHCPv6 server will be Messages from the DHCPv6 server will be returned to the DHCPv6 relay
returned to the DHCPv6 relay agent, with the message for the DHCPv6 agent, with the message for the DHCPv6 client encapsulated in the
client encapsulated in the Relay Message option [RFC3315] in a Relay- Relay Message option [RFC3315] in a Relay-reply message. The relay
reply message. The relay agent function extracts the message for the agent function extracts the message for the client from the Relay
client from the Relay Message option and hands the message to the Message option and hands the message to the DHCPv6 client in the MR.
DHCPv6 client in the MR. The way in which, the message is passed to The way in which the message is passed to the client is beyond the
the client is beyond the scope of this document. scope of this document.
3.4. Exchanging DHCPv6 messages when MR is at home 3.2. Exchanging DHCPv6 messages when MR is at home
When the MR is on its home link, the HA uses the home link to When the MR is on its home link, the HA uses the home link to
exchange DHCPv6PD messages with the MR. It is the responsibility of exchange DHCPv6PD messages with the MR (Figure 3). In this case, the
the implementation to determine when the MR is on its home link and DHCPv6 co-located relay function is disabled. It is the
to avoid use of any existing tunnel. responsibility of the implementation to determine when the MR is on
its home link. The Home Link Detection mechanism is described in the
section 11.5.2 of RFC3775bis.
3.5. Selecting an HA that provides DHCPv6PD MR HA
(RR) (DR)
| |
| DHCPv6 Solicit |
|------------------------>|
| |
| DHCPv6 Advertise |
|<------------------------|
| |
| DHCPv6 Request |
|------------------------>|
| |
| DHCPv6 Reply |
|<------------------------|
| (Mobile Network Prefix) |
| |
Figure 3: Signaling sequence for the case the HA is at home
3.3. Selecting an HA that provides DHCPv6PD
Not all nodes that are willing to act as an HA are required to Not all nodes that are willing to act as an HA are required to
provide DHCPv6PD. Therefore, when selecting an HA, an MR that provide DHCPv6PD. Therefore, when selecting an HA, an MR that
requires DHCPv6PD service must identify an HA that will provide the requires DHCPv6PD service must identify an HA that will provide the
service. The MR can determine if an HA provides DHCPv6PD by service. The MR can determine if an HA provides DHCPv6PD by
initiating a DHCPv6 message exchange in which the MR requests initiating a DHCPv6 message exchange (i.e. sending a Solicit message)
delegated prefix(es). If the HA does not respond or responds but in which the MR requests delegated prefix(es). If the HA does not
does not delegate any prefix(es) in its response, the MR assumes that respond or responds but does not delegate any prefix(es) in its
the HA does not provide DHCPv6PD service. The MR continues to query response, the MR assumes that the HA does not provide DHCPv6PD
all candidate HAs until it finds an HA that provides DHCPv6PD. Note service. The MR continues to query all candidate HAs until it finds
that in this particular case, the MR has also to setup a tunnel with an HA that provides DHCPv6PD. Note that in this particular case and
each HA (this requires the MR to perform an MIPv6 registration) it if the MR is away from home, the MR has to have already performed an
queries. MIPv6 registration with the HA it queries.
Querying an HA to determine if it provides DHCPv6PD requires a small Querying an HA to determine if it provides DHCPv6PD requires a small
modification to the operation of DHCPv6 as described in RFC 3315. modification to the operation of DHCPv6 as described in RFC 3315.
Under normal circumstances, a host will continue to send DHCPv6 Under normal circumstances, a host will continue to send DHCPv6
Solicit messages until it receives a response (see Section 17 of RFC Solicit messages until it receives a response (see Section 17 of RFC
3315). However, an HA may choose not to respond to the Solicit 3315). However, an HA may choose not to respond to the Solicit
messages from the MR because the HA does not provide DHCPv6. messages from the MR because the HA does not provide DHCPv6.
Therefore, when querying an HA to determine if the HA provides Therefore, when querying an HA to determine if the HA provides
DHCPv6PD service, the MR MUST discontinue sending Solicit messages to DHCPv6PD service, the MR SHOULD discontinue sending Solicit messages
the HA after sending 6 Solicit messages, and conclude that the HA to the HA after sending 6 Solicit messages, and conclude that the HA
will not provide DHCPv6PD service. Sending 6 queries provides enough will not provide DHCPv6PD service. Sending 6 queries provides enough
reliability for scenarios in which the wireless connectivity is lost reliability for scenarios in which the wireless connectivity is lost
for a short period after sending the first BU message. for a short period after sending the first BU message.
It is recommended that the MR uses a sequential probing of the HAs It is recommended that the MR uses a sequential probing of the HAs
for DHCPv6PD service. for DHCPv6PD service.
3.6. Minimizing DHCPv6PD messages 3.4. Minimizing DHCPv6PD messages
DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
option [RFC3315] to provide DHCPv6 prefix delegation with a two
message exchange between the mobile node and the DHCPv6PD DR.
3.7. Location of DHCPv6PD Delegating Router function
Support of DHCPv6PD for a Mobile Network is optional.
The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol
or other out-of-band communication to add routing information for
delegated prefixes into the provider edge router" (section 14 of RFC
3633). If the DHCPv6PD DR function is implemented in the HA for the
MR, no relay agent function is required.
It may be desirable to use a single DR to manage RRs in a network
with multiple HAs. In this scenario, the HAs will act as DHCP relay
agents, forwarding messages between the RRs and the DR.
The use of the DHCPv6 relay agent function with DHCPv6PD requires
that there be some mechanism through which routing information for
the delegated prefixes can be added to the appropriate routing
infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA
SHOULD add a route to the delegated prefix and advertise that route
after receiving a binding update for the prefix from the RR
[RFC3963]. Note that such binding update is received after the first
binding update message which is sent by the MR in order to set-up the
bidirectional tunnel (see Figure 4).
MR HA DHCPv6
(RR) (DRA) Server
| Binding Update | |
|------------------------>| |
| (HoA, CoA) | |
| | |
| Binding Ack | |
|<------------------------| |
| | |
| DHCPv6 Solicit | DHCPv6 Solicit |
|--=====================->|------------------------>|
| | |
| DHCPv6 Advertise | DHCPv6 Advertise |
|<-=====================--|<------------------------|
| | |
| DHCPv6 Request | DHCPv6 Request |
|--=====================->|------------------------>|
| | |
| DHCPv6 Reply | DHCPv6 Reply |
|<-=====================--|<------------------------|
| (Mobile Network Prefix) | (Mobile Network Prefix) |
| | |
| Binding Update | |
|------------------------>| |
| (HoA, CoA, MNP) | ( HA starts ) |
| | ( advertising ) |
| Binding Ack | ( routes to ) |
|<------------------------| ( the MNP ) |
| | |
Figure 4: Signaling sequence for the case the HA acts as DHCPv6 relay
agent
In particular, if the MR uses NEMO explicit mode, then it must add
the delegated prefix to the prefix list in the Binding Update
messages. If the binding cache is cleared before the prefix valid
lifetime, the MR might bind that prefix again using explicit mode,
till the lifetime expires.
In implicit mode, the HA must save the delegated prefix with the
binding cache entry (BCE) of the Mobile Router. When the BCE is
cleared, the HA loses the information about the delegated prefix.
Because the MR will use DHCPv6 when it reestablishes its tunnel to
the HA (see Section 3.1), the HA will be able to add the delegated
prefix back to the BCE.
At the time this document was written, one way in which a DR can
explicitly notify a relay agent about delegated prefixes, is to use
the "DHCP Relay Agent Assignment Notification Option"
[I-D.ietf-dhc-dhcpv6-agentopt-delegate].
Another alternative, if the RR is part of the same administrative
domain as the home network to which it is attached through the HA,
and the RR can be trusted, the RR can use a routing protocol like
OSPF to advertise any delegated prefixes.
NEMO explicit mode is recommended to take advantage of the function DHCPv6PD in a NEMO can be combined with the Rapid Commit option
already defined for NEMO. [RFC3315] to provide DHCPv6 prefix delegation with a two message
exchange between the mobile router and the DHCPv6PD DR.
3.8. Other DHCPv6 functions 3.5. Other DHCPv6 functions
The DHCPv6 messages exchanged between the MR and the HA may also be The DHCPv6 messages exchanged between the MR and the HA MAY also be
used for other DHCPv6 functions in addition to DHCPv6PD. For used for other DHCPv6 functions in addition to DHCPv6PD. For
example, the HA may assign global addresses to the MR and may pass example, the HA MAY assign global addresses to the MR and MAY pass
other configuration information such as a list of available DNS other configuration information such as a list of available DNS
recursive name servers [RFC3646] to the MR using the same DHCPv6 recursive name servers [RFC3646] to the MR using the same DHCPv6
messages as used for DHCPV6PD. messages as used for DHCPV6PD.
The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR The HA MAY act as a DHCPv6 relay agent for Mobile Nodes while it acts
for MRs. as a DR for MRs.
4. Security Considerations 4. Security Considerations
This document describes the use of DHCPv6 for prefix delegation in This document describes the use of DHCPv6 for prefix delegation in
Mobile Networks. It does not introduce any additional security NEMO. In addition to the security considerations for DHCPv6
considerations for DHCPv6 beyond those described in the "Security described in the "Security Considerations" section of the DHCPv6 base
Considerations" section of the DHCPv6 base specification [RFC3315] specification [RFC3315] and the "Security Considerations" of the
and the "Security Considerations" of the DHCPv6 Prefix Delegation DHCPv6 Prefix Delegation specification [RFC3633], there are two
specification [RFC3633]. aspects that need to be considered.
The use of DHCPv6, as described in this document, requires only
message integrity protection, which can be provided by the mobile
network infrastructure between the MR and the HA.
If the network infrastructure connecting the various communicating
nodes does not provide message integrity and source authentication
for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6
authentication as described in section "Authentication of DHCP
messages" of the DHCPv6 specification [RFC3315], to guard against
attacks mounted through prefix delegation.
If the HA and DHCPv6 PD functions are not provided by the same First, the NEMO Basic Support specification requires the HA to
physical node, the HA will act as a DHCPv6 relay agent between the MR prevent an MR from claiming MNPs belonging to another MR. Upon
and the DHCPv6 server. In this scenario, the mobile network reception of an implicit BU from an MR, the HA MUST only add prefixes
infrastructure will only protect the DHCPv6 traffic between the RR into the MR's Binding Cache Entry if the MR has a valid DHCPv6 Prefix
(MR) and the relay agent (HA). The following text, based on Section Delegation lease for said prefixes. If the MR does not have a valid
21.1 of RFC 3315, describes how appropriate security can be provided DHCPv6 Prefix Delegation lease, the HA MUST NOT add any prefixes into
between a DHCPv6 relay agent and server. the MR's Binding Cache Entry. Upon the MR obtaining a valid DHCPv6
Prefix Delegation lease for a given set of prefixes, the HA MUST add
these prefixes to the MR's Binding Cache Entry. This avoids the HA
forwarding traffic addressed to prefixes that have not been yet
delegated to the MR.
DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6 The use of DHCPv6, as described in this document, requires message
[RFC4301] to exchange messages securely. DHCPv6 relay agents and integrity protection and source authentication. When the MR is at
servers that support secure relay agent to server or relay agent home, normal DHCPv6 operation is used between MR and HA and therefore
to relay agent communication use IPsec under the following this specification does not add any new security issue. While the MR
conditions: is away from home, the IPsec security mechanism mandated by MIPv6
MUST be used to secure the DHCPv6 signaling. In the following, we
describe the Security Policy Database (SPD) and Security Association
Database (SAD) entries necessary to protect the DHCPv6 signaling. We
use the same format than that used by of [RFC4877]. The SPD and SAD
entries are only example configurations. A particular mobile router
implementation and a home agent implementation could configure
different SPD and SAD entries as long as they provide the required
security of the DHCPv6 signaling messages.
Selectors DHCPv6 relay agents are manually configured with For the examples described in this document, a mobile router with
the addresses of the DHCPv6 server to which DHCPv6 home address, "home_address_1", and a home agent with address,
messages are to be forwarded. Each DHCPv6 server "home_agent_1" are assumed. If the home address of the mobile router
that will be using IPsec for securing DHCPv6 changes, the SPD and SAD entries need to be re-created or updated for
messages must also be configured with a list of the new home address.
the DHCPv6 relay agents to which messages will be
returned. The selectors for the DHCPv6 relay
agents and servers will be the pairs of addresses
defining DHCPv6 relay agents and servers that
exchange DHCP messages on the DHCPv6 UDP ports 546
and 547.
Mode DHCPv6 relay agents and servers use transport mode mobile router SPD-S:
and ESP. The information in DHCPv6 messages is - IF local_address = home_address_1 &
not generally considered confidential, so remote_address = home_agent_1 & proto = UDP &
encryption need not be used (i.e., NULL encryption local_port = any & remote_port = DHCP
can be used). Then use SA1 (OUT) and SA2 (IN)
Key management If the HA providing the DHCPv6 relay agent mobile router SAD:
function and the DHCPv6 servers are both - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
administered by the same organization, public key local_address = home_address_1 &
schemes are not necessary. Because the relay remote_address = home_agent_1 &
agents and servers must be manually configured, proto = UDP & remote_port = DHCP
manually configured key management may suffice, - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
but does not provide defense against replayed local_address = home_agent_1 &
messages. Accordingly, IKE with preshared secrets remote_address = home_address_1 &
SHOULD be supported. proto = UDP & local_port = DHCP
Security policy DHCPv6 messages between relay agents and servers home agent SPD-S:
should only be accepted from DHCPv6 peers as - IF local_address = home_agent_1 &
identified in the local configuration. remote_address = homa_address_1 & proto = UDP &
local_port = DHCP & remote_port = any
Then use SA2 (OUT) and SA1 (IN)
Authentication Shared keys, indexed to the source IP address of home agent SAD:
the received DHCPv6 message, are adequate in this - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
application. local_address = home_agent_1 &
remote_address = home_address_1 &
proto = UDP & local_port = DHCP
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = UDP & remote_port = DHCP
5. IANA Considerations 5. IANA Considerations
This document describes the use of DHCPv6 for prefix delegation in This document describes the use of DHCPv6 for prefix delegation in
Mobile Networks. It does not introduce any additional IANA NEMOs. It does not introduce any additional IANA considerations.
considerations.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank people who have given valuable The authors would like to thank people who have given valuable
comments on the mailing list. Specific suggestions from Ryuji comments on the mailing list. Specific suggestions from Ryuji
Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and
Marcelo Bagnulo were incorporated into this document. Marcelo Bagnulo were incorporated into this document.
The authors would like to thank Julien Laganier, Michaela Vanderveen
and Jean-Michel Combes for their review of previous versions of this
document.
7. Change Log 7. Change Log
This section MUST be removed before this document is published as an This section MUST be removed before this document is published as an
RFC. RFC.
7.1. Revision -00 7.1. Revision -00
This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes
the use of the DHCPv6 relay agent in the MR, as described in the use of the DHCPv6 relay agent in the MR from
Section 3.3, from draft-dupont-mext-dhcrelay-00. draft-dupont-mext-dhcrelay-00.
7.2. Revision -01 7.2. Revision -01
Added detail in Section 4, "Security Considerations", describing Added detail in Section 4, "Security Considerations", describing
protection required for DHCPv6 and a mechanism for protecting traffic protection required for DHCPv6 and a mechanism for protecting traffic
between the DHCPv6 relay agent and server. between the DHCPv6 relay agent and server.
Corrected minor typos. Corrected minor typos.
7.3. Revision -02 7.3. Revision -02
Removed text describing extensions to DHAAD for discovery of HA that Removed text describing extensions to DHAAD for discovery of HA that
will provide PD. will provide PD.
Added Section 3.5, "Selecting an HA that provides DHCPv6PD," which Added Section 3.3, "Selecting an HA that provides DHCPv6PD," which
describes how an MR can discover DHCPv6PD service through polling of describes how an MR can discover DHCPv6PD service through polling of
multiple HAs. multiple HAs.
Added text to Section 4, "Security Considerations", giving detail Added text to Section 4, "Security Considerations", giving detail
about the use of IPsec. about the use of IPsec.
7.4. Revision -04 7.4. Revision -04
Added some figures to better explaining considered topologies and Added some figures to better explaining considered topologies and
message exchanges. Credits to Alex Petrescu. message exchanges. Credits to Alex Petrescu.
skipping to change at page 15, line 33 skipping to change at page 12, line 21
the tunnel to the HA so the DHCPv6 signaling can be sent, and one to the tunnel to the HA so the DHCPv6 signaling can be sent, and one to
register the delegated prefixes as MNPs at the HA. This updates RFC register the delegated prefixes as MNPs at the HA. This updates RFC
3963 behavior (note added). 3963 behavior (note added).
Text added to address some comments received on the MEXT mailing list Text added to address some comments received on the MEXT mailing list
Corrected minor typos. Corrected minor typos.
Enlisted Carlos J. Bernardos as co-author Enlisted Carlos J. Bernardos as co-author
7.5. Revision -05
Only implicit BU mode supported.
Only DHCPv6 relay agent in the MR co-located with the DHCPv6 client
function is supported as mode of operation when the MR is away from
home.
Security considerations include now the issue of the HA enforcing
that the MR registers the prefixes that were delegated to it via
DHCPv6PD.
Since RFC3775bis specifies that MR and HA operate in RO mode when
sending traffic between them, the term tunnel has been removed.
Some typos detected and corrected.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
Internet Protocol", RFC 4301, December 2005. IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dhc-dhcpv6-agentopt-delegate] [I-D.ietf-mext-rfc3775bis]
Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
Assignment Notification (RAAN) Option", in IPv6", draft-ietf-mext-rfc3775bis-05 (work in
draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in progress), October 2009.
progress), July 2009.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
Authors' Addresses Authors' Addresses
Ralph Droms Ralph Droms
Cisco Cisco
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
 End of changes. 72 change blocks. 
408 lines changed or deleted 291 lines changed or added

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