idnits 2.17.1 draft-iab-multilink-subnet-issues-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2007) is 6130 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 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4541 == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 1884 (Obsoleted by RFC 2373) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Thaler 3 January 23, 2006 Internet Architecture Board 4 Expires July 2007 6 Multilink Subnet Issues 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 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 IETF Trust (2007). 36 Abstract 38 There have been several proposals around the notion that a subnet 39 may span multiple links connected by routers. This memo documents 40 the issues and potential problems that have been raised with such an 41 approach. 43 Draft Multilink Subnet Issues January 2007 45 Table of Contents 47 1. Introduction.................................................2 48 2. Issues.......................................................3 49 2.1. IP Model...................................................3 50 2.2. TTL/Hop Limit Issues.......................................4 51 2.3. Link-scoped multicast and broadcast........................6 52 2.4. Duplicate Address Detection Issues.........................7 53 3. Security Considerations......................................8 54 4. Recommendations..............................................8 55 4.1. IP Link Model..............................................8 56 4.2. IPv6 Address Assignment...................................10 57 4.3. Duplicate Address Detection Optimizations.................11 58 5. IANA Considerations.........................................12 59 6. Normative References........................................12 60 7. Informative References......................................13 61 IAB Members at the time of this writing..........................15 62 Author's Address.................................................16 63 Full Copyright Statement.........................................17 64 Intellectual Property............................................17 66 1. Introduction 68 The original IPv4 address definition [RFC791] consisted of a Network 69 field, identifying a network number, and a Local Address field, 70 identifying a host within that network. As organizations grew to 71 want many links within their network, their choices were (from 72 [RFC950]) to: 74 1. Acquire a distinct Internet network number for each cable; 75 subnets are not used at all. 77 2. Use a single network number for the entire organization, but 78 assign host numbers without regard to which LAN a host is on 79 ("transparent subnets"). 81 3. Use a single network number, and partition the host address 82 space by assigning subnet numbers to the LANs ("explicit 83 subnets"). 85 [RFC925] was a proposal for option 2 which defined a specific type 86 of ARP proxy behavior, where the forwarding plane had the properties 87 of decrementing the TTL to prevent loops when forwarding, not 88 forwarding packets destined to 255.255.255.255, and supporting 89 subnet broadcast by requiring that the ARP-based bridge maintain a 90 list of recent broadcast packets. This approach was never 91 standardized, although [RFC1027] later documented an implementation 92 of a subset of [RFC925]. 94 Draft Multilink Subnet Issues January 2007 96 Instead, the IETF standardized option 3 with [RFC950], whereby hosts 97 were required to learn a subnet mask, and this became the IPv4 98 model. 100 Over the recent past there have been several newer protocols 101 proposing to extend the notion of a subnet to be able to span 102 multiple links, similar to [RFC925]. 104 Early drafts of the IPv6 scoped address architecture [SCOPID] 105 proposed a subnet scope above the link scope, to allow for multi- 106 link subnets. This notion was rejected by the WG due to the issues 107 discussed in this memo, and as a result the final version [RFC4007] 108 has no such notion. 110 There was also a proposal to define multi-link subnets [MLSR] for 111 IPv6. However this notion was abandoned by the IPv6 WG due to the 112 issues discussed in this memo, and that proposal was replaced by a 113 different mechanism which preserves the notion that a subnet spans 114 only one link [RFC4389]. 116 However, other WGs continued to allow for this concept even though 117 it had been rejected in the IPv6 WG. Mobile IPv6 [RFC3775] allows 118 tunnels to mobile nodes to use the same subnet as a home link, with 119 the Home Agent doing layer 3 forwarding between them. 121 The notion also arises in Mobile Ad-hoc NETworks (MANETs) with 122 proposals that an entire MANET is a subnet, with routers doing 123 layer 3 forwarding within it. 125 The use of multilink subnets has also been considered by other 126 working groups, including NetLMM, 16ng, and Autoconf, and by other 127 external organizations such as WiMax. 129 In this memo we document the issues raised in the IPv6 WG which 130 motivated the abandonment of the multi-link subnet concept, so that 131 designers of other protocols can (and should) be aware of the 132 issues. 134 The key words "MUST", "RECOMMENDED", and "SHOULD" in this document 135 are to be interpreted as described in [RFC2119]. 137 2. Issues 139 2.1. IP Model 141 The term "link" is generally used to refer to a topological area 142 bounded by routers which decrement the IPv4 TTL or IPv6 Hop Limit 143 when forwarding the packet. A link-local address prefix is defined 144 in both IPv4 [RFC3927] and IPv6 [RFC4291]. 146 The term "subnet" is generally used to refer to a topological area 147 that uses the same address prefix, where that prefix is not further 148 subdivided except into individual addresses. 150 Draft Multilink Subnet Issues January 2007 152 In December 1995, the original IP Version 6 Addressing Architecture 153 [RFC1884] was published, stating: "IPv6 continues the IPv4 model 154 that a subnet is associated with one link. Multiple subnets may be 155 assigned to the same link." 157 Thus it explicitly acknowledges that the current IPv4 model has been 158 that a subnet is associated with one link, and that IPv6 does not 159 change this model. Furthermore, a subnet is sometimes considered to 160 be only a subset of a link, when multiple subnets are assigned to 161 the same link. 163 The IPv6 addressing architecture has since been updated three times, 164 first in July 1998 [RFC2373], then April 2003 [RFC3513], and finally 165 in February 2006 [RFC4291]. All updates include the language: 166 "Currently IPv6 continues the IPv4 model that a subnet prefix is 167 associated with one link. Multiple subnet prefixes may be assigned 168 to the same link." 170 Clearly the notion of a multi-link subnet would be a change to the 171 existing IP model. 173 Similarly, the Mobility Related Terminology [RFC3753] defines a 174 Foreign subnet prefix as "A bit string that consists of some number 175 of initial bits of an IP address which identifies a node's foreign 176 link within the Internet topology" with a similar definition for a 177 Home subnet prefix. These both state that the subnet prefix 178 identifies a (singular) link. 180 2.2. TTL/Hop Limit Issues 182 Since a link is bounded by routers that decrement the IPv4 TTL or 183 IPv6 Hop Limit, there may be issues with applications and protocols 184 that make any assumption about the relationship between TTL/Hop 185 Limit and subnet prefix. 187 There are two main cases which may arise. Some applications and 188 protocols may send packets with a TTL/Hop Limit of 1. Other 189 applications and protocols may send packets with a TTL/Hop Limit of 190 255, and verify that the value is 255 on receipt. Both are ways of 191 limiting communication to within a single link, although the effects 192 of these two approaches are quite different. Setting TTL/Hop Limit 193 to 1 ensures that packets that are sent do not leave the link, but 194 it does not prevent an off-link attacker from sending a packet that 195 can reach the link. Checking that TTL/Hop Limit is 255 on receipt 196 prevents a receiver from accepting packets from an off-link sender, 197 but it doesn't prevent a sent packet from being forwarded off-link. 199 As for assumptions about the relationship between TTL/Hop Limit and 200 subnet, let's look at some example references familiar to many 201 protocol and application developers. 203 Stevens' "Unix Network Programming, 2nd ed." [UNP] states on page 204 490 "a TTL if 0 means node-local, 1 means link-local" (this of 205 Draft Multilink Subnet Issues January 2007 207 course being true by the definition of link). Then page 498 states, 208 regarding IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, "If this is not 209 specified, both default to 1, which restricts the datagram to the 210 local subnet." Here, Unix programmers learn that TTL=1 packets are 211 restricted to a subnet (as opposed to a link). This is typical of 212 many documents which use the terms interchangeably due to the IP 213 Model described earlier. 215 Similarly, "TCP/IP Illustrated, Volume 1" [TCPILL] states on page 216 182: "By default, multicast datagrams are sent with a TTL of 1. This 217 restricts the datagram to the same subnet." 219 Steve Deering's original multicast README file [DEERING] contained 220 the statement "multicast datagrams with initial TTL 1 are restricted 221 to the same subnet", and similar statements now appear in many 222 vendors' documentation, including documentation for Windows (e.g., 223 [TCPIP2K]) and Linux (e.g., [LINUX] says a TTL of 1 is "Restricted 224 to the same subnet. Won't be forwarded by a router.") 226 The above are only some examples. There is no shortage of places 227 where application developers are being taught that a subnet is 228 confined to a single link, and so we must expect that arbitrary 229 applications may embed such assumptions. 231 Some examples of protocols today that are known to embed some 232 assumption about the relationship between TTL and subnet prefix are: 234 o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit 235 255 checked on receipt, to resolve the link-layer address of any 236 IP address in the subnet. 238 o Older clients of Apple's Bonjour [MDNS] use messages with TTL 239 255 checked on receipt, and only respond to queries from 240 addresses in the same subnet. (Note that multilink subnets do 241 not necessarily break this, as this behavior is to constrain 242 communication to within a subnet, where a subnet is only a 243 subset of a link; however it will not work across a multi-link 244 subnet.) 246 Some other examples of protocols today that are known to use a TTL 1 247 or 255, but do not appear to explicitly have any assumption about the 248 relationship to subnet prefixes (other than the well-known link-local 249 prefix) include: 251 o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop 252 Limit of 1 for TCP. 254 o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 255 1. 257 o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 checked 258 on receipt for Registration Requests sent to foreign agents. 260 Draft Multilink Subnet Issues January 2007 262 o [RFC3927] discusses the use of TTL=1 and TTL=255 within the IPv4 263 link-local address prefix. 265 It is unknown whether any implementations of such protocols exist 266 that add such assumptions about the relationship to subnet prefixes 267 for other reasons. 269 2.3. Link-scoped multicast and broadcast 271 Because multicast routing is not ubiquitous, the notion of a subnet 272 which spans multiple links tends to result in cases where multicast 273 does not work across the subnet. Per [RFC2644], the default 274 behavior is that routers do not forward directed broadcast packets 275 either, nor do they forward limited broadcasts (see [RFC1812] 276 Section 4.2.2.11). 278 There are many protocols and applications today that use link-scoped 279 multicast. The list of such applications and protocols that have 280 been assigned their own link-scoped multicast group address (and may 281 also have assumptions about the TTL/Hop Limit as noted above) can be 282 found at: 284 http://www.iana.org/assignments/multicast-addresses 286 http://www.iana.org/assignments/ipv6-multicast-addresses 288 In addition, an arbitrarily large number of other applications may 289 be using the all-1's broadcast address, or the all-hosts link-scoped 290 multicast address, rather than their own group address. 292 The well-known examples of protocols using link-scoped multicast or 293 broadcast generally fall into one of the following groups: 295 o Routing protocols: DVMRP [DVMRP], OSPF [RFC2328], RIP 296 [RFC2453][RFC2080], EIGRP [EIGRP], etc. These protocols 297 exchange routes to subnet prefixes. 299 o Address management protocols: Neighbor Discovery, DHCPv4 300 [RFC2131], DHCPv6 [RFC3315], Teredo [RFC4380], etc. By their 301 nature this group tends to embed assumptions about the 302 relationship between a link and a subnet prefix. For example, 303 ND uses link-scoped multicast to resolve the link-layer address 304 of an IP address in the same subnet prefix, and to do duplicate 305 address detection (see section 2.4 below) within the subnet. 306 DHCP uses link-scoped multicast or broadcast to obtain an 307 address in the subnet. Teredo states: "An IPv4 multicast 308 address used to discover other Teredo clients on the same IPv4 309 subnet. The value of this address is 224.0.0.253", which is a 310 link-scoped multicast address. It also says "the client MUST 311 silently discard all local discovery bubbles [...] whose IPv4 312 source address does not belong to the local IPv4 subnet". 314 Draft Multilink Subnet Issues January 2007 316 o Service discovery protocols: SSDP [SSDP], Bonjour, WS-Discovery 317 [WSDISC], etc. These often do not define any explicit 318 assumption about the relationship to subnet prefix. 320 o Name resolution protocols: NetBios [RFC1001], Bonjour, LLMNR, 321 etc. Most often these do not define any explicit assumption 322 about the relationship to subnet prefix, but Bonjour only 323 responds to queries from addresses within the same subnet 324 prefix. 326 Note that protocols such as Bonjour and Teredo which drop packets 327 which don't come from an address within the subnet are not 328 necessarily broken by multilink subnets, as this behavior is meant to 329 constrain the behavior to within a subnet, when a link is larger than 330 a single subnet. 332 However, regardless of whether any assumption about the relationship 333 to subnet prefixes exists, all protocols mentioned above or on the 334 IANA assignments lists will not work across a multilink subnet 335 without protocol-specific proxying functionality in routers, and 336 adding proxying for an arbitrary number of protocols and applications 337 does not scale. Furthermore, it may hinder the development and use 338 of future protocols using link-scoped multicast. 340 2.4. Duplicate Address Detection Issues 342 Duplicate Address Detection (DAD) uses link-scoped multicast in IPv6 343 and link-scoped broadcast in IPv4 and so has the issues mentioned in 344 Section 2.3 above. 346 In addition, [RFC2462] contains the statement: 348 "Thus, for a set of addresses formed from the same interface 349 identifier, it is sufficient to check that the link-local address 350 generated from the identifier is unique on the link. In such 351 cases, the link-local address MUST be tested for uniqueness, and 352 if no duplicate address is detected, an implementation MAY choose 353 to skip Duplicate Address Detection for additional addresses 354 derived from the same interface identifier." 356 The last possibility, sometimes referred to as Duplicate Interface 357 Identifier Detection (DIID), has been a matter of much debate, and 358 the current draft in progress [2462BIS] states: 360 Each individual unicast address SHOULD be tested for uniqueness. 361 Note that there are implementations deployed that only perform 362 Duplicate Address Detection for the link-local address and skip 363 the test for the global address using the same interface 364 identifier as that of the link-local address. Whereas this 365 document does not invalidate such implementations, this kind of 366 "optimization" is NOT RECOMMENDED, and new implementations MUST 367 NOT do that optimization. 369 Draft Multilink Subnet Issues January 2007 371 The existence of such implementations also causes problems with 372 multilink subnets. Specifically, a link-local address is only valid 373 within a link, and hence is only tested for uniqueness within a 374 single link. If the same interface identifier is then assumed to be 375 unique across all links within a multilink subnet, address conflicts 376 can occur. 378 3. Security Considerations 380 The notion of multilink subnets can cause problems with any security 381 protocols which either rely on the assumption that a subnet only 382 spans a single link, or can leave gaps in the security solution 383 where protocols are only defined for use on a single link. 385 Secure Neighbor Discovery (SEND) [RFC3971], in particular, is 386 currently only defined within a single link. If a subnet were to 387 span multiple links, SEND would not work as currently specified, 388 since it secures Neighbor Discovery messages which include link- 389 layer addresses, and if forwarded to other links, the link-layer 390 address of the sender will be different. This same problem also 391 exists in cases where a subnet does not span multiple links but 392 where Neighbor Discovery is proxied within a link. Section 9 of 393 [RFC4389] discusses some possible future directions in this regard. 395 Furthermore, as noted above some applications and protocols (ND, 396 Bonjour, Mobile IPv4, etc.) mitigate against off-link spoofing 397 attempts by requiring a TTL or Hop Limit of 255 on receipt. If this 398 restriction were removed, or if alternative protocols were used, 399 then off-link spoofing attempts would become easier, and some 400 alternative way to mitigate such attacks would be needed. 402 4. Recommendations 404 4.1. IP Link Model 406 There are two models which do not have the issues pointed out in the 407 rest of the document. 409 The IAB recommends that protocol designers use one of the following 410 two models: 412 o Multiaccess link model: In this model, there can be multiple 413 nodes on the same link, including zero or more routers. Data 414 packets sent to the IPv4 link-local broadcast address 415 (255.255.255.255) or to a link-local multicast address can be 416 received by all other interested nodes on the link. Two nodes on 417 the link are able to communicate without any IPv4 TTL or IPv6 Hop 418 Limit decrement. There can be any number of layer 2 devices 419 (bridges, switches, access points, whatever) in the middle of the 420 link. 422 Draft Multilink Subnet Issues January 2007 424 o Point-to-point link model: In this model, there are exactly two 425 nodes on the same link. Data packets sent to the IPv4 link-local 426 broadcast address or to a link-local multicast address can be 427 received by the other node on the link. The two nodes are able 428 to communicate without any IPv4 TTL or IPv6 Hop Limit decrement. 429 There can be any number of layer 2 devices (bridges, switches, 430 access points, whatever) in the middle of the link. 432 A variant of the multi-access link model, which has fewer issues, 433 but still some, is: 435 o Non-broadcast multi-access (NBMA) model: Same as the multi-access 436 link model, except that no broadcast or multicast packets can be 437 sent, even between two nodes on the same link. As a result, no 438 protocols or applications which make use of broadcast or 439 multicast will work. 441 Links that appear as NBMA links at layer 3 are problematic. 442 Instead, if a link is an NBMA link at layer 2, then protocol 443 designers should define some mechanism such that it appears as 444 either the multi-access link model or point-to-point link model at 445 layer 3. 447 One use of an NBMA link is when the link itself is intended as a 448 wide-area link (e.g., a tunnel such as 6to4 [RFC3056]) where none of 449 the groups of functionality in section 2.3 are required across the 450 wide area. Admittedly, the definition of wide-area is somewhat 451 subjective. Support for multicast on a wide-area link would be 452 analogous to supporting multicast routing across a series of local- 453 area links. The issues discussed in section 2.3 will arise, but may 454 be acceptable over a wide area until multicast routing is also 455 supported. 457 Note that the distinction of whether a link is a tunnel or not is 458 orthogonal to the choice of model; there exist tunnel links for all 459 link models mentioned above. 461 A multilink subnet model should be avoided. IETF working groups 462 using, or considering using, multilink subnets today should 463 investigate moving to one of the other models. For example, the 464 Mobile IPv6 WG should investigate having the Home Agent not 465 decrement the Hop Limit, and forward multicast traffic. 467 When considering changing an existing multilink subnet solution to 468 another model, the following issues should be considered: 470 Draft Multilink Subnet Issues January 2007 472 Loop prevention: If physical loops cannot exist within the subnet, 473 then removing the TTL/Hop Limit decrement is not an issue. 474 Otherwise, protocol designers can (for example) retain the 475 decrement but use a separate prefix per link, or use some form 476 of bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]). 478 Limiting broadcast (including all-hosts multicast): If there is no 479 efficiency requirement to prevent broadcast from going to other 480 on-link hosts, then flooding it within the subnet is not an 481 issue. Otherwise, protocol designers can (for example) use a 482 separate prefix per link, or flood broadcast other than ARP 483 within the subnet (ARP is covered below in section 4.3). 485 Limiting the scope of other multicast (including IPv6 Neighbor 486 Discovery): If there is no efficiency requirement to prevent 487 multicast from going to other on-link hosts, then flooding 488 multicast within the subnet is not an issue. Otherwise, 489 protocol designers can (for example) use a separate prefix per 490 link, or use IGMP/MLD snooping [RFC4541] instead. 492 4.2. IPv6 Address Assignment 494 In IPv6, the Prefix Information Option in a Router Advertisement 495 (RA) is defined for use by a router to advertise an on-link prefix. 496 That is, it indicates that a prefix is assigned to the link over 497 which the RA is sent/received. That is, the router and the node 498 both have an on-link route in their routing table (or on-link Prefix 499 List, in the conceptual model of a host in [RFC2461]), and any 500 addresses used in the prefix are assigned to an interface (on any 501 node) attached to that. 503 In contrast, DHCPv6 Prefix Delegation (DHCP-PD) [RFC3633] is defined 504 for use by a client to request a prefix for use on a different 505 link. Section 12.1 of RFC 3633 states: 507 Upon the receipt of a valid Reply message, for each IA_PD the 508 requesting router assigns a subnet from each of the delegated 509 prefixes to each of the links to which the associated interfaces 510 are attached, with the following exception: the requesting router 511 MUST NOT assign any delegated prefixes or subnets from the 512 delegated prefix(es) to the link through which it received the 513 DHCP message from the delegating router. 515 Hence, the upstream router has a route in its routing table that is 516 not on-link, but points to the client; the prefix is assigned to a 517 link other than the one over which DHCP-PD was done; and any 518 Draft Multilink Subnet Issues January 2007 520 addresses used in the prefix are assigned to an interface (on any 521 node) attached to that other link. 523 The IAB believes that the distinction between these two cases 524 (assigning a prefix to the same link vs. another link) is important, 525 and that the IETF protocols noted above are appropriate for the two 526 scenarios noted. The IAB recommends that other protocol designers 527 remain consistent with the IETF-defined scopes of these protocols 528 (e.g., not using DHCP-PD to assign a prefix to the same link, or 529 using RAs to assign a prefix to another link). 531 In addition, the Prefix Information Option contains an L (on-link) 532 flag. Normally this flag is set, indicating that this prefix can be 533 used for on-link determination. When not set the advertisement 534 makes no statement about on-link or off-link properties of the 535 prefix. For instance, the prefix might be used for address 536 configuration with some of the addresses belonging to the prefix 537 being on-link and others being off-link. Care must be taken when 538 the L flag is not set. Specifically, some platforms allow 539 applications to retrieve the prefix length associated with each 540 address of the node. If an implementation were to return the prefix 541 length used for address configuration, then applications may 542 incorrectly assume that TTL=1 is sufficient for communication, and 543 that link-scoped multicast will reach other addresses in the prefix. 544 As a result, the IAB recommends to designers and maintainers of APIs 545 that provide a prefix length to applications, that they address this 546 issue. For example, they might indicate that no prefix length 547 exists when the prefix is not on-link. If the API is not capable of 548 reporting that one does not exist, then they might choose to report 549 a value of 128 when the prefix is not on-link. This would result in 550 such applications believing they are on separate subnets, rather 551 than on a multilink subnet. 553 4.3. Duplicate Address Detection Optimizations 555 One of the reasons sometimes cited for wanting a multilink subnet 556 model (rather than a multi-access link model), is to minimize the 557 ARP/ND traffic between end-nodes. This is primarily a concern in 558 IPv4 where ARP results in a broadcast that would be seen by all 559 nodes, not just the node with the IPv4 address being resolved. Even 560 if this is a significant concern, the use of a multilink subnet 561 model is not necessary. The point-to-point link model is one way to 562 avoid this issue entirely. 564 In the multi-access link model, IPv6 ND traffic can be reduced by 565 using well-known multicast learning techniques (e.g., [RFC4541] at a 566 Draft Multilink Subnet Issues January 2007 568 layer 2 intermediate device (bridge, switch, access point, 569 whatever). 571 Some have suggested that a layer 2 device could maintain an ARP or 572 ND cache and service requests from that cache. However, such a 573 cache prevents any type of fast mobility between layer 2 ports, and 574 breaks Secure Neighbor Discovery [RFC3971]. As a result, the IAB 575 recommends to protocol designers that this approach be avoided, 576 instead using an alternative such as layer 2 learning. For IPv4 577 (where no Secure ARP exists) the IAB recommends that protocol 578 designers avoid having a device respond from its cache in cases 579 where a node can legitimately move between layer 2 segments of the 580 link without any layer 2 indications at the layer 2 intermediate 581 device. Also, since currently there is no guarantee that any device 582 other than the end host knows all addresses of the end host, 583 protocol designers should avoid any dependency on such an 584 assumption. For example, when no cache entry for a given request is 585 found, protocol designers may specify that a node broadcast the 586 request to all nodes. 588 5. IANA Considerations 590 This document has no actions for IANA. 592 6. Normative References 594 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 595 1981. 597 [RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting 598 Procedure", STD 5, RFC 950, August 1985. 600 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 601 1812, June 1995. 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 607 Discovery for IP Version 6 (IPv6)", RFC 2461, December 608 1998. 610 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 611 Autoconfiguration", RFC 2462, December 1998. 613 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 614 in Routers", BCP 34, RFC 2644, August 1999. 616 Draft Multilink Subnet Issues January 2007 618 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 619 Host Configuration Protocol (DHCP) version 6", RFC 3633, 620 December 2003. 622 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 623 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 624 2005. 626 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 627 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 629 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 630 B. Zill. "IPv6 Scoped Address Architecture", RFC 4007, 631 March 2005. 633 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 634 Architecture", RFC 4291, February 2006. 636 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 637 "Considerations for Internet Group Management Protocol 638 (IGMP) and Multicast Listener Discovery (MLD) Snooping 639 Switches", RFC 4541, May 2006. 641 7. Informative References 643 [2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 644 Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis- 645 08.txt, May 2005. 647 [BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", 648 ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/ 649 getieee802/download/802.1D-2004.pdf. 651 [DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and 652 related systems (MULTICAST 1.2 Release)", June 1989. 653 http://www.kohala.com/start/mcast.api.txt 655 [DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance 656 Vector Multicast Routing Protocol", RFC 1075, November 657 1988. 659 [EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco 660 Document ID 16406, September 2005. 661 http://www.cisco.com/warp/public/103/eigrp-toc.html 663 [LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO", 664 March 1998. http://www.linux.com/howtos/Multicast-HOWTO- 665 2.shtml 667 [LLMNR] Aboba, B., Thaler, D. and L. Esibov, "Linklocal Multicast 668 Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-47.txt, 669 August 2006. 671 Draft Multilink Subnet Issues January 2007 673 [MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet 674 Draft, June 2005. http://files.multicastdns.org/draft- 675 cheshire-dnsext-multicastdns.txt 677 [MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in 678 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt (expired), 679 June 2002. http://www.ietf.org/proceedings/02jul/I- 680 D/draft-ietf-ipv6-multilink-subnets-00.txt 682 [RBRIDGE] Perlman, R., and J. Touch, "Rbridges: Base Protocol 683 Specification", draft-ietf-trill-rbridge-protocol-00.txt, 684 May 2006. 686 [RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, 687 October 1984. 689 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 690 Projects Agency, Internet Activities Board, End-to-End 691 Services Task Force, "Protocol standard for a NetBIOS 692 service on a TCP/UDP transport: Concepts and methods", RFC 693 1001, March 1987. 695 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 696 implement transparent subnet gateways", RFC 1027, October 697 1987. 699 [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing 700 Architecture", RFC 1884, December 1995. 702 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 703 January 1997. 705 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 706 2131, March 1997. 708 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 710 [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing 711 Architecture", RFC 2373, July 1998. 713 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 714 1998. 716 [RFC3024] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, 717 revised", RFC 3024, January 2001. 719 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 720 via IPv4 Clouds", RFC 3056, February 2001. 722 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 723 and M. Carney, "Dynamic Host Configuration Protocol for 724 IPv6 (DHCPv6)", RFC 3315, July 2003. 726 Draft Multilink Subnet Issues January 2007 728 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 729 (IPv6) Addressing Architecture", RFC 3513, April 2003. 731 [RFC3753] J. Manner, Ed., M. Kojo, Ed., "Mobility Related 732 Terminology", RFC 3753, June 2004. 734 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 735 in IPv6", RFC 3775, June 2004. 737 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 738 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 740 [RFC4380] C. Huitema, "Teredo: Tunneling IPv6 over UDP through 741 Network Address Translations (NATs)", RFC 4380, February 742 2006. 744 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 745 Proxies (ND Proxy)", RFC 4389, February 2006. 747 [SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, 748 A., and B. Zill, "IPv6 Scoped Address Architecture", 749 Internet-Draft (Obsolete), March 2005. 750 http://www.ietf.org/proceedings/02jul/I-D/draft-ietf- 751 ipngwg-scoping-arch-04.txt 753 [SSDP] Goland, Yaron Y., Cai, T., Leach, P., Gu, Y., and S. 754 Albright, "Simple Service Discovery Protocol (SSDP)", 755 1999. http://www.upnp.org/resources/specifications.asp 757 [TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", 758 Addison-Wesley, 1994. 760 [TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000 761 TCP/IP Implementation Details". 762 http://www.microsoft.com/technet/itsolutions/network/deplo 763 y/depovg/tcpip2k.mspx 765 [UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1, 766 Second Edition", Prentice Hall, 1998. 768 [WSDISC] Microsoft, "Web Services Dynamic Discovery (WS- 769 Discovery)", 2005. 770 http://specs.xmlsoap.org/ws/2005/04/discovery/ws- 771 discovery.pdf 773 IAB Members at the time of this writing 775 Bernard Aboba 776 Loa Andersson 777 Brian Carpenter 778 Leslie Daigle 779 Elwyn Davies 780 Draft Multilink Subnet Issues January 2007 782 Kevin Fall 783 Olaf Kolkman 784 Kurtis Lindqvist 785 David Meyer 786 David Oran 787 Eric Rescorla 788 Dave Thaler 789 Lixia Zhang 791 Author's Address 793 Dave Thaler 794 Microsoft 795 One Microsoft Way 796 Redmond, WA 98052 797 Phone: +1 425 703 8835 798 Email: dthaler@microsoft.com 799 Draft Multilink Subnet Issues January 2007 801 Full Copyright Statement 803 Copyright (C) The IETF Trust (2007). 805 This document is subject to the rights, licenses and restrictions 806 contained in BCP 78, and except as set forth therein, the authors 807 retain all their rights. 809 This document and the information contained herein are provided on 810 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 811 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 812 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 813 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 814 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 815 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 816 FOR A PARTICULAR PURPOSE. 818 Intellectual Property 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed 822 to pertain to the implementation or use of the technology described 823 in this document or the extent to which any license under such 824 rights might or might not be available; nor does it represent that 825 it has made any independent effort to identify any such rights. 826 Information on the procedures with respect to rights in RFC 827 documents can be found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use 832 of such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository 834 at http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 this standard. Please address the information to the IETF at ietf- 840 ipr@ietf.org. 842 IAB Expires February 2007 17