idnits 2.17.1 draft-droms-dhc-dhcpv6-solmaxrt-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (December 9, 2011) is 4521 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 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track December 9, 2011 5 Expires: June 11, 2012 7 Modification to Default Value of SOL_MAX_RT 8 draft-droms-dhc-dhcpv6-solmaxrt-update-00 10 Abstract 12 This document updates RFC 3315 by redefining the default value for 13 SOL_MAX_RT and defining an option through which a DHCPv6 server can 14 override the client's default value for SOL_MAX_RT with a new value. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 11, 2012. 33 Copyright Notice 35 Copyright (c) 2011 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. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Introduction 50 Section 5.5 of the DHCPv6 specification [RFC3315] defines the default 51 value of SOL_MAX_RT to be 120 seconds. In some circumstances, this 52 default will lead to an unacceptably high volume of aggregated 53 traffic at a DHCPv6 server. 55 1.1. Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 2. Update to RC 3315 63 This document changes section 5.5 of RFC 3315 as follows: 65 OLD: 66 SOL_MAX_RT 120 secs Max Solicit timeout value 68 NEW: 69 SOL_MAX_RT 3600 secs Max Solicit timeout value 71 With this change, a DHCPv6 client that does not receive a 72 satisfactory response will send Solicit messages with the same 73 initial frequency and exponential backoff as specified in RFC 3315. 74 However, the long term behavior of these DHCPv6 clients will be to 75 send a Solicit message every 3600 seconds rather than every 120 76 seconds, significantly reducing the aggregated traffic at the DHCPv6 77 server. 79 The change to SOL_MAX_RT is in response to DHCPv6 message rates 80 observed at a DHCPv6 server in a deployment in which many DHCPv6 81 clients are sending Solicit messages but the DHCPv6 server has been 82 configured not to respond to those Solicit messages. RFC 3315 was 83 written with the expectation that the 'M' and 'O' flags in NDP 84 [RFC2461] would control the use of DHCPv6 by hosts. However, the 85 current definition of the 'M' and 'O' flags in RFC 4861 [RFC4861] 86 does not explicitly preclude the use of DHCPv6 by a host. Some 87 devices are specified to initiate DHCPv6 even if RAs are received 88 with the 'M' and 'O' bits set to 0. In some circumstances, it is 89 desirable to enable the assignment of IPv6 addresses through DHCPv6 90 to some nodes on a link but not to others, which cannot be 91 implemented through the 'M' and 'O' bits. 93 3. SOL_MAX_RT option 95 A DHCPv6 server sends the SOL_MAX_RT option to a client to override 96 the default value of SOL_MAX_RT. One use for the SOL_MAX_RT option 97 is to set a longer value for SOL_MAX_RT, which reduces the Solicit 98 traffic from a client that has not received any IPv6 addresses. 100 The format of the SOL_MAX_RT option is: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | option-code | option-len | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | SOL_MAX_RT value | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 option-code OPTION_SOL_MAX_RT (TBD). 112 option-len 4. 114 SOL_MAX_RT value Overriding value for SOL_MAX_RT in seconds. 116 Figure 1 118 If the DHCPv6 server declines to assign any addresses to a client in 119 an IA_NA or IA_TA option, it MAY include a SOL_MAX_RT option in the 120 appropriate options field along with a Status Code option indicating 121 NoAddrsAvail. 123 If a DHCPv6 client receives an IA_NA or IA_TA option containing a 124 SOL_MAX_RT option, the client MUST set its internal SOL_MAX_RT 125 parameter to the value contained in the SOL_MAX_RT option. 127 4. Security Considerations 129 This document introduces one security considerations beyond those 130 described in RFC 3315. A malicious DHCPv6 server might cause a 131 client to set its SOL_MAX_RT parameter to an arbitrarily high value 132 with the SOL_MAX_RT option. Assuming the client also receives a 133 response from a valid DHCPv6 server, the large value for SOL_MAX_RT 134 will not have any effect. 136 5. IANA Considerations 138 IANA is requested to assign an options code from the "DHCP Option 139 Codes" Registry for OPTION_SOL_MAX_RT. 141 6. Normative References 143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", BCP 14, RFC 2119, March 1997. 146 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 147 Discovery for IP Version 6 (IPv6)", RFC 2461, 148 December 1998. 150 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 151 and M. Carney, "Dynamic Host Configuration Protocol for 152 IPv6 (DHCPv6)", RFC 3315, July 2003. 154 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 155 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 156 September 2007. 158 Author's Address 160 Ralph Droms 161 Cisco Systems 162 1414 Massachusetts Avenue 163 Boxborough, MA 01719 164 USA 166 Phone: +1 978 936 1674 167 Email: rdroms@cisco.com