Network Working Group A. Matsumoto Internet-Draft T. Fujisaki Expires: December 21, 2006 J. Kato S. Niinobe NTT June 19, 2006 Practical Usages of Address Selection Policy Distribution draft-arifumi-ipv6-policy-dist-01.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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes some practical usages of address selection policy distribution mechanism defined in another document. Address selection policies are originated by ISPs or by network administrators and are delivered to each end host. These policies are stored at end hosts in the form of default address selection policy table. This mechanism enables central control of address Matsumoto, et al. Expires December 21, 2006 [Page 1] Internet-Draft Policy Table Distribution Usage June 2006 selection policy at end hosts, so it is essential or helpful in many cases, such as IPv4 and IPv6 dual-stack environment and ULA and Global address parallel-use environment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Practical Use Example . . . . . . . . . . . . . . . . . . . . 3 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 3 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6 2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7 2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 7 2.1.6. Multicast Source Address Selection . . . . . . . . . . 8 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 8 2.2. Destination Address Selection . . . . . . . . . . . . . . 9 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 10 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Matsumoto, et al. Expires December 21, 2006 [Page 2] Internet-Draft Policy Table Distribution Usage June 2006 1. Introduction IPv6 is originally designed to be able to have multiple addresses on a network interface. RFC 3484 [RFC3484] defines some default rules by which destination address and a source addresses are selected among two or more addresses. Also, RFC 3484 address selection mechanism is implemented on major OSes. However, we've found that some important cases where those default rules aren't enough or even evil. We published a problem statement Internet Draft [I-D.arifumi-v6ops- addr-select-ps] that illustrates various kinds of address selection related problems. Almost all of these problems can be solved by a built-in feature called "policy table" that is already defined in RFC 3484 and implemented in a lot of operating systems. What is missing here is a method to centrally control end-hosts' address selection behavior from outside of the host like routing protocol for routing table. It is almost non-sense to force every user to configure policy table manually, to inform users of relatively large amount of policies and to make them change policy table configuration every time the backbone topology or address space changes. We've proposed a method [I-D.fujisaki-dhc-addr-select-opt] to distribute address selection policy to end-hosts, in the form of a new option for DHCPv6 [RFC3315]. Our method is so versatile that can be used in a lot of environments for a lot of purposes. This document describes some practical usages of our method. 2. Practical Use Example 2.1. Source Address Selection Matsumoto, et al. Expires December 21, 2006 [Page 3] Internet-Draft Policy Table Distribution Usage June 2006 2.1.1. Multiple Routers on Single Interface ================== | Internet | ================== | | 2001:db8::/32 | | 3ffe:1800::/32 +----+-+ +-+----+ | ISP1 | | ISP2 | +----+-+ +-+----+ | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 +------+---+ +----+-----+ | Gateway1 | | Gateway2 | +--------+-+ +-+--------+ | | 2001:db8:a:1::/64 | | 3ffe:1800:a:1::/64 | | -----+-+-----+------ | +-+----+ 2001:db8:a:1:EUI64 | Host | 3ffe:1800:a:1:EUI64 +------+ [Fig. 1] To avoid wrong address selection and connection failure, one approach is to configure correctly both the routing table and address policy table at Host. You can use RFC 4191 [RFC4191] to deliver routing information to hosts. When the Host selects Gateway1 for its default route and each ISP distributes its address block, Prefix Precedence Label 2001:db8::/32 20 1 ::/0 20 1 3ffe:1800:/32 10 2 Another approach is to configure the gateways but not the Host and make use of packet redirection based on the source address between the gateways. Matsumoto, et al. Expires December 21, 2006 [Page 4] Internet-Draft Policy Table Distribution Usage June 2006 2.1.2. Ingress Filtering Problem ================== | Internet | ================== | | 2001:db8::/32 | | 3ffe:1800::/32 +----+-+ +-+----+ | ISP1 | | ISP2 | +----+-+ +-+----+ | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 ++-------++ | Gateway | +----+----+ | 2001:db8:a:1::/64 | 3ffe:1800:a:1::/64 ------+---+---------- | +-+----+ 2001:db8:a:1:EUI64 | Host | 3ffe:1800:a:1:EUI64 +------+ [Fig. 2] In this example, as far as Gateway1 doesn't adopt source-address- based routing, the Host has to select an appropriate source address in accordance with Gateway's routing policy. The Gateway can notify its routing policy in the form of policy table like below. Here the Gateway selects ISP1 for its default route. Prefix Precedence Label 2001:db8::/32 20 1 ::/0 20 1 3ffe:1800:/32 10 2 Matsumoto, et al. Expires December 21, 2006 [Page 5] Internet-Draft Policy Table Distribution Usage June 2006 2.1.3. Half-Closed Network Problem +--------+ | Host-C | 3ffe:503:c:1:EUI64 +-----+--+ | ============== +--------+ | Internet | | Host-B | 3ffe:1800::EUI64 ============== +--------+ | | 2001:db8::/32 | | 3ffe:1800::/32 +----+-+ +-+---++ | ISP1 | | ISP2 | (Closed Network/VPN tunnel) +----+-+ +-+----+ | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 ++-------++ | Gateway | +----+----+ | 2001:db8:a:1::/64 | 3ffe:1800:a:1::/64 ------+---+---------- | +--+-----+ 2001:db8:a:1:EUI64 | Host-A | 3ffe:1800:a:1:EUI64 +--------+ [Fig. 3] To avoid wrong address selection to Host-C, Gateway have to distribute the following policy to Host-A. In this case The longest matching algorithm always chooses the wrong address. Prefix Precedence Label 2001:db8::/32 10 1 ::/0 10 1 3ffe:1800::/32 10 2 Only the ISP1 and ISP2 know what policy Host-A should have, so we propose that ISPs should deliver their policy information to their customers in the form of DHCPv6 option that we stated above. Matsumoto, et al. Expires December 21, 2006 [Page 6] Internet-Draft Policy Table Distribution Usage June 2006 2.1.4. Combined Use of Global and ULA +--------+ | Host-C | 8000:db8::1 +-----+--+ | ============ | Internet | ============ | | +----+----+ | ISP | +----+----+ | 2001:db8:a::/48 | +----+----+ | Gateway | +-+-----+-+ | | 2001:db8:a:100::/64 fd01:2:3:200:/64 | | fd01:2:3:100:/64 -----+--+- -+--+---- | | fd01:2:3:200:EUI64 | | 2001:db8:a:100:EUI64 +----+----+ +-+------+ fd01:2:3:100:EUI64 | Printer | | Host-A | +---------+ +--------+ [Fig. 4] In a few years the longest matching rule will not be able to choose the correct address anymore: the moment the assignment of those Global Unicast Addresses whose beginning bit is 1 starts. So, to avoid connection failure between Host-A and Host-C in this figure the site administrator should distribute the following policy. Prefix Precedence Label fd01:2:3::/48 20 1 2001:db8:a::/48 10 2 ::/0 10 2 2.1.5. Site Renumbering It takes a long time to invalidate the old prefix. Also you cannot stop routing to the old prefix because there could be a long-lived TCP or UDP session that uses the old prefix. Matsumoto, et al. Expires December 21, 2006 [Page 7] Internet-Draft Policy Table Distribution Usage June 2006 +-----+---+ | Gateway | +----+----+ | 2001:db8:a:1::/64 (new) | 3ffe:1800:a:1::/64 (old) ------+---+---------- | +--+-----+ 2001:db8:a:1:EUI64 (new) | Host-A | 3ffe:1800:a:1:EUI64 (old) +--------+ [Fig. 5] Prefix Precedence Label 2001:db8:a:1::/64 20 1 ::/0 20 1 3ffe:1800:a:1::/64 10 2 2.1.6. Multicast Source Address Selection The longest matching algorithm selects a ULA [RFC4193] address if the sending host has both a ULA and a global address. This behavior is not always desirable. It depends on the usage and the routing policy of ULA. If the source address of the multicast packets should not be ULA, you have to configure policy table accordingly. The policy below selects ULA for site-local multicast address and global unicast address for global-scope multicast address. Prefix Precedence Label ff05::/16 10 1 fc00::/7 10 1 ff0e::/16 10 2 2000::/3 10 2 2.1.7. Temporary Address Selection For now you do not have a method to control usage policy of temporary address other than specifying a temporary address at 128bit prefix length and keeping the entry up-to-date according to the change of the temporary address. There are a lot of cases that we want to control the usage of temporary address more minutely, so it is desirable to make policy table support temporary address description. Matsumoto, et al. Expires December 21, 2006 [Page 8] Internet-Draft Policy Table Distribution Usage June 2006 2.2. Destination Address Selection 2.2.1. IPv4 or IPv6 prioritization The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. +---------+ | Tunnel | | Service | +--+---++-+ | || | || ===========||== | Internet || | ===========||== | || 10.2.0.0/16 | || +----+-+ || | ISP | || +----+-+ || | || IPv4 (Native) | || IPv6 (Tunnel) 10.2.30.0/32 | || ++-----++-+ | Gateway | +----+----+ | 2001:db8:a:1::/64 | 192.168.0.0/24 | ------+---+---------- | +-+----+ 2001:db8:a:1:EUI64 | Host | 192.168.0.100 +------+ [Fig. 6] In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. Therefore, the administrator may want to set a higher priority for using IPv4 than using IPv6 because the quality of the tunnel network seems to be worse than that of the native transport. Prefix Precedence Label ::/0 20 1 ::ffff:0:0/96 10 2 Matsumoto, et al. Expires December 21, 2006 [Page 9] Internet-Draft Policy Table Distribution Usage June 2006 The administrator can indicate that IPv4 should take precedence over IPv6, while keeping to provide both IPv4 and IPv6 connectivity, by delivering DHCPv6 Default Address Selection Option that includes the policy above. 2.2.2. ULA and IPv4 dual-stack environment When the Host below tries to connect to Host-C that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and ULA for the source address. This will clearly result in a connection failure. +--------+ | Host-C | AAAA = 2001:db8::80 +-----+--+ A = 192.47.163.1 | ============ | Internet | ============ | no IPv6 connectivity +----+-+ | ISP | +----+-+ | | fd01:2:3::/48 (ULA) | 10.2.0.0/16 IPv4 NAT ++--------+ | Gateway | +----+----+ | fd01:2:3:4::/64 (ULA) | 192.168.0.0/24 ------+---+---------- | +-+----+ fd01:2:3:4::100 (ULA) | Host | 192.168.0.100 +------+ [Fig. 7] The policy below enables IPv6 communication within the ISP. Outside of the ISP IPv4 communication has highor priority than IPv6. Prefix Precedence Label fd01:2:3::/48 30 3 ::ffff:0:0/96 20 2 ::/0 10 1 Matsumoto, et al. Expires December 21, 2006 [Page 10] Internet-Draft Policy Table Distribution Usage June 2006 2.2.3. ULA or Global Prioritization ULA and IPv6 global address both have global scope, and default rules do not specify which address should be given priority. This point makes IPv6 implementation of address-based service differentiation a bit harder. +------+ | Host | +-+--|-+ | | ===========|== | Internet | | ===========|== | | | | +----+-+ +-->+------+ | ISP +------+ DNS | 2001:db8:a::80 +----+-+ +-->+------+ fd01:2:3::80 | | 2001:db8:a::/48 | | fd01:2:3:::/48 | | +----+----|+ | Gateway || +---+-----|+ | | 2001:db8:a:100::/64 | | fd01:2:3:100:/64 --+-+---|----- | | +-+---|+ 2001:db8:a:100:EUI64 | Host | fd01:2:3:100:EUI64 +------+ [Fig. 7] If you want to make in-site hosts to get information of DNS internal zone, you should deliver the following policies to them from the gateway. Prefix Precedence Label fd01:2:3::/48 20 1 ::/0 10 2 3. Security Considerations With regard to the possibility of traffic abduction through the announcement of a bogus policy, this scheme seems to neither lower Matsumoto, et al. Expires December 21, 2006 [Page 11] Internet-Draft Policy Table Distribution Usage June 2006 nor raise the security level obtained by the existing base-protocols, such as DHCP-PD, DHCP and RA. However, it does raise the possibility of a new form of DoS attack on routers and hosts, in which large numbers of address-selection policies are generated by different source addresses. We will have to discuss this and take precautionary measures in designing the protocol specification. 4. IANA Considerations This document has no actions for IANA. 5. Acknowledgement Many thanks to Tim Chown, Iljitsch, Changming and Shin Miyagawa for detailed feedbacks and discussions on this document. We really appreciate all the members in our laboratory for their contributions. 6. References 6.1. Normative References [I-D.arifumi-v6ops-addr-select-ps] Matsumoto, A., "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", draft-arifumi-v6ops-addr-select-ps-00 (work in progress), June 2006. [I-D.fujisaki-dhc-addr-select-opt] Fujisaki, T., "Distributing Default Address Selection Policy using DHCPv6", draft-fujisaki-dhc-addr-select-opt-02 (work in progress), June 2006. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. 6.2. Informative 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. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Matsumoto, et al. Expires December 21, 2006 [Page 12] Internet-Draft Policy Table Distribution Usage June 2006 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. Appendix A. Revision History 00-version (2005.12.1): Initial version. 01-version (2006.6.19): Some cases were added in accordance with the problem statement I-D. Matsumoto, et al. Expires December 21, 2006 [Page 13] Internet-Draft Policy Table Distribution Usage June 2006 Authors' Addresses Arifumi Matsumoto NTT PFLab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Tomohiro Fujisaki NTT PFLab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki@lab.ntt.co.jp Jun-ya Kato NTT PFLab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 2939 Email: kato@syce.net Shirou Niinobe NTT PFLab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 4949 Email: nin@syce.net Matsumoto, et al. Expires December 21, 2006 [Page 14] Internet-Draft Policy Table Distribution Usage June 2006 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 (2006). 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. Matsumoto, et al. Expires December 21, 2006 [Page 15]