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