idnits 2.17.1 draft-ietf-6man-addr-select-opt-08.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 (January 16, 2013) is 4115 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: 'RFC3493' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 362, but no explicit reference was found in the text ** 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 (~~), 5 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 NTT 5 Expires: July 20, 2013 T. Chown 6 University of Southampton 7 January 16, 2013 9 Distributing Address Selection Policy using DHCPv6 10 draft-ietf-6man-addr-select-opt-08.txt 12 Abstract 14 RFC 6724 defines default address selection mechanisms for IPv6 that 15 allow nodes to select an appropriate address when faced with multiple 16 source and/or destination addresses to choose between. The RFC 6724 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 July 20, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 6724, 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 [RFC6724] as well as the DHCPv6 option defined in this 87 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 An Address Selection option contains zero or more policy table 106 options. Multiple Policy Table options in an Address Selection 107 option 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 OPTIONS 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 6724 [RFC6724]. If this flag is set to 1, it 135 does not change client host behavior, that is, a client MAY 136 automatically add additional site-specific rows to the policy 137 table. If set to 0, the Automatic Row Addition flag is 138 disabled, and a client SHOULD NOT automatically add rows to the 139 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 6724 [RFC6724]. If this flag is set to 1, it 144 does not change client host behavior, that is, a client will 145 prefer temporary addresses. If set to 0, the Privacy Preference 146 flag is disabled, and a client will prefer public addresses. 148 POLICY TABLE OPTIONS: Zero or more Address Selection Policy Table 149 options described below. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | OPTION_ADDRSEL_TABLE | option-len | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | label | precedence | prefix-len | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 158 | | 159 | prefix (variable length) | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 2: Address Selection Policy Table option format 165 option-code: OPTION_ADDRSEL_TABLE (TBD). 167 option-len: The total length of the label field, precedence field, 168 prefix-len field, and prefix field. 170 label: An 8-bit unsigned integer; this value is for correlation of 171 source address prefixes and destination address prefixes. 173 precedence: An 8-bit unsigned integer; this value is used for 174 sorting destination addresses. 176 prefix-len: An 8-bit unsigned integer; the number of leading bits in 177 the prefix that are valid. The value ranges from 0 to 128. 179 prefix: A variable-length field containing an IP address or the 180 prefix of an IP address. An IPv4-mapped address [RFC4291] must 181 be used to represent an IPv4 address as a prefix value. The 182 prefix should be left aligned, big-endian, and zero padded on 183 the right up to the next octet boundary. So the length of this 184 field should be between 0 and 16 bytes. 186 3. Appearance of the Address Selection options 188 The Address Selection options MUST NOT appear in any DHCPv6 messages 189 other than the following ones: Solicit, Advertise, Request, Renew, 190 Rebind, Reconfigure, Information-Request, and Reply. 192 4. Processing the Policy Table option 194 This section describes how to process received Policy Table option at 195 the DHCPv6 client. 197 This option's concept is to serve as a hint for a node about how to 198 behave in the network. So, basically, it should be up to the node's 199 administrator how to deal with the received policy information in the 200 way described below. 202 4.1. Handling of the local policy table 204 RFC 6724 defines the default policy table. Also, users are usually 205 able to configure the policy table to satisfy their own requirements. 207 The client implementation SHOULD provide the following choices to the 208 user: 210 a) replace the existing active policy table with the DHCPv6 211 distributed policy table. 212 b) preserve the existing active policy table, whether this be the 213 default policy table, or user configured policy. 215 4.2. Handling of the stale policy table 217 When the information from the DHCP server goes stale, the policy 218 received form the DHCP server should be deprecated. 220 The received information can be considered stale in several cases, 221 such as, when the interface goes down, the DHCP server does not 222 respond for a certain amount of time, and the Information Refresh 223 Time is expired. 225 4.3. Multi-interface situation 227 The policy table, and other parameters specified in this document are 228 node-global information by their nature. One reason being that the 229 outbound interface is usually chosen after destination address 230 selection. So, a host cannot make use of multiple address selection 231 policies even if they are stored per interface. 233 Even if the received policy from one source is merged with one from 234 another source, the effect of both policy are more or less changed. 235 The policy table is defined as a whole, so the slightest addition/ 236 deletion from the policy table brings a change in semantics of the 237 policy. 239 It also should be noted that absence of the distributed policy from a 240 certain network interface should not be treated as absence of policy 241 itself, because it may mean preference for the default address 242 selection policy. 244 Under the above assumptions, how to handle received policy is 245 specified below. 247 A node MAY use Address Selection options by default in any of the 248 following two cases: 250 1: The host is single-homed, where the host belongs to one 251 administrative network domain exclusively usually through one 252 active network interface. 253 2: The host implements some advanced heuristics to deal with multiple 254 received policy, which is outside the scope of this document. 256 The above restrictions do not preclude implementations from providing 257 configuration options to enable this option on a certain network 258 interface. 260 Nor, they do not preclude implementations from storing distributed 261 address selection policies per interface. They can be used 262 effectively on such implementations that adopt per-application 263 interface selection. 265 5. Implementation Considerations 267 o The value 'label' is passed as an unsigned integer, but there is 268 no special meaning for the value, that is whether it is a large or 269 small number. It is used to select a preferred source address 270 prefix corresponding to a destination address prefix by matching 271 the same label value within the DHCP message. DHCPv6 clients 272 SHOULD convert this label to a representation appropriate for the 273 local implementation (e.g., string). 275 o Currently, the label and precedence values are defined as 8-bit 276 unsigned integers. In almost all cases, this value will be 277 enough. 279 o The maximum number of address selection rules that may be conveyed 280 in one DHCPv6 message depends on the prefix length of each rule 281 and the maximum DHCPv6 message size defined in RFC 3315. It is 282 possible to carry over 3,000 rules in one DHCPv6 message (maximum 283 UDP message size). However, it should not be expected that DHCP 284 clients, servers and relay agents can handle UDP fragmentation. 285 Network adiministrators SHOULD consider local limitations to the 286 maximum DHCPv6 message size that can be reliably transported via 287 their specific local infrastructure to end nodes; and therefore 288 they SHOULD consider the number of options, the total size of the 289 options, and the resulting DHCPv6 message size, when defining 290 their Policy Table. 292 o Since the number of selection rules could be large, an 293 administrator configuring the policy to be distributed should 294 consider the resulting DHCPv6 message size. 296 6. Security Considerations 298 A rogue DHCPv6 server could issue bogus address selection policies to 299 a client. This might lead to incorrect address selection by the 300 client, and the affected packets might be blocked at an outgoing ISP 301 because of ingress filtering, incur additional network charges, or be 302 misdirected to an attacker's machine. Alternatively, an IPv6 303 transition mechanism might be preferred over native IPv6, even if it 304 is available. To guard against such attacks, a legitimate DHCPv6 305 server should communicate through a secure, trusted channel, such as 306 a channel protected by IPsec, SEND and DHCP authentication, as 307 described in section 21 of RFC 3315, 309 Another threat is about privacy concern. As in the security 310 consideration section of RFC 6724, at least a part of, the address 311 selection policy stored in a host can be leaked by a packet from a 312 remote host. This issue will not be modified by the introduction of 313 this option, regardless of whether the host is multihomed or not. 315 7. IANA Considerations 317 IANA is requested to assign option codes to OPTION_ADDRSEL and 318 OPTION_ADDRSEL_TABLE from the option-code space as defined in section 319 "DHCPv6 Options" of RFC 3315. 321 8. References 322 8.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 328 and M. Carney, "Dynamic Host Configuration Protocol for 329 IPv6 (DHCPv6)", RFC 3315, July 2003. 331 [RFC3484] Draves, R., "Default Address Selection for Internet 332 Protocol version 6 (IPv6)", RFC 3484, February 2003. 334 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 335 "Default Address Selection for Internet Protocol Version 6 336 (IPv6)", RFC 6724, September 2012. 338 8.2. Informative References 340 [I-D.ietf-6man-addr-select-considerations] 341 Chown, T. and A. Matsumoto, "Considerations for IPv6 342 Address Selection Policy Changes", 343 draft-ietf-6man-addr-select-considerations-04 (work in 344 progress), October 2011. 346 [I-D.ietf-6man-addr-select-sol] 347 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 348 approaches for address-selection problems", 349 draft-ietf-6man-addr-select-sol-03 (work in progress), 350 March 2010. 352 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 353 (IPv6) Specification", RFC 2460, December 1998. 355 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 356 Stevens, "Basic Socket Interface Extensions for IPv6", 357 RFC 3493, February 2003. 359 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 360 Architecture", RFC 4291, February 2006. 362 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 363 Extensions for Stateless Address Autoconfiguration in 364 IPv6", RFC 4941, September 2007. 366 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 367 "Problem Statement for Default Address Selection in Multi- 368 Prefix Environments: Operational Issues of RFC 3484 369 Default Rules", RFC 5220, July 2008. 371 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 372 "Requirements for Address Selection Mechanisms", RFC 5221, 373 July 2008. 375 Appendix A. Acknowledgements 377 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 378 Courmont, Francois-Xavier Le Bail, Ole Troan, Bob Hinden, Dmitry 379 Anipko, Ray Hunter, Rui Paulo, Brian E Carpenter, Tom Petch, and the 380 members of 6man's address selection design team for their invaluable 381 contributions to this document. 383 Appendix B. Past Discussion 385 o The 'zone index' value is used to specify a particular zone for 386 scoped addresses. This can be used effectively to control address 387 selection in the site scope (e.g., to tell a node to use a 388 specified source address corresponding to a site-scoped multicast 389 address). However, in some cases such as a link-local scope 390 address, the value specifying one zone is only meaningful locally 391 within that node. There might be some cases where the 392 administrator knows which clients are on the network and wants 393 specific interfaces to be used though. However, in general case, 394 it is really rare case, and the field was removed. 396 Authors' Addresses 398 Arifumi Matsumoto 399 NTT NT Lab 400 3-9-11 Midori-Cho 401 Musashino-shi, Tokyo 180-8585 402 Japan 404 Phone: +81 422 59 3334 405 Email: arifumi@nttv6.net 406 Tomohiro Fujisaki 407 NTT NT Lab 408 3-9-11 Midori-Cho 409 Musashino-shi, Tokyo 180-8585 410 Japan 412 Phone: +81 422 59 7351 413 Email: fujisaki@nttv6.net 415 Tim Chown 416 University of Southampton 417 Southampton, Hampshire SO17 1BJ 418 United Kingdom 420 Email: tjc@ecs.soton.ac.uk