idnits 2.17.1 draft-volz-dhc-dhcpv6-srsn-option-00.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. ** 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. 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 : ---------------------------------------------------------------------------- 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (August 9, 2006) is 6468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '3') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '4') (Obsoleted by RFC 9293) -- No information found for draft-ietf-dhc-dhcpv6-agentopt-delegate- - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Group B. Volz 3 Internet-Draft R. Droms 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: February 10, 2007 August 9, 2006 7 DHCPv6 Server Reply Sequence Number Option 8 draft-volz-dhc-dhcpv6-srsn-option-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 10, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This memo defines the Server Reply Sequence Number option for the 42 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option 43 is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay 44 agent to detect proper sequencing of Relay-Reply messages that could 45 be delivered out of order. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The Server Reply Sequence Number Option . . . . . . . . . . . . 3 52 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 53 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5 54 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Security considerations . . . . . . . . . . . . . . . . . . . . 6 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 62 1. Introduction 64 When a DHCPv6 server sends a Reply, there is no guarantee as to the 65 order of delivery of those datagrams sent by a server. A DHCPv6 66 client is protected against delivery of old Reply messages because of 67 the transaction-id in the message. However, a relay agent receiving 68 Relay-Reply messages and maintaining client state information (e.g., 69 [5]) has no such technique. Thus a delayed earlier Relay-Reply may 70 arrive after other Relay-Reply messages. As an example, suppose a 71 client sends a Request, the Reply (encapsulated in a Relay-Reply) is 72 delayed between server and relay agent. The client retransmits the 73 Request, the retransmitted Reply is processed through the relay agent 74 and then by the client. The client next transacts a Release/Reply 75 sequence, which causes the relay agent to remove the client's state 76 information when relaying the Relay-Reply. However, now the delayed 77 first Request's Reply arrives at the relay agent; if the relay agent 78 were to update the client's state based on this out of order message 79 (e.g., [5]), it would add client state that is no longer valid. The 80 Server Reply Sequence Number (SRSN) option can be used to prevent 81 this as the relay agent can detect and discard out of order message. 83 To allow a relay agent to detect and discard out of order messages, 84 the relay agent requests the server to include a SRSN option in 85 Relay-Reply messages. The SRSN option contains a monotonically 86 increasing sequence number that the relay agent can use to re- 87 sequence (or discard) out of order Relay-Reply messages from the 88 server. 90 2. Terminology 92 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 93 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 94 interpreted as described in RFC 2119 [1]. 96 Additional terms used in the description of DHCPv6 and DHCPv6 prefix 97 delegation are defined in [2] and [3]. 99 3. The Server Reply Sequence Number Option 101 The SRSN option is used by a server to indicate the order in which 102 the server has generated replies and therefore allows a relay agent 103 receiving Relay-Reply messages to determine the order in which those 104 Relay-Reply messages were originally sent. The Relay-Reply messages 105 are sent via UDP and, therefore, may be delivered out of order. 107 The server's sequence number in the SRSN is a monotonically 108 increasing series. This property is maintained by the server even if 109 the server loses internal state; e.g., if the server is restarted. 110 The value of the sequence number in the SRSN option is not related to 111 the contents of any options in the Relay-Reply message; the existence 112 of this sequence number does not indicate that any data at the server 113 has necessarily changed. 115 The DHCPv6 Server Reply Sequence Number Option has the following 116 format: 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | option-code | length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | | 124 + server-reply-sequence-number + 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 option-code OPTION_SRSN (TBD). 130 length 8. 132 server-reply-sequence-number 133 The 64-bit monotonically increasing server reply 134 sequence number. 136 4. DHCPv6 Relay Agent Behavior 138 If a relay agent requires the server to provide the SRSN option, it 139 MUST include an Option Request option, requesting the SRSN option, as 140 described in section 22.7 of [2]. 142 A relay agent MUST save the received server-reply-sequence-number 143 (and the server's Server Identifier Option, OPTION_SERVERID) with any 144 client state information extracted from a Relay-Reply if it needs to 145 assure it does not use out of date information. 147 A relay agent that uses the SRSN option needs do the following when 148 maintaining client state information: 150 1. Only update existing client state information if the received 151 server-reply-sequence-number (if from the same server) is greater 152 than the stored server-reply-sequence-number for the information; 153 the received server-reply-sequence-number and Server Identifier 154 must be stored with the client state information. 156 2. Delay removing expired client state information from its storage 157 for at least the maximum lifetime of a datagram. This assures 158 that any undelivered Relay-Reply datagrams will have expired and 159 been dropped from the network; and thus the server-reply- 160 sequence-number checking will prevent outdated information from 161 being used. A value of 2 minutes is the recommended value for 162 the maximum datagram lifetime, based on the maximum segment 163 lifetime used by the Transmission Control Protocol (TCP) [4]. 165 A change in the server-reply-sequence-number MUST NOT be used to 166 assume a client's state has changed, as a server may be 167 retransmitting the same information but with a different server- 168 reply-sequence-number. 170 5. DHCPv6 Server Behavior 172 If a relay agent has requested the SRSN option in an ORO, the server 173 SHOULD return the option with a monotonically increasing sequence 174 number. And, the server MUST also include a Server Identifier Option 175 (OPTION_SERVER_ID) in the Relay-Reply if it includes the SRSN option. 177 The server MUST monotonically increase the sequence number for any 178 Relay-Reply messages it transmits which include a SRSN option. A 179 server MAY increase the sequence number for each message it 180 transmits, even those that do not include a SRSN option. 182 One technique for a server to provide the monotonically increasing 183 sequence number is by splitting the 64-bit number into two 32-bit 184 values (minding network/host byte ordering) - a major (most 185 significant bits) and minor sequence number. When the server starts, 186 the major sequence number is read from stable storage if available, 187 incremented, and saved to stable storage. If no sequence number is 188 in stable storage, the current time (in seconds since Jan 1, 1970) is 189 used to seed the sequence number and write it to stable storage. The 190 minor sequence number is set to 0 and only it is incremented while 191 the server is running (except if it rolls over, in which case the 192 major sequence number MUST be updated); there is no need to commit 193 the minor sequence number to stable storage. 195 6. IANA considerations 197 IANA is requested to assign an option code from the "DHCPv6 and 198 DHCPv6 options" registry, 199 http://www.iana.org/assignments/dhcpv6-parameters, to OPTION_SRSN. 201 7. Security considerations 203 Security issues related to DHCP are described in [2] and [3]. 205 The DHCPv6 Server Reply Sequence Number option may be used to mount a 206 denial of service attack by causing a relay agent to incorrectly 207 record a very high server-reply-sequence-number and thus preventing 208 legitimate Relay-Reply messages from a server from being processed. 209 Communication between a server and a relay agent, and communication 210 between relay agents, can be secured through the use of IPSec, as 211 described in section 21.1 of [2]. 213 8. References 215 8.1. Normative References 217 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 218 Levels", BCP 14, RFC 2119, March 1997. 220 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 221 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 222 RFC 3315, July 2003. 224 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 225 Configuration Protocol (DHCP) version 6", RFC 3633, 226 December 2003. 228 8.2. Informative References 230 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 231 September 1981. 233 [5] Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent Assignment 234 Notification Option 235 (draft-ietf-dhc-dhcpv6-agentopt-delegate-*)", August 2006. 237 Authors' Addresses 239 Bernie Volz 240 Cisco Systems, Inc. 241 1414 Massachusetts Avenue 242 Boxborough, MA 01719 243 USA 245 Phone: +1 978.936.0382 246 Email: volz@cisco.com 248 Ralph Droms 249 Cisco Systems, Inc. 250 1414 Massachusetts Avenue 251 Boxborough, MA 01719 252 USA 254 Phone: +1 978.936.1674 255 Email: rdroms@cisco.com 257 Full Copyright Statement 259 Copyright (C) The Internet Society (2006). 261 This document is subject to the rights, licenses and restrictions 262 contained in BCP 78, and except as set forth therein, the authors 263 retain all their rights. 265 This document and the information contained herein are provided on an 266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 268 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 269 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 270 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 273 Intellectual Property 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at 295 ietf-ipr@ietf.org. 297 Acknowledgment 299 Funding for the RFC Editor function is provided by the IETF 300 Administrative Support Activity (IASA).