idnits 2.17.1 draft-ietf-dhc-dhcpv6-srsn-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 (February 4, 2009) is 5559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 793 (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 (==), 4 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: August 8, 2009 February 4, 2009 7 DHCPv6 Server Reply Sequence Number Option 8 draft-ietf-dhc-dhcpv6-srsn-option-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This memo defines the Server Reply Sequence Number option for the 48 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option 49 is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay 50 agent to detect proper sequencing of Relay-Reply messages that could 51 be delivered out of order. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The Server Reply Sequence Number Option . . . . . . . . . . . . 3 58 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 59 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security considerations . . . . . . . . . . . . . . . . . . . . 6 62 8. Modification History . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 When a DHCPv6 server sends a Reply, there is no guarantee as to the 71 order of delivery of those datagrams sent by a server. A DHCPv6 72 client is protected against delivery of old Reply messages because of 73 the transaction-id in the message. However, a relay agent receiving 74 Relay-Reply messages and maintaining client state information (e.g., 75 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] has no such technique. Thus 76 a delayed earlier Relay-Reply may arrive after other Relay-Reply 77 messages. As an example, suppose a client sends a Request, the Reply 78 (encapsulated in a Relay-Reply) is delayed between server and relay 79 agent. The client retransmits the Request, the retransmitted Reply 80 is processed through the relay agent and then by the client. The 81 client next transacts a Release/Reply sequence, which causes the 82 relay agent to remove the client's state information when relaying 83 the Relay-Reply. However, now the delayed first Request's Reply 84 arrives at the relay agent; if the relay agent were to update the 85 client's state based on this out of order message (e.g., 86 [I-D.ietf-dhc-dhcpv6-agentopt-delegate]), it would add client state 87 that is no longer valid. The Server Reply Sequence Number (SRSN) 88 option can be used to prevent this as the relay agent can detect and 89 discard out of order message. 91 To allow a relay agent to detect and discard out of order messages, 92 the relay agent requests the server to include a SRSN option in 93 Relay-Reply messages. The SRSN option contains a monotonically 94 increasing sequence number that the relay agent can use to re- 95 sequence (or discard) out of order Relay-Reply messages from the 96 server. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 Additional terms used in the description of DHCPv6 and DHCPv6 prefix 105 delegation are defined in [RFC3315] and [RFC3633]. 107 3. The Server Reply Sequence Number Option 109 The SRSN option is used by a server to indicate the order in which 110 the server has generated replies and therefore allows a relay agent 111 receiving Relay-Reply messages to determine the order in which those 112 Relay-Reply messages were originally sent. The Relay-Reply messages 113 are sent via UDP and, therefore, may be delivered out of order. 115 The server's sequence number in the SRSN is a monotonically 116 increasing series. This property is maintained by the server even if 117 the server loses internal state; e.g., if the server is restarted. 118 The value of the sequence number in the SRSN option is not related to 119 the contents of any options in the Relay-Reply message; the existence 120 of this sequence number does not indicate that any data at the server 121 has necessarily changed. 123 The DHCPv6 Server Reply Sequence Number Option has the following 124 format: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | option-code | length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | 132 + server-reply-sequence-number + 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 option-code OPTION_SRSN (TBD). 138 length 8. 140 server-reply-sequence-number 141 The 64-bit monotonically increasing server reply 142 sequence number. 144 4. DHCPv6 Relay Agent Behavior 146 If a relay agent requires the server to provide the SRSN option, it 147 MUST include an Option Request option, requesting the SRSN option, as 148 described in section 22.7 of [RFC3315]. 150 A relay agent MUST save the received server-reply-sequence-number 151 (and the server's Server Identifier Option, OPTION_SERVERID) with any 152 client state information extracted from a Relay-Reply if it needs to 153 assure it does not use out of date information. 155 A relay agent that uses the SRSN option needs do the following when 156 maintaining client state information: 158 1. Only update existing client state information if the received 159 server-reply-sequence-number (if from the same server) is greater 160 than the stored server-reply-sequence-number for the information; 161 the received server-reply-sequence-number and Server Identifier 162 must be stored with the client state information. 164 2. Delay removing expired client state information from its storage 165 for at least the maximum lifetime of a datagram. This assures 166 that any undelivered Relay-Reply datagrams will have expired and 167 been dropped from the network; and thus the server-reply- 168 sequence-number checking will prevent outdated information from 169 being used. A value of 2 minutes is the recommended value for 170 the maximum datagram lifetime, based on the maximum segment 171 lifetime used by the Transmission Control Protocol (TCP) 172 [RFC0793]. 174 A change in the server-reply-sequence-number MUST NOT be used to 175 assume a client's state has changed, as a server may be 176 retransmitting the same information but with a different server- 177 reply-sequence-number. 179 5. DHCPv6 Server Behavior 181 If a relay agent has requested the SRSN option in an ORO, the server 182 SHOULD return the option with a monotonically increasing sequence 183 number. And, the server MUST also include a Server Identifier Option 184 (OPTION_SERVER_ID) in the Relay-Reply if it includes the SRSN option. 186 The server MUST monotonically increase the sequence number for any 187 Relay-Reply messages it transmits which include a SRSN option. A 188 server MAY increase the sequence number for each message it 189 transmits, even those that do not include a SRSN option. 191 One technique for a server to provide the monotonically increasing 192 sequence number is by splitting the 64-bit number into two 32-bit 193 values (minding network/host byte ordering) - a major (most 194 significant bits) and minor sequence number. When the server starts, 195 the major sequence number is set to the current time (in seconds 196 since Jan 1, 1970). The minor sequence number is set to 0 and only 197 it is incremented while the server is running (except if it rolls 198 over, in which case the major sequence number MUST be updated); there 199 is no need to commit the sequence number to stable storage. 201 6. IANA considerations 203 IANA is requested to assign an option code from the "DHCPv6 and 204 DHCPv6 options" registry, 205 http://www.iana.org/assignments/dhcpv6-parameters, to OPTION_SRSN. 207 7. Security considerations 209 Security issues related to DHCP are described in [RFC3315] and 210 [RFC3633]. 212 The DHCPv6 Server Reply Sequence Number option may be used to mount a 213 denial of service attack by causing a relay agent to incorrectly 214 record a very high server-reply-sequence-number and thus preventing 215 legitimate Relay-Reply messages from a server from being processed. 216 Communication between a server and a relay agent, and communication 217 between relay agents, can be secured through the use of IPSec, as 218 described in section 21.1 of [RFC3315]. 220 8. Modification History 222 Changes in rev -02: None except boiler plate, version number, and 223 date. 225 Changes in rev -01 (to fix idnits): 226 o Revised terminology section to match recommended RFC 2119 syntax. 227 o Used new I-D boilerplate. 228 o Added this section. 230 9. References 232 9.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 238 and M. Carney, "Dynamic Host Configuration Protocol for 239 IPv6 (DHCPv6)", RFC 3315, July 2003. 241 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 242 Host Configuration Protocol (DHCP) version 6", RFC 3633, 243 December 2003. 245 9.2. Informative References 247 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 248 RFC 793, September 1981. 250 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 251 Droms, R., "DHCPv6 Relay Agent Assignment Notification 252 (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 253 (work in progress), November 2006. 255 Authors' Addresses 257 Bernie Volz 258 Cisco Systems, Inc. 259 1414 Massachusetts Avenue 260 Boxborough, MA 01719 261 USA 263 Phone: +1 978.936.0382 264 Email: volz@cisco.com 266 Ralph Droms 267 Cisco Systems, Inc. 268 1414 Massachusetts Avenue 269 Boxborough, MA 01719 270 USA 272 Phone: +1 978.936.1674 273 Email: rdroms@cisco.com