idnits 2.17.1 draft-arifumi-ipv6-sas-policy-dist-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 846. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 738 has weird spacing: '...actions for I...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2005) is 7024 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2991' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC2992' is defined on line 767, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 2991 ** Downref: Normative reference to an Informational RFC: RFC 2992 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group A. Matsumoto 2 Internet-Draft NTT 3 Expires: August 1, 2005 T. Fujisaki 4 H. Matsuoka 5 J. Kato 6 January 31, 2005 8 Source Address Selection Policy Distribution for Multihoming 9 draft-arifumi-ipv6-sas-policy-dist-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 1, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes a method for the distribution of source 45 address selection policy from ISPs to gateway routers for consumers 46 and from the gateways to end nodes. This method is particularly 47 effective when a consumer site has multiple address blocks. Every 48 end node is guided by the policy in selecting an appropriate source 49 address for each destination address and every gateway is guided by 50 the policy in forwarding packets to appropriate next-hop ISPs. This 51 makes it possible for an end node to set a connection up without 52 being concerned about failures of transfer due to ingress filtering 53 by the ISPs, for ISP operators to manage consumers' behavior and 54 networking policy, and for consumers to be provided with networks 55 that are almost automatically robust and reliable. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1 Ingress Filtering Problem . . . . . . . . . . . . . . . . 3 62 2.2 Closed Network Problem . . . . . . . . . . . . . . . . . . 4 63 3. Concepts of Our Proposal . . . . . . . . . . . . . . . . . . . 5 64 4. Proposal Overview For Each Case . . . . . . . . . . . . . . . 7 65 4.1 Case 1: Multihome Site with Global-Closed Mixed 66 Connectivity . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1.1 Description of Each Element . . . . . . . . . . . . . 7 68 4.1.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2 Case 2: Host with Multiple Addresses and Connectivity 70 to Two Global Networks . . . . . . . . . . . . . . . . . . 11 71 4.2.1 Description of Each Element . . . . . . . . . . . . . 11 72 4.2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3 Case 3: A Host Directly Connected to Multiple ISPs . . . . 13 74 5. Who merges conflicting policies and how ? . . . . . . . . . . 14 75 6. Failure Recovery . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.1 Stop advertising . . . . . . . . . . . . . . . . . . . . . 14 77 6.2 Address Revocation . . . . . . . . . . . . . . . . . . . . 15 78 6.3 Policy Modification . . . . . . . . . . . . . . . . . . . 15 79 7. Solution Comparison . . . . . . . . . . . . . . . . . . . . . 15 80 7.1 Site Local Address . . . . . . . . . . . . . . . . . . . . 15 81 7.2 Router Selection . . . . . . . . . . . . . . . . . . . . . 16 82 7.3 Routing Protocol Based Policy Distribution . . . . . . . . 16 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 86 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 17 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 89 12.2 Informative References . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 91 Intellectual Property and Copyright Statements . . . . . . . . 19 93 1. Introduction 95 An IPv6 multihoming site has multiple nodes, each of which is 96 assigned multiple IPv6 addresses by up-stream ISPs. When there are 97 multiple up-stream ISPs, the means of selection of the ISP for an 98 outgoing packet is currently based on the destination address. In 99 general, however, each packet should have a source address that has 100 been allocated by the selected up-stream ISP. This is because the 101 routers of ISPs may be configured to perform ingress filtering with 102 the aim of blocking packets that have strange source addresses. 104 In this document, we clarify the problems of source address 105 selection, list up solutions for them, and propose our solution, 106 which is a technique that is used both to distribute policy 107 information for source address selection at end nodes and to 108 establish a method for the forwarding of packets by routers. This 109 enables the control of incoming traffic from customer sites by ISPs, 110 the selection of appropriate source addresses by end nodes, and the 111 selection of outgoing ISPs in a way that is almost certain to produce 112 successful connection setup. 114 2. Problem Statement 116 2.1 Ingress Filtering Problem 118 ================== 119 | Internet | 120 ================== 121 | | 122 2001:db8::/32 | | 3ffe:1800::/32 123 +----+-+ +-+----+ 124 | ISP1 | | ISP2 | 125 +----+-+ +-+----+ 126 | | 127 2001:db8:a::/48 | | 3ffe:1800:a::/48 128 ++-------++ 129 | Gateway | 130 +----+----+ 131 | 2001:db8:a:1::/64 132 | 3ffe:1800:a:1::/64 133 ------+---+---------- 134 | 135 +-+----+ 2001:db8:a:1:EUI64 136 | Host | 3ffe:1800:a:1:EUI64 137 +------+ 139 [Fig. 1] 141 When a relatively small site, we call it "consumer network", is 142 attached to two up-stream ISPs, each ISP delegates network address 143 block, which is usually /48, and a host has multiple IPv6 addresses. 145 When the source address of an outgoing packet isn't the one that is 146 delegated by a transit ISP, the packet will be very probably dropped 147 by ISP's ingress filter. Ingress filtering is getting popular and 148 popular among ISPs in order to mitigate the damage of DoS attacks. 150 One possible solution for this problem is to adopt source address 151 based routing at consumer site's gateway, but this new way of routing 152 is not widely deployed yet. 154 2.2 Closed Network Problem 156 You can see a second typical source address selection problem in a 157 multihome site with global-closed mixed connectivity like the figure 158 below. In this case, Host-A is in a multihomed network and has two 159 IPv6 addresses delegated from each of up-stream ISPs. Note that ISP2 160 is closed network and doesn't have connectivity to the Internet. 162 +--------+ 163 | Host-C | 3ffe:503:c:1:EUI64 164 +-----+--+ 165 | 166 ============== +--------+ 167 | Internet | | Host-B | 3ffe:1800::EUI64 168 ============== +--------+ 169 | | 170 2001:db8::/32 | | 3ffe:1800::/32 171 +----+-+ +-+---++ 172 | ISP1 | | ISP2 | (Closed Network / VPN tunnel) 173 +----+-+ +-+----+ 174 | | 175 2001:db8:a::/48 | | 3ffe:1800:a::/48 176 ++-------++ 177 | Gateway | 178 +----+----+ 179 | 2001:db8:a:1::/64 180 | 3ffe:1800:a:1::/64 181 ------+---+---------- 182 | 183 +--+-----+ 2001:db8:a:1:EUI64 184 | Host-A | 3ffe:1800:a:1:EUI64 185 +--------+ 187 [Fig. 2] 189 This network environment isn't so uncommon as you might perhaps think 190 of it. The access-line to the ISP2 might be actually a VPN tunnel 191 over ISP1 and the Internet. 193 When Host-A starts connection to Host-B in ISP2, the source address 194 of a sending packet will be the one delegated from ISP2, that is 195 3ffe:1800:a:1:EUI64, because of rule 8 (longest matching prefix) in 196 RFC 3484 [RFC3484]. 198 Host-C is located somewhere in the Internet and has an IPv6 address 199 3ffe:503:c:1:EUI64. When Host-A sends a packet to Host-C, longest 200 matching algorithm chooses 3ffe:1800:a:1:EUI64 for the source 201 address. In this case, the packet goes through ISP1 and may be 202 filtered by ISP1's ingress filter. Even if the packet isn't filtered 203 by ISP1 fortunately, a return packet from Host-C won't possibly reach 204 at Host-A, because the return packet is destined for 205 3ffe:1800:a:1:EUI64, which is closed from the Internet. 207 In this case, source address based routing alone described in the 208 previous section doesn't solve the problem. What is important is 209 that each host chooses a correct source address for a given 210 destination address as far as NAT doesn't exist in IPv6 world. 212 3. Concepts of Our Proposal 214 In this document, we propose a method by which an ISP can distribute 215 source address selection policies to each end node at a customer 216 site. The policy information is particularly helpful to hosts in 217 which multihoming is used, since an end node can use the destination 218 address to select a source address that leads to a high probability 219 of successful setup for the connection. 221 An up-stream ISP is expected to use DHCPv6 Prefix Options [RFC3633] 222 to delegate a certain portion of the IPv6 address space to its 223 subscribers. We propose a DHCPv6 new option, which contains a per- 224 delegating-prefix address-selection policy. By making use of this 225 option, an ISP can inform its customers of an address block that can 226 be reached through the ISP and of a corresponding source address of 227 packets, that is, a source address that must be used to reach the 228 given block. This is simply achieved through delegation of the 229 delegated source-address prefix and policy by the ISP. 231 The gateway router of a customer's site receives the delegated prefix 232 and address-selection policy mentioned above from its up-stream ISPs. 233 The router in turn distributes this information to end nodes at the 234 site. Here, we propose an extension to the ND6 Router Advertisement 235 Message [RFC2461] and a DHCPv6 [RFC3315] new option to cover delivery 236 of address-selection policy to the end nodes. The address-selection 237 policy delivered to an end node is stored in the form of a Policy 238 Table as defined in RFC 3484 [RFC3484]. 240 Once the above series of processes is complete, an end node can 241 select an appropriate source address for a given destination address. 242 Routing of an outgoing packet to the corresponding up-stream ISP can 243 be implemented in several ways that avoids blocking of the packet by 244 ingress filtering. One way is a routing method guided by the source 245 address of the packet, which is sometimes called "policy routing". 246 Another method uses destination address based routing with the aid of 247 additional routing information. 249 This mechanism is particularly effective when a site subscribes to an 250 ISP or VPN service that provides connectivity to a certain closed 251 network as described in the previous section. This is because 252 selecting an appropriate source address for a given destination 253 address is crucial in such a network environment. 255 This approach gives end nodes an advance measure against connection 256 setup failure. At the same time, an ISP can control incoming traffic 257 from customers' sites, and the network managers of customers' sites 258 can reflect their networking policy to some extent by configuring 259 DHCPv6 or ND6 RA settings on routers. The last but not the least 260 significant feature to note here is that this sequence of passing, 261 processing, generation, and reflection of policy information can be 262 made almost totally automatic from the viewpoint of customers. 264 4. Proposal Overview For Each Case 266 4.1 Case 1: Multihome Site with Global-Closed Mixed Connectivity 268 Fig. 3 shows a multihome site that subscribes to two ISPs. One ISP 269 provides global network connectivity and the other provides 270 connectivity to a closed network but not to the Internet. This site 271 has one border router, labeled Gateway here, and the router may be 272 connected to up-stream ISPs through a physical or logical link, say 273 PPPoE or an IPsec Tunnel. 275 ============== 276 | Internet | 277 ============== 278 | 279 2001:db8::/32 | 3ffe:1800::/32 280 +----+-+ +-+----+ 281 | ISP1 | | ISP2 | (Closed Network / VPN tunnel ) 282 +----+-+ +-+----+ 283 | | 284 2001:db8:a::/48 | | 3ffe:1800:a::/48 285 (DHCP-PD') ++-------++ (DHCP-PD') 286 | Gateway | 287 +----+----+ 288 | 2001:db8:a:1::/64 289 | 3ffe:1800:a:1::/64 290 | (RA'/DHCP') 291 ------+---+---------- 292 | 293 +-+----+ 2001:db8:a:1:EUI64 294 | Host | 3ffe:1800:a:1:EUI64 295 +------+ 297 [Fig. 3] 299 4.1.1 Description of Each Element 301 i) ISP -> Gateway 302 This figure shows that ISP1 has been allocated 2001:db8::/32 and 303 ISP2 has been allocated 3ffe:1800::/32. Each ISP delegates part 304 of its address block, called the "provider aggregatable (PA)" 305 block, to this customer site. Here, ISP1 and ISP2 use DHCP-PD to 306 delegate 2001:db8:a::/48 and 3ffe:1800:a::/48, respectively. 308 In this document, we propose an extension to DHCP-PD, which is 309 actually a new DHCP option and called DHCP-PD' here. DHCP-PD' 310 gives DHCP servers (ISPs) functionality for delivering an address- 311 selection policy in combination with a delegated prefix to a 312 client (gateway). In this example, ISP2 includes 314 Address Addr. Sel. Policy 315 3ffe:1800:a::/48 ---- 3ffe:1800::/32 317 in the PD and address-selection policy options sent to the client. 318 This means that the subscribers of ISP2 should use an address from 319 the delegated range, that is, 3ffe:1800:a::/48, when communicating 320 with 3ffe:1800::/32. 322 Selection of an appropriate source address is very important, and 323 this is particularly so when one of the subscribing networks is 324 closed as in this example. This is simply because a return packet 325 from the closed network can't possibly reach the session- 326 originating host if the return packet is destined for an address 327 beyond the range available to the closed ISP. 329 ISP1 also uses DHCP-PD', in this case to deliver its address- 330 selection policy to its customers. As ISP1 provides global 331 network connectivity, the PD and policy options will take the 332 following form. 334 Address Addr-Sel. Policy 335 2001:db8:a::/48 --+-- 2001:db8::/32 336 +-- ::/0 (all address) 338 This means that ISP1 can provide connectivity to 2001:db8::/32 and 339 act as a transit point for any other address (::/0) in the 340 Internet as long as the source address is that delegated by ISP1, 341 namely 2001:db8:a::/48. 343 Of course, ::/0 includes 2001:db8::/32, so 2001:db8::/32 isn't 344 necessary information for down-stream users. Like this way, 345 however, by announcing more specific network block than ::/0 as a 346 policy to down-stream, it is more likely to be adopted by 347 down-stream nodes. This is because conflicting policies will be 348 probably discarded at end nodes and routers, as mentioned below in 349 4.2.1, and ::/0 is much more likely to conflict with other ISP's 350 policy than 2001:db8::/32. ISPs often provides additional 351 services, such as video streaming and homepage building tool, only 352 to their customers. This kind of access control is easily 353 implemented by announcing ISP's specific network block in their 354 address-selection policies. 356 With regard to backward compatibility, a normal DHCP-PD packet, 357 which does not carry address-selection policy information of the 358 above type, should be deemed to have ::/0 as its policy field. 360 ii) Gateway -> Host 361 A gateway router receives address-delegation information and 362 address-selection policy from up-stream ISPs, in turn delivering 363 both to down-stream nodes. In this document, we propose DHCP new 364 option and an extension to RA (Router Advertisement Message). We 365 refer to these as DHCP' and RA', respectively. The gateway router 366 combines information given by multiple up-stream ISPs and 367 distributes the following information down-stream through DHCP' or 368 RA'. 370 Address Addr. Sel. Policy 371 1 2001:db8:a:1::/64 --+-- 2001:db8::/32 372 +-- ::/0 373 2 3ffe:1800:a:1::/64 ----- 3ffe:1800::/32 375 This is just the combination of the information from the two up- 376 stream elements in the previous section, except that each 377 advertising address prefix is 64 bits long. 379 iii) Host 380 When a host receives an RA' or DHCP' message from the site 381 gateway, it configures addresses for each receiving network 382 interface and reflects address-selection policy in its 383 RFC3484-based policy table. 385 In this example, we propose that the policy table should be 386 configured as follows, by making use of the Label field defined in 387 RFC3484, and the relation between address prefix and address- 388 selection policy should be kept in this table. 390 Prefix Pref. Label 391 2001:db8::/32 10 100 392 ::/0 10 100 393 2001:db8:a:1::/64 10 100 394 3ffe:1800::/32 10 200 395 3ffe:1800:a:1::/64 10 200 397 When this host sends a packet to, for example, 3ffe:1800:a::100, 398 whose longest matching entry in this table is 3ffe:1800::/32, the 399 host chooses the address beginning with 3ffe:1800:a:1:: as the 400 source address. The source-address selection algorithm will 401 select the longest entry that is a candidate source-address range 402 and has the same label as the longest matching address for the 403 destination address. In the same way, the source address of a 404 packet destined for 2001:db8::/32 or 2002::/16 will be 405 2001:db8:a:1:EUI64. 407 Preference values are only used in the selection of destination 408 addresses. This document does not include an algorithm for 409 determining preference values. 411 iv) Gateway 412 As well as delivering addresses and policy information to hosts 413 through RA' or DHCP', the gateway is in charge of forwarding 414 packets according to policy information distributed by up-stream 415 ISPs. One way of implementing such forwarding or routing, called 416 policy routing, is based on the source addresses of out-going 417 packets. Policy routing is illustrated in the table below. 419 Src. Next Hop 420 2001:db8:a:1::/64 ISP1 421 3ffe:1800:a:1::/64 ISP2 423 This kind of routing method, however, isn't so common for 424 consumer network routers. Even if this technique is implemented, 425 it may degrade packet forwarding performance seriously when it 426 doesn't have hardware acceleration support. One alternative for 427 policy routing is to use a routing protocol or some similar 428 protocols and give a consumer network gateway as much routing 429 information as the gateway can do destination address based 430 routing. In this example, the routing table of the gateway looks 431 like this. 433 Dst. Next Hop 434 2001:db8::/32 ISP1 435 ::/0 ISP1 436 3ffe:1800::/32 ISP2 438 4.1.2 Discussion 440 The benefits of this scheme are very clear. Every end node can 441 determine which source address should be used and can send packets 442 without a risk of failure due to ingress filtering or the limited 443 reachability of a closed network. 445 What should be discussed from here is the need for and implementation 446 of policy enforcement to end nodes and the process of combining 447 multiple address-selection policies. It's so hard to combine two 448 policies automatically when a policy coming from an ISP conflicts 449 with another ISP's policy. We may also have to think about combining 450 or pruning algorithm to contain too much policy information in one 451 packet. 453 4.2 Case 2: Host with Multiple Addresses and Connectivity to Two Global 454 Networks 456 ================== 457 | Internet | 458 ================== 459 | | 460 2001:db8::/32 | | 3ffe:1800::/32 461 +----+-+ +-+----+ 462 | ISP1 | | ISP2 | 463 +----+-+ +-+----+ 464 | | 465 2001:db8:a::/48 | | 3ffe:1800:a::/48 466 (DHCP-PD') ++-------++ (DHCP-PD') 467 | Gateway | 468 +----+----+ 469 | 2001:db8:a:1::/64 470 | 3ffe:1800:a:1::/64 471 | (RA'/DHCP') 472 ------+---+---------- 473 | 474 +-+----+ 2001:db8:a:1:EUI64 475 | Host | 3ffe:1800:a:1:EUI64 476 +------+ 478 [Fig. 4] 480 Fig. 4 shows a host with multiple addresses that subscribes to two 481 ISPs for connectivity to the Internet. The manner of address 482 delegation and allocation is as described in the previous example. 484 4.2.1 Description of Each Element 486 i) ISP -> Gateway 487 The difference between this and the previous example is that ISP2 488 provides global network connectivity, so the DHCP-PD' address- 489 selection policy option for ISP2 includes an additional entry. 491 Address Addr. Sel. Policy 492 3ffe:1800:a::/48 --+-- 3ffe:1800::/32 493 +-- ::/0 495 ii) Gateway -> Host 496 As both ISPs provide global network connectivity, the policy for 497 address-selection from the gateway router to the end nodes is of 498 the form shown below. 500 Address Addr. Sel. Policy 501 1 2001:db8:a:1::/64 --+-- 2001:db8::/32 502 +-- ::/0 503 2 3ffe:1800:a:1::/64 --+-- 3ffe:1800::/32 504 +-- ::/0 (deleted) 506 Note that the gateway is notified of an address-selection policy 507 that includes prefix ::/0 by both ISPs. A policy table cannot 508 have multiple entries whose prefixes are the same and labels 509 aren't the same, which we call conflicting policies. 511 Though the next section includes further statements about merging 512 conflicting policies, there are basically two solutions for this 513 issue: to remove all the conflicting policies or to choose one. 514 Here, we continue the description of this example with the latter 515 solution, so the second entry above is removed here and not 516 forwarded down-stream. 518 iii) Host 519 Each end node will have the following address-selection policy 520 table. 522 Prefix. Pref. Label 523 2001:db8::/32 10 100 524 ::0 10 100 525 2001:db8:a:1::/64 10 100 526 3ffe:1800::/32 10 200 527 3ffe:1800:a:1::/64 10 200 529 It doesn't have any conflicting entries anymore, owing to the 530 conflict removal at the gateway. Thus, end nodes can determine a 531 source address for any destination addresses without any trouble. 533 iv) Gateway 534 If you remove conflicting source address selection policies for 535 ::/0 and choose one ::/0 policy, the gateway can do destination 536 address based routing. The routing table at the gateway looks 537 like this. 539 Dst. Next Hop 540 2001:db8::/32 ISP1 541 ::/0 ISP1 542 3ffe:1800::/32 ISP2 544 Here, we assume that end nodes select an appropriate source 545 address for any destination addresses by the aid of distributed 546 source address selection policy. So, destination address based 547 routing suffices in this case. 549 4.2.2 Discussion 551 One of the benefits of having an ISP provide address-selection policy 552 to its customers is that it can explicitly check incoming packets to 553 see if it is delegated their source addresses. Delivery of an 554 address-selection policy makes the following mechanisms possible. 556 - Since end nodes and routers in a multihoming site are given some 557 kind of routing information, they can select the route expected to 558 be optimal. In the above example, end nodes can communicate with 559 servers of the ISPs without any circumvention. 560 - Another possible usage of this framework is notification of 561 security policy. ISPs commonly apply IP-address-based filtering 562 to packets that attempt access to their services, such as POP, 563 SMTP and Web content, partly for security reasons and partly as a 564 value- added service for their customers. 566 4.3 Case 3: A Host Directly Connected to Multiple ISPs 568 ================== 569 | Internet | 570 ================== 571 | | 572 2001:db8::/32 | | 3ffe:1800::/32 573 | | 574 2001:db8:a::/48 | | 3ffe:1800:a::/48 575 (DHCP-PD') +----+-+ +-+----+ (DHCP-PD') 576 | GW1 | | GW2 | 577 +----+-+ +-+----+ 578 2001:db8:a:1::/64 | | 3ffe:1800:a:1::/64 579 (RA'/DHCP') | | (RA'/DHCP') 580 -----+---+---+----- 581 | 582 2001:db8:a:1:EUI64 +--+---+ 3ffe:1800:a:1:EUI64 583 | Host | 584 +------+ 586 [Fig. 5] 588 This example shows an end node directly connected to two ISPs, both 589 of which provide global network connectivity. This case also has 590 source address selection problem. Even if a host has enough 591 knowledge about up-stream network addresses and routes, a host in 592 this site cannot select an appropriate source address for a given 593 destination address, as we've mentioned in the problem statement 594 section. 596 [I-D.ietf-ipv6-router-selection] defines another Neighbor Discovery 597 Router Advertisement option for distributing routing information. In 598 a case that a host has two network interfaces and is connected to 599 gateways on a separate link, routing information suffices for 600 choosing a correct source address. In a site like this, however, a 601 host should store relationships between routing information and 602 source address selection. So, in this kind of site, it seems to be 603 better to use both router-selection mechanism, for distributing 604 routing information, and our mechanism, for distributing source 605 address selection policy. 607 In case gateways are under your control, there is one alternative 608 approach. It is to redirect packets with a wrong source address at 609 gateways. 611 5. Who merges conflicting policies and how ? 613 Another discussion topic should be about merging method of 614 conflicting policies and who merges them. As far as an end node 615 cannot have or make use of multiple source address selection policy 616 entry for the same prefix, somebody has to merge them into one 617 policy. There may be three cases for this issue; the site exit 618 gateway does the merging job, end nodes do and both gateways and end 619 nodes do. 621 The management cost of a site might be relatively low, if you let a 622 gateway to decide which policy to choose, in that you have only to 623 configure the gateway. 625 In contrast, if you give end nodes all the information the gateway 626 received, you can let each end node to choose which source address 627 selection policy to apply and to select which access-line to use. 628 This means, at the same time, you have to configure each end node. 630 Even in such a site that a gateway removes policy conflicts, an end 631 node should be capable of receiving and manipulating conflicting 632 policies in case that an additional gateway gets into a local link. 634 6. Failure Recovery 636 When one of the links to up-stream ISPs has network trouble and the 637 consumer gateway detects it, the gateway can take the following 638 responses. 640 6.1 Stop advertising 642 "Stop advertising IPv6 address prefix of the ISP in trouble." 643 If the address is assigned by Router Advertisement, this doesn't have 644 effects on source address selection immediately, because IPv6 address 645 has relatively long valid and preferred lifetime. 647 6.2 Address Revocation 649 "Revoke an address delegated by an ISP in trouble." 651 If IPv6 address is assigned to end nodes by DHCPv6, the gateway 652 (DHCPv6 Server) can revoke those addresses that is delegated by a 653 troubled ISP in a reasonably short time. 655 6.3 Policy Modification 657 "Distribute modified source address selection policy that prevents 658 end nodes from using a certain address." 660 By distributing, for example, the following source address selection 661 policy to end nodes, the gateway can control end hosts' address 662 selection quickly. 664 Prefix. Pref. Label 665 2001:db8::/32 10 100 666 ::0 10 100 667 2001:db8:a:1::/64 10 100 668 3ffe:1800::/32 10 100 669 3ffe:1800:a:1::/64 10 200 671 In this case, this host doesn't use the address 3ffe:1800:a:1:EUI64, 672 except when it communicate with hosts on the same link. 674 You may argue that Router Advertisement is essentially a rather 675 static protocol and isn't suitable for this kind of dynamic 676 configuration modification. However, it seems also to be true that 677 these failure recovery methods are useful enough. We basically leave 678 this topic to an operational issue. 680 7. Solution Comparison 682 7.1 Site Local Address 684 One alternative method for this approach is to use site-local address 685 for closed network ISP. The site-local address, however, is 686 deprecated and isn't recommended to use anymore. The newly proposed 687 site-local address, what we call Unique Local IPv6 Unicast Address 688 [I-D.ietf-ipv6-unique-local-addr], isn't appropriate for such kind of 689 use as this, because the address block size of it (/48) is too small 690 for ISPs to delegate a certain size of IPv6 address block to each 691 customer. 693 7.2 Router Selection 695 Router Selection [I-D.ietf-ipv6-router-selection] internet-draft is a 696 proposal for introducing new options for Router Advertisement. As it 697 is mentioned in section 4.3, this is a solution especially for those 698 IPv6 nodes that has multiple network interfaces and assigned one IPv6 699 address for each network interface. Our proposal and this draft 700 surely has close relationship with each other, but our scope of 701 problem cannot be resolved only by this mechanism. 703 7.3 Routing Protocol Based Policy Distribution 705 Another alternative might be such a modified form of routing 706 protocol, so that it can store relationships of routes and source 707 address selection policy. However, it seems to be a big drawback 708 that consumer site gateway has to support a dynamic routing protocol. 709 This can bring a big impact on both consumer site gateways and a 710 provider edge routers. 712 8. Security Considerations 714 With regard to the possibility of traffic abduction through the 715 announcement of a bogus policy, this scheme seems to neither lower 716 nor raise the security level obtained by the existing base-protocols, 717 such as DHCP-PD, DHCP and RA. However, it does raise the possibility 718 of a new form of DoS attack on routers and hosts, in which large 719 numbers of address-selection policies are generated by different 720 source addresses. We will have to discuss this and take 721 precautionary measures in designing the protocol specification. 723 9. Revision History 725 The previous revision of this document is 726 "draft-arifumi-multi6-sas-policy-dist-00.txt". 727 [I-D.arifumi-multi6-sas-policy-dist] Here lists differences from it. 729 o Section 2,5,6,7,9 are added. 730 o We removed descriptions that show dependency on source address 731 base routing. 732 o 3rd case in section 4 is changed to one network interface host 733 from two. 734 o A little description about merging conflicting policies is added 735 to 2nd case in section 4. 737 10. IANA Considerations 738 This document has no actions for IANA. 740 11. Acknowledgement 742 Many thanks to Iljitsch, Changming and Shin Miyagawa for detailed 743 feedbacks and discussions on this document. We really appreciate all 744 the members in our laboratory for their contributions. 746 12. References 748 12.1 Normative References 750 [I-D.ietf-ipv6-router-selection] 751 Draves, R. and D. Thaler, "Default Router Preferences and 752 More-Specific Routes", draft-ietf-ipv6-router-selection-07 753 (work in progress), January 2005. 755 [I-D.ietf-ipv6-unique-local-addr] 756 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 757 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in 758 progress), January 2005. 760 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 761 Discovery for IP Version 6 (IPv6)", RFC 2461, December 762 1998. 764 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 765 Multicast Next-Hop Selection", RFC 2991, November 2000. 767 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 768 Algorithm", RFC 2992, November 2000. 770 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 771 M. Carney, "Dynamic Host Configuration Protocol for IPv6 772 (DHCPv6)", RFC 3315, July 2003. 774 [RFC3484] Draves, R., "Default Address Selection for Internet 775 Protocol version 6 (IPv6)", RFC 3484, February 2003. 777 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 778 Host Configuration Protocol (DHCP) version 6", RFC 3633, 779 December 2003. 781 12.2 Informative References 783 [I-D.arifumi-multi6-sas-policy-dist] 784 Matsumoto, A., "Source Address Selection Policy 785 Distribution for Multihoming", 786 draft-arifumi-multi6-sas-policy-dist-00 (work in 787 progress), October 2004. 789 Authors' Addresses 791 Arifumi Matsumoto 792 NTT PFLab 793 Midori-Cho 3-9-11 794 Mitaka City, Tokyo Prefecture 180-8585 795 JP 797 Phone: +81 422 59 3334 798 EMail: arifumi@nttv6.net 800 Tomohiro Fujisaki 801 Midori-Cho 3-9-11 802 Mitaka City, Tokyo Prefecture 180-8585 803 JP 805 Phone: +81 422 59 7351 806 EMail: fujisaki@syce.net 808 Hirotaka Matsuoka 809 Midori-Cho 3-9-11 810 Mitaka City, Tokyo Prefecture 180-8585 811 JP 813 Phone: +81 422 59 4949 814 EMail: matsuoka@syce.net 816 Jun-ya Kato 817 Midori-Cho 3-9-11 818 Mitaka City, Tokyo Prefecture 180-8585 819 JP 821 Phone: +81 422 59 2939 822 EMail: kato@syce.net 824 Intellectual Property Statement 826 The IETF takes no position regarding the validity or scope of any 827 Intellectual Property Rights or other rights that might be claimed to 828 pertain to the implementation or use of the technology described in 829 this document or the extent to which any license under such rights 830 might or might not be available; nor does it represent that it has 831 made any independent effort to identify any such rights. Information 832 on the procedures with respect to rights in RFC documents can be 833 found in BCP 78 and BCP 79. 835 Copies of IPR disclosures made to the IETF Secretariat and any 836 assurances of licenses to be made available, or the result of an 837 attempt made to obtain a general license or permission for the use of 838 such proprietary rights by implementers or users of this 839 specification can be obtained from the IETF on-line IPR repository at 840 http://www.ietf.org/ipr. 842 The IETF invites any interested party to bring to its attention any 843 copyrights, patents or patent applications, or other proprietary 844 rights that may cover technology that may be required to implement 845 this standard. Please address the information to the IETF at 846 ietf-ipr@ietf.org. 848 Disclaimer of Validity 850 This document and the information contained herein are provided on an 851 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 852 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 853 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 854 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 855 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 856 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 858 Copyright Statement 860 Copyright (C) The Internet Society (2005). This document is subject 861 to the rights, licenses and restrictions contained in BCP 78, and 862 except as set forth therein, the authors retain all their rights. 864 Acknowledgment 866 Funding for the RFC Editor function is currently provided by the 867 Internet Society.