idnits 2.17.1 draft-cui-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 13, 2015) is 3086 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 (~~), 2 warnings (==), 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: May 16, 2016 Tsinghua University 6 November 13, 2015 8 DHCPv6 Prefix Length Hint Issues 9 draft-cui-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 May 16, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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, encapsulated in an IA_PD option, with the "IPv6 78 prefix" field set to zero and the "prefix-length" field set to a non- 79 zero value. The delegating routers are free to ignore the hint 80 values depending on server policy. This would not cause problems for 81 some hint values such as T1 and T2 lifetimes, but it would be an 82 issue for the prefix-length hint. Some requesting routers can't 83 function normally when they're provided with a prefix which length is 84 different from what they requested. E.g. if the requesting router is 85 asking for a /56 and the delegating router returns a /64, the 86 functionality of the requesting router might be limited because it 87 might not be able to split the prefix for all its interfaces. The 88 requesting routers usually have higher preference on the prefix- 89 length hint than the other option hints, and it should be given more 90 consideration. 92 The current specification is unclear about how the requesting router 93 and delegating router should act in different situations involving 94 the prefix-length hint. From the requesting router perspective, it 95 should be able to use the prefix-length hint to signal to the 96 delegating router its real time need and it should be able to handle 97 the prefixes which lengths are different from the prefix-length hint. 98 This document provides guidance on what a requesting router should do 99 in different situations, to prevent it from failing. From the 100 delegating router perspective, the delegating router is free to 101 ignore the prefix-length hints depending on server policy, but in 102 cases where the delegating router has a policy for considering the 103 hint, this document provides guidance on how the prefix-length hint 104 should be handled by the delegating router in different situations. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Problem Description and Proposed Solutions 114 3.1. Creation of Solicit Message 116 Problem: 118 The Solicit message allows a requesting router to ask delegating 119 routers for prefixes and other configuration parameters. When the 120 requesting router's configuration changes, it might require a prefix 121 length different from what it had previously gotten. The delegating 122 router usually has a record of the prefix it delegated to the 123 requesting router during previous interactions. How should the 124 requesting router avoid getting the same prefix back from the 125 delegating router? 127 The delegating router could decide whether to provide the requesting 128 router with the preferred prefix depending on server policy, but the 129 requesting router should be able to signal to the delegating router 130 whether it wants a different prefix or the same prefix. The best way 131 to assure a completely new delegated prefix is to send a new IAID in 132 the IA_PD. However, this would require the requesting router device 133 to have persistant storage, since rebooting the device would cause 134 the 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 including the preferred prefix-length value in the "prefix- 141 length" field of the IA_PD Prefix option, and set the "IPv6 prefix" 142 field to zero. This is an indiction to the delegating router that 143 the requesting router prefers a prefix of specific length, regardless 144 of what it had gotten before. 146 When the requesting router wants the same prefix back from the 147 delegating router, it should include the prefix value in the "IPv6 148 prefix" field of the IA_PD Prefix option, and the length of the 149 prefix in the "prefix-length" field. This is an indication to the 150 delegating router that the requesting router wants the same prefix 151 back. 153 3.2. Receipt of Solicit message 155 Problem: 157 [RFC3633] allows a requesting router to include a prefix-length hint 158 in the Solicit message, to signal its preference to the delegating 159 router. However, it is unclear about how this prefix-length hint 160 should be handled by the delegating router. Some delegating routers 161 will keep a record about prefixes it gave to the requesting router 162 during previous interactions, and give the requesting router the same 163 prefix. When the requesting router includes a prefix-length hint in 164 the Solicit message, the delegating router has to decide whether to 165 honor the newly requested prefix-length hint or give the requesting 166 router the recorded prefix. The requesting router might want a 167 different prefix length due to configuration changes or it might just 168 want the same prefix again after reboot. The delegating router 169 should interpret these cases differently. 171 Many delegating routers are configured to provide only prefixes of 172 specific lengths to the requesting router. E.g. If the requesting 173 router requested for a /54, and the delegating router could only 174 provide /30,/48, and /56. How should these delegating routers decide 175 which prefix to give to the requesting router based on the requesting 176 router's prefix-length hint? 178 Solution: 180 Upon the receipt of Solicit message, if the requesting router 181 included only a prefix-length hint in the message, the delegating 182 router should try to honor the prefix-length hint within bounds of 183 what the delegating router is configured to return, regardless of the 184 prefix record from previous interactions with the requesting router. 185 The delegating router should regard the prefix-length hint in the 186 Solicit message as the prefix length most preferred by the requesting 187 router at the time. 189 If the requesting router included a specific prefix value and the 190 corresponding prefix-length value in the Solicit message, the 191 delegating router should first try to provide the requested prefix to 192 the requesting router. If the requested prefix is not available in 193 the delegating router's prefix pool, then the delegating router 194 should try to provide a prefix matching the prefix-length value. 196 The delegating router might not have prefixes exactly matching the 197 prefix-length hint. In this situation, the delegating router should 198 provide the shortest prefix length possible which is closest to the 199 prefix-length hint. E.g. If the delegating router could only 200 provide prefixes pf lengths /30,/48, and /56, and the requesting 201 router is requesting for a /50 in the prefix-length hint, then the 202 delegating router should provide the /48 to the requesting router. 204 3.3. Receipt of Advertise Message 206 Problem: 208 The delegating router might not be able to honor the prefix-length 209 hint due to server policy. If the prefix length provided by the 210 delegating router in the Advertise message is different from what the 211 requesting router requested in the Solicit message, the question 212 would be whether the requesting router should use the provided prefix 213 length or continue to ask for its preferred prefix length. There are 214 certain situations where the requesting router would fail if it used 215 a prefix which length is different from what it requested in the 216 prefix-length hint. However, if the requesting router ignores the 217 Advertise messages, and continues to solicit for the preferred prefix 218 length, the requesting router might be stuck in the DHCP process. 220 Solution: 222 If none of the prefixes provided by the delegating router in the 223 Advertise messages match the prefix-length hint the requesting router 224 included in the Solicit message, the requesting router could choose 225 to either accept or ignore the prefixes provided by the delegating 226 routers depending on functional need. 228 If the requesting router could use the prefixes provided by the 229 delegating routers despite being different from the prefix-length 230 hint, the requesting router should choose the shortest prefix length 231 which is closest to the prefix-length hint. 233 There are certain situations where the requesting router will fail if 234 it used a prefix which length does not meet its requirement. If the 235 requesting router cannot use the prefixes provided by the delegating 236 routers, it should ignore the Advertise messages and continue to send 237 Solicit messages until it gets the preferred prefix. To avoid 238 traffic congestion, the requesting router should send Solicit 239 messages at defined intervals, as specified in [RFC7083]. If the 240 requesting router also Solicited for IA_NAs, the requesting router 241 should accept the IA_NA addresses and continue to request for the 242 desired IA_PD prefix in subsequent DHCPv6 messages as specified in 243 [RFC7550]. 245 3.4. Creation of Renew/Rebind Message 247 Problem: 249 delegating routers might not be able to provide a prefix matching the 250 prefix-length hint requested by the requesting router. If the 251 requesting router decided to use the prefix provided by the 252 delegating router which doesn't match the prefix-length hint, but 253 would still prefer the prefix-length hint it originally requested in 254 the Solicit message, there should be some way for the requesting 255 router to express this preference during Renew/Rebind. E.g. If the 256 requesting router requested for a /60 but got a /64, the requesting 257 router should be able to signal to the delegating router during 258 Renew/Rebind that it would still prefer a /60. This is to see 259 whether the delegating router has the prefix preferred by the 260 requesting router available in its prefix pool during Renew/ 261 Rebind.[RFC3633] is not completely clear on whether the requesting 262 router is allowed to include a prefix-length hint in the Renew/Rebind 263 message. 265 Solution: 267 During the Renew process, if the requesting router prefers a prefix 268 length different from the prefix it is currently using, then the 269 requesting router should send the Renew message with the same IA_PD, 270 and include two IA_PD Prefix options, one containing the currently 271 delegated prefix and the other containing the prefix-length hint. 272 This is to extend lifetime of the prefix the requesting router is 273 currently using and also get the prefix the requesting router 274 prefers, and go through a graceful switch over. 276 If the delegating router is unable to provide the requesting router 277 with the newly requested prefix, the requesting router should 278 continue using the prefix it currently has. 280 3.5. Receipt of Renew/Rebind Message 282 Problem: 284 The prefix preferred by the requesting router might become available 285 in the delegating router's prefix pool during Renew/Rebind, but was 286 unavailable during Solicit. This might be due to delegating router 287 configuration change or because some other requesting router stopped 288 using the prefix. 290 The question is whether the delegating router should remember the 291 prefix-length hint the requesting router originally included in the 292 Solicit message and check during Renew/Rebind see if it has the 293 prefix length the requesting router preferred. This would require 294 the delegating router to keep extra information about the requesting 295 router. There is also the possibility that the requesting router's 296 preference for the prefix length might have changed during this time 297 interval, so the prefix-length hint remembered by the delegating 298 router might not be what the requesting router prefers during Renew/ 299 Rebind. 301 Instead of having the delegating router remember the prefix-length 302 hint of the requesting router, another option is for the requesting 303 router to include the prefix-length hint in the Renew/Rebind message. 304 The current specification is unclear about what the delegating router 305 should do if the requesting router also included in the Renew/Rebind 306 message a prefix-length hint value, and whether the delegating router 307 could provide a different prefix to the requesting router during 308 Renew/Rebind. 310 Solution: 312 Upon the receipt of Renew message, if the requesting router included 313 in the IA_PD both the delegated prefix value and a prefix-length hint 314 value, the delegating router should check to see whether it could 315 extend the lifetime of the original delegated prefix and whether it 316 has any available prefix matching the prefix-length hint, or as close 317 a possible to the requested length, within the delegating router's 318 limit. 320 The delegating router could do one of the following depending on 321 server policy: 323 1. Renew just the original delegated prefix. 325 2. Renew the original delegated prefix and assign a new prefix of 326 the requested length. 328 3. Mark the original delegated prefix as invalid by giving it 0 329 lifetimes, and asssign a new prefix of requested length. This avoids 330 the complexity of handling multiple delegated prefixes, but may break 331 all the existing connections of the requesting router. 333 4. Assign the original delegated prefix with 0 preferred-lifetime, a 334 short non-zero valid-lifetime, and asssign a new prefix of requested 335 length. This allows the requesting router to finish up existing 336 connections with the original prefix, and use the new prefix to 337 establish new connections. 339 5. Do not include the original delegated prefix in the Reply 340 message, and assign a new prefix of requested length. The original 341 prefix would be valid until it's lifetime expires. This avoids 342 sudden renumbering on the requesting router. 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 TBD. 355 5. IANA Considerations 357 This document does not include an IANA request. 359 6. Contributors List 361 Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, 362 Marcin Siodelski. 364 7. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 372 Host Configuration Protocol (DHCP) version 6", RFC 3633, 373 DOI 10.17487/RFC3633, December 2003, 374 . 376 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 377 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 378 2013, . 380 [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and 381 Recommendations with Multiple Stateful DHCPv6 Options", 382 RFC 7550, DOI 10.17487/RFC7550, May 2015, 383 . 385 Authors' Addresses 387 Yong Cui 388 Tsinghua University 389 Beijing 100084 390 P.R.China 392 Phone: +86-10-6260-3059 393 Email: yong@csnet1.cs.tsinghua.edu.cn 395 Tianxiang Li 396 Tsinghua University 397 Beijing 100084 398 P.R.China 400 Phone: +86-18301185866 401 Email: peter416733@gmail.com 403 Cong Liu 404 Tsinghua University 405 Beijing 100084 406 P.R.China 408 Phone: +86-10-6278-5822 409 Email: gnocuil@gmail.com