Remote DHCPv6 Autoconfiguration
draft-mrugalski-remote-dhcpv6-01

Abstract

This document describes remote autoconfiguration mechanism, an extension to DHCPv6 protocol. Every time a node attaches to a new link, it must renew or obtain new address and parameters, using DHCPv6 protocol. For mobile nodes it is beneficial to obtain address and other configuration parameters remotely, before actually attaching to destination link. This document defines mechanism using remote configuration and new options required to remotely discover destination DHCPv6 servers. Remote unicast communication 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 April 28, 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 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
    1.1.  Classic handover and DHCPv6 configuration
    1.2.  Remote DHCPv6 Rationale
2.  Remote DHCPv6 Operation
    2.1.  Discovering Neighboring Networks
    2.2.  Remote Autoconfiguration
3.  DHCPv6 Options Format
    3.1.  Neighbors Option Format
    3.2.  Remote Autoconfiguration Option
4.  DHCPv6 Server Behavior
5.  DHCPv6 Client Behavior
6.  IANA Considerations
7.  Security Considerations
8.  Normative References
§  Author's Address

1.  Introduction

1.1.  Classic handover and DHCPv6 configuration

During normal operation, a node attaches to a link (e.g. after completing, waking up from standby mode, booting up etc.) and, if certain condtions are met (see [RFC4862] (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.)), it initiates DHCPv6 operation. It is assumed that initial communication with servers (directly or via relays) is performed locally, i.e. client and server or relay are attached to the same link.

In certain mobility scenarios, it may be beneficial to initiate configuration and obtain parameters before physically attaching to local link. When client (a mobile IPv6 node, likely to be conformant to [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)) changes its physical location, radio signal and other metrics deteriorate and eventually handover decision is made. During normal handover procedure, data link layer (e.g. IEEE 802.11 or IEEE 802.16) performs handover procedure. This phase is sometimes referred to as link layer handover. After such procedure is completed, IPv6 reconfiguration is started. After client 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) or Home Agent (HA) using Binding Update procedure [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). If aforementioned actions are preformed sequencially, delays introduced by each layer are adding up, resulting in a large overall delay. This introduces gaps in communication capabilites that should be avoided, if possible.

1.2.  Remote DHCPv6 Rationale

Instead of performing DHCPv6 configuration after physically attaching to a link, client communicates with server (or relay) located at destination link remotely, while still being attached to the old link. Assuming client is able to communicate with destination server, it may obtain all requested parameters. Although this mechanism is generic and not tied to any specific mobility mechanism, there are number of benefits client could gain from learning its parameters before handover:

Mobile Client may perform certain actions earlier, e.g. Mobile Client may send Binding Update notifications to its correspondent nodes before performing handover. This may potentially halve the Round Trip Time delay.

Mobile Client may perform many actions at once, e.g. update CNs about its new address while initiating handover preparation. Some network access technologies like IEEE 802.16 (WiMAX) allow node to initiate handover procedure and remain attached to old base station. Node maintains full communication capability at that time. The exact detachment event is left up to the client.

Mobile Client may consider several target locations as target destinations. The knowledge about availability (or lack of thereof) of requested services may be leveraged during destination selection.

The exact way of exploiting gained knowledge via remote autoconfiguration mechanism is outside of scope of this document.

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 (Discovering Neighboring Networks).

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 (Remote Autoconfiguration). The target selection algorithm is outside of scope of this document.

After changing point of attachment, client behaves as described in [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.): attempts to verify its address using CONFIRM message.

Discussion: The concept may be briefly described as "extending unicast communication." Maybe reference to Server Unicast Option should be explicitly mentioned?

2.1.  Discovering Neighboring Networks

Client, while still connected to its old location, sends regular SOLICIT, REQUEST, RENEW or REBIND message to its locally available DHCPv6 server. Client includes OPTION_NEIGHBORS code in the transmitted Option Request Option (ORO). 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 one or more DHCPv6 servers, 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 (DHCPv6 Options Format). 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.

3.  DHCPv6 Options Format

Following sections define two DHCPv6 options, used in remote autoconfiguration process.

3.1.  Neighbors Option Format

Neighbors Option is used to announce neighboring DHCPv6 servers, located in nearby networks. Client requests this option to learn about DHCPv6 servers located at nearby networks (potential candidates for handovers).

 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)                             |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

Discussion: While some network access technologies allow discovery of neighboring networks (e.g. Neighbor Advertisments or Scanning mechanism in 802.16 networks), but they provide information on link layer level (e.g. BS ID in case of 802.16 networks). Some mapping between IP information (i.e. neighboring DHCPv6 servers) and link layer level (e.g. BSID) may be considered here. If such approach is deemed feasible, Neighbors Option format should be extended with additional link layer information.

3.2.  Remote Autoconfiguration Option

Remote Autoconfiguration Option is used by the client to inform server that it is performing remote configuration, rather than local.

 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_REMOTE_AUTOCONF     |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           suboptions                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code:

OPTION_REMOTE_AUTOCONF (TBD).

option-len:

Length of the suboptions field. 0, if there are no suboptions.

suboptions

Zero or more suboptions.

The Remote Autoconfiguration Option may include suboptions. Currently there are no such suboptions defined.

Discussion: The Remote Autoconfiguration Option is used to inform server that client is currently located off-link, but would like to get on-link configuration. Also, it informs server that unicast communication from non-local prefix. However, if server is configured to allow such communication, it does not need to know about client's current location (just treat it as regular, local client). In that case, this option is not needed.

4.  DHCPv6 Server Behavior

Servers conformant to this specification MUST support unicast communication.

Server MUST NOT send OPTION_NEIGHBOR to client, unless client explicitly requested such option.

Server MUST respond to client message transmitted off-link if OPTION_REMOTE_AUTOCONF option is included in client's message.

Server SHOULD 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 MUST include OPTION_REMOTE_AUTOCONF in its messages, if communicating with server remotely (i.e. client and server are currently not on the same link).

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 DHCPv6 option codes referencing this document: OPTION_NEIGHBORS and OPTION_REMOTE_AUTOCONF.

7.  Security Considerations

The overall security considerations discussed in [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) apply also to this document. OPTION_REMOTE_AUTOCONF may be used to attack known DHCPv6 server, but that does not differ from attacks directed at servers supporting unicast address option. Compromised DHCPv6 server may be used to misinform clients about available nearby networks.

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

Author's Address