idnits 2.17.1 draft-yu-simple-ipv6multihoming-00.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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) ** Obsolete normative reference: RFC 2546 (Obsoleted by RFC 2772) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 UUNET 3 Expires February, 2000 August, 1999 5 draft-yu-simple-ipv6multihoming-00.txt 7 A Simple Solution for IPv6 Multihoming 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 There is a challenge of providing IPv6 multihoming sites with the 38 basic benefits such as redundancy and load sharing, and at the same 39 time, scaling the global IPv6 routing table. It is equally 40 challenging to provide a solution which is simple enough to be 41 operational manageable. This document proposes a simple solution 42 which meets the requirements and is also operationally manageable. 44 1. Purpose 46 There is a challenge of providing IPv6 multihoming sites with the 47 basic benefits such as redundancy and load sharing, and at the same 48 time, scaling the global IPv6 routing table. It is equally 49 challenging to provide a solution which is simple enough to be 50 operational manageable. This document proposes a routing and 51 addressing scheme that supports IPv6 multihoming which achieves the 52 followings: 54 a. Providing redundancy and load sharing for the multi-homed sites 55 b. Scaling the global IPv6 Internet routing table 56 c. Simple and operationally manageable 58 2. Proposal 60 ISP-3 ---- ISP-4 61 | / | 62 | / | 63 | / | 64 ISP-1 ---- ISP-2 65 link-1 \ / link-2 66 Customer-A 68 A multi-homed customer will designate a primary ISP and receive IP 69 address from its primary ISP's IPv6 aggregation block. In this 70 example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A 71 to the customer. Customer-A will advertise addr-1-A to ISP-1 and 72 ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to 73 ISP-1 only. ISP-1 will, of course, advertise its own aggregation 74 Addr-1 to the entire Internet. 76 For inbound traffic to Customer-A, traffic will first be forwarded to 77 ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will 78 then forward the traffic destined to Customer-A via its connection to 79 ISP-2 and/or its direct link to customer-A, according to certain 80 polices. Most common policy would be the use of the shortest exit. By 81 using both connections to forward traffic to Customer-A, load sharing 82 is achieved. 84 For outbound traffic from Customer-A, ISP-1 and ISP-2 can announce 85 default and/or specific prefixes based on customer-A's requirements 86 and traffic originated from Customer-A will be forwarded accordingly. 88 When the link between customer-A and ISP-2 (link-2 in the figure) 89 goes down, all traffic will go in/out via the connection between 90 Customer-A and ISP-1 (link-1 in the figure). Likewise, when link-1 is 91 experiencing an outage, link-2 will be used for the traffic. This is 92 because ISP-1 will continue announce its aggregate block (i.e. Addr- 93 1) to the entire Internet and ISP-2 will still advertise Addr-1-A to 94 ISP-1, all the inbound traffic to the customer will be take the path: 95 ISP-1 -> ISP-2 -> Customer-A. Outbound traffic will automatically 96 fall to link-2. This way, redundancy is achieved. 98 Same mechanism can be extended to those sites multihoming to more 99 than two ISPs. Only those ISPs that the customer directly connected 100 to would carry the more specific prefix assigned to the multi-homed 101 customer. 103 The more specific prefix announcement could be covered under the 104 peering agreement between ISPs as stated in [RFC2546]. 106 3. Advantages of the proposal 108 - Achieves the goal of scaling the global routing table. 110 - It scales the global routing table. Only ISPs involved in the 111 multihoming attachment need to know the more specific route of 112 Addr-1. Other ISPs such as ISP-3 and ISP-4 in figure 1 do not need 113 to know specifics. 115 If the two involved ISPs has no direct connection, the more 116 specific route would need to be carried by other ISPs in the path. 117 This seems to be lesser a problem since ISP assigned with an 118 Internet visible aggregate block usually has direct connection to 119 each other. 121 - It is really simple and thus more manageable and scalable 122 operation wise. It does not require multiple addresses assigned 123 all individual hosts of a multi-homed customer site, neither it 124 requires O(N^2) tunnels among different ISP routers. 126 4. Concerns 128 - The primary ISP of a multihoming customer (such as ISP-1 in the 129 example) would need to do more work in terms of distributing the 130 traffic among other connected ISPs and the customer link. This 131 can be done using BGP policy (BGP community) and using shortest 132 exit. It will also carry more traffic for the customer. However, 133 this is a value added service to the customer and the primary ISP 134 can charge more fees for such services. 136 - The primary ISP is the sole interface for the multihomed 137 customer to the Internet other than the ISPs the customer has 138 directly connection with. Outages such as one between ISP-1 and 139 ISP-4 would impact the reachability from customers of ISP-4 to 140 Customer-A even though ISP-2 still has good connection to ISP-4. 141 However, if the primary ISP is a good quality ISP, this sort of 142 situation should happen rarely. The reason is that it's common 143 practice that an ISP, especially good quality ISP, has multiple 144 connections to other big ISPs at different geographical locations. 145 Good quality ISPs also have robust network design to prevent any 146 failure to impact the whole network. Choosing a good quality and 147 robust ISP as primary ISP is a good practice. 149 It is desirable to have solution which provides perfect redundancy 150 and, at the same time, simplicity to scale management and operation. 151 In the absence of a perfect solution, the trade-off needs to be made. 152 The author believes that it is very important that the solution has 153 to be simple and manageable. Manageability should be the top 154 consideration. 156 5. Security Considerations 158 Security considerations are out of scope of this document. 160 6. References 162 [RFC2546] A. Durand and B. Buclin, "6Bone Routing Practice." 163 RFC2546, March 1999.ftp://ftp.isi.edu/in-notes/rfc2546.txt. 165 Author's Address 167 Jieyun (Jessica) Yu 168 UUNET Technology 169 880 Technology Dr. 170 Ann Arbor, MI 48108 172 Phone: (734) 214-7314 174 EMail: jyy@uu.net 176 ------- End of Forwarded Message