idnits 2.17.1 draft-ietf-6man-addr-select-opt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (June 28, 2011) is 4685 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 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-03 == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-03 -- 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 (~~), 4 warnings (==), 3 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 J. Kato 5 Expires: December 30, 2011 NTT 6 T. Chown 7 University of Southampton 8 June 28, 2011 10 Distributing Address Selection Policy using DHCPv6 11 draft-ietf-6man-addr-select-opt-01.txt 13 Abstract 15 RFC 3484 defines default address selection mechanisms for IPv6 that 16 allow nodes to select appropriate address when faced with multiple 17 source and/or destination addresses to choose between. The RFC 18 allowed for the future definition of methods to administratively 19 configure the address selection policy information. This document 20 defines a new DHCPv6 option for such configuration, allowing a site 21 administrator to distribute address selection policy, and thus 22 control the address selection behavior of nodes in their site. While 23 RFC 3484 is in the process of being updated, with a revised default 24 policy table, that table may not suit every scenario, and thus the 25 DHCPv6 option defined in this text may be used to override that 26 policy where desired. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 30, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 1. Introduction 74 RFC 3484 [RFC3484] describes default algorithms for selecting an 75 address when a node has multiple destination and/or source addresses 76 to choose between by using an address selection policy. In Section 2 77 of RFC 3484, it is suggested that the default policy table may be 78 administratively configured to suit the specific needs of a site. 79 This text defines a new DHCPv6 option for such configuration. 81 Some problems have been identified with the default address selection 82 policy detailed in RFC 3484 [RFC5220], and as a result the RFC is in 83 the process of being updated, as per [I-D.ietf-6man-rfc3484-revise]. 84 While this update provides a better default address selection policy, 85 it is unlikely that such a default will suit all scenarios, and thus 86 mechanisms to control the source address selection policy will be 87 necessary. Requirements for those mechanisms are described in 88 [RFC5221], while solutions are discussed in 89 [I-D.ietf-6man-addr-select-sol] and 90 [I-D.ietf-6man-addr-select-considerations]. Those documents have 91 helped shape the improvements in [I-D.ietf-6man-rfc3484-revise] as 92 well as the DHCPv6 option defined here. 94 1.1. Conventions Used in This Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 1.2. Terminology 102 This document uses the terminology defined in [RFC2460] and the 103 DHCPv6 specification defined in [RFC3315] 105 2. Address Selection Policy Option 107 The Address Selection Policy Option provides the policy table for 108 address selection rules as described in RFC 3484 and updated in 109 [I-D.ietf-6man-rfc3484-revise]. 111 Each end node is expected to configure its policy table, as described 112 in RFC 3484, using the Address Selection Policy option information as 113 described in the section below on processing the option. 115 The format of the Address Selection Policy option is given below: 117 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | OPTION_DASP | option-len | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | label | precedence |z| reserved | prefix-len | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | zone-index (if present (z = 1)) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 | Prefix (Variable Length) | 129 | | 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | label | precedence |z| reserved | prefix-len | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | zone-index (if present (z = 1)) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 | Prefix (Variable Length) | 138 | | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 . . 142 . . 143 . . 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | label | precedence |z| reserved | prefix-len | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | zone-index (if present (z = 1)) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | | 150 | Prefix (Variable Length) | 151 | | 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 [Fig. 1] 157 Fields: 159 option-code: OPTION_DASP (TBD) 161 option-len: The total length of the label fields, precedence fields, 162 zone-index fields, prefix-len fields, and prefix fields in 163 octets. 165 label: An 8-bit unsigned integer; this value is used to make a 166 combination of source address prefixes and destination address 167 prefixes. 169 precedence: An 8-bit unsigned integer; this value is used for 170 sorting destination addresses. 172 z bit: 'zone-index' bit. If z bit is set to 1, 32 bit zone-index 173 value is included right after the "prefix-len" field, and 174 "Prefix" value continues after the "zone-index" field. If z bit 175 is 0, "Prefix" value continues right after the "prefix-len" 176 value. 178 reserved: 6-bit reserved field. Initialized to zero by sender, and 179 ignored by receiver. 181 zone-index: If the z-bit is set to 1, this field is inserted between 182 "prefix-len" field and "Prefix" field. The zone-index field is 183 an 32-bit unsigned integer and used to specify zones for scoped 184 addresses. This bit length is defined in RFC3493 [RFC3493] as 185 'scope ID'. 187 prefix-len: An 8-bit unsigned integer; the number of leading bits in 188 the prefix that are valid. The value ranges from 0 to 128. The 189 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 190 length. 192 Prefix: A variable-length field containing an IP address or the 193 prefix of an IP address. An IPv4-mapped address [RFC4291] must 194 be used to represent an IPv4 address as a prefix value. 196 3. Appearance of this Option 198 The Address Selection Policy option MUST NOT appear in any messages 199 other than the following ones: Solicit, Advertise, Request, Renew, 200 Rebind, Information-Request, and Reply. 202 4. Processing the Address Selection Policy Option 204 This section describes how to process received Address Selection 205 Policy Options at the DHCPv6 client. 207 This option's concept is to serve as a hint for a node about how to 208 behave in the network. So, basically, it should be up to the node's 209 administrator how to make use of or even ignore the received policy 210 information. 212 However, we need to define the default behavior of the receiving node 213 in order to reduce operational complexity. 215 4.1. Handling the local policy table 217 RFC3484 defines the default policy for the policy table. Also, a 218 user is usually able to configure the policy table to satisfy his 219 requirement. 221 The client node SHOULD provide the following choices: 223 a) It receives distributed policy table, and replaces the existing 224 policy tables with that. 225 b) It preserves the default policy table, or manually configured 226 policy. 228 4.2. Processing multiple received policy tables 230 The policy table is node-global information by its nature. So, the 231 node cannot use multiple received policy tables at the same time. 233 It should be noted that adopting a received policy table as the node- 234 global information can cause security problems, such as DOS attack, 235 and leak of privacy information. 237 Moreover, it also should be noted that, when a node is single-homed 238 and has only one upstream line, adopting a received policy table does 239 not degrade the security level. 241 Under the above assumptions, we specify how to handle multiple 242 received policy tables below. 244 A node MAY use OPTION_DASP in any of the following two cases: 246 1: The address selection option is delivered across a secure, trusted 247 channel. 248 2: The address selection option is not secured, but the node is 249 single-homed. 251 In other cases the node MUST NOT use OPTION_DASP unless the node is 252 specifically configured to do so. 254 5. Implementation Considerations 256 o The value 'label' is passed as an unsigned integer, but there is 257 no special meaning for the value, that is whether it is a large or 258 small number. It is used to select a preferred source address 259 prefix corresponding to a destination address prefix by matching 260 the same label value within the DHCP message. DHCPv6 clients need 261 to convert this label to a representation specified by each 262 implementation (e.g., string). 264 o Currently, the label and precedence values are defined as 8-bit 265 unsigned integers. In almost all cases, this value will be 266 enough. 268 o The maximum number of address selection rules that may be conveyed 269 in one DHCPv6 message depends on the prefix length of each rule 270 and the maximum DHCPv6 message size defined in RFC 3315. It is 271 possible to carry over 3,000 rules in one DHCPv6 message (maximum 272 UDP message size), but the usual number would be much smaller, 273 e.g. the default policy table defined in RFC 3484 contains 5 274 rules. 276 o Since the number of selection rules could be large, an 277 administrator configuring the policy to be distributed should 278 consider the resulting DHCPv6 message size. 280 6. Security Considerations 282 A rogue DHCPv6 server could issue bogus address selection policies to 283 a client. This might lead to incorrect address selection by the 284 client, and the affected packets might be blocked at an outgoing ISP 285 because of ingress filtering. Alternatively, an IPv6 transition 286 mechanism might be preferred over native IPv6, even if it is 287 available. 289 To guard against such attacks, both DCHP clients and servers SHOULD 290 use DHCP authentication, as described in section 21 of RFC 3315, 291 "Authentication of DHCP messages." 293 7. IANA Considerations 295 IANA is requested to assign option codes to OPTION_DASP from the 296 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 298 8. References 300 8.1. Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 306 and M. Carney, "Dynamic Host Configuration Protocol for 307 IPv6 (DHCPv6)", RFC 3315, July 2003. 309 [RFC3484] Draves, R., "Default Address Selection for Internet 310 Protocol version 6 (IPv6)", RFC 3484, February 2003. 312 8.2. Informative References 314 [I-D.ietf-6man-addr-select-considerations] 315 Chown, T., "Considerations for IPv6 Address Selection 316 Policy Changes", 317 draft-ietf-6man-addr-select-considerations-03 (work in 318 progress), March 2011. 320 [I-D.ietf-6man-addr-select-sol] 321 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 322 approaches for address-selection problems", 323 draft-ietf-6man-addr-select-sol-03 (work in progress), 324 March 2010. 326 [I-D.ietf-6man-rfc3484-revise] 327 Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC 328 3484 Default Address Selection for IPv6", 329 draft-ietf-6man-rfc3484-revise-03 (work in progress), 330 June 2011. 332 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 333 (IPv6) Specification", RFC 2460, December 1998. 335 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 336 Stevens, "Basic Socket Interface Extensions for IPv6", 337 RFC 3493, February 2003. 339 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 340 Architecture", RFC 4291, February 2006. 342 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 343 Extensions for Stateless Address Autoconfiguration in 344 IPv6", RFC 4941, September 2007. 346 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 347 "Problem Statement for Default Address Selection in Multi- 348 Prefix Environments: Operational Issues of RFC 3484 349 Default Rules", RFC 5220, July 2008. 351 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 352 "Requirements for Address Selection Mechanisms", RFC 5221, 353 July 2008. 355 Appendix A. Past Discussion 357 o The 'zone index' value is used to specify a particular zone for 358 scoped addresses. This can be used effectively to control address 359 selection in the site scope (e.g., to tell a node to use a 360 specified source address corresponding to a site-scoped multicast 361 address). However, in some cases such as a link-local scope 362 address, the value specifying one zone is only meaningful locally 363 within that node. There might be some cases where the 364 administrator knows which clients are on the network and wants 365 specific interfaces to be used though. However, in general case, 366 it is hard to use this value. 368 o Since we got a comment that some implementations use 32-bit 369 integers for zone index value, we extended the bit length of the 370 'zone index' field. However, as described above, there might be 371 few cases to specify 'zone index' in policy distribution, we 372 defined this field as optional, controlled by a flag. 374 o There may be some demands to control the use of special address 375 types such as the temporary addresses described in RFC4941 376 [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing 377 not to use a temporary address when it communicate within the an 378 organization's network). It is possible to indicate the type of 379 addresses using reserved field value. 381 Authors' Addresses 383 Arifumi Matsumoto 384 NTT SI Lab 385 3-9-11 Midori-Cho 386 Musashino-shi, Tokyo 180-8585 387 Japan 389 Phone: +81 422 59 3334 390 Email: arifumi@nttv6.net 392 Tomohiro Fujisaki 393 NTT PF Lab 394 3-9-11 Midori-Cho 395 Musashino-shi, Tokyo 180-8585 396 Japan 398 Phone: +81 422 59 7351 399 Email: fujisaki@nttv6.net 401 Jun-ya Kato 402 NTT SI Lab 403 3-9-11 Midori-Cho 404 Musashino-shi, Tokyo 180-8585 405 Japan 407 Phone: +81 422 59 2939 408 Email: kato@syce.net 410 Tim Chown 411 University of Southampton 412 Southampton, Hampshire SO17 1BJ 413 United Kingdom 415 Email: tjc@ecs.soton.ac.uk