DHC Working Group H. Matsuoka Internet-Draft T. Fujisaki Expires: August 4, 2005 A. Matsumoto J. Kato NTT January 31, 2005 Source Address Selection Policy option for DHCPv6 draft-hirotaka-dhc-source-address-selection-opt-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 4, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Source Address Selection Policy option of DHCPv6 provides a mechanism for notifying end nodes of information about source address selection policies using DHCPv6. This makes it possible for an end node to set up a connection without concern for transfer failures due Matsuoka, et al. Expires August 4, 2005 [Page 1] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 to ingress filtering by ISPs, for ISP operators to manage user behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. 1. Introduction An IPv6 multihoming site may have multiple nodes, each of which is assigned multiple IPv6 addresses by upstream ISPs. When there are multiple upstream ISPs, the current means of selecting the ISP for an outgoing packet is based on the destination address. Actually, in general, each packet should have a source address that has been allocated by the selected upstream ISP. This is because the routers of ISPs may be configured to perform ingress filtering with the aim of blocking packets with strange source addresses. In another Internet-Draft[A. Matsumoto] , we propose a technique that can be used both to distribute policy information for source address selection(SAS) at end nodes and to establish a method for packet- forwarding by routers. This enables ISPs to control incoming traffic from customer sites and the end nodes to select appropriate source addresses. It also enables the selection of outgoing ISPs in a way that is almost certain to produce successful connection setups. This document defines a new DHCPv6 option called the Source Address Selection Policy option. It enables DHCPv6 clients to obtain information about DHCPv6 source address selection policies. The policy information can be distributed by upstream ISPs or configured manually in DHCPv6 servers at the user site, and end nodes can accept these policies by using the Source Address Selection Policy option. 2. DHCPv6 specification dependency This document describes a new DHCPv6 option for IPv6 source address selection. It should be read in conjunction with the DHCPv6 specification, [RFC3315], for a complete specification of the Source Address Selection Policy options and mechanism. Terms and acronyms not specifically defined in this document are defined in RFC 3315. 3. Terminology This document uses the terminology defined in [RFC2460] and the DHCP specification. In addition, it uses the following terms. requesting client: A client that acts as a DHCP client and is requesting the Source Address Selection Policy option. delegating router: Matsuoka, et al. Expires August 4, 2005 [Page 2] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 A router that acts as a DHCP server and is responding to a Source Address Selection Policy request. 4. Source Address Selection Policy option The Source Address Selection Policy (SASP) option provides policy information for source address selection rules. Specifically, it transmits a set of IPv6 source and destination address prefixes that are used to control address selection as described in RFC 3484 [RFC3484]. With the SASP option, an ISP transmits information about its Source Address Selection Policy to the border router at a user site, and this router then transmits this information to end nodes. Each end node is expected to configure its policy table, as described in RFC 3484, in a manner consistent with the Source Address Selection Policy option information. To keep the Source Address Selection Policy information current, the requesting client MUST request the Source Address Selection Policy option immediately when a delegated address or address prefix information is changed, or when it has just received a reconfigure message about a delegated address or address prefix. The delegating router SHOULD be expected to create and transmit a reconfigure message about a delegated address or address prefix when it detects some change in the Source Address Selection Policy. The format of the Source Address Selection Policy option is given below: 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_SASP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | src-prefix-len| | +-+-+-+-+-+-+-+-+ | | Related IPv6 source address prefix | | (Variable Length) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | dst-prefix-len| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dst-prefix-len| . +-+-+-+-+-+-+-+-+ . Matsuoka, et al. Expires August 4, 2005 [Page 3] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 . . . dst-prefix-len and Prefix ... . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding and End Marker | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Fig. 1] Fields: option-code: OPTION_SASP (TBD) option-len: The total length of the src-prefix-len field, Related IPv6 source address prefix field, dst-prefix-len fields, prefix fields and Padding field in octets. src-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. Related IPv6 source address prefix: The IPv6 prefix for the source address. dst-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. The dest-prefix-len field contains the number of valid leading bits in the prefix. The bits in the prefix after the Prefix Length (if any) MUST be initialized to zero by the sender and ignored by the receiver. Pairs of Prefix Length and Prefix fields may follow here. Padding and End Marker: A variable-length field for 32-bit alignment. This field MUST be initialized to 1 by the sender and ignored by the receiver. 5. Appearance of this option The Source Address Selection Policy option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. Matsuoka, et al. Expires August 4, 2005 [Page 4] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 6. Example and applicability ISP-1: ISP-2: Allocated address: (A::/32) Allocated address: (B::/32) Reachable address: (A::/32) Reachable address: (B::/32,::/0) Address assigned Address assigned to user-C: (A::/48) to user-C: (B::/48) +-------+ +---+---+ +----------+ | ISP-1 | | ISP-2 +---+ Internet | +---+---+ +---+---+ +----+-----+ | user-C | | +---------+ | +-------+ Router +-------+ +----+----+ | +-----+------+ | | +---+---+ +---+---+ | Node | | Node | +-------+ +-------+ The above figure illustrates a usage example for this option. The router of user-C connects to two ISPs, ISP-1 and ISP-2, and provides IPv6 connectivity to end nodes. At this time, ISP-1 has no connectivity to the Internet. Each ISP provides IPv6 prefixes and source address selection policies by using stateful and stateless DHCPv6 functions, respectively. The user router also provides IPv6 addresses and source address selection policies by using DHCPv6 functions or router advertisement messages. The procedure may proceed as follows: o The user router requests the IA_PD and SASP options by transmitting an Information-Request message. o Each ISP replies with usable prefixes and reachable address prefixes by using the IA_PD and SASP options, respectively. In the above figure, ISP-1 notifies user-C of 'A::/48' as a useable prefix and 'A::/32' as a reachable address, while ISP-2 notifies user-C of 'B::/48' as a useable prefix and 'B::/32 and ::/0' as reachable address prefixes. o End nodes set up their IPv6 addresses by using a stateful DHCPv6 function or receiving router advertisement message. They also request the SASP option by transmitting Information-Request messages to the router. Matsuoka, et al. Expires August 4, 2005 [Page 5] o The router replies with appropriate addresses and reachable address prefixes by using stateful DHCPv6 functions and the SASP option, respectively. In the above figure, the router assigns two addresses, "A::../64" and "B::../64", and notifies end nodes of 'A::/32' as a reachable address prefix for the address prefix (A::/32) allocated by ISP-1, and of 'B::/32 and ::/0' as reachable address prefixes for the prefix (B::/32) allocated by ISP-2. o The end nodes configure their policy tables as described in RFC 3484 to match the label values of the reachable addresses and the corresponding source address.These tuples are stored in a policy table as follows. Prefix Precedence Label A::/32 undefined 10 A::/64 undefined 10 B::/32 undefined 20 B::/64 undefined 20 ::/0 undefined 20 o When a change in a source address selection policy occurs, the delegating router creates and transmits a reconfigure message about the delegated address or address prefix. o When the requesting client detects a change in a delegated address or address prefix, it requests the Source Address Selection Policy option again. 7. Security Considerations Security considerations in using DHCP are described in section 23 of RFC 3315, "Security Considerations." A rogue DHCPv6 server can issue bogus source address selection policies to a client. This may lead to incorrect address selection for the client, and the affected packets may be blocked at an outgoing ISP because of ingress filtering. A malicious DHCPv6 client may be able to mount a denial-of-service attack by sending repeated requests for the Source Address Selection Policy option, thus exhausting the DHCP server's resources. To guard against attacks, both DCHP clients and servers SHOULD use DHCP authentication, as described in section 21 of RFC 3315, "Authentication of DHCP messages." 8. References [A. Matsumoto] Matsuoka, et al. Expires August 4, 2005 [Page 6] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 Matsumoto, A., Fujisaki, T., Matsuoka, H. and J. Kato, "Source Address Selection Policy Distribution for Multihoming", Internet-draft draft-arifumi-ipv6-sas-policy-dist-00.txt. (Work In Progress), January 2005. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Authors' Addresses Hirotaka Matsuoka NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 4949 Email: matsuoka@nttv6.net Tomohiro Fujisaki NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki.tomohiroi@lab.ntt.co.jp Arifumi Matsumoto NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Matsuoka, et al. Expires August 4, 2005 [Page 7] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 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 Matsuoka, et al. Expires August 4, 2005 [Page 8] Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Matsuoka, et al. Expires August 4, 2005 [Page 9]