idnits 2.17.1 draft-fujisaki-dhc-addr-select-opt-01.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 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 269. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 141: '...on Policy option MUST NOT appear in an...' RFC 2119 keyword, line 187: '..., both DCHP clients and servers SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Dec 2005) is 6704 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Expires: June 4, 2006 J. Kato 5 S. Niinobe 6 NTT 7 Dec 2005 9 Distributing Default Address Selection Policy using DHCPv6 10 draft-fujisaki-dhc-addr-select-opt-01.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 June 4, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes a new DHCPv6 option for distributing default 44 address selection policy information to a client. With this option, 45 site administrators can distribute address selection policy to 46 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. Administrators can control the 53 node's default address selection behavior by distributing the policy. 54 Practical usages are described in [A. Matsumoto]. This document 55 describes an option for distributing default address selection policy 56 information using DHCPv6. 58 2. Terminology 60 This document uses the terminology defined in [RFC2460] and the DHCP 61 specification defined in [RFC3315] 63 3. Default Address Selection Policy Option 65 The Default Address Selection Policy Option provides policy 66 information for address selection rules. Specifically, it transmits 67 a set of IPv6 source and destination address prefixes and some 68 parameters that are used to control address selection as described in 69 RFC 3484. 71 Each end node is expected to configure its policy table, as described 72 in RFC 3484, in a manner consistent with the Default Address 73 Selection Policy option information. 75 The format of the Default Address Selection Policy option is given 76 below: 78 0 1 2 3 80 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 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | OPTION_DASP | option-len | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | label | precedence | zone-index | prefix-len | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | | 87 | Prefix (Variable Length) | 88 | | 89 | | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | label | precedence | zone-index | prefix-len | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | | 94 | Prefix (Variable Length) | 95 | | 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 . . 99 . . 100 . . 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | label | precedence | zone-index | prefix-len | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | | 105 | Prefix (Variable Length) | 106 | | 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 [Fig. 1] 112 Fields: 114 option-code: OPTION_DASP (TBD) 116 option-len: The total length of the label fields, precedence fields, 117 zone-index fields, prefix-len fields, and prefix fields in 118 octets. 120 label: An 8-bit unsigned integer; this value is used to make a 121 combination of source address prefixes and destination address 122 prefixes. 124 precedence: An 8-bit unsigned integer; this value is used for sorting 125 destination addresses. 127 zone-index: An 8-bit unsigned integer; this value is used to specify 128 zones for scoped addresses. 130 prefix-len: An 8-bit unsigned integer; the number of leading bits in 131 the prefix that are valid. The value ranges from 0 to 128. The 132 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 133 length. 135 Prefix: A variable-length field containing an IP address or the 136 prefix of an IP address. IPv4-mapped address [mapped] must be 137 used to represent an IPv4 address as a prefix value. 139 4. Appearance of this Option 141 The Default Address Selection Policy option MUST NOT appear in any 142 messages other than the following ones : Solicit, Advertise, Request, 143 Renew, Rebind, Information-Request, and Reply. 145 5. Implementation Considerations 147 o The value 'label' is passed as an unsigned integer, but there is 148 no special meaning for the value, that is whether it is a large or 149 small number. It is used to select a preferred source address 150 prefix corresponding to a destination address prefix by matching 151 the same label value within this DHCP message. DHCPv6 clients 152 need to convert this label to a representation specified by each 153 implementation (e.g., string). 155 o Currently, the value label, precedence, and zone indices are 156 defined as 8-bit unsigned integers. In almost all cases, this 157 value will be enough. 159 o The 'precedence' is used to sort destination addresses. There 160 might be some cases where precedence values will conflict when a 161 client already has a selection policy configured or a client 162 receives multiple policies from multiple DHCP servers (e.g., when 163 a home gateway in a user network is connected to multiple upstream 164 ISPs). In such cases, manual configuration of the policy will be 165 necessary. 167 6. Discussion 169 o The 'zone index' value is used to specify a particular zone for 170 scoped addresses. This can be used effectively to control address 171 selection in the site scope (e.g., to tell a node to use a 172 specified source address corresponding to a site-scoped multicast 173 address). However, in some cases such as a link-local scope 174 address, the value specifying one zone is only meaningful locally 175 within that node. There might be some cases where the 176 administrator knows which clients are on the network and wants 177 specific interfaces to be used though. However, it is hard to use 178 this value in general case. 180 7. Security Considerations 182 A rogue DHCPv6 server could issue bogus default address selection 183 policies to a client. This might lead to incorrect address selection 184 by the client, and the affected packets might be blocked at an 185 outgoing ISP because of ingress filtering. 187 To guard against such attacks, both DCHP clients and servers SHOULD 188 use DHCP authentication, as described in section 21 of RFC 3315, 189 "Authentication of DHCP messages." 191 8. References 193 [A. Matsumoto] 194 Matsumoto, A., Fujisaki, T., and J. Kato, "Practical 195 Usages of Default Address Selection Policy Distribution", 196 draft-arifumi-ipv6-policy-dist-00.txt-00.txt. (Work In 197 Progress) (work in progress), Dec 1 2005. 199 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 200 (IPv6) Specification", RFC 2460, December 1998. 202 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 203 and M. Carney, "Dynamic Host Configuration Protocol for 204 IPv6 (DHCPv6)", RFC 3315, July 2003. 206 [RFC3484] Draves, R., "Default Address Selection for Internet 207 Protocol version 6 (IPv6)", RFC 3484, February 2003. 209 Authors' Addresses 211 Tomohiro Fujisaki 212 NTT PF Lab 213 3-9-11 Midori-Cho 214 Musashino-shi, Tokyo 180-8585 215 Japan 217 Phone: +81 422 59 7351 218 Email: fujisaki.tomohiroi@lab.ntt.co.jp 220 Arifumi Matsumoto 221 NTT PF Lab 222 3-9-11 Midori-Cho 223 Musashino-shi, Tokyo 180-8585 224 Japan 226 Phone: +81 422 59 3334 227 Email: arifumi@nttv6.net 229 Jun-ya Kato 230 NTT PF Lab 231 3-9-11 Midori-Cho 232 Musashino-shi, Tokyo 180-8585 233 Japan 235 Phone: +81 422 59 2939 236 Email: kato@syce.net 238 Shirou Niinobe 239 NTT PF Lab 240 3-9-11 Midori-Cho 241 Musashino-shi, Tokyo 180-8585 242 Japan 244 Phone: +81 422 59 4949 245 Email: nin@syce.net 247 Intellectual Property Statement 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 258 Copies of IPR disclosures made to the IETF Secretariat and any 259 assurances of licenses to be made available, or the result of an 260 attempt made to obtain a general license or permission for the use of 261 such proprietary rights by implementers or users of this 262 specification can be obtained from the IETF on-line IPR repository at 263 http://www.ietf.org/ipr. 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights that may cover technology that may be required to implement 268 this standard. Please address the information to the IETF at 269 ietf-ipr@ietf.org. 271 Disclaimer of Validity 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 276 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 277 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 278 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Copyright Statement 283 Copyright (C) The Internet Society (2005). This document is subject 284 to the rights, licenses and restrictions contained in BCP 78, and 285 except as set forth therein, the authors retain all their rights. 287 Acknowledgment 289 Funding for the RFC Editor function is currently provided by the 290 Internet Society.