idnits 2.17.1 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03.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 (July 26, 2016) is 2830 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 T. Li 3 Internet-Draft C. Liu 4 Intended status: Standards Track Y. Cui 5 Expires: January 27, 2017 Tsinghua University 6 July 26, 2016 8 DHCPv6 Prefix Length Hint Issues 9 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03 11 Abstract 13 DHCPv6 Prefix Delegation [RFC3633] allows a client to include a 14 prefix-length hint value in the IA_PD option to indicate a preference 15 for the size of the prefix to be delegated, but is unclear about how 16 the client and server should act in different situations involving 17 the prefix-length hint. This document provides a summary of the 18 existing problems with the prefix-length hint and guidance on what 19 the client and server could do in different situations. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 27, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Description and Proposed Solutions . . . . . . . . . 3 58 3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3 59 3.2. Receipt of Solicit message . . . . . . . . . . . . . . . 4 60 3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5 61 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 5 62 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 63 3.6. General Recommendation . . . . . . . . . . . . . . . . . 8 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 client to include a 73 prefix-length hint value in the message sent to the server, to 74 indicate a preference for the size of the prefix to be delegated. A 75 prefix-length hint is communicated by a client to the server by 76 including an IA_PD Prefix Option(IAPREFIX option), encapsulated in an 77 IA_PD option, with the "IPv6 prefix" field set to zero and the 78 "prefix-length" field set to a non-zero value. The servers are free 79 to ignore the prefix-length hint values depending on server policy. 80 However, some clients may not be able to function (or only in a 81 degraded state) when they're provided with a prefix which length is 82 different from what they requested. E.g. If the client is asking 83 for a /56 and the server returns a /64, the functionality of the 84 client might be limited because it might not be able to split the 85 prefix for all its interfaces. For other hints, such as requesting 86 for a explicit address, this might be less critical as it just helps 87 a client that wishes to continue using what it used last time. The 88 prefix-length hint directly impacts the operational capability of the 89 client, thus should be given more consideration. 91 [RFC3633] is unclear about how the client and server should act in 92 different situations involving the prefix-length hint. From the 93 client perspective, it should be able to use the prefix-length hint 94 to signal to the server its real time need and it should be able to 95 handle prefixes with lengths different from the prefix-length hint. 96 This document provides guidance on what a client should do in 97 different situations to help it operate properly. From the server 98 perspective, the server is free to ignore the prefix-length hints 99 depending on server policy, but in cases where the server has a 100 policy for considering the hint, this document provides guidance on 101 how the prefix-length hint should be handled by the server in 102 different situations. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Problem Description and Proposed Solutions 112 3.1. Creation of Solicit Message 114 Problem: 116 The Solicit message allows a client to ask servers for prefixes and 117 other configuration parameters. The client might want a different 118 prefix length due to configuration changes or it might just want the 119 same prefix again after reboot. The client might also prefer a 120 prefix of specific length in case the requested prefix is not 121 available. The server could decide whether to provide the client 122 with the preferred prefix depending on server policy, but the client 123 should be able to signal to the server its real time need. 125 The servers usually has a record of the prefix it gave to the client 126 during previous interactions. The best way to assure a completely 127 new delegated prefix is to send a new IAID in the IA_PD. However, 128 this would require the client device to have persistant storage, 129 since rebooting the device would cause the client to use the original 130 IAID in the IA_PD. 132 Solution: 134 When the client prefers a prefix of specific length from the server, 135 the client MUST send a Solicit message using the same IAID in the 136 IAPD, include the preferred prefix-length value in the "prefix- 137 length" field of the IAPREFIX option, and set the "IPv6 prefix" field 138 to zero. This is an indiction to the server that the client prefers 139 a prefix of the specified length, regardless of what it had gotten 140 before. 142 When the client wants the same prefix back from the server, it MUST 143 send a Solicit message using the same IAID in the IAPD, include the 144 previously delegated prefix value in the "IPv6 prefix" field of the 145 IAPREFIX option, and the length of the prefix in the "prefix-length" 146 field. This is an indication to the server that the client wants the 147 same prefix back. 149 When the client wants the same prefix back from the server, and would 150 prefer to accept a prefix of specified length in case the requested 151 prefix is not avaiable, the client MUST send a Solicit message using 152 the same IAID in the IAPD, include the previously delegated prefix in 153 one IAPREFIX option, and include the prefix-length hint in another 154 IAPREFIX option. 156 3.2. Receipt of Solicit message 158 Problem: 160 [RFC3633] allows a client to include a prefix-length hint in the 161 Solicit message, to signal its preference to the server. It is 162 unclear about how the prefix-length hint should be handled by the 163 server. The client might want a different prefix length due to 164 configuration changes or it might just want the same prefix again 165 after reboot. The server should interpret these cases differently. 167 Many servers are configured to provide only prefixes of specific 168 lengths to the client. E.g. If the client requested for a /54, and 169 the server could only provide /30, /48, and /56. How should these 170 servers decide which prefix to give to the client based on the 171 prefix-length hint? 173 Solution: 175 Upon the receipt of Solicit message, if the client included only a 176 prefix-length hint in the message, the server SHOULD first check its 177 prefix pool for a prefix with length matching the prefix-length hint 178 value, regardless of the prefix record from previous interactions 179 with the client. If the server does not have a prefix with length 180 matching the prefix-length hint value, then the server SHOULD provide 181 the prefix with the shortest length possible which is closest to the 182 prefix-length hint value. 184 If the client included a specific prefix value in the Solicit 185 message, the server SHOULD check its prefix pool for a prefix 186 matching the requested prefix value. If the requested prefix is not 187 available in the server's prefix pool, and the client also included a 188 prefix-length hint in the same IA_PD option, then the server SHOULD 189 try to provide a prefix matching the prefix-length value, or the 190 prefix with the shortest length possible which is closest to the 191 prefix-length hint value. 193 3.3. Receipt of Advertise Message 195 Problem: 197 The server might not be able to honor the prefix-length hint due to 198 server policy or lack of resources in its prefix pool. If the prefix 199 length provided by the server in the Advertise message is different 200 from what the client requested in the Solicit message, the question 201 would be whether the client should use the provided prefix length or 202 continue to ask for its preferred prefix length. There are certain 203 situations where the client could not operate properly if it used a 204 prefix which length is different from what it requested in the 205 prefix-length hint. However, if the client ignores the Advertise 206 messages, and continues to solicit for the preferred prefix length, 207 the client might be stuck in the DHCP process. Another question is 208 whether the client should ignore other configuration parameters such 209 as available addresses. 211 Solution: 213 If the client could use the prefixes included in the Advertise 214 messages despite being different from the prefix-length hint, the 215 client SHOULD choose the shortest prefix length which is closest to 216 the prefix-length hint. The client SHOULD continue requesting for 217 the preferred prefix in the subsequent DHCPv6 messages as defined in 218 section 3.4 of this document 220 If the client Solicted for only IA_PDs and cannot use the prefixes 221 included in the Advertise messages, it MUST ignore the Advertise 222 messages and continue to send Solicit messages until it gets the 223 preferred prefix. To avoid traffic congestion, the client MUST send 224 Solicit messages at defined intervals, as specified in [RFC7083]. 226 If the client also Solicited for other stateful configuration options 227 such as IA_NAs and the client cannot use the prefixes included in the 228 Advertise messages, the client SHOULD accept the other stateful 229 configuration options and continue to request for the desired IA_PD 230 prefix in subsequent DHCPv6 messages as specified in [RFC7550]. 232 3.4. Creation of Renew/Rebind Message 234 Problem: 236 servers might not be able to provide a prefix with length equal or 237 shorter than the prefix-length hint. If the client decided to use 238 the prefix provided by the server despite being longer than the 239 prefix-length hint, but would still prefer the prefix-length hint it 240 originally requested in the Solicit message, there should be some way 241 for the client to express this preference during Renew/Rebind. E.g. 242 If the client requested for a /60 but got a /64, the client should be 243 able to signal to the server during Renew/Rebind that it would still 244 prefer a /60. This is to see whether the server has the prefix 245 preferred by the client available in its prefix pool during Renew/ 246 Rebind. [RFC3633] is not completely clear on whether the client is 247 allowed to include a prefix-length hint in the Renew/Rebind message. 249 Solution: 251 During Renew/Rebind, if the client prefers a prefix length different 252 from the prefix it is currently using, then the client SHOULD send 253 the Renew/Rebind message with the same IA_PD, and include two 254 IAPREFIX options, one containing the currently delegated prefix and 255 the other containing the prefix-length hint. This is to extend the 256 lifetime of the prefix the client is currently using and also get the 257 prefix the client prefers, and go through a graceful switch over. 259 If the server is unable to provide the client with the newly 260 requested prefix, but is able to extend lifetime of the old prefix, 261 the client SHOULD continue using the old prefix. 263 3.5. Receipt of Renew/Rebind Message 265 Problem: 267 The prefix preferred by the client might become available in the 268 server's prefix pool during Renew/Rebind, but was unavailable during 269 Solicit. This might be due to server configuration change or because 270 some other client stopped using the prefix. 272 The question is whether the server should remember the prefix-length 273 hint the client originally included in the Solicit message and check 274 during Renew/Rebind to see if it has the prefix length the client 275 preferred. This would require the server to keep extra information 276 about the client. There is also the possibility that the client's 277 preference for the prefix length might have changed during this time 278 interval, so the prefix-length hint remembered by the server might 279 not be what the client prefers during Renew/Rebind. 281 Instead of having the server remember the prefix-length hint of the 282 client, another option is for the client to include the prefix-length 283 hint in the Renew/Rebind message. The current specification is 284 unclear about what the server should do if the client also included 285 in the Renew/Rebind message a prefix-length hint value, and whether 286 the server could provide a different prefix to the client during 287 Renew/Rebind. 289 Solution: 291 Upon the receipt of Renew/Rebind, if the client included in the IA_PD 292 both an IAPREFIX option with the delegated prefix value and an 293 IAPREFIX option with a prefix-length hint value, the server SHOULD 294 check to see whether it could extend the lifetime of the original 295 delegated prefix and whether it has any available prefix matching the 296 prefix-length hint, or as close a possible to the prefix-length hint, 297 within the server's limit. 299 If the server assigned the prefix included in IA_PD to the client, 300 the server SHOULD do one of the following, depending on its policy: 302 1. Extend lifetime of the original delegated prefix. 304 2. Extend lifetime of the original delegated prefix and assign a new 305 prefix of the requested length. 307 3. Mark the original delegated prefix as invalid by giving it 0 308 lifetimes, and assign a new prefix of requested length. This avoids 309 the complexity of handling multiple delegated prefixes, but may break 310 all the existing connections of the client. 312 4. Assign the original delegated prefix with 0 preferred-lifetime, a 313 short non-zero valid-lifetime, and assign a new prefix of requested 314 length. This allows the client to finish up existing connections 315 with the original prefix, and use the new prefix to establish new 316 connections. 318 5. Do not include the original delegated prefix in the Reply 319 message, and assign a new prefix of requested length. The original 320 prefix would be valid until it's lifetime expires. This avoids 321 sudden renumbering on the client. 323 If the server does not know the client's bindings(e.g. a different 324 server receiving the message during Rebind), then the server SHOULD 325 ignore the original delegated prefix, and try to assign a new prefix 326 of requested length. 328 It's unnecessary for the server to remember the prefix-length hint 329 the client requested during Solicit. It is possible that the 330 client's preference for the prefix length might have changed during 331 this time interval, so the prefix-length hint in the Renew message is 332 reflecting what the client prefers at the time. 334 3.6. General Recommendation 336 The recommendation to address the issues discussed in this document, 337 is for a client that wants (at least) to have a delegated prefix of a 338 specific prefix length to always include an IAPREFIX option with just 339 the prefix-length hint in addition to any IAPREFIX options it has 340 included for each IA_PD in any Solicit, Request, Renew, and Rebind 341 messages it sends. While a server is free to ignore the hint, 342 servers that do not choose to ignore the hint should attempt to 343 assign a prefix of at least the hint length (or shorter) if one is 344 available. Whether a server favors the hint or avoiding a 345 renumbering event is a matter of server policy. 347 4. Security Considerations 349 This document introduces no new security considerations over those 350 already discussed in section 15 of RFC3633, as this document provides 351 guidance on how the clients and servers interact with regard to the 352 prefix-length hint mechanism introduced 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 Tianxiang Li 387 Tsinghua University 388 Beijing 100084 389 P.R.China 391 Phone: +86-18301185866 392 Email: peter416733@gmail.com 394 Cong Liu 395 Tsinghua University 396 Beijing 100084 397 P.R.China 399 Phone: +86-10-6278-5822 400 Email: gnocuil@gmail.com 402 Yong Cui 403 Tsinghua University 404 Beijing 100084 405 P.R.China 407 Phone: +86-10-6260-3059 408 Email: yong@csnet1.cs.tsinghua.edu.cn