idnits 2.17.1 draft-arifumi-6man-addr-select-conflict-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 202 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 (July 6, 2009) is 5380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 3 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: January 3, 2010 R. Hiromi 6 Intec Netcore 7 July 6, 2009 9 Considerations of address selection policy conflicts 10 draft-arifumi-6man-addr-select-conflict-00.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 January 3, 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 classifying address selection 60 policies, we proposed how to solve the merging conflicting policies 61 for each classes. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Address Selection Control . . . . . . . . . . . . . . . . . . . 3 67 3. Source Address Selection Conflicts and Solution . . . . . . . . 4 68 4. Destination Address Selection Conflicts and Solution . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 As mentioned in RFC 5220 [RFC5220], a host and a site can belong to 80 multiple upstream networks. For example, a host with multiple 81 interfaces, such as wireless and wired interfaces, can easily belong 82 to multiple networks. A site may have connectivity to ISP and a 83 corporate network through a VPN link. 85 In these cases, if two or more of the upstream networks want to 86 control address selection behavior of his network's customer host, 87 those address selection policies have to be merged at the host, and 88 they may collide there. 90 Some of the problems described in RFC 5220 are specific to and 91 resulted from the address selection mechanism defined in RFC 3484. 92 [RFC3484] However, above mentioned policy collision is an intrinsic 93 problem of address selection policy merging, and not specific to the 94 RFC 3484 mechanism. 96 This document tries to speculate how policy conflicts happen, and how 97 to address the conflicts. However, this document does not aim to 98 examine a concrete mechanism for solving conflicts, nor assume the 99 address selection mechanism defined in RFC 3484. [RFC3484] This 100 document focuses on identifying what kind of conflict related 101 problems we have, and in what kind of manner we can solve them. 103 2. Address Selection Control 105 As in RFC 5220, there are various motivations for network 106 administrator to control address selection behavior of his customers' 107 hosts. However, we can summarize them into two following kinds of 108 controls. 110 - Source address selection behavior control: 112 "When accessing to PREFIX-1, use ADDRESS-1 as the source address." 113 A lot of ISPs have this policy and they usually implement it by 114 adopting ingress filtering to incoming packets from their 115 customers. Another case where this policy is used is a network 116 that makes use of multiple address blocks in the network and 117 assigns multiple addresses/prefixes to its customers and use them 118 for different purpose, such as the Internet access use and 119 telephone call use. 121 - Destination address selection behavior control: 123 "When accessing to PREFIX-1 or PREFIX-2, prefer PREFIX-1 rather 124 than PREFIX-2." This control is rather intended for optimization 125 of the customers' traffic. This kind of control is not intended 126 for on-off switch, but rather a preference degree. For example, 127 this is useful when a destination site has both PREFIX-1 and 128 PREFIX-2, and the network administrator knows connectivity to 129 PREFIX-1 is better than PREFIX-2. The typical case of this is 130 IPv4 and IPv6 prioritization as mentioned in RFC 5220. 132 On-off switch manner of control is not in scope of address 133 selection behavior, but it should be implemented some other 134 mechanism, such as routing table manipulation and DNS resolution. 136 As this is intrinsiclly intended for optimization, it should not 137 be used for any other purpose like security . 139 Here, PREFIX-* is used to denote both IPv4 and IPv6 prefixes. In the 140 following part, policy conflict and solution for these two patterns 141 above are examined separately. 143 3. Source Address Selection Conflicts and Solution 145 As mentioned above, source address selection policy have following 146 meaning: "When accessing to PREFIX-1, use ADDRESS-1 as the source 147 address." The upstream network that has this kind of policy usually 148 assigns an address block that includes ADDRESS-1, and also provides 149 reachability to the network that is specified by PREFIX-1. 151 Source address selection policy conflict can happen when different 152 network have a policy for the same prefix. For example, in the 153 following figure, Network-1 have a policy: "To PREFIX-1, use 154 ADDRESS-1", and Network-2: "To PREFIX-1 and PREFIX-2, use ADDRESS-2". 156 PREFIX-1 -----+ PREFIX-2 157 | \ | 158 | \ | 159 +-----+-----+ +-+---+-----+ 160 | Network-1 | | Network-2 | 161 +------+----+ +----+------+ 162 \ / 163 \ / 164 ADDRESS-1 \ / ADDRESS-2 165 +---+----+---+ 166 | Host/Site | 167 +------------+ 169 In this case, the solution is straightforward. The destination 170 address is determined before source address selection policy is used. 171 Thus, the outgoing route, such as the next-hop node and the network 172 interface, is determined by looking up the routing table at a host. 173 That is, the outgoing network that carries the packet to the 174 destination is fixed without source address selection policy. 176 So, the bottom line is that the source address selection policy that 177 matches routing table's behavior should be chosen. There is no point 178 adopting the source address selection policy of a network where a 179 packet does not go through. 181 In other words, if the routing table is fixed before the source 182 address selection policy, then the source address selection policy 183 should be implemented avoiding contradiction with the routing table. 184 If not, the routing table should be coordinated to match the source 185 address selection policy. 187 4. Destination Address Selection Conflicts and Solution 189 As mentioned in section 2, destination address selection policy have 190 following meaning: "When accessing to a destination site that has 191 PREFIX-1 and PREFIX-2, prefer PREFIX-1 rather than PREFIX-2." The 192 upstream network that has this kind of policy should provides 193 reachability to both networks that are specified by PREFIX-1 and 194 PREFIX-2. 196 Destination address selection policy conflict can happen when a 197 network has a policy that has inverse effect of another network's 198 policy. That is, in the figure below, Network-1 prefers PREFIX-1 199 rather than PREFIX-2, and Network-2 prefers PREFIX-2 rather than 200 PREFIX-1. 202 bad bad 203 PREFIX-1 ---- ---- PREFIX-2 204 | X | 205 good | / \ | good 206 +-----+-----+ +-----+-----+ 207 | Network-1 | | Network-2 | 208 +------+----+ +----+------+ 209 \ / 210 \ / 211 ADDRESS-1 \ / ADDRESS-2 212 +---+---+---+ 213 | Host/Site | 214 +-----------+ 216 This problem is very similar to routing protocol's route selection. 217 In any routing protocols, a router advertises a route with the cost, 218 in the form of AS path length or metric, that have to be paid when 219 accessing to the route via the router. 221 In routing protocols, for example, Network-1 router advertises the 222 following routes to customers: 223 to PREFIX-1, cost 10 via Network-1 224 to PREFIX-2, cost 20 via Network-1 226 Network-2 advertises: 227 to PREFIX-1, cost 20 via Network-2 228 to PREFIX-2, cost 10 via Network-2 230 Then, the receiving host will have the following merged routing 231 table: 232 to PREFIX-1, cost 10 via Network-1 233 to PREFIX-2, cost 10 via Network-2 235 Going back to address selection, almost the same goes for it. That 236 is, in address selection, a network advertises prefixes A, B to reach 237 a destination FQDN, and each prefix has a cost. 239 For example, Network-1 router advertises the following policy to the 240 customers: 241 to PREFIX-1, cost 10 242 to PREFIX-2, cost 20 244 Network-2 advertises: 245 to PREFIX-1, cost 20 246 to PREFIX-2, cost 10 248 Then, the receiving host should have the following merged address 249 selection policy: 250 to PREFIX-1, cost 10 via Network-1 251 to PREFIX-2, cost 10 via Network-2 253 Here, it should be noted that the resulting address selection policy 254 is combined with routing table nature. It does not mean that the 255 database schema for address selection policy has to be extended, but 256 that address selection policy has to be coordinated with routing 257 table when merging these kind of policies. 259 5. IANA Considerations 261 This document has no actions for IANA. 263 6. Security Considerations 265 TBD 267 7. Conclusions 269 In this document, we examined and classified address selection 270 policies. For each class, we proposed how to solve the merging 271 conflicting policies. 273 8. References 275 8.1. Normative References 277 [RFC3484] Draves, R., "Default Address Selection for Internet 278 Protocol version 6 (IPv6)", RFC 3484, February 2003. 280 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 281 "Problem Statement for Default Address Selection in Multi- 282 Prefix Environments: Operational Issues of RFC 3484 283 Default Rules", RFC 5220, July 2008. 285 8.2. Informative References 287 Authors' Addresses 289 Arifumi Matsumoto 290 NTT PF Lab 291 Midori-Cho 3-9-11 292 Musashino-shi, Tokyo 180-8585 293 Japan 295 Phone: +81 422 59 3334 296 Email: arifumi@nttv6.net 298 Tomohiro Fujisaki 299 NTT PF Lab 300 Midori-Cho 3-9-11 301 Musashino-shi, Tokyo 180-8585 302 Japan 304 Phone: +81 422 59 7351 305 Email: fujisaki@syce.net 306 Ruri Hiromi 307 Intec Netcore, Inc. 308 Shinsuna 1-3-3 309 Koto-ku, Tokyo 136-0075 310 Japan 312 Phone: +81 3 5665 5069 313 Email: hiromi@inetcore.com