idnits 2.17.1 draft-touch-trill-prob-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 653), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- The document date (November 17, 2005) is 6735 days in the past. Is this intentional? 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: '2' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 570, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 580, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 583, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 602, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '7') (Obsoleted by RFC 4861) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL WG J. Touch (ed.) 2 Internet Draft USC/ISI 3 Expires: May 2006 November 17, 2005 5 Transparent Interconnection of Lots of Links (TRILL): 6 Problem and Applicability Statement 7 draft-touch-trill-prob-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on May 17, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 Current Ethernet (802.1) link layers use custom routing protocols 42 that have a number of challenges. The routing protocols need to 43 strictly avoid loops, even temporary loops during route propagation, 44 because of the lack of header loop detection support. Routing tends 45 not to take full advantage of alternate paths, or even non- 46 overlapping pairwise paths (in the case of spanning trees). The 47 convergence of these routing protocols and stability under link 48 changes and failures is also of concern. This document addresses 49 these concerns and suggests that they are related to the need to be 50 able to apply network layer routing (e.g., link state or distance 51 vector) protocols at the link layer. This document assumes that 52 solutions would not address issues of scalability beyond that of 53 existing bridged (802.1D) links, but that a solution would be 54 backward compatible with 802.1D, including hubs, bridges, and their 55 existing plug-and-play capabilities. 57 This document is a work in progress; we invite you to participate on 58 the mailing list at http://www.postel.org/rbridge 60 Table of Contents 62 1. Introduction...................................................3 63 2. The TRILL Problem..............................................4 64 2.1. Inefficient Paths.........................................4 65 2.2. Convergence Under Reconfiguration.........................5 66 2.3. Robustness to Link Interruption...........................6 67 2.4. Problems Not Addressed....................................6 68 3. Desired Properties of Solutions to TRILL.......................7 69 3.1. No Change to Link Capabilities............................7 70 3.2. Zero Configuration and Zero Assumption....................8 71 3.3. Forwarding Loop Mitigation................................8 72 3.4. Spanning Tree Management..................................9 73 3.5. Multiple Attachments......................................9 74 3.6. VLAN Issues...............................................9 75 3.7. Equivalence...............................................9 76 3.8. Optimizations............................................10 77 3.9. Internet Architecture Issues.............................10 78 4. Applicability.................................................11 79 5. Security Considerations.......................................12 80 6. IANA Considerations...........................................12 81 7. Conclusions...................................................12 82 8. Acknowledgments...............................................12 83 8.1. Normative References.....................................12 84 8.2. Informative References...................................13 85 Author's Addresses...............................................14 86 Intellectual Property Statement..................................14 87 Disclaimer of Validity...........................................14 88 Copyright Statement..............................................15 89 Acknowledgment...................................................15 91 1. Introduction 93 [CAVEAT: this document is in very rough form. Input and feedback is 94 solicited 96 NOTE: the terms 'campus' and 'rbridge' intentionally do not appear in 97 this document] 99 Conventional Ethernet link subnets have a number of attractive 100 features, allowing hosts and routers to relocate within the subnet 101 without requiring renumbering and are automatically configuring. 102 Unfortunately, the basis of the simplicity of these subnets is the 103 spanning tree, which although simple and elegant, can have 104 substantial limitations. In subnets with high host reattachment 105 frequency, convergence of the spanning tree protocol can be slow. 106 Because all traffic flows over a single tree, all traffic is 107 concentrated on a subset of links, increasing susceptibility to the 108 effects of link failures and limiting the bandwidth across the 109 subnet. 111 [I use the term Ethernet link subnets; do I need to define this? It's 112 not a segment, which I think of as being shared or hubbed but not 113 bridged] 115 The alternative to an Ethernet link subnet is often a network subnet. 116 Network subnets can use link-state routing protocols that allow 117 traffic to traverse least-cost paths rather than being aggregated on 118 a spanning tree backbone, providing higher aggregate capacity and 119 more resistance to link failures. Unfortunately, IP - the dominant 120 network layer technology - requires that hosts be renumbered when 121 relocated in different network subnets, interrupting network (e.g., 122 tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are 123 in progress during the transition. 125 It is thus useful to consider a new approach that combines the 126 features of these two existing solutions, hopefully retaining the 127 desirable properties of each. Such an approach would develop a new 128 kind of bridge system that was capable of using network-style 129 routing, while still operating at the link layer. This allows reuse 130 of well-understood network routing protocols to benefit the link 131 layer. 133 This document describes the challenge of such a combined approach in 134 detail. This problem is known as "Transparent Interconnection of Lots 135 of Links" or "TRILL". The remainder of this document makes as few 136 assumptions about a solution to TRILL as possible. 138 2. The TRILL Problem 140 Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted 141 pair with hubs to twisted pair with switches, becoming increasingly 142 simple to wire and manage. Each level has corresponding topology 143 restrictions; thicknet is inherently linear, whereas thinnet and hub- 144 connected twisted pair have to be wired as a tree. Switches allow 145 network managers to avoid thinking in trees, where the spanning tree 146 protocol finds a valid tree automatically; unfortunately, this 147 additional simplicity comes with a number of associated penalties. 149 The spanning tree often results in inefficient use of the link 150 topology; traffic is concentrated on the spanning tree path, and all 151 traffic follows that path even when other more direct paths may be 152 available. The spanning tree configuration is affected by even small 153 topology changes, and small changes can have large effects. Each of 154 these inefficiencies can cause problems for current link layer 155 deployments. 157 2.1. Inefficient Paths 159 The Spanning Tree Protocol (STP) helps break cycles in a set of 160 interconnected bridges, but it also can limit the bandwidth among 161 that set and cause traffic to take circuitous paths. 163 Consider the network shown in Figure 1, which shows a number of 164 bridges and their interconnecting links. End hosts and routers are 165 not shown; they would connect to the bridges that are shown, labeled 166 A-H. Note that the network shown has cycles which would cause packet 167 storms if hubs (repeaters) were used instead of STP-capable bridges. 168 One possible spanning tree is shown by double lines. 170 B=======\\ C 171 // \ \\ / \\ D 172 // \ \\/ \\ // 173 A-----\-------H===== E 174 \ // || 175 \ // || 176 \ // || 177 G----------F 179 Figure 1 Bridged subnet with spanning tree shown 181 The spanning tree limits the capacity of the resulting subnet. Assume 182 that the links are 100 Mbps. Figure 2 shows how traffic from hosts on 183 A to hosts on C goes via the spanning tree path A-B-H-E-C (links 184 replaced with '1' in the figure); traffic from hosts on G to F go via 185 the spanning three path G-H-E-F (links replaced by '2' in the 186 figure). The link H-E is shared by both paths (alternating '1's and 187 '2's), resulting in an aggregate capacity for both A..C and G..F 188 paths of a total of 100 Mbps. 190 B11111111 C 191 1 1 1 192 1 1 1 193 A H121212E 194 2 2 195 2 2 196 2 2 197 G F 199 Figure 2 Traffic from A..C (1) and G..F (2) share a link 201 If traffic from G to F were to go directly using full routing, e.g., 202 from G-F, both paths could have 100 Mbps each, and the total 203 aggregate capacity could be 200 Mbps (Figure 3). In this case, the H- 204 F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is 205 more direct. 207 B11111111 C 208 1 1 1 D 209 1 1 1 210 A H111111E 212 G2222222222F 214 Figure 3 Traffic from A..C (1) and G..F (2) with full routing 216 There are a number of features of modern layer 3 routing protocols 217 which would be beneficial if available at layer 2, but which cannot 218 be integrated into the spanning tree system. Multipath routing can 219 distribute load simultaneously among two different paths; alternate 220 path routing supports rapid failover to backup paths. Layer 3 routing 221 typically optimizes paths between pairs of endpoints, conventionally 222 based on hopcount but also including bandwidth, latency, or other 223 policy metrics. 225 2.2. Convergence Under Reconfiguration 227 The spanning tree is dependent on the way a set of bridges are 228 interconnected, i.e., the link layer topology. Small changes in this 229 topology can cause large changes in the spanning tree. Changes in the 230 spanning tree can take time to propagate and converge. 232 [QUESTION: is there a good visual example of this, one that we can 233 walk through in the description?] 235 [QUESTION: What is the timescale? O(# bridges)? O(#links?), etc?] 237 [QUESTION: is port autolearning in this category too? i.e., are TRILL 238 solutions trying to hide port reattachment from other nodes (or is 239 that even necessary?)] 241 The spanning tree protocol is inherently global to an entire layer 2 242 subnet; there is no current way to contain, partition, or otherwise 243 factor the protocol into a number of smaller, more stable subsets 244 that interact as groups. Contrast this with Internet routing, which 245 includes both intradomain and interdomain variants, split to provide 246 exactly that containment and scalability within a domain while 247 allowing domains to interact freely independent of what happens 248 inside. 250 [QUESTION: anybody have a convenient reference for a proof? Are new 251 spanning tree protocols not considering AS-like boundaries? (just 252 checking)] 254 2.3. Robustness to Link Interruption 256 Persistent changes to the link topology, as described in Section 2.2, 257 are not the only effects on subnet stability. Transient link 258 interruptions have similar effects, with similar scalability issues. 259 It would be more useful for subnet configuration to be tolerant of 260 such transients, e.g., supporting alternate, backup paths. 262 [QUESTION: is there more to say here?] 264 Contrast this to network layer intradomain and interdomain routing, 265 both of which include provisions for backup paths. These backups 266 allow routing to be more stable in the presence of transients, as 267 well as to recover more rapidly when the transient disappears. 269 2.4. Problems Not Addressed 271 There are other challenges to 802.1D link layer subnets that are not 272 addressed in this document. These include: 274 [NOTE: these are guesses; if any are wrong, we can move or revise] 275 o increased Ethernet link subnet scale 277 o increased node relocation 279 o Ethernet link subnet management protocol security 281 o flooding attacks on a Ethernet link subnet 283 Solutions to TRILL are not intended to support increasingly larger 284 scales of Ethernet link subnets than current spanning tree protocols 285 can support. This may be a side-effect of supporting more rapid 286 reaction to subnet reconfiguration or multiple internal paths, or of 287 the grouped modularity that network style routing affords, but is not 288 the focus of this work. 290 Similarly, solutions to TRILL are not intended to address link layer 291 node migration, which can complicate the caches in learning bridges. 292 Similar challenges exist in the ARP protocol, where link layer 293 forwarding is not updated appropriately when nodes move to ports on 294 other bridges. Again, the grouped modularity of network routing, like 295 that of network layer ASes, can help hide the effect of migration. 296 That is a side effect, however, and not a primary focus of this work. 298 Current link control plane protocols, including Ethernet link subnet 299 management (STP) and link/network integration (ARP), are vulnerable 300 to a variety of attacks. Solutions to TRILL are not intended to 301 directly address these vulnerabilities. Similar attacks exist in the 302 data plane, e.g., source address spoofing, single address traffic 303 attacks, traffic snooping, and broadcast flooding. TRILL solutions do 304 not address any of these issues, although it is critical that they do 305 not introduce new vulnerabilities in the process (see Section 5). 307 3. Desired Properties of Solutions to TRILL 309 This section describes some of the desirable or required properties 310 of any system that would solve the TRILL problems, independent of the 311 details of such an architecture. Most of these are based on retaining 312 useful properties of bridges, or maintaining those properties while 313 solving the problems listed in Section 2. 315 3.1. No Change to Link Capabilities 317 There must be no change to the service that Ethernet subnets already 318 provide as a result of deploying a TRILL solution. Ethernet supports 319 unicast, broadcast, and multicast natively. Although network 320 protocols, notably IP, can tolerate link layers that do not provide 321 all three, it would be useful to retain the support already in place 323 [6]. Zeroconf, as well as existing bridge autoconfiguration, are 324 dependent on broadcast as well. 326 There are subtle implications to such a requirement. Bridge 327 autolearning already is susceptible to moving nodes between ports, 328 because previously learned associations between port and link address 329 change. A TRILL solution could be similarly susceptible to such 330 changes. 332 3.2. Zero Configuration and Zero Assumption 334 Both bridges and hubs are zero configuration devices; hubs having no 335 configuration at all, and bridges being automatically self- 336 configured. Bridges are further zero-assumption devices, unlike hubs. 337 Bridges can be interconnected in arbitrary topologies, without regard 338 for cycles or even (inadvertent) self-attachment. STP removes the 339 impact of cycles automatically, and port autolearning reduces 340 unnecessary broadcast of unicast traffic. 342 A TRILL solution should strive to have similar zero configuration, 343 zero assumption operation. This includes having TRILL solution 344 components automatically discover other TRILL solution components and 345 organize themselves, as well as to configure that organization for 346 proper operation (plug-and-play). It also includes zero configuration 347 backward compatibility with existing bridges and hubs, which may 348 include interacting with some of the bridge protocols, such as STP. 350 Autoconfiguration extends to optional services, such as multicast 351 support via IGMP snooping, broadcast support via internal serial 352 copy, and supporting multiple VLANs. 354 3.3. Forwarding Loop Mitigation 356 Spanning tree avoids forwarding loops by design, even during update 357 (?). Solutions to TRILL are intended to use adapted network layer 358 routing protocols which may introduce transient loops during routing 359 convergence. TRILL solutions thus need support for mitigating the 360 effect of such routing loops. 362 In the Internet, loop avoidance is provided by a decrementing 363 hopcounts (TTL); in other networks, packets include a trace 364 (serialized or unioned) of visited nodes [1]. These mechanisms 365 (respectively) limit the impact of loops or detect them explicitly. A 366 mechanism with similar effect should be included in TRILL solutions. 368 [QUESTION: anyone have a good reference for serialized or union 369 traces - or better names for them?] 371 3.4. Spanning Tree Management 373 In order to address convergence under reconfiguration and robustness 374 to link interruption (Sections 2.2 and 2.3), participation in the STP 375 must be carefully managed. The goal is to provide the desired 376 stability inside the TRILL solution and of the entire Ethernet link 377 subnet while not interfering with the operation of STP outside the 378 TRILL solution. This may involve TRILL solutions participating in the 379 STP, where internally a more stable protocol is run such that the 380 interactions between the TRILL solution and external STP is dampened, 381 or it may involve severing the external STP into separate STPs on 382 'stub' external Ethernet link subnet segments. 384 [we need pictures here; to appear in the next version] 386 3.5. Multiple Attachments 388 [QUESTION: I'm not sure what this refers to; is it the same NIC 389 attached at different points to a TRIL solution? If so, why should 390 this be possible where it seems ignored in bridges?] 392 3.6. VLAN Issues 394 A TRILL solution should support multiple VLANs. This may involve 395 ignorance, just as many bridge devices do not participate in the VLAN 396 protocols. It may alternately support direct VLAN support, e.g., by 397 the use of separate internal routing protocol instances to separate 398 traffic for each VLAN inside a TRILL solution. 400 [QUESTION: is it possible to be ignorant of VLANs and still operate? 401 Bridges are, right?] 403 3.7. Equivalence 405 As with any extension to an existing architecture, it would be useful 406 - though not strictly necessary - to be able to describe or consider 407 a TRILL solution as a model of an existing link layer component. Such 408 equivalence provides a validation model for the architecture. 410 This provides a sanity check, i.e., "we got it right if we can 411 replace a TRILL solution with an X" (where "X" might be a single 412 bridge, a hub, or some other link layer abstraction). It does not 413 matter whether "X" can be implemented on the same scale as the 414 corresponding TRILL solution. It also does not matter if it can - 415 there may be utility to deploying the TRILL solution components 416 incrementally, in ways that a single "X" could not be installed. 418 For example, if TRILL solution were equivalent to a single bridge, it 419 would mean that the TRILL solution would - as a whole - participate 420 in the STP. This need not require that TRILL solution would propagate 421 STP internally, any more than a bridge need do so in its on-board 422 control. It would mean that the solution would interact with BPDUs at 423 the edge, where the solution would - again, as a whole - participate 424 as if a single node in the spanning tree. Note that this equivalence 425 is not required; a solution may act as if a hub, or may not have a 426 corresponding equivalent link layer component at all. 428 3.8. Optimizations 430 There are a number of optimizations that may be applied to TRILL 431 solutions. These must be applied in a way that does not affect 432 functionality as a tradeoff for increased performance. Such 433 optimizations address broadcast and multicast frame distribution, 434 VLAN support, and snooping of ARP and IPv6 neighbor discovery. 436 [NOTE: need to say more here.] 438 3.9. Internet Architecture Issues 440 TRILL solutions are intended to have no impact on the Internet 441 network layer architecture. In particular, the Internet and higher 442 layer headers should remain intact when traversing a TRILL solution, 443 just as they do when traversing any other link subnet technologies. 444 This means that the IP TTL field cannot be co-opted for forwarding 445 loop mitigation, as it would interfere with the Internet layer 446 assuming that the link subnet was reachable with no changes in TTL 447 (Internet TTLs are changed only at routers, as per RFC 1812) [1]. 449 TRILL solutions should also have no impact on Internet routing or 450 signaling, which also means that broadcast and multicast, both of 451 which can pervade an entire Ethernet link subnet, must be able to 452 transparently pervade a TRILL solution. Changing how either of these 453 capabilities behaves would have significant effects on a variety of 454 protocols, including RIP (broadcast), RIPv2 (multicast), ARP 455 (broadcast), IPv6 neighbor discovery (multicast), etc. 457 Note that snooping of network layer packets may be useful, especially 458 for certain optimizations. These include snooping multicast control 459 plane packets (IGMP) to tune link multicast to match the network 460 multicast topology, as is already done in existing smart switches 461 [3]. This also includes snooping IPv6 neighbor discovery messages to 462 assist with governing TRILL solution edge configuration, as is the 463 case in some smart learning bridges [7]. Other layers may similarly 464 be snooped, notably ARP packets, for similar reasons for IPv4 [11]. 466 [Need a ref for the router-router 'igmp' protocol] 468 4. Applicability 470 As might be expected, TRILL solutions are intended to be used to 471 solve the problems described in Section 2. However, not all such 472 installations are appropriate environments for such solutions. This 473 section outlines the issues in the appropriate use of these 474 solutions. 476 TRILL solutions are intended to address problems of path efficiency 477 and stability within a single Ethernet link subnet. Like bridges, 478 individual TRILL solution components may find other TRILL solution 479 components within a single Ethernet link subnet and aggregate into a 480 single TRILL solution. 482 TRILL solutions are not intended to span separate Ethernet link 483 subnets where interconnected by network layer (e.g., router) devices, 484 except via link layer tunnels that are in place prior to their 485 deployment, where such tunnels render the distinct subnet 486 undetectably equivalent from a single Ethernet link subnet. 488 A currently open question is whether a single Ethernet link subnet 489 should contain only one TRILL solution instance, either of necessity 490 of architecture or utility. Multiple TRILL solutions, like Internet 491 ASes, may allow internal TRILL routing protocols to be partitioned in 492 ways that help their stability, but this may come at the price of 493 needing the TRILL solutions to participate more fully as nodes (each 494 modeling a bridge) in the Ethernet link subnet STP. Each architecture 495 solution should decide whether multiple TRILL solutions are supported 496 within a single Ethernet link subnet and mechanisms should be 497 included to enforce whatever decision is made. 499 TRILL solutions are not intended to address scalability limitations 500 in bridged subnets. Although there may be scale benefits of other 501 aspects of solving TRILL problems, e.g., of using network layer 502 routing to provide stability under link changes or intermittent 503 outages, this is not a focus of this work. 505 As also noted earlier, TRILL solutions are not intended to address 506 security vulnerabilities in either the data plane or control plane of 507 the link layer. This means that TRILL solutions should not limit 508 broadcast frames, ARP requests, or spanning tree protocol messages 509 (if such are interpreted by the TRILL solution or solution edge). 511 5. Security Considerations 513 TRILL solutions should not introduce new vulnerabilities compared to 514 traditional bridged subnets. 516 TRILL solutions are not intended to be a solution to Ethernet link 517 subnet vulnerabilities, including spoofing, flooding, snooping, and 518 attacks on the link control plane (STP, flooding the learning cache) 519 and link-network control plane (ARP). Although TRILL solutions are 520 intended to provide more stable routing than STP, this stability is 521 limited to performance, and the subsequent robustness is intended to 522 address non-malicious events. 524 There may be some side-effects to the use of TRILL solutions that can 525 provide more robust operation under certain attacks, such as those 526 interrupting link service, but TRILL solutions should not be relied 527 upon for such capabilities. 529 Finally, TRILL solutions should not interfere with other protocols 530 intended to address these vulnerabilities, such as those under 531 development to secure IPv6 neighbor discovery. 533 [need a ref for secure ipv6 nd] 535 6. IANA Considerations 537 This document has no IANA considerations. 539 This section should be removed by the RFC Editor prior to final 540 publication. 542 7. Conclusions 544 (TBA) 546 8. Acknowledgments 548 Portions of this document are based on a preliminary solution 549 description document [10]. 551 8.1. Normative References 553 None. 555 8.2. Informative References 557 [1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812 558 (Standards Track), June 1995. 560 [2] Braden, R., "Requirements for Internet Hosts - Communication 561 Layers", STD 3, RFC 1122, October 1989. 563 [3] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, 564 "Internet Group Management Protocol, Version 3," RFC 3376 565 (Proposed Standard), October 2002. 567 [4] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 568 environments", RFC 1195, December 1990. 570 [5] IEEE 802.1d bridging standard, "IEEE 802.1d bridging standard". 572 [6] P. Karn (ed.), C. Bormann, G.Fairhurst, D. Grossman, R. Ludwig, 573 J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for 574 Internet Subnetwork Designers," RFC-3819 / BCP 89, July 2004. 576 [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 577 for IP Version 6 (IPv6)", RFC 2461 (Standards Track), December 578 1998. 580 [8] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 581 2005, March 2004. 583 [9] Perlman, R., "Interconnection: Bridges, Routers, Switches, and 584 Internetworking Protocols", Addison Wesley Chapter 3, 1999. 586 [10] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent 587 Routing," (work in progress), Apr. 2004 - May 2005. 589 [11] Plummer, D., "Ethernet Address Resolution Protocol: Or 590 converting network protocol addresses to 48.bit Ethernet 591 address for transmission on Ethernet hardware", STD 37, RFC 826 592 (Standard), November 1982. 594 [12] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual 595 Internet Architecture", ISI Technical Report ISI-TR-570, 596 Presented at the Workshop on Future Directions in Network 597 Architecture (FDNA) 2003 at Sigcomm 2003, March 2003. 599 [13] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 600 November 1990. 602 [14] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923 603 (Informational), September 2000. 605 Author's Addresses 607 Joe Touch 608 USC/ISI 609 4676 Admiralty Way 610 Marina del Rey, CA 90292-6695 611 U.S.A. 613 Phone: +1 (310) 448-9151 614 Email: touch@isi.edu 615 URL: http://www.isi.edu/touch 617 Intellectual Property Statement 619 The IETF takes no position regarding the validity or scope of any 620 Intellectual Property Rights or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; nor does it represent that it has 624 made any independent effort to identify any such rights. Information 625 on the procedures with respect to rights in RFC documents can be 626 found in BCP 78 and BCP 79. 628 Copies of IPR disclosures made to the IETF Secretariat and any 629 assurances of licenses to be made available, or the result of an 630 attempt made to obtain a general license or permission for the use of 631 such proprietary rights by implementers or users of this 632 specification can be obtained from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its attention any 636 copyrights, patents or patent applications, or other proprietary 637 rights that may cover technology that may be required to implement 638 this standard. Please address the information to the IETF at 639 ietf-ipr@ietf.org. 641 Disclaimer of Validity 643 This document and the information contained herein are provided on an 644 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 645 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 646 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 647 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 648 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 649 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Copyright Statement 653 Copyright (C) The Internet Society (2005). 655 This document is subject to the rights, licenses and restrictions 656 contained in BCP 78, and except as set forth therein, the authors 657 retain all their rights. 659 Acknowledgment 661 Funding for the RFC Editor function is currently provided by the 662 Internet Society.