idnits 2.17.1 draft-thaler-ipngwg-multilink-subnets-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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '...local address MUST be tested for uniqu...' RFC 2119 keyword, line 214: '..., an implementation MAY choose to skip...' RFC 2119 keyword, line 241: '...multiple links in the subnet, NS's MAY...' RFC 2119 keyword, line 348: '... all interfaces in the same subnet MAY...' RFC 2119 keyword, line 396: '...y, a Class 1 MSR MUST disable itself i...' 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 (19 July 2001) is 8311 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) ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dave Thaler 3 Internet-Draft Christian Huitema 4 Expires: January 2002 Microsoft 5 19 July 2001 7 Multi-link Subnet Support in IPv6 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Draft Multilink Subnets July 2001 38 Abstract 40 Bridging multiple links into a single entity has several 41 operational advantages. A single subnet prefix is sufficient to 42 support multiple physical links. There is no need to allocate 43 subnet numbers to the different networks, simplifying management. 44 This document introduces the concept of a "multilink subnet", 45 defined as a collection of independent links, connected by 46 routers, but sharing a common subnet prefix. It then specifies 47 the behavior of multilink subnet routers so that no changes to 48 host behavior are needed. 50 1. Introduction 52 Bridging multiple links into a single entity has several 53 operational advantages. A single subnet prefix is sufficient to 54 support multiple physical links. There is no need to allocate 55 subnet numbers to the different networks, simplifying management. 57 However, not all link-layer media can be easily bridged. Classic 58 IEEE 802 bridging technology fails when the media does not 59 naturally support IEEE 802 addressing. Furthermore, the operation 60 becomes problematic when the different links don't support the 61 same MTU size. Finally, bridging cannot be easily implemented 62 when the network interface cannot be easily placed in 63 "promiscuous" mode. 65 This document introduces the concept of a "multilink subnet", 66 defined as a collection of independent links, connected by 67 routers, but sharing a common subnet prefix. Herein we discuss 68 many of the problems and possible solutions surrounding this 69 concept. The initial version of this draft will not specify 70 behavior, but merely discuss the tradeoffs. A later version will 71 narrow the solution space to a recommended approach. 73 2. Terminology 75 multilink subnet: 76 a collection of independent links, connected by routers, but 77 sharing a common subnet prefix. 79 subnet scope: 80 multicast SCOP value 3, as specified in [ADDRARCH], which 82 Draft Multilink Subnets July 2001 84 covers a (potentially multilink) subnet. This is the next 85 larger multicast scope above link scope. 87 multilink-subnet router (MSR): 88 a router which has interfaces attached to different links in 89 a multilink subnet, and which implements the rules in this 90 document. 92 Class 1 multilink subnet: 93 a multilink subnet with only one MSR. 95 Class 2 multilink subnet: 96 a multilink subnet composed of multiple MSRs and links in a 97 tree topology. That is, there is only one possible path 98 within the subnet between any pair of nodes in the subnet. 100 Class 3 multilink subnet: 101 a multilink subnet composed of multiple MSRs and links 102 connected together in an arbitrary topology. 104 Class 1 MSR: 105 an MSR which only works in a Class 1 multilink subnet. 107 Class 2 MSR: 108 an MSR which only works in a Class 1 or 2 multilink subnet. 110 Class 3 MSR: 111 an MSR which works in all types of multilink subnets. 113 3. Design Goals 115 Multilink subnets are designed with the following goals in mind: 117 o Existing IPv6 end hosts should continue to work when 118 connected to a multilink subnet, without requiring any change 119 to their behavior. For example, the host behavior parts of 120 Router Discovery, Neighbor Discovery [ND], and Multicast 121 Listener Discovery [MLD], must be supported. 123 o Leave link-local address behavior unchanged. Link-local 124 behavior continues to function only within a link, not across 125 a multilink subnet. That is sending and receiving unicast, 126 anycast, and multicast traffic within the link should be 127 supported in the normal fashion. 129 Draft Multilink Subnets July 2001 131 o Also support sending and receiving unicast and anycast 132 traffic at the site and global scopes. 134 o Also support sending and receiving multicast traffic at the 135 subnet scope and above. 137 o Prevent routing loops. 139 o Support nodes moving between links within the subnet, with a 140 reasonably fast convergence time (on the same order as 141 Neighbor Unreachability Detection). 143 o In a Class 3 multilink subnet, exploit richer connectivity 144 than just using a spanning tree. 146 4. Overview 148 This section gives an overview of multilink subnets. We describe 149 the behavior of hosts (which is normal IPv6 host behavior with no 150 changes), and the resulting requirements for routers. 152 4.1. Router Discovery 154 Router Discovery continues to work on a per-link basis, as 155 specified in [ND]. When sending Router Advertisements (RAs) with 156 a Prefix Information Option, there are two possibilities for how 157 an MSR can influence the Neighbor Discovery procedure used. 159 4.1.1. Making hosts not use ND 161 If the MSR sets the A (autonomous address-configuration) flag on, 162 and the L (on-link) flag off, then hosts on the link will attempt 163 stateless address configuration [ADDRCONF] in the given prefix, 164 but will not treat the prefix as being on-link. As a result, 165 neighbor discovery is effectively disabled and packets to new 166 destinations always go to the router first, which will then either 167 forward them if the destination is off-link, or redirect them if 168 the destination is on-link. 170 In the remainder of this document, we will refer to this model as 171 the "off-link" model, since hosts initially treat all addresses in 172 the subnet as being off-link. 174 Draft Multilink Subnets July 2001 176 4.1.2. Making hosts use ND 178 If the MSR sets both the A and the L flags, then hosts on the link 179 will perform stateless address configuration and neighbor 180 discovery as usual. However, since Neighbor Solicitations (NSs) 181 from existing hosts are sent to a link-scoped solicited-node 182 multicast address, they will never reach nodes on other links 183 within the subnet. Instead, MSRs must either know the location of 184 the destination a priori, or else be able to relay such NS's to 185 other links, either using link-scoped NS's relayed link-by-link, 186 or using a subnet-scoped NS. 188 In the remainder of this document, we will refer to this model as 189 the "on-link" model, since hosts treat all addresses in the subnet 190 as being on-link. 192 4.1.3. Effects on Duplicate Address Detection 194 In either approach above, existing nodes will still do Duplicate 195 Address Detection using the link-scoped solicited-node multicast 196 address. 198 Two important issues arise that must be addressed: 200 1) If two nodes on different links simultaneously attempt DAD for 201 the same address, care must be taken to so that the collision 202 is detected correctly. 204 2) If a node moves from one link to another link in the same 205 multilink subnet, and performs DAD in its new location, care 206 must be taken so that MSRs can distinguish between such a move, 207 and a legitimate duplicate, so that after the move, the node 208 can retain its address. 209 Because of these issues, routers cannot use cached information to 210 respond on behalf of off-link nodes. 212 Another problem arises from the statement in [ND] that: "the link- 213 local address MUST be tested for uniqueness, and if no duplicate 214 address is detected, an implementation MAY choose to skip 215 Duplicate Address Detection for additional addresses derived from 216 the same interface identifier". 218 Collisions would result if the interface identifier were unique on 219 the link, but not across the entire multilink subnet. To avoid 220 Draft Multilink Subnets July 2001 222 this, MSRs must get involved in duplicate address detection even 223 for link-local addresses, to ensure that all addresses are unique 224 across a multilink subnet. 226 4.2. Neighbor Discovery 228 Neighbor Discovery is used differently, depending on whether the 229 on-link or off-link model is used, as described in the previous 230 section. 232 Off-link model 233 If the subnet is treated as being off-link, all packets are 234 sent to a default router. It is then the default router's 235 responsibility to figure out the next-hop of the packets. If 236 the next-hop is on-link, it sends a Redirect to the source. 238 On-link model 239 If the subnet is treated as being on-link, nodes will send 240 NS's to the solicited node multicast address. (If a node has 241 interfaces attached to multiple links in the subnet, NS's MAY 242 be sent on each link.) If the next-hop is off-link, a router 243 will respond with a proxy Neighbor Advertisement (NA) 244 containing its own link-layer address. 246 In either case, it is the router's responsibility to determine 247 whether a destination in the subnet is on-link. 249 In this version of this draft, we will describe the rules for both 250 of the above models. A future version of this draft may choose 251 only one of them. 253 5. Basic (Class 1) Behavior 255 In a Class 1 multilink subnet, only one router exists. This might 256 be the case, for example, in a home network where a router 257 connects a wired and a wireless link together to form a single 258 subnet. 260 Draft Multilink Subnets July 2001 262 5.1. Basic Unicast 264 In this section, we step through an example of basic unicast 265 communication, assuming that address configuration has already 266 completed, and the router's routing table and neighbor cache 267 already have any required information. 269 In the simple scenario depicted in Figure 1 below, two links, (1) 270 and (2) on a common subnet with global prefix G, are connected by 271 an MSR B. Node A has link-layer address a on link 1, and has 272 acquired global IPv6 address Ga. Similarly, MSR B has on link 1, 273 link-layer address b1, and IPv6 address Gb1, and on link 2, link- 274 layer address b2 and IPv6 address Gb2. Node C has link-layer 275 address c on link 2, and IPv6 address Gc. Node D has link-layer 276 address d on link 1, and IPv6 address Gd. 278 +---+ +---+ 279 | A | | D | 280 +-+-+ +-+-+ 281 | | 282 --+------------+-------------+--------------(1)-- 283 | 284 +-+-+ 285 | B | 286 +-+-+ 287 | 288 ---------------+-------------+--------------(2)-- 289 | 290 +-+-+ 291 | C | 292 +---+ 294 Figure 1: Class 1 Scenario 296 Off-link model 297 When A wants to start communication with Gc, it finds that 298 the destination address matches no on-link prefix, and so 299 sends the packet directly to its default router B. B first 300 applies its usual packet validation rules (including 301 decrementing the Hop Count in the IPv6 header). B knows that 302 C is on-link to link 2, with link-layer address c, and so it 303 forwards the packet to C. 305 Draft Multilink Subnets July 2001 307 When A wants to communicate with Dc, it again finds that the 308 destination address matches no on-link prefix, and so sends 309 the packet directly to its default router B. B knows that D 310 is on-link to the same link as A, and so responds with a 311 Redirect. 313 On-link model 314 When A wants to start communication with Gc, it finds that 315 the destination address matches an on-link prefix, and so 316 sends an NS to the solicited-node multicast address Sc 317 constructed from Gc. The NS message is received by the MSR 318 B, which listens on all multicast groups. B knows that C is 319 on-link to link 2, and responds to A with an NA containing 320 its own link-layer address b1 as the Target Link-Layer 321 Address. 323 After this, A can send packets to the address Gc. The 324 packets will be sent to the link address b1; they will be 325 received by B, which will apply its usual validation rules 326 (including decrementing the Hop Count in the IPv6 header), 327 and forward them to the address c on link 2. 329 When A wants to communicate with Gd, it again finds that the 330 destination address matches an on-link prefix, and so sends 331 an NS to its solicited-node multicast address. D receives 332 the NS and responds. B also receives the NS, but knows that 333 D is on the same link as A, and so does not respond. 335 Note that we did not assume that the links had to use IEEE 802 336 addresses, or in fact any form of consistent addressing. B can 337 also handle MTU discovery procedures, returning an ICMP messages 338 if either A or C sends a packet that is too long. 340 5.2. Router Configuration 342 The previous section assumed that the router's routing table and 343 neighbor cache already had any required information. We now 344 describe how this can be done. 346 Like any other router, an MSR can acquire routes (including the 347 subnet prefix) by using manual configuration or a routing 348 protocol. An MSR with all interfaces in the same subnet MAY 349 Draft Multilink Subnets July 2001 351 acquire its information solely based on RAs received from another 352 router (which is not an MSR), in the same way a host would. It 353 can then advertise the same prefix/route information on other 354 links in the subnet, using either the on-link or off-link model. 356 When needing to resolve a target address to a next-hop (when a 357 host performs ND or DAD), it send a Neighbor Solicitation on each 358 attached link in the subnet, except in the on-link model one is 359 not sent back on the link from which an NS was just received. 360 After sending an NS, the router suppresses sending of any other 361 NS's for the same target address for a short interval (which must 362 be less than ND's RetransTimer). While it is resolving a next- 363 hop, the router also remembers each node sending an NS for the 364 same target address. 366 A Neighbor Advertisement would be sent in response to an NS only 367 by (a) the actual node with the target address, or (b) an MSR 368 which has received an NA in response to a relayed NS it sent as a 369 result of receiving the first NS. Specifically, an NA is not sent 370 just because the MSR has a neighbor cache entry for the target. 371 When an MSR receives an NA, it sends an NA to all nodes from which 372 it received NSs above. 374 As specified in [ND], proxy Neighbor Advertisements sent by MSR's 375 on behalf of remote targets always have the Override bit clear. 377 5.3. Multicast 379 Most current multicast routing protocols are based on a "Reverse- 380 Path Forwarding" check. That is, they drop a packet if the packet 381 does not arrive on the link towards a given address (e.g., the 382 source address, or a Rendezvous Point address associated with the 383 group address). Thus, multicast will work as long as a router can 384 tell which link is towards any address within the subnet. Note 385 that in particular, simply using the subnet route is not 386 sufficient in a multilink subnet. If an MSR's longest-match RPF 387 lookup matches the subnet route for the multilink subnet, it means 388 the source is in the subnet, and the neighbor cache is consulted 389 (as for unicast) to find the link towards the source. 391 Draft Multilink Subnets July 2001 393 5.4. Disabling Class 1 MSRs 395 The above rules assume that the MSR is the only MSR in the subnet. 396 Consequently, a Class 1 MSR MUST disable itself if it detects that 397 another MSR is present. This can be done by assigning a flag 398 (say, bit 0x4) in the RA that is set by all MSRs. 400 TBD: If an MSR only sends RAs on links other than the one from 401 which it got an RA from the "real" (non-MSR) router, then it seems 402 that there can safely be multiple MSR's in parallel on that same 403 link, and the rule above will not disable them either. This is 404 really a Class 2 subnet. 406 TBD: Do the rules above work in transit multilink subnets or not? 407 If not, it also needs to disable itself if any RAs are seen on 408 multiple links in the subnet. 410 6. Class 2 Behavior 412 to Internet 413 | 414 +-+-+ 415 | R | 416 +-+-+ 417 | | 418 --+------------+-------------+----------+---(1)-- | +---+ 419 | | | +--+ F | 420 +-+-+ +-+-+ +-+-+ | +---+ 421 | C | | A | | B +----------+ 422 +---+ +-+-+ +-+-+ | 423 | | | +---+ 424 --(2)-------+-------+---- ---+-----+---(3)-- +--+ G | 425 | | | +---+ 426 +-+-+ +-+-+ | 427 | D | | E | (4) 428 +---+ +---+ | 430 Figure 2: Class 2 Scenario 432 Figure 2 shows a sample tree topology with MSRs A and B connecting 433 four links into a single subnet with hosts C, D, E, F, and G. R 434 is a normal router that provides connectivity to an internet, and 435 sends RAs on link 1. 437 Draft Multilink Subnets July 2001 439 TBD: Fill this in. Is there actually any difference between Class 440 1 and Class 2 behavior, if a single specific link is configured as 441 the "upstream" (towards outside of the subnet) link? We may be 442 able to collapse Class 1 and 2 into the same thing. 444 TBD: What about transit subnets with exit points on different 445 links? 447 7. Security Considerations 449 TBD. 451 8. Appendix A: Class 3 Behavior 453 In the network depicted in Figure 2, we have now three links, and 454 also three multilink-subnet routers (MSRs), B, E, and F. 456 +---+ +---+ 457 | A | | D | 458 +-+-+ +-+-+ 459 | | 460 --+------------+-------------+----------+---(1)-- 461 | | 462 +-+-+ +-+-+ 463 | B | | E | 464 +-+-+ +-+-+ 465 | | 466 -----------+-------------+----------+---(2)-- 467 | 468 +-+-+ 469 | F | 470 +-+-+ 471 | 472 ------+----------+--------------(3)-- 473 | 474 +-+-+ 475 | C | 476 +---+ 478 Figure 3: Class 3 Scenario 480 The network is sufficiently complex to expose several problems: 482 Draft Multilink Subnets July 2001 484 o If A sends an NS packet, that packet is received by both B 485 and E. Depending on the inter-router communication 486 mechanism, this could lead to duplicate transmissions on link 487 2, and possibly to random behaviors, or to loops. 489 o If A sends a multicast packet, and that packet is relayed by 490 both B and E, it would lead to duplicate traffic, or even 491 potential loops. It may not be relayed at all, if neither B 492 nor E realize there is a group member hidden behind F. 494 There are multiple possible approaches to solving the above 495 problems which might meet our design goals. We discuss each 496 approach in turn below, with examples using Figure 3 when no 497 previous state is known. 499 8.1. Method A: Flooding Neighbor Solicitations 501 Neighbor Soliticitations and Advertisements are proxied as 502 described earlier, with the following additional rules. 504 Since multiple paths may exist, to assist in loop prevention and 505 provide shortest paths, a new "Local Distance" option in NA's can 506 be defined: 507 0 1 2 3 508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type | Length | Reserved | Hop Count | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Timestamp | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 The option contains five fields, encoded in 8 octets. 516 The Hop Count field contains an 8-bit unsigned integer being the 517 number of hops between the advertising station and the source or 518 the target address. It is used to assist in loop prevention and 519 provide shortest paths. 521 The Timestamp, is a 32-bit integer (in seconds) that describes the 522 time at which the source or target address was last advertised by 523 the actual node with that address. It is used to ensure that 524 neighbor discovery messages do not loop forever if the propagation 525 delay through across the subnet is significant. (Authors' note: 527 Draft Multilink Subnets July 2001 529 is there a way to make this work without synchronized clocks? Is 530 a Timestamp really required?) 532 If this option is used, it is expected that an MSR's neighbor 533 cache entries would also contain the Hop Count and Timestamp 534 information associated with the link-layer address used. 536 The absence of such this option implies a Hop Count value of 0. 537 When proxying an NA, an MSR would include the Local Distance 538 option with an incremented value. Legacy nodes will ignore the 539 option, but MSRs (and new nodes if they wish) can use the option 540 to prefer link-layer addresses with a lower Local Distance. 542 To route actual packets, an MSR's route lookup would determine 543 that the longest matching route is on-link to multiple links. The 544 router would consult its (conceptual) neighbor cache, and use the 545 next-hop with the lowest Local Distance. The same procedure would 546 apply to multicast packets as well, when the router would look up 547 the RPF address. 549 8.1.1. On-link model example 551 In Figure 3, when A wishes to communicate with Gc, both B and E 552 will receive an NS from A. Each will originate an NS for Gc on 553 link 2. B, E, and F will receive the NS's on link 2. B and E 554 will ignore each others' NS since they have just sent an NS for 555 the same address. 557 F will receive the NS's and the first one will cause it to create 558 a neighbor cache entry in the INCOMPLETE state, and originate its 559 own NS on link 3. When C receives this NS, it will respond with 560 an NA. 562 When F receives the NA from C, it will respond to B and E with an 563 NA with its own link-layer address f2 as the Target Link Layer 564 Address, and a "Local Distance = 1" option. B and E will then 565 respond to A with NAs containing b1 and e1, respectively, as the 566 Target Link Layer Address, and a "Local Distance = 2" option. 568 8.1.2. Off-link model example 570 In Figure 3, when A wishes to communicate with Gc, it will send 571 packets to a default router, say, B. B will send an NS on link 1, 572 Draft Multilink Subnets July 2001 574 which will be received by E, and on link 2 which will be received 575 by E and F. Depending on timing, E may send an NS on link 1 or 576 link 2 or neither. (If a short delay were inserted before 577 sending, both could be suppressed.) F will send an NS on link 3, 578 to which C will reply with an NA. Upon receiving the NA, F sends 579 an NA to all nodes from which it has seen an NS for Gc, namely B 580 and possibly E. 582 B (and possibly E as well) will then send an NA on link 1, after 583 which A can communicate with C. 585 8.2. Method B: Proactively populate host routes 587 The basic idea here is that MSR's would inject host routes into a 588 routing protocol used within (at least) the subnet upon detecting 589 a new node on a directly-connected link (e.g., when DAD completes 590 on an Ethernet, or when IPv6CP completes on a PPP link). 592 Once host routes exist, either the off-link or the on-link model 593 could be used. In addition, multicast works with no changes, 594 since host routes would be used for RPF checks. 596 Another advantage is that since all resolution is done by MSR's "a 597 priori", no additional delay is incurred when A wants to 598 communicate with A. If the on-link model is used, no neighbor 599 discovery delay exists at all. Packets are immediately forwarded 600 along the correct path. This approach avoids all bursty-source 601 problems. 603 Since host routes are cached state, they cannot, however, be used 604 for duplicate address detection, due to the issues described in 605 Section 4.1.3. That is, the presence of a host route does not 606 imply a duplicate, since the node may have just moved. The lack 607 of a host route does not imply uniqueness, since another node may 608 be simultaneously choosing the same address. As a result, DAD 609 requires additional mechanisms, such as flooding neighbor 610 discovery messages as in Method A, or provided by a specialized 611 routing protocol. 613 Work in progress in the Mobile Ad-hoc Networks (manet) WG may 614 provide solutions to the above problems in the future. 616 Draft Multilink Subnets July 2001 618 9. Acknowledgements 620 Steve Deering, Brian Zill, Hesham Soliman, and Karim ElMalki 621 participated in discussions that led to this draft. The term 622 "multilink subnet" was coined by Steve Deering. 624 10. Authors' Addresses 626 Dave Thaler 627 Microsoft Corporation 628 One Microsoft Way 629 Redmond, WA 98052-6399 630 Phone: +1 425 703 8835 631 EMail: dthaler@microsoft.com 633 Christian Huitema 634 Microsoft Corporation 635 One Microsoft Way 636 Redmond, WA 98052-6399 637 EMail: huitema@microsoft.com 639 11. References 641 [ADDRARCH] 642 Hinden, R., and S. Deering, "IP Version 6 Addressing 643 Architecture", RFC 2373, July 1998. 645 [ADDRCONF] 646 Thomson, S., and T. Narten, "IPv6 Stateless Address 647 Autoconfiguration", RFC 2462, December 1998. 649 [MLD] 650 Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 651 Discovery (MLD) for IPv6", RFC 2710, October 1999. 653 [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 654 for IP Version 6 (IPv6)", RFC 2461, December 1998. 656 12. Full Copyright Statement 658 Copyright (C) The Internet Society (2001). All Rights Reserved. 660 Draft Multilink Subnets July 2001 662 This document and translations of it may be copied and furnished 663 to others, and derivative works that comment on or otherwise 664 explain it or assist in its implmentation may be prepared, copied, 665 published and distributed, in whole or in part, without 666 restriction of any kind, provided that the above copyright notice 667 and this paragraph are included on all such copies and derivative 668 works. However, this document itself may not be modified in any 669 way, such as by removing the copyright notice or references to the 670 Internet Society or other Internet organizations, except as needed 671 for the purpose of developing Internet standards in which case the 672 procedures for copyrights defined in the Internet Standards 673 process must be followed, or as required to translate it into 674 languages other than English. 676 The limited permissions granted above are perpetual and will not 677 be revoked by the Internet Society or its successors or assigns. 679 This document and the information contained herein is provided on 680 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 681 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 682 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 683 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 684 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.