idnits 2.17.1 draft-ietf-6man-addr-select-opt-13.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 09, 2013) is 3844 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 informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 3 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: April 12, 2014 T. Chown 6 University of Southampton 7 October 09, 2013 9 Distributing Address Selection Policy using DHCPv6 10 draft-ietf-6man-addr-select-opt-13.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. RFC 6724 17 allows 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 to 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 April 12, 2014. 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 [RFC6724] describes default algorithms for selecting an address when 71 a node has multiple destination and/or source addresses to choose 72 from by using an address selection policy. This specification 73 defines a new DHCPv6 option for configuring the default policy table. 75 Some problems were identified with the default address selection 76 policy as originally defined in [RFC3484]. As a result, RFC 3484 was 77 updated and obsoleted by [RFC6724]. While this update corrected a 78 number of issues identifed from operational experience, it is 79 unlikely that any default policy will suit all scenarios, and thus 80 mechanisms to control the source address selection policy will be 81 necessary. Requirements for those mechanisms are described in 82 [RFC5221], while solutions are discussed in 83 [I-D.ietf-6man-addr-select-considerations]. Those documents have 84 helped shape the improvements in the default address selection 85 algorithm in [RFC6724] as well as the requirements for the DHCPv6 86 option defined in this specification. 88 This option's concept is to serve as a hint for a node about how to 89 behave in the network. Ultimately, while the node's administrator 90 can control how to deal with the received policy information, the 91 implementation SHOULD follow the method described below uniformly, to 92 ease troubleshooting and to reduce operational costs. 94 1.1. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 1.2. Terminology 101 This document uses the terminology defined in [RFC2460] and the 102 DHCPv6 specification defined in [RFC3315] 104 2. Address Selection options 106 The Address Selection option provides the address selection policy 107 table, and some other configuration parameters. 109 An Address Selection option contains zero or more policy table 110 options. Multiple policy table options in an Address Selection 111 option constitute a single policy table. When an Address Selection 112 option does not contain a policy table option, it may be used to just 113 convey the A and P flags. 115 The format of the Address Selection option is given below. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | OPTION_ADDRSEL | option-len | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Reserved |A|P| | 123 +-+-+-+-+-+-+-+-+ POLICY TABLE OPTIONS | 124 | (variable length) | 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 1: Address Selection option format 130 option-code: OPTION_ADDRSEL (TBD). 132 option-len: The total length of the Reserved field, A, P flags, and 133 POLICY TABLE OPTIONS in octets. 135 Reserved: Reserved field. The server MUST set this value to zero 136 and the client MUST ignore its content. 138 A: Automatic Row Addition flag. This flag toggles the Automatic 139 Row Addition flag at client hosts, which is described in section 140 2.1 of [RFC6724]. If this flag is set to 1, it does not change 141 client host behavior, that is, a client MAY automatically add 142 additional site-specific rows to the policy table. If set to 0, 143 the Automatic Row Addition flag is disabled, and a client SHOULD 144 NOT automatically add rows to the policy table. If the option 145 contains a POLICY TABLE option, this flag is meaningless, and 146 automatic row addition SHOULD NOT be performed against the 147 distributed policy table. This flag SHOULD be set to 0 only 148 when the Automatic Row Addition at client hosts is harmful for 149 site-specific reasons. 151 P: Privacy Preference flag. This flag toggles the Privacy 152 Preference flag on client hosts, which is described in section 5 153 of [RFC6724]. If this flag is set to 1, it does not change 154 client host behavior, that is, a client will prefer temporary 155 addresses [RFC4941]. If set to 0, the Privacy Preference flag 156 is disabled, and a client will prefer public addresses. This 157 flag SHOULD be set to 0 only when the temporary addresses should 158 not be preferred for site-specific reasons. 160 POLICY TABLE OPTIONS: Zero or more Address Selection Policy Table 161 options, as described below. This option corresponds to a row 162 in the policy table defined in section 2.1 of [RFC6724]. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | OPTION_ADDRSEL_TABLE | option-len | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | label | precedence | prefix-len | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 171 | | 172 | prefix (variable length) | 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 2: Address Selection Policy Table option format 178 option-code: OPTION_ADDRSEL_TABLE (TBD). 180 option-len: The total length of the label field, precedence field, 181 prefix-len field, and prefix field. 183 label: An 8-bit unsigned integer; this value is for correlation of 184 source address prefixes and destination address prefixes. This 185 field is used to deliver a label value in the [RFC6724] policy 186 table. 188 precedence: An 8-bit unsigned integer; this value is used for 189 sorting destination addresses. This field is used to to deliver 190 a precedence value in [RFC6724] policy table. 192 prefix-len: An 8-bit unsigned integer; the number of leading bits in 193 the prefix that are valid. The value ranges from 0 to 128. If 194 an option with a prefix length greater than 128 is included, the 195 whole Address Selection option MUST be ignored. 197 prefix: A variable-length field containing an IP address or the 198 prefix of an IP address. An IPv4-mapped address [RFC4291] must 199 be used to represent an IPv4 address as a prefix value. This 200 field is padded with zeros up to the nearest octet boundary when 201 prefix-len is not divisible by 8. This can be expressed using 202 the following equation: (prefix-len + 7)/8 So the length of this 203 field should be between 0 and 16 bytes. For example, the prefix 204 2001:db8::/60 would be encoded with an prefix-len of 60, the 205 prefix would be 8 octets and would contains octets 20 01 0d b8 206 00 00 00 00. 208 3. Processing the Address Selection option 210 This section describes how to process a received Address Selection 211 option at the DHCPv6 client. 213 This option's concept is to serve as a hint for a node about how to 214 behave in the network. Ultimately, while the node's administrator 215 can control how to deal with the received policy information, the 216 implementation SHOULD follow the method described below uniformly, to 217 ease troubleshooting and to reduce operational costs. 219 3.1. Handling local configurations 221 [RFC6724] defines two flags (A, P) and the default policy table. 222 Also, users are usually able to configure the flags and the policy 223 table to satisfy their own requirements. 225 The client implementation SHOULD provide the following choices to the 226 user. 228 (a) replace the existing flags and active policy table with the 229 DHCPv6 distributed flags and policy table. 231 (b) preserve the existing flags and active policy table, whether 232 this be the default policy table, or user configured policy. 234 Choice (a) SHOULD be the default, i.e. that the policy table is not 235 explictly configured by the user. 237 3.2. Handling stale distributed flags and policy table 239 When the information from the DHCP server goes stale, the flags and 240 the policy table received from the DHCP server SHOULD be deprecated. 241 The local configuration SHOULD be restored when the DHCP-supplied 242 configuration has been deprecated. In order to implement this, a 243 host can retain the local configuration even after the flags and the 244 policy table is updated by the distributed flags and policy table. 246 The received information can be considered stale in several cases, 247 e.g., when the interface goes down, the DHCP server does not respond 248 for a certain amount of time, or the Information Refresh Time has 249 expired. 251 3.3. Handling multiple interfaces 253 The policy table, and other parameters specified in this document, 254 are node-global information by their nature. One reason being that 255 the outbound interface is usually chosen after destination address 256 selection. So a host cannot make use of multiple address selection 257 policies even if they are stored per interface. 259 The policy table is defined as a whole, so the slightest addition/ 260 deletion from the policy table brings a change in the semantics of 261 the policy. 263 It also should be noted that the absence of a DHCP-distributed policy 264 from a certain network interface should not infer that the network 265 administrator does not care about address selection policy at all, 266 because it may mean there is a preference to use the default address 267 selection policy. So, it should be safe to assume that the default 268 address selection policy should be used where no overriding policy is 269 provided. 271 Under the above assumptions, we can specify how to handle received 272 policy as follows. 274 In the absence of distributed policy for a certain network interface, 275 the default address selection policy SHOULD be used. A node should 276 use Address Selection options by default in any of the following two 277 cases: 279 1: A single-homed host SHOULD use default address selection options, 280 where the host belongs exclusively to one administrative network 281 domain, usually through one active network interface. 283 2: Hosts that use advanced heuristics to deal with multiple received 284 policies that are defined outside the scope of this document 285 SHOULD use Address Selection options. 287 Implementations MAY provide configuration options to enable this 288 protocol on a per interface basis. 290 Implementations MAY store distributed address selection policies per 291 interface. They can be used effectively on implementations that 292 adopt per-application interface selection. 294 4. Implementation Considerations 296 o The value 'label' is passed as an unsigned integer, but there is 297 no special meaning for the value, that is whether it is a large or 298 small number. It is used to select a preferred source address 299 prefix corresponding to a destination address prefix by matching 300 the same label value within the DHCP message. DHCPv6 clients 301 SHOULD convert this label to a representation appropriate for the 302 local implementation (e.g., string). 304 o The maximum number of address selection rules that may be conveyed 305 in one DHCPv6 message depends on the prefix length of each rule 306 and the maximum DHCPv6 message size defined in [RFC3315]. It is 307 possible to carry over 3,000 rules in one DHCPv6 message (maximum 308 UDP message size). However, it should not be expected that DHCP 309 clients, servers and relay agents can handle UDP fragmentation. 311 Network adiministrators SHOULD consider local limitations to the 312 maximum DHCPv6 message size that can be reliably transported via 313 their specific local infrastructure to end nodes; and therefore 314 they SHOULD consider the number of options, the total size of the 315 options, and the resulting DHCPv6 message size, when defining 316 their policy table. 318 5. Security Considerations 320 A rogue DHCPv6 server could issue bogus address selection policies to 321 a client. This might lead to incorrect address selection by the 322 client, and the affected packets might be blocked at an outgoing ISP 323 because of ingress filtering, incur additional network charges, or be 324 misdirected to an attacker's machine. Alternatively, an IPv6 325 transition mechanism might be preferred over native IPv6, even if it 326 is available. To guard against such attacks, a legitimate DHCPv6 327 server should communicate through a secure, trusted channel, such as 328 a channel protected by IPsec, SEND and DHCP authentication, as 329 described in section 21 of [RFC3315]. A commonly used alternative 330 mitigation is to employ DHCP snooping at Layer 2. 332 Another threat surrounds the potential privacy concern as described 333 in the security considerations section of [RFC6724], whereby an 334 attacker can send packets with different source addresses to a 335 destination to solicit different source addresses in the responses 336 from that destination. This issue will not be modified by the 337 introduction of this option, regardless of whether the host is 338 multihomed or not. 340 6. IANA Considerations 342 IANA is requested to assign option codes to OPTION_ADDRSEL and 343 OPTION_ADDRSEL_TABLE from the "DHCP Option Codes" registry (http:// 344 www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 346 7. References 348 7.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 354 and M. Carney, "Dynamic Host Configuration Protocol for 355 IPv6 (DHCPv6)", RFC 3315, July 2003. 357 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 358 "Default Address Selection for Internet Protocol Version 6 359 (IPv6)", RFC 6724, September 2012. 361 7.2. Informative References 363 [I-D.ietf-6man-addr-select-considerations] 364 Chown, T. and A. Matsumoto, "Considerations for IPv6 365 Address Selection Policy Changes", draft-ietf-6man-addr- 366 select-considerations-05 (work in progress), April 2013. 368 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 369 (IPv6) Specification", RFC 2460, December 1998. 371 [RFC3484] Draves, R., "Default Address Selection for Internet 372 Protocol version 6 (IPv6)", RFC 3484, February 2003. 374 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 375 Architecture", RFC 4291, February 2006. 377 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 378 Extensions for Stateless Address Autoconfiguration in 379 IPv6", RFC 4941, September 2007. 381 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 382 "Problem Statement for Default Address Selection in Multi- 383 Prefix Environments: Operational Issues of RFC 3484 384 Default Rules", RFC 5220, July 2008. 386 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 387 "Requirements for Address Selection Mechanisms", RFC 5221, 388 July 2008. 390 Appendix A. Acknowledgements 392 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 393 Courmont, Francois-Xavier Le Bail, Ole Troan, Bob Hinden, Dmitry 394 Anipko, Ray Hunter, Rui Paulo, Brian E Carpenter, Tom Petch, and the 395 members of 6man's address selection design team for their invaluable 396 contributions to this document. 398 Appendix B. Examples 400 [RFC5220] gives several cases where address selection problems 401 happen. This section contains some examples for solving those cases 402 by using the DHCP option defined in this text to update the hosts' 403 policy table in a network accordingly. There is also some discussion 404 of example policy tables in sections 10.3 to 10.7 of RFC 6724. 406 B.1. Ingress Filtering Problem 408 In the case described in section 2.1.2 of [RFC5220], the following 409 policy table should be distributed, when Router performs static 410 routing and directs the default route to ISP1 as per Figure 2. By 411 putting the same label value to all IPv6 addresses (::/0) and the 412 local subnet (2001:db8:1000:1::/64), a host picks a source address in 413 this subnet to send a packet via the default route. 415 Prefix Precedence Label 416 ::1/128 50 0 417 ::/0 40 1 418 2001:db8:1000:1::/64 45 1 419 2001:db8:8000:1::/64 45 14 420 ::ffff:0:0/96 35 4 421 2002::/16 30 2 422 2001::/32 5 5 423 fc00::/7 3 13 424 ::/96 1 3 425 fec0::/10 1 11 426 3ffe::/16 1 12 428 B.2. Half-Closed Network Problem 430 In the case described in section 2.1.3 of [RFC5220], the following 431 policy table should be distributed. By splitting the closed network 432 prefix (2001:db8:8000::/36) from all IPv6 addresses (::/0) and giving 433 different labels, the closed network prefix will only be used when 434 packets are destined for the closed network. 436 Prefix Precedence Label 437 ::1/128 50 0 438 ::/0 40 1 439 2001:db8:8000::/36 45 14 440 ::ffff:0:0/96 35 4 441 2002::/16 30 2 442 2001::/32 5 5 443 fc00::/7 3 13 444 ::/96 1 3 445 fec0::/10 1 11 446 3ffe::/16 1 12 448 B.3. IPv4 or IPv6 Prioritization 449 In the case described in section 2.2.1 of [RFC5220], the following 450 policy table should be distributed to prioritize IPv6. This case is 451 also described in [RFC6724] 453 Prefix Precedence Label 454 ::1/128 50 0 455 ::/0 40 1 456 ::ffff:0:0/96 100 4 457 2002::/16 30 2 458 2001::/32 5 5 459 fc00::/7 3 13 460 ::/96 1 3 461 fec0::/10 1 11 462 3ffe::/16 1 12 464 B.4. ULA or Global Prioritization 466 In the case described in section 2.2.3 of [RFC5220], the following 467 policy table should be distributed, or Automatic Row Addition flag 468 should be set to 1. By splitting the ULA in this site 469 (fc12:3456:789a::/48) from all IPv6 addresses (::/0) and giving it 470 higher precendence, the ULA will be used to connect to servers in the 471 same site. 473 Prefix Precedence Label 474 ::1/128 50 0 475 fc12:3456:789a::/48 45 14 476 ::/0 40 1 477 ::ffff:0:0/96 35 4 478 2002::/16 30 2 479 2001::/32 5 5 480 fc00::/7 3 13 481 ::/96 1 3 482 fec0::/10 1 11 483 3ffe::/16 1 12 485 Authors' Addresses 487 Arifumi Matsumoto 488 NTT NT Lab 489 3-9-11 Midori-Cho 490 Musashino-shi, Tokyo 180-8585 491 Japan 493 Phone: +81 422 59 3334 494 Email: arifumi@nttv6.net 495 Tomohiro Fujisaki 496 NTT NT Lab 497 3-9-11 Midori-Cho 498 Musashino-shi, Tokyo 180-8585 499 Japan 501 Phone: +81 422 59 7351 502 Email: fujisaki@nttv6.net 504 Tim Chown 505 University of Southampton 506 Southampton, Hampshire SO17 1BJ 507 United Kingdom 509 Email: tjc@ecs.soton.ac.uk