idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.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 contain references ([RFC3633]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2016) is 2920 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7550 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Y. Cui 3 Internet-Draft T. Li 4 Intended status: Informational C. Liu 5 Expires: October 30, 2016 Tsinghua University 6 April 28, 2016 8 DHCPv6 Prefix Length Hint Issues 9 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01 11 Abstract 13 DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to 14 include a prefix-length hint value in the IA_PD option to indicate a 15 preference for the size of the prefix to be delegated, but is unclear 16 about how the requesting router and delegating router should act in 17 different situations involving the prefix-length hint. This document 18 provides a summary of the existing problems with the prefix-length 19 hint and guidance on what the requesting router and delegating router 20 could do in different situations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 30, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Description and Proposed Solutions . . . . . . . . . 3 59 3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3 60 3.2. Receipt of Solicit message . . . . . . . . . . . . . . . 4 61 3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5 62 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6 63 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to 73 include a prefix-length hint value in the message sent to the 74 delegating router, to indicate a preference for the size of the 75 prefix to be delegated. A prefix-length hint is communicated by a 76 requesting router to the delegating router by including an IA_PD 77 Prefix Option(OPTION_IAPREFIX), encapsulated in an IA_PD option, with 78 the "IPv6 prefix" field set to zero and the "prefix-length" field set 79 to a non-zero value. The delegating routers are free to ignore the 80 prefix-length hint values depending on server policy. However, some 81 requesting routers can't function normally when they're provided with 82 a prefix which length is different from what they requested. E.g. 83 If the requesting router is asking for a /56 and the delegating 84 router returns a /64, the functionality of the requesting router 85 might be limited because it might not be able to split the prefix for 86 all its interfaces. 88 [RFC3633] is unclear about how the requesting router and delegating 89 router should act in different situations involving the prefix-length 90 hint. From the requesting router perspective, it should be able to 91 use the prefix-length hint to signal to the delegating router its 92 real time need and it should be able to handle the prefixes which 93 lengths are different from the prefix-length hint. This document 94 provides guidance on what a requesting router should do in different 95 situations to help it operate properly. From the delegating router 96 perspective, the delegating router is free to ignore the prefix- 97 length hints depending on server policy, but in cases where the 98 delegating router has a policy for considering the hint, this 99 document provides guidance on how the prefix-length hint should be 100 handled by the delegating router in different situations. 102 2. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Problem Description and Proposed Solutions 110 3.1. Creation of Solicit Message 112 Problem: 114 The Solicit message allows a requesting router to ask delegating 115 routers for prefixes and other configuration parameters. When the 116 requesting router's configuration changes, it might require a prefix 117 length different from what it had previously gotten. The delegating 118 router usually has a record of the prefix it delegated to the 119 requesting router during previous interactions. How should the 120 requesting router avoid getting the same prefix back from the 121 delegating router? 123 The delegating router could decide whether to provide the requesting 124 router with the preferred prefix depending on server policy, but the 125 requesting router should be able to signal to the delegating router 126 whether it wants a different prefix or the same prefix. The best way 127 to assure a completely new delegated prefix is to send a new IAID in 128 the IA_PD. However, this would require the requesting router device 129 to have persistant storage, since rebooting the device would cause 130 the requesting router to use the original IAID in the IA_PD. 132 Solution: 134 When the requesting router prefers a prefix of specific length from 135 the delegating router, the requesting router SHOULD send a Solicit 136 message including the preferred prefix-length value in the "prefix- 137 length" field of the OPTION_IAPREFIX option, and set the "IPv6 138 prefix" field to zero. This is an indiction to the delegating router 139 that the requesting router prefers a prefix of specific length, 140 regardless of what it had gotten before. 142 When the requesting router wants the same prefix back from the 143 delegating router, it SHOULD include the prefix value in the "IPv6 144 prefix" field of the OPTION_IAPREFIX option, and the length of the 145 prefix in the "prefix-length" field. This is an indication to the 146 delegating router that the requesting router wants the same prefix 147 back. 149 3.2. Receipt of Solicit message 151 Problem: 153 [RFC3633] allows a requesting router to include a prefix-length hint 154 in the Solicit message, to signal its preference to the delegating 155 router. It is unclear about how this prefix-length hint should be 156 handled by the delegating router, whether to honor the prefix-length 157 hint or provide the prefix from previous interactions with the 158 requesting router. The requesting router might want a different 159 prefix length due to configuration changes or it might just want the 160 same prefix again after reboot. The delegating router should 161 interpret these cases differently. 163 Many delegating routers are configured to provide only prefixes of 164 specific lengths to the requesting router. E.g. If the requesting 165 router requested for a /54, and the delegating router could only 166 provide /30, /48, and /56. How should these delegating routers 167 decide which prefix to give to the requesting router based on the 168 prefix-length hint? 170 Solution: 172 Upon the receipt of Solicit message, if the requesting router 173 included only a prefix-length hint in the message, the delegating 174 router SHOULD try to honor the prefix-length hint within bounds of 175 what the delegating router is configured to return, regardless of the 176 prefix record from previous interactions with the requesting router. 177 The delegating router SHOULD regard the prefix-length hint in the 178 Solicit message as the prefix length most preferred by the requesting 179 router at the time. 181 If the requesting router included a specific prefix value and the 182 corresponding prefix-length value in the Solicit message, the 183 delegating router SHOULD first try to provide the requested prefix to 184 the requesting router. If the requested prefix is not available in 185 the delegating router's prefix pool, then the delegating router 186 SHOULD try to provide a prefix matching the prefix-length value. 188 The delegating router might not have prefixes exactly matching the 189 prefix-length hint. In this situation, the delegating router SHOULD 190 provide the shortest prefix length possible which is closest to the 191 prefix-length hint. E.g. If the delegating router could only 192 provide prefixes of lengths /30, /48, and /56, and the requesting 193 router is requesting for a /50 in the prefix-length hint, then the 194 delegating router should provide the /48 to the requesting router. 196 3.3. Receipt of Advertise Message 198 Problem: 200 The delegating router might not be able to honor the prefix-length 201 hint due to server policy. If the prefix length provided by the 202 delegating router in the Advertise message is different from what the 203 requesting router requested in the Solicit message, the question 204 would be whether the requesting router should use the provided prefix 205 length or continue to ask for its preferred prefix length. There are 206 certain situations where the requesting router could not operate 207 properly if it used a prefix which length is different from what it 208 requested in the prefix-length hint. However, if the requesting 209 router ignores the Advertise messages, and continues to solicit for 210 the preferred prefix length, the requesting router might be stuck in 211 the DHCP process. 213 Solution: 215 If none of the prefixes provided by the delegating router in the 216 Advertise messages are equal or shorter than the prefix-length hint 217 the requesting router included in the Solicit message, the requesting 218 router could choose to either accept or ignore the prefixes provided 219 by the delegating routers depending on functional need. 221 If the requesting router could use the prefixes provided by the 222 delegating routers despite being different from the prefix-length 223 hint, the requesting router SHOULD choose the shortest prefix length 224 which is closest to the prefix-length hint. 226 There are certain situations where the requesting router could not 227 operate if it used a prefix which length does not meet its 228 requirement. If the requesting router cannot use the prefixes 229 provided by the delegating routers, it SHOULD ignore the Advertise 230 messages and continue to send Solicit messages until it gets the 231 preferred prefix. To avoid traffic congestion, the requesting router 232 SHOULD send Solicit messages at defined intervals, as specified in 233 [RFC7083]. If the requesting router also Solicited for IA_NAs, the 234 requesting router SHOULD accept the IA_NA addresses and continue to 235 request for the desired IA_PD prefix in subsequent DHCPv6 messages as 236 specified in [RFC7550].. 238 3.4. Creation of Renew/Rebind Message 240 Problem: 242 Delegating routers might not be able to provide a prefix with length 243 equal or shorter than the prefix-length hint. If the requesting 244 router decided to use the prefix provided by the delegating router 245 despite being longer than the prefix-length hint, but would still 246 prefer the prefix-length hint it originally requested in the Solicit 247 message, there should be some way for the requesting router to 248 express this preference during Renew/Rebind. E.g. If the requesting 249 router requested for a /60 but got a /64, the requesting router 250 should be able to signal to the delegating router during Renew/Rebind 251 that it would still prefer a /60. This is to see whether the 252 delegating router has the prefix preferred by the requesting router 253 available in its prefix pool during Renew/Rebind. [RFC3633] is not 254 completely clear on whether the requesting router is allowed to 255 include a prefix-length hint in the Renew/Rebind message. 257 Solution: 259 During Renew/Rebind, if the requesting router prefers a prefix length 260 different from the prefix it is currently using, then the requesting 261 router SHOULD send the Renew/Rebind message with the same IA_PD, and 262 include two OPTION_IAPREFIX options, one containing the currently 263 delegated prefix and the other containing the prefix-length hint. 264 This is to extend the lifetime of the prefix the requesting router is 265 currently using and also get the prefix the requesting router 266 prefers, and go through a graceful switch over. 268 If the delegating router is unable to provide the requesting router 269 with the newly requested prefix, but is able to extend lifetime of 270 the old prefix, the requesting router SHOULD continue using the old 271 prefix. 273 3.5. Receipt of Renew/Rebind Message 275 Problem: 277 The prefix preferred by the requesting router might become available 278 in the delegating router's prefix pool during Renew/Rebind, but was 279 unavailable during Solicit. This might be due to delegating router 280 configuration change or because some other requesting router stopped 281 using the prefix. 283 The question is whether the delegating router should remember the 284 prefix-length hint the requesting router originally included in the 285 Solicit message and check during Renew/Rebind to see if it has the 286 prefix length the requesting router preferred. This would require 287 the delegating router to keep extra information about the requesting 288 router. There is also the possibility that the requesting router's 289 preference for the prefix length might have changed during this time 290 interval, so the prefix-length hint remembered by the delegating 291 router might not be what the requesting router prefers during Renew/ 292 Rebind. 294 Instead of having the delegating router remember the prefix-length 295 hint of the requesting router, another option is for the requesting 296 router to include the prefix-length hint in the Renew/Rebind message. 297 The current specification is unclear about what the delegating router 298 should do if the requesting router also included in the Renew/Rebind 299 message a prefix-length hint value, and whether the delegating router 300 could provide a different prefix to the requesting router during 301 Renew/Rebind. 303 Solution: 305 Upon the receipt of Renew/Rebind, if the requesting router included 306 in the IA_PD both OPTION_IAPREFIX option with the delegated prefix 307 value and an OPTION_IAPREFIX option with a prefix-length hint value, 308 the delegating router SHOULD check to see whether it could extend the 309 lifetime of the original delegated prefix and whether it has any 310 available prefix matching the prefix-length hint, or as close a 311 possible to the prefix-length hint, within the delegating router's 312 limit. 314 If the delegating router assigned the prefix included in IA_PD to the 315 requesting router, the delegating router SHOULD do one of the 316 following, depending on its policy: 318 1. Extend lifetime of the original delegated prefix. 320 2. Extend lifetime of the original delegated prefix and assign a new 321 prefix of the requested length. 323 3. Mark the original delegated prefix as invalid by giving it 0 324 lifetimes, and assign a new prefix of requested length. This avoids 325 the complexity of handling multiple delegated prefixes, but may break 326 all the existing connections of the requesting router. 328 4. Assign the original delegated prefix with 0 preferred-lifetime, a 329 short non-zero valid-lifetime, and assign a new prefix of requested 330 length. This allows the requesting router to finish up existing 331 connections with the original prefix, and use the new prefix to 332 establish new connections. 334 5. Do not include the original delegated prefix in the Reply 335 message, and assign a new prefix of requested length. The original 336 prefix would be valid until it's lifetime expires. This avoids 337 sudden renumbering on the requesting router. 339 If the delegating router does not know the requesting router's 340 bindings(e.g. a different delegating router receiving the message 341 during Rebind), then the delegating router SHOULD ignore the original 342 delegated prefix, and try to assign a new prefix of requested length. 344 It's unnecessary for the delegating router to remember the prefix- 345 length hint the requesting router requested during Solicit. It is 346 possible that the requesting router's preference for the prefix 347 length might have changed during this time interval, so the prefix- 348 length hint in the Renew message is reflecting what the requesting 349 router prefers at the time. 351 4. Security Considerations 353 This document introduces no new security considerations over those 354 already discussed in section 15 of RFC3633, as this document provides 355 guidance on how the requesting routers and delegating routers 356 interact with regard to the prefix-length hint mechanism introduced 357 in RFC3633. 359 5. IANA Considerations 361 This document does not include an IANA request. 363 6. Contributors List 365 Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, 366 Marcin Siodelski. 368 7. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 376 Host Configuration Protocol (DHCP) version 6", RFC 3633, 377 DOI 10.17487/RFC3633, December 2003, 378 . 380 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 381 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 382 2013, . 384 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 385 Recommendations with Multiple Stateful DHCPv6 Options", 386 RFC 7550, DOI 10.17487/RFC7550, May 2015, 387 . 389 Authors' Addresses 391 Yong Cui 392 Tsinghua University 393 Beijing 100084 394 P.R.China 396 Phone: +86-10-6260-3059 397 Email: yong@csnet1.cs.tsinghua.edu.cn 399 Tianxiang Li 400 Tsinghua University 401 Beijing 100084 402 P.R.China 404 Phone: +86-18301185866 405 Email: peter416733@gmail.com 407 Cong Liu 408 Tsinghua University 409 Beijing 100084 410 P.R.China 412 Phone: +86-10-6278-5822 413 Email: gnocuil@gmail.com