Arifumi Matsumoto Internet-Draft Tomohiro Fujisaki Expires: April 18, 2005 Hirotaka Matsuoka Jun-ya Kato NTT PF Lab. October 18, 2004 Configuring Source Address Selection Policy by Neighbor Discovery Protocol for IPv6 draft-arifumi-ipv6-nd-source-address-select-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we 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 made obsolete 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 This document describes a Neighbor Discovery IPv6 Source Address Selection(SAS) Policy option for distributing of source address selection policies to end nodes. This option is particularly effective when a consumer site has multiple address blocks. Every end node is guided by such a policy in selecting an appropriate source address for each destination address. This makes it possible Arifumi Expires April 18, 2005 [Page 1] Internet-Draft October 2004 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. 1. Introduction An IPv6 multihoming site has multiple nodes, each of which is assigned multiple IPv6 addresses by up stream ISPs. When there are multiple up stream 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 up stream ISP. This is because the routers of ISPs may be configured to perform ingress filtering with the aim of blocking packets with illegal source addresses. In another Internet-Draft [1], 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. In this document, we propose an extension to the Neighbor Discovery Router Advertisement Message [2]. In another draft, we propose a new option [5] for DHCPv6 [3,4] to handle delivery of address selection policies end nodes. An address selection policy delivered to an end node is stored in the form of a policy table, as defined in RFC 3484 [6]. These two drafts are protocol specifications implementing the multihome network technique proposed previously [1]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [7]. 3. Message formats 3.1. Changes to Prefix Information option of Router Advertisement Message The change from Neighbor Discovery [2] section 4.6 is as follows: Arifumi Expires April 18, 2005 [Page 2] Internet-Draft October 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A| SASID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: SASID A 6-bit unsigned integer; the identifier of the Source Address Selection (SAS) Policy option related to this Prefix Information option. Each Prefix Information option can be linked with one SAS Policy option, as mentioned in the next paragraph. If this Prefix Information option isn't bound with any SAS Policy option, the value of this field must be zero. Otherwise, it will be the identifier of the corresponding SAS option. Arifumi Expires April 18, 2005 [Page 3] Internet-Draft October 2004 3.2 Source Address Selection (SAS) Policy option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | SASID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ Prefix (Variable Length) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Prefix ... . . +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBD Length An 8-bit unsigned integer; the length of the option (including the Type and Length fields) in units of 4 octets. Reserved A 10-bit unused field. This field MUST be initialized to zero by the sender and ignored by the receiver. SASID A 6-bit unsigned integer; the identifier of the SAS Policy option. A Router Advertisement Message cannot contain multiple SAS Policy options with the same SASID. With this identifier, the SAS Policy options are linked with the Prefix Information option. An SAS Policy option with no linked Prefix Information option will be discarded. Prefix Length 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 Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the Prefix Length (if any) are reserved and Arifumi Expires April 18, 2005 [Page 4] Internet-Draft October 2004 MUST be initialized to zero by the sender and ignored by the receiver. Padding A variable-length field for 32-bit alignment. This field MUST be initialized to 1 by the sender and ignored by the receiver. This option appears only in Router Advertisement Message and has to have corresponding Prefix Information option within the same Router Advertisement Message. Otherwise, this option MUST be ignored. 3.3 Discussion The SASID, mentioned above, is used to link the Prefix Information and a SAS Policy option. This field occupies as much space as 6-bit reserved field in the Prefix Information option. Instead of the SASID, an alternative method of linking is to copy the prefix of the corresponding Prefix Information option into the SAS Policy option, as shown in the figure below. This method, however, is expected to consume more option space. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ Prefix (Variable Length) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Prefix ... . . +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arifumi Expires April 18, 2005 [Page 5] Internet-Draft October 2004 4. Specifications 4.1 Router Specification - The SAS Policy option MUST NOT appear in anything other than a Neighbor Discovery Router Advertisement Message. - Multiple Prefix Information options can share the same SASID. - When a router has too much information to make into one packet (1280 bytes), the incident SHOULD be reported or logged. 4.2 Host Specification - An SAS Policy option in anything other than a Neighbor Distribution Router Advertisement Message MUST be ignored. - Each SAS Policy option is linked with one or more Prefix Information options. This tuple will be kept in a policy table, as defined in RFC 3484, Section 2.1 [6]. Assume that a host receives the following tuples: Prefix SAS 2001:1:1:1::/64 - SAS1 (2001:1::/16, 2001:2::/16) 2001:2:2:2::/64 - SAS1 (2001:1::/16, 2001:2::/16) 2002:3:3:3::/64 - SAS2 (::/0) Table 1 Then, these tuples are stored in a policy table like that shown below. Prefix Precedence Label 2001:1:1:1::/64 undefined 10 2001:2:2:2::/64 undefined 10 2001:1::/16 undefined 10 2001:2::/16 undefined 10 2002:3:3:3::/64 undefined 20 ::/0 undefined 20 Table 2 The first two tuples in Table 1 are linked with the same SAS Policy option (SAS1), so they are also linked with each other, and thus, they have the same Label value in Table 2. Arifumi Expires April 18, 2005 [Page 6] Internet-Draft October 2004 - When two Prefixes contained in different SAS Policy options are the same, the Prefixes will be ignored. - Each SAS Policy option has a lifetime, which is the valid lifetime of the corresponding Prefix Information option. When an SAS Policy option is related to multiple Prefix Information options, its lifetime will be the maximum lifetime among those of all the Prefix Information options. 5. Security Considerations With regard to the possibility of traffic abduction by announcing a bogus policy, this scheme seems to neither lower nor raise the security level obtained with the existing base protocol, namely, Neighbor Discovery Router Advertisement. It does, however, 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. 6. Normative References [1] Matsumoto, A., Fujisaki, T., Matsuoka. H and J. Kato, "Source Address Selection Policy Distribution for Multihoming", Internet-Draft, October 2004, draft-arifumi-multi6-sas-policy- dist-00.txt. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 3315, July 2003. [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" RFC 3633, December 2003. [5] Matsuoka, H., Fujisaki, T., Kato, J. and A. Matsumoto, "Source Address Selection Option DHCPv6," Internet-Draft, October 2004, draft-hirotaka-dhcp6-sas-option-00.txt. [6] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)," RFC 3484, February 2003. [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Arifumi Expires April 18, 2005 [Page 7] Internet-Draft October 2004 Authors' Addresses 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 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 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 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 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. 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. Arifumi Expires April 18, 2005 [Page 8] Internet-Draft October 2004 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. Arifumi Expires April 18, 2005 [Page 9] Internet Engineering Task Force Arifumi Matsumoto Internet-Draft Tomohiro Fujisaki Expires: April 12, 2005 Hirotaka Matsuoka Jun-ya Kato NTT PF Lab. October 12, 2004 Source Address Selection Policy Distribution for Multihoming draft-arifumi-multi6-sas-policy-dist-00.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, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we 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 made obsolete 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 This document describes a method for the distribution of source address selection policy from ISPs to gateway routers for consumers and from the gateways to end nodes. This method is particularly effective when a consumer site has multiple address blocks. Every end node is guided by the policy in selecting an appropriate source address for each destination address and every gateway is guided by Arifumi [Page 1] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 the policy in forwarding packets to appropriate next-hop ISPs. This makes it possible for an end node to set a connection up without being concerned about failures of transfer due to ingress filtering by the ISPs, for ISP operators to manage consumers' 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 has multiple nodes, each of which is assigned multiple IPv6 addresses by up-stream ISPs. When there are multiple up-stream ISPs, the means of selection of the ISP for an outgoing packet is currently based on the destination address. In general, however, each packet should have a source address that has been allocated by the selected up-stream ISP. This is because the routers of ISPs may be configured to perform ingress filtering with the aim of blocking packets that have strange source addresses. In this document, we propose a technique that is used both to distribute policy information for source address selection at end nodes and to establish a method for the forwarding of packets by routers. This enables the control of incoming traffic from customer sites by ISPs, the selection of appropriate source addresses by end nodes, and the selection of outgoing ISPs in a way that is almost certain to produce successful connection setup. 2. Concepts In this document, we propose a method by which an ISP can distribute source address selection policies to each end node at a customer site. The policy information is particularly helpful to hosts in which multihoming is used, since an end node can use the destination address to select a source address that leads to a high probability of successful setup for the connection. An up-stream ISP is expected to use DHCPv6 Prefix Options [3633] to delegate a certain portion of the IPv6 address space to its subscribers. We propose a DHCPv6 new option, which contains a per- delegating-prefix address-selection policy. By making use of this option, an ISP can inform its customers of an address block that can be reached through the ISP and of a corresponding source address of packets, that is, a source address that must be used to reach the given block. This is simply achieved through delegation of the delegated source-address prefix and policy by the ISP. The gateway router of a customer's site receives the delegated prefix and address-selection policy mentioned above from its up-stream ISPs. Arifumi [Page 2] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 The router in turn distributes this information to end nodes at the site. Here, we propose an extension to the ND6 Router Advertisement Message [2461] and a DHCPv6 [3315] new option to cover delivery of address-selection policy to the end nodes. The address-selection policy delivered to an end node is stored in the form of a Policy Table as defined in RFC 3484 [3484]. Once the above series of processes is complete, an end node can select an appropriate source address for a given destination address. Routing of an outgoing packet to the corresponding up-stream ISP is mainly guided by the source address of the packet; this avoids blocking of the packet by ingress filtering. This mechanism is particularly effective when a site subscribes to an ISP or VPN service that provides connectivity to a certain closed network as well as acting as an ISP for global network connectivity. This is because selecting an appropriate source address for a given destination address is crucial in such a network environment. This approach gives end nodes an advance measure against connection setup failure. At the same time, an ISP can control incoming traffic from customers' sites, and the network managers of customers' sites can reflect their networking policy to some extent by configuring DHCPv6 or ND6 RA settings on routers. The last but not the least significant feature to note here is that this sequence of passing, processing, generation, and reflection of policy information can be made almost totally automatic from the viewpoint of customers. In the context of Multi6 WG activity, IMHO this kind of information will be very useful in terms of efficiently and effectively setting up connections no matter what modifications have been applied to the protocol stacks of end nodes. Also, this will be very helpful for those end nodes that haven't received the protocol-stack modifications required for this technique, in other words, to legacy nodes. This document also serves as a proposal for the Multi6 WG to consider a mechanism of the kind described as one element of the component class. Arifumi [Page 3] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 3. Overview 3.1 Multihome Site with Global-Closed Mixed Connectivity ============== | Internet | ============== | 2001:db8::/32 | 3ffe:1800::/32 +----+-+ +-+----+ | ISP1 | | ISP2 | (Closed Network) +----+-+ +-+----+ | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 (DHCP-PD') ++-------++ (DHCP-PD') | Gateway | +----+----+ | 2001:db8:a:1::/64 | 3ffe:1800:a:1::/64 | (RA'/DHCP') ------+---+---------- | +-+----+ 2001:db8:a:1:[EUI64] | Host | 3ffe:1800:a:1:[EUI64] +------+ [Fig. 1] Fig. 1 shows a multihome site that subscribes to two ISPs. One ISP provides global network connectivity and the other provides connectivity to a closed network but not to the Internet. This site has one border router, labeled Gateway here, and the router may be connected to up-stream ISPs through a physical or logical link, say PPPoE or an IPsec Tunnel. 3.1.1 Description of Each Element i) ISP -> Gateway This figure shows that ISP1 has been allocated 2001:db8::/32 and ISP2 has been allocated 3ffe:1800::/32. Each ISP delegates part of its address block, called the "provider aggregatable (PA)" block, to this customer site. Here, ISP1 and ISP2 use DHCP-PD to delegate 2001:db8:a::/48 and 3ffe:1800:a::/48, respectively. In this document, we propose an extension to DHCP-PD, which is actually a new DHCP option and called DHCP-PD' here. DHCP-PD' gives DHCP servers (ISPs) functionality for delivering an address- Arifumi [Page 4] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 selection policy in combination with a delegated prefix to a client (gateway). In this example, ISP2 includes Address Addr. Sel. Policy 3ffe:1800:a::/48 ---- 3ffe:1800::/32 in the PD and address-selection policy options sent to the client. This means that the subscribers of ISP2 should use an address from the delegated range, that is, 3ffe:1800:a::/48, when communicating with 3ffe:1800::/32. Selection of an appropriate source address is very important, and this is particularly so when one of the subscribing networks is closed as in this example. This is simply because a return packet from the closed network can't possibly reach the session- originating host if the return packet is destined for an address beyond the range available to the closed ISP. ISP1 also uses DHCP-PD', in this case to deliver its address- selection policy to its customers. As ISP1 provides global network connectivity, the PD and policy options will take the following form. Address Addr-Sel. Policy 2001:db8:a::/48 --+-- 2001:db8::/32 +-- ::/0 (all address) This means that ISP1 can provide connectivity to 2001:db8::/32 and act as a transit point for any other address (::/0) in the Internet as long as the source address is that delegated by ISP1, namely 2001:db8:a::/48. With regard to backward compatibility, a normal DHCP-PD packet, which does not carry address-selection policy information of the above type, should be deemed to have ::/0 as its policy field. ii) Gateway -> Host A gateway router receives address-delegation information and address-selection policy from up-stream ISPs, in turn delivering both to down-stream nodes. In this document, we propose DHCP new option and an extension to RA (Router Advertisement Message). We refer to these as DHCP' and RA', respectively. The gateway router combines information given by multiple up-stream ISPs and distributes the following information down-stream through DHCP' or RA'. Arifumi [Page 5] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 Address Addr. Sel. Policy 1 2001:db8:a:1::/64 --+-- 2001:db8::/32 +-- ::/0 2 3ffe:1800:a:1::/64 ----- 3ffe:1800::/32 This is just the combination of the information from the two up- stream elements in the previous section, except that each advertising address prefix is 64 bits long. iii) Host When a host receives an RA' or DHCP' message from the site gateway, it configures addresses for each receiving network interface and reflects address-selection policy in its RFC3484-based policy table. In this example, we propose that the policy table should be configured as follows, by making use of the Label field defined in RFC3484, and the relation between address prefix and address- selection policy should be kept in this table. Prefix Pref. 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 When this host sends a packet to, for example, 3ffe:1800:a::100, whose longest matching entry in this table is 3ffe:1800::/32, the host chooses the address beginning with 3ffe:1800:a:1:: as the source address. The source-address selection algorithm will select the longest entry that is a candidate source-address range and has the same label as the longest matching address for the destination address. In the same way, the source address of a packet destined for 2001:db8::/32 or 2002::/16 will be 2001:db8:a:1:[EUI64]. Preference values are only used in the selection of destination addresses. This document does not include an algorithm for determining preference values. iv) Gateway As well as delivering addresses and policy information to hosts through RA' or DHCP', the gateway forwards packets according to policy information distributed by up-stream ISPs. One way of implementing such forwarding or routing, called policy routing, is based on the source addresses of out-going packets. Policy routing Arifumi [Page 6] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 is illustrated in the table below. Src. Next Hop 2001:db8:a:1::/64 ISP1 3ffe:1800:a:1::/64 ISP2 In this example, the next-hop is deterministically selected by the destination address. So, normal destination-address-based routing with the following routing table is sufficient. Dst. Next Hop 2001:db8::/32 ISP1 ::/0 ISP1 3ffe:1800::/32 ISP2 3.1.2 Discussion The benefits of this scheme are very clear. Every end node can determine which source address should be used and can send packets without a risk of failure due to ingress filtering or the limited reachability of a closed network. What should be discussed from here is the need for and implementation of policy enforcement to end nodes and the process of combining multiple address-selection policies. It's so hard to combine two policies automatically when a policy coming from an ISP conflicts with another ISP's policy. We may also have to think about combining or pruning algorithm to contain too much policy information in one packet. Arifumi [Page 7] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 3.2 Host with Multiple Home Addresses and Connectivity to Two Global Networks ================== | Internet | ================== | | 2001:db8::/32 | | 3ffe:1800::/32 +----+-+ +-+----+ | ISP1 | | ISP2 | +----+-+ +-+----+ | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 (DHCP-PD') ++-------++ (DHCP-PD') | Gateway | +----+----+ | 2001:db8:a:1::/64 | 3ffe:1800:a:1::/64 | (RA'/DHCP') ------+---+---------- | +-+----+ 2001:db8:a:1:[EUI64] | Host | 3ffe:1800:a:1:[EUI64] +------+ [Fig. 2] Fig. 2 shows a host with multiple home addresses that subscribes to two ISPs for connectivity to the Internet. The manner of address delegation and allocation is as described in 3.1. 3.2.1 Description of Each Element i) ISP -> Gateway The difference between this and the previous example is that ISP2 provides global network connectivity, so the DHCP-PD' address- selection policy option for ISP2 includes an additional entry. Address Addr. Sel. Policy 3ffe:1800:a::/48 --+-- 3ffe:1800::/32 +--- ::/0 ii) Gateway -> Host As both ISPs provide global network connectivity, the policy for address-selection from the gateway router to the end nodes is of the form shown below. Arifumi [Page 8] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 Address Addr. Sel. Policy 1 2001:db8:a:1::/64 --+-- 2001:db8::/32 +-- ::/0 2 3ffe:1800:a:1::/64 --+-- 3ffe:1800::/32 +--- ::/0 iii) Host Each end node will have the following address-selection policy table. Prefix. Pref. Label 2001:db8::/32 10 100 2001:db8:a:1::/64 10 100 (::/0 10 100) 3ffe:1800::/32 10 200 3ffe:1800:a:1::/64 10 200 (::/0 10 200) Note that the end nodes are notified of an address-selection policy that includes prefix ::/0 by both ISPs, hence a specific source address for ::/0 can't be determined in the Label-Rule judgment phase described in RFC3484. So, these entries for prefix ::/0 won't actually be stored in the policy table, and this policy table won't have any effect on source-address selection for packets that match ::/0. The source address in these cases will be determined by following rules listed in RFC3484, such as longest match with the destination address. iv) Gateway Unlike the previous example (3.1.1(iv)), normal destination- address-based routing doesn't specify a particular next-hop. Dst Next-Hop 2001:db8::/32 ISP1 ::/0 ISP1 3ffe:1800::/32 ISP2 ::/0 ISP2 So, source-address-based routing as described in 3.1.1(iv) will be effective. 3.2.2 Discussion One of the benefits of having an ISP provide address-selection policy to its customers is that it can explicitly check incoming packets to Arifumi [Page 9] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 see if it delegated their source addresses. Delivery of an address- selection policy makes the following mechanisms possible. - Since end nodes and routers in a multihoming site are given some kind of routing information, they can select the route expected to be optimal. In the above example, end nodes can communicate with servers of the ISPs without any circumvention. - Another possible usage of this framework is notification of security policy. ISPs commonly apply IP-address-based filtering to packets that attempt access to their services, such as POP, SMTP and Web content, partly for security reasons and partly as a value-added service for their customers. IMHO one issue to be discussed is multipath routing. In the second of the examples presented above, the router and host have two default routes and thus have the potential to apply multipath techniques [2991][2992]. To take greater advantage of multihoming, we should probably consider using a multipath routing algorithm. 3.3 A Host Directly Connected to Multiple ISPs ================== | Internet | ================== | | 2001:db8::/32 | | 3ffe:1800::/32 | | 2001:db8:a::/48 | | 3ffe:1800:a::/48 (DHCP-PD') +----+-+ +-+----+ (DHCP-PD') | GW1 | | GW2 | +----+-+ +-+----+ 2001:db8:a:1::/64 | | 3ffe:1800:a:1::/64 (RA'/DHCP') | | (RA'/DHCP') -----+-+- -+-+----- | | 2001:db8:a:1:[EUI64]++---++ 3ffe:1800:a:1:[EUI64] | Host| +-----+ [Fig. 3] Arifumi [Page 10] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 This example shows an end node directly connected to two ISPs, both of which provide global network connectivity. The only difference between this case and the case described in 3.2 is that the host itself has to take on the role of gateway router, that is, of applying routing policy based on source addresses. 4. 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. 5. Normative References [3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6," RFC 3633, Dec. 2003. [2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, Dec. 1998. [3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 3315, Jul. 2003. [3484] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)," RFC 3484, Feb. 2003. [2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection," RFC 2991, Nov. 2000. [2992] C. Hopps, "Analysis of an Equal-Cost Multi-Path Algorithm," RFC 2992, Nov. 2000. Authors' Addresses Arifumi Matsumoto Nippon Telegraph and Telephone Corporation Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Arifumi [Page 11] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 Phone: +81-422-59-3334 E-Mail: matsumoto.arifumi@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 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 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 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. 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 Arifumi [Page 12] draft-arifumi-multi6-sas-policy-dist-00.txt 10 Sep 2004 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. Arifumi [Page 13]