idnits 2.17.1 draft-ietf-ipv6-multilink-subnets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 192: '... issues, routers MUST NOT use cached i...' RFC 2119 keyword, line 196: '...local address MUST be tested for uniqu...' RFC 2119 keyword, line 197: '..., an implementation MAY choose to skip...' RFC 2119 keyword, line 224: '...multiple links in the subnet, NS's MAY...' RFC 2119 keyword, line 241: '...An ND-Proxy MAY support automatic conf...' (4 more instances...) 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 (29 June 2002) is 7972 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) == Outdated reference: A later version (-06) exists of draft-ietf-magma-igmp-proxy-00 ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 3 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: December 2002 Microsoft 5 29 June 2002 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 (2002). All Rights Reserved. 36 Draft Multilink Subnets June 2002 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 Not all link-layer media can be easily bridged. Classic IEEE 802 53 bridging technology fails when the media does not naturally 54 support IEEE 802 addressing. Furthermore, the operation becomes 55 problematic when the different links don't support the same MTU 56 size. Finally, bridging cannot be easily implemented when the 57 network interface cannot be easily placed in "promiscuous" mode. 59 We define a "multilink subnet" as a collection of independent 60 links, connected by routers, but sharing a common subnet prefix. 61 This might be used, for example, in a home network where a router 62 connects a wired and a wireless link together to form a single 63 subnet. 65 A multilink subnet can be implemented in either of two ways. In a 66 simple scenario, a router can act as an asymmetric Neighbor 67 Discovery proxy, connecting links in a loop-free topology. In a 68 more complex scenario, an arbitrary topology exists, and routers 69 within the subnet communicate using some means of exchanging host 70 routes. In this draft, we will only specify the behavior of a 71 router in the simple scenario, while the behavior of hosts in 72 either scenario is the same (indeed hosts need not even know which 73 scenario they are in, or even whether they are on a multilink 74 subnet). Appendix A will discuss some of the issues affecting 75 routers in the complex scenario. 77 2. Terminology 79 multilink subnet: 80 a collection of independent links, connected by routers, but 82 Draft Multilink Subnets June 2002 84 sharing a common subnet prefix. 86 subnet scope: 87 multicast SCOP value 3, as specified in [ADDRARCH], which 88 covers a (potentially multilink) subnet. This is the next 89 larger multicast scope above link scope. 91 multilink-subnet router (MSR): 92 a router which has interfaces attached to different links in 93 a multilink subnet, and which implements the rules in this 94 document. Such interfaces are boundaries for the link 95 scope, but not for the subnet scope. 97 3. Design Goals 99 Multilink subnet functionality is designed with the following 100 goals in mind: 102 o Existing IPv6 end hosts should continue to work when 103 connected to a multilink subnet, without requiring any change 104 to their behavior. For example, the host behavior parts of 105 Router Discovery, Neighbor Discovery [ND], and Multicast 106 Listener Discovery [MLD], must be supported. 108 o Leave link-local address behavior unchanged. Link-local 109 behavior continues to function only within a link, not across 110 a multilink subnet. That is, sending and receiving unicast, 111 anycast, and multicast traffic within the link should be 112 supported in the normal fashion. 114 o Also support sending and receiving unicast and anycast 115 traffic at the site and global scopes. 117 o Also support sending and receiving multicast traffic at the 118 subnet scope and above. 120 o Prevent routing loops. 122 o Support nodes moving between links within the subnet, with a 123 reasonably fast convergence time (on the same order as 124 Neighbor Unreachability Detection). 126 Draft Multilink Subnets June 2002 128 4. Overview 130 This section gives an overview of multilink subnets. We describe 131 the behavior of hosts (which is normal IPv6 host behavior with no 132 changes), and the resulting requirements for routers. 134 4.1. Router Discovery 136 Router Discovery continues to work on a per-link basis, as 137 specified in [ND]. When sending Router Advertisements (RAs) with 138 a Prefix Information Option, there are two possibilities for how a 139 multilink subnet router can influence the Neighbor Discovery 140 procedure used. 142 4.1.1. Making hosts not use ND 144 If the MSR sets the A (autonomous address-configuration) flag on, 145 and the L (on-link) flag off, then hosts on the link will attempt 146 stateless address configuration [ADDRCONF] in the given prefix, 147 but will not treat the prefix as being on-link. As a result, 148 neighbor discovery is effectively disabled and packets to new 149 destinations always go to the router first, which will then either 150 forward them if the destination is off-link, or redirect them if 151 the destination is on-link. 153 In the remainder of this document, we will refer to this model as 154 the "off-link" model, since hosts initially treat all addresses in 155 the subnet as being off-link. 157 4.1.2. Making hosts use ND 159 If the MSR sets both the A and the L flags, then hosts on the link 160 will perform stateless address configuration and neighbor 161 discovery as usual. However, since Neighbor Solicitations (NSs) 162 from existing hosts are sent to a link-scoped solicited-node 163 multicast address, they will never reach nodes on other links 164 within the subnet. Instead, MSRs must either know the location of 165 the destination a priori, or else be able to relay such NS's to 166 other links. We will return to this discussion in Section 5. 168 In the remainder of this document, we will refer to this model as 169 the "on-link" model, since hosts treat all addresses in the subnet 170 Draft Multilink Subnets June 2002 172 as being on-link. 174 4.1.3. Effects on Duplicate Address Detection 176 In either approach above, existing nodes will still do Duplicate 177 Address Detection using the link-scoped solicited-node multicast 178 address. 180 Two important issues arise that must be addressed: 182 1) If two nodes on different links in the subnet simultaneously 183 attempt DAD for the same address, care must be taken to so that 184 the collision is detected correctly. 186 2) If a node moves from one link to another link in the same 187 subnet, and performs DAD in its new location, care must be 188 taken so that MSRs can distinguish between such a move, and a 189 legitimate duplicate, so that after the move, the node can 190 retain its address. 192 Because of these issues, routers MUST NOT use cached information 193 to respond on behalf of off-link nodes. 195 Another problem arises from the statement in [ND] that: "the link- 196 local address MUST be tested for uniqueness, and if no duplicate 197 address is detected, an implementation MAY choose to skip 198 Duplicate Address Detection for additional addresses derived from 199 the same interface identifier". 201 Collisions would result if the interface identifier were unique on 202 the link, but not across the entire multilink subnet. To avoid 203 this, MSRs must get involved in duplicate address detection even 204 for link-local addresses, to ensure that all addresses are unique 205 across a multilink subnet. 207 4.2. Neighbor Discovery 209 Neighbor Discovery is used differently, depending on whether the 210 on-link or off-link model is used, as described in the previous 211 section. 213 Draft Multilink Subnets June 2002 215 Off-link model 216 If the subnet is treated as being off-link, all packets are 217 sent to a default router. It is then the default router's 218 responsibility to figure out the next-hop of the packets. If 219 the next-hop is on-link, it sends a Redirect to the source. 221 On-link model 222 If the subnet is treated as being on-link, nodes will send 223 NS's to the solicited node multicast address. (If a node has 224 interfaces attached to multiple links in the subnet, NS's MAY 225 be sent on each link.) If the next-hop is off-link, a router 226 will respond with a proxy Neighbor Advertisement (NA) 227 containing its own link-layer address. 229 In either case, it is the router's responsibility to determine 230 whether a destination in the subnet is on-link. 232 5. ND-Proxy Behavior 234 A simple ND-Proxy router will have one or more interfaces on which 235 it acts as a router, and optionally an interface on which it acts 236 as a "host", proxying for all nodes on its router interfaces. We 237 will hereafter refer to an interface in this latter mode as a 238 "proxy-mode" interface. (This configuration is consistent with 239 that of an IGMP/MLD Proxy [IGMPPROXY].) 241 An ND-Proxy MAY support automatic configuration as follows. 242 First, it starts out as a normal host, discovering routers (if 243 any) on each interface. Then, it switches to router-mode on all 244 interfaces on which no routers were discovered. If any interfaces 245 with routers were found, it chooses one and acts in proxy-mode on 246 that interface. In Router Advertisements sent on its router-mode 247 interfaces, the ND-Proxy advertises itself as a default router, 248 and includes copies of the Prefix Information options it learned 249 on its proxy-mode interface, possibly after changing the parity of 250 the L flag, depending on whether it wants nodes to use the on-link 251 or the off-link model. 253 5.1. Basic Unicast 255 In this section, we step through an example of basic unicast 256 communication, assuming that address configuration has already 257 completed, and the router's routing table and neighbor cache 258 Draft Multilink Subnets June 2002 260 already have any required information. Section 5.2 will then 261 explain how it obtains the required information when a cache miss 262 occurs. 264 In the simple scenario depicted in Figure 1 below, two links, (1) 265 and (2) on a common subnet with global prefix G, are connected by 266 an ND-Proxy B. Node A has link-layer address a on link 1, and has 267 acquired global IPv6 address Ga. ND-Proxy B is in router-mode on 268 link 1, where it has link-layer address b1, and IPv6 address Gb1. 269 It is in either router-mode or proxy-mode (e.g., if C is a router) 270 on link 2, where it has link-layer address b2 and IPv6 address 271 Gb2. Node C has link-layer address c on link 2, and IPv6 address 272 Gc. Node D has link-layer address d on link 1, and IPv6 address 273 Gd. 275 +---+ 276 | C | 277 +-+-+ 278 | 279 ---------------+-------------+--------------(2)-- 280 |Router-mode or proxy-mode 281 +-+-+ 282 | B | 283 +-+-+ 284 |Router-mode 285 --+------------+-------------+--------------(1)-- 286 | | 287 +-+-+ +-+-+ 288 | A | | D | 289 +---+ +---+ 291 Figure 1: Simple ND-Proxy Scenario 293 Off-link model 294 When A wants to start communication with Gc, it finds that 295 the destination address matches no on-link prefix, and so 296 sends the packet directly to its default router B. B first 297 applies its usual packet validation rules (including 298 decrementing the Hop Count in the IPv6 header). B knows that 299 C is on-link to link 2, with link-layer address c, and so it 300 forwards the packet to C. 302 When A wants to communicate with Dc, it again finds that the 304 Draft Multilink Subnets June 2002 306 destination address matches no on-link prefix, and so sends 307 the packet directly to its default router B. B knows that D 308 is on-link to the same link as A, and so responds with a 309 Redirect. 311 On-link model 312 When A wants to start communication with Gc, it finds that 313 the destination address matches an on-link prefix, and so 314 sends an NS to the solicited-node multicast address Sc 315 constructed from Gc. The NS message is received by the ND- 316 Proxy B, which listens on all multicast groups. B knows that 317 C is on-link to link 2, and responds to A with an NA 318 containing its own link-layer address b1 as the Target Link- 319 Layer Address. 321 After this, A can send packets to the address Gc. The 322 packets will be sent to the link address b1; they will be 323 received by B, which will apply its usual validation rules 324 (including decrementing the Hop Count in the IPv6 header), 325 and forward them to the address c on link 2. 327 When A wants to communicate with Gd, it again finds that the 328 destination address matches an on-link prefix, and so sends 329 an NS to its solicited-node multicast address. D receives 330 the NS and responds. B also receives the NS, but knows that 331 D is on the same link as A, and so does not respond. 333 Note that we did not assume that the links had to use IEEE 802 334 addresses, or in fact any form of consistent link-layer 335 addressing. B can also handle MTU discovery procedures, returning 336 an ICMP messages if either A or C sends a packet that is too long. 338 5.2. Router Configuration 340 The previous section assumed that the router's routing table and 341 neighbor cache already had any required information. We now 342 describe how this can be done. 344 Like any other router, an MSR can acquire routes (including the 345 subnet prefix) by using manual configuration or a routing 346 protocol. An MSR with all interfaces in the same subnet MAY 347 acquire its information solely based on RAs received from another 348 Draft Multilink Subnets June 2002 350 router (which is not an MSR), in the same way a host would. It 351 can then advertise the same prefix/route information on other 352 links in the subnet, using either the on-link or off-link model. 354 To receive Neighbor Solicitations for nodes for which it is 355 proxying, the MSR must be able to receive NS's sent to any 356 multicast group on any of its links within the subnet (including 357 its proxy-mode interface). 359 When a Neighbor Solicitation is received, and a corresponding 360 entry is not found in its neighbor cache, the MSR will attempt to 361 resolve by sending a Neighbor Solicitation on each attached link 362 in the subnet, except that in the on-link model one is not sent 363 back on the link from which an NS was just received. After 364 sending an NS, the router SHOULD suppress sending of any other 365 NS's for the same target address for a short interval (which must 366 be less than ND's RetransTimer), and while it is resolving a next- 367 hop, remember each node sending an NS for the same target address. 368 If a Neighbor Advertisement is received, a proxy NA is sent to 369 each nodes from which the MSR received an NS. 371 A Neighbor Advertisement would be sent in response to an NS only 372 by (a) the actual node with the target address, or (b) an MSR 373 which has received an NA in response to a relayed NS it sent as a 374 result of receiving the first NS. Specifically, a Neighbor 375 Advertisement MUST NOT be sent just because the MSR has a neighbor 376 cache entry for the target. When an MSR receives an NA, it sends 377 an NA to all nodes from which it received NSs above. 379 As specified in [ND], proxy Neighbor Advertisements sent by MSR's 380 on behalf of remote targets always have the Override bit clear. 382 5.3. Multicast 384 Most current multicast routing protocols are based on a "Reverse- 385 Path Forwarding" check. That is, they drop a packet if the packet 386 does not arrive on the link towards a given address (e.g., the 387 source address, or a Rendezvous Point address associated with the 388 group address). Thus, sourcing multicast will work as long as a 389 router can tell which link is towards any address within the 390 subnet. Note that in particular, simply using the subnet route is 391 not sufficient in a multilink subnet. If an MSR's longest-match 392 RPF lookup matches the subnet route for the multilink subnet, it 393 means the source is in the subnet, and the neighbor cache is 394 Draft Multilink Subnets June 2002 396 consulted (as for unicast) to find the link towards the source. 398 To allow hosts to receive multicast data, an ND-Proxy acts as an 399 MLD-Proxy using the rules described in [IGMPPROXY]. 401 5.4. Disabling ND-Proxying 403 The above rules assume only one ND-proxy is acting as a router on 404 each link. Consequently, an ND-Proxy MUST stop acting as a router 405 on a given interface if it receives an RA from another device on 406 that interface. 408 6. Connecting ND-Proxies 410 ND-Proxies can be connected, either in parallel (connecting 411 different leaf links) or in series (subject to the constraints 412 below), using the same rules specified above. The following 413 figure illustrates this. 415 to Internet 416 | 417 +-+-+ 418 | R | 419 +-+-+ 420 | | 421 --+------------+-------------+----------+---(1)-- | +---+ 422 | | | +--+ F | 423 +-+-+ +-+-+ +-+-+ | +---+ 424 | C | | A | | B +----------+ 425 +---+ +-+-+ +-+-+ | 426 | | | +---+ 427 --(2)-------+-------+---- ---+-----+---(3)-- +--+ G | 428 | | | +---+ 429 +-+-+ +-+-+ | 430 | D | | E | (4) 431 +-+-+ +---+ | 432 | 433 --(5)---------------+---- 434 | 435 +-+-+ 436 | H | 437 +-+-+ 439 Draft Multilink Subnets June 2002 441 Figure 2: Multiple ND-Proxy Scenario 443 Figure 2 shows a complex tree topology with MSRs A, B, and D 444 connecting five links into a single subnet with hosts C, D, E, F, 445 and G. R is a normal router that provides connectivity to an 446 internet, and sends RAs on link 1. 448 MSR's A and B have both discovered router R on link 1, and are 449 acting in proxy-mode on that link, while acting in router-mode on 450 their other links. 452 MSR D is acting in proxy-mode on link 2, and in router-mode on 453 link 5. In this configuration, all hosts can communicate with 454 each other and with the Internet. However, the automatic 455 configuration mechanism described in section X above does not 456 always work for D. If D comes up before A, then it would act in 457 router-mode on link 2, preventing A from doing so. As a result, 458 chaining ND-Proxies should only be done where some means of 459 preventing this exists. For example, D could either: 461 o be manually configured to be in proxy-mode on link 2, or 463 o could have one of its ports permanently labelled as being its 464 proxy-mode port, so the correct orientation is obvious either 465 when connecting cables (if homogenous media types are used on 466 different interfaces) or when first obtaining the device (if 467 its purpose is to connect heterogeneous media types). 469 7. Security Considerations 471 In general, the security considerations issues and recommendations 472 are the same as those described in Section 11 of [ND]. In 473 addition, the following points are worth noting. 475 In the off-link model, the source address of the relevant ICMP 476 messages is the address of the actual source. As a result, 477 messages can be authenticated, if some means of securing Router 478 Discovery is used. 480 In the on-link model, Neighbor Discovery messages are proxied, and 481 hence Neighbor Discovery is harder to secure. As a result, when 482 secure Neighbor Discovery is required, the off-link model should 483 be used. 485 Draft Multilink Subnets June 2002 487 8. Appendix A: Complex Scenario Issues 489 In the network depicted in Figure 2, we have now three links, and 490 also three multilink-subnet routers (MSRs), B, E, and F. 492 +---+ +---+ 493 | A | | D | 494 +-+-+ +-+-+ 495 | | 496 --+------------+-------------+----------+---(1)-- 497 | | 498 +-+-+ +-+-+ 499 | B | | E | 500 +-+-+ +-+-+ 501 | | 502 -----------+-------------+----------+---(2)-- 503 | 504 +-+-+ 505 | F | 506 +-+-+ 507 | 508 ------+----------+--------------(3)-- 509 | 510 +-+-+ 511 | C | 512 +---+ 514 Figure 3: Arbitrary Topology Scenario 516 The network is sufficiently complex to expose several problems: 518 o If A sends an NS packet, that packet is received by both B 519 and E. Depending on the inter-router communication 520 mechanism, this could lead to duplicate transmissions on link 521 2, and possibly to random behaviors, or to loops. 523 o If A sends a multicast packet, and that packet is relayed by 524 both B and E, it would lead to duplicate traffic, or even 525 potential loops. It may not be relayed at all, if neither B 526 nor E realize there is a group member hidden behind F. 528 There are multiple possible approaches to solving the above 529 problems which might meet our design goals. We discuss two 530 examples below. 532 Draft Multilink Subnets June 2002 534 8.1. Method 1: Flooding Neighbor Solicitations 536 Neighbor Soliticitations and Advertisements could be proxied out 537 all interfaces and hence flooded across the subnet. To prevent 538 loops, some mechanism such as a new "Local Distance" option in 539 NA's would be needed. The use of Neighbor Discovery would then be 540 equivalent to a simple means of exchanging host routes between 541 MSRs, and could be used regardless of which routing protocol is 542 used. 544 To route actual packets, an MSR's route lookup would determine 545 that the longest matching route is on-link to multiple links. The 546 router would consult its (conceptual) neighbor cache, and use the 547 next-hop with the lowest Local Distance. The same procedure would 548 apply to multicast packets as well, when the router would look up 549 the RPF address. 551 8.2. Method 2: Proactively populate host routes 553 MSR's could inject host routes into a routing protocol used within 554 (at least) the subnet upon detecting a new node on a directly- 555 connected link (e.g., when DAD completes on an Ethernet, or when 556 IPv6CP completes on a PPP link). 558 Once host routes exist, either the off-link or the on-link model 559 could be used. In addition, multicast works with no changes, 560 since host routes would be used for RPF checks. 562 Another advantage is that since all resolution is done by MSR's "a 563 priori", no additional delay is incurred when A wants to 564 communicate with A. If the on-link model is used, no neighbor 565 discovery delay exists at all. Packets are immediately forwarded 566 along the correct path. This approach avoids bursty-source 567 problems. 569 Since host routes are cached state, they cannot, however, be used 570 for duplicate address detection, due to the issues described in 571 Section 4.1.3. That is, the presence of a host route does not 572 imply a duplicate, since the node may have just moved. The lack 573 of a host route does not imply uniqueness, since another node may 574 be simultaneously choosing the same address. As a result, DAD 575 requires additional mechanisms, such as flooding neighbor 576 discovery messages as in Method 1, or provided by a specialized 577 routing protocol. 579 Draft Multilink Subnets June 2002 581 Work in progress in the Mobile Ad-hoc Networks (manet) WG may 582 provide solutions to the above problems in the future. 584 9. Acknowledgements 586 Steve Deering, Brian Zill, Hesham Soliman, and Karim El-Malki 587 participated in discussions that led to this draft. The term 588 "multilink subnet" was coined by Steve Deering. 590 10. Authors' Addresses 592 Dave Thaler 593 Microsoft Corporation 594 One Microsoft Way 595 Redmond, WA 98052-6399 596 Phone: +1 425 703 8835 597 EMail: dthaler@microsoft.com 599 Christian Huitema 600 Microsoft Corporation 601 One Microsoft Way 602 Redmond, WA 98052-6399 603 EMail: huitema@microsoft.com 605 11. References 607 [ADDRARCH] 608 Hinden, R., and S. Deering, "IP Version 6 Addressing 609 Architecture", RFC 2373, July 1998. 611 [ADDRCONF] 612 Thomson, S., and T. Narten, "IPv6 Stateless Address 613 Autoconfiguration", RFC 2462, December 1998. 615 [IGMPPROXY] 616 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP-based 617 Multicast Forwarding (IGMP Proxying)", draft-ietf-magma-igmp- 618 proxy-00.txt, November, 2001. 620 [MLD] 621 Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 622 Discovery (MLD) for IPv6", RFC 2710, October 1999. 624 Draft Multilink Subnets June 2002 626 [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 627 for IP Version 6 (IPv6)", RFC 2461, December 1998. 629 12. Full Copyright Statement 631 Copyright (C) The Internet Society (2002). All Rights Reserved. 633 This document and translations of it may be copied and furnished 634 to others, and derivative works that comment on or otherwise 635 explain it or assist in its implmentation may be prepared, copied, 636 published and distributed, in whole or in part, without 637 restriction of any kind, provided that the above copyright notice 638 and this paragraph are included on all such copies and derivative 639 works. However, this document itself may not be modified in any 640 way, such as by removing the copyright notice or references to the 641 Internet Society or other Internet organizations, except as needed 642 for the purpose of developing Internet standards in which case the 643 procedures for copyrights defined in the Internet Standards 644 process must be followed, or as required to translate it into 645 languages other than English. 647 The limited permissions granted above are perpetual and will not 648 be revoked by the Internet Society or its successors or assigns. 650 This document and the information contained herein is provided on 651 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 652 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 653 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 654 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 655 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 657 Draft Multilink Subnets June 2002 659 Table of Contents 661 1: Introduction ............................................. 2 662 2: Terminology .............................................. 2 663 3: Design Goals ............................................. 3 664 4: Overview ................................................. 4 665 4.1: Router Discovery ....................................... 4 666 4.1.1: Making hosts not use ND .............................. 4 667 4.1.2: Making hosts use ND .................................. 4 668 4.1.3: Effects on Duplicate Address Detection ............... 5 669 4.2: Neighbor Discovery ..................................... 5 670 5: ND-Proxy Behavior ........................................ 6 671 5.1: Basic Unicast .......................................... 6 672 5.2: Router Configuration ................................... 8 673 5.3: Multicast .............................................. 9 674 5.4: Disabling ND-Proxying .................................. 10 675 6: Connecting ND-Proxies .................................... 10 676 7: Security Considerations .................................. 11 677 8: Appendix A: Complex Scenario Issues ...................... 12 678 8.1: Method 1: Flooding Neighbor Solicitations .............. 13 679 8.2: Method 2: Proactively populate host routes ............. 13 680 9: Acknowledgements ......................................... 14 681 10: Authors' Addresses ...................................... 14 682 11: References .............................................. 14 683 12: Full Copyright Statement ................................ 15