idnits 2.17.1 draft-ietf-6man-addr-select-opt-06.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 6724 [RFC6724]. 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 (September 21, 2012) is 4234 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 321, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 365, 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 (~~), 8 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: March 25, 2013 T. Chown 6 University of Southampton 7 September 21, 2012 9 Distributing Address Selection Policy using DHCPv6 10 draft-ietf-6man-addr-select-opt-06.txt 12 Abstract 14 RFC 6724 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 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 March 25, 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 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 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 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 MAY 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 SHOULD 145 prefer temporary addresses. If set to 0, the Privacy Preference 146 flag is disabled, and a client SHOULD 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 zero padded up to the next octet boundary. So 183 the length of this field should be between 0 and 16 bytes. 185 3. Appearance of the Address Selection options 187 The Address Selection options MUST NOT appear in any messages other 188 than the following ones: Solicit, Advertise, Request, Renew, Rebind, 189 Reconfigure, Information-Request, and Reply. 191 4. Processing the Policy Table option 193 This section describes how to process received Policy Table option at 194 the DHCPv6 client. 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 deal with the received policy information in the 199 way described below. 201 4.1. Handling of the local policy table 203 RFC 6724 defines the default policy table. Also, a user is usually 204 able to configure the policy table to satisfy his requirement. 206 The client implementation SHOULD provide the following choices to the 207 user: 209 a) It receives distributed policy table, and replaces the existing 210 policy tables with that. 211 b) It preserves the default policy table, or manually configured 212 policy. 214 4.2. Handling of the stale policy table 216 When the information from the DHCP server goes stale, the policy 217 received form the DHCP server should be removed and the default 218 policy should be restored. 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 its nature. One of the reason is that the 229 outbound interface is usually chosen after destination address 230 selection. So, a host cannot make use of multiple address selection 231 policy 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 need 272 to convert this label to a representation specified by each 273 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 So, the number of the options and the total size of the options 286 should be taken care of. 288 o Since the number of selection rules could be large, an 289 administrator configuring the policy to be distributed should 290 consider the resulting DHCPv6 message size. 292 6. Security Considerations 294 A rogue DHCPv6 server could issue bogus address selection policies to 295 a client. This might lead to incorrect address selection by the 296 client, and the affected packets might be blocked at an outgoing ISP 297 because of ingress filtering. Alternatively, an IPv6 transition 298 mechanism might be preferred over native IPv6, even if it is 299 available. To guard against such attacks, a legitimate DHCPv6 server 300 should be communicated through a secure, trusted channel, such as a 301 channel protected by IPsec, SEND and DHCP authentication, as 302 described in section 21 of RFC 3315, 304 Another threat is about privacy concern. As in the security 305 consideration section of RFC 6724, at least a part of, the address 306 selection policy stored in a host can be leaked by a packet from a 307 remote host. This issue will not be degraded regardless of the 308 introduction of this option, or regardless of whether the host is 309 multihomed or not. 311 7. IANA Considerations 313 IANA is requested to assign option codes to OPTION_ADDRSEL , 314 OPTION_ADDRSEL_TABLE, and OPTION_ADDRSEL_ZONE from the option-code 315 space as defined in section "DHCPv6 Options" of RFC 3315. 317 8. References 319 8.1. Normative References 321 [I-D.ietf-6man-stable-privacy-addresses] 322 Gont, F., "A method for Generating Stable Privacy-Enhanced 323 Addresses with IPv6 Stateless Address Autoconfiguration 324 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 325 (work in progress), May 2012. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 331 and M. Carney, "Dynamic Host Configuration Protocol for 332 IPv6 (DHCPv6)", RFC 3315, July 2003. 334 [RFC3484] Draves, R., "Default Address Selection for Internet 335 Protocol version 6 (IPv6)", RFC 3484, February 2003. 337 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 338 "Default Address Selection for Internet Protocol Version 6 339 (IPv6)", RFC 6724, September 2012. 341 8.2. Informative References 343 [I-D.ietf-6man-addr-select-considerations] 344 Chown, T. and A. Matsumoto, "Considerations for IPv6 345 Address Selection Policy Changes", 346 draft-ietf-6man-addr-select-considerations-04 (work in 347 progress), October 2011. 349 [I-D.ietf-6man-addr-select-sol] 350 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 351 approaches for address-selection problems", 352 draft-ietf-6man-addr-select-sol-03 (work in progress), 353 March 2010. 355 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 356 (IPv6) Specification", RFC 2460, December 1998. 358 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 359 Stevens, "Basic Socket Interface Extensions for IPv6", 360 RFC 3493, February 2003. 362 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 363 Architecture", RFC 4291, February 2006. 365 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 366 Extensions for Stateless Address Autoconfiguration in 367 IPv6", RFC 4941, September 2007. 369 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 370 "Problem Statement for Default Address Selection in Multi- 371 Prefix Environments: Operational Issues of RFC 3484 372 Default Rules", RFC 5220, July 2008. 374 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 375 "Requirements for Address Selection Mechanisms", RFC 5221, 376 July 2008. 378 Appendix A. Acknowledgements 380 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 381 Courmont, Francois-Xavier Le Bail, Ole Troan, Bob Hinden, Dmitry 382 Anipko, and the members of 6man's address selection design team for 383 their invaluable contributions to this document. 385 Appendix B. Past Discussion 387 o The 'zone index' value is used to specify a particular zone for 388 scoped addresses. This can be used effectively to control address 389 selection in the site scope (e.g., to tell a node to use a 390 specified source address corresponding to a site-scoped multicast 391 address). However, in some cases such as a link-local scope 392 address, the value specifying one zone is only meaningful locally 393 within that node. There might be some cases where the 394 administrator knows which clients are on the network and wants 395 specific interfaces to be used though. However, in general case, 396 it is really rare case, and the field was removed. 398 Authors' Addresses 400 Arifumi Matsumoto 401 NTT NT Lab 402 3-9-11 Midori-Cho 403 Musashino-shi, Tokyo 180-8585 404 Japan 406 Phone: +81 422 59 3334 407 Email: arifumi@nttv6.net 408 Tomohiro Fujisaki 409 NTT NT Lab 410 3-9-11 Midori-Cho 411 Musashino-shi, Tokyo 180-8585 412 Japan 414 Phone: +81 422 59 7351 415 Email: fujisaki@nttv6.net 417 Tim Chown 418 University of Southampton 419 Southampton, Hampshire SO17 1BJ 420 United Kingdom 422 Email: tjc@ecs.soton.ac.uk