Network Working Group A. Matsumoto Internet-Draft T. Fujisaki Expires: June 4, 2006 J. Kato NTT Dec 1, 2005 Practical Usages of Default Address Selection Policy Distribution draft-arifumi-ipv6-policy-dist-00.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 June 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes some practical usages of default address selection policy distribution mechanism defined in another document. Default address selection policies are originated by ISPs or by network administrators and are delivered to each end node. These policies are stored at end nodes in the form of default address selection policy table. This mechanism is effective in many cases, such as IPv4 and IPv6 dual-stack environment and other multiple Matsumoto, et al. Expires June 4, 2006 [Page 1] Internet-Draft Policy Table Distribution Dec 2005 address environment. Every end node is guided by the policy in selecting an appropriate destination and source addresses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Practical Use Example . . . . . . . . . . . . . . . . . . . . 3 2.1. Case 1: IPv4 and IPv6 prioritization . . . . . . . . . . . 3 2.2. Case 2: ULA or Global Prioritization . . . . . . . . . . . 5 2.3. Case 3: Multicast Source Address Selection . . . . . . . . 6 2.4. Case 4: Global-Closed Mixed Connectivity . . . . . . . . . 6 2.5. Case 5: Renumbering Site Prefix . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Matsumoto, et al. Expires June 4, 2006 [Page 2] Internet-Draft Policy Table Distribution Dec 2005 1. Introduction This document describes some practical usages of the distribution mechanism for default address selection policy that is defined in another document. [T. Fujisaki] 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. Even in those cases, you can make a host to select a correct address by configuring address selection policy table correctly. There is, however, no mechanism to automatically configure policy table 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. So we propose a mechanism to distribute address selection policy. Our proposal is a new option for DHCPv6 [RFC3315] and its format is defined in another document. This document illustrates practical examples that benefit from our proposing protocol. 2. Practical Use Example 2.1. Case 1: IPv4 and IPv6 prioritization The default policy for policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seems to be a lot of cases, however, where network administrators want to control end nodes address selection policy otherwise. Matsumoto, et al. Expires June 4, 2006 [Page 3] Internet-Draft Policy Table Distribution Dec 2005 +---------+ | 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. 1] In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. Therefore, the administrator of this site knows communication quality of IPv6 is much worse than IPv4. This kind of problem can be solved by applying the following policy table to hosts. Prefix Precedence Label ::/0 20 1 ::ffff:0:0/96 10 2 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. Matsumoto, et al. Expires June 4, 2006 [Page 4] Internet-Draft Policy Table Distribution Dec 2005 2.2. Case 2: ULA or Global Prioritization By default, the scope of these addresses is global. Also, unlike site-locals, a site may have more than one of these prefixes and use them at the same time. By making use of this characteristics, you can achieve strong and simple access control. Like the figure below, a web server has both ULA [RFC4193] and Global IPv6 addresses. A host in this site also has both addresses. By configuring client address based access control at the web server, a client with ULA gets in internal only web pages and a client with Global address gets access to only public web pages. As it is relatively easy to reject packets with ULA source address getting into the site at border router, this kind of access control seems to be reliable. +------+ | Host | +-+--|-+ | | ===========|== | Internet | | ===========|== | | | | +----+-+ +-->+------+ | ISP +------+ Web | 2001:db8:a::80 +----+-+ +-->+------+ fc12:3456:789a::80 | | 2001:db8:a::/48 | | fc12:3456:789a::/48 | | +----+----|+ | Gateway || +---+-----|+ | | 2001:db8:a:100::/64 | | fc12:3456:789a:100:/64 --+-+---|----- | | +-+---|+ 2001:db8:a:100:EUI64 | Host | fc12:3456:789a:100:EUI64 +------+ [Fig. 2] If you want to make in-site hosts to get into internal web site, you should deliver the following policies to them from the gateway. Matsumoto, et al. Expires June 4, 2006 [Page 5] Internet-Draft Policy Table Distribution Dec 2005 Prefix Precedence Label fc00::/7 20 1 ::/0 10 2 2.3. Case 3: Multicast Source Address Selection This case is an example of Site-local or Global prioritization. When you send a multicast packet across site-borders, the source address of the multicast packet has to be a global scope address. The longest matching algorithm, however, selects a ULA address, if a sending host has both an ULA and a global address. The following policy fixes this incongruity. For site-scope multicast, the destination address is in ff05::/16, and the source address should be ULA. For global-scope multicast, the destination address is in ff0e::/16, and the source address will be global unicast address. Prefix Precedence Label ff05::/16 10 5 fc00::/7 10 5 ff0e::/16 10 6 2000::/3 10 6 This is surely a workaround. But, this clearly seems to be a defect of the rules of RFC 3484 and this is supposed to be fixed sooner. 2.4. Case 4: Global-Closed Mixed Connectivity You can see another typical source address selection problem in a site with global-closed mixed connectivity like the figure below. In this case, Host-A is in a multihomed network and has two IPv6 addresses delegated from each of up-stream ISPs. Note that ISP2 is closed network and doesn't have connectivity to the Internet. Matsumoto, et al. Expires June 4, 2006 [Page 6] Internet-Draft Policy Table Distribution Dec 2005 +--------+ | 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) +----+-+ +-+----+ DHCP-PD | | DHCP-PD 2001:db8:a::/48 | | 3ffe:1800:a::/48 ++-------++ | Gateway | +----+----+ | 2001:db8:a:1::/64 | 3ffe:1800:a:1::/64 DHCP | ------+---+---------- | +--+-----+ 2001:db8:a:1:EUI64 | Host-A | 3ffe:1800:a:1:EUI64 +--------+ [Fig. 3] Host-C is located somewhere in the Internet and has an IPv6 address 3ffe:503:c:1:EUI64. When Host-A sends a packet to Host-C, longest matching algorithm chooses 3ffe:1800:a:1:EUI64 for the source address. In this case, the packet goes through ISP1 and may be filtered by ISP1's ingress filter. Even if the packet isn't filtered by ISP1 fortunately, a return packet from Host-C won't possibly reach at Host-A, because the return packet is destined for 3ffe:1800:a:1: EUI64, which is closed from the Internet. In this case, the source address selection problem will be solved, if Host-A has the following policy table and the gateway has an appropriate routing table. Prefix Precedence Label 2001:db8::/32 10 100 ::/0 10 100 2001:db8:a:1::/64 10 100 3ffe:1800::/32 10 200 3ffe:1800:a:1::/64 10 200 Matsumoto, et al. Expires June 4, 2006 [Page 7] Internet-Draft Policy Table Distribution Dec 2005 2.5. Case 5: Renumbering Site Prefix RFC 4192 [RFC4192] describes a recommended procedure to renumber a network from one prefix to another. An auto-configured address has a lifetime, so by stopping advertisement old prefix is invalidated eventually. However, you can make this transition more rapid and smooth by injecting address selection policy like below. | +-----+---+ | 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. 4] Prefix Precedence Label 2001:db8:a:1::/64 20 1 ::/0 20 1 3ffe:1800:a:1::/64 10 2 In addition to whole site renumbering, partial site renumbering may be getting more common. For example, ISP's customer prefix renumbering may be helpful for privacy protection. This is common with IPv4, but you can provide smooth renumbering in IPv6. 3. Security Considerations With regard to the possibility of traffic abduction through the announcement of a bogus policy, this scheme seems to neither lower 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. Matsumoto, et al. Expires June 4, 2006 [Page 8] Internet-Draft Policy Table Distribution Dec 2005 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 [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. [T. Fujisaki] Fujisaki, T., Matsumoto, A., Kato, J., and S. Niinobe, "Practical Usages of Default Address Selection Policy Distribution", draft-fujisaki-dhc-addr-select-opt-01.txt. (Work In Progress) (work in progress), Dec 1 2005. 6.2. Informative References [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. Matsumoto, et al. Expires June 4, 2006 [Page 9] Internet-Draft Policy Table Distribution Dec 2005 Authors' Addresses Arifumi Matsumoto NTT PFLab Midori-Cho 3-9-11 Mitaka City, Tokyo Prefecture 180-8585 JP Phone: +81 422 59 3334 Email: arifumi@nttv6.net Tomohiro Fujisaki NTT PFLab Midori-Cho 3-9-11 Mitaka City, Tokyo Prefecture 180-8585 JP Phone: +81 422 59 7351 Email: fujisaki@syce.net Jun-ya Kato NTT PFLab Midori-Cho 3-9-11 Mitaka City, Tokyo Prefecture 180-8585 JP Phone: +81 422 59 2939 Email: kato@syce.net Matsumoto, et al. Expires June 4, 2006 [Page 10] Internet-Draft Policy Table Distribution Dec 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. Matsumoto, et al. Expires June 4, 2006 [Page 11]