summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4903.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4903.txt')
-rw-r--r--doc/rfc/rfc4903.txt955
1 files changed, 955 insertions, 0 deletions
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]
+