summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3203.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3203.txt')
-rw-r--r--doc/rfc/rfc3203.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3203.txt b/doc/rfc/rfc3203.txt
new file mode 100644
index 0000000..5f5b567
--- /dev/null
+++ b/doc/rfc/rfc3203.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group Y. T'Joens
+Request for Comments: 3203 C. Hublet
+Category: Standards Track Alcatel
+ P. De Schrijver
+ Mind
+ December 2001
+
+
+ DHCP reconfigure extension
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document defines extensions to DHCP (Dynamic Host Configuration
+ Protocol) to allow dynamic reconfiguration of a single host triggered
+ by the DHCP server (e.g., a new IP address and/or local configuration
+ parameters). This is achieved by introducing a unicast FORCERENEW
+ message which forces the client to the RENEW state. The behaviour
+ for hosts using the DHCP INFORM message to obtain configuration
+ information is also described.
+
+1. Introduction
+
+ The procedures as described within this document allow the dynamic
+ reconfiguration of individual hosts.
+
+1.1 Conventions
+
+ 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].
+
+2. DHCP force renew
+
+ This section describes the FORCERENEW message extension.
+
+
+
+
+
+T'Joens, et al. Standards Track [Page 1]
+
+RFC 3203 DHCP reconfigure extension December 2001
+
+
+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 unicast FORCERENEW message to the client.
+ Upon receipt of the unicast FORCERENEW message, the client will
+ change its state to the RENEW state, and 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 FORCERENEW message is lost, the DHCP server will not receive a
+ DHCP REQUEST from the client and it should retransmit the FORCERENEW
+ message using an exponential backoff algorithm. Depending on the
+ bandwidth of the network between server and client, the server should
+ choose a delay. This delay grows exponentially as retransmissions
+ fail. The amount of retransmissions should be limited.
+
+ The procedures described above assume the server to send a unicast
+ FORCERENEW message to the client. Receipt of a multicast FORCERENEW
+ message by the client should be silently discarded.
+
+ It can be that a client has obtained a network address through some
+ other means (e.g., manual configuration) and has used a DHCP INFORM
+ request to obtain other local configuration parameters. Such clients
+ should respond to the receipt of a unicast FORCERENEW message with a
+ new DHCP INFORM request so as to obtain a potential new set of local
+ configuration parameters. Note that the usage of these procedures
+ are limited to the set of options that are eligible for configuration
+ by DHCP and should not override manually configured parameters.
+
+ Note further that usage of the FORCERENEW message to reconfigure a
+ client address or local configuration parameters can lead to the
+ interruption of active sessions, and that as such these procedures
+ should be used in controlled circumstances.
+
+
+
+
+
+
+
+
+
+
+
+T'Joens, et al. Standards Track [Page 2]
+
+RFC 3203 DHCP reconfigure extension December 2001
+
+
+2.3 Example usage
+
+2.3.1 Embedded DHCP clients
+
+ The autoconfiguration of home gateways (more generically Network
+ Termination equipment) for public networking purposes can be achieved
+ through means of DHCP, as described in [DSL_autoconf]. In order to
+ allow service changes or service interruption, the FORCERENEW message
+ can trigger the home gateway to contact the DHCP server, prior to the
+ expiry of the lease.
+
+2.3.2 Hospitality service scenario
+
+ In self provisioned networks, e.g., hotel rooms, the hotel owned DHCP
+ server can hand out limited use IP addresses, that allows the
+ customer to consume local services or select external services from a
+ web browser interface. In order to allow external services through
+ other service providers, e.g., global internet services or enterprise
+ VPN services, the DHCP server can trigger the client to ask for a new
+ DHCP initialization session so as to obtain e.g., a globally routed
+ IP address.
+
+2.3.3 Network renumbering
+
+ Under tightly controlled conditions, the FORCERENEW procedures can be
+ used to brute force the renumbering of entire subnets, client per
+ client, under control of a DHCP server.
+
+2.4 Rationale
+
+ The approach as described in this document 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+T'Joens, et al. Standards Track [Page 3]
+
+RFC 3203 DHCP reconfigure extension December 2001
+
+
+3. Extended DHCP state diagram
+
++--------+ +------+
+| 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
+
+ The FORCERENEW message makes use of the normal DHCP message layout
+ with the introduction of a new DHCP message type. DHCP option 53
+ (DHCP message type) is extended with a new value: DHCPFORCERENEW (9)
+
+5. IANA Considerations
+
+ The new value for DHCP option 53 (DHCP message type) to indicate a
+ DHCPFORCERENEW message is 9.
+
+6. Security Considerations
+
+ As in some network environments FORCERENEW can be used to snoop and
+ spoof traffic, the FORCERENEW message MUST be authenticated using the
+ procedures as described in [DHCP-AUTH]. FORCERENEW messages failing
+ the authentication should be silently discarded by the client.
+
+
+
+
+
+
+T'Joens, et al. Standards Track [Page 4]
+
+RFC 3203 DHCP reconfigure extension December 2001
+
+
+6.1 Protocol vulnerabilities
+
+ The mechanism described in this document is vulnerable to a denial of
+ service attack through flooding a client with bogus FORCERENEW
+ messages. The calculations involved in authenticating the bogus
+ FORECERENEW messages may overwhelm the device on which the client is
+ running.
+
+7. References
+
+ [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+ [DHCP-AUTH] Droms, R. and W. Arbaugh, "Authentication for DHCP
+ Messages", RFC 3118, June 2001.
+
+ [DSL_autoconf] Technical Report TR-044, "Auto-Configuration for Basic
+ Internet (IP-based) Services", DSL Forum, November
+ 2001
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8. Acknowledgements
+
+ The authors would like to thank David Allan, Nortel, for the
+ constructive comments to these procedures.
+
+9. Authors' Addresses
+
+ Yves T'joens
+ Alcatel Network Strategy Group
+ Francis Wellesplein 1, 2018 Antwerp, Belgium
+ Phone: +32 3 240 7890
+ EMail: yves.tjoens@alcatel.be
+
+
+ Peter De Schrijver
+ Mind NV
+ Vaartkom 11
+ 3000 Leuven
+ EMail: p2@mind.be
+
+
+ Alcatel Broadband Networking Division
+ Veldkant 33b, 2550 Kontich, Belgium
+ Phone: +32 3 450 3322
+ EMail: Christian.Hublet@alcatel.be
+
+
+
+T'Joens, et al. Standards Track [Page 5]
+
+RFC 3203 DHCP reconfigure extension December 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+T'Joens, et al. Standards Track [Page 6]
+