idnits 2.17.1 draft-ietf-dhc-pv4-reconfigure-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([DHCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-dhc-authentication-14 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Submitted to DHC Working Group Peter De Schrijver 2 INTERNET DRAFT Yves T'Joens 3 Christian Hublet 4 Alcatel 5 November 2000 6 Expires June, 2001 8 DHCP reconfigure extension 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a 23 ``working draft'' or ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 34 ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), 35 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Distribution of this memo is unlimited. 39 Abstract 41 This draft defines extensions to DHCP [DHCP] to allow dynamic 42 reconfiguration of a single host triggered by the DHCP server (eg. a 43 new IP address). This is achieved by introducing a unicast DHCP 44 FORCERENEW message which forces the client to the RENEW state. 46 1. Introduction 48 The procedures as described within this draft allow the dynamic 49 reconfiguration of individual hosts. 51 1.1 Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 2. DHCP force renew 58 This section describes the DHCP force renew extension. 60 2.1 Terminology 62 DHCP client : host to be reconfigured using DHCP. 64 DHCP server : server which configured the DHCP client. 66 2.2 Force renew procedures 68 The DHCP server sends a force renew message to the client. The client 69 will change its state to the RENEW state. The client will then try to 70 renew its lease according to normal DHCP procedures. If the server 71 wants to assign a new IP address to the client, it will reply to the 72 DHCP REQUEST with a DHCP NAK. The client will then go back to the 73 init state and broadcast a DHCP DISCOVER message. The server can now 74 assign a new IP address to the client by replying with a DHCP OFFER. 75 If the force renew message is lost, the DHCP server will not receive 76 a DHCP REQUEST from the client and it should retransmit the DHCP 77 FORCERENEW message using an exponential backoff algorithm. Depending 78 on the bandwidth of the network between server and client, the server 79 should choose a delay. This delay grows exponentially as 80 retransmissions fail. The amount of retransmissions should be 81 limited. 83 2.3 Rationale 85 This approach has a number of advantages. It does not require new 86 states to be added to the DHCP client implementation. This minimizes 87 the amount of code to be changed. It also allows lease RENEWAL to be 88 driven by the server, which can be used to optimize network usage or 89 DHCP server load. 91 3. Extended DHCP state diagram 92 +--------+ +------+ 93 | Init / | +-->+ Init +<---------------+-------------------+ 94 | Reboot | | +--+---+ | | 95 +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | 96 | Restart | (broadcast) | | 97 | | v v-------------+ | | 98 -/Send DHCPREQUEST| +----+------+ DHCPOFFER/DHCPDECLINE | 99 | (broadcast)| | Selecting |----------+ | | 100 v | +----+------+ | | 101 +---+----+ | DHCPOFFER/DHCPREQUEST | | 102 | Reboot +---------+ (broadcast) | | 103 +---+----+ v | | 104 | +----+-------+ DHCPNAK /halt network 105 | + Requesting | | lease expired 106 DHCPACK/ +----+-------+ | | 107 Record lease | | | 108 set timers DHCPACK/Record lease | | 109 | v Set T1 & T2 | | 110 | +--+----+DHCPFORCE +---+---+ +----+---+ 111 +----------------->+ Bound +---------->+ Renew +--------->+ Rebind | 112 +--+-+--+T1 expires +-+-+---+T2 expires+----+---+ 113 ^ /DHCPREQUEST | | /broadcast | 114 DHCPACK to leasing | | DHCPREQUEST | 115 | server | | | 116 +----------------------------------------+ 118 4. Message layout 120 Field DHCPFORCERENEW 121 ----- --------------- 122 'op' BOOTREPLY 123 'htype' (From "Assigned Numbers" RFC) 124 'hlen' (Hardware address length in octets) 125 'hops' 0 126 'xid' selected by server 127 'secs' 0 128 'ciaddr' 0 129 'yiaddr' 0 130 'siaddr' 0 131 'flags' 0 132 'giaddr' 0 133 'chaddr' client's hardware address 134 'sname' 0 135 'file' 0 136 'options' options 138 DHCP option 53 (DHCP message type) is extended with a new value : 140 DHCPFORCERENEW (TBD) 142 5. IANA Considerations 144 The new value for DHCP option 53 (DHCP message type) to indicate a 145 DHCPFORCERENEW message is TBD. 147 6. Security Considerations 149 As in some network environments DHCPFORCERENEW can be used to snoop 150 and spoof traffic, the DHCPFORCERENEW message MUST be authenticated 151 using the procedures as described in [DHCP-AUTH]. 153 7. References 155 [DHCP] R.Droms, "Dynamic Host Configuration Protocol", RFC 2131, 156 March 1997. 158 [DHCP-AUTH] R. Droms et al., "Authentication for DHCP Messages", 159 draft-ietf-dhc-authentication-14, July 2000, Work in progress. 161 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 9. Contacts 166 Peter De Schrijver 167 Alcatel Network Strategy Group 168 Francis Wellesplein 1, 2018 Antwerp, Belgium 169 Phone : +32 3 240 8569 170 E-mail : peter.de_schrijver@alcatel.be 172 Yves T'joens 173 Alcatel Network Strategy Group 174 Francis Wellesplein 1, 2018 Antwerp, Belgium 175 Phone : +32 3 240 7890 176 E-mail : yves.tjoens@alcatel.be 178 Christian Hublet 179 Alcatel Carrier Internetworking Division 180 De Villermontstraat 28, 2550 Kontich, Belgium 181 Phone : +32 3 450 3322 182 E-mail : Christian.Hublet@alcatel.be 184 8. Full Copyright Statement 185 This document and translations of it may be copied and furnished to 186 others, and derivative works that comment on or otherwise explain it 187 or assist in its implmentation may be prepared, copied, published and 188 distributed, in whole or in part, without restriction of any kind, 189 provided that the above copyright notice and this paragraph are 190 included on all such copies and derivative works. However, this 191 document itself may not be modified in any way, such as by removing 192 the copyright notice or references to the Internet Society or other 193 Internet organizations, except as needed for the purpose of 194 developing Internet standards in which case the procedures for 195 copyrights defined in the Internet Standards process must be 196 followed, or as required to translate it into languages other than 197 English. 199 The limited permissions granted above are perpetual and will not be 200 revoked by the Internet Society or its successors or assigns. 202 This document and the information contained herein is provided on an 203 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 204 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 205 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 206 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.''