Hirotaka Matsuoka Internet-Draft Tomohiro Fujisaki October 18, 2004 Jun-ya Kato Arifumi Matsumoto NTT PF Lab. Source Address Selection Policy option for DHCPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Source Address Selection Policy option of DHCPv6 provides a mechanism for notifying end nodes of information about source address selection policies. This makes it possible for an end node to set up a connection without concern for transfer failures due 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. Hirotaka [Page 1] Internet-Draft October 2004 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. This document defines a new DHCPv6 option called the Source Address Selection Policy option. It enables DPCPv6 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 new DHCPv6 options for IPv6 source address selection. It should be read in conjunction with the DHCPv6 specification, RFC 3315 [2], 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 RFC 2460 [1] and the DHCP specification [2]. 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: 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. With the SASP option, an ISP transmits information about its Source Address Selection Policy to the border router at a user site, and Hirotaka [Page 2] Internet-Draft October 2004 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 | | (16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix-num | prefix-length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 destination prefix | | (16 octets) | | +-+-+-+-+-+-+-+-+ | | prefix-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 destination prefix | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dst-prefix-len| | +-+-+-+-+-+-+-+-+ . . ... +-+-+-+-+-+-+-+-+ . | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hirotaka [Page 3] Internet-Draft October 2004 Fields: option-code: OPTION_SASP (TBD) option-len: The total length of the IAID, the prefix-length, and the IPv6 destination prefix and SASP_options, in octets. src-prefix-len: The length of the related IPv6 source address prefix. related IPv6 source address prefix: The IPv6 prefix for the source address. prefix-num: The number of IPv6 destination prefixes, in octets. dst-prefix-len: The length of the IPv6 destination prefix. IPv6 destination prefix: The IPv6 prefix for the destination address. Padding: 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. Hirotaka [Page 4] Internet-Draft October 2004 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 stateless DHCPv6 functions. The user router also provides IPv6 addresses and source address selection policies by using stateful and stateless DHCPv6 functions, respectively. The procedure may proceed as follows: -The user router requests the IA_PD and SASP options by transmitting an Information-Request message. -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. -End nodes request IPv6 addresses from the router by using a stateful DHCPv6 function. They also request the SASP option by transmitting Information-Request messages to the router. -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 Hirotaka [Page 5] Internet-Draft October 2004 the prefix (B::/32) allocated by ISP-2. -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 -The router transmits packets by utilizing source-address-based routing. -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. -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. Normative References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Hirotaka [Page 6] Internet-Draft October 2004 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] O. Troan, and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC3633, December 2003. Authors' Addresses Hirotaka Matsuoka Nippon Telegraph and Telephone Corporation Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-4949 E-Mail: matsuoka.hirotaka@lab.ntt.co.jp Tomohiro Fujisaki Nippon Telegraph and Telephone Corporation Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-7351 E-Mail: fujisaki.tomohiro@lab.ntt.co.jp Jun-ya Kato Nippon Telegraph and Telephone Corporation Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-2939 E-Mail: kato.junya@lab.ntt.co.jp Arifumi Matsumoto Nippon Telegraph and Telephone Corporation Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3334 E-Mail: matsumoto.arifumi@lab.ntt.co.jp Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Hirotaka [Page 7] Internet-Draft October 2004 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. 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. Hirotaka [Page 8]