idnits 2.17.1 draft-ietf-dhc-dhcpv6-reconfigure-rebind-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC3315, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (November 8, 2009) is 5282 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Evans 3 Internet-Draft ARRIS International, Inc. 4 Intended status: Informational R. Droms 5 Expires: May 12, 2010 Cisco Systems, Inc. 6 November 8, 2009 8 Rebind Capability in DHCPv6 Reconfigure Messages 9 draft-ietf-dhc-dhcpv6-reconfigure-rebind-07.txt 11 Abstract 13 This document updates RFC 3315 to allow the Rebind message type to 14 appear in the Reconfigure Message option of a Reconfigure message, 15 which extends the Reconfigure message to allow a DHCPv6 server to 16 cause a DHCPv6 client to send a Rebind message. The document also 17 clarifies how a DHCPv6 client responds to a received Reconfigure 18 message. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 12, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 1. Introduction 60 DHCPv6 [RFC3315] allows a server to send an unsolicited Reconfigure 61 message to a client. The client's response to a Reconfigure message, 62 according to section 19 of RFC 3315 is either a Renew or an 63 Information-Request message, depending on the contents of the msg- 64 type field in the Reconfigure Message option of the Reconfigure 65 message. 67 If the client sends a Renew message, it includes a Server Identifier 68 option in the Renew message to specify the server that should respond 69 to the Renew message. Under some circumstances, it may be desirable 70 for the client to communicate with a different server; for example, 71 if the server that the client most recently communicated with is no 72 longer available, the network administrator may want the client to 73 communicate with a different server. This document expands the 74 allowed values of the msg-type field to allow the server to indicate 75 that the client is to send a Rebind message, which does not include a 76 Server Identifier option and allows any server to respond to the 77 client. 79 RFC 3315 does not specify that a Reconfigure message must be sent 80 from the server with which the client most recently communicated, and 81 it does not specify which server the client should identify with a 82 Server Identifier option when the client responds to the Reconfigure 83 message. This document clarifies that the client should send a Renew 84 message in response to a Reconfigure message with a Server Identifier 85 option identifying the same server that the client would have 86 identified if the client had sent the Renew message after expiration 87 of T1. 89 2. Terminology 91 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 92 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 93 interpreted as described in [RFC2119]. 95 This document uses IPv6 and DHCPv6 terms as defined in section 4 of 96 RFC 3315. 98 3. The Reconfigure Message option of the DHCPv6 Reconfigure 99 Message 101 This section modifies section 22.19 of RFC 3315 to allow the 102 specification of the Rebind message in a Reconfigure message. 104 A server includes a Reconfigure Message option in a Reconfigure 105 message to indicate to the client whether the client responds with a 106 Renew, an Information-request, or a Rebind message. 108 The format of this option is: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | OPTION_RECONF_MSG | option-len | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | msg-type | 116 +-+-+-+-+-+-+-+-+ 118 option-code OPTION_RECONF_MSG (19). 119 option-len 1. 120 msg-type 5 for Renew message, 6 for Rebind, 11 for 121 Information-request message. 123 4. Server Behavior 125 This section updates specific text in sections 19.1, 19.2 and 19.3 of 126 RFC 3315. 128 The server MUST include a Reconfigure Message option (as defined in 129 Section 3) to select whether the client responds with a Renew 130 message, a Rebind message or an Information-Request message. 132 The Reconfigure message causes the client to initiate a Renew/Reply, 133 a Rebind/Reply message exchange or an Information-request/Reply 134 message exchange. The server interprets the receipt of a Renew, a 135 Rebind or an Information-request message (whichever was specified in 136 the original Reconfigure message) from the client as satisfying the 137 Reconfigure message request. 139 The server retransmits a Reconfigure message specifying a Rebind 140 message in the same way as described in section 19.1.2 of RFC 3315. 142 In response to a Rebind message, the server generates and sends a 143 Reply message to the client as described in sections 18.2.4 and 144 18.2.8, including options for configuration parameters. 146 The server MAY include options containing the IAs and new values for 147 other configuration parameters in the Reply message, even if those 148 IAs and parameters were not requested in the Renew message from the 149 client. 151 4.1. Client Behavior 153 This section updates specific text in section 19.4 of RFC 3315. 155 Upon receipt of a valid Reconfigure message, the client responds with 156 a Renew message, a Rebind message or an Information-request message 157 as indicated by the Reconfigure Message option (as defined in 158 Section 3). The client ignores the transaction-id field in the 159 received Reconfigure message. While the transaction is in progress, 160 the client silently discards any Reconfigure messages it receives. 162 When responding to a Reconfigure, the client creates and sends the 163 Rebind message in exactly the same manner as outlined in section 164 18.1.4 of RFC 3315, with the exception that the client copies the 165 Option Request option and any IA options from the Reconfigure message 166 into the Rebind message. 168 If a client is currently sending Rebind messages, as described in 169 section 18.1.4 of RFC 3315, the client ignores any received 170 Reconfigure messages. 172 The client uses the same variables and retransmission algorithm as it 173 does with Renew, Rebind or Information-request messages generated as 174 part of a client-initiated configuration exchange. See sections 175 18.1.3, 18.1.4 and 18.1.5 of RFC 3315 for details. If the client 176 does not receive a response from the server by the end of the 177 retransmission process, the client ignores and discards the 178 Reconfigure message. 180 5. Clarification of section 19.4.2, RFC 3315 182 When sending a Renew message in response to the receipt of a 183 Reconfigure message, the client MUST include a Server Identifier 184 option identifying the server the client most recently communicated 185 with. 187 6. Security Considerations 189 This document adds no new security considerations beyond those 190 present in RFC 3315. 192 7. IANA Considerations 194 There are no actions for IANA associated with this document. 196 8. Change log 198 This section MUST be removed before publication. 200 8.1. Revision -05 202 Clarified description of this feature in introduction. 204 Clarified action of client if it receives a Reconfigure while sending 205 Rebind messages. 207 8.2. Revision -06 209 Corrected a minor typo, changing "RFC3315" to "RFC 3315" in section 210 1. 212 8.3. Revision -07 214 Refreshed expired draft, no material changes. 216 9. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 222 and M. Carney, "Dynamic Host Configuration Protocol for 223 IPv6 (DHCPv6)", RFC 3315, July 2003. 225 Authors' Addresses 227 D. R. Evans 228 ARRIS International, Inc. 229 7912 Fairview Road 230 Boulder, CO 80303 231 USA 233 Phone: +1 303.494.0394 234 Email: N7DR@arrisi.com 236 Ralph Droms 237 Cisco Systems, Inc. 238 1414 Massachusetts Avenue 239 Boxborough, MA 01719 240 USA 242 Phone: +1 978.936.1674 243 Email: rdroms@cisco.com