idnits 2.17.1 draft-fujisaki-dhc-addr-select-opt-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 426. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2008) is 5802 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 (-03) exists of draft-ietf-6man-addr-select-sol-00 == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-06 -- 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 (~~), 3 warnings (==), 9 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 S. Niinobe 5 Expires: December 6, 2008 NTT 6 R. Hiromi 7 Intec Netcore 8 K. Kanayama 9 Intec 10 June 4, 2008 12 Distributing Address Selection Policy using DHCPv6 13 draft-fujisaki-dhc-addr-select-opt-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 6, 2008. 40 Abstract 42 This document describes a new DHCPv6 option for distributing address 43 selection policy information defined in RFC3484 to a client. With 44 this option, site administrators can distribute address selection 45 policy to control the node's address selection behavior. 47 1. Introduction 49 RFC3484 [RFC3484] describes algorithms for selecting a default 50 address when a node has multiple destination and/or source addresses 51 by using an address selection policy. However, there are some 52 problems with the default address selection policy in RFC3484 53 [I-D.ietf-v6ops-addr-select-ps], and mechanisms to control a proper 54 source address selection will be necessary. Requiremets for those 55 mechanisms are described in [I-D.ietf-v6ops-addr-select-req], and 56 solutions are discussed in [I-D.ietf-6man-addr-select-sol] This 57 document describes an option for distributing address selection 58 policy information using DHCPv6, which is refered as `most proactive 59 approach' in the solution document. 61 1.1. Conventions Used in This Document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC2119 [RFC2119]. 67 1.2. Terminology 69 This document uses the terminology defined in [RFC2460] and the DHCP 70 specification defined in [RFC3315] 72 2. Address Selection Policy Option 74 The Address Selection Policy Option provides policy information for 75 address selection rules. Specifically, it transmits a set of IPv6 76 source and destination address prefixes and some parameters that are 77 used to control address selection as described in RFC 3484. 79 Each end node is expected to configure its policy table, as described 80 in RFC 3484, using the Address Selection Policy option information as 81 an reference. 83 The format of the Address Selection Policy option is given below: 85 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | OPTION_DASP | option-len | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | label | precedence |z| reserved | prefix-len | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | zone-index (if present (z = 1)) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | | 96 | Prefix (Variable Length) | 97 | | 98 | | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | label | precedence |z| reserved | prefix-len | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | zone-index (if present (z = 1)) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | | 105 | Prefix (Variable Length) | 106 | | 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 . . 110 . . 111 . . 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | label | precedence |z| reserved | prefix-len | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | zone-index (if present (z = 1)) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 | Prefix (Variable Length) | 119 | | 120 | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 [Fig. 1] 125 Fields: 127 option-code: OPTION_DASP (TBD) 129 option-len: The total length of the label fields, precedence fields, 130 zone-index fields, prefix-len fields, and prefix fields in 131 octets. 133 label: An 8-bit unsigned integer; this value is used to make a 134 combination of source address prefixes and destination address 135 prefixes. 137 precedence: An 8-bit unsigned integer; this value is used for 138 sorting destination addresses. 140 z bit If z bit is set to 1, 32 bit zone-index value is included 141 right after the "prefix-len" field, and "Prefix" value continues 142 after the "zone-index" field. If z bit is 0, "Prefix" value 143 contitunes right after the "prefix-len" value. 145 reserved 7-bit reservied field. Initialized to zero by sender, and 146 ignored by receiver. 148 zone-index: If z-bit is set to 1, this field is inserted between 149 "prefix-len" field and "Prefix" field. Zone-index field is an 150 32-bit unsigned integer and used to specify zones for scoped 151 addresses. This bit length is defined in RFC3493 [RFC3493] as 152 'scope ID'. 154 prefix-len: An 8-bit unsigned integer; the number of leading bits in 155 the prefix that are valid. The value ranges from 0 to 128. The 156 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 157 length. 159 Prefix: A variable-length field containing an IP address or the 160 prefix of an IP address. IPv4-mapped address [mapped] must be 161 used to represent an IPv4 address as a prefix value. 163 3. Appearance of this Option 165 The Address Selection Policy option MUST NOT appear in any messages 166 other than the following ones : Solicit, Advertise, Request, Renew, 167 Rebind, Information-Request, and Reply. 169 4. Implementation Considerations 170 o The value 'label' is passed as an unsigned integer, but there is 171 no special meaning for the value, that is whether it is a large or 172 small number. It is used to select a preferred source address 173 prefix corresponding to a destination address prefix by matching 174 the same label value within this DHCP message. DHCPv6 clients 175 need to convert this label to a representation specified by each 176 implementation (e.g., string). 178 o Currently, the value label, precedence are defined as 8-bit 179 unsigned integers. In almost all cases, this value will be 180 enough. 182 o The 'precedence' is used to sort destination addresses. There 183 might be some cases where precedence values will conflict when a 184 client already has a selection policy configured or a client 185 receives multiple policies from multiple DHCP servers (e.g., when 186 a home gateway in a user network is connected to multiple upstream 187 ISPs). In such cases, manual configuration of the policy will be 188 necessary. 190 o The maximum number of address selection rules in one DHCPv6 191 message depend on the prefix length of each rules and maximum 192 DHCPv6 message size defined in RFC3315. It is possible to carry 193 over 3,000 rules (e.g. default policy table defined in RFC3484 194 contains 5 rules) in one DHCPv6 message (maximum UDP message 195 size). 197 o Since the number of selection rules would be large, policy 198 distributer should be care about the DHCPv6 message size. 200 o If a ndoe has multiple interfaces, the node may have multiple 201 address selection policies. Since RFC3484 policy table is one and 202 global for a node, multiple polices should be merged in one. In a 203 case that node's interfaces belong to different management domain 204 (e.g. each interfaces are connected different site), it would have 205 conflict policies. In that case, it would be possible to merge 206 them by using other information such as routing information or 207 preference for each interfaces, however, such automatic policy 208 merge lead to potential security problems such as using unintended 209 source addresses. 211 5. Discussion 213 o The 'zone index' value is used to specify a particular zone for 214 scoped addresses. This can be used effectively to control address 215 selection in the site scope (e.g., to tell a node to use a 216 specified source address corresponding to a site-scoped multicast 217 address). However, in some cases such as a link-local scope 218 address, the value specifying one zone is only meaningful locally 219 within that node. There might be some cases where the 220 administrator knows which clients are on the network and wants 221 specific interfaces to be used though. However, in general case, 222 it is hard to use this value. 224 o Since we got a comment that some implementations use 32-bit 225 integers for zone index value, we extended the bit lenght of the 226 'zone index' field. However, as described above, there might be 227 few cases to specify 'zone index' in policy distribution, we 228 defined this field as optional, controled by a flag. 230 o There may be some demands to control the use of special address 231 types such as the temporary addresses described in RFC4941 232 [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing 233 not to use a temporary address when it communicate within the an 234 organization's network). It is possible to indicate the type of 235 addresses using reserved field value. 237 o We also proposed a policy distribution option using a Router 238 Advertisement message defined in RFC4861 [RFC4861]. There was a 239 discussion that using DHCPv6 was more suitable to distribute a 240 selection policy, because such policy should be distributed under 241 the site administrator's centralized control. 243 6. Security Considerations 245 A rogue DHCPv6 server could issue bogus address selection policies to 246 a client. This might lead to incorrect address selection by the 247 client, and the affected packets might be blocked at an outgoing ISP 248 because of ingress filtering. 250 To guard against such attacks, both DCHP clients and servers SHOULD 251 use DHCP authentication, as described in section 21 of RFC 3315, 252 "Authentication of DHCP messages." 254 7. IANA Considerations 256 IANA is requested to assign option codes to OPTION_DASP from the 257 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 259 Appendix A. RFC3484 implementation status 261 Today, many operating systems implement address selection mechanism 262 defined in RFC3484. Many of them, however, implement the 263 specification partially. We summarize current implementation status 264 of RFC 3484 at http://www.nttv6.net/dass/. 266 Appendix B. Revision History 268 06: 269 Added the reasion to extend zone index field in discussions 270 section. 271 References updated. 272 Authors' e-mail addresses corrected. 273 Some editorial changes. 275 05: 276 Extended bit length of the zone-index field to 32-bits (thank you 277 Jinmei-sanfor your comment), and changed packet format to reflect 278 the extension. 279 Refrect Yoshifuji-san's comment to use this option information as 280 an reference. 281 Modified the text controling special address types. 283 04: 284 Added description about policy merge. 285 Modified the text controling special address types. 287 03: 288 Discussion about DHCPv6 packetsize and number of rules added. 289 Authors' e-mail addresses corrected. 290 Some editorial changes. 292 8. References 294 8.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 300 and M. Carney, "Dynamic Host Configuration Protocol for 301 IPv6 (DHCPv6)", RFC 3315, July 2003. 303 [RFC3484] Draves, R., "Default Address Selection for Internet 304 Protocol version 6 (IPv6)", RFC 3484, February 2003. 306 8.2. Informative References 308 [I-D.ietf-6man-addr-select-sol] 309 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 310 "Solution approaches for address-selection problems", 311 draft-ietf-6man-addr-select-sol-00 (work in progress), 312 January 2008. 314 [I-D.ietf-v6ops-addr-select-ps] 315 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 316 "Problem Statement of Default Address Selection in Multi- 317 prefix Environment: Operational Issues of RFC3484 Default 318 Rules", draft-ietf-v6ops-addr-select-ps-06 (work in 319 progress), May 2008. 321 [I-D.ietf-v6ops-addr-select-req] 322 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 323 "Requirements for address selection mechanisms", 324 draft-ietf-v6ops-addr-select-req-07 (work in progress), 325 May 2008. 327 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 328 (IPv6) Specification", RFC 2460, December 1998. 330 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 331 Stevens, "Basic Socket Interface Extensions for IPv6", 332 RFC 3493, February 2003. 334 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 335 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 336 September 2007. 338 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 339 Extensions for Stateless Address Autoconfiguration in 340 IPv6", RFC 4941, September 2007. 342 Authors' Addresses 344 Tomohiro Fujisaki 345 NTT PF Lab 346 3-9-11 Midori-Cho 347 Musashino-shi, Tokyo 180-8585 348 Japan 350 Phone: +81 422 59 7351 351 Email: fujisaki@nttv6.net 352 Arifumi Matsumoto 353 NTT PF Lab 354 3-9-11 Midori-Cho 355 Musashino-shi, Tokyo 180-8585 356 Japan 358 Phone: +81 422 59 3334 359 Email: arifumi@nttv6.net 361 Shirou Niinobe 362 NTT PF Lab 363 3-9-11 Midori-Cho 364 Musashino-shi, Tokyo 180-8585 365 Japan 367 Phone: +81 422 59 4949 368 Email: nin@syce.net 370 Ruri Hiromi 371 Intec Netcore, Inc. 372 Shinsuna 1-3-3 373 Koto-ku, Tokyo 136-0075 374 Japan 376 Phone: +81 3 5665 5069 377 Email: hiromi@inetcore.com 379 Ken-ichi Kanayama 380 INTEC Systems Institute, Inc. 381 Shimoshin-machi 5-33 382 Toyama-shi, Toyama 930-0804 383 Japan 385 Phone: +81 76 444 8088 386 Email: kanayama_kenichi@intec-si.co.jp 388 Full Copyright Statement 390 Copyright (C) The IETF Trust (2008). 392 This document is subject to the rights, licenses and restrictions 393 contained in BCP 78, and except as set forth therein, the authors 394 retain all their rights. 396 This document and the information contained herein are provided on an 397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 399 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 400 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 401 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Intellectual Property 406 The IETF takes no position regarding the validity or scope of any 407 Intellectual Property Rights or other rights that might be claimed to 408 pertain to the implementation or use of the technology described in 409 this document or the extent to which any license under such rights 410 might or might not be available; nor does it represent that it has 411 made any independent effort to identify any such rights. Information 412 on the procedures with respect to rights in RFC documents can be 413 found in BCP 78 and BCP 79. 415 Copies of IPR disclosures made to the IETF Secretariat and any 416 assurances of licenses to be made available, or the result of an 417 attempt made to obtain a general license or permission for the use of 418 such proprietary rights by implementers or users of this 419 specification can be obtained from the IETF on-line IPR repository at 420 http://www.ietf.org/ipr. 422 The IETF invites any interested party to bring to its attention any 423 copyrights, patents or patent applications, or other proprietary 424 rights that may cover technology that may be required to implement 425 this standard. Please address the information to the IETF at 426 ietf-ipr@ietf.org.