idnits 2.17.1 draft-fujisaki-6man-addr-select-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 -- The document date (July 28, 2010) is 4992 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 (-05) exists of draft-ietf-6man-addr-select-considerations-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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group T. Fujisaki 3 Internet-Draft A. Matsumoto 4 Intended status: Standards Track NTT 5 Expires: January 29, 2011 R. Hiromi 6 Intec Netcore 7 July 28, 2010 9 Distributing Address Selection Policy using DHCPv6 10 draft-fujisaki-6man-addr-select-opt-00.txt 12 Abstract 14 This document describes a new DHCPv6 option for distributing address 15 selection policy information defined in RFC3484 to a client. With 16 this option, site administrators can distribute address selection 17 policy to control the node's address selection behavior. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 29, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 RFC3484 [RFC3484] describes algorithms for selecting a default 54 address when a node has multiple destination and/or source addresses 55 by using an address selection policy. However, there are some 56 problems with the default address selection policy in RFC3484 57 [RFC5220], and mechanisms to control a proper source address 58 selection will be necessary. Requiremets for those mechanisms are 59 described in [RFC5221]. Solutions are discussed in 60 [I-D.ietf-6man-addr-select-sol] and 61 [I-D.ietf-6man-addr-select-considerations]. This document describes 62 an option for distributing address selection policy information using 63 DHCPv6, which is refered as `most proactive approach' in the solution 64 document, and `perferable protocol to deliver RFC3848 policies' in 65 consideration document. 67 1.1. Conventions Used in This Document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC2119 [RFC2119]. 73 1.2. Terminology 75 This document uses the terminology defined in [RFC2460] and the DHCP 76 specification defined in [RFC3315] 78 2. Address Selection Policy Option 80 The Address Selection Policy Option provides policy information for 81 address selection rules. Specifically, it transmits a set of IPv6 82 source and destination address prefixes and some parameters that are 83 used to control address selection as described in RFC 3484. 85 Each end node is expected to configure its policy table, as described 86 in RFC 3484, using the Address Selection Policy option information as 87 an reference. 89 The format of the Address Selection Policy option is given below: 91 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | OPTION_DASP | option-len | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | label | precedence |z|n| reserved | prefix-len | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | zone-index (if present (z = 1)) | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | | 102 | Prefix (Variable Length) | 103 | | 104 | | 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 . . 116 . . 117 . . 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | label | precedence |z|n| reserved | prefix-len | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | zone-index (if present (z = 1)) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | | 124 | Prefix (Variable Length) | 125 | | 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 [Fig. 1] 131 Fields: 133 option-code: OPTION_DASP (TBD) 135 option-len: The total length of the label fields, precedence fields, 136 zone-index fields, prefix-len fields, and prefix fields in 137 octets. 139 label: An 8-bit unsigned integer; this value is used to make a 140 combination of source address prefixes and destination address 141 prefixes. 143 precedence: An 8-bit unsigned integer; this value is used for 144 sorting destination addresses. 146 z bit: 'zone-index' bit. If z bit is set to 1, 32 bit zone-index 147 value is included right after the "prefix-len" field, and 148 "Prefix" value continues after the "zone-index" field. If z bit 149 is 0, "Prefix" value contitunes right after the "prefix-len" 150 value. 152 n bit: 'no privacy iid' bit. If n bit is set to 1, RFC 4941 153 [RFC4941] privacy extensions MUST NOT be used for this prefix. 154 If n bit is 0, interface ID may use RFC4941. 156 reserved: 6-bit reservied field. Initialized to zero by sender, and 157 ignored by receiver. 159 zone-index: If z-bit is set to 1, this field is inserted between 160 "prefix-len" field and "Prefix" field. Zone-index field is an 161 32-bit unsigned integer and used to specify zones for scoped 162 addresses. This bit length is defined in RFC3493 [RFC3493] as 163 'scope ID'. 165 prefix-len: An 8-bit unsigned integer; the number of leading bits in 166 the prefix that are valid. The value ranges from 0 to 128. The 167 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 168 length. 170 Prefix: A variable-length field containing an IP address or the 171 prefix of an IP address. IPv4-mapped address [mapped] must be 172 used to represent an IPv4 address as a prefix value. 174 3. Appearance of this Option 176 The Address Selection Policy option MUST NOT appear in any messages 177 other than the following ones : Solicit, Advertise, Request, Renew, 178 Rebind, Information-Request, and Reply. 180 4. Implementation Considerations 182 o The value 'label' is passed as an unsigned integer, but there is 183 no special meaning for the value, that is whether it is a large or 184 small number. It is used to select a preferred source address 185 prefix corresponding to a destination address prefix by matching 186 the same label value within this DHCP message. DHCPv6 clients 187 need to convert this label to a representation specified by each 188 implementation (e.g., string). 190 o Currently, the value label, precedence are defined as 8-bit 191 unsigned integers. In almost all cases, this value will be 192 enough. 194 o The maximum number of address selection rules in one DHCPv6 195 message depend on the prefix length of each rules and maximum 196 DHCPv6 message size defined in RFC3315. It is possible to carry 197 over 3,000 rules (e.g. default policy table defined in RFC3484 198 contains 5 rules) in one DHCPv6 message (maximum UDP message 199 size). 201 o Since the number of selection rules would be large, policy 202 distributer should be care about the DHCPv6 message size. 204 o If there are multiple DHCPv6 servers (e.g. a node with multiple 205 interface), a node may have multiple address selection policies. 206 Since RFC3484 policy table is one and global for a node, the node 207 have to decide how to process multiple policies. This policy 208 conflict is discussed in 209 [I-D.ietf-6man-addr-select-considerations]. 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 6. Security Considerations 239 A rogue DHCPv6 server could issue bogus address selection policies to 240 a client. This might lead to incorrect address selection by the 241 client, and the affected packets might be blocked at an outgoing ISP 242 because of ingress filtering. 244 To guard against such attacks, both DCHP clients and servers SHOULD 245 use DHCP authentication, as described in section 21 of RFC 3315, 246 "Authentication of DHCP messages." 248 7. IANA Considerations 250 IANA is requested to assign option codes to OPTION_DASP from the 251 option-code space as defined in section "DHCPv6 Options" of RFC 3315. 253 8. References 255 8.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 261 and M. Carney, "Dynamic Host Configuration Protocol for 262 IPv6 (DHCPv6)", RFC 3315, July 2003. 264 [RFC3484] Draves, R., "Default Address Selection for Internet 265 Protocol version 6 (IPv6)", RFC 3484, February 2003. 267 8.2. Informative References 269 [I-D.ietf-6man-addr-select-considerations] 270 Chown, T., "Considerations for IPv6 Address Selection 271 Policy Changes", 272 draft-ietf-6man-addr-select-considerations-02 (work in 273 progress), July 2010. 275 [I-D.ietf-6man-addr-select-sol] 276 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 277 approaches for address-selection problems", 278 draft-ietf-6man-addr-select-sol-03 (work in progress), 279 March 2010. 281 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 282 (IPv6) Specification", RFC 2460, December 1998. 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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 289 Extensions for Stateless Address Autoconfiguration in 290 IPv6", RFC 4941, September 2007. 292 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 293 "Problem Statement for Default Address Selection in Multi- 294 Prefix Environments: Operational Issues of RFC 3484 295 Default Rules", RFC 5220, July 2008. 297 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 298 "Requirements for Address Selection Mechanisms", RFC 5221, 299 July 2008. 301 Authors' Addresses 303 Tomohiro Fujisaki 304 NTT PF Lab 305 3-9-11 Midori-Cho 306 Musashino-shi, Tokyo 180-8585 307 Japan 309 Phone: +81 422 59 7351 310 Email: fujisaki@nttv6.net 311 Arifumi Matsumoto 312 NTT PF Lab 313 3-9-11 Midori-Cho 314 Musashino-shi, Tokyo 180-8585 315 Japan 317 Phone: +81 422 59 3334 318 Email: arifumi@nttv6.net 320 Ruri Hiromi 321 Intec Netcore, Inc. 322 Shinsuna 1-3-3 323 Koto-ku, Tokyo 136-0075 324 Japan 326 Phone: +81 3 5665 5069 327 Email: hiromi@inetcore.com