From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4903.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc4903.txt (limited to 'doc/rfc/rfc4903.txt') diff --git a/doc/rfc/rfc4903.txt b/doc/rfc/rfc4903.txt new file mode 100644 index 0000000..f2e83b6 --- /dev/null +++ b/doc/rfc/rfc4903.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group D. Thaler +Request for Comments: 4903 Internet Architecture Board +Category: Informational June 2007 + + + Multi-Link Subnet Issues + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + There have been several proposals around the notion that a subnet may + span multiple links connected by routers. This memo documents the + issues and potential problems that have been raised with such an + approach. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Issues ..........................................................3 + 2.1. IP Model ...................................................3 + 2.2. TTL/Hop Limit Issues .......................................4 + 2.3. Link-scoped Multicast and Broadcast ........................6 + 2.4. Duplicate Address Detection Issues .........................7 + 3. Security Considerations .........................................8 + 4. Recommendations .................................................9 + 4.1. IP Link Model ..............................................9 + 4.2. IPv6 Address Assignment ...................................10 + 4.3. Duplicate Address Detection Optimizations .................12 + 5. Normative References ...........................................12 + 6. Informative References .........................................13 + + + + + + + + + + + + +Thaler Informational [Page 1] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + +1. Introduction + + The original IPv4 address definition [RFC791] consisted of a Network + field, identifying a network number, and a Local Address field, + identifying a host within that network. As organizations grew to + want many links within their network, their choices were (from + [RFC950]) to: + + 1. Acquire a distinct Internet network number for each cable; + subnets are not used at all. + + 2. Use a single network number for the entire organization, but + assign host numbers without regard to which LAN a host is on + ("transparent subnets"). + + 3. Use a single network number, and partition the host address + space by assigning subnet numbers to the LANs ("explicit + subnets"). + + [RFC925] was a proposal for option 2 that defined a specific type of + Address Resolution Protocol (ARP) proxy behavior, where the + forwarding plane had the properties of decrementing the Time To Live + (TTL) to prevent loops when forwarding, not forwarding packets + destined to 255.255.255.255, and supporting subnet broadcast by + requiring that the ARP-based bridge maintain a list of recent + broadcast packets. This approach was never standardized, although + [RFC1027] later documented an implementation of a subset of [RFC925]. + + Instead, the IETF standardized option 3 with [RFC950], whereby hosts + were required to learn a subnet mask, and this became the IPv4 model. + + Over the recent past, there have been several newer protocols + proposing to extend the notion of a subnet to be able to span + multiple links, similar to [RFC925]. + + Early versions of the IPv6 scoped address architecture [SCOPID] + proposed a subnet scope above the link scope, to allow for multi-link + subnets. This notion was rejected by the WG due to the issues + discussed in this memo, and as a result the final version [RFC4007] + has no such notion. + + There was also a proposal to define multi-link subnets [MLSR] for + IPv6. However, this notion was abandoned by the IPv6 WG due to the + issues discussed in this memo, and that proposal was replaced by a + different mechanism that preserves the notion that a subnet spans + only one link [RFC4389]. + + + + + +Thaler Informational [Page 2] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + However, other WGs continued to allow for this concept even though it + had been rejected in the IPv6 WG. Mobile IPv6 [RFC3775] allows + tunnels to mobile nodes to use the same subnet as a home link, with + the Home Agent doing layer 3 forwarding between them. + + The notion also arises in Mobile Ad-hoc NETworks (MANETs) with + proposals that an entire MANET is a subnet, with routers doing layer + 3 forwarding within it. + + The use of multi-link subnets has also been considered by other + working groups, including NetLMM, 16ng, and Autoconf, and by other + external organizations such as WiMax. + + In this memo, we document the issues raised in the IPv6 WG which + motivated the abandonment of the multi-link subnet concept, so that + designers of other protocols can (and should) be aware of the issues. + + The key words "MUST", "RECOMMENDED", and "SHOULD" in this document + are to be interpreted as described in [RFC2119]. + +2. Issues + +2.1. IP Model + + The term "link" is generally used to refer to a topological area + bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit when + forwarding the packet. A link-local address prefix is defined in + both IPv4 [RFC3927] and IPv6 [RFC4291]. + + The term "subnet" is generally used to refer to a topological area + that uses the same address prefix, where that prefix is not further + subdivided except into individual addresses. + + In December 1995, the original IP Version 6 Addressing Architecture + [RFC1884] was published, stating: "IPv6 continues the IPv4 model that + a subnet is associated with one link. Multiple subnets may be + assigned to the same link." + + Thus, it explicitly acknowledges that the current IPv4 model has been + that a subnet is associated with one link and that IPv6 does not + change this model. Furthermore, a subnet is sometimes considered to + be only a subset of a link, when multiple subnets are assigned to the + same link. + + The IPv6 addressing architecture has since been updated three times, + first in July 1998 [RFC2373], then April 2003 [RFC3513], and finally + in February 2006 [RFC4291]. All updates include the language: + "Currently IPv6 continues the IPv4 model that a subnet prefix is + + + +Thaler Informational [Page 3] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + associated with one link. Multiple subnet prefixes may be assigned + to the same link." + + Clearly, the notion of a multi-link subnet would be a change to the + existing IP model. + + Similarly, the Mobility Related Terminology [RFC3753] defines a + Foreign subnet prefix as "a bit string that consists of some number + of initial bits of an IP address which identifies a node's foreign + link within the Internet topology" with a similar definition for a + Home subnet prefix. These both state that the subnet prefix + identifies a (singular) link. + +2.2. TTL/Hop Limit Issues + + Since a link is bounded by routers that decrement the IPv4 TTL or + IPv6 Hop Limit, there may be issues with applications and protocols + that make any assumption about the relationship between TTL/Hop Limit + and subnet prefix. + + There are two main cases that may arise. Some applications and + protocols may send packets with a TTL/Hop Limit of 1. Other + applications and protocols may send packets with a TTL/Hop Limit of + 255 and verify that the value is 255 on receipt. Both are ways of + limiting communication to within a single link, although the effects + of these two approaches are quite different. Setting TTL/Hop Limit + to 1 ensures that packets that are sent do not leave the link, but it + does not prevent an off-link attacker from sending a packet that can + reach the link. Checking that TTL/Hop Limit is 255 on receipt + prevents a receiver from accepting packets from an off-link sender, + but it doesn't prevent a sent packet from being forwarded off-link. + + As for assumptions about the relationship between TTL/Hop Limit and + subnet, let's look at some example references familiar to many + protocol and application developers. + + Stevens' "Unix Network Programming", 2nd ed. [UNP], states on page + 490, "A TTL of 0 means node-local, 1 means link-local" (this of + course being true by the definition of link). Then page 498 states, + regarding IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, "If this is not + specified, both default to 1, which restricts the datagram to the + local subnet." Here, Unix programmers learn that TTL=1 packets are + restricted to a subnet (as opposed to a link). This is typical of + many documents that use the terms interchangeably due to the IP model + described earlier. + + + + + + +Thaler Informational [Page 4] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + Similarly, "TCP/IP Illustrated", Volume 1 [TCPILL], states on page + 182: "By default, multicast datagrams are sent with a TTL of 1. This + restricts the datagram to the same subnet." + + Steve Deering's original multicast README file [DEERING] contained + the statement "multicast datagrams with initial TTL 1 are restricted + to the same subnet", and similar statements now appear in many + vendors' documentation, including documentation for Windows (e.g., + [TCPIP2K]) and Linux (e.g., [LINUX] says a TTL of 1 is "restricted to + the same subnet. Won't be forwarded by a router.") + + The above are only some examples. There is no shortage of places + where application developers are being taught that a subnet is + confined to a single link, and so we must expect that arbitrary + applications may embed such assumptions. + + Some examples of protocols today that are known to embed some + assumption about the relationship between TTL and subnet prefix are + the following: + + o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit + 255 checked on receipt, to resolve the link-layer address of + any IP address in the subnet. + + o Older clients of Apple's Bonjour [MDNS] use messages with TTL + 255 checked on receipt, and only respond to queries from + addresses in the same subnet. (Note that multi-link subnets do + not necessarily break this, as this behavior is to constrain + communication to within a subnet, where a subnet is only a + subset of a link. However, it will not work across a multi- + link subnet.) + + Some other examples of protocols today that are known to use a TTL 1 + or 255, but do not appear to explicitly have any assumption about the + relationship to subnet prefixes (other than the well-known link-local + prefix) include the following: + + o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop + Limit of 1 for TCP. + + o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit + of 1. + + o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 + checked on receipt for Registration Requests sent to foreign + agents. + + + + + +Thaler Informational [Page 5] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + o [RFC3927] discusses the use of TTL=1 and TTL=255 within the + IPv4 link-local address prefix. + + It is unknown whether any implementations of such protocols exist + that add such assumptions about the relationship to subnet prefixes + for other reasons. + +2.3. Link-scoped Multicast and Broadcast + + Because multicast routing is not ubiquitous, the notion of a subnet + that spans multiple links tends to result in cases where multicast + does not work across the subnet. Per [RFC2644], the default behavior + is that routers do not forward directed broadcast packets either, nor + do they forward limited broadcasts (see [RFC1812], Section 4.2.2.11). + + There are many protocols and applications today that use link-scoped + multicast. The list of such applications and protocols that have + been assigned their own link-scoped multicast group address (and may + also have assumptions about the TTL/Hop Limit as noted above) can be + found at: + + http://www.iana.org/assignments/multicast-addresses + + http://www.iana.org/assignments/ipv6-multicast-addresses + + In addition, an arbitrarily large number of other applications may be + using the all-1's broadcast address, or the all-hosts link-scoped + multicast address, rather than their own group address. + + The well-known examples of protocols using link-scoped multicast or + broadcast generally fall into one of the following groups: + + o Routing protocols: Distance Vector Multicast Routing Protocol + (DVMRP) [RFC1075], OSPF [RFC2328], RIP [RFC2453][RFC2080], + Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP], + etc. These protocols exchange routes to subnet prefixes. + + o Address management protocols: Neighbor Discovery, DHCPv4 + [RFC2131], Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) [RFC3315], Teredo [RFC4380], etc. By their nature, + this group tends to embed assumptions about the relationship + between a link and a subnet prefix. For example, ND uses + link-scoped multicast to resolve the link-layer address of an + IP address in the same subnet prefix, and to do duplicate + address detection (see Section 2.4 below) within the subnet. + DHCP uses link-scoped multicast or broadcast to obtain an + address in the subnet. Teredo states that the Teredo IPv4 + Discovery Address is "an IPv4 multicast address used to + + + +Thaler Informational [Page 6] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + discover other Teredo clients on the same IPv4 subnet. The + value of this address is 224.0.0.253", which is a link-scoped + multicast address. It also says that "the client MUST silently + discard all local discovery bubbles [...] whose IPv4 source + address does not belong to the local IPv4 subnet". + + o Service discovery protocols: Simple Service Discovery Protocol + (SSDP) [SSDP], Bonjour, WS-Discovery [WSDISC], etc. These + often do not define any explicit assumption about the + relationship to subnet prefix. + + o Name resolution protocols: NetBios [RFC1001], Bonjour, LLMNR, + etc. Most often these do not define any explicit assumption + about the relationship to subnet prefix, but Bonjour only + responds to queries from addresses within the same subnet + prefix. + + Note that protocols such as Bonjour and Teredo that drop packets that + don't come from an address within the subnet are not necessarily + broken by multi-link subnets, as this behavior is meant to constrain + the behavior to within a subnet, when a link is larger than a single + subnet. + + However, regardless of whether any assumption about the relationship + to subnet prefixes exists, all protocols mentioned above or on the + IANA assignments lists will not work across a multi-link subnet + without protocol-specific proxying functionality in routers, and + adding proxying for an arbitrary number of protocols and applications + does not scale. Furthermore, it may hinder the development and use + of future protocols using link-scoped multicast. + +2.4. Duplicate Address Detection Issues + + Duplicate Address Detection (DAD) uses link-scoped multicast in IPv6 + and link-scoped broadcast in IPv4 and so has the issues mentioned in + Section 2.3 above. + + In addition, [RFC2462] contains the statement: + + "Thus, for a set of addresses formed from the same interface + identifier, it is sufficient to check that the link-local address + generated from the identifier is unique on the link. In such + cases, the link-local address MUST be tested for uniqueness, and + if no duplicate address is detected, an implementation MAY choose + to skip Duplicate Address Detection for additional addresses + derived from the same interface identifier." + + + + + +Thaler Informational [Page 7] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + The last possibility, sometimes referred to as Duplicate Interface + Identifier Detection (DIID), has been a matter of much debate, and + the current work in progress [2462BIS] states: + + Each individual unicast address SHOULD be tested for uniqueness. + Note that there are implementations deployed that only perform + Duplicate Address Detection for the link-local address and skip + the test for the global address using the same interface + identifier as that of the link-local address. Whereas this + document does not invalidate such implementations, this kind of + "optimization" is NOT RECOMMENDED, and new implementations MUST + NOT do that optimization. + + The existence of such implementations also causes problems with + multi-link subnets. Specifically, a link-local address is only valid + within a link, and hence is only tested for uniqueness within a + single link. If the same interface identifier is then assumed to be + unique across all links within a multi-link subnet, address conflicts + can occur. + +3. Security Considerations + + The notion of multi-link subnets can cause problems with any security + protocols that either rely on the assumption that a subnet only spans + a single link or can leave gaps in the security solution where + protocols are only defined for use on a single link. + + Secure Neighbor Discovery (SEND) [RFC3971], in particular, is + currently only defined within a single link. If a subnet were to + span multiple links, SEND would not work as currently specified, + since it secures Neighbor Discovery messages that include link-layer + addresses, and if forwarded to other links, the link-layer address of + the sender will be different. This same problem also exists in cases + where a subnet does not span multiple links but where Neighbor + Discovery is proxied within a link. Section 9 of [RFC4389] discusses + some possible future directions in this regard. + + Furthermore, as noted above some applications and protocols (ND, + Bonjour, Mobile IPv4, etc.) mitigate against off-link spoofing + attempts by requiring a TTL or Hop Limit of 255 on receipt. If this + restriction were removed, or if alternative protocols were used, then + off-link spoofing attempts would become easier, and some alternative + way to mitigate such attacks would be needed. + + + + + + + + +Thaler Informational [Page 8] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + +4. Recommendations + +4.1. IP Link Model + + There are two models that do not have the issues pointed out in the + rest of the document. + + The IAB recommends that protocol designers use one of the following + two models: + + o Multi-access link model: In this model, there can be multiple + nodes on the same link, including zero or more routers. Data + packets sent to the IPv4 link-local broadcast address + (255.255.255.255) or to a link-local multicast address can be + received by all other interested nodes on the link. Two nodes + on the link are able to communicate without any IPv4 TTL or + IPv6 Hop Limit decrement. There can be any number of layer 2 + devices (bridges, switches, access points, etc.) in the middle + of the link. + + o Point-to-point link model: In this model, there are exactly two + nodes on the same link. Data packets sent to the IPv4 link- + local broadcast address or to a link-local multicast address + can be received by the other node on the link. The two nodes + are able to communicate without any IPv4 TTL or IPv6 Hop Limit + decrement. There can be any number of layer 2 devices + (bridges, switches, access points, etc.) in the middle of the + link. + + A variant of the multi-access link model, which has fewer issues, but + still some, is the following: + + o Non-broadcast multi-access (NBMA) model: Same as the multi- + access link model, except that no broadcast or multicast + packets can be sent, even between two nodes on the same link. + As a result, no protocols or applications that make use of + broadcast or multicast will work. + + Links that appear as NBMA links at layer 3 are problematic. Instead, + if a link is an NBMA link at layer 2, then protocol designers should + define some mechanism such that it appears as either the multi-access + link model or point-to-point link model at layer 3. + + One use of an NBMA link is when the link itself is intended as a + wide-area link (e.g., a tunnel such as 6to4 [RFC3056]) where none of + the groups of functionality in Section 2.3 are required across the + wide area. Admittedly, the definition of wide-area is somewhat + subjective. Support for multicast on a wide-area link would be + + + +Thaler Informational [Page 9] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + analogous to supporting multicast routing across a series of local- + area links. The issues discussed in Section 2.3 will arise, but may + be acceptable over a wide area until multicast routing is also + supported. + + Note that the distinction of whether or not a link is a tunnel is + orthogonal to the choice of model; there exist tunnel links for all + link models mentioned above. + + A multi-link subnet model should be avoided. IETF working groups + using, or considering using, multi-link subnets today should + investigate moving to one of the other models. For example, the + Mobile IPv6 WG should investigate having the Home Agent not decrement + the Hop Limit, and forward multicast traffic. + + When considering changing an existing multi-link subnet solution to + another model, the following issues should be considered: + + Loop prevention: If physical loops cannot exist within the subnet, + then removing the TTL/Hop Limit decrement is not an issue. + Otherwise, protocol designers can (for example) retain the + decrement but use a separate prefix per link, or use some form of + bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]). + + Limiting broadcast (including all-hosts multicast): If there is no + efficiency requirement to prevent broadcast from going to other + on-link hosts, then flooding it within the subnet is not an issue. + Otherwise, protocol designers can (for example) use a separate + prefix per link, or flood broadcast other than ARP within the + subnet (ARP is covered below in Section 4.3). + + Limiting the scope of other multicast (including IPv6 Neighbor + Discovery): If there is no efficiency requirement to prevent + multicast from going to other on-link hosts, then flooding + multicast within the subnet is not an issue. Otherwise, protocol + designers can (for example) use a separate prefix per link, or use + Internet Group Management Protocol (IGMP)/MLD snooping [RFC4541] + instead. + +4.2. IPv6 Address Assignment + + In IPv6, the Prefix Information Option in a Router Advertisement (RA) + is defined for use by a router to advertise an on-link prefix. That + is, it indicates that a prefix is assigned to the link over which the + RA is sent/received. That is, the router and the node both have an + on-link route in their routing table (or on-link Prefix List, in the + conceptual model of a host in [RFC2461]), and any addresses used in + + + + +Thaler Informational [Page 10] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + the prefix are assigned to an interface (on any node) attached to + that. + + In contrast, DHCPv6 Prefix Delegation (DHCP-PD) [RFC3633] is defined + for use by a client to request a prefix for use on a different link. + Section 12.1 of RFC 3633 states: + + Upon the receipt of a valid Reply message, for each IA_PD the + requesting router assigns a subnet from each of the delegated + prefixes to each of the links to which the associated interfaces + are attached, with the following exception: the requesting router + MUST NOT assign any delegated prefixes or subnets from the + delegated prefix(es) to the link through which it received the + DHCP message from the delegating router. + + Hence, the upstream router has a route in its routing table that is + not on-link, but points to the client; the prefix is assigned to a + link other than the one over which DHCP-PD was done; and any + addresses used in the prefix are assigned to an interface (on any + node) attached to that other link. + + The IAB believes that the distinction between these two cases + (assigning a prefix to the same link vs. another link) is important, + and that the IETF protocols noted above are appropriate for the two + scenarios noted. The IAB recommends that other protocol designers + remain consistent with the IETF-defined scopes of these protocols + (e.g., not using DHCP-PD to assign a prefix to the same link, or + using RAs to assign a prefix to another link). + + In addition, the Prefix Information Option contains an L (on-link) + flag. Normally, this flag is set, indicating that this prefix can be + used for on-link determination. When not set, the advertisement + makes no statement about on-link or off-link properties of the + prefix. For instance, the prefix might be used for address + configuration with some of the addresses belonging to the prefix + being on-link and others being off-link. Care must be taken when the + L flag is not set. Specifically, some platforms allow applications + to retrieve the prefix length associated with each address of the + node. If an implementation were to return the prefix length used for + address configuration, then applications may incorrectly assume that + TTL=1 is sufficient for communication, and that link-scoped multicast + will reach other addresses in the prefix. As a result, the IAB + recommends that designers and maintainers of APIs that provide a + prefix length to applications address this issue. For example, they + might indicate that no prefix length exists when the prefix is not + on-link. If the API is not capable of reporting that one does not + exist, then they might choose to report a value of 128 when the + prefix is not on-link. This would result in such applications + + + +Thaler Informational [Page 11] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + believing they are on separate subnets, rather than on a multi-link + subnet. + +4.3. Duplicate Address Detection Optimizations + + One of the reasons sometimes cited for wanting a multi-link subnet + model (rather than a multi-access link model), is to minimize the + ARP/ND traffic between end-nodes. This is primarily a concern in + IPv4 where ARP results in a broadcast that would be seen by all + nodes, not just the node with the IPv4 address being resolved. Even + if this is a significant concern, the use of a multi-link subnet + model is not necessary. The point-to-point link model is one way to + avoid this issue entirely. + + In the multi-access link model, IPv6 ND traffic can be reduced by + using well-known multicast learning techniques (e.g., [RFC4541] at a + layer 2 intermediate device (bridge, switch, access point, etc.). + + Some have suggested that a layer 2 device could maintain an ARP or ND + cache and service requests from that cache. However, such a cache + prevents any type of fast mobility between layer 2 ports, and breaks + Secure Neighbor Discovery [RFC3971]. As a result, the IAB recommends + to protocol designers that this approach be avoided, instead using an + alternative such as layer 2 learning. For IPv4 (where no Secure ARP + exists), the IAB recommends that protocol designers avoid having a + device respond from its cache in cases where a node can legitimately + move between layer 2 segments of the link without any layer 2 + indications at the layer 2 intermediate device. Also, since + currently there is no guarantee that any device other than the end- + host knows all addresses of the end-host, protocol designers should + avoid any dependency on such an assumption. For example, when no + cache entry for a given request is found, protocol designers may + specify that a node broadcast the request to all nodes. + +5. Normative References + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting + Procedure", STD 5, RFC 950, August 1985. + + [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + +Thaler Informational [Page 12] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in + Routers", BCP 34, RFC 2644, August 1999. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, May + 2005. + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. + Zill, "IPv6 Scoped Address Architecture", RFC 4007, March + 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4541] Christensen, M., Kimball, K., and F. Solensky, + "Considerations for Internet Group Management Protocol + (IGMP) and Multicast Listener Discovery (MLD) Snooping + Switches", RFC 4541, May 2006. + +6. Informative References + + [2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", Work in Progress, May 2005. + + [BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", + ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/ + getieee802/download/802.1D-2004.pdf. + + [DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and + related systems (MULTICAST 1.2 Release)", June 1989. + http://www.kohala.com/start/mcast.api.txt + + + + + + +Thaler Informational [Page 13] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + [EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco + Document ID 16406, September 2005. + http://www.cisco.com/warp/public/103/eigrp-toc.html + + [LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO", + March 1998. http://www.linux.com/howtos/Multicast-HOWTO- + 2.shtml + + [LLMNR] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast + Name Resolution (LLMNR)", RFC 4795, January 2007. + + [MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. + http://files.multicastdns.org/draft-cheshire-dnsext- + multicastdns.txt + + [MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in + IPv6", Proceedings of IETF 54, June 2002. + http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-ipv6- + multilink-subnets-00.txt + + [RBRIDGE] Perlman, R., Gai, S., and D. Dutt, "Rbridges: Base Protocol + Specification", Work in Progress, March 2007. + + [RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, + October 1984. + + [RFC1001] NetBIOS Working Group in the Defense Advanced Research + Projects Agency, Internet Activities Board, and End-to-End + Services Task Force, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport: Concepts and Methods", STD + 19, RFC 1001, March 1987. + + [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to + Implement Transparent Subnet Gateways", RFC 1027, October + 1987. + + [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance + Vector Multicast Routing Protocol", RFC 1075, November + 1988. + + [RFC1884] Hinden, R., Ed., and S. Deering, Ed., "IP Version 6 + Addressing Architecture", RFC 1884, December 1995. + + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, + January 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + + +Thaler Informational [Page 14] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November + 1998. + + [RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, + revised", RFC 3024, January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via + IPv4 Clouds", RFC 3056, February 2001. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related + Terminology", RFC 3753, June 2004. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener + Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, February + 2006. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery + Proxies (ND Proxy)", RFC 4389, April 2006. + + [SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, + A., and B. Zill, "IPv6 Scoped Address Architecture", + Proceedings of IETF 54, July 2002. + http://www.ietf.org/proceedings/02jul/I-D/draft-ietf- + ipngwg-scoping-arch-04.txt + + [SSDP] Goland, Yaron Y., Cai, T., Leach, P., Gu, Y., and S. + Albright, "Simple Service Discovery Protocol (SSDP)", 1999. + http://www.upnp.org/resources/specifications.asp + + + + + +Thaler Informational [Page 15] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + + [TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", + Addison-Wesley, 1994. + + [TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000 + TCP/IP Implementation Details". http://www.microsoft.com/ + technet/itsolutions/network/deploy/depovg/tcpip2k.mspx + + [UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1, + Second Edition", Prentice Hall, 1998. + + [WSDISC] Microsoft, "Web Services Dynamic Discovery (WS-Discovery)", + 2005. http://specs.xmlsoap.org/ws/2005/04/discovery/ws- + discovery.pdf + +IAB Members at the time of this writing + + Bernard Aboba + Loa Andersson + Brian Carpenter + Leslie Daigle + Elwyn Davies + Kevin Fall + Olaf Kolkman + Kurtis Lindqvist + David Meyer + David Oran + Eric Rescorla + Dave Thaler + Lixia Zhang + +Author's Address + + Dave Thaler + Microsoft + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + + + + + + + + + + +Thaler Informational [Page 16] + +RFC 4903 Multi-Link Subnet Issues June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Thaler Informational [Page 17] + -- cgit v1.2.3