idnits 2.17.1 draft-ietf-dhc-dhcpv6-srsn-option-01.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, updated by RFC 4748 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. 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 IETF Trust 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 (March 1, 2007) is 6266 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) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: September 2, 2007 March 1, 2007 7 DHCPv6 Server Reply Sequence Number Option 8 draft-ietf-dhc-dhcpv6-srsn-option-01.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 September 2, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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. Modification History . . . . . . . . . . . . . . . . . . . . . 6 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 When a DHCPv6 server sends a Reply, there is no guarantee as to the 66 order of delivery of those datagrams sent by a server. A DHCPv6 67 client is protected against delivery of old Reply messages because of 68 the transaction-id in the message. However, a relay agent receiving 69 Relay-Reply messages and maintaining client state information (e.g., 70 [5] has no such technique. Thus a delayed earlier Relay-Reply may 71 arrive after other Relay-Reply messages. As an example, suppose a 72 client sends a Request, the Reply (encapsulated in a Relay-Reply) is 73 delayed between server and relay agent. The client retransmits the 74 Request, the retransmitted Reply is processed through the relay agent 75 and then by the client. The client next transacts a Release/Reply 76 sequence, which causes the relay agent to remove the client's state 77 information when relaying the Relay-Reply. However, now the delayed 78 first Request's Reply arrives at the relay agent; if the relay agent 79 were to update the client's state based on this out of order message 80 (e.g., [5]), it would add client state that is no longer valid. The 81 Server Reply Sequence Number (SRSN) option can be used to prevent 82 this as the relay agent can detect and discard out of order message. 84 To allow a relay agent to detect and discard out of order messages, 85 the relay agent requests the server to include a SRSN option in 86 Relay-Reply messages. The SRSN option contains a monotonically 87 increasing sequence number that the relay agent can use to re- 88 sequence (or discard) out of order Relay-Reply messages from the 89 server. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [1]. 97 Additional terms used in the description of DHCPv6 and DHCPv6 prefix 98 delegation are defined in [2] and [3]. 100 3. The Server Reply Sequence Number Option 102 The SRSN option is used by a server to indicate the order in which 103 the server has generated replies and therefore allows a relay agent 104 receiving Relay-Reply messages to determine the order in which those 105 Relay-Reply messages were originally sent. The Relay-Reply messages 106 are sent via UDP and, therefore, may be delivered out of order. 108 The server's sequence number in the SRSN is a monotonically 109 increasing series. This property is maintained by the server even if 110 the server loses internal state; e.g., if the server is restarted. 111 The value of the sequence number in the SRSN option is not related to 112 the contents of any options in the Relay-Reply message; the existence 113 of this sequence number does not indicate that any data at the server 114 has necessarily changed. 116 The DHCPv6 Server Reply Sequence Number Option has the following 117 format: 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 | length | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | 125 + server-reply-sequence-number + 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 option-code OPTION_SRSN (TBD). 131 length 8. 133 server-reply-sequence-number 134 The 64-bit monotonically increasing server reply 135 sequence number. 137 4. DHCPv6 Relay Agent Behavior 139 If a relay agent requires the server to provide the SRSN option, it 140 MUST include an Option Request option, requesting the SRSN option, as 141 described in section 22.7 of [2]. 143 A relay agent MUST save the received server-reply-sequence-number 144 (and the server's Server Identifier Option, OPTION_SERVERID) with any 145 client state information extracted from a Relay-Reply if it needs to 146 assure it does not use out of date information. 148 A relay agent that uses the SRSN option needs do the following when 149 maintaining client state information: 151 1. Only update existing client state information if the received 152 server-reply-sequence-number (if from the same server) is greater 153 than the stored server-reply-sequence-number for the information; 154 the received server-reply-sequence-number and Server Identifier 155 must be stored with the client state information. 157 2. Delay removing expired client state information from its storage 158 for at least the maximum lifetime of a datagram. This assures 159 that any undelivered Relay-Reply datagrams will have expired and 160 been dropped from the network; and thus the server-reply- 161 sequence-number checking will prevent outdated information from 162 being used. A value of 2 minutes is the recommended value for 163 the maximum datagram lifetime, based on the maximum segment 164 lifetime used by the Transmission Control Protocol (TCP) [4]. 166 A change in the server-reply-sequence-number MUST NOT be used to 167 assume a client's state has changed, as a server may be 168 retransmitting the same information but with a different server- 169 reply-sequence-number. 171 5. DHCPv6 Server Behavior 173 If a relay agent has requested the SRSN option in an ORO, the server 174 SHOULD return the option with a monotonically increasing sequence 175 number. And, the server MUST also include a Server Identifier Option 176 (OPTION_SERVER_ID) in the Relay-Reply if it includes the SRSN option. 178 The server MUST monotonically increase the sequence number for any 179 Relay-Reply messages it transmits which include a SRSN option. A 180 server MAY increase the sequence number for each message it 181 transmits, even those that do not include a SRSN option. 183 One technique for a server to provide the monotonically increasing 184 sequence number is by splitting the 64-bit number into two 32-bit 185 values (minding network/host byte ordering) - a major (most 186 significant bits) and minor sequence number. When the server starts, 187 the major sequence number is set to the current time (in seconds 188 since Jan 1, 1970). The minor sequence number is set to 0 and only 189 it is incremented while the server is running (except if it rolls 190 over, in which case the major sequence number MUST be updated); there 191 is no need to commit the sequence number to stable storage. 193 6. IANA considerations 195 IANA is requested to assign an option code from the "DHCPv6 and 196 DHCPv6 options" registry, 197 http://www.iana.org/assignments/dhcpv6-parameters, to OPTION_SRSN. 199 7. Security considerations 201 Security issues related to DHCP are described in [2] and [3]. 203 The DHCPv6 Server Reply Sequence Number option may be used to mount a 204 denial of service attack by causing a relay agent to incorrectly 205 record a very high server-reply-sequence-number and thus preventing 206 legitimate Relay-Reply messages from a server from being processed. 207 Communication between a server and a relay agent, and communication 208 between relay agents, can be secured through the use of IPSec, as 209 described in section 21.1 of [2]. 211 8. Modification History 213 Changes in rev -01 (to fix idnits): 214 o Revised terminology section to match recommended RFC 2119 syntax. 215 o Used new I-D boilerplate. 216 o Added this section. 218 9. References 220 9.1. Normative References 222 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", BCP 14, RFC 2119, March 1997. 225 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 226 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 227 RFC 3315, July 2003. 229 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 230 Configuration Protocol (DHCP) version 6", RFC 3633, 231 December 2003. 233 9.2. Informative References 235 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 236 September 1981. 238 [5] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) 239 Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in 240 progress), November 2006. 242 Authors' Addresses 244 Bernie Volz 245 Cisco Systems, Inc. 246 1414 Massachusetts Avenue 247 Boxborough, MA 01719 248 USA 250 Phone: +1 978.936.0382 251 Email: volz@cisco.com 253 Ralph Droms 254 Cisco Systems, Inc. 255 1414 Massachusetts Avenue 256 Boxborough, MA 01719 257 USA 259 Phone: +1 978.936.1674 260 Email: rdroms@cisco.com 262 Full Copyright Statement 264 Copyright (C) The IETF Trust (2007). 266 This document is subject to the rights, licenses and restrictions 267 contained in BCP 78, and except as set forth therein, the authors 268 retain all their rights. 270 This document and the information contained herein are provided on an 271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 273 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 274 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 275 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 278 Intellectual Property 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at 300 ietf-ipr@ietf.org. 302 Acknowledgment 304 Funding for the RFC Editor function is provided by the IETF 305 Administrative Support Activity (IASA).