idnits 2.17.1 draft-ietf-6man-addr-select-opt-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 : ---------------------------------------------------------------------------- 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 (February 21, 2012) is 4447 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-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 (~~), 3 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: August 24, 2012 NTT 6 T. Chown 7 University of Southampton 8 February 21, 2012 10 Distributing Address Selection Policy using DHCPv6 11 draft-ietf-6man-addr-select-opt-03.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 3484 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 overriding the 22 default address selection policy table, and thus control the address 23 selection behavior of nodes in their site. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 24, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 1. Introduction 71 RFC 3484 [RFC3484] describes default algorithms for selecting an 72 address when a node has multiple destination and/or source addresses 73 to choose from by using an address selection policy. In Section 2 of 74 RFC 3484, it is suggested that the default policy table may be 75 administratively configured to suit the specific needs of a site. 76 This specification defines a new DHCPv6 option for such 77 configuration. 79 Some problems have been identified with the default RFC 3484 address 80 selection policy [RFC5220]. It is unlikely that any default policy 81 will suit all scenarios, and thus mechanisms to control the source 82 address selection policy will be necessary. Requirements for those 83 mechanisms are described in [RFC5221], while solutions are discussed 84 in [I-D.ietf-6man-addr-select-sol] and 85 [I-D.ietf-6man-addr-select-considerations]. Those documents have 86 helped shape the improvements in the default address selection 87 algorithm [I-D.ietf-6man-rfc3484-revise] as well as the DHCPv6 option 88 defined in this specification. 90 1.1. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 1.2. Terminology 98 This document uses the terminology defined in [RFC2460] and the 99 DHCPv6 specification defined in [RFC3315] 101 2. Address Selection Policy option 103 The Address Selection Policy option provides the policy table for 104 address selection rules as described in RFC 3484 and in 105 [I-D.ietf-6man-rfc3484-revise]. 107 Each end node is expected to configure its policy table, as described 108 in RFC 3484, using the Address Selection Policy option as described 109 in the section below on processing the option. 111 Multiple Address Selection Policy options MAY appear in a DHCPv6 112 message. They constitute a single policy table. 114 The format of the Address Selection Policy option is given below. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | OPTION_DASP | option-len | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | label | precedence | prefix-len | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 123 | | 124 | prefix (variable length) | 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 . DASP options . 129 . . 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1: Address Selection Policy option format 134 option-code: OPTION_DASP (TBD). 136 option-len: The total length of the label field, precedence field, 137 prefix-len field, prefix field, and DASP options field in 138 octets. 140 label: An 8-bit unsigned integer; this value is used to make a 141 combination of source address prefixes and destination address 142 prefixes. 144 precedence: An 8-bit unsigned integer; this value is used for 145 sorting destination addresses. 147 prefix-len: An 8-bit unsigned integer; the number of leading bits in 148 the prefix that are valid. The value ranges from 0 to 128. 150 prefix: A variable-length field containing an IP address or the 151 prefix of an IP address. An IPv4-mapped address [RFC4291] must 152 be used to represent an IPv4 address as a prefix value. The 153 Prefix should be truncated on the byte boundary. So the length 154 of this field should be between 0 and 16 bytes. 156 DASP options: Options specific to this particular Address Selection 157 Policy option. This includes, but not limited to, zero or one 158 PREFIX_ZONE option that specify the zone index of the prefix in 159 this option. 161 The format of the Zone Index option is given below. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | OPTION_ZONE_INDEX | option-len | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | zone-index | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 2: Zone Index option format 173 option-code: OPTION_ZONE_INDEX (TBD). 175 option-len: 4. 177 zone-index: The zone-index field is an 32-bit unsigned integer, and 178 used to specify the zone for scoped addresses. The zone-index 179 is defined in RFC 3493 [RFC3493] as 'scope ID'. 181 3. Appearance of the Address Selection Policy option 183 The Address Selection Policy option MUST NOT appear in any messages 184 other than the following ones: Solicit, Advertise, Request, Renew, 185 Rebind, Reconfigure, Information-Request, and Reply. 187 4. Processing the Address Selection Policy option 189 This section describes how to process received Address Selection 190 Policy options at the DHCPv6 client. 192 When a host receives a DHCPv6 message that includes multiple Address 193 Selection Policy options, they MUST be treated as a single policy 194 table. 196 This option's concept is to serve as a hint for a node about how to 197 behave in the network. So, basically, it should be up to the node's 198 administrator how to make use of or even ignore the received policy 199 information. 201 4.1. Handling of the local policy table 203 RFC 3484 defines the default policy table. Also, a user is usually 204 able to configure the policy table to satisfy his requirement. 206 The client node SHOULD provide the following choices: 208 a) It receives distributed policy table, and replaces the existing 209 policy tables with that. 210 b) It preserves the default policy table, or manually configured 211 policy. 213 4.2. Handling of the stale policy table 215 When the information from the DHCP server goes stale, the policy 216 received form the DHCP server should be removed and the default 217 policy should be restored. 219 The received information can be considered stale in several cases, 220 such as, when the interface goes down, the DHCP server does not 221 respond for a certain amount of time, and the Information Refresh 222 Time is expired. 224 4.3. Processing multiple received policy tables 226 The policy table is node-global information by its nature. So, the 227 node cannot use multiple received policy tables at the same time. In 228 other words, once the received policy from one source is merged with 229 another source, the policy is more or less changed. The policy table 230 is defined as a whole, so the slightest addition/deletion from the 231 policy table brings a change in semantics of the policy. 233 It also should be noted that, when a node is single-homed and has 234 only one upstream line, adopting a received policy table does not 235 degrade the security level. 237 Under the above assumptions, we specify how to handle multiple 238 received policy tables below. 240 A node MAY use OPTION_DASP in any of the following two cases: 242 1: The address selection option is delivered across the only secure, 243 trusted channel. 244 2: The address selection option delivery is not secured, but the node 245 is single-homed. 247 In other cases the node MUST NOT use OPTION_DASP unless the node is 248 specifically configured to do so. 250 5. Implementation Considerations 252 o The value 'label' is passed as an unsigned integer, but there is 253 no special meaning for the value, that is whether it is a large or 254 small number. It is used to select a preferred source address 255 prefix corresponding to a destination address prefix by matching 256 the same label value within the DHCP message. DHCPv6 clients need 257 to convert this label to a representation specified by each 258 implementation (e.g., string). 260 o Currently, the label and precedence values are defined as 8-bit 261 unsigned integers. In almost all cases, this value will be 262 enough. 264 o The maximum number of address selection rules that may be conveyed 265 in one DHCPv6 message depends on the prefix length of each rule 266 and the maximum DHCPv6 message size defined in RFC 3315. It is 267 possible to carry over 3,000 rules in one DHCPv6 message (maximum 268 UDP message size). However, it should not be expected that DHCP 269 clients, servers and relay agents can handle UDP fragmentation. 270 So, the number of the options and the total size of the options 271 should be taken care of. 273 o Since the number of selection rules could be large, an 274 administrator configuring the policy to be distributed should 275 consider the resulting DHCPv6 message size. 277 6. Security Considerations 279 A rogue DHCPv6 server could issue bogus address selection policies to 280 a client. This might lead to incorrect address selection by the 281 client, and the affected packets might be blocked at an outgoing ISP 282 because of ingress filtering. Alternatively, an IPv6 transition 283 mechanism might be preferred over native IPv6, even if it is 284 available. To guard against such attacks, a legitimate DHCPv6 server 285 should be communicated through a secure, trusted channel, such as a 286 channel protected by IPsec, SEND and DHCP authentication, as 287 described in section 21 of RFC 3315, 289 Another threat is about privacy concern. As in the security 290 consideration section of RFC 3484, at least a part of, the address 291 selection policy stored in a host can be leaked by a packet from a 292 remote host. This issue will not be degraded regardless of the 293 introduction of this option, or regardless of whether the host is 294 multihomed or not. 296 7. IANA Considerations 298 IANA is requested to assign option codes to OPTION_DASP from the 299 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 301 8. References 303 8.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 309 and M. Carney, "Dynamic Host Configuration Protocol for 310 IPv6 (DHCPv6)", RFC 3315, July 2003. 312 [RFC3484] Draves, R., "Default Address Selection for Internet 313 Protocol version 6 (IPv6)", RFC 3484, February 2003. 315 8.2. Informative References 317 [I-D.ietf-6man-addr-select-considerations] 318 Chown, T. and A. Matsumoto, "Considerations for IPv6 319 Address Selection Policy Changes", 320 draft-ietf-6man-addr-select-considerations-04 (work in 321 progress), October 2011. 323 [I-D.ietf-6man-addr-select-sol] 324 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 325 approaches for address-selection problems", 326 draft-ietf-6man-addr-select-sol-03 (work in progress), 327 March 2010. 329 [I-D.ietf-6man-rfc3484-revise] 330 Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, 331 "Update to RFC 3484 Default Address Selection for IPv6", 332 draft-ietf-6man-rfc3484-revise-05 (work in progress), 333 October 2011. 335 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 336 (IPv6) Specification", RFC 2460, December 1998. 338 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 339 Stevens, "Basic Socket Interface Extensions for IPv6", 340 RFC 3493, February 2003. 342 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 343 Architecture", RFC 4291, February 2006. 345 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 346 Extensions for Stateless Address Autoconfiguration in 347 IPv6", RFC 4941, September 2007. 349 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 350 "Problem Statement for Default Address Selection in Multi- 351 Prefix Environments: Operational Issues of RFC 3484 352 Default Rules", RFC 5220, July 2008. 354 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 355 "Requirements for Address Selection Mechanisms", RFC 5221, 356 July 2008. 358 Appendix A. Past Discussion 360 o The 'zone index' value is used to specify a particular zone for 361 scoped addresses. This can be used effectively to control address 362 selection in the site scope (e.g., to tell a node to use a 363 specified source address corresponding to a site-scoped multicast 364 address). However, in some cases such as a link-local scope 365 address, the value specifying one zone is only meaningful locally 366 within that node. There might be some cases where the 367 administrator knows which clients are on the network and wants 368 specific interfaces to be used though. However, in general case, 369 it is hard to use this value. 371 o Since we got a comment that some implementations use 32-bit 372 integers for zone index value, we extended the bit length of the 373 'zone index' field. However, as described above, there might be 374 few cases to specify 'zone index' in policy distribution, we 375 defined this field as optional, controlled by a flag. 377 o There may be some demands to control the use of special address 378 types such as the temporary addresses described in RFC4941 379 [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing 380 not to use a temporary address when it communicate within the an 381 organization's network). It is possible to indicate the type of 382 addresses using reserved field value. 384 Authors' Addresses 386 Arifumi Matsumoto 387 NTT SI Lab 388 3-9-11 Midori-Cho 389 Musashino-shi, Tokyo 180-8585 390 Japan 392 Phone: +81 422 59 3334 393 Email: arifumi@nttv6.net 395 Tomohiro Fujisaki 396 NTT PF Lab 397 3-9-11 Midori-Cho 398 Musashino-shi, Tokyo 180-8585 399 Japan 401 Phone: +81 422 59 7351 402 Email: fujisaki@nttv6.net 404 Jun-ya Kato 405 NTT SI Lab 406 3-9-11 Midori-Cho 407 Musashino-shi, Tokyo 180-8585 408 Japan 410 Phone: +81 422 59 2939 411 Email: kato@syce.net 412 Tim Chown 413 University of Southampton 414 Southampton, Hampshire SO17 1BJ 415 United Kingdom 417 Email: tjc@ecs.soton.ac.uk