idnits 2.17.1 draft-ietf-6man-addr-select-opt-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A: Automatic Row Addition flag. This flag toggles the Automatic Row Addition flag at client hosts, which is described in the section 2.1 in RFC 3484 revision [I-D.ietf-6man-rfc3484bis]. If this flag is set to 1, it does not change client host behavior, that is, a client MAY automatically add additional site-specific rows to the policy table. If set to 0, the Automatic Row Addition flag is disabled, and a client MAY NOT automatically add rows to the policy table. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 23, 2012) is 4261 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) == Unused Reference: 'I-D.ietf-6man-stable-privacy-addresses' is defined on line 351, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-00 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-05) exists of draft-ietf-6man-addr-select-considerations-04 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Standards Track NTT 5 Expires: February 24, 2013 T. Chown 6 University of Southampton 7 August 23, 2012 9 Distributing Address Selection Policy using DHCPv6 10 draft-ietf-6man-addr-select-opt-05.txt 12 Abstract 14 RFC 3484 defines default address selection mechanisms for IPv6 that 15 allow nodes to select appropriate address when faced with multiple 16 source and/or destination addresses to choose between. The RFC 3484 17 allowed for the future definition of methods to administratively 18 configure the address selection policy information. This document 19 defines a new DHCPv6 option for such configuration, allowing a site 20 administrator to distribute address selection policy overriding the 21 default address selection parameters and policy table, and thus 22 control the address selection behavior of nodes in their site. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 24, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 1. Introduction 70 RFC 3484 [RFC3484] describes default algorithms for selecting an 71 address when a node has multiple destination and/or source addresses 72 to choose from by using an address selection policy. In Section 2 of 73 RFC 3484, it is suggested that the default policy table may be 74 administratively configured to suit the specific needs of a site. 75 This specification defines a new DHCPv6 option for such 76 configuration. 78 Some problems have been identified with the default RFC 3484 address 79 selection policy [RFC5220]. It is unlikely that any default policy 80 will suit all scenarios, and thus mechanisms to control the source 81 address selection policy will be necessary. Requirements for those 82 mechanisms are described in [RFC5221], while solutions are discussed 83 in [I-D.ietf-6man-addr-select-sol] and 84 [I-D.ietf-6man-addr-select-considerations]. Those documents have 85 helped shape the improvements in the default address selection 86 algorithm [I-D.ietf-6man-rfc3484bis] as well as the DHCPv6 option 87 defined in this specification. 89 1.1. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 1.2. Terminology 97 This document uses the terminology defined in [RFC2460] and the 98 DHCPv6 specification defined in [RFC3315] 100 2. Address Selection options 102 The Address Selection option provides the address selection policy 103 table, and some other configuration parameters. 105 A address selection option contains zero or more policy table 106 options. Multiple policy table options in a Policy Table option 107 constitute a single policy table. 109 The format of the Address Selection option is given below. 111 0 1 2 3 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | OPTION_ADDRSEL | option-len | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Reserved |A|P| | 117 +-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS | 118 | (variable length) | 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: Address Selection option format 124 option-code: OPTION_ADDRSEL (TBD). 126 option-len: The total length of the Reserved field, A, P flags, and 127 POLICY TABLE OPITONS in octets. 129 Reserved: Reserved field. Server MUST set this value to zero and 130 client MUST ignore its content. 132 A: Automatic Row Addition flag. This flag toggles the Automatic 133 Row Addition flag at client hosts, which is described in the 134 section 2.1 in RFC 3484 revision [I-D.ietf-6man-rfc3484bis]. If 135 this flag is set to 1, it does not change client host behavior, 136 that is, a client MAY automatically add additional site-specific 137 rows to the policy table. If set to 0, the Automatic Row 138 Addition flag is disabled, and a client MAY NOT automatically 139 add rows to the policy table. 141 P: Privacy Preference flag. This flag toggles the Privacy 142 Preference flag at client hosts, which is described in the 143 section 5 in RFC 3484 revision [I-D.ietf-6man-rfc3484bis]. If 144 this flag is set to 1, it does not change client host behavior, 145 that is, a client SHOULD prefer temporary addresses. If set to 146 0, the Privacy Preference flag is disabled, and a client SHOULD 147 prefer public addresses. 149 POLICY TABLE OPTIONS: Zero or more Address Selection Policy Table 150 options described below. 152 0 1 2 3 153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | OPTION_ADDRSEL_TABLE | option-len | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | label | precedence | prefix-len | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 159 | | 160 | prefix (variable length) | 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 . Prefix Specific options . 165 . . 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 2: Address Selection Policy Table option format 170 option-code: OPTION_ADDRSEL_TABLE (TBD). 172 option-len: The total length of the label field, precedence field, 173 prefix-len field, prefix field, and DASP options field in 174 octets. 176 label: An 8-bit unsigned integer; this value is used to make a 177 combination of source address prefixes and destination address 178 prefixes. 180 precedence: An 8-bit unsigned integer; this value is used for 181 sorting destination addresses. 183 prefix-len: An 8-bit unsigned integer; the number of leading bits in 184 the prefix that are valid. The value ranges from 0 to 128. 186 prefix: A variable-length field containing an IP address or the 187 prefix of an IP address. An IPv4-mapped address [RFC4291] must 188 be used to represent an IPv4 address as a prefix value. The 189 Prefix should be truncated on the byte boundary. So the length 190 of this field should be between 0 and 16 bytes. 192 Prefix Specific options: Options specific to this particular Address 193 Selection Policy option. This includes, but not limited to, 194 zero or one Zone Index option that specify the zone index of the 195 prefix in this option. 197 The format of the Zone Index option is given below. 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | OPTION_ADDRSEL_ZONE | option-len | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | zone-index | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 3: Zone Index option format 209 option-code: OPTION_ADDRSEL_ZONE (TBD). 211 option-len: 4. 213 zone-index: The zone-index field is an 32-bit unsigned integer, and 214 used to specify the zone for scoped addresses. The zone-index 215 is defined in RFC 3493 [RFC3493] as 'scope ID'. 217 3. Appearance of the Address Selection options 219 The Address Selection options MUST NOT appear in any messages other 220 than the following ones: Solicit, Advertise, Request, Renew, Rebind, 221 Reconfigure, Information-Request, and Reply. 223 4. Processing the Policy Table option 225 This section describes how to process received Policy Table option at 226 the DHCPv6 client. 228 This option's concept is to serve as a hint for a node about how to 229 behave in the network. So, basically, it should be up to the node's 230 administrator how to deal with the received policy information in the 231 way described below. 233 4.1. Handling of the local policy table 235 RFC 3484 defines the default policy table. Also, a user is usually 236 able to configure the policy table to satisfy his requirement. 238 The client implementation SHOULD provide the following choices to the 239 user: 241 a) It receives distributed policy table, and replaces the existing 242 policy tables with that. 243 b) It preserves the default policy table, or manually configured 244 policy. 246 4.2. Handling of the stale policy table 248 When the information from the DHCP server goes stale, the policy 249 received form the DHCP server should be removed and the default 250 policy should be restored. 252 The received information can be considered stale in several cases, 253 such as, when the interface goes down, the DHCP server does not 254 respond for a certain amount of time, and the Information Refresh 255 Time is expired. 257 4.3. Multi-interface situation 259 The policy table, and other parameters specified in this document are 260 node-global information by its nature. So, the node cannot use 261 multiple received policies at the same time. In other words, once 262 the received policy from one source is merged with one from another 263 source, the effect of both policy are more or less changed. The 264 policy table is defined as a whole, so the slightest addition/ 265 deletion from the policy table brings a change in semantics of the 266 policy. 268 It also should be noted that absence of the distributed policy from a 269 certain network interface should not be treated as absence of policy 270 itself, because it may mean preference for the default address 271 selection policy. 273 Under the above assumptions, how to handle received policy is 274 specified below. 276 A node MAY use Address Selection options by default in any of the 277 following two cases: 279 1: The host is single-homed, where the host belongs to one 280 administrative network domain exclusively usually through one 281 active network interface. 282 2: The host implements some advanced heuristics to deal with multiple 283 received policy, which is outside the scope of this document. 285 The above restrictions do not preclude implementations from providing 286 configuration options to enable this option on a certain network 287 interface. 289 5. Implementation Considerations 291 o The value 'label' is passed as an unsigned integer, but there is 292 no special meaning for the value, that is whether it is a large or 293 small number. It is used to select a preferred source address 294 prefix corresponding to a destination address prefix by matching 295 the same label value within the DHCP message. DHCPv6 clients need 296 to convert this label to a representation specified by each 297 implementation (e.g., string). 299 o Currently, the label and precedence values are defined as 8-bit 300 unsigned integers. In almost all cases, this value will be 301 enough. 303 o The maximum number of address selection rules that may be conveyed 304 in one DHCPv6 message depends on the prefix length of each rule 305 and the maximum DHCPv6 message size defined in RFC 3315. It is 306 possible to carry over 3,000 rules in one DHCPv6 message (maximum 307 UDP message size). However, it should not be expected that DHCP 308 clients, servers and relay agents can handle UDP fragmentation. 309 So, the number of the options and the total size of the options 310 should be taken care of. 312 o Since the number of selection rules could be large, an 313 administrator configuring the policy to be distributed should 314 consider the resulting DHCPv6 message size. 316 6. Security Considerations 318 A rogue DHCPv6 server could issue bogus address selection policies to 319 a client. This might lead to incorrect address selection by the 320 client, and the affected packets might be blocked at an outgoing ISP 321 because of ingress filtering. Alternatively, an IPv6 transition 322 mechanism might be preferred over native IPv6, even if it is 323 available. To guard against such attacks, a legitimate DHCPv6 server 324 should be communicated through a secure, trusted channel, such as a 325 channel protected by IPsec, SEND and DHCP authentication, as 326 described in section 21 of RFC 3315, 328 Another threat is about privacy concern. As in the security 329 consideration section of RFC 3484, at least a part of, the address 330 selection policy stored in a host can be leaked by a packet from a 331 remote host. This issue will not be degraded regardless of the 332 introduction of this option, or regardless of whether the host is 333 multihomed or not. 335 7. IANA Considerations 337 IANA is requested to assign option codes to OPTION_ADDRSEL , 338 OPTION_ADDRSEL_TABLE, and OPTION_ADDRSEL_ZONE from the option-code 339 space as defined in section "DHCPv6 Options" of RFC 3315. 341 8. References 343 8.1. Normative References 345 [I-D.ietf-6man-rfc3484bis] 346 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 347 "Default Address Selection for Internet Protocol version 6 348 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 349 June 2012. 351 [I-D.ietf-6man-stable-privacy-addresses] 352 Gont, F., "A method for Generating Stable Privacy-Enhanced 353 Addresses with IPv6 Stateless Address Autoconfiguration 354 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 355 (work in progress), May 2012. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 361 and M. Carney, "Dynamic Host Configuration Protocol for 362 IPv6 (DHCPv6)", RFC 3315, July 2003. 364 [RFC3484] Draves, R., "Default Address Selection for Internet 365 Protocol version 6 (IPv6)", RFC 3484, February 2003. 367 8.2. Informative References 369 [I-D.ietf-6man-addr-select-considerations] 370 Chown, T. and A. Matsumoto, "Considerations for IPv6 371 Address Selection Policy Changes", 372 draft-ietf-6man-addr-select-considerations-04 (work in 373 progress), October 2011. 375 [I-D.ietf-6man-addr-select-sol] 376 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 377 approaches for address-selection problems", 378 draft-ietf-6man-addr-select-sol-03 (work in progress), 379 March 2010. 381 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 382 (IPv6) Specification", RFC 2460, December 1998. 384 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 385 Stevens, "Basic Socket Interface Extensions for IPv6", 386 RFC 3493, February 2003. 388 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 389 Architecture", RFC 4291, February 2006. 391 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 392 Extensions for Stateless Address Autoconfiguration in 393 IPv6", RFC 4941, September 2007. 395 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 396 "Problem Statement for Default Address Selection in Multi- 397 Prefix Environments: Operational Issues of RFC 3484 398 Default Rules", RFC 5220, July 2008. 400 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 401 "Requirements for Address Selection Mechanisms", RFC 5221, 402 July 2008. 404 Appendix A. Past Discussion 406 o The 'zone index' value is used to specify a particular zone for 407 scoped addresses. This can be used effectively to control address 408 selection in the site scope (e.g., to tell a node to use a 409 specified source address corresponding to a site-scoped multicast 410 address). However, in some cases such as a link-local scope 411 address, the value specifying one zone is only meaningful locally 412 within that node. There might be some cases where the 413 administrator knows which clients are on the network and wants 414 specific interfaces to be used though. However, in general case, 415 it is hard to use this value. 417 o Since we got a comment that some implementations use 32-bit 418 integers for zone index value, we extended the bit length of the 419 'zone index' field. However, as described above, there might be 420 few cases to specify 'zone index' in policy distribution, we 421 defined this field as optional, controlled by a flag. 423 o There may be some demands to control the use of special address 424 types such as the temporary addresses described in RFC4941 425 [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing 426 not to use a temporary address when it communicate within the an 427 organization's network). It is possible to indicate the type of 428 addresses using reserved field value. 430 Authors' Addresses 432 Arifumi Matsumoto 433 NTT NT Lab 434 3-9-11 Midori-Cho 435 Musashino-shi, Tokyo 180-8585 436 Japan 438 Phone: +81 422 59 3334 439 Email: arifumi@nttv6.net 441 Tomohiro Fujisaki 442 NTT NT Lab 443 3-9-11 Midori-Cho 444 Musashino-shi, Tokyo 180-8585 445 Japan 447 Phone: +81 422 59 7351 448 Email: fujisaki@nttv6.net 449 Tim Chown 450 University of Southampton 451 Southampton, Hampshire SO17 1BJ 452 United Kingdom 454 Email: tjc@ecs.soton.ac.uk