idnits 2.17.1 draft-arifumi-6man-addr-select-conflict-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- == There are 1 instance 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 IETF Trust and authors Copyright Line does not match the current year == Line 224 has weird spacing: '... bad bad...' == Line 372 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 (October 24, 2009) is 5297 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 (-09) exists of draft-fujisaki-dhc-addr-select-opt-08 == Outdated reference: A later version (-05) exists of draft-ietf-6man-addr-select-considerations-00 Summary: 2 errors (**), 0 flaws (~~), 7 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: April 27, 2010 R. Hiromi 6 Intec Netcore 7 October 24, 2009 9 Considerations of address selection policy conflicts 10 draft-arifumi-6man-addr-select-conflict-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 27, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document tries to speculate how policy conflicts happen, and how 59 to address the conflicts. After making it clear what kind of address 60 selection policy should be necessary, we proposed how to merge the 61 possibily conflicting policies for each of the destination address 62 selection policy and source address selection policy. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Address Selection Control . . . . . . . . . . . . . . . . . . 3 68 3. Source Address Selection Conflicts and Solution . . . . . . . 4 69 4. Destination Address Selection Conflicts and Solution . . . . . 5 70 5. Cenceptual Message Processing Model . . . . . . . . . . . . . 7 71 5.1. Source Address Selection Policy . . . . . . . . . . . . . 7 72 5.2. Destination Address Selection Policy . . . . . . . . . . . 9 73 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 RFC 5220 [RFC5220] describes several cases that have problems caused 86 by using multiple prefixes at hosts and sites. The address selection 87 design team is working on this issue and summarizes their work in the 88 considerations document [I-D.ietf-6man-addr-select-considerations]. 89 Their solution mechanism is going to be an update mechanism of the 90 address selection policy table at a host from the network. A new 91 DHCPv6 option [I-D.fujisaki-dhc-addr-select-opt] is proposed for this 92 purpose. 94 As mentioned in RFC 5220 [RFC5220], a host and a site can belong to 95 multiple upstream networks. For example, a host with multiple 96 interfaces, such as wireless and wired interfaces, can easily belong 97 to multiple networks. A site may have connectivity to ISP and a 98 corporate network through a VPN link. 100 In these cases, if two or more of the upstream networks want to 101 control address selection behavior of his network's customer host, 102 those address selection policies have to be merged at the host, and 103 they may collide there. 105 This document tries to speculate how policy conflicts happen, and how 106 to address the conflicts. Moreover, this document also tries to 107 examine a mechanism for solving conflicts in the section of 108 cenceptual processing model. This document focuses on identifying 109 what kind of conflict related problems we have, and in what kind of 110 manner we can solve them. 112 Some of the problems described in RFC 5220 are specific to and 113 resulted from the address selection mechanism defined in RFC 3484. 114 [RFC3484] However, above mentioned policy collision is an intrinsic 115 problem of address selection policy merging, and not specific to the 116 RFC 3484 mechanism. 118 2. Address Selection Control 120 As in RFC 5220, there are various motivations for network 121 administrator to control address selection behavior of his customers' 122 hosts. However, we can summarize them into two following kinds of 123 controls. 125 - Source address selection behavior control: 127 "When accessing to PREFIX-1, use ADDRESS-1 as the source address." 128 A lot of ISPs have this policy and they usually implement it by 129 adopting ingress filtering to incoming packets from their 130 customers. Another case where this policy is used is a network 131 that makes use of multiple address blocks in the network and 132 assigns multiple addresses/prefixes to its customers and use them 133 for different purpose, such as the Internet access use and 134 telephone call use. 136 - Destination address selection behavior control: 138 "When accessing to PREFIX-1 or PREFIX-2, prefer PREFIX-1 rather 139 than PREFIX-2." This control is rather intended for optimization 140 of the customers' traffic. This kind of control is not intended 141 for on-off switch, but rather a preference degree. For example, 142 this is useful when a destination site has both PREFIX-1 and 143 PREFIX-2, and the network administrator knows connectivity to 144 PREFIX-1 is better than PREFIX-2. The typical case of this is 145 IPv4 and IPv6 prioritization as mentioned in RFC 5220. 147 On-off switch manner of control is not in scope of address 148 selection behavior, but it should be implemented some other 149 mechanism, such as routing table manipulation and DNS resolution. 151 As this is intrinsiclly intended for optimization, it should not 152 be used for any other purpose like security . 154 Here, PREFIX-* is used to denote both IPv4 and IPv6 prefixes. In the 155 following part, policy conflict and solution for these two patterns 156 above are examined separately. 158 3. Source Address Selection Conflicts and Solution 160 As mentioned above, source address selection policy have following 161 meaning: "When accessing to PREFIX-1, use ADDRESS-1 as the source 162 address." The upstream network that has this kind of policy usually 163 assigns an address block that includes ADDRESS-1, and also provides 164 reachability to the network that is specified by PREFIX-1. 166 Source address selection policy conflict can happen when different 167 network have a policy for the same prefix. For example, in the 168 following figure, Network-1 have a policy: "To PREFIX-1, use 169 ADDRESS-1", and Network-2: "To PREFIX-1 and PREFIX-2, use ADDRESS-2". 171 PREFIX-1 -----+ PREFIX-2 172 | \ | 173 | \ | 174 +-----+-----+ +-+---+-----+ 175 | Network-1 | | Network-2 | 176 +------+----+ +----+------+ 177 \ / 178 \ / 179 ADDRESS-1 \ / ADDRESS-2 180 +---+----+---+ 181 | Host/Site | 182 +------------+ 184 In this case, the solution is straightforward. The destination 185 address is determined before source address selection policy is used. 186 Thus, the outgoing route, such as the next-hop node and the network 187 interface, is determined by looking up the routing table at a host. 188 That is, the outgoing network that carries the packet to the 189 destination is determined without the source address selection 190 policy. 192 So, the bottom line is that the source address selection policy that 193 matches routing table's behavior should be chosen. There is no point 194 adopting the source address selection policy of a network where a 195 packet does not go through. 197 In other words, if the routing table is fixed before the source 198 address selection policy is fixed, then the source address selection 199 policy should be implemented while avoiding contradiction with the 200 routing table. If not, the routing table should be coordinated to 201 match the source address selection policy. 203 In a case where a site is connected to the multiple ISPs, like the 204 figure above, and receives policies from the ISPs and re-distribute 205 policies to the downstream hosts, the hosts cannot know which ISP are 206 chosen for transit to PREFIX-1. So, in this case, the entity who 207 knows which way is chosen have to address the policy conflict. 209 4. Destination Address Selection Conflicts and Solution 211 As mentioned in section 2, destination address selection policy have 212 following meaning: "When accessing to a destination site that has 213 PREFIX-1 and PREFIX-2, prefer PREFIX-1 rather than PREFIX-2." The 214 upstream network that has this kind of policy should provides 215 reachability to both networks that are specified by PREFIX-1 and 216 PREFIX-2. 218 Destination address selection policy conflict can happen when a 219 network has a policy that has inverse effect of another network's 220 policy. That is, in the figure below, Network-1 prefers PREFIX-1 221 rather than PREFIX-2, and Network-2 prefers PREFIX-2 rather than 222 PREFIX-1. 224 bad bad 225 PREFIX-1 ---- ---- PREFIX-2 226 | X | 227 good | / \ | good 228 +-----+-----+ +-----+-----+ 229 | Network-1 | | Network-2 | 230 +------+----+ +----+------+ 231 \ / 232 \ / 233 ADDRESS-1 \ / ADDRESS-2 234 +---+---+---+ 235 | Host/Site | 236 +-----------+ 238 In routing mechanism, a router advertises a route A to a certain 239 destination, another advertises a route B to the same destination, 240 and the receiver decides which route to take by looking at the cost 241 of the routes and other information. 243 In destination address selection policy, a network advertises prefix 244 A and the precedence degree. The destination address selection 245 policy conflict happens when multiple entities provide policies for 246 the same or the overlapping destination prefix with different costs. 247 This is the same situation as the routing mechanism in that there can 248 be multiple "routes" for the same destination. 250 Here, we can choose the better, that is, higher precedence "route" 251 for the destination prefix, but there is no point if the route is not 252 actually used by the routing mechainism. Even if we choose a policy 253 for prefix A provided from Network-1, a packet destined for the 254 prefix A does not always go through Network-1. This is what the 255 routing mechianism of the host or the site router decides. 257 So, we propose to adopt the policy that is provided from the network 258 the routing mechanism selected and thus a packet goes through, 259 because the routing mechanism is already there and performs routing 260 decisions by making use of the routing protocols metrics and also 261 implementation dependent information. 263 For example, Network-1 router advertises the following policy to the 264 customers: 266 to PREFIX-1, precedence 20 267 to PREFIX-2, precedence 10 269 Network-2 advertises: 270 to PREFIX-1, precedence 30 271 to PREFIX-2, precedence 40 273 And when the routing table is: 274 PREFIX-1 via Network-1 275 PREFIX-2 via Network-2 277 Then, the receiving host should have the following merged destination 278 address selection policy: 279 to PREFIX-1, precedence 20 via Network-1 280 to PREFIX-2, precedence 40 via Network-2 282 5. Cenceptual Message Processing Model 284 The merging process described here does not demand any modification 285 to the address selection mechanism defined in RFC 3484. However, the 286 policy receiver has to keep multiple sets of the received policy as 287 they are somewhere other than the policy table defined in RFC 3484. 288 Also, the default policy table define in RFC 3484 has to be kept. 290 The merging process retrieves all the above stored sets of policy, 291 processes them, and put the merged policy into the policy table. 292 This process should be performed every time the received policy 293 changes. 295 The default priority should be defined which to prioritize the 296 default policy table or the received policy, or possibly the manually 297 configured policy on the host. The priority should also be 298 configurable. 300 5.1. Source Address Selection Policy 301 ::/0 -----+ fd00:2::/48 302 | \ | 303 | \ | 304 +-----+-----+ +--+---+----+ 305 | Network-1 | | Network-2 | 306 +------+----+ +-----+-----+ 307 \ / 308 \ / 309 2001:db8:1::/64 \ / 2001:db8:2::/64 310 +---+----+---+ 311 | Host | 312 +------------+ 314 When these two ISPs, Network-1 and Network-2, provide the source 315 address selection policy below, 317 Network-1 "if dst ::/0, then src 2001:db8:1::/64" 318 Network-2 "if dst ::/0 or fd00:2::/48, then src 2001:db8:2::/64" 320 and when the Host's routing table looks like below, 322 Prefix Nexthop 323 ::/0 Network-1 324 fd00:2::/48 Network-2 326 as mentioned in the previous section, the policy that came from the 327 selected entity in the routing table should be selected in the policy 328 table also. In this case, the routing table selected Network-1 for 329 the nexthop for the prefix ::/0, so the Network-1's policy should be 330 selected in the policy table. 332 Prefix Precedence Label 333 ::/0 ? 1 334 2001:db8:1::/64 ? 1 335 fd00:2::/48 ? 5 336 2001:db8:2::/64 ? 5 338 If we consider about the merging with the default policy table, which 339 is pasted below from the RFC 3484, 341 Prefix Precedence Label 342 ::1/128 50 0 343 ::/0 40 1 344 2002::/16 30 2 345 ::/96 20 3 346 ::ffff:0:0/96 10 4 348 We can have the following merged table. 350 Prefix Precedence Label 351 ::1/128 50 0 352 ::/0 40 1 353 * 2001:db8:1::/64 40 1 354 * fd00:2::/48 40 5 355 * 2001:db8:2::/64 40 5 356 2002::/16 30 2 357 ::/96 20 3 358 ::ffff:0:0/96 10 4 360 Here, the merging process was used that chooses the most harmless 361 Precedence value. That means, the Precedence value that does not 362 spoil or change the other policy table entries' effects. 364 The process is to find a prefix that includes or overlaps with the 365 inserting entry in the default policy table, and to use the 366 Precedence value of the prefix. In this example, the prefix 2001: 367 db8:1::/64 longestly matches with the existing prefix ::/0, so the 368 Precedence value 40 was used for the merged entries. 370 5.2. Destination Address Selection Policy 372 bad bad 373 ::/0 ---- ---- ::ffff:0:0/96 374 | X | 375 good | / \ | good 376 +-----+-----+ +-----+-----+ 377 | Network-1 | | Network-2 | 378 +------+----+ +----+------+ 379 \ / 380 \ / 381 2001:db8:1::/64 \ / 2001:db8:2::/64 382 +---+---+---+ 383 | Host | 384 +-----------+ 386 When these two ISPs, Network-1 and Network-2, provide the source 387 address selection policy below, 389 Network-1 "::/0 Precedence 20, ::ffff:0:0/96 Precedence 10" 390 Network-2 "::/0 Precedence 30, ::ffff:0:0/96 Precedence 40" 391 and the routing table of the Host is like below. 393 Prefix Nexthop 394 ::/0 Network-1 395 ::ffff:0:0/96 Network-2 397 Here, the merging process selects the Precedence value of the policy 398 that is selected in the routing table. That is, the routing table 399 above selects Network-1 for the prefix ::/0, so the Precedence value 400 for the prefix ::/0 should be the value of the Network-1's policy. 401 The resulf of this merging process is below. 403 Prefix Precedence Label 404 ::/0 20 ? 405 ::ffff:0:0/96 40 ? 407 If we consider about the merging with the default policy table, 409 the merged policy table is going to be 411 Prefix Precedence Label 412 ::1/128 50 0 413 * ::/0 20 1 414 2002::/16 30 2 415 ::/96 20 3 416 * ::ffff:0:0/96 40 4 418 by adopting almost the same process as the source address policy 419 merging. That is, the merging process was used that chooses the most 420 harmless Label value. The Label value should be used that does not 421 spoil or change the other policy table entries' effects. It seems to 422 be harmless to use the same Label value as the existing entry that 423 longestly matches the inserting entry's prefix. 425 6. Discussion 427 In this document, we examined and classified address selection 428 policies. For each class, we proposed how to solve the merging 429 conflicting policies. 431 As documented here, the merging process has close relationship with 432 the routing table. It should be noted that the address selection 433 policy distribution has to be considered and used along with the 434 routing mechanism. 436 7. IANA Considerations 438 This document has no actions for IANA. 440 8. Security Considerations 442 TBD 444 9. Acknowledgements 446 Dave Thaler and Aleksi Suhonen has given invaluable advice and 447 feedback on this document. 449 10. References 451 10.1. Normative References 453 [RFC3484] Draves, R., "Default Address Selection for Internet 454 Protocol version 6 (IPv6)", RFC 3484, February 2003. 456 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 457 "Problem Statement for Default Address Selection in Multi- 458 Prefix Environments: Operational Issues of RFC 3484 459 Default Rules", RFC 5220, July 2008. 461 10.2. Informative References 463 [I-D.fujisaki-dhc-addr-select-opt] 464 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 465 Address Selection Policy using DHCPv6", 466 draft-fujisaki-dhc-addr-select-opt-08 (work in progress), 467 October 2009. 469 [I-D.ietf-6man-addr-select-considerations] 470 Chown, T., "Considerations for IPv6 Address Selection 471 Policy Changes", 472 draft-ietf-6man-addr-select-considerations-00 (work in 473 progress), October 2009. 475 Appendix A. Appendix. Revision History 477 01: 479 The section 4 was made clearer. 480 The section 5 "Conceptual processing model" was added. 481 The section "Conclusions" was renamed to "Discussion". 483 Authors' Addresses 485 Arifumi Matsumoto 486 NTT PF Lab 487 Midori-Cho 3-9-11 488 Musashino-shi, Tokyo 180-8585 489 Japan 491 Phone: +81 422 59 3334 492 Email: arifumi@nttv6.net 494 Tomohiro Fujisaki 495 NTT PF Lab 496 Midori-Cho 3-9-11 497 Musashino-shi, Tokyo 180-8585 498 Japan 500 Phone: +81 422 59 7351 501 Email: fujisaki@syce.net 503 Ruri Hiromi 504 Intec Netcore, Inc. 505 Shinsuna 1-3-3 506 Koto-ku, Tokyo 136-0075 507 Japan 509 Phone: +81 3 5665 5069 510 Email: hiromi@inetcore.com