idnits 2.17.1 draft-arifumi-6man-addr-select-conflict-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 261 has weird spacing: '... bad bad...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5155 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-05) exists of draft-ietf-6man-addr-select-considerations-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Informational NTT 5 Expires: September 9, 2010 R. Hiromi 6 Intec Netcore 7 March 8, 2010 9 Considerations of address selection policy conflicts 10 draft-arifumi-6man-addr-select-conflict-02.txt 12 Abstract 14 This document examines how policy conflicts happen, and how to 15 address the conflicts. After making it clear what kind of address 16 selection policy should be necessary, we proposed how to merge the 17 possibily conflicting policies for each of the destination address 18 selection policy and source address selection policy. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Motivations for Address Selection Control . . . . . . . . . . 4 74 3. Conflicts and Solution Analysis . . . . . . . . . . . . . . . 5 75 3.1. Source Address Selection . . . . . . . . . . . . . . . . . 5 76 3.2. Destination Address Selection . . . . . . . . . . . . . . 7 77 4. Cenceptual Policy Processing Model . . . . . . . . . . . . . . 9 78 4.1. The Whole Picture of Policy Merging Process . . . . . . . 9 79 4.2. Example of Address Selection Policy Merging . . . . . . . 10 80 4.2.1. Processing Source Address Selection Policy . . . . . . 10 81 4.2.2. Processing Destination Address Selection Policy . . . 11 82 4.2.3. Precedence and Label Values Adjustment . . . . . . . . 12 83 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 RFC 5220 [RFC5220] describes several cases where problems are caused 96 by using multiple prefixes at hosts and sites. The address selection 97 design team is working on this issue and summarizes their work in the 98 considerations document [I-D.ietf-6man-addr-select-considerations]. 99 Their solution mechanism is going to be an update mechanism of the 100 address selection policy table at a host from the network. As one of 101 the possible solutions, a DHCPv6 option 102 [I-D.fujisaki-dhc-addr-select-opt] is proposed. 104 As mentioned in RFC 5220 [RFC5220], a host or a site belongs to 105 multiple upstream networks in some environments. For example, a host 106 with multiple interfaces, such as wireless and wired interfaces, can 107 easily belong to multiple networks. A site may have connectivity to 108 ISP and a corporate network through a VPN link. 110 In these cases, if two or more of the upstream networks want to 111 control address selection behavior of his network's customer host, 112 those address selection policies have to be merged at the host, and 113 they may collide there. 115 Note that this document does not assume the address selection policy 116 transmitted by an upstream network provider is in the form of RFC 117 3484 [RFC3484] policy table itself. Rather, it sorts out the 118 motivation for address selection control in Section 2, and 119 accordingly defines the form of policy. Then, this document 120 describes how policy conflicts happen, and how they can be merged in 121 the Section 4. 123 Some of the problems described in RFC 5220 are specific to and 124 resulted from the address selection mechanism defined in RFC 3484 125 [RFC3484]. However, above mentioned policy collision is an intrinsic 126 problem of address selection policy merging, and not specific to the 127 RFC 3484 mechanism. 129 2. Motivations for Address Selection Control 131 As in RFC 5220, there are various motivations for network 132 administrator to control address selection behavior of his customers' 133 hosts. We can classify these policies into the following two groups. 135 - Source address selection behavior control: 137 "When accessing to PREFIX-1, use ADDRESS-1 as the source address." 138 A lot of ISPs have this policy and they usually implement it by 139 adopting ingress filtering to incoming packets from their 140 customers. Another example is a multi-prefix network that makes 141 use of multiple address blocks in the network and assigns multiple 142 addresses/prefixes to its customers for different purpose, such as 143 a prefix for the Internet access and a prefix for telephone call. 145 - Destination address selection behavior control: 147 "When accessing to PREFIX-1 or PREFIX-2, prefer PREFIX-1 rather 148 than PREFIX-2." This kind of control policy is usually intended 149 for optimization of the customers' traffic. It is not usually 150 intended for on-off switch manner of control, but rather control 151 of preference degree. For example, this is useful when a 152 destination site has both PREFIX-1 and PREFIX-2, and the network 153 administrator knows connectivity to PREFIX-1 is better than 154 PREFIX-2. The typical use case is IPv4 and IPv6 prioritization as 155 mentioned in RFC 5220. 157 On-off switch manner of destination address selection control is 158 not in scope of RFC 3484 address selection behavior, but it can be 159 implemented by some other means, such as routing table 160 manipulation and DNS resolution. 162 As it is intrinsiclly intended for optimization, it should not be 163 used for any other purpose like security . 165 Here, PREFIX-* is used to denote both IPv4 and IPv6 prefixes. In the 166 following part, policy conflict and its solution for these two kinds 167 of control policy are discussed individually. 169 3. Conflicts and Solution Analysis 171 3.1. Source Address Selection 173 As mentioned above, source address selection policy have following 174 meaning: 176 "When accessing to PREFIX-1, use ADDRESS-1 as the source address." 178 The upstream network that has this kind of policy usually assigns an 179 address block that includes ADDRESS-1, and also provides reachability 180 to the network that is specified by PREFIX-1. 182 Source address selection policy conflict can happen when different 183 network have a policy for the same prefix. For example, in the 184 following figure, Network-1 have a policy: "To PREFIX-1, use 185 ADDRESS-1", and Network-2: "To PREFIX-1 and PREFIX-2, use ADDRESS-2". 187 PREFIX-1 -----+ PREFIX-2 188 | \ | 189 | \ | 190 +-----+-----+ +-+---+-----+ 191 | Network-1 | | Network-2 | 192 +------+----+ +----+------+ 193 \ / 194 \ / 195 ADDRESS-1 \ / ADDRESS-2 196 +---+----+---+ 197 | Host/Site | 198 +------------+ 200 In this case, the solution is straightforward. As documented in RFC 201 3484, the destination address is determined before source address 202 selection policy is used. Thus, the outgoing route, such as the 203 next-hop node and the network interface, is determined by looking up 204 the routing table at a host. In other words, the outgoing network 205 that carries the packet to the destination is determined without the 206 source address selection policy. 208 So, the bottom line is that the source address selection policy that 209 matches routing table's behavior should be chosen. There is no point 210 adopting the source address selection policy of a network where a 211 packet does not go through. 213 In other words, if the routing table is fixed before the source 214 address selection policy is fixed, then the source address selection 215 policy should be implemented while avoiding contradiction with the 216 routing table. If not, the routing table should be coordinated to 217 match the source address selection policy. 219 In a case where a site is connected to the multiple ISPs, like the 220 figure above, and receives policies from the ISPs and re-distribute 221 policies to the downstream hosts, the hosts cannot know which ISP are 222 chosen for transit to PREFIX-1. So, in this case, the entity who 223 knows which way is chosen have to address the policy conflict. 225 For example, Network-1 and Network-2 advertise the following policy 226 to the customers, 228 Network-1: to PREFIX-1, use ADDRESS-1 229 Network-2: to PREFIX-1, use ADDRESS-2 230 to PREFIX-2, use ADDRESS-2 232 The policy for PREFIX-1 is conflicted in this case. And when the 233 routing table of the Host/Site is like below, 235 Destination Gateway 236 PREFIX-1 Gateway Address of Network-1 237 PREFIX-2 Gateway Address of Network-2 239 the merging process should choose a policy from Network-1 for the 240 conflicting PREFIX-1. By this process, the merged policy table will 241 be: 243 to PREFIX-1, use ADDRESS-1 244 to PREFIX-2, use ADDRESS-2 246 3.2. Destination Address Selection 248 As mentioned in section 2, destination address selection policy have 249 following meaning: "When accessing to a destination site that has 250 PREFIX-1 and PREFIX-2, prefer PREFIX-1 rather than PREFIX-2." The 251 upstream network that has this kind of policy should provides 252 reachability to both networks that are specified by PREFIX-1 and 253 PREFIX-2. 255 Destination address selection policy conflict can happen when a 256 network has a policy that has inverse effect of another network's 257 policy. That is, in the figure below, Network-1 prefers PREFIX-1 258 rather than PREFIX-2, and Network-2 prefers PREFIX-2 rather than 259 PREFIX-1. 261 bad bad 262 PREFIX-1 ---- ---- PREFIX-2 263 | X | 264 good | / \ | good 265 +-----+-----+ +-----+-----+ 266 | Network-1 | | Network-2 | 267 +------+----+ +----+------+ 268 \ / 269 \ / 270 ADDRESS-1 \ / ADDRESS-2 271 +---+---+---+ 272 | Host/Site | 273 +-----------+ 275 In routing mechanism, a router advertises a route A to a certain 276 destination, another advertises a route B to the same destination, 277 and the receiver decides which route to take by looking at the cost 278 of the routes and other information. 280 In destination address selection policy, a network advertises prefix 281 A and the precedence degree. The destination address selection 282 policy conflict happens when multiple entities provide policies for 283 the same or the overlapping destination prefix with different costs. 284 This is the same situation as the routing mechanism in that there can 285 be multiple "routes" for the same destination. 287 Here, we can choose the better, that is, higher precedence "route" 288 for the destination prefix, but there is no point if the route is not 289 actually used by the routing mechainism. Even if we choose a policy 290 for prefix A provided from Network-1, a packet destined for the 291 prefix A does not always go through Network-1. This is what the 292 routing mechianism of the host or the site router decides. 294 So, we propose to adopt the policy that is provided from the network 295 the routing mechanism selected and thus a packet goes through, 296 because the routing mechanism is already there and performs routing 297 decisions by making use of the routing protocols metrics and also 298 implementation dependent information. 300 For example, Network-1 router advertises the following policy to the 301 customers: 303 to PREFIX-1, precedence 20 304 to PREFIX-2, precedence 10 306 Network-2 advertises: 308 to PREFIX-1, precedence 30 309 to PREFIX-2, precedence 40 311 And when the routing table is: 313 PREFIX-1 via Network-1 314 PREFIX-2 via Network-2 316 Then, the receiving host should have the following merged destination 317 address selection policy: 319 to PREFIX-1, precedence 20 via Network-1 320 to PREFIX-2, precedence 40 via Network-2 322 4. Cenceptual Policy Processing Model 324 4.1. The Whole Picture of Policy Merging Process 326 The merging process in Section 3 describes how conflicting source 327 address selection policies can be merged, and how conflicting 328 destination address selection policies can be merged. The output of 329 these merged process is not in the form of RFC 3484 policy table. 331 However, we can get these merged policies into the RFC 3484 policy 332 table by the following processing of the merged policies. By 333 processing the policies this way, we do not need to modify the form 334 of RFC 3484 policy table. 336 +-------------+ +-------------+ 337 | Network-1 | | Network-2 | 338 +-------------+ +-------------+ 339 | \ / | 340 | X | 341 v v v v 342 +-------------+ +-------------+ 343 | Dst Address | | Src Address | 344 | Policy Pool | | Policy Pool | 345 +-------------+ +-------------+ 346 | | +---------------+ 347 |<------|<------------| Routing Table | 348 v v +---------------+ 349 +-----------------+ 350 | RFC3484 Default | 351 | Policy Table | 352 +-----------------+ 353 | 354 v 355 +-----------------------------+ 356 | RFC 3484 Policy Table | 357 +-----------------------------+ 359 In the figure above, Network-1 and Network-2 provide both destination 360 address selection poilcies and source address selection policies. 361 The policy receiver should keep the received policies as they are in 362 policy pools. Also, the default policy table define in RFC 3484 has 363 to be kept. 365 The conflicts in policy pools can be solved by looking up the routing 366 table by the process of Section 3. The outputs from this process are 367 injected into the RFC 3484 default policy table so that the injecting 368 policies should least change the effects of the default policy. 370 This process should be performed every time the received policy 371 changes. This is because the change cannot alway be made 372 incrementally. 374 In the sub-sections below, the detailed merging process are 375 described. The merging process begins with the merging of source 376 address selection policies. The merging of destination address 377 policies comes after that. And it ends with adjustment of the 378 inserted entries' precedence and label values in accordance with the 379 default policy table. 381 4.2. Example of Address Selection Policy Merging 383 ::ffff:0:0/96 384 ::/0 -----+ 385 | \ 386 | \ 387 +-----+-----+ +--+--------+ 388 | Network-1 | | Network-2 +---- fd00:2::/48 389 +------+----+ +-----+-----+ 390 \ / 391 \ / 392 2001:db8:1::/64 \ / 2001:db8:2::/64 393 +---+----+---+ 394 | Host | 395 +------------+ 397 4.2.1. Processing Source Address Selection Policy 399 The two ISPs, Network-1 and Network-2, provide the source address 400 selection policy below, 402 Network-1 "if dst ::/0, then src 2001:db8:1::/64" 403 Network-2 "if dst ::/0 or fd00:2::/48, then src 2001:db8:2::/64" 405 and the Host's routing table looks like below, 407 Prefix Nexthop 408 ::/0 Network-1 409 fd00:2::/48 Network-2 411 As mentioned in the previous section, the policy that came from the 412 selected entity in the routing table should be selected in the policy 413 table also. In this case, the routing table selected Network-1 for 414 the nexthop for the prefix ::/0, so the Network-1's policy should be 415 selected in the policy table. 417 Prefix Precedence Label 418 ::/0 ? 1 419 2001:db8:1::/64 ? 1 420 fd00:2::/48 ? 5 421 2001:db8:2::/64 ? 5 423 Next comes the merging with the default policy table, which is pasted 424 below from the RFC 3484, 426 Prefix Precedence Label 427 ::1/128 50 0 428 ::/0 40 1 429 2002::/16 30 2 430 ::/96 20 3 431 ::ffff:0:0/96 10 4 433 We can have the following merged table. 435 Prefix Precedence Label 436 ::1/128 50 0 437 ::/0 40 1 438 *S 2001:db8:1::/64 ? 1 439 *S fd00:2::/48 ? 5 440 *S 2001:db8:2::/64 ? 5 441 2002::/16 30 2 442 ::/96 20 3 443 ::ffff:0:0/96 10 4 445 There are unresolved values in the table, which should be resolved in 446 accordance with other policies below. 448 4.2.2. Processing Destination Address Selection Policy 450 The above mentioned two ISPs, Network-1 and Network-2, also want to 451 provide the destination address selection policy below, 453 Network-1 "::/0 Precedence 20, ::ffff:0:0/96 Precedence 10" 454 Network-2 "::/0 Precedence 30, ::ffff:0:0/96 Precedence 40" 455 and the routing table of the Host is like below. 457 Prefix Nexthop 458 ::/0 Network-1 459 ::ffff:0:0/96 Network-2 460 fd00:2::/48 Network-2 462 Here, the merging process selects the Precedence value of the policy 463 that is selected in the routing table. That is, the routing table 464 above selects Network-1 for the prefix ::/0, so the Precedence value 465 for the prefix ::/0 should be the value of the Network-1's policy. 466 The resulf of this merging process is below. 468 Prefix Precedence Label 469 ::/0 20 ? 470 ::ffff:0:0/96 40 ? 472 Next comes the merging with the policy table that is merged with the 473 source address selection policy. 475 Prefix Precedence Label 476 ::1/128 50 0 477 *D ::/0 20 1 478 *S 2001:db8:1::/64 ? 1 479 *S fd00:2::/48 ? 5 480 *S 2001:db8:2::/64 ? 5 481 2002::/16 30 2 482 ::/96 20 3 483 *D ::ffff:0:0/96 40 4 485 4.2.3. Precedence and Label Values Adjustment 487 Regarding the unresolved value in the previous unfinished policy 488 table, the merging process should choose the most harmless Precedence 489 value. That means, the Precedence value that does not spoil or 490 change the other policy table entries' effects. 492 The process should find a prefix that best includes or matches the 493 prefix with the unresolved value in this policy table, and use the 494 Precedence value of the selected prefix. In this example, the prefix 495 2001:db8:1::/64 longestly matches with the existing prefix ::/0, so 496 the Precedence value 20 was used for the merged entries. The same 497 value goes to the entries with 2001:db8:2::/64 and fd00:2::/48. 499 Prefix Precedence Label 500 ::1/128 50 0 501 *D ::/0 20 1 502 *S 2001:db8:1::/64 20 1 503 *S fd00:2::/48 20 5 504 *S 2001:db8:2::/64 20 5 505 2002::/16 30 2 506 ::/96 20 3 507 *D ::ffff:0:0/96 40 4 509 Though not ducumented in this example, almost the same process as the 510 Precedence value adjustment should be applied to the Label value. 511 That is, the merging process should choose the most harmless Label 512 value, which does not spoil or change the other policy table entries' 513 effects. Hense, it should use the same Label value as the existing 514 entry that longestly matches the prefix of the unresolved Label 515 value. 517 5. Discussion 519 In this document, we examined and classified address selection 520 policies. For each kind, we proposed how to solve the merging 521 conflicting policies. 523 As documented here, the merging process has close relationship with 524 the routing table. It should be noted that the address selection 525 policy distribution has to be considered and used along with the 526 routing mechanism. 528 6. IANA Considerations 530 This document has no actions for IANA. 532 7. Security Considerations 534 TBD 536 8. Acknowledgements 538 Dave Thaler and Aleksi Suhonen has given invaluable advice and 539 feedback on this document. 541 9. References 542 9.1. Normative References 544 [I-D.fujisaki-dhc-addr-select-opt] 545 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 546 Address Selection Policy using DHCPv6", 547 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 548 March 2010. 550 [RFC3484] Draves, R., "Default Address Selection for Internet 551 Protocol version 6 (IPv6)", RFC 3484, February 2003. 553 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 554 "Problem Statement for Default Address Selection in Multi- 555 Prefix Environments: Operational Issues of RFC 3484 556 Default Rules", RFC 5220, July 2008. 558 9.2. Informative References 560 [I-D.ietf-6man-addr-select-considerations] 561 Chown, T., "Considerations for IPv6 Address Selection 562 Policy Changes", 563 draft-ietf-6man-addr-select-considerations-00 (work in 564 progress), October 2009. 566 Appendix A. Revision History 568 02: 569 The document structure was changed. 570 Detailed the whole picture of merging process implementation in 571 Section 4. 572 Documented how the source address policy merging and destination 573 address policy merging interacts in Section 4. 575 01: 576 The section 4 was made clearer. 577 The section 5 "Conceptual processing model" was added. 578 The section "Conclusions" was renamed to "Discussion". 580 Authors' Addresses 582 Arifumi Matsumoto 583 NTT PF Lab 584 Midori-Cho 3-9-11 585 Musashino-shi, Tokyo 180-8585 586 Japan 588 Phone: +81 422 59 3334 589 Email: arifumi@nttv6.net 591 Tomohiro Fujisaki 592 NTT PF Lab 593 Midori-Cho 3-9-11 594 Musashino-shi, Tokyo 180-8585 595 Japan 597 Phone: +81 422 59 7351 598 Email: fujisaki@syce.net 600 Ruri Hiromi 601 Intec Netcore, Inc. 602 Shinsuna 1-3-3 603 Koto-ku, Tokyo 136-0075 604 Japan 606 Phone: +81 3 5665 5069 607 Email: hiromi@inetcore.com