Internet DRAFT - draft-deschrijver-dhcpv4-reconfigure
draft-deschrijver-dhcpv4-reconfigure
Submitted to DHC Working Group Peter De Schrijver
INTERNET DRAFT Yves T'Joens
<draft-schrijvp-dhcpv4-reconfigure-00.txt> Alcatel
June 1999
Expires December, 1999
Dynamic host configuration : DHCP reconfigure extension
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This draft defines extensions to DHCP [DHCP] to allow dynamic
reconfiguration of a single host with a new IP address. This is
achieved by introducing a unicast DHCP FORCERENEW message which
forces the client to the RENEW state.
1. Introduction
The procedures as described within this draft allow the dynamic
reconfiguration of individual hosts between subnets. This allows a
VPN like service to be offered to customers.
De Schrijver, et al. Expires December 1999 [Page 1]
Internet Draft draft-schrijvp-dhcpv4-reconfigure-00 June 1999
The following describes an example configuration and operation to
allow the reader both to understand the need and applicability of the
DHCP extension.
Assume a dial in host that establishes a connection with its network
access provider. Upon network layer configuration, the host gets
configured by DHCP with an IP address local to the network access
provider. This local IP address allows the host to communicate within
the boundary of the (private) IP network operated by the network
access provider. The network access provider provides, besides
offering local content, VPN services by means of service selection
through e.g., a web browser (personalized web page). Upon selecting
(clicking) a specific VPN service, the host IP stack needs to be
reconfigured with an IP address local to a subnet of the selected
VPN.
To that end, some entity within the network access will trigger the
host to reconfigure its IP layer, after which, the host is virtually
connected to the VPN of choice. The procedures by which the entity
obtains the VPN IP address is outside the scope of this document.
Note that these procedures are not limited to dial-in like (point to
point) access, but can equally well apply within shared LAN media.
The extensions defined within this draft should be clearly
distinguished from subnet reconfiguration as it applies to single
hosts.
The same host behaviour may be obtained in the following ways,
however with some clear drawbacks.
The first alternative is to use a short lease time for the original
DHCP request. Depending on the specified lease time, this either
introduces unnecessary traffic and DHCP server load due to frequent
DHCP REQUEST messages to extend the lease, or lacking interactivity
due to the long delays between service selection and service
establishment. These problems render this alternative useless in
practice.
The second alternative is to specify a different protocol which
allows the client to be triggered to release its IP address.
Regardless of the installation and maintenace headaches at the client
end this would introduce, this would be including DHCP related
functionality in another protocol, and goes against the spirit of
reusing existing protocols whenever applicable.
1.1 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
De Schrijver, et al. Expires December 1999 [Page 2]
Internet Draft draft-schrijvp-dhcpv4-reconfigure-00 June 1999
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. DHCP force renew
This section describes the DHCP force renew extension.
2.1 Terminology
DHCP client : host to be reconfigured using DHCP.
DHCP server : server which configured the DHCP client.
2.2 Force renew procedures
The DHCP server sends a force renew message to the client. The client
will change its state to the RENEW state. The client will then try to
renew its lease according to normal DHCP procedures. If the server
wants to assign a new IP address to the client, it will reply to the
DHCP REQUEST with a DHCP NAK. The client will then go back to the
init state and broadcast a DHCP DISCOVER message. The server can now
assign a new IP address to the client by replying with a DHCP OFFER.
If the force renew message is lost, the DHCP server should do message
retransmission based on the strategy as described in RFC 2131 [DHCP]
page 24.
2.3 Rationale
This approach has a number of advantages. It does not require new
states to be added to the DHCP client implementation. This minimizes
the amount of code to be changed. It also allows lease RENEWAL to be
driven by the server, which can be used to optimize network usage or
DHCP server load.
3. Extended DHCP state diagram
De Schrijver, et al. Expires December 1999 [Page 3]
Internet Draft draft-schrijvp-dhcpv4-reconfigure-00 June 1999
+--------+ +------+
| Init / | +-->+ Init +<---------------+-------------------+
| Reboot | | +--+---+ | |
+---+----+ DHCPNAK/ -/Send DHCPDISCOVER | |
| Restart | (broadcast) | |
| | v v-------------+ | |
-/Send DHCPREQUEST | +----+------+ DHCPOFFER/DHCPDECLINE |
| (broadcast) | | Selecting |----------+ | |
v | +----+------+ | |
+---+----+ | DHCPOFFER/DHCPREQUEST | |
| Reboot +--------------+ (broadcast) | |
+---+----+ v | |
| +----+-------+ DHCPNAK /halt network
| + Requesting | | lease expired
DHCPACK/ +----+-------+ | |
Record lease | | |
set timers DHCPACK/Record lease | |
| v Set T1 & T2 | |
| +--+----+DHCPFORCE +---+---+ +---+----+
+---------------------->+ Bound +---------->+ Renew +---------->+ Rebind |
+--+-+--+T1 expires +-+-+---+ T2 expires+--+--+--+
^ /DHCPREQUEST | | /broadcast |
DHCPACK to leasing | | DHCPREQUEST |
| server | | |
+------------------------------------------+
4. Message layout
Field DHCPFORCERENEW
----- ---------------
'op' BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0
'xid' selected by server
'secs' 0
'ciaddr' 0
'yiaddr' 0
'siaddr' 0
'flags' 0
'giaddr' 0
'chaddr' client's hardware address
'sname' 0
'file' 0
'options' options
DHCP option 53 (DHCP message type) is extended with a new value :
De Schrijver, et al. Expires December 1999 [Page 4]
Internet Draft draft-schrijvp-dhcpv4-reconfigure-00 June 1999
DHCPFORCERENEW
5. IANA Considerations
A new value for DHCP option 53 (DHCP message type) should be added to
indicate a DHCPFORCERENEW message.
6. Security Considerations
Depending on layer 2 characteristics, DHCP reconfigure can be a
security problem. Use of DHCP authentication is recommended in such
cases.
7. References
[DHCP] R.Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
8. Contacts
Peter De Schrijver
Alcatel Corporate Research Center
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 8569
E-mail : peter.de_schrijver@alcatel.be
Yves T'joens
Alcatel Corporate Research Center
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 7890
E-mail : yves.tjoens@alcatel.be
De Schrijver, et al. Expires December 1999 [Page 5]
