idnits 2.17.1 draft-ietf-dhc-pv4-reconfigure-00.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. == 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 61 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. ** There are 25 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...d is in full ...' == Line 21 has weird spacing: '...-Drafts may ...' == Line 23 has weird spacing: '... Drafts as r...' == Line 32 has weird spacing: '...e check the...' == Line 33 has weird spacing: '...listing conta...' == (22 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (September 2000) is 8624 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) == Missing Reference: 'RFC2119' is mentioned on line 57, but not defined -- No information found for draft-ietf-dhc-euthentication - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DHCP-AUTH' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 4 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 6 March 2000 7 Expires September 2000 9 Dynamic host configuration : DHCP reconfigure extension 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 35 ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), 36 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Distribution of this memo is unlimited. 40 Abstract 42 This draft defines extensions to DHCP [DHCP] to allow dynamic 43 reconfiguration of a single host triggered by the DHCP server (eg. a 44 new IP address). This is achieved by introducing a unicast DHCP 45 FORCERENEW message which forces the client to the RENEW state. 47 1. Introduction 49 The procedures as described within this draft allow the dynamic 50 reconfiguration of individual hosts. 52 1.1 Conventions 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 2. DHCP force renew 60 This section describes the DHCP force renew extension. 62 2.1 Terminology 64 DHCP client : host to be reconfigured using DHCP. 66 DHCP server : server which configured the DHCP client. 68 2.2 Force renew procedures 70 The DHCP server sends a force renew message to the client. The client 71 will change its state to the RENEW state. The client will then try to 72 renew its lease according to normal DHCP procedures. If the server 73 wants to assign a new IP address to the client, it will reply to the 74 DHCP REQUEST with a DHCP NAK. The client will then go back to the 75 init state and broadcast a DHCP DISCOVER message. The server can now 76 assign a new IP address to the client by replying with a DHCP OFFER. 77 If the force renew message is lost, the DHCP server will not receive 78 a DHCP REQUEST from the client and it should retransmit the DHCP 79 FORCERENEW message using an exponential backoff algorithm. Depending 80 on the bandwidth of the network between server and client, the server 81 should choose a delay. This delay grows exponentially as 82 retransmissions fail. The amount of retransmissions should be 83 limited. 85 2.3 Rationale 87 This approach has a number of advantages. It does not require new 88 states to be added to the DHCP client implementation. This minimizes 89 the amount of code to be changed. It also allows lease RENEWAL to be 90 driven by the server, which can be used to optimize network usage or 91 DHCP server load. 93 3. Extended DHCP state diagram 94 +--------+ +------+ 95 | Init / | +-->+ Init +<---------------+-------------------+ 96 | Reboot | | +--+---+ | | 97 +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | 98 | Restart | (broadcast) | | 99 | | v v-------------+ | | 100 -/Send DHCPREQUEST | +----+------+ DHCPOFFER/DHCPDECLINE | 101 | (broadcast) | | Selecting |----------+ | | 102 v | +----+------+ | | 103 +---+----+ | DHCPOFFER/DHCPREQUEST | | 104 | Reboot +--------------+ (broadcast) | | 105 +---+----+ v | | 106 | +----+-------+ DHCPNAK /halt network 107 | + Requesting | | lease expired 108 DHCPACK/ +----+-------+ | | 109 Record lease | | | 110 set timers DHCPACK/Record lease | | 111 | v Set T1 & T2 | | 112 | +--+----+DHCPFORCE +---+---+ +---+----+ 113 +---------------------->+ Bound +---------->+ Renew +---------->+ Rebind | 114 +--+-+--+T1 expires +-+-+---+ T2 expires+--+--+--+ 115 ^ /DHCPREQUEST | | /broadcast | 116 DHCPACK to leasing | | DHCPREQUEST | 117 | server | | | 118 +------------------------------------------+ 120 4. Message layout 122 Field DHCPFORCERENEW 123 ----- --------------- 124 'op' BOOTREPLY 125 'htype' (From "Assigned Numbers" RFC) 126 'hlen' (Hardware address length in octets) 127 'hops' 0 128 'xid' selected by server 129 'secs' 0 130 'ciaddr' 0 131 'yiaddr' 0 132 'siaddr' 0 133 'flags' 0 134 'giaddr' 0 135 'chaddr' client's hardware address 136 'sname' 0 137 'file' 0 138 'options' options 140 DHCP option 53 (DHCP message type) is extended with a new value : 142 DHCPFORCERENEW 144 5. Failover Considerations 146 A DHCP server should only send a DHCPFORCERENEW when it's fully aware 147 of the current state of the DHCP client. In practice this means it 148 should only send a DHCPFORCERENEW when in "PARTNER DOWN", 149 "COMMUNICATIONS INTERRUPTED" or "NORMAL" state, and only for DHCP 150 clients of which the state is synchronised. 152 6. IANA Considerations 154 A new value for DHCP option 53 (DHCP message type) should be added to 155 indicate a DHCPFORCERENEW message. 157 7. Security Considerations 159 Depending on layer 2 characteristics, DHCP force renew can be used to 160 snoop and spoof traffic. To prevent this, the DHCPFORCERENEW message 161 should be authenticated using a shared secret based mechanism as 162 described in [DHCP-AUTH]. 164 8. References 166 [DHCP] R.Droms, "Dynamic Host Configuration Protocol", RFC 2131, 167 March 1997. 169 [DHCP-AUTH] R. Droms, "Authentication for DHCP Messages", draft- 170 ietf-dhc-euthentication-12, October 1999. 172 9. Contacts 174 Peter De Schrijver 175 Alcatel Corporate Research Center 176 Francis Wellesplein 1, 2018 Antwerp, Belgium 177 Phone : +32 3 240 8569 178 E-mail : peter.de_schrijver@alcatel.be 180 Yves T'joens 181 Alcatel Corporate Research Center 182 Francis Wellesplein 1, 2018 Antwerp, Belgium 183 Phone : +32 3 240 7890 184 E-mail : yves.tjoens@alcatel.be 186 Christian Hublet 187 Alcatel Carrier Internetworking Division 188 De Villermontstraat 28, 2550 Kontich, Belgium 189 Phone : +32 3 450 3322 190 E-mail : Christian.Hublet@alcatel.be