Network Working Group T. Mrugalski
Internet-Draft Gdansk University of Technology
Intended status: Experimental Oct 25, 2010
Expires: April 28, 2011
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 [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.
Mrugalski Expires April 28, 2011 [Page 1]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 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
1.1. Classic handover and DHCPv6 configuration . . . . . . . . . 3
1.2. Remote DHCPv6 Rationale . . . . . . . . . . . . . . . . . . 3
2. Remote DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . 4
2.1. Discovering Neighboring Networks . . . . . . . . . . . . . 4
2.2. Remote Autoconfiguration . . . . . . . . . . . . . . . . . 4
3. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . . 5
3.1. Neighbors Option Format . . . . . . . . . . . . . . . . . . 5
3.2. Remote Autoconfiguration Option . . . . . . . . . . . . . . 6
4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 7
5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Mrugalski Expires April 28, 2011 [Page 2]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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]), 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]) 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]. 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.
Mrugalski Expires April 28, 2011 [Page 3]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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.
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. The target
selection algorithm is outside of scope of this document.
After changing point of attachment, client behaves as described in
[RFC3315]: 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
Mrugalski Expires April 28, 2011 [Page 4]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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.
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Neighbors Option Format
Mrugalski Expires April 28, 2011 [Page 5]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Neighbors Option Format
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
Mrugalski Expires April 28, 2011 [Page 6]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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] 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.
Mrugalski Expires April 28, 2011 [Page 7]
Internet-Draft Remote DHCPv6 Autoconfiguration Oct 2010
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
in IPv6", RFC 3775, June 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
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 April 28, 2011 [Page 8]