idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.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 (June 19, 2016) is 2866 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 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: Standards Track C. Liu 5 Expires: December 21, 2016 Tsinghua University 6 June 19, 2016 8 DHCPv6 Prefix Length Hint Issues 9 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 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 December 21, 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 . . . . . . . . . . . . 5 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 may not be able to function (or only in a degraded 82 state) when they're provided with a prefix which length is different 83 from what they requested. E.g. If the requesting router is asking 84 for a /56 and the delegating router returns a /64, the functionality 85 of the requesting router might be limited because it might not be 86 able to split the prefix for all its interfaces. For other hints, 87 such as requesting for a explicit address or lifetime, this might be 88 less critical as it just help a client that wishes to continue using 89 what it used last time, or a client that wants to Renew its lease for 90 a certain period of time. The prefix-length hint directly impacts 91 the operational capability of the requesting router, thus should be 92 given more consideration. 94 [RFC3633] is unclear about how the requesting router and delegating 95 router should act in different situations involving the prefix-length 96 hint. From the requesting router perspective, it should be able to 97 use the prefix-length hint to signal to the delegating router its 98 real time need and it should be able to handle the prefixes which 99 lengths are different from the prefix-length hint. This document 100 provides guidance on what a requesting router should do in different 101 situations to help it operate properly. From the delegating router 102 perspective, the delegating router is free to ignore the prefix- 103 length hints depending on server policy, but in cases where the 104 delegating router has a policy for considering the hint, this 105 document provides guidance on how the prefix-length hint should be 106 handled by the delegating router in different situations. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Problem Description and Proposed Solutions 116 3.1. Creation of Solicit Message 118 Problem: 120 The Solicit message allows a requesting router to ask delegating 121 routers for prefixes and other configuration parameters. The 122 requesting router might want a different prefix length due to 123 configuration changes or it might just want the same prefix again 124 after reboot. The delegating router could decide whether to provide 125 the requesting router with the preferred prefix depending on server 126 policy, but the requesting router should be able to signal to the 127 delegating router its real time need. 129 The delegating routers usually has a record of the prefix it gave to 130 the requesting router during previous interactions. The best way to 131 assure a completely new delegated prefix is to send a new IAID in the 132 IA_PD. However, this would require the requesting router device to 133 have persistant storage, since rebooting the device would cause the 134 requesting router to use the original IAID in the IA_PD. 136 Solution: 138 When the requesting router prefers a prefix of specific length from 139 the delegating router, the requesting router SHOULD send a Solicit 140 message using the same IAID in the IAPD, include the preferred 141 prefix-length value in the "prefix-length" field of the 142 OPTION_IAPREFIX option, and set the "IPv6 prefix" field to zero. 143 This is an indiction to the delegating router that the requesting 144 router prefers a prefix of the specified length, regardless of what 145 it had gotten before. 147 When the requesting router wants the same prefix back from the 148 delegating router, it SHOULD send a Solicit message using the same 149 IAID in the IAPD, include the previously delegated prefix value in 150 the "IPv6 prefix" field of the OPTION_IAPREFIX option, and the length 151 of the prefix in the "prefix-length" field. This is an indication to 152 the delegating router that the requesting router wants the same 153 prefix back. 155 3.2. Receipt of Solicit message 157 Problem: 159 [RFC3633] allows a requesting router to include a prefix-length hint 160 in the Solicit message, to signal its preference to the delegating 161 router. It is unclear about how the prefix-length hint should be 162 handled by the delegating router. The requesting router might want a 163 different prefix length due to configuration changes or it might just 164 want the same prefix again after reboot. The delegating router 165 should interpret these cases differently. 167 Many delegating routers are configured to provide only prefixes of 168 specific lengths to the requesting router. E.g. If the requesting 169 router requested for a /54, and the delegating router could only 170 provide /30, /48, and /56. How should these delegating routers 171 decide which prefix to give to the requesting router based on the 172 prefix-length hint? 174 Solution: 176 Upon the receipt of Solicit message, if the requesting router 177 included only a prefix-length hint in the message, the delegating 178 router SHOULD first check its prefix pool for a prefix with length 179 matching the prefix-length hint value, regardless of the prefix 180 record from previous interactions with the requesting router. If the 181 delegating router does not have a prefix with length matching the 182 prefix-length hint value, then the delegating router SHOULD provide 183 the prefix with the shortest length possible which is closest to the 184 prefix-length hint value. 186 If the requesting router included a specific prefix value and the 187 corresponding prefix-length value in the Solicit message, the 188 delegating router SHOULD first try to check its prefix pool for a 189 prefix matching the requested prefix value. If the requested prefix 190 is not available in the delegating router's prefix pool, then the 191 delegating router SHOULD try to provide a prefix matching the prefix- 192 length value, or the prefix with the shortest length possible which 193 is closest to the prefix-length value. 195 3.3. Receipt of Advertise Message 197 Problem: 199 The delegating router might not be able to honor the prefix-length 200 hint due to server policy or lack of resources in its prefix pool. 201 If the prefix length provided by the delegating router in the 202 Advertise message is different from what the requesting router 203 requested in the Solicit message, the question would be whether the 204 requesting router should use the provided prefix length or continue 205 to ask for its preferred prefix length. There are certain situations 206 where the requesting router could not operate properly if it used a 207 prefix which length is different from what it requested in the 208 prefix-length hint. However, if the requesting router ignores the 209 Advertise messages, and continues to solicit for the preferred prefix 210 length, the requesting router might be stuck in the DHCP process. 211 Another question is whether the requesting router should ignore other 212 configuration parameters such as available addresses. 214 Solution: 216 If the requesting router could use the prefixes provided by the 217 delegating routers despite being different from the prefix-length 218 hint, the requesting router SHOULD choose the shortest prefix length 219 which is closest to the prefix-length hint. 221 If the requesting router cannot use the prefixes provided by the 222 delegating routers, it MUST ignore the Advertise messages and 223 continue to send Solicit messages until it gets the preferred prefix. 224 To avoid traffic congestion, the requesting router MUST send Solicit 225 messages at defined intervals, as specified in [RFC7083]. 227 If the requesting router also Solicited for other stateful 228 configuration options such as IA_NAs, the requesting router SHOULD 229 accept the stateful configuration options and continue to request for 230 the desired IA_PD prefix in subsequent DHCPv6 messages as specified 231 in [RFC7550]. 233 3.4. Creation of Renew/Rebind Message 235 Problem: 237 Delegating routers might not be able to provide a prefix with length 238 equal or shorter than the prefix-length hint. If the requesting 239 router decided to use the prefix provided by the delegating router 240 despite being longer than the prefix-length hint, but would still 241 prefer the prefix-length hint it originally requested in the Solicit 242 message, there should be some way for the requesting router to 243 express this preference during Renew/Rebind. E.g. If the requesting 244 router requested for a /60 but got a /64, the requesting router 245 should be able to signal to the delegating router during Renew/Rebind 246 that it would still prefer a /60. This is to see whether the 247 delegating router has the prefix preferred by the requesting router 248 available in its prefix pool during Renew/Rebind. [RFC3633] is not 249 completely clear on whether the requesting router is allowed to 250 include a prefix-length hint in the Renew/Rebind message. 252 Solution: 254 During Renew/Rebind, if the requesting router prefers a prefix length 255 different from the prefix it is currently using, then the requesting 256 router SHOULD send the Renew/Rebind message with the same IA_PD, and 257 include two OPTION_IAPREFIX options, one containing the currently 258 delegated prefix and the other containing the prefix-length hint. 259 This is to extend the lifetime of the prefix the requesting router is 260 currently using and also get the prefix the requesting router 261 prefers, and go through a graceful switch over. 263 If the delegating router is unable to provide the requesting router 264 with the newly requested prefix, but is able to extend lifetime of 265 the old prefix, the requesting router SHOULD continue using the old 266 prefix. 268 3.5. Receipt of Renew/Rebind Message 270 Problem: 272 The prefix preferred by the requesting router might become available 273 in the delegating router's prefix pool during Renew/Rebind, but was 274 unavailable during Solicit. This might be due to delegating router 275 configuration change or because some other requesting router stopped 276 using the prefix. 278 The question is whether the delegating router should remember the 279 prefix-length hint the requesting router originally included in the 280 Solicit message and check during Renew/Rebind to see if it has the 281 prefix length the requesting router preferred. This would require 282 the delegating router to keep extra information about the requesting 283 router. There is also the possibility that the requesting router's 284 preference for the prefix length might have changed during this time 285 interval, so the prefix-length hint remembered by the delegating 286 router might not be what the requesting router prefers during Renew/ 287 Rebind. 289 Instead of having the delegating router remember the prefix-length 290 hint of the requesting router, another option is for the requesting 291 router to include the prefix-length hint in the Renew/Rebind message. 292 The current specification is unclear about what the delegating router 293 should do if the requesting router also included in the Renew/Rebind 294 message a prefix-length hint value, and whether the delegating router 295 could provide a different prefix to the requesting router during 296 Renew/Rebind. 298 Solution: 300 Upon the receipt of Renew/Rebind, if the requesting router included 301 in the IA_PD both OPTION_IAPREFIX option with the delegated prefix 302 value and an OPTION_IAPREFIX option with a prefix-length hint value, 303 the delegating router SHOULD check to see whether it could extend the 304 lifetime of the original delegated prefix and whether it has any 305 available prefix matching the prefix-length hint, or as close a 306 possible to the prefix-length hint, within the delegating router's 307 limit. 309 If the delegating router assigned the prefix included in IA_PD to the 310 requesting router, the delegating router SHOULD do one of the 311 following, depending on its policy: 313 1. Extend lifetime of the original delegated prefix. 315 2. Extend lifetime of the original delegated prefix and assign a new 316 prefix of the requested length. 318 3. Mark the original delegated prefix as invalid by giving it 0 319 lifetimes, and assign a new prefix of requested length. This avoids 320 the complexity of handling multiple delegated prefixes, but may break 321 all the existing connections of the requesting router. 323 4. Assign the original delegated prefix with 0 preferred-lifetime, a 324 short non-zero valid-lifetime, and assign a new prefix of requested 325 length. This allows the requesting router to finish up existing 326 connections with the original prefix, and use the new prefix to 327 establish new connections. 329 5. Do not include the original delegated prefix in the Reply 330 message, and assign a new prefix of requested length. The original 331 prefix would be valid until it's lifetime expires. This avoids 332 sudden renumbering on the requesting router. 334 If the delegating router does not know the requesting router's 335 bindings(e.g. a different delegating router receiving the message 336 during Rebind), then the delegating router SHOULD ignore the original 337 delegated prefix, and try to assign a new prefix of requested length. 339 It's unnecessary for the delegating router to remember the prefix- 340 length hint the requesting router requested during Solicit. It is 341 possible that the requesting router's preference for the prefix 342 length might have changed during this time interval, so the prefix- 343 length hint in the Renew message is reflecting what the requesting 344 router prefers at the time. 346 4. Security Considerations 348 This document introduces no new security considerations over those 349 already discussed in section 15 of RFC3633, as this document provides 350 guidance on how the requesting routers and delegating routers 351 interact with regard to the prefix-length hint mechanism introduced 352 in RFC3633. 354 5. IANA Considerations 356 This document does not include an IANA request. 358 6. Contributors List 360 Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, 361 Marcin Siodelski. 363 7. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 371 Host Configuration Protocol (DHCP) version 6", RFC 3633, 372 DOI 10.17487/RFC3633, December 2003, 373 . 375 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 376 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 377 2013, . 379 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 380 Recommendations with Multiple Stateful DHCPv6 Options", 381 RFC 7550, DOI 10.17487/RFC7550, May 2015, 382 . 384 Authors' Addresses 386 Yong Cui 387 Tsinghua University 388 Beijing 100084 389 P.R.China 391 Phone: +86-10-6260-3059 392 Email: yong@csnet1.cs.tsinghua.edu.cn 394 Tianxiang Li 395 Tsinghua University 396 Beijing 100084 397 P.R.China 399 Phone: +86-18301185866 400 Email: peter416733@gmail.com 402 Cong Liu 403 Tsinghua University 404 Beijing 100084 405 P.R.China 407 Phone: +86-10-6278-5822 408 Email: gnocuil@gmail.com