DHC Working Group T. Fujisaki Internet-Draft A. Matsumoto Intended status: Standards Track J. Kato Expires: May 4, 2008 S. Niinobe NTT Nov 2007 Distributing Address Selection Policy using DHCPv6 draft-fujisaki-dhc-addr-select-opt-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior. Fujisaki, et al. Expires May 4, 2008 [Page 1] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 1. Introduction RFC3484 [RFC3484] describes algorithms for selecting a default address when a node has multiple destination and/or source addresses by using an address selection policy. However, there are some problems with the default address selection policy in RFC3484 [I-D.ietf-v6ops-addr-select-ps], and mechanisms to control a proper source address selection will be necessary. Requiremets for those mechanisms are described in [I-D.ietf-v6ops-addr-select-req], and solutions are discussed in [I-D.arifumi-v6ops-addr-select-sol] This document describes an option for distributing address selection policy information using DHCPv6. 2. Terminology This document uses the terminology defined in [RFC2460] and the DHCP specification defined in [RFC3315] 3. Address Selection Policy Option The Address Selection Policy Option provides policy information for address selection rules. Specifically, it transmits a set of IPv6 source and destination address prefixes and some parameters that are used to control address selection as described in RFC 3484. Each end node is expected to configure its policy table, as described in RFC 3484, using the Address Selection Policy option information as an reference. The format of the Address Selection Policy option is given below: Fujisaki, et al. Expires May 4, 2008 [Page 2] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DASP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | label | precedence |z| reserved | prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zone-index (if present (z = 1)) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Prefix (Variable Length) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | label | precedence |z| reserved | prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zone-index (if present (z = 1)) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Prefix (Variable Length) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | label | precedence |z| reserved | prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zone-index (if present (z = 1)) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Prefix (Variable Length) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Fig. 1] Fields: Fujisaki, et al. Expires May 4, 2008 [Page 3] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 option-code: OPTION_DASP (TBD) option-len: The total length of the label fields, precedence fields, zone-index fields, prefix-len fields, and prefix fields in octets. label: An 8-bit unsigned integer; this value is used to make a combination of source address prefixes and destination address prefixes. precedence: An 8-bit unsigned integer; this value is used for sorting destination addresses. z bit If z bit is set to 1, 32 bit zone-index value is included right after the "prefix-len" field, and "Prefix" value continues after the "zone-index" field. If z bit is 0, "Prefix" value contitunes right after the "prefix-len" value. reserved 7-bit reservied field. Initialized to zero by sender, and ignored by receiver. zone-index: If z-bit is set to 1, this field is inserted between "prefix-len" field and "Prefix" field. Zone-index field is an 32-bit unsigned integer and used to specify zones for scoped addresses. This bit length is defined in RFC3493 [RFC3493] as 'scope ID'. prefix-len: An 8-bit unsigned integer; the number of leading bits in the prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0, 4, 8, 12, or 16 octets, depending on the length. Prefix: A variable-length field containing an IP address or the prefix of an IP address. IPv4-mapped address [mapped] must be used to represent an IPv4 address as a prefix value. 4. Appearance of this Option The Address Selection Policy option MUST NOT appear in any messages other than the following ones : Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. 5. Implementation Considerations Fujisaki, et al. Expires May 4, 2008 [Page 4] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 o The value 'label' is passed as an unsigned integer, but there is no special meaning for the value, that is whether it is a large or small number. It is used to select a preferred source address prefix corresponding to a destination address prefix by matching the same label value within this DHCP message. DHCPv6 clients need to convert this label to a representation specified by each implementation (e.g., string). o Currently, the value label, precedence are defined as 8-bit unsigned integers. In almost all cases, this value will be enough. o The 'precedence' is used to sort destination addresses. There might be some cases where precedence values will conflict when a client already has a selection policy configured or a client receives multiple policies from multiple DHCP servers (e.g., when a home gateway in a user network is connected to multiple upstream ISPs). In such cases, manual configuration of the policy will be necessary. o The maximum number of address selection rules in one DHCPv6 message depend on the prefix length of each rules and maximum DHCPv6 message size defined in RFC3315. It is possible to carry over 3,000 rules (e.g. default policy table defined in RFC3484 contains 5 rules) in one DHCPv6 message (maximum UDP message size). o Since the number of selection rules would be large, policy distributer should be care about the DHCPv6 message size. o If a ndoe has multiple interfaces, the node may have multiple address selection policies. Since RFC3484 policy table is one and global for a node, multiple polices should be merged in one. In a case that node's interfaces belong to different management domain (e.g. each interfaces are connected different site), it would have conflict policies. In that case, it would be possible to merge them by using other information such as routing information or preference for each interfaces, however, such automatic policy merge lead to potential security problems such as using unintended source addresses. 6. Discussion o The 'zone index' value is used to specify a particular zone for scoped addresses. This can be used effectively to control address selection in the site scope (e.g., to tell a node to use a Fujisaki, et al. Expires May 4, 2008 [Page 5] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 specified source address corresponding to a site-scoped multicast address). However, in some cases such as a link-local scope address, the value specifying one zone is only meaningful locally within that node. There might be some cases where the administrator knows which clients are on the network and wants specific interfaces to be used though. However, it is hard to use this value in general case. o There may be some demands to control the use of special address types such as the temporary addresses described in RFC3041 [RFC3041], address assigned by DHCPv6 and so on. (e.g., informing not to use a temporary address when it communicate within the an organization's network). It is possible to indicate the type of addresses using reserved field value. o We also proposed a policy distribution option using a Router Advertisement message defined in RFC2461 [RFC2461]. There was a discussion that using DHCPv6 was more suitable to distribute a selection policy, because such policy should be distributed under the site administrator's centralized control. 7. Security Considerations A rogue DHCPv6 server could issue bogus address selection policies to a client. This might lead to incorrect address selection by the client, and the affected packets might be blocked at an outgoing ISP because of ingress filtering. To guard against such attacks, both DCHP clients and servers SHOULD use DHCP authentication, as described in section 21 of RFC 3315, "Authentication of DHCP messages." 8. IANA Considerations IANA is requested to assign option codes to OPTION_DASP from the option-code space as defined in section "DHCPv6 Options" of RFC 3315. Appendix A. RFC3484 implementation status Today, many operating systems implement address selection mechanism defined in RFC3484. Many of them, however, implement the specification partially. We summarize current implementation status of RFC 3484 at http://www.nttv6.net/dass/. Fujisaki, et al. Expires May 4, 2008 [Page 6] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 Appendix B. Revision History 05: Extended bit length of the zone-index field to 32-bits (thank you Jinmei-sanfor your comment), and changed packet format to reflect the extension. Refrect Yoshifuji-san's comment to use this option information as an reference. Modified the text controling special address types. 04: Added description about policy merge. Modified the text controling special address types. 03: Discussion about DHCPv6 packetsize and number of rules added. Authors' e-mail addresses corrected. Some editorial changes. 9. References 9.1. Normative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. 9.2. Informative References [I-D.arifumi-v6ops-addr-select-sol] Matsumoto, A., "Solution approaches for address-selection problems", draft-arifumi-v6ops-addr-select-sol-00 (work in progress), June 2007. [I-D.ietf-v6ops-addr-select-ps] Matsumoto, A., "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", draft-ietf-v6ops-addr-select-ps-02 (work in progress), October 2007. Fujisaki, et al. Expires May 4, 2008 [Page 7] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 [I-D.ietf-v6ops-addr-select-req] Matsumoto, A., "Requirements for address selection mechanisms", draft-ietf-v6ops-addr-select-req-04 (work in progress), November 2007. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Authors' Addresses Tomohiro Fujisaki NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki.tomohiro@lab.ntt.co.jp Arifumi Matsumoto NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Jun-ya Kato NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 2939 Email: kato@syce.net Fujisaki, et al. Expires May 4, 2008 [Page 8] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 Shirou Niinobe NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 4949 Email: nin@syce.net Fujisaki, et al. Expires May 4, 2008 [Page 9] Internet-Draft DHCPv6 Address Selection Policy Opt Nov 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fujisaki, et al. Expires May 4, 2008 [Page 10]