idnits 2.17.1 draft-ietf-6man-addr-select-opt-09.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 (April 25, 2013) is 4012 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 348, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 355, 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) -- 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.M. Matsumoto 3 Internet-Draft T.F. Fujisaki 4 Intended status: Standards Track NTT 5 Expires: October 27, 2013 T.C. Chown 6 University of Southampton 7 April 25, 2013 9 Distributing Address Selection Policy using DHCPv6 10 draft-ietf-6man-addr-select-opt-09.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 October 27, 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 96 This document uses the terminology defined in [RFC2460] and the 97 DHCPv6 specification defined in [RFC3315] 99 2. Address Selection options 101 The Address Selection option provides the address selection policy 102 table, and some other configuration parameters. 104 An Address Selection option contains zero or more policy table 105 options. Multiple Policy Table options in an Address Selection 106 option constitute a single policy table. 108 The format of the Address Selection option is given below. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | OPTION_ADDRSEL | option-len | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Reserved |A|P| | 116 +-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS | 117 | (variable length) | 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1: Address Selection option format 123 option-code: OPTION_ADDRSEL (TBD). 125 option-len: The total length of the Reserved field, A, P flags, and 126 POLICY TABLE OPTIONS in octets. 128 Reserved: Reserved field. Server MUST set this value to zero and 129 client MUST ignore its content. 131 A: Automatic Row Addition flag. This flag toggles the Automatic 132 Row Addition flag at client hosts, which is described in the 133 section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, it 134 does not change client host behavior, that is, a client MAY 135 automatically add additional site-specific rows to the policy 136 table. If set to 0, the Automatic Row Addition flag is 137 disabled, and a client SHOULD NOT automatically add rows to the 138 policy table. 140 P: Privacy Preference flag. This flag toggles the Privacy 141 Preference flag at client hosts, which is described in the 142 section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, it 143 does not change client host behavior, that is, a client will 144 prefer temporary addresses. If set to 0, the Privacy Preference 145 flag is disabled, and a client will prefer public addresses. 147 POLICY TABLE OPTIONS: Zero or more Address Selection Policy Table 148 options described below. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | OPTION_ADDRSEL_TABLE | option-len | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | label | precedence | prefix-len | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 157 | | 158 | prefix (variable length) | 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 2: Address Selection Policy Table option format 164 option-code: OPTION_ADDRSEL_TABLE (TBD). 166 option-len: The total length of the label field, precedence field, 167 prefix-len field, and prefix field. 169 label: An 8-bit unsigned integer; this value is for correlation of 170 source address prefixes and destination address prefixes. 172 precedence: An 8-bit unsigned integer; this value is used for 173 sorting destination addresses. 175 prefix-len: An 8-bit unsigned integer; the number of leading bits in 176 the prefix that are valid. The value ranges from 0 to 128. 178 prefix: A variable-length field containing an IP address or the 179 prefix of an IP address. An IPv4-mapped address [RFC4291] must 180 be used to represent an IPv4 address as a prefix value. This 181 field is padded with zeros up to the nearest octet boundary when 182 prefix6-len is not divisible by 8. This can be expressed using 183 the following equation: (prefix-len+7)/8 So the length of this 184 field should be between 0 and 16 bytes. For example, the prefix 185 2001:db8::/60 would be encoded with an prefix-len of 60, the 186 prefix would be 8 octets and would contains octets 20 01 0d b8 187 00 00 00 00. 189 3. Processing the Policy Table option 191 This section describes how to process received Policy Table option at 192 the DHCPv6 client. 194 This option's concept is to serve as a hint for a node about how to 195 behave in the network. So, basically, it should be up to the node's 196 administrator how to deal with the received policy information in the 197 way described below. 199 3.1. Handling of the local policy table 201 RFC 6724 defines the default policy table. Also, users are usually 202 able to configure the policy table to satisfy their own requirements. 204 The client implementation SHOULD provide the following choices to the 205 user: 207 a) replace the existing active policy table with the DHCPv6 208 distributed policy table. 210 b) preserve the existing active policy table, whether this be the 211 default policy table, or user configured policy. 213 3.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 deprecated. 218 The received information can be considered stale in several cases, 219 such as, when the interface goes down, the DHCP server does not 220 respond for a certain amount of time, and the Information Refresh 221 Time is expired. 223 3.3. Multi-interface situation 224 The policy table, and other parameters specified in this document are 225 node-global information by their nature. One reason being that the 226 outbound interface is usually chosen after destination address 227 selection. So, a host cannot make use of multiple address selection 228 policies even if they are stored per interface. 230 Even if the received policy from one source is merged with one from 231 another source, the effect of both policy are more or less changed. 232 The policy table is defined as a whole, so the slightest addition/ 233 deletion from the policy table brings a change in semantics of the 234 policy. 236 It also should be noted that absence of the distributed policy from a 237 certain network interface should not be treated as absence of policy 238 itself, because it may mean preference for the default address 239 selection policy. 241 Under the above assumptions, how to handle received policy is 242 specified below. 244 A node MAY use Address Selection options by default in any of the 245 following two cases: 247 1: The host is single-homed, where the host belongs to one 248 administrative network domain exclusively usually through one 249 active network interface. 251 2: The host implements some advanced heuristics to deal with multiple 252 received policy, which is outside the scope of this document. 254 The above restrictions do not preclude implementations from providing 255 configuration options to enable this option on a certain network 256 interface. 258 Nor, they do not preclude implementations from storing distributed 259 address selection policies per interface. They can be used 260 effectively on such implementations that adopt per-application 261 interface selection. 263 4. Implementation Considerations 265 o The value 'label' is passed as an unsigned integer, but there is 266 no special meaning for the value, that is whether it is a large or 267 small number. It is used to select a preferred source address 268 prefix corresponding to a destination address prefix by matching 269 the same label value within the DHCP message. DHCPv6 clients 270 SHOULD convert this label to a representation appropriate for the 271 local implementation (e.g., string). 273 o Currently, the label and precedence values are defined as 8-bit 274 unsigned integers. In almost all cases, this value will be 275 enough. 277 o The maximum number of address selection rules that may be conveyed 278 in one DHCPv6 message depends on the prefix length of each rule 279 and the maximum DHCPv6 message size defined in RFC 3315. It is 280 possible to carry over 3,000 rules in one DHCPv6 message (maximum 281 UDP message size). However, it should not be expected that DHCP 282 clients, servers and relay agents can handle UDP fragmentation. 283 Network adiministrators SHOULD consider local limitations to the 284 maximum DHCPv6 message size that can be reliably transported via 285 their specific local infrastructure to end nodes; and therefore 286 they SHOULD consider the number of options, the total size of the 287 options, and the resulting DHCPv6 message size, when defining 288 their Policy Table. 290 5. Security Considerations 292 A rogue DHCPv6 server could issue bogus address selection policies to 293 a client. This might lead to incorrect address selection by the 294 client, and the affected packets might be blocked at an outgoing ISP 295 because of ingress filtering, incur additional network charges, or be 296 misdirected to an attacker's machine. Alternatively, an IPv6 297 transition mechanism might be preferred over native IPv6, even if it 298 is available. To guard against such attacks, a legitimate DHCPv6 299 server should communicate through a secure, trusted channel, such as 300 a channel protected by IPsec, SEND and DHCP authentication, as 301 described in section 21 of RFC 3315, 303 Another threat is about privacy concern. As in the security 304 consideration section of RFC 6724, at least a part of, the address 305 selection policy stored in a host can be leaked by a packet from a 306 remote host. This issue will not be modified by the introduction of 307 this option, regardless of whether the host is multihomed or not. 309 6. IANA Considerations 311 IANA is requested to assign option codes to OPTION_ADDRSEL and 312 OPTION_ADDRSEL_TABLE from the option-code space as defined in section 313 "DHCPv6 Options" of RFC 3315. 315 7. References 317 7.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 323 and M. Carney, "Dynamic Host Configuration Protocol for 324 IPv6 (DHCPv6)", RFC 3315, July 2003. 326 [RFC3484] Draves, R., "Default Address Selection for Internet 327 Protocol version 6 (IPv6)", RFC 3484, February 2003. 329 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 330 "Default Address Selection for Internet Protocol Version 6 331 (IPv6)", RFC 6724, September 2012. 333 7.2. Informative References 335 [I-D.ietf-6man-addr-select-considerations] 336 Chown, T. and A. Matsumoto, "Considerations for IPv6 337 Address Selection Policy Changes", draft-ietf-6man-addr- 338 select-considerations-05 (work in progress), April 2013. 340 [I-D.ietf-6man-addr-select-sol] 341 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 342 approaches for address-selection problems", draft-ietf- 343 6man-addr-select-sol-03 (work in progress), March 2010. 345 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 346 6 (IPv6) Specification", RFC 2460, December 1998. 348 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 349 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 350 3493, February 2003. 352 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 353 Architecture", RFC 4291, February 2006. 355 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 356 Extensions for Stateless Address Autoconfiguration in 357 IPv6", RFC 4941, September 2007. 359 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 360 "Problem Statement for Default Address Selection in Multi- 361 Prefix Environments: Operational Issues of RFC 3484 362 Default Rules", RFC 5220, July 2008. 364 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 365 "Requirements for Address Selection Mechanisms", RFC 5221, 366 July 2008. 368 Appendix A. Acknowledgements 370 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 371 Courmont, Francois-Xavier Le Bail, Ole Troan, Bob Hinden, Dmitry 372 Anipko, Ray Hunter, Rui Paulo, Brian E Carpenter, Tom Petch, and the 373 members of 6man's address selection design team for their invaluable 374 contributions to this document. 376 Appendix B. Past Discussion 378 o The 'zone index' value is used to specify a particular zone for 379 scoped addresses. This can be used effectively to control address 380 selection in the site scope (e.g., to tell a node to use a 381 specified source address corresponding to a site-scoped multicast 382 address). However, in some cases such as a link-local scope 383 address, the value specifying one zone is only meaningful locally 384 within that node. There might be some cases where the 385 administrator knows which clients are on the network and wants 386 specific interfaces to be used though. However, in general case, 387 it is really rare case, and the field was removed. 389 Authors' Addresses 391 Arifumi Matsumoto 392 NTT NT Lab 393 3-9-11 Midori-Cho 394 Musashino-shi, Tokyo 180-8585 395 Japan 397 Phone: +81 422 59 3334 398 Email: arifumi@nttv6.net 400 Tomohiro Fujisaki 401 NTT NT Lab 402 3-9-11 Midori-Cho 403 Musashino-shi, Tokyo 180-8585 404 Japan 406 Phone: +81 422 59 7351 407 Email: fujisaki@nttv6.net 408 Tim Chown 409 University of Southampton 410 Southampton, Hampshire SO17 1BJ 411 United Kingdom 413 Email: tjc@ecs.soton.ac.uk