Mobility Extensions for IPv6 R. Droms (MExt) P. Thubert Internet-Draft Cisco Intended status: Standards Track F. Dupont Expires: April 29, 2010 ISC W. Haddad Ericsson October 26, 2009 DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 April 29, 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 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. Droms, et al. Expires April 29, 2010 [Page 1] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 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 Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Application of DHCPv6 prefix delegation to mobile networks for delegation of home prefixes . . . . . . . . . . . . . . . 4 3.1. When the MR uses DHCPv6 . . . . . . . . . . . . . . . . . 4 3.2. Use of MR-HA tunnel for DHCPv6 messages . . . . . . . . . 5 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages . . 5 3.3.1. Relay agent configuration . . . . . . . . . . . . . . 5 3.3.2. Transmission of DHCPv6 messages . . . . . . . . . . . 6 3.3.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 6 3.4. Exchanging DHCPv6 messages when MR is at home . . . . . . 6 3.5. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 7 3.6. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 7 3.7. Location of DHCPv6PD Delegating Router function . . . . . 7 3.8. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Droms, et al. Expires April 29, 2010 [Page 2] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 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 Mobile Network. 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 [RFC3775]: home agent (HA) home link The following terms used in this document are defined in the Mobile Network terminology document [RFC4886]: Mobile Router (MR) Mobile Network mobile host (MH) 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 The following acronym is used in this document: Droms, et al. Expires April 29, 2010 [Page 3] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 DHCPv6PD: DHCPv6 prefix delegation 3. Application of DHCPv6 prefix delegation to mobile networks for delegation of home prefixes The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol [RFC3775] to enable network mobility. In this extension, a 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 Mobile Network can maintain connectivity with nodes not in the Mobile Network. The requirements for NEMO [RFC4885] include the ability of the MR to receive delegated prefixes that can then be assigned to links in the Mobile Network. DHCPv6PD can be used to meet this requirement for prefix 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 connecting them. The tunnel acts as the link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD specification. 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 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. When the MR uses DHCPv6 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 Droms, et al. Expires April 29, 2010 [Page 4] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 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. If 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. 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 MUST NOT be tunneled to the mobile node. The DHCPv6 messages exchanged between the HA and the MR originate only with the HA and the MR, and therefore are not "intercepted packets" and may be sent between the HA and the MR through the tunnel. Even though the MR-HA tunnel is a point to point connection, the MR SHOULD use multicast DHCPv6 messages as described in RFC 3315 over that tunnel. 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages A DHPCv6 relay agent function [RFC3315] can be used as an alternative to multicast DHCPv6 messages over the tunnel between the MR and the HA. In this configuration, the relay agent function is co-located in the MR with the DHCPv6 client function. Rather than using multicast to send DHCPv6 messages through the tunnel to the DHCPv6 server, the 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. 3.3.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 or another DHCPv6 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 Droms, et al. Expires April 29, 2010 [Page 5] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 hosts the next hop in the path the to the DHCPv6 server: either the DHCPv6 server or a relay agent that will forward message to the 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 In this configuration, 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 this handoff takes place 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 A non-link-local address from the MR interface to the tunnel between the HA and MR peer-address A non-link-local address from the MR interface to the tunnel between the HA and MR options MUST include a "Relay Message option" [RFC3315]; MAY include other options added by the relay agent. 3.3.3. Receipt of DHCPv6 messages In this configuration, 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 this handoff takes place is beyond the scope of this document. 3.4. 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. It is the responsibility of the implementation to determine when the MR is on its home link and to avoid use of any existing tunnel. Droms, et al. Expires April 29, 2010 [Page 6] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 3.5. 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, a 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 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. 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 MUST discontinue sending Solicit messages to the HA after sending 6 Solicit messages, and conclude that the HA will not provide DHCPv6PD service. The MR may choose to probe the HAs for DHCPv6PD service sequentially or in parallel. 3.6. 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. Use of the DHCPv6 relay agent function with DHCPv6PD requires that there be some mechanism through which routing information for the Droms, et al. Expires April 29, 2010 [Page 7] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 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]. 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 (BDE) 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 draft 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 already defined for NEMO. 3.8. 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 MHs while it acts as a DR for MRs. 4. Security Considerations This document describes the use of DHCPv6 for prefix delegation in Droms, et al. Expires April 29, 2010 [Page 8] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 Mobile Networks. It does not introduce any additional security considerations for DHCPv6 beyond those described in the "Security Considerations" section of the DHCPv6 base specification [RFC3315] and the "Security Considerations" of the DHCPv6 Prefix Delegation specification [RFC3633]. 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 physical node, the HA will act as a DHCPv6 relay agent between the MR and the DHCPv6 server. In this scenario, the mobile network infrastructure will only protect the DHCPv6 traffic between the RR (MR) and the relay agent (HA). The following text, based on Section 21.1 of RFC 3315, describes how appropriate security can be provided between a DHCPv6 relay agent and server. DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6 [RFC2401] to exchange messages securely. DHCPv6 relay agents and servers that support secure relay agent to server or relay agent to relay agent communication use IPsec under the following conditions: Selectors DHCPv6 relay agents are manually configured with the addresses of the DHCPv6 server to which DHCPv6 messages are to be forwarded. Each DHCPv6 server that will be using IPsec for securing DHCPv6 messages must also be configured with a list of 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 and ESP. The information in DHCPv6 messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used). Droms, et al. Expires April 29, 2010 [Page 9] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 Key management If the HA providing the DHCPv6 relay agent function and the DHCPv6 servers are both administered by the same organization, public key schemes are not necessary. Because the relay agents and servers must be manually configured, manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. Discussion: If NEMO may be deployed with the HA and the DHCPv6 server in different administrative domains, this text should be extended to include the use of IKE with public keys. Security policy DHCPv6 messages between relay agents and servers should only be accepted from DHCPv6 peers as identified in the local configuration. Authentication Shared keys, indexed to the source IP address of the received DHCPv6 message, are adequate in this application. 5. IANA Considerations This document describes the use of DHCPv6 for prefix delegation in Mobile Networks. It does not introduce any additional IANA considerations. 6. Change Log This section MUST be removed before this document is published as an RFC. 6.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, as described in Section 3.3, from draft-dupont-mext-dhcrelay-00. 6.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. Droms, et al. Expires April 29, 2010 [Page 10] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 Corrected minor typos. 6.3. Revision -02 Removed text describing extensions to DHAAD for discovery of HA that will provide PD. Added Section 3.5, "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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [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. [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. [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. 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. Droms, et al. Expires April 29, 2010 [Page 11] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 7.2. Informative References [I-D.ietf-dhc-dhcpv6-agentopt-delegate] Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in progress), July 2009. [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. Authors' Addresses Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1674 Email: rdroms@cisco.com 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 Droms, et al. Expires April 29, 2010 [Page 12] Internet-Draft DHCPv6 Prefix Delegation for NEMO October 2009 Wassim Haddad Ericsson 6210 Spine Road Boulder, CO 80301 USA Phone: +1 303.473.6963 Email: wmhaddad@gmail.com Droms, et al. Expires April 29, 2010 [Page 13]