idnits 2.17.1 draft-halwasia-dhc-inform-refresh-time-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2012) is 4245 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) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bhandari 3 Internet-Draft G. Halwasia 4 Intended status: Standards Track B. Volz 5 Expires: March 14, 2013 Cisco Systems 6 September 10, 2012 8 DHCPv4 INFORM Refresh Time Option 9 draft-halwasia-dhc-inform-refresh-time-opt-00 11 Abstract 13 This document describes a Dynamic Host Configuration Protocol for 14 IPv4 (DHCPv4) [RFC2131] option for specifying an upper bound for how 15 long a client should wait before refreshing information retrieved 16 from DHCPv4 Server by using DHCP INFORM message. It is used with 17 stateless DHCPv4 as there are no addresses or other entities with 18 lifetimes that can tell the client when to contact the DHCPv4 server 19 to refresh its configuration. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 14, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. DHCPv4 INFORM Refresh Time Option . . . . . . . . . . . . . . . 3 63 3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 DHCPv4 [RFC2131] specifies DHCP INFORM message which a client can 74 sent to obtain other local configuration parameters in case client 75 has obtained a network address through some other means. This other 76 configuration data will typically have no associated "lease", hence 77 there may be no information telling a host when to refresh its 78 configuration data. Therefore, an option that can be used from 79 server to client to inform the client when it should refresh the 80 other configuration data is needed. 82 This option is useful in many situations:- 84 - Unstable environments where unexpected changes are likely to occur. 86 - For planned changes, including renumbering. An administrator can 87 gradually decrease the time as the event nears. 89 - Use cases described in [I-D.bhandari-netext-pmipv6-dhcp-options] 90 also intends to use this option to exchange configuration parameters 91 in between MAG and LMA. 93 2. DHCPv4 INFORM Refresh Time Option 95 The INFORM refresh time option specifies an upper bound for how long 96 a client should wait before refreshing configuration parameters 97 retrieved from DHCPv4. It is only used in DHCP ACK messages in 98 response to DHCP INFORM messages. In other messages there will 99 usually be other options that indicate when the client should contact 100 the server. Note that it is only an upper bound. If the client has 101 any reason to send DHCP INFORM before the refresh time expires, it 102 should attempt to refresh all the configuration parameters. A client 103 may contact the server before the refresh time expires due to various 104 reasons. For example, it may need additional configuration 105 parameters (such as by an application), or that it has an indication 106 that it may have moved to a new link etc. The expiry of the refresh 107 time in itself does not in any way mean that the client should remove 108 the data. The client should keep its current data while attempting 109 to refresh it. When a client receives a ACK message to an INFORM 110 message that contains configuration information, it should install 111 that new configuration information after removing any previously 112 received configuration information. It should also remove 113 information that is missing from the new information set, e.g., an 114 option might be left out or contain only a subset of what it did 115 previously. 117 The format of the DHCPv4 INFORM Refresh Time Option option is shown 118 below. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | option-code | option-len | option-value | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | option-value(cont.) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 option-code: 8-bit option code 128 option-len: 4 129 option-value: Time duration relative to the current time, 130 expressed in units of seconds 132 3. Client Behaviour 134 A client MUST request this option in the Parameter Request List 135 Option when sending Parameter Request List message to the DHCPv4 136 server. A client MUST NOT request this option in the Parameter 137 Request List option in any other messages. This document recommends 138 default refresh time of 86400 seconds and minimum default refresh 139 time of 600 seconds. If the Reply to an INFORM message does not 140 contain this option, the client MUST behave as if the option with 141 value 86400 seconds (24 hrs) was provided. A client MUST use the 142 refresh time of 600 seconds if it receives the option with a value 143 less than 600 seconds. 145 The value 0xffffffff in this option implies that the client should 146 not refresh its configuration data without some other trigger (such 147 as detecting movement to a new link). If a client contacts the 148 server to obtain new data or refresh some existing data before the 149 refresh time expires, then it SHOULD also refresh all data covered by 150 this option. When the client detects that the refresh time has 151 expired, it SHOULD try to update its configuration data by sending an 152 INFORM message as specified in section 4.4.3 of [RFC2131]. A client 153 MAY have a maximum value for the refresh time, where that value is 154 used whenever the client receives this option with a value higher 155 than the maximum. This also means that the maximum value is used 156 when the received value is "0xffffffff". A maximum value might make 157 the client less vulnerable to attacks based on forged DHCP messages. 158 Without a maximum value, a client may be made to use wrong 159 information for a possibly infinite period of time. There may 160 however be reasons for having a very long refresh time, so it may be 161 useful for this maximum value to be configurable. 163 4. Server Behaviour 165 A server sending a ACK message to an INFORM message SHOULD include 166 this option if it is requested in the Parameter Request List Option 167 of the INFORM message. The option value MUST NOT be smaller than 600 168 seconds. The server SHOULD give a warning if it is configured with a 169 smaller value. The option MUST only appear in the ACK messages. 171 5. IANA Considerations 173 This document defines DHCPv4 INFORM Refresh Time Option which 174 requires assignment of DHCPv4 option code TBD1 assigned from "Bootp 175 and DHCP options" registry (http://www.iana.org/assignments/ bootp- 176 dhcp-parameters/bootp-dhcp-parameters.xml), as specified in 177 [RFC2939]. 179 6. Security Considerations 181 Section 7 of [RFC2131] outlines the DHCPv4 security considerations. 182 This option does not change these in any significant way. An 183 attacker could send faked ACK messages with a low INFORM refresh time 184 value, which would trigger use of minimum recommended value of 600 185 seconds to minimize this threat. Another attack might be to send a 186 very large value, to make the client use forged information for a 187 long period of time. A possible maximum limit at the client is 188 suggested, which would reduce this problem. 190 7. Acknowledgements 192 Thanks to Authors of [RFC4242] as this document is essentially an 193 edited version of their memo. 195 8. Normative References 197 [I-D.bhandari-netext-pmipv6-dhcp-options] 198 Systems, C. and S. Kumar, "DHCPv4 Configuration Options in 199 PMIPv6", draft-bhandari-netext-pmipv6-dhcp-options-00 200 (work in progress), July 2012. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 206 RFC 2131, March 1997. 208 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 209 of New DHCP Options and Message Types", BCP 43, RFC 2939, 210 September 2000. 212 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 213 Time Option for Dynamic Host Configuration Protocol for 214 IPv6 (DHCPv6)", RFC 4242, November 2005. 216 Authors' Addresses 218 Shwetha Bhandari 219 Cisco Systems 220 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 221 Bangalore, KARNATAKA 560 087 222 India 224 Phone: +91 80 4426 0474 225 Email: shwethab@cisco.com 227 Gaurav Halwasia 228 Cisco Systems 229 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 230 Bangalore, KARNATAKA 560 087 231 India 233 Phone: +91 80 4426 1321 234 Email: ghalwasi@cisco.com 236 Bernie Volz 237 Cisco Systems 238 1414 Massachusetts Ave 239 BOXBOROUGH, MASSACHUSETTS 01719 240 UNITED STATES 242 Phone: +1 978 936 0382 243 Email: volz@cisco.com