idnits 2.17.1 draft-fujisaki-dhc-addr-select-opt-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: n bit 'no privacy iid' bit. If n bit is set to 1, RFC 4941 [RFC4941] privacy extensions MUST not be used for this prefix. If n bit is 0, interface ID may use RFC4941. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 8, 2010) is 5156 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 (-02) exists of draft-arifumi-6man-addr-select-conflict-01 == Outdated reference: A later version (-03) exists of draft-ietf-6man-addr-select-sol-02 -- 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group T. Fujisaki 3 Internet-Draft A. Matsumoto 4 Intended status: Standards Track NTT 5 Expires: September 9, 2010 R. Hiromi 6 Intec Netcore 7 March 8, 2010 9 Distributing Address Selection Policy using DHCPv6 10 draft-fujisaki-dhc-addr-select-opt-09.txt 12 Abstract 14 This document describes a new DHCPv6 option for distributing address 15 selection policy information defined in RFC3484 and/or source address 16 and destination address selection policies to a client. With this 17 option, site administrators can distribute address selection policy 18 to control the node's address selection behavior. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 1. Introduction 72 RFC3484 [RFC3484] describes algorithms for selecting a default 73 address when a node has multiple destination and/or source addresses 74 by using an address selection policy. However, there are some 75 problems with the default address selection policy in RFC3484 76 [RFC5220], and mechanisms to control a proper source address 77 selection will be necessary. Requirements for those mechanisms are 78 described in [RFC5221], and solutions are discussed in 79 [I-D.ietf-6man-addr-select-sol]. This document describes an option 80 for distributing address selection policy information using DHCPv6, 81 which is referred as `most proactive approach' in the solution 82 document. 84 1.1. Conventions Used in This Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC2119 [RFC2119]. 90 1.2. Terminology 92 This document uses the terminology defined in [RFC2460] and the DHCP 93 specification defined in [RFC3315] 95 2. Address Selection Policy Option 97 The Address Selection Policy Option provides policy information for 98 address selection rules. Specifically, it transmits a set of IPv6 99 source and destination address prefixes and some parameters that are 100 used to control address selection as described in RFC 3484. 102 Each end node is expected to configure its policy table, as described 103 in RFC 3484, using the Address Selection Policy option information as 104 an reference. 106 The format of the Address Selection Policy option is given below: 108 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | OPTION_DASP | option-len | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | label | precedence |z|n|s|d| resvd | prefix-len | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | zone-index (if present (z = 1)) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | | 119 | Prefix (Variable Length) | 120 | | 121 | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | label | precedence |z|n|s|d| resvd | prefix-len | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | zone-index (if present (z = 1)) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 | Prefix (Variable Length) | 129 | | 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 . . 133 . . 134 . . 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | label | precedence |z|n|s|d| resvd | prefix-len | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | zone-index (if present (z = 1)) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 | Prefix (Variable Length) | 142 | | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 [Fig. 1] 148 Fields: 150 option-code: OPTION_DASP (TBD) 152 option-len: The total length of the label fields, precedence fields, 153 zone-index fields, prefix-len fields, and prefix fields in 154 octets. 156 label: An 8-bit unsigned integer; this value is used to make a 157 combination of source address prefixes and destination address 158 prefixes. 160 precedence: An 8-bit unsigned integer; this value is used for 161 sorting destination addresses. 163 z bit 'zone-index' bit. If z bit is set to 1, 32 bit zone-index 164 value is included right after the "prefix-len" field, and 165 "Prefix" value continues after the "zone-index" field. If z bit 166 is 0, "Prefix" value continues right after the "prefix-len" 167 value. 169 n bit 'no privacy iid' bit. If n bit is set to 1, RFC 4941 170 [RFC4941] privacy extensions MUST not be used for this prefix. 171 If n bit is 0, interface ID may use RFC4941. 173 s bit 'source address selection policy' bit. If s bit is set to 1, 174 this prefix is source address selection policy, not RFC3484 175 policy table entry. The usage of this policy is defined in 176 [I-D.arifumi-6man-addr-select-conflict]. 178 d bit 'destination address selection policy' bit. If d bit is set 179 to 1, this prefix is destination address selection policy, not 180 RFC3484 policy table entry. The usage of this policy is defined 181 in [I-D.arifumi-6man-addr-select-conflict]. 183 resvd 4-bit reserved field. Initialized to zero by sender, and 184 ignored by receiver. 186 zone-index: If z-bit is set to 1, this field is inserted between 187 "prefix-len" field and "Prefix" field. Zone-index field is an 188 32-bit unsigned integer and used to specify zones for scoped 189 addresses. This bit length is defined in RFC3493 [RFC3493] as 190 'scope ID'. 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. The 194 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 195 length. 197 Prefix: A variable-length field containing an IP address or the 198 prefix of an IP address. IPv4-mapped address [mapped] must be 199 used to represent an IPv4 address as a prefix value. 201 3. Appearance of this Option 203 The Address Selection Policy option MUST NOT appear in any messages 204 other than the following ones : Solicit, Advertise, Request, Renew, 205 Rebind, Information-Request, and Reply. 207 4. Implementation Considerations 209 If there are multiple DHCPv6 servers, a node may have multiple 210 address selection policies. Since RFC3484 policy table is one and 211 global for a node, multiple polices should be merged in one. In a 212 case that node's interfaces belong to different management domain 213 (e.g. each interfaces are connected different site), it would have 214 conflict policies. The policy merging algorithm is defined in 215 [I-D.arifumi-6man-addr-select-conflict]. 217 o The value 'label' is passed as an unsigned integer, but there is 218 no special meaning for the value, that is whether it is a large or 219 small number. It is used to select a preferred source address 220 prefix corresponding to a destination address prefix by matching 221 the same label value within this DHCP message. DHCPv6 clients 222 need to convert this label to a representation specified by each 223 implementation (e.g., string). 225 o Currently, the value label, precedence are defined as 8-bit 226 unsigned integers. In almost all cases, this value will be 227 enough. 229 o The 'precedence' is used to sort destination addresses. There 230 might be some cases where precedence values will conflict when a 231 client already has a selection policy configured or a client 232 receives multiple policies from multiple DHCP servers (e.g., when 233 a home gateway in a user network is connected to multiple upstream 234 ISPs). In such cases, manual configuration of the policy will be 235 necessary. 237 o The maximum number of address selection rules in one DHCPv6 238 message depend on the prefix length of each rules and maximum 239 DHCPv6 message size defined in RFC3315. It is possible to carry 240 over 3,000 rules (e.g. default policy table defined in RFC3484 241 contains 5 rules) in one DHCPv6 message (maximum UDP message 242 size). 244 o Since the number of selection rules would be large, policy 245 distributer should be care about the DHCPv6 message size. 247 5. Discussion 249 o The 'zone index' value is used to specify a particular zone for 250 scoped addresses. This can be used effectively to control address 251 selection in the site scope (e.g., to tell a node to use a 252 specified source address corresponding to a site-scoped multicast 253 address). However, in some cases such as a link-local scope 254 address, the value specifying one zone is only meaningful locally 255 within that node. There might be some cases where the 256 administrator knows which clients are on the network and wants 257 specific interfaces to be used though. However, in general case, 258 it is hard to use this value. 260 o Since we got a comment that some implementations use 32-bit 261 integers for zone index value, we extended the bit length of the 262 'zone index' field. However, as described above, there might be 263 few cases to specify 'zone index' in policy distribution, we 264 defined this field as optional, controlled by a flag. 266 o There may be some demands to control the use of special address 267 types such as the temporary addresses described in RFC4941 268 [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing 269 not to use a temporary address when it communicate within the an 270 organization's network). It is possible to indicate the type of 271 addresses using reserved field value. 273 o We also proposed a policy distribution option using a Router 274 Advertisement message defined in RFC4861 [RFC4861]. There was a 275 discussion that using DHCPv6 was more suitable to distribute a 276 selection policy, because such policy should be distributed under 277 the site administrator's centralized control. 279 6. Security Considerations 281 A rogue DHCPv6 server could issue bogus address selection policies to 282 a client. This might lead to incorrect address selection by the 283 client, and the affected packets might be blocked at an outgoing ISP 284 because of ingress filtering. 286 To guard against such attacks, both DHCP clients and servers SHOULD 287 use DHCP authentication, as described in section 21 of RFC 3315, 288 "Authentication of DHCP messages." 290 7. IANA Considerations 292 IANA is requested to assign option codes to OPTION_DASP from the 293 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 295 Appendix A. RFC3484 implementation status 297 Today, many operating systems implement address selection mechanism 298 defined in RFC3484. Many of them, however, implement the 299 specification partially. We summarize current implementation status 300 of RFC 3484 at http://www.nttv6.net/dass/. 302 Appendix B. Revision History 304 09: 305 Add 's' and 'd' option for policy merge. 306 correct some typo. 308 08: 309 Add reference for policy conflict discussion. 310 Update some references. 312 07: 313 Added the n bit and its description. 315 06: 316 Added the reason to extend zone index field in discussions 317 section. 318 References updated. 319 Authors' e-mail addresses corrected. 320 Some editorial changes. 322 05: 323 Extended bit length of the zone-index field to 32-bits (thank you 324 Jinmei-sanfor your comment), and changed packet format to reflect 325 the extension. 326 Refrect Yoshifuji-san's comment to use this option information as 327 an reference. 329 Modified the text controlling special address types. 331 04: 332 Added description about policy merge. 333 Modified the text controlling special address types. 335 03: 336 Discussion about DHCPv6 packet size and number of rules added. 337 Authors' e-mail addresses corrected. 338 Some editorial changes. 340 8. References 342 8.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 348 and M. Carney, "Dynamic Host Configuration Protocol for 349 IPv6 (DHCPv6)", RFC 3315, July 2003. 351 [RFC3484] Draves, R., "Default Address Selection for Internet 352 Protocol version 6 (IPv6)", RFC 3484, February 2003. 354 8.2. Informative References 356 [I-D.arifumi-6man-addr-select-conflict] 357 Matsumoto, A., Fujisaki, T., and R. Hiromi, 358 "Considerations of address selection policy conflicts", 359 draft-arifumi-6man-addr-select-conflict-01 (work in 360 progress), October 2009. 362 [I-D.ietf-6man-addr-select-sol] 363 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 364 "Solution approaches for address-selection problems", 365 draft-ietf-6man-addr-select-sol-02 (work in progress), 366 July 2009. 368 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 369 (IPv6) Specification", RFC 2460, December 1998. 371 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 372 Stevens, "Basic Socket Interface Extensions for IPv6", 373 RFC 3493, February 2003. 375 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 376 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 377 September 2007. 379 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 380 Extensions for Stateless Address Autoconfiguration in 381 IPv6", RFC 4941, September 2007. 383 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 384 "Problem Statement for Default Address Selection in Multi- 385 Prefix Environments: Operational Issues of RFC 3484 386 Default Rules", RFC 5220, July 2008. 388 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 389 "Requirements for Address Selection Mechanisms", RFC 5221, 390 July 2008. 392 Authors' Addresses 394 Tomohiro Fujisaki 395 NTT PF Lab 396 3-9-11 Midori-Cho 397 Musashino-shi, Tokyo 180-8585 398 Japan 400 Phone: +81 422 59 7351 401 Email: fujisaki@nttv6.net 403 Arifumi Matsumoto 404 NTT PF Lab 405 3-9-11 Midori-Cho 406 Musashino-shi, Tokyo 180-8585 407 Japan 409 Phone: +81 422 59 3334 410 Email: arifumi@nttv6.net 412 Ruri Hiromi 413 Intec Netcore, Inc. 414 Shinsuna 1-3-3 415 Koto-ku, Tokyo 136-0075 416 Japan 418 Phone: +81 3 5665 5069 419 Email: hiromi@inetcore.com