idnits 2.17.1 draft-venaas-dhc-lifetime-01.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 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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A server sending an Advertise or Reply message containing options, SHOULD include this option if requested by client, or if none of the options contained in the message have associated lifetimes. The option MAY also be used in other cases when server sends Advertise or Reply messages. It MUST not be used when server sends other types of messages. -- 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 2003) is 7462 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) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Venaas 2 Internet Draft UNINETT 3 Expiration Date: May 2004 4 T. Chown 5 University of Southampton 7 November 2003 9 Lifetime Option for DHCPv6 11 draft-venaas-dhc-lifetime-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes an option for specifying a lifetime for other 37 DHCPv6 configuration options. It's mainly intended for the stateless 38 DHCPv6, but also useful when there are no addresses or other entities 39 with lifetimes that can tell the client when to contact the DHCP 40 server to update its configuration. 42 Table of Contents 44 1. Introduction ............................................... 2 45 2. Terminology ................................................ 3 46 3. Lifetime option definition ................................. 3 47 3.1. Client behaviour ....................................... 3 48 3.2. Server behaviour ....................................... 4 49 3.3. Option format .......................................... 4 50 4. IANA Considerations ........................................ 4 51 5. Acknowledgments ............................................ 4 52 6. Security Considerations .................................... 5 53 7. References ................................................. 5 54 7.1. Normative References ................................... 5 55 7.2. Informative References ................................. 5 56 Authors' Addresses ............................................. 5 58 1. Introduction 60 DHCPv6 [RFC 3315] has been defined for IPv6 hosts wishing to use 61 stateful autoconfiguration. However, many hosts will use stateless 62 autoconfiguration as specified in [RFC 2462] for address assignment, 63 and use DHCPv6 only for other configuration data. This other 64 configuration data will typically have no associated lifetime, hence 65 there may be no information telling a host when to update its DHCP 66 configuration data. 68 This option may be useful in unstable environments where unexpected 69 changes are likely to occur, or for planned changes, including 70 renumbering where an administrator can gradually decrease the value 71 as the event nears. 73 It may also be useful to allow the client to detect within an 74 appropriate time when a specific service change has been made, e.g. 75 the addition of a new NTP server, or a change of address of a DNS 76 server within the local network. See [RENUMREQS] for further 77 details. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14, RFC 2119 [RFC 84 2119]. 86 3. Lifetime option definition 88 The lifetime option specifies a lifetime for all configuration data 89 contained in other options in an advertise or reply message that have 90 no associated lifetime. This means that it does not effect e.g. the 91 IA Address option which contains a lifetime. 93 3.1. Client behaviour 95 A client supporting this option MAY include it in the Option Request 96 Option (ORO) when sending messages to the DHCP server that allows ORO 97 to be included. 99 If client has received a lifetime with this option, and contacts 100 server to receive new or update any existing data prior to its 101 expiration, it SHOULD also update data covered by this option. If no 102 new lifetime is received, it MUST behave as if no value was ever 103 provided. 105 When the client detects that the lifetime has expired, it must do as 106 follows. 108 First it MUST ignore or remove the existing lifetime value. If it 109 does not receive a new value in a later request, it MUST behave as if 110 no value was ever provided. 112 Next it MUST wait for a random amount of time between 0 and 113 INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. 115 Finally it must make a new DHCP request, updating the current 116 configuration. This request will usually be an Information-request 117 Message. If client fails to receive a valid response from a server, 118 it MUST retransmit the message according to the retransmission rules 119 specified in [RFC 3315]. 121 If the update fails, the current configuration must be kept as if no 122 lifetime was ever provided. 124 3.2. Server behaviour 126 A server sending an Advertise or Reply message containing options, 127 SHOULD include this option if requested by client, or if none of the 128 options contained in the message have associated lifetimes. The 129 option MAY also be used in other cases when server sends Advertise or 130 Reply messages. It MUST not be used when server sends other types of 131 messages. 133 3.3. Option format 135 The format of the Lifetime option is: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | OPTION_LIFETIME | option-len | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | lifetime | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 option-code: OPTION_LIFETIME (to be decided) 147 option-len: 4 149 lifetime: lifetime in seconds 151 4. IANA Considerations 153 IANA is requested to assign an option code to the lifetime option 154 from the DHCP option-code space defined in section "IANA 155 Considerations" of RFC 3315. 157 5. Acknowledgments 159 The authors thank Mat Ford, A.K. Vijayabhaskar and Bernie Volz for 160 valuable discussions and comments. 162 6. Security Considerations 164 An attacker could send a fake DHCP reply with a very low lifetime 165 value. This could make a client request new data almost immediately. 166 The value is however not kept when the next request is made. 168 7. References 170 7.1. Normative References 172 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address 176 Autoconfiguration", RFC 2462, December 1998. 178 [RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, 179 M. Carney, "Dynamic Host Configuration Protocol for IPv6 180 (DHCPv6)", RFC 3315, July 2003. 182 7.2. Informative References 184 [RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering 185 Requirements for Stateless DHCPv6", work-in-progress, 186 draft-chown-dhc-stateless-dhcpv6-renumbering-00, 187 November 2003. 189 Authors' Addresses 191 Stig Venaas 192 UNINETT 193 NO-7465 Trondheim, Norway 194 Email: venaas@uninett.no 196 Tim Chown 197 University of Southampton 198 School of Electronics and Computer Science 199 Southampton, Hampshire SO17 1BJ 200 United Kingdom 201 EMail: tjc@ecs.soton.ac.uk