idnits 2.17.1 draft-rfced-info-bates-multihoming-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 260 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: 'RFC1918' is defined on line 454, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1773 (ref. 'GRE') ** Downref: Normative reference to an Historic RFC: RFC 1518 Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES JUNE 1998 INTERNET DRAFT 3 Network Working Group Tony Bates 4 Internet Draft Cisco Systems 5 Expiration Date: June 1998 Yakov Rekhter 6 Cisco Systems 8 Scalable support for multi-homed multi-provider connectivity 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To learn the current status of any Internet-Draft, please check 25 the "1id-abstracts.txt" listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. 32 2. Abstract 34 This document describes addressing and routing strategies for multi- 35 homed enterprises attached to multiple Internet Service Providers 36 (ISPs) that are intended to reduce the routing overhead due to these 37 enterprises in the global Internet routing system. 39 3. Motivations 41 An enterprise may acquire its Internet connectivity from more than 42 one Internet Service Provider (ISP) for some of the following rea- 43 sons. Maintaining connectivity via more than one ISP could be viewed 44 as a way to make connectivity to the Internet more reliable. This way 45 when connectivity through one of the ISPs fails, connectivity via the 46 other ISP(s) would enable the enterprise to preserve its connectivity 47 to the Internet. In addition to providing more reliable connectivity, 48 maintaining connectivity via more than one ISP could also allow the 49 enterprise to distribute load among multiple connections. For enter- 50 prises that span wide geographical area this could also enable better 51 (more optimal) routing. 53 The above considerations, combined with the decreasing prices for the 54 Internet connectivity, motivate more and more enterprises to become 55 multi-homed to multiple ISPs. At the same time, the routing overhead 56 that such enterprises impose on the Internet routing system becomes 57 more and more significant. Scaling the Internet, and being able to 58 support a growing number of such enterprises demands mechanism(s) to 59 contain this overhead. This document assumes that an approach where 60 routers in the "default-free" zone of the Internet would be required 61 to maintain a route for every multi-homed enterprise that is con- 62 nected to multiple ISPs does not provide an adequate scaling. More- 63 over, given the nature of the Internet, this document assumes that 64 any approach to handle routing for such enterprises should minimize 65 the amount of coordination among ISPs, and especially the ISPs that 66 are not directly connected to these enterprises. 68 There is a difference of opinions on whether the driving factors 69 behind multi-homing to multiple ISPs could be adequately addressed by 70 multi-homing just to a single ISP, which would in turn eliminate the 71 negative impact of multi-homing on the Internet routing system. Dis- 72 cussion of this topic is beyond the scope of this document. 74 The focus of this document is on the routing and addressing strate- 75 gies that could reduce the routing overhead due to multi-homed enter- 76 prises connected to multiple ISPs in the Internet routing system. 78 The strategies described in this document are equally applicable to 79 both IPv4 and IPv6. 81 4. Address allocation and assignment 83 A multi-homed enterprise connected to a set of ISPs would be allo- 84 cated a block of addresses (address prefix) by each of these ISPs (an 85 enterprise connected to N ISPs would get N different blocks). The 86 address allocation from the ISPs to the enterprise would be based on 87 the "address-lending" policy [RFC2008]. The allocated addresses then 88 would be used for address assignment within the enterprise. 90 One possible address assignment plan that the enterprise could employ 91 is to use the topological proximity of a node (host) to a particular 92 ISP (to the interconnect between the enterprise and the ISP) as a 93 criteria for selecting which of the address prefixes to use for 94 address assignment to the node. A particular node (host) may be 95 assigned address(es) out of a single prefix, or may have addresses 96 from different prefixes. 98 5. Routing information exchange 100 The issue of routing information exchange between an enterprise and 101 its ISPs is decomposed into the following components: 103 a) reachability information that an enterprise border router 104 advertises to a border router within an ISP 106 b) reachability information that a border router within an ISP 107 advertises to an enterprise border router 109 The primary focus of this document is on (a); (b) is covered only as 110 needed by this document. 112 5.1. Advertising reachability information by enterprise border routers 114 When an enterprise border router connected to a particular ISP deter- 115 mines that the connectivity between the enterprise and the Internet 116 is up through all of its ISPs, the router advertises (to the border 117 router of that ISP) reachability to only the address prefix that the 118 ISP allocated to the enterprise. This way in a steady state routes 119 injected by the enterprise into its ISPs are aggregated by these 120 ISPs, and are not propagated into the "default-free" zone of the 121 Internet. 123 When an enterprise border router connected to a particular ISP deter- 124 mines that the connectivity between the enterprise and the Internet 125 through one or more of its other ISPs is down, the router starts 126 advertising reachability to the address prefixes that was allocated 127 by these ISPs to the enterprise. This would result in injecting addi- 128 tional routing information into the "default-free" zone of the Inter- 129 net. However, one could observe that the probability of all multi- 130 homed enterprises in the Internet concurrently losing connectivity to 131 the Internet through one or more of their ISPs is fairly small. Thus 132 on average the number of additional routes in the "default-free" zone 133 of the Internet due to multi-homed enterprises is expected to be a 134 small fraction of the total number of such enterprises. 136 The approach described above is predicated on the assumption that an 137 enterprise border router has a mechanism(s) by which it could deter- 138 mine (a) whether the connectivity to the Internet through some other 139 border router of that enterprise is up or down, and (b) the address 140 prefix that was allocated to the enterprise by the ISP connected to 141 the other border router. One such possible mechanism could be pro- 142 vided by BGP [BGP]. In this case border routers within the enterprise 143 would have an IBGP peering with each other. Whenever one border 144 router determines that the intersection between the set of reachable 145 destinations it receives via its EBGP (from its directly connected 146 ISP) peerings and the set of reachable destinations it receives from 147 another border router (in the same enterprise) via IBGP is empty, the 148 border router would start advertising to its external peer reachabil- 149 ity to the address prefix that was allocated to the enterprise by the 150 ISP connected to the other border router. The other border router 151 would advertise (via IBGP) the address prefix that was allocated to 152 the enterprise by the ISP connected to that router. This approach is 153 known as "auto route injection". 155 As an illustration consider an enterprise connected to two ISPs, ISP- 156 A and ISP-B. Denote the enterprise border router that connects the 157 enterprise to ISP-A as BR-A; denote the enterprise border router that 158 connects the enterprise to ISP-B as BR-B. Denote the address prefix 159 that ISP-A allocated to the enterprise as Pref-A; denote the address 160 prefix that ISP-B allocated to the enterprise as Pref-B. When the 161 set of routes BR-A receives from ISP-A (via EBGP) has a non-empty 162 intersection with the set of routes BR-A receives from BR-B (via 163 IBGP), BR-A advertises to ISP-A only the reachability to Pref-A. 164 When the intersection becomes empty, BR-A would advertise to ISP-A 165 reachability to both Pref-A and Pref-B. This would continue for as 166 long as the intersection remains empty. Once the intersection becomes 167 non-empty, BR-A would stop advertising reachability to Pref-B to ISP- 168 A (but would still continue to advertise reachability to Pref-A to 169 ISP-A). Figure 1 below describes this method graphically. 171 +-------+ +-------+ +-------+ +-------+ 172 ( ) ( ) ( ) ( ) 173 ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) 174 ( ) ( ) ( ) ( ) 175 +-------+ +-------+ +-------+ +-------+ 176 | /\ | /\ | /\ | 177 | || | || | Pref-A (connection 178 | Pref-A | Pref-B | Pref-B broken) 179 | || | || | || | 180 +-----+ +-----+ +-----+ +-----+ 181 | BR-A|------|BR-B | | BR-A|------|BR-B | 182 +-----+ IBGP +-----+ +-----+ IBGP +-----+ 184 non-empty intersection empty intersection 186 Figure 1: Reachability information advertised 188 Although strictly an implementation detail, calculating the intersec- 189 tion could potentially be a costly operation for a large set of 190 routes. An alternate solution to this is to make use of a selected 191 single (or more) address prefix received from an ISP (the ISP's back- 192 bone route for example) and configure the enterprise border router to 193 perform auto route injection if the selected prefix is not present 194 via IBGP. Let's suppose ISP-B has a well known address prefix, ISP- 195 Pref-B for its backbone. ISP-B advertises this to BR-B and BR-B in 196 turn advertises this via IBGP to BR-A. If BR-A sees a withdraw for 197 ISP-Pref-B it advertises Pref-B to ISP-A. 199 The approach described in this section may produce less than the full 200 Internet-wide connectivity in the presence of ISPs that filter out 201 routes based on the length of their address prefixes. One could 202 observe however, that this would be a problem regardless of how the 203 enterprise would set up its routing and addressing. 205 5.2. Further improvements 207 The approach described in the previous section allows to signifi- 208 cantly reduce the routing overhead in the "default-free" zone of the 209 Internet due to multi-homed enterprises. The approach described in 210 this section allows to completely eliminate this overhead. 212 An enterprise border router would maintain EBGP peering not just with 213 the directly connected border router of an ISP, but with the border 214 router(s) in one or more ISPs that have their border routers directly 215 connected to the other border routers within the enterprise. We 216 refer to such peering as "non-direct" EBGP. 218 An ISP that maintains both direct and non-direct EBGP peering with a 219 particular enterprise would advertise the same set of routes over 220 both of these peerings. An enterprise border router that maintains 221 either direct or non-direct peering with an ISP advertises to that 222 ISP reachability to the address prefix that was allocated by that ISP 223 to the enterprise. Within the ISP routes received over direct peer- 224 ing should be preferred over routes received over non-direct peering. 225 Likewise, within the enterprise routes received over direct peering 226 should be preferred over routes received over non-direct peering. 228 Forwarding along a route received over non-direct peering should be 229 accomplished via encapsulation [GRE]. 231 As an illustration consider an enterprise connected to two ISPs, ISP- 232 A and ISP-B. Denote the enterprise border router that connects the 233 enterprise to ISP-A as E-BR-A, and the ISP-A border router that is 234 connected to E-BR-A as ISP-BR-A; denote the enterprise border router 235 that connects the enterprise to ISP-B as E-BR-B, and the ISP-B border 236 router that is connected to E-BR-B as ISP-BR-B. Denote the address 237 prefix that ISP-A allocated to the enterprise as Pref-A; denote the 238 address prefix that ISP-B allocated to the enterprise as Pref-B. E- 239 BR-A maintains direct EBGP peering with ISP-BR-A and advertises 240 reachability to Pref-A over that peering. E-BR-A also maintain a non- 241 direct EBGP peering with ISP-BR-B and advertises reachability to 242 Pref-B over that peering. E-BR-B maintains direct EBGP peering with 243 ISP-BR-B, and advertises reachability to Pref-B over that peering. 244 E-BR-B also maintains a non-direct EBGP peering with ISP-BR-A, and 245 advertises reachability to Pref-A over that peering. 247 When connectivity between the enterprise and both of its ISPs (ISP-A 248 and ISP-B is up, traffic destined to hosts whose addresses were 249 assigned out of Pref-A would flow through ISP-A to ISP-BR-A to E-BR- 250 A, and then into the enterprise. Likewise, traffic destined to hosts 251 whose addresses were assigned out of Pref-B would flow through ISP-B 252 to ISP-BR-B to E-BR-B, and then into the enterprise. Now consider 253 what would happen when connectivity between ISP-BR-B and E-BR-B goes 254 down. In this case traffic to hosts whose addresses were assigned out 255 of Pref-A would be handled as before. But traffic to hosts whose 256 addresses were assigned out of Pref-B would flow through ISP-B to 257 ISP-BR-B, ISP-BR-B would encapsulate this traffic and send it to E- 258 BR-A, where the traffic will get decapsulated and then be sent into 259 the enterprise. Figure 2 below describes this approach graphically. 261 +---------+ +---------+ 262 ( ) ( ) 263 ( ISP-A ) ( ISP-B ) 264 ( ) ( ) 265 +---------+ +---------+ 266 | | 267 +--------+ +--------+ 268 |ISP-BR-A| |ISP-BR-B| 269 +--------+ +--------+ 270 | /+/ | 271 /\ | Pref-B /+/ | 272 || | /+/ \./ 273 Pref-A| /+/ non- /.\ 274 || | /+/ direct | 275 | /+/ EBGP | 276 +------+ +-------+ 277 |E-BR-A|-----------|E-BR-B | 278 +------+ IBGP +-------+ 280 Figure 2: Reachability information advertised via non-direct EBGP 282 Observe that with this scheme there is no additional routing informa- 283 tion due to multi-homed enterprises that has to be carried in the 284 "default-free" zone of the Internet. In addition this scheme doesn't 285 degrade in the presence of ISPs that filter out routes based on the 286 length of their address prefixes. 288 Note that the set of routers within an ISP that maintain non-direct 289 peering with the border routers within an enterprise doesn't have to 290 be restricted to the ISP's border routers that have direct peering 291 with the enterprise's border routers. The non-direct peering could be 292 maintained with any router within the ISP. Doing this could improve 293 the overall robustness in the presence of failures within the ISP. 295 5.3. Combining the two 297 One could observe that while the approach described in Section 5.2 298 allows to completely eliminate the routing overhead due to multi- 299 homed enterprises in the "default-free" zone of the Internet, it may 300 result in a suboptimal routing in the presence of link failures. The 301 sub-optimality could be reduced by combining the approach described 302 in Section 5.2 with a slightly modified version of the approach 303 described in Section 5.1. The modification consists of constraining 304 the scope of propagation of additional routes that are advertised by 305 an enterprise border router when the router detects problems with the 306 Internet connectivity through its other border routers. A way to con- 307 strain the scope is by using the BGP Community attribute [RFC1997]. 309 5.4. Better (more optimal) routing in steady state 311 The approach described in this document assumes that in a steady 312 state an enterprise border router would advertise to a directly con- 313 nected ISP border router only the reachability to the address prefix 314 that this ISP allocated to the enterprise. As a result, traffic orig- 315 inated by other enterprises connected to that ISP and destined to the 316 parts of the enterprise numbered out of other address prefixes would 317 not enter the enterprise at this border router, resulting in poten- 318 tially suboptimal paths. To improve the situation the border router 319 may (in steady state) advertise reachability not only to the address 320 prefix that was allocated by the ISP that the router is directly con- 321 nected to, but to the address prefixes allocated by some other ISPs 322 (directly connected to some other border routers within the enter- 323 prise). Distribution of such advertisements should be carefully con- 324 strained, or otherwise this may result in significant additional 325 routing information that would need to be maintained in the "default- 326 free" part of the Internet. A way to constrain the distribution of 327 such advertisements is by using the BGP Community attribute 328 [RFC1997]. 330 6. Comparison with other approaches 332 CIDR [RFC1518] proposes several possible address allocation strate- 333 gies for multi-homed enterprises that are connected to multiple ISPs. 334 The following briefly reviews the alternatives being used today, and 335 compares them with the approaches described above. 337 6.1. Solution 1 339 One possible solution suggested in [RFC1518] is for each multi-homed 340 enterprise to obtain its IP address space independently from the ISPs 341 to which it is attached. This allows each multi-homed enterprise to 342 base its IP assignments on a single prefix, and to thereby summarize 343 the set of all IP addresses reachable within that enterprise via a 344 single prefix. The disadvantage of this approach is that since the 345 IP address for that enterprise has no relationship to the addresses 346 of any particular ISPs, the reachability information advertised by 347 the enterprise is not aggregatable with any, but default route. 348 results in the routing overhead in the "default-free" zone of the 349 Internet of O(N), where N is the total number of multi-homed enter- 350 prises across the whole Internet that are connected to multiple ISPs. 352 As a result, this approach can't be viewed as a viable alternative 353 for all, but the enterprises that provide high enough degree of 354 addressing information aggregation. Since by definition the number of 355 such enterprises is likely to be fairly small, this approach isn't 356 viable for most of the multi-homed enterprises connected to multiple 357 ISPs. 359 6.2. Solution 2 361 Another possible solution suggested in [RFC1518] is to assign each 362 multi-homed enterprise a single address prefix, based on one of its 363 connections to one of its ISPs. Other ISPs to which the multi-homed 364 enterprise is attached maintain a routing table entry for the organi- 365 zation, but are extremely selective in terms of which other ISPs are 366 told of this route and would need to perform "proxy" aggregation. 367 Most of the complexity associated with this approach is due to the 368 need to perform "proxy" aggregation, which in turn requires addi- 369 tional inter-ISP coordination and more complex router configuration. 371 7. Discussion 373 The approach described in this document assumes that addresses that 374 an enterprise would use are allocated based on the "address lending" 375 policy. Consequently, whenever an enterprise changes its ISP, the 376 enterprise would need to renumber part of its network that was num- 377 bered out of the address block that the ISP allocated to the enter- 378 prise. However, these issues are not specific to multihoming and 379 should be considered accepted practice in todays internet. The 380 approach described in this document effectively eliminates any dis- 381 tinction between single-home and multi-homed enterprise with respect 382 to the impact of changing ISPs on renumbering. 384 The approach described in this document also requires careful address 385 assignment within an enterprise, as address assignment impacts traf- 386 fic distribution among multiple connections between an enterprise and 387 its ISPs. 389 Both the issue of address assignment and renumbering could be 390 addressed by the appropriate use of network address translation 391 (NAT). The use of NAT for multi-homed enterprises is the beyond the 392 scope of this document. 394 Use of auto route injection (as described in Section 5.1) increases 395 the number of routers in the default-free zone of the Internet that 396 could be affected by changes in the connectivity of multi-homed 397 enterprises, as compared to the use of provider-independed addresses 398 (as described in Section 6.1). Specifically, with auto route injec- 399 tion when a multi-homed enterprise loses its connectivity through one 400 of its ISPs, the auto injected route has to be propagated to all the 401 routers in the default-free zone of the Internet. In contrast, when 402 an enterprise uses provider-independent addresses, only some (but not 403 all) of the routers in the default-free zone would see changes in 404 routing when the enterprise loses its connectivity through one of its 405 ISPs. 407 To supress excessive routing load due to link flapping the auto 408 injected route has to be advertised until the connectivity via the 409 other connection (that was previously down and that triggered auto 410 route injection) becomes stable. 412 Use of the non-direct EBGP approach (as described in Section 5.2) 413 allows to eliminate route flapping due to multi-homed enterprises in 414 the default-free zone of the Internet. That is the non-direct EBGP 415 approach has better properties with respect to routing stability than 416 the use of provider-independent addresses (as described in Section 417 6.1). 419 8. Applications to multi-homed ISPs 421 The approach described in this document could be applicable to a 422 small to medium size ISP that is connected to several upstream ISPs. 423 The ISP would acquire blocks of addresses (address prefixes) from its 424 upstream ISPs, and would use these addresses for allocations to its 425 customers. Either auto route injection, or the non-direct EBGP 426 approach, or a combination of both could be used by the ISP when 427 peering with its upstream ISPs. Doing this would provide routability 428 for the customers of such ISP, without advertsely affecting the over- 429 all scalability of the Internet routing system. 431 9. Security Considerations 433 Since the non-direct EBGP approach (as described in Section 5.2) 434 requires EBGP sessions between routers that are more than one IP hop 435 from each other, routers that maintain these sessions should use an 436 appropriate authentication mechanism(s) for BGP peer authentication. 438 Security issues related to the IBGP peering, as well as the EBGP 439 peering between routers that are one IP hop from each other are out- 440 side the scope of this document. 442 10. Acknowledgments 444 The authors of this document do not make any claims on the original- 445 ity of the ideas described in this document. Anyone who thought about 446 these ideas before should be given all due credit. 448 11. References 450 [RFC2008] 451 Y. Rekhter, T. Li, "Implications of Various Address Allocation 452 Policies for Internet Routing", RFC2008, BCP7, October 1996. 454 [RFC1918] 455 Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear, 456 "Address Allocation for Private Internets", RFC1918, February 1996. 458 [BGP] 459 Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 460 RFC1771, March 1995. 462 [GRE] 463 S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing Encapsu- 464 lation over IPv4 networks", RFC1773, October 1994. 466 [RFC1997] 467 R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", RFC1997, 468 August 1996 470 [RFC1518] 471 Y. Rekhter & T. Li, "An Architecture for IP Address Allocation with 472 CIDR", RFC1518, September 1993. 474 12. Author's Addresses 476 Tony Bates 477 Cisco Systems, Inc. 478 170 West Tasman Drive 479 San Jose, CA 95134 480 email: tbates@cisco.com 482 Yakov Rekhter 483 Cisco Systems, Inc. 484 170 West Tasman Drive 485 San Jose, CA 95134 486 email: yakov@cisco.com 488 INTERNET DRAFT EXPIRES JUNE 1998 INTERNET DRAFT