idnits 2.17.1 draft-fujisaki-dhc-addr-select-opt-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 159: '...on Policy option MUST NOT appear in an...' RFC 2119 keyword, line 238: '..., both DCHP clients and servers SHOULD...' 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 (Nov 2007) is 6004 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) ** Downref: Normative reference to an Informational RFC: RFC 3493 == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-02 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-addr-select-req-04 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 J. Kato 5 Expires: May 4, 2008 S. Niinobe 6 NTT 7 Nov 2007 9 Distributing Address Selection Policy using DHCPv6 10 draft-fujisaki-dhc-addr-select-opt-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 4, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a new DHCPv6 option for distributing address 44 selection policy information defined in RFC3484 to a client. With 45 this option, site administrators can distribute address selection 46 policy to control the node's address selection behavior. 48 1. Introduction 50 RFC3484 [RFC3484] describes algorithms for selecting a default 51 address when a node has multiple destination and/or source addresses 52 by using an address selection policy. However, there are some 53 problems with the default address selection policy in RFC3484 54 [I-D.ietf-v6ops-addr-select-ps], and mechanisms to control a proper 55 source address selection will be necessary. Requiremets for those 56 mechanisms are described in [I-D.ietf-v6ops-addr-select-req], and 57 solutions are discussed in [I-D.arifumi-v6ops-addr-select-sol] This 58 document describes an option for distributing address selection 59 policy information using DHCPv6. 61 2. Terminology 63 This document uses the terminology defined in [RFC2460] and the DHCP 64 specification defined in [RFC3315] 66 3. Address Selection Policy Option 68 The Address Selection Policy Option provides policy information for 69 address selection rules. Specifically, it transmits a set of IPv6 70 source and destination address prefixes and some parameters that are 71 used to control address selection as described in RFC 3484. 73 Each end node is expected to configure its policy table, as described 74 in RFC 3484, using the Address Selection Policy option information as 75 an reference. 77 The format of the Address Selection Policy option is given below: 79 0 1 2 3 81 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 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | OPTION_DASP | option-len | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | label | precedence |z| reserved | prefix-len | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | zone-index (if present (z = 1)) | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | | 90 | Prefix (Variable Length) | 91 | | 92 | | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | label | precedence |z| reserved | prefix-len | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | zone-index (if present (z = 1)) | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | | 99 | Prefix (Variable Length) | 100 | | 101 | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 . . 104 . . 105 . . 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | label | precedence |z| reserved | prefix-len | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | zone-index (if present (z = 1)) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 | Prefix (Variable Length) | 113 | | 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 [Fig. 1] 119 Fields: 121 option-code: OPTION_DASP (TBD) 123 option-len: The total length of the label fields, precedence fields, 124 zone-index fields, prefix-len fields, and prefix fields in 125 octets. 127 label: An 8-bit unsigned integer; this value is used to make a 128 combination of source address prefixes and destination address 129 prefixes. 131 precedence: An 8-bit unsigned integer; this value is used for 132 sorting destination addresses. 134 z bit If z bit is set to 1, 32 bit zone-index value is included 135 right after the "prefix-len" field, and "Prefix" value continues 136 after the "zone-index" field. If z bit is 0, "Prefix" value 137 contitunes right after the "prefix-len" value. 139 reserved 7-bit reservied field. Initialized to zero by sender, and 140 ignored by receiver. 142 zone-index: If z-bit is set to 1, this field is inserted between 143 "prefix-len" field and "Prefix" field. Zone-index field is an 144 32-bit unsigned integer and used to specify zones for scoped 145 addresses. This bit length is defined in RFC3493 [RFC3493] as 146 'scope ID'. 148 prefix-len: An 8-bit unsigned integer; the number of leading bits in 149 the prefix that are valid. The value ranges from 0 to 128. The 150 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 151 length. 153 Prefix: A variable-length field containing an IP address or the 154 prefix of an IP address. IPv4-mapped address [mapped] must be 155 used to represent an IPv4 address as a prefix value. 157 4. Appearance of this Option 159 The Address Selection Policy option MUST NOT appear in any messages 160 other than the following ones : Solicit, Advertise, Request, Renew, 161 Rebind, Information-Request, and Reply. 163 5. Implementation Considerations 164 o The value 'label' is passed as an unsigned integer, but there is 165 no special meaning for the value, that is whether it is a large or 166 small number. It is used to select a preferred source address 167 prefix corresponding to a destination address prefix by matching 168 the same label value within this DHCP message. DHCPv6 clients 169 need to convert this label to a representation specified by each 170 implementation (e.g., string). 172 o Currently, the value label, precedence are defined as 8-bit 173 unsigned integers. In almost all cases, this value will be 174 enough. 176 o The 'precedence' is used to sort destination addresses. There 177 might be some cases where precedence values will conflict when a 178 client already has a selection policy configured or a client 179 receives multiple policies from multiple DHCP servers (e.g., when 180 a home gateway in a user network is connected to multiple upstream 181 ISPs). In such cases, manual configuration of the policy will be 182 necessary. 184 o The maximum number of address selection rules in one DHCPv6 185 message depend on the prefix length of each rules and maximum 186 DHCPv6 message size defined in RFC3315. It is possible to carry 187 over 3,000 rules (e.g. default policy table defined in RFC3484 188 contains 5 rules) in one DHCPv6 message (maximum UDP message 189 size). 191 o Since the number of selection rules would be large, policy 192 distributer should be care about the DHCPv6 message size. 194 o If a ndoe has multiple interfaces, the node may have multiple 195 address selection policies. Since RFC3484 policy table is one and 196 global for a node, multiple polices should be merged in one. In a 197 case that node's interfaces belong to different management domain 198 (e.g. each interfaces are connected different site), it would have 199 conflict policies. In that case, it would be possible to merge 200 them by using other information such as routing information or 201 preference for each interfaces, however, such automatic policy 202 merge lead to potential security problems such as using unintended 203 source addresses. 205 6. Discussion 207 o The 'zone index' value is used to specify a particular zone for 208 scoped addresses. This can be used effectively to control address 209 selection in the site scope (e.g., to tell a node to use a 210 specified source address corresponding to a site-scoped multicast 211 address). However, in some cases such as a link-local scope 212 address, the value specifying one zone is only meaningful locally 213 within that node. There might be some cases where the 214 administrator knows which clients are on the network and wants 215 specific interfaces to be used though. However, it is hard to use 216 this value in general case. 218 o There may be some demands to control the use of special address 219 types such as the temporary addresses described in RFC3041 220 [RFC3041], address assigned by DHCPv6 and so on. (e.g., informing 221 not to use a temporary address when it communicate within the an 222 organization's network). It is possible to indicate the type of 223 addresses using reserved field value. 225 o We also proposed a policy distribution option using a Router 226 Advertisement message defined in RFC2461 [RFC2461]. There was a 227 discussion that using DHCPv6 was more suitable to distribute a 228 selection policy, because such policy should be distributed under 229 the site administrator's centralized control. 231 7. Security Considerations 233 A rogue DHCPv6 server could issue bogus address selection policies to 234 a client. This might lead to incorrect address selection by the 235 client, and the affected packets might be blocked at an outgoing ISP 236 because of ingress filtering. 238 To guard against such attacks, both DCHP clients and servers SHOULD 239 use DHCP authentication, as described in section 21 of RFC 3315, 240 "Authentication of DHCP messages." 242 8. IANA Considerations 244 IANA is requested to assign option codes to OPTION_DASP from the 245 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 247 Appendix A. RFC3484 implementation status 249 Today, many operating systems implement address selection mechanism 250 defined in RFC3484. Many of them, however, implement the 251 specification partially. We summarize current implementation status 252 of RFC 3484 at http://www.nttv6.net/dass/. 254 Appendix B. Revision History 256 05: 257 Extended bit length of the zone-index field to 32-bits (thank you 258 Jinmei-sanfor your comment), and changed packet format to reflect 259 the extension. 260 Refrect Yoshifuji-san's comment to use this option information as 261 an reference. 262 Modified the text controling special address types. 264 04: 265 Added description about policy merge. 266 Modified the text controling special address types. 268 03: 269 Discussion about DHCPv6 packetsize and number of rules added. 270 Authors' e-mail addresses corrected. 271 Some editorial changes. 273 9. References 275 9.1. Normative References 277 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 278 and M. Carney, "Dynamic Host Configuration Protocol for 279 IPv6 (DHCPv6)", RFC 3315, July 2003. 281 [RFC3484] Draves, R., "Default Address Selection for Internet 282 Protocol version 6 (IPv6)", RFC 3484, February 2003. 284 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 285 Stevens, "Basic Socket Interface Extensions for IPv6", 286 RFC 3493, February 2003. 288 9.2. Informative References 290 [I-D.arifumi-v6ops-addr-select-sol] 291 Matsumoto, A., "Solution approaches for address-selection 292 problems", draft-arifumi-v6ops-addr-select-sol-00 (work in 293 progress), June 2007. 295 [I-D.ietf-v6ops-addr-select-ps] 296 Matsumoto, A., "Problem Statement of Default Address 297 Selection in Multi-prefix Environment: Operational Issues 298 of RFC3484 Default Rules", 299 draft-ietf-v6ops-addr-select-ps-02 (work in progress), 300 October 2007. 302 [I-D.ietf-v6ops-addr-select-req] 303 Matsumoto, A., "Requirements for address selection 304 mechanisms", draft-ietf-v6ops-addr-select-req-04 (work in 305 progress), November 2007. 307 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 308 (IPv6) Specification", RFC 2460, December 1998. 310 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 311 Discovery for IP Version 6 (IPv6)", RFC 2461, 312 December 1998. 314 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 315 Stateless Address Autoconfiguration in IPv6", RFC 3041, 316 January 2001. 318 Authors' Addresses 320 Tomohiro Fujisaki 321 NTT PF Lab 322 3-9-11 Midori-Cho 323 Musashino-shi, Tokyo 180-8585 324 Japan 326 Phone: +81 422 59 7351 327 Email: fujisaki.tomohiro@lab.ntt.co.jp 329 Arifumi Matsumoto 330 NTT PF Lab 331 3-9-11 Midori-Cho 332 Musashino-shi, Tokyo 180-8585 333 Japan 335 Phone: +81 422 59 3334 336 Email: arifumi@nttv6.net 338 Jun-ya Kato 339 NTT PF Lab 340 3-9-11 Midori-Cho 341 Musashino-shi, Tokyo 180-8585 342 Japan 344 Phone: +81 422 59 2939 345 Email: kato@syce.net 346 Shirou Niinobe 347 NTT PF Lab 348 3-9-11 Midori-Cho 349 Musashino-shi, Tokyo 180-8585 350 Japan 352 Phone: +81 422 59 4949 353 Email: nin@syce.net 355 Full Copyright Statement 357 Copyright (C) The IETF Trust (2007). 359 This document is subject to the rights, licenses and restrictions 360 contained in BCP 78, and except as set forth therein, the authors 361 retain all their rights. 363 This document and the information contained herein are provided on an 364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 366 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 367 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 368 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 369 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 371 Intellectual Property 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Acknowledgment 397 Funding for the RFC Editor function is provided by the IETF 398 Administrative Support Activity (IASA).