Network Working Group T. Mrugalski Internet-Draft Gdansk University of Technology Intended status: Standards Track July 05, 2010 Expires: January 6, 2011 Remote DHCPv6 Autoconfiguration draft-mrugalski-remote-dhcpv6-00 Abstract This document describes remote autoconfiguration, using DHCPv6 protocol. Every time a node attaches to a new link, it must renew or obtain new address and parameters, using DHCPv6 protocol. In case of mobile nodes, it is beneficial to obtain address and other configuration parameters remotely, before actually attaching to destination link. This document defines new options required to remotely discover destination DHCPv6 servers. Remote unicast configuration with DHCPv6 servers is also defined. Requirements Language 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 RFC 2119 [RFC2119]. 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 January 6, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Mrugalski Expires January 6, 2011 [Page 1] Internet-Draft Remote DHCPv6 Autoconfiguration July 2010 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 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. Remote DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . 3 2.1. Discovering Neighboring Networks . . . . . . . . . . . . . 3 2.2. Remote Autoconfiguration . . . . . . . . . . . . . . . . . 3 3. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . . 4 3.1. Neighbors Option Format . . . . . . . . . . . . . . . . . . 4 4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Mrugalski Expires January 6, 2011 [Page 2] Internet-Draft Remote DHCPv6 Autoconfiguration July 2010 1. Introduction When mobile IPv6 node (MN) changes its location, signal quality and other metrics fluctuate and handover decision is made. During normal handover procedure, data link layer (e.g. 802.16) initiates and performs handover procedure. This phase is often referred to as L2 handover. After such procedure is completed, network layer (e.g. IPv6) handover is performed. After MN attaches to its new location, it tries to confirm old or obtain new configuration parameters, using DHCPv6 CONFIRM or SOLICIT messages. After discovering available DHCPv6 servers, MN requests new address and possibly other configuration options. Once DHCPv6 configuration is complete, it may start other handover related activities, like updating Correspondent Nodes (CN) using Binding Update procedure [RFC3775]. Doing aforementioned actions sequencially, delays introduced by each layer are adding up, resulting in a large overall delay. This intrduces gaps in communication capabilites that should be avoided. 2. Remote DHCPv6 Operation Client, while still connected to its old location, gains information about DHCPv6 servers located at possible handover destinations. One of the possible ways to determine such addresses is specified in Section 2.1. After gaining knowledge about potential destinations, client chooses one or more destinations and obtains configuration parameters from each chosen location, as defined in Section 2.2. 2.1. Discovering Neighboring Networks Client, while still connected to its old location, sends regular SOLICIT, REQUEST, RENEW or REBIND message to its DHCPv6 server. Client includes OPTION_NEIGHBORS code in the transmitted ORO. DHCPv6 server responds with the list of addresses of DHCPv6 servers located at possible handover targets. Such list is conveyed in OPTION_NEIGHBORS option. 2.2. Remote Autoconfiguration Client communicates with remote DHCPv6 server, located at potential destination. To do so, client transmits SOLICIT message to known server unicast address and includes OPTION_REMOTE_AUTOCONF (defined in Section 3. Server, supporting remote autoconfiguration responds as if the message was received locally, e.g. responds with ADVERTISE to client's SOLICIT message. Client continues remote configuration using REQUEST or CONFIRM message. Server concludes remote autoconfiguration by responding using REPLY message. Mrugalski Expires January 6, 2011 [Page 3] Internet-Draft Remote DHCPv6 Autoconfiguration July 2010 3. DHCPv6 Options Format A DHCPv6 based solution is able to address the problems of lengthly reconfiguration, by allowing MN to remotely complete its DHCPv6 configuration. 3.1. Neighbors Option Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NEIGHBORS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 1st Neighboring DHCPv6 Server Address | | (16 octets) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . additional Neighboring DHCPv6 Server Addresses . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | n-th Neighboring DHCPv6 Server Address | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IPv6 Neighbors Option Format option-code: OPTION_NEIGHBORS (TBD). option-len: Number of specified neghbors, multiplied by 16. Neighboring DHCPv6 server Address One or more IPv6 address of the neighboring DHCPv6 servers. 4. DHCPv6 Server Behavior Server MUST NOT send OPTION_NEIGHBOR to client, unless client explicitly requested such option. Server MUST respond to client message transmitted off-link if Mrugalski Expires January 6, 2011 [Page 4] Internet-Draft Remote DHCPv6 Autoconfiguration July 2010 OPTION_REMOTE_AUTOCONF option is included in client's message. Server MUST ignore off-link messages that does not contain OPTION_REMOTE_AUTOCONF option. 5. DHCPv6 Client Behavior Client supporting remote autoconfiguration, SHOULD request OPTION_NEIGHBORS every time it sends SOLICIT, REQUEST, RENEW, REBIND or CONFIRM messages. Client MAY initiate remote autoconfiguration at its own discretion. Depending on client policy, that may be as soon as local configuration is completed, when radio signal quality degrades and handover is imminent or when other implementation specific conditions are met. 6. IANA Considerations IANA is requested to allocate two DHCPA option codes referencing this document: OPTION_NEIGHBORS and OPTION_REMOTE_AUTOCONF. 7. Security Considerations The overall security considerations discussed in [RFC3315] apply also to this document. OPTION_REMOTE_AUTOCONF may be used to attack know DHCPv6 server, but that does not differ from attacks directed at servers supporting unicast address option. Neither of the above considerations are new and specific to the proposed remote configuration option. The mechanisms identified for securing DHCPv6 as well as reasonable checks performed by client implementations are deemed sufficient in addressing these problems. 8. 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. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support Mrugalski Expires January 6, 2011 [Page 5] Internet-Draft Remote DHCPv6 Autoconfiguration July 2010 in IPv6", RFC 3775, June 2004. Author's Address Tomasz Mrugalski Gdansk University of Technology Storczykowa 22B/12 Gdansk 80-177 Poland Phone: +48 698 088 272 Email: tomasz.mrugalski@eti.pg.gda.pl Mrugalski Expires January 6, 2011 [Page 6]