Mobility Extensions for IPv6 R. Droms
(MEXT) P. Thubert
Internet-Draft Cisco
Intended status: Standards Track F. Dupont
Expires: February 23, 2011 ISC
W. Haddad
Ericsson
CJ. Bernardos
UC3M
August 22, 2010
DHCPv6 Prefix Delegation for NEMO
draft-ietf-mext-nemo-pd-06
Abstract
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 NEMO.
DHCPv6 prefix delegation can be used for this configuration task.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 23, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Droms, et al. Expires February 23, 2011 [Page 1]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4
3.1. Exchanging DHCPv6 messages when the MR is not at home . . 5
3.1.1. Relay agent configuration . . . . . . . . . . . . . . 6
3.1.2. Transmission of DHCPv6 messages . . . . . . . . . . . 7
3.1.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 7
3.2. Exchanging DHCPv6 messages when MR is at home . . . . . . 7
3.3. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 8
3.4. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 9
3.5. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Revision -05 . . . . . . . . . . . . . . . . . . . . . . . 12
7.6. Revision -06 . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Droms, et al. Expires February 23, 2011 [Page 2]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
1. Introduction
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 NEMO.
DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used for this
configuration task.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
The following terms used in this document are defined in the IPv6
Addressing Architecture document [RFC4291]:
Link-Local Unicast address
Link-Local Scope Multicast address
The following terms used in this document are defined in the Mobile
IPv6 specification [I-D.ietf-mext-rfc3775bis]:
Home Agent (HA)
Home Link
The following terms used in this document are defined in the Mobile
Network terminology document [RFC4885]:
Mobile Router (MR)
Mobile Network (NEMO)
Mobile Network Prefix (MNP)
The following terms used in this document are defined in the DHCPv6
[RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications:
Delegating Router (DR; acts as a DHCPv6 server)
Requesting Router (RR; acts as a DHCPv6 client)
DHCPv6 Relay Agent (DRA)
The following acronym is used in this document:
Droms, et al. Expires February 23, 2011 [Page 3]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
DHCPv6PD: DHCPv6 Prefix Delegation
3. DHCPv6 Prefix Delegation of Mobile Network Prefixes
The NEMO Basic Support protocol [RFC3963] extends the Mobile IPv6
protocol [I-D.ietf-mext-rfc3775bis] to enable network mobility. In
this extension, an MR uses the Mobile IPv6 protocol to establish and
maintain a session with its HA, and uses bidirectional tunneling
between the MR and HA to provide a path through which nodes attached
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
receive delegated prefixes that can then be assigned to links in the
NEMO. DHCPv6PD can be used to meet this requirement for prefix
delegation.
To use DHCPv6PD for NEMOs, the HA assumes the role of the DR, and the
MR assumes the role of the RR when located at home, and the role of a
DRA co-located with the RR function, when the MR is away from home.
When the MR is not at home, the HA and MR exchange DHCPv6PD protocol
messages as specified in RFC3775bis. This means that messages sent
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 |----------------| HA |
|(RR)| (home network) |(DR)|
------ ------
------- /-----------\ ------
| MR |----| Internet |-----| HA |
|(RR) | \-----------/ |(DR)|
|(DRA)| ------
-------
(visited network)
Figure 1: Deployment topologies of the use of DHCPv6PD for delegation
of MNPs
The DHCPv6PD server is provisioned with prefixes to be assigned using
any of the prefix assignment mechanisms described in the DHCPv6PD
specifications. Other updates to the HA data structures required as
a side effect of prefix delegation are specified by the particular
Droms, et al. Expires February 23, 2011 [Page 4]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
network mobility protocol. For example, in the case of Basic Network
Mobility Support [RFC3963], the HA would add an entry in its binding
cache registering the delegated prefix to the MR to which the prefix
was delegated.
3.1. Exchanging DHCPv6 messages when the MR is not at home
The case when the MR is away from home is described in this section.
Section 3.2 describes the protocol operation for the case when the MR
is attached to its home link.
The MR MUST register at the HA (i.e. by sending a Binding Update to
the HA) before initiating a DHCPv6 message exchange for prefix
delegation. Since the MR may not have yet requested any prefixes,
implicit BU signaling MUST be used. While using the NEMO Basic
Support protocol with DHCPv6PD, implicit BU signaling is the default
mode of operation.
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
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.
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.
A DHPCv6 relay agent function [RFC3315] is used at the MR. This
relay agent function is co-located in the MR with the DHCPv6 client
function (see Figure 2). The DHCPv6 signaling between the MR and the
HA are exchanged between the DHCPv6 relay agent in the MR and the
DHCPv6 server on the HA. DHCPv6 messages from the MR to the HA are
unicast packets sent from the unicast HoA of the MR to the global
unicast address of the HA, and therefore the Home Address destination
option is used. DHCPv6 replies from the HA to the MR are sent using
the Routing Header type 2, as specified in RFC3775bis. The DHCPv6
client in the MR hands any outbound DHCPv6 messages to the co-located
Droms, et al. Expires February 23, 2011 [Page 5]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
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 | | HA |
| (RR) (DRA) | | (DR) |
---------------------------- --------
| | 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) |
| | |
Figure 2: Signaling sequence when the MR is not at home
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). 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
unicast DHCPv6 messages to the DHCPv6 server. The relay agent MUST
be configured with the address of the DHCPv6 server. For the
purposes of NEMO, the relay agent assumes that the HA for the MR
hosts the DHCPv6 server. Therefore, the MR MUST configure the DHCPv6
relay agent to forward DHCPv6 messages to the HA.
Droms, et al. Expires February 23, 2011 [Page 6]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
3.1.2. Transmission of DHCPv6 messages
When the DHCPv6 client in the MR sends a message, it hands the
message to the DHCPv6 relay agent in the MR. The way in which the
message is passed to the DHCP relay agent is beyond the scope of this
document. The relay agent encapsulates the message from the client
according to RFC 3315 in a Relay-forward message and sends the
resulting DHCPv6 message to the HA. The relay agent sets the fields
in the Relay-forward message as follows:
msg-type RELAY-FORW
hop-count 1
link-address The home address of the MR
peer-address A non-link-local address from the MR egress interface
(e.g., home address) used to send packets between the
HA and the MR
options MUST include a "Relay Message option" [RFC3315]; MAY
include other options added by the relay agent.
3.1.3. Receipt of DHCPv6 messages
Messages from the DHCPv6 server will be returned to the DHCPv6 relay
agent, with the message for the DHCPv6 client encapsulated in the
Relay Message option [RFC3315] in a Relay-reply message. The relay
agent function extracts the message for the client from the Relay
Message option and hands the message to the DHCPv6 client in the MR.
The way in which the message is passed to the client is beyond the
scope of this document.
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
exchange DHCPv6PD messages with the MR (Figure 3). In this case, the
DHCPv6 co-located relay function is disabled. It is the
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.
Droms, et al. Expires February 23, 2011 [Page 7]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
-------- --------
| 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
provide DHCPv6PD. Therefore, when selecting an HA, an MR that
requires DHCPv6PD service must identify an HA that will provide the
service. The MR can determine if an HA provides DHCPv6PD by
initiating a DHCPv6 message exchange (i.e. sending a Solicit message)
in which the MR requests delegated prefix(es). If the HA does not
respond or responds but does not delegate any prefix(es) in its
response, the MR assumes that the HA does not provide DHCPv6PD
service. The MR continues to query all candidate HAs until it finds
an HA that provides DHCPv6PD. Note that in this particular case and
if the MR is away from home, the MR has to have already performed an
MIPv6 registration with the HA it queries.
Querying an HA to determine if it provides DHCPv6PD requires a small
modification to the operation of DHCPv6 as described in RFC 3315.
Under normal circumstances, a host will continue to send DHCPv6
Solicit messages until it receives a response (see Section 17 of RFC
3315). However, an HA may choose not to respond to the Solicit
messages from the MR because the HA does not provide DHCPv6.
Therefore, when querying an HA to determine if the HA provides
DHCPv6PD service, the MR SHOULD discontinue sending Solicit messages
to the HA after sending 6 Solicit messages, and conclude that the HA
will not provide DHCPv6PD service. Sending 6 queries provides enough
reliability for scenarios in which the wireless connectivity is lost
for a short period after sending the first BU message.
Droms, et al. Expires February 23, 2011 [Page 8]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
It is recommended that the MR uses a sequential probing of the HAs
for DHCPv6PD service.
3.4. Minimizing DHCPv6PD messages
DHCPv6PD in a NEMO can be combined with the Rapid Commit option
[RFC3315] to provide DHCPv6 prefix delegation with a two message
exchange between the mobile router and the DHCPv6PD DR.
3.5. Other DHCPv6 functions
The DHCPv6 messages exchanged between the MR and the HA MAY also be
used for other DHCPv6 functions in addition to DHCPv6PD. For
example, the HA MAY assign global addresses to the MR and MAY pass
other configuration information such as a list of available DNS
recursive name servers [RFC3646] to the MR using the same DHCPv6
messages as used for DHCPV6PD.
The HA MAY act as a DHCPv6 relay agent for Mobile Nodes while it acts
as a DR for MRs.
4. Security Considerations
This document describes the use of DHCPv6 for prefix delegation in
NEMO. In addition to the security considerations for DHCPv6
described in the "Security Considerations" section of the DHCPv6 base
specification [RFC3315] and the "Security Considerations" of the
DHCPv6 Prefix Delegation specification [RFC3633], there are two
aspects that need to be considered.
First, the NEMO Basic Support specification requires the HA to
prevent an MR from claiming MNPs belonging to another MR. Upon
reception of an implicit BU from an MR, the HA MUST only add prefixes
into the MR's Binding Cache Entry if the MR has a valid DHCPv6 Prefix
Delegation lease for said prefixes. If the MR does not have a valid
DHCPv6 Prefix Delegation lease, the HA MUST NOT add any prefixes into
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.
The use of DHCPv6, as described in this document, requires message
integrity protection and source authentication. When the MR is at
home, normal DHCPv6 operation is used between MR and HA and therefore
this specification does not add any new security issue. While the MR
is away from home, the IPsec security mechanism mandated by MIPv6
Droms, et al. Expires February 23, 2011 [Page 9]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
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.
For the examples described in this document, a mobile router with
home address "home_address_1", and a home agent with address
"home_agent_1" are assumed. If the home address of the mobile router
changes, the SPD and SAD entries need to be re-created or updated for
the new home address.
mobile router SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = UDP &
local_port = any & remote_port = DHCP
Then use SA1 (OUT) and SA2 (IN)
mobile router SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = UDP & remote_port = DHCP
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = UDP & local_port = DHCP
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = homa_address_1 & proto = UDP &
local_port = DHCP & remote_port = any
Then use SA2 (OUT) and SA1 (IN)
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
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
Droms, et al. Expires February 23, 2011 [Page 10]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
5. IANA Considerations
This document describes the use of DHCPv6 for prefix delegation in
NEMOs. It does not introduce any additional IANA considerations.
6. Acknowledgments
The authors would like to thank people who have given valuable
comments on the mailing list. Specific suggestions from Ryuji
Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and
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
This section MUST be removed before this document is published as an
RFC.
7.1. Revision -00
This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes
the use of the DHCPv6 relay agent in the MR from
draft-dupont-mext-dhcrelay-00.
7.2. Revision -01
Added detail in Section 4, "Security Considerations", describing
protection required for DHCPv6 and a mechanism for protecting traffic
between the DHCPv6 relay agent and server.
Corrected minor typos.
7.3. Revision -02
Removed text describing extensions to DHAAD for discovery of HA that
will provide PD.
Added Section 3.3, "Selecting an HA that provides DHCPv6PD," which
describes how an MR can discover DHCPv6PD service through polling of
multiple HAs.
Added text to Section 4, "Security Considerations", giving detail
about the use of IPsec.
Droms, et al. Expires February 23, 2011 [Page 11]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
7.4. Revision -04
Added some figures to better explaining considered topologies and
message exchanges. Credits to Alex Petrescu.
Added some text to clarify that two BUs are required, one to set up
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
3963 behavior (note added).
Text added to address some comments received on the MEXT mailing list
Corrected minor typos.
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.
7.6. Revision -06
Some nits fixed.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
Droms, et al. Expires February 23, 2011 [Page 12]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
8.2. Informative References
[I-D.ietf-mext-rfc3775bis]
Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mext-rfc3775bis-06 (work in
progress), July 2010.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
Authors' Addresses
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Phone: +1 978.936.1674
Email: rdroms@cisco.com
Droms, et al. Expires February 23, 2011 [Page 13]
Internet-Draft DHCPv6 Prefix Delegation for NEMO August 2010
Pascal Thubert
Cisco
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
Email: pthubert@cisco.com
Francis Dupont
ISC
Email: Francis.Dupont@fdupont.fr
Wassim Haddad
Ericsson
6210 Spine Road
Boulder, CO 80301
USA
Phone: +1 303.473.6963
Email: Wassim.Haddad@ericsson.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Droms, et al. Expires February 23, 2011 [Page 14]