idnits 2.17.1 draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 291 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jieyun (Jessica) Yu 2 INTERNET DRAFT CoSine Communications 3 Expires February, 2001 August, 2000 5 IPv6 Multihoming with Route Aggregation 6 draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 24 Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 With the growing requirements for reliable Internet connectivity, 36 increasing number of enterprises choose to acquire Internet 37 connectivity from more than one Internet Service Providers (ISPs) for 38 the purpose of connectivity redundancy and traffic load distribution. 40 The potential of large number of multi-connection sites impose direct 41 challenge on routing aggregation and consequently on scalability of 42 the global Internet routing. Hence a solution is highly desirable 43 which provides the benefit of multi-connection as well as the better 44 scalability of the global routing system. In addition, such solution 45 needs to be simple enough to be operationally manageable. With the 46 fast growth of ISP networks as well as enterprise networks, network 47 manageability is becoming an increasingly important requirement. This 48 document describes a solution which achieves the stated goals. 50 1. Motivations 52 With the growing requirements for reliable Internet connectivity, 53 increasing number of enterprises choose to acquire Internet 54 connectivity from more than one Internet Service Providers (ISPs) for 55 the purpose of connectivity redundancy and traffic load distribution. 57 This type of Internet connection arrangement is referred to as 58 multihoming and such enterprise network is referred to as multi-homed 59 site. 61 Large numbers of Multi-homed sites impose a direct challenge on 62 routing aggregation and consequently on global Internet routing 63 scalability. As is well known, the keys to scaling of huge global 64 Internet routing system including routing information abstraction and 65 aggregation. The IPv6 unicast address format described in [1] enables 66 the strategy of allocating a large block of IPv6 address space to a 67 service provider and letting the service provider further assign 68 sub-blocks of the IP addresses to its customers. This provider based 69 IP address assignment strategy makes it possible for route 70 aggregation at the provider level and thus facilitates the scaling of 71 the global Internet routing system. 73 However, the current common mechanism to route to a multi-homed site 74 is to make the route specifically associated with the site visible in 75 the global Internet routing system. This practice prevents route 76 aggregation at the provider level and imposes challenge to a scalable 77 global routing. Therefore, a solution is needed for IPv6 multihoming 78 which provides the desired benefits of a multihoming connection such 79 as redundancy and load sharing, and at the same time, enables better 80 scaling of the global global routing system. In addition, such a 81 solution needs to be simple enough to be operationally manageable. 82 With the fast growth of ISP networks as well as enterprise networks, 83 network manageability is becoming an increasingly important 84 requirement. In today's Internet, manageability of a solution should 85 be one of the top considerations. 87 This document describes a scheme that supports IPv6 multihoming and 88 also achieves the followings: 90 a. Providing redundancy and load sharing for the multi-homed sites 92 b. Facilitating the scalability of the global IPv6 Internet 93 routing table 95 c. Simple and operationally manageable 97 This mechanism is a routing approach for multihoming. It uses 98 existing routing protocol and implementation thus no new protocol or 99 changes are needed. 101 The mechanism described in this document can also be applied to IPv4 102 Internet. 104 2. The Multihoming Mechanism 106 Multihoming connections in general can be categorized into two 107 different types: a) a site multi-homed to a single ISP, commonly at 108 different geography locations and b) a site multi-homed to more than 109 one ISPs. 111 In scenario a), the specific routes associated with the multihomed 112 site will not be visible outside of the particular ISP network and 113 thus there is no real impact on the global routing. Therefore, no 114 special mechanism is needed for multihoming in this scenario. The 115 mechanism described in this document addresses the situation of a 116 multi-homed site connects to more than one ISPs. 118 The mechanism is described with an example of a multi-homed site with 119 two ISPs connections since two-connection multihoming represents the 120 majority of the multihoming cases and it simplifies the discussion. 121 The mechanism, however, can be extended to apply to multi-homed sites 122 with more than two ISP connections. 124 2.1. Address Assignment 126 To obtain IP addresses, a multi-homed site will designate one of its 127 ISPs as its primary ISP and receive IP address assignment from the 128 primary ISP's IPv6 aggregation block. 130 Figure-1 illustrates an example of a multi-homed site (Customer-A) 131 with connectivity to ISP-1 and ISP-2. ISP-1 is chosen as the primary 132 ISP for customer-A and assigns Addr-1-A from its address block 133 (Addr-1) to the customer. 135 ISP-3 ---- ISP-4 136 | / | 137 | / | 138 | / | 139 ISP-1 ---- ISP-2 140 \ / 141 link-1 \ / link-2 142 Customer-A 144 Figure 1: Example of Multihomed Site 146 2.2. Routing 148 In order for Internet traffic destinated to Customer-A to reach the 149 targeted destinations, Customer-A will advertise addr-1-A to ISP-1 150 and ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to 151 ISP-1 only. ISP-1 will, of course, advertise its own aggregation 152 Addr-1 to the entire Internet. 154 As a result of this routing advertisement, inbound traffic destinated 155 to Customer-A and originating within ISP-1 or ISP-2 will be forwarded 156 to Customer-A using link-1 or link-2 respectively. Traffic originated 157 from anywhere else in the Internet will first be forwarded to ISP-1 158 since it advertises the route to Addr-1 which contains Addr-1-A. 159 ISP-1 will then forward the traffic destined to Customer-A via its 160 connection(s) to ISP-2 and/or via its direct link to customer-A, 161 according to the preset routing polices. The commonly used policy is 162 to use the shortest exit by utilizing IGP metric as a tier break in 163 BGP route selection process. By using both connections to forward 164 traffic to Customer-A, load sharing among the multiple links used by 165 Customer-A for connecting to the Internet is achieved. 167 For outbound traffic originated from Customer-A, ISP-1 and ISP-2 168 would announce default route and/or a selected set of specific 169 prefixes to Customer-A based on the requirements of Customer-A. As a 170 result of the advertisement, traffic originated from Customer-A to 171 the Internet will be forwarded accordingly and load sharing can be 172 accomplished. 174 In the aspect of redundancy, when the link between customer-A and 175 ISP-2 (link-2 in Figure 1) fails, all traffic will go in and out via 176 the connection between Customer-A and ISP-1 (i.e. via link-1 as shown 177 in Figure 1). Likewise, when link-1 is experiencing an outage, link-2 178 will be used for transmitting the traffic. This is because ISP-1 will 179 continue announcing its aggregate block Addr-1 to the entire Internet 180 and ISP-2 will still advertise Addr-1-A to ISP-1. All of the inbound 181 traffic to the customer will utilize link-2 by taking the path of 182 ISP-1 -> ISP-2 -> Customer-A. Outbound traffic from Customer-A will 183 automatically fall to link-2. This way, when one of the two links 184 fails, the other will be used for traffic in and out from the multi- 185 homed site. Redundancy is thus accomplished. 187 As one would observe, with this mechanism, the specific route 188 associated with the multi-homed site is only visible to ISP-1 and 189 ISP-2 in the example. Only the multi-homed sites directly connected 190 ISPs, not the rest of the Internet will have to obtain the specific 191 route(s) associated with a multi-homed site. This results in better 192 scaling of the global Internet routing. 194 The same mechanism can be extended to sites multihoming to more than 195 two ISPs. Again, only those ISPs that the customer directly connected 196 to would carry the more specific prefix assigned to the multi-homed 197 customer. 199 3. Discussions 201 Characteristics of a multihoming mechanism described in this document 202 include: 204 - Improved scaling of the global routing system without loosing 205 the benefits expected from multihoming. 207 - Does not require new protocol or routing software changes to 208 deploy the scheme. 210 - Simple and thus manageable. In addition, operationally, it has 211 less chances of generating errors compared to more complicated 212 solutions. 214 - Due to its simpleness, the requirement of having sophisticated 215 network administrator onsite is greatly reduced, which can be an 216 attractive choice for a variety of multi-homed sites. 218 - The primary ISP of a multi-homed site such as ISP-1 in Figure-1 219 would need to do more work in terms of distributing traffic among 220 the other ISP the multi-homed site directly connect to and its 221 direct link to the site. It will also carry more traffic for the 222 multi-homed customer. However, this can be considered as a value 223 added service from the ISP to the customer and the primary ISP 224 could charge for such services accordingly. 226 - If the two involved ISPs has no direct connection, the more 227 specific route associated with the multi-homed site would need to 228 be carried by other ISP(s) in the path thus it would result in 229 less effective aggregation. However, it seems to be lesser of a 230 problem since ISP assigned with an Internet visible aggregate 231 block or Top Level Aggregator (TLA) usually are top tiered ISPs 232 and all such ISPs generally have direct connections to each other 233 either via private peering or public peering points. 235 - The primary ISP is the sole interface for the multi-homed 236 customer to the Internet with the exception of the ISPs the 237 customer has direct connection with. Outages such as one between 238 ISP-1 and ISP-4 in Figure-1 would impact the reachability from 239 customers of ISP-4 to Customer-A even though ISP-2 still has good 240 connection to ISP-4. 242 However, if the primary ISP is a good quality ISP, this sort of 243 situation should rarely happen. It's common practice that an ISP, 244 especially a good quality one, to have multiple connections to other 245 big ISPs at different geographical locations. Good quality ISPs also 246 have robust internal network design to prevent any failure from 247 impacting the entire network. Choosing a good quality ISP as primary 248 ISP is a good practice for multi-homed sites adopting this solution. 250 4. Conclusions 252 It wouldn't be hard to understand that even those enterprises 253 desiring multiple Internet connections may have different criteria 254 and resource constraints for implementing such connection. Some may 255 require absolute redundancy while most may only desire reasonable 256 redundancy. This document offers a viable multihoming solution for an 257 enterprise to choose based on its particular requirements and 258 constraints. The multihoming mechanism described in this document is 259 applicable to various multihoming scenarios, the most suitable 260 environment for deploying it are: 262 a. ISPs serving the multi-homed site have direct connection(s) to 263 each other. Although such direct connection is not required, it 264 would make arrangement simpler and will also improve aggregation 265 by limiting specific routes visible only to ISPs serving the 266 multi-homed site. 268 b. Enterprises with requirements for good redundancy but not 269 absolute redundancy. 271 c. Enterprises with limited to resource for onsite sophisticated 272 network administrators 274 d. Enterprises able to choose a robust ISP as primary provider. 276 Although not the main focus, the mechanism described in this document 277 can also be used to improve routing scalability within networks 278 shares one aggregation block or Top Level Aggregator (TLA). 280 5. Security Considerations 282 BGP security applies to the work presented. No added security risk is 283 known. 285 6. Acknowledgements 286 Many thanks to Guy Davis, Robert J. Rockell and Akira Kato for their 287 insightful comments. 289 7. Reference 291 [1] R. Hinden, M. O'Dell and S. Deering, "An IPv6 Aggregatable Global 292 Unicast Address Format." RFC2374, July 1998. ftp://ftp.isi.edu/in- 293 notes/rfc2374.txt 295 8. Author's Address 297 Jieyun (Jessica) Yu 298 CoSine Communications 299 1200 Bridge Parkway 300 Redwood City, CA 94065 302 Email: jyy@cosinecom.com