--- 1/draft-ietf-v6ops-addr-select-ps-06.txt 2008-06-12 12:12:58.000000000 +0200 +++ 2/draft-ietf-v6ops-addr-select-ps-07.txt 2008-06-12 12:12:58.000000000 +0200 @@ -1,22 +1,23 @@ IPv6 Operations Working Group A. Matsumoto Internet-Draft T. Fujisaki Intended status: Informational NTT -Expires: November 15, 2008 R. Hiromi - K. Kanayama +Expires: December 14, 2008 R. Hiromi Intec Netcore - May 14, 2008 + K. Kanayama + INTEC Systems + June 12, 2008 Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules - draft-ietf-v6ops-addr-select-ps-06.txt + draft-ietf-v6ops-addr-select-ps-07.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 @@ -27,38 +28,38 @@ 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 November 15, 2008. + This Internet-Draft will expire on December 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OS's. But, it has been too difficult to use operationally - for several reasons, In some environment where multiple prefixes are - assigned on a single physical link, the host with the default address - selection rules will experience some trouble in communication. This - document describes the possible problems that end hosts could - encounter in an environment with multiple prefixes. + for several reasons. In some environment where multiple prefixes are + assigned on a single physical link, the host using the default + address selection rules will experience some trouble in + communication. This document describes the possible problems that + end hosts could encounter in an environment with multiple prefixes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 4 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6 @@ -95,34 +96,34 @@ unexpected asymmetric routing, filtering by a router or discarding of packets bacause there is no route to the host. Considering a multi-prefix environment, destination address selection is also important for correct or better communication establishment. RFC 3484 [RFC3484] defines default source and destination address selection algorithms and is implemented in a variety of OS's. But, it has been too difficult to use operationally for several reasons, such as lack of autoconfiguration method. There are some problematic - cases where the host with the default address selection rules + cases where the hosts using the default address selection rules encounter communication troubles. This document describes such possibilities of incorrect address selection which leads to dropping packets and communication failure. 1.1. Scope of this document - As other mechanisms already exists, the multi-homing techniques for + As other mechanisms already exist, the multi-homing techniques for achieving redundancy are basically out of our scope. We focus on an end-site network environment and unmanaged hosts in such an environment. This is because address selection behavior at - this kind of hosts are difficult to manipulate owing to the users's + this kind of hosts is difficult to manipulate owing to the users's lack of knowledge, hosts' location, or massiveness of the hosts. The scope of this document is to sort out problematic cases related to address selection. It includes problems that can be solved in the framework of RFC 3484 and problems that cannot. For the latter, RFC 3484 might be modified to meet their needs, or another address selection solution might be necessary. For the former, an additional mechanism that mitigates the operational difficulty might be necessary. @@ -206,23 +207,23 @@ +------+ [Fig. 2] When a relatively small site, which we call a "customer network", is attached to two upstream ISPs, each ISP delegates a network address block, which is usually /48, and a host has multiple IPv6 addresses. When the source address of an outgoing packet is not the one that is delegated by an upstream ISP, there is a possibility that the packet - will be dropped at the ISP by its Ingress Filter. Ingress - filtering(uRPF: unicast Reverse Path Forwarding) is becoming more - popular among ISPs to mitigate the damage of DoS attacks. + will be dropped at the ISP by its Ingress Filter. Ingress filtering + is becoming more popular among ISPs to mitigate the damage of DoS + attacks. In this example, when the Router chooses the default route to ISP2 and the Host chooses 2001:db8:1000:1::100 as the source address for packets sent to a host (2001:db8:2000::1) somewhere on the Internet, the packets may be dropped at ISP2 because of Ingress Filtering. Solution analysis: One possible solution for this case is adopting source address based routing at Router. Another solution may be using static @@ -403,30 +404,30 @@ web pages or communicating with the general public, but that is bad for a service that uses address-based authentication and for logging purposes. If you could turn the temporary address on and off, that would be better. If you could switch its usage per service (destination address), that would also be better. The same situation can be found when using HA (home address) and CoA (care-of address)in a Mobile IPv6 [RFC3775] network. - At the Future Work section in RFC 3041, it discusses that the API - extension might be necessary to achieve better address selection - mechanism with finer granularity. + The Future Work section in RFC 3041 discusses that an API extension + might be necessary to achieve a better address selection mechanism + with finer granularity. Solution analysis: This problem can not be solved in the RFC 3484 framework. A possible solution is to make applications to select desirable - addresses by using IPv6 Socket API for Source Address Selection - defind in RFC 5014 [RFC5014]. + addresses by using the IPv6 Socket API for Source Address + Selection defind in RFC 5014 [RFC5014]. 2.2. Destination Address Selection 2.2.1. IPv4 or IPv6 prioritization The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seem to be many cases, however, where network administrators want to control the address selection policy of end- hosts the other way around. @@ -579,31 +580,31 @@ 4. Security Considerations When an intermediate router performs policy routing (e.g. source address based routing), inappropriate address selection causes unexpected routing. For example, in the network described in 2.1.3, when Host-A uses a default address selection policy and chooses an inappropriate address, a packet sent to VPN can be delivered to a location via the Internet. This issue can lead to packet eavesdropping or session hijack. However, sending the packet back to the correct path from the attacker to the node is not easy, so these - two risk are not serious. + two risks are not serious. As documented in the security consideration section in RFC 3484, address selection algorithms expose a potential privacy concern. When a malicious host can make a target host perform address selection, for example by sending a anycast or a multicast packet, - the malicious host can know multiple addresses attached to the target - host. In a case like 2.1.4, if an attacker can make Host to send a - multicast packet and Host performs the default address selection - algorithm, the attacker may be able to determine the ULAs attached to - the Host. + the malicious host can get knowledge multiple addresses attached to + the target host. In a case like 2.1.4, if an attacker can make Host + to send a multicast packet and Host performs the default address + selection algorithm, the attacker may be able to determine the ULAs + attached to the Host. These security risks have roots in inappropriate address selection. Therefore, if a countermeasure is taken, and hosts always select an appropriate address that is suitable to a site's network structure and routing, these risks can be avoided. 5. IANA Considerations This document has no actions for IANA. @@ -641,33 +642,35 @@ [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. 6.2. Informative References Appendix A. Appendix. Revision History 01: - IP addresse notations changed to docmentation address. - Descriptoin of solutions deleted. + IP addresse notations changed to documentation address. + Description of solutions deleted. 02: Security considerations section rewritten according to comments from SECDIR. 03: Intended status changed to Informational. 04: This version reflects comments from IESG members. 05: This version reflects comments from IESG members and Bob Hinden. 06: This version reflects comments from Thomas Narten. + 07: + This version reflects comments from Alfred Hoenes. Authors' Addresses Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 @@ -684,26 +687,26 @@ Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan Phone: +81 3 5665 5069 Email: hiromi@inetcore.com Ken-ichi Kanayama - Intec Netcore, Inc. - Shinsuna 1-3-3 - Koto-ku, Tokyo 136-0075 + INTEC Systems Institute, Inc. + Shimoshin-machi 5-33 + Toyama-shi, Toyama 930-0804 Japan - Phone: +81 3 5665 5069 + Phone: +81 76 444 8088 Email: kanayama_kenichi@intec-si.co.jp Full Copyright Statement Copyright (C) The IETF Trust (2008). 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.