idnits 2.17.1 draft-cui-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 11, 2015) is 3113 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) Summary: 3 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: Standards Track C. Liu 5 Expires: April 13, 2016 Tsinghua University 6 October 11, 2015 8 DHCPv6 Prefix Length Hint Issues 9 draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01 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 April 13, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Creation of Solicit Message by the Client . . . . . . . . 3 59 3.2. Receipt of Solicit message by the Server . . . . . . . . 3 60 3.3. Receipt of Advertise Message by the Client . . . . . . . 4 61 3.4. Creation of Renew/Rebind Message by the Client . . . . . 4 62 3.5. Receipt of Renew/Rebind Message by the Server . . . . . . 4 63 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Creation of Solicit Message by the Client . . . . . . . . 5 65 4.2. Receipt of Solicit message by the Server . . . . . . . . 5 66 4.3. Receipt of Advertise Message by the Client . . . . . . . 6 67 4.4. Creation of Renew/Rebind Message by the Client . . . . . 6 68 4.5. Receipt of Renew/Rebind Message by the Server . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 DHCPv6 Prefix Delegation [RFC3633] allows a client to include a 78 prefix-length hint value in the message sent to the server, to 79 indicate a preference for the size of the prefix to be delegated. A 80 prefix-length hint is communicated by a client to the server by 81 including an IA_PD Prefix Option, encapsulated in an IA_PD option, 82 with the "IPv6 prefix" field set to zero and the "prefix-length" 83 field set to a non-zero value. The servers are free to ignore the 84 hint values depending on server policy. This would not cause 85 problems for some hint values such as T1 and T2 lifetimes, but it 86 would be an issue for the prefix-length hint. Some clients can't 87 function normally when they're provided with a prefix which length is 88 different from what they requested. E.g. if the client is asking for 89 a /56 and the server returns a /64, the functionality of the client 90 might be limited because it might not be able to split the prefix for 91 all its interfaces. The clients usually have higher preference on 92 the prefix-length hint than the other option hints, and it should be 93 given more consideration. 95 The current specification is unclear about how the client and server 96 should act in different situations involving the prefix-length hint. 98 From the client perspective, it should be able to use the prefix- 99 length hint to signal to the server its real time need and it should 100 be able to handle the prefixes which lengths are different from the 101 prefix-length hint. This document provides guidance on what a client 102 should do in different situations, to prevent it from failing. From 103 the server perspective, the server is free to ignore the prefix- 104 length hints depending on server policy, but in cases where the 105 server has a policy for considering the hint, this document provides 106 guidance on how the prefix-length hint should be handled by the 107 server in different situations. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Problem Description 117 3.1. Creation of Solicit Message by the Client 119 The Solicit message allows a client to ask servers for addresses and 120 configuration parameters. When the client's configuration changes, 121 it might require a prefix length different from what it had 122 previously gotten. The server usually has a record of the prefix it 123 delegated to the client during previous interactions. How should the 124 client avoid getting the same prefix back from the server? 126 The server could decide whether to provide the client with the 127 preferred prefix depending on server policy, but the client should be 128 able to signal to the server that it wants a different prefix. The 129 best way to assure a completely new delegated prefix is to send a new 130 IAID in the IA_PD. However, this would require the client device to 131 have persistant storage, since rebooting the device would cause the 132 client to use the original IAID in the IA_PD. 134 3.2. Receipt of Solicit message by the Server 136 [RFC3633] allows a client to include a prefix-length hint in the 137 Solicit message, to signal its preference to the server. However, it 138 is unclear about how this prefix-length hint should be handled by the 139 server. Some servers will keep a record about prefixes it gave to 140 the client during previous interactions, and give the client the same 141 prefix. When the client includes a prefix-length hint in the Solicit 142 message, the server has to decide whether to honor the newly 143 requested prefix-length hint or give the client the recorded prefix. 144 The client might want a different prefix length due to configuration 145 changes or it might just want the same prefix again after reboot. 147 The server should interpret these cases differently. 149 Many servers are configured to provide only prefixes of specific 150 lengths to the client. E.g. If the client requested for a /54, and 151 the server could only provide /30,/48, and /56. How should these 152 servers decide which prefix to give to the client based on the 153 client's prefix-length hint? 155 3.3. Receipt of Advertise Message by the Client 157 The server might not be able to honor the prefix-length hint due to 158 server policy. If the prefix length provided by the server in the 159 Advertise message is different from what the client requested in the 160 Solicit message, the question would be whether the client should use 161 the provided prefix length or continue to ask for its preferred 162 prefix length. There are certain situations where the client would 163 fail if it used a prefix which length is different from what it 164 requested in the prefix-length hint. However, if the client ignores 165 the Advertise messages, and continues to solicit for the preferred 166 prefix length, the client might be stuck in the DHCP process. 168 3.4. Creation of Renew/Rebind Message by the Client 170 Servers might not be able to provide a prefix matching the prefix- 171 length hint requested by the client. If the client decided to use 172 the prefix provided by the server which doesn't match the prefix- 173 length hint, but would still prefer the prefix-length hint it 174 originally requested in the Solicit message, there should be some way 175 for the client to express this preference during Renew/Rebind. E.g. 176 If the client requested for a /60 but got a /64, the client should be 177 able to signal to the server during Renew/Rebind that it would still 178 prefer a /60. This is to see whether the server has the prefix 179 preferred by the client available in its prefix pool during Renew/ 180 Rebind.[RFC3633] is not completely clear on whether the client is 181 allowed to include a prefix-length hint in the Renew/Rebind message. 183 3.5. Receipt of Renew/Rebind Message by the Server 185 The prefix preferred by the client might become available in the 186 server's prefix pool during Renew/Rebind, but was unavailable during 187 Solicit. This might be due to server configuration change or because 188 some other client stopped using the prefix. 190 The question is whether the server should remember the prefix-length 191 hint the client originally included in the Solicit message and check 192 during Renew/Rebind see if it has the prefix length the client 193 preferred. This would require the server to keep extra information 194 about the client. There is also the possibility that the client's 195 preference for the prefix length might have changed during this time 196 interval, so the prefix-length hint remembered by the server might 197 not be what the client prefers during Renew/Rebind. 199 Instead of having the server remember the prefix-length hint of the 200 client, another option is for the client to include the prefix-length 201 hint in the Renew/Rebind message. The current specification is 202 unclear about what the server should do if the client also included 203 in the Renew/Rebind message a prefix-length hint value, and whether 204 the server could provide a different prefix to the client during 205 Renew/Rebind. 207 4. Proposed Solution 209 4.1. Creation of Solicit Message by the Client 211 When the client prefers a prefix of specific length from the server, 212 the client should send a Solicit message including the preferred 213 prefix-length value in the "prefix-length" field of the IA_PD Prefix 214 option, and set the "IPv6 prefix" field to zero. This is an 215 indiction to the server that the client prefers a prefix of specific 216 length, regardless of what it had gotten before. 218 When the client wants the same prefix back from the server, it should 219 include the prefix value in the "IPv6 prefix" field of the IA_PD 220 Prefix option, and the length of the prefix in the "prefix-length" 221 field. This is an indication to the server that the client wants the 222 same prefix back. 224 4.2. Receipt of Solicit message by the Server 226 Upon the receipt of Solicit message, if the client included a prefix- 227 length hint in the message, the server should try to honor the 228 prefix-length hint within bounds of what the server is configured to 229 return, regardless of the prefix record from previous interactions 230 with the client. The server should regard the prefix-length hint in 231 the Solicit message as the prefix length most preferred by the client 232 at the time. 234 Many servers are configured to provide prefixes of specific lengths 235 to the client. In this situation, the server should provide the 236 shortest prefix length possible which is closest to the prefix-length 237 hint. E.g. If the server could only provide prefixes with lengths 238 /30,/48, and /56, and the client is requesting for a /50 in the 239 prefix-length hint, then the server should provide the /48 to the 240 client. 242 4.3. Receipt of Advertise Message by the Client 244 If none of the prefixes provided by the server in the Advertise 245 messages match the prefix-length hint the client included in the 246 Solicit message, the client could choose to either accept or ignore 247 the prefixes provided by the servers depending on functional need. 249 If the client could use the prefixes provided by the servers despite 250 being different from the prefix-length hint, the client should choose 251 a prefix length closest to the prefix-length hint. 253 There are certain situations where the client will fail if it used a 254 prefix which length does not meet its requirement. If the client 255 cannot use the prefixes provided by the servers, it should ignore the 256 Advertise messages and continue to send Solicit messages until it 257 gets the preferred prefix. To avoid traffic congestion, the client 258 should send Solicit messages at defined intervals, as specified in 259 [RFC7083]. To prevent the client from not functioning, the client 260 should not ignore other configuration parameters provided by the 261 server such as available IA_NA addresses. 263 4.4. Creation of Renew/Rebind Message by the Client 265 During the Renew process, if the client prefers a prefix length 266 different from the prefix it is currently using, then the client 267 should send the Renew message with the same IA_PD, and include two 268 IA_PD Prefix options, one containing the currently delegated prefix 269 and the other containing the prefix-length hint. This is to extend 270 lifetime of the prefix the client is currently using and also get the 271 prefix the client prefers, and go through a graceful switch over. 273 If the server is unable to provide the client with the newly 274 requested prefix, the client should continue using the prefix it 275 currently has. 277 4.5. Receipt of Renew/Rebind Message by the Server 279 Upon the receipt of Renew message, if the client included in the 280 IA_PD both the delegated prefix value and a prefix-length hint value, 281 the server should check to see whether it could extend the lifetime 282 of the original delegated prefix and whether it has any available 283 prefix matching the prefix-length hint, or as close a possible to the 284 requested length, within the server's limit. 286 The server could do one of the following depending on server policy: 288 1. Renew just the original delegated prefix. 290 2. Renew the original delegated prefix and assign a new prefix of 291 the requested length. 293 3. Mark the original delegated prefix as invalid by giving it 0 294 lifetimes, and asssign a new prefix of requested length. This avoids 295 the complexity of handling multiple delegated prefixes, but may break 296 all the existing connections of the client. 298 4. Assign the original delegated prefix with 0 preferred-lifetime, a 299 short non-zero valid-lifetime, and asssign a new prefix of requested 300 length. This is to provide the original delegated prefix with a 301 short lifetime so the client can go through a graceful switch over. 303 It's unnecessary for the server to remember the prefix-length hint 304 the client requested during Solicit. It is possible that the 305 client's preference for the prefix length might have changed during 306 this time interval, so the prefix-length hint in the Renew message is 307 reflecting what the client prefers at the time. 309 5. Security Considerations 311 TBD. 313 6. IANA Considerations 315 This document does not include an IANA request. 317 7. Contributors List 319 Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar. 321 8. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, 325 DOI 10.17487/RFC2119, March 1997, 326 . 328 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 329 Host Configuration Protocol (DHCP) version 6", RFC 3633, 330 DOI 10.17487/RFC3633, December 2003, 331 . 333 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 334 and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 335 2013, . 337 Authors' Addresses 339 Yong Cui 340 Tsinghua University 341 Beijing 100084 342 P.R.China 344 Phone: +86-10-6260-3059 345 Email: yong@csnet1.cs.tsinghua.edu.cn 347 Tianxiang Li 348 Tsinghua University 349 Beijing 100084 350 P.R.China 352 Phone: +86-18301185866 353 Email: peter416733@gmail.com 355 Cong Liu 356 Tsinghua University 357 Beijing 100084 358 P.R.China 360 Phone: +86-10-6278-5822 361 Email: gnocuil@gmail.com