idnits 2.17.1 draft-ietf-dhc-lifetime-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 334), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2005) is 7038 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 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-ietf-dhc-stateless-dhcpv6-renumbering-01 Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Venaas 3 Internet Draft University of Southampton 4 Expiration Date: July 2005 5 T. Chown 6 University of Southampton 8 B. Volz 9 Cisco Systems, Inc. 11 January 2005 13 Information Refresh Time Option for DHCPv6 15 draft-ietf-dhc-lifetime-03.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 To view the list Internet-Draft Shadow Directories, see 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 This document describes a DHCPv6 option for specifying an upper bound 47 for how long a client should wait before refreshing information 48 retrieved from DHCPv6. It is used with stateless DHCPv6 as there are 49 no addresses or other entities with lifetimes that can tell the 50 client when to contact the DHCPv6 server to refresh its 51 configuration. 53 Table of Contents 55 1. Introduction ............................................... 2 56 2. Terminology ................................................ 3 57 3. Information refresh time option definition ................. 3 58 3.1. Constants .............................................. 4 59 3.2. Client behaviour ....................................... 4 60 3.3. Server behaviour ....................................... 5 61 3.4. Option format .......................................... 5 62 4. IANA Considerations ........................................ 6 63 5. Acknowledgements ........................................... 6 64 6. Security Considerations .................................... 6 65 7. References ................................................. 6 66 7.1. Normative References ................................... 6 67 7.2. Informative References ................................. 7 68 Authors' Addresses ............................................. 7 69 Intellectual Property and Copyright Statements ................. 7 71 1. Introduction 73 DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 74 hosts. However, many hosts will use stateless autoconfiguration as 75 specified in [RFC 2462] for address assignment, and use DHCPv6 only 76 for other configuration data, see [RFC 3736]. This other 77 configuration data will typically have no associated lifetime, hence 78 there may be no information telling a host when to refresh its DHCPv6 79 configuration data. Therefore, an option that can be used from 80 server to client to inform the client when it should refresh the 81 other configuration data is needed. 83 This option is useful in many situations: 85 - Unstable environments where unexpected changes are likely to 86 occur. 88 - For planned changes, including renumbering. An administrator 89 can gradually decrease the time as the event nears. 91 - Limit the amount of time before new services or servers are 92 available to the client, such as the addition of a new NTP 93 server or a change of address of a DNS server. See 94 [RENUMREQS]. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP 14, RFC 2119 [RFC 101 2119]. 103 3. Information refresh time option definition 105 The information refresh time option specifies an upper bound for how 106 long a client should wait before refreshing information retrieved 107 from DHCPv6. It is only used in Reply messages in response to 108 Information-Request messages. In other messages there will usually 109 be other options that indicate when the client should contact the 110 server, e.g. addresses with lifetimes. 112 Note that it is only an upper bound. If the client has any reason to 113 make a DHCPv6 request before the refresh time expires, it should 114 attempt to refresh all the data. 116 A client may contact the server before the refresh time expires. 117 Reasons it may do this include the need for additional configuration 118 parameters (such as by an application), a new IPv6 prefix announced 119 by a router, or that it has an indication it may have moved to a new 120 link. 122 The refresh time option specifies a common refresh time for all the 123 data. It doesn't make sense to have different refresh time values 124 for different data, since when the client has reason to refresh some 125 of its data, it should also refresh the remaining data. Because of 126 this, the option must only appear in the options area of the Reply 127 message. 129 The expiry of the refresh time in itself does not in any way mean 130 that the client should remove the data. The client should keep its 131 current data while attempting to refresh it. The client is however 132 free to fall back to other mechanisms than DHCPv6 if it cannot 133 refresh the data within a reasonable amount of time. 135 When a client receives a Reply to an Information-Request that 136 contains configuration information, it should install that new 137 configuration information after removing any previously received 138 configuration information. It should also remove information that is 139 missing from the new information set, e.g. an option might be left 140 out or contain only a subset of what it did previously. 142 3.1. Constants 144 We define two constants for use by the protocol. How they are used 145 is specified in the sections below. 147 IRT_DEFAULT 86400 148 In some cases the client uses a default refresh time 149 IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 150 (24 hours). The client implementation SHOULD allow for this 151 value to be configurable. 153 IRT_MINIMUM 600 154 This defines a minimum value for the refresh time. 156 3.2. Client behaviour 158 A client MUST request this option in the Option Request Option (ORO) 159 when sending Information-Request messages to the DHCPv6 server. A 160 client MUST NOT request this option in the ORO in any other messages. 162 If the Reply to an Information-Request message does not contain this 163 option, the client MUST behave as if the option with value 164 IRT_DEFAULT was provided. 166 A client MUST use the refresh time IRT_MINIMUM if it receives the 167 option with a value less than IRT_MINIMUM. 169 As per section 5.6 of [RFC 3315], the value 0xffffffff is taken to 170 mean "infinity" and implies that the client should not refresh its 171 configuration data without some other trigger (such as detecting 172 movement to a new link). 174 If a client contacts the server to obtain new data or refresh some 175 existing data before the refresh time expires, then it SHOULD also 176 refresh all data covered by this option. 178 When the client detects that the refresh time has expired, it SHOULD 179 try to update its configuration data by sending an Information- 180 Request as specified in section 18.1.5 of [RFC 3315], except that the 181 client MUST delay sending the first Information-Request by a random 182 amount of time between 0 and INF_MAX_DELAY. 184 A client MAY have a maximum value for the refresh time, where that 185 value is used whenever the client receives this option with a value 186 higher than the maximum. This also means that the maximum value is 187 used when the received value is "infinity". A maximum value might 188 make the client less vulnerable to attacks based on forged DHCP 189 messages. Without a maximum value, a client may be made to use wrong 190 information for a possibly infinite period of time. There may 191 however be reasons for having a very long refresh time, so it may be 192 useful for this maximum value to be configurable. 194 3.3. Server behaviour 196 A server sending a Reply to an Information-Request message SHOULD 197 include this option if it is requested in the ORO of the Information- 198 Request. 200 The option value MUST NOT be smaller than IRT_MINIMUM. The server 201 SHOULD give a warning if it is configured with a smaller value. 203 The option MUST only appear in the options area of Reply messages. 205 3.4. Option format 207 The format of the information refresh time option is: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | option-code | option-len | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | information-refresh-time | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 option-code 218 OPTION_INFORMATION_REFRESH_TIME (to be decided) 220 option-len 221 4 223 information-refresh-time 224 Time duration relative to the current time, expressed in units 225 of seconds 227 4. IANA Considerations 229 IANA is requested to assign an option code for the information 230 refresh time option from the DHCPv6 option-code space [RFC 3315]. 232 5. Acknowledgements 234 The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten, 235 Joe Quanaim and A.K. Vijayabhaskar for valuable discussions and 236 comments. 238 6. Security Considerations 240 Section 23 of [RFC 3315] outlines the DHCPv6 security considerations. 241 This option does not change these in any significant way. An 242 attacker could send faked Reply messages with a low information 243 refresh time value, which would trigger use of IRT_MINIMUM to 244 minimize this threat. Another attack might be to send a very large 245 value, to make the client use forged information for a long period of 246 time. A possible maximum limit at the client is suggested, which 247 would reduce this problem. 249 7. References 251 7.1. Normative References 253 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address 257 Autoconfiguration", RFC 2462, December 1998. 259 [RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, 260 M. Carney, "Dynamic Host Configuration Protocol for IPv6 261 (DHCPv6)", RFC 3315, July 2003. 263 [RFC 3736] R. Droms, "Stateless Dynamic Host Configuration Protocol 264 (DHCP) Service for IPv6", RFC 3736, April 2004. 266 7.2. Informative References 268 [RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering 269 Requirements for Stateless DHCPv6", work-in-progress, 270 draft-ietf-dhc-stateless-dhcpv6-renumbering-01, 271 March 2004. 273 Authors' Addresses 275 Stig Venaas 276 University of Southampton 277 School of Electronics and Computer Science 278 Southampton, Hampshire SO17 1BJ 279 United Kingdom 280 EMail: sv@ecs.soton.ac.uk 282 Tim Chown 283 University of Southampton 284 School of Electronics and Computer Science 285 Southampton, Hampshire SO17 1BJ 286 United Kingdom 287 EMail: tjc@ecs.soton.ac.uk 289 Bernard Volz 290 Cisco Systems, Inc. 291 1414 Massachusetts Ave. 292 Boxborough, MA 01719 293 USA 294 EMail: volz@cisco.com 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at ietf- 318 ipr@ietf.org. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 325 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 326 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 327 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Copyright Statement 332 Copyright (C) The Internet Society (2005). This document is subject 333 to the rights, licenses and restrictions contained in BCP 78, and 334 except as set forth therein, the authors retain all their rights. 336 Acknowledgement 338 Funding for the RFC Editor function is currently provided by the 339 Internet Society.