Internet Draft D. Thaler December 12, 2006 Internet Architecture Board Expires June 2007 Multilink Subnet Issues Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2006). 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. Thaler Expires June 2007 1 Draft Multilink Subnet Issues December 2006 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..............................................8 4.1. IP Link Model..............................................8 4.2. IPv6 Address Assignment...................................10 4.3. Duplicate Address Detection Optimizations.................11 5. IANA Considerations.........................................11 6. Normative References........................................11 7. Informative References......................................12 IAB Members at the time of this writing..........................15 Author's Address.................................................15 Full Copyright Statement.........................................16 Intellectual Property............................................16 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 which defined a specific type of ARP proxy behavior, where the forwarding plane had the properties of decrementing the 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. IAB Expires February 2007 2 Draft Multilink Subnet Issues December 2006 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 drafts 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 which preserves the notion that a subnet spans only one link [RFC4389]. 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 multilink 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 terms MUST, RECOMMENDED, SHOULD, and SHOULD NOT are used as defined in [RFC2119]. 2. Issues 2.1. IP Model The term "link" is generally used to refer to a topological area bounded by routers which 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 [RFC3513]. 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. IAB Expires February 2007 3 Draft Multilink Subnet Issues December 2006 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 twice, first in July 1998 [RFC2373] and again in April 2003 [RFC3513]. Both updates include the language: "Currently IPv6 continues the IPv4 model that a subnet prefix is 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 which 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. 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 if 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 which use the terms interchangeably due to the IP Model described earlier. IAB Expires February 2007 4 Draft Multilink Subnet Issues December 2006 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: 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 Apple's Bonjour [MDNS] uses messages with TTL 255 checked on receipt, and only responds to queries from addresses in the same subnet. (Note that multilink 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: o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit of 1. 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. 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. IAB Expires February 2007 5 Draft Multilink Subnet Issues December 2006 2.3. Link-scoped multicast and broadcast Because multicast routing is not ubiquitous, the notion of a subnet which 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 broadcast packets either. 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: DVMRP [DVMRP], OSPF [RFC2328], RIP [RFC2453][RFC2080], EIGRP [EIGRP], etc. These protocols exchange routes to subnet prefixes. o Address management protocols: Neighbor Discovery, DHCPv4 [RFC2131], 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: "An IPv4 multicast address used to 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 "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: 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. IAB Expires February 2007 6 Draft Multilink Subnet Issues December 2006 Note that protocols such as Bonjour and Teredo which drop packets which don't come from an address within the subnet are not necessarily broken by multilink 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 multilink 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." The last possibility, sometimes referred to as Duplicate Interface Identifier Detection (DIID), has been a matter of much debate, and the current draft 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 multilink 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 multilink subnet, address conflicts can occur. IAB Expires February 2007 7 Draft Multilink Subnet Issues December 2006 3. Security Considerations The notion of multilink subnets can cause problems with any security protocols which 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. 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. 4. Recommendations 4.1. IP Link Model There are two models which do not have the issues pointed out in the rest of the document. It is RECOMMENDED that one of the following two models be used: o Multiaccess 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, whatever) 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, whatever) in the middle of the link. IAB Expires February 2007 8 Draft Multilink Subnet Issues December 2006 A variant of the multi-access link model, which has fewer issues, but still some, is: 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 which make use of broadcast or multicast will work. Links that appear as NBMA links at layer 3 SHOULD NOT be used. Instead, if a link is an NBMA link at layer 2, then some mechanism SHOULD be defined 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 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 a link is a tunnel or not is orthogonal to the choice of model; there exist tunnel links for all link models mentioned above. A multilink subnet model SHOULD NOT be used. IETF working groups using, or considering using, multilink subnets today should investigate moving to one of the other models. For example, Mobile IPv6 should investigate having the Home Agent not decrement the Hop Limit, and forward multicast traffic. When considering changing an existing multilink 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, implementers SHOULD either retain the decrement but use a separate prefix per link, or else 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 IAB Expires February 2007 9 Draft Multilink Subnet Issues December 2006 issue. Otherwise, implementers SHOULD either use a separate prefix per link, or else 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, implementers SHOULD either use a separate prefix per link, or else use 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 the prefix are assigned to an interface (on any node) attached to that. The Prefix Information Option SHOULD NOT be used to advertise a prefix which is not intended for use on the link over which it is sent. 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. That is, 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. DHCP-PD SHOULD NOT be used to assign a prefix which is intended for use on the link over which DHCP-PD is done. 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 IAB Expires February 2007 10 Draft Multilink Subnet Issues December 2006 that link-scoped multicast will reach other addresses in the prefix. As a result, it is RECOMMENDED that any APIs that provide a prefix length to applications 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 an acceptable workaround would be to report a value of 128 when the prefix is not on-link. This results in such applications believing they are on separate subnets, rather than on a multilink subnet. 4.3. Duplicate Address Detection Optimizations One of the reasons sometimes cited for wanting a multilink 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 multilink 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, whatever). 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, a device SHOULD NOT respond from its cache for IPv6 (instead layer 2 learning is RECOMMENDED). For IPv4 (where no Secure ARP exists) a device SHOULD NOT 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, if no cache entry is found for a given request the request MUST still be broadcast to all nodes. 5. IANA Considerations This document has no actions for IANA. 6. Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. IAB Expires February 2007 11 Draft Multilink Subnet Issues December 2006 [RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [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. [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. 7. Informative References [2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis- 08.txt, 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 IAB Expires February 2007 12 Draft Multilink Subnet Issues December 2006 [DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [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, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-47.txt, August 2006. [MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet Draft, June 2005. http://files.multicastdns.org/draft- cheshire-dnsext-multicastdns.txt [MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in IPv6", draft-ietf-ipv6-multilink-subnets-00.txt (expired), June 2002. http://www.ietf.org/proceedings/02jul/I- D/draft-ietf-ipv6-multilink-subnets-00.txt [RBRIDGE] Perlman, R., and J. Touch, "Rbridges: Base Protocol Specification", draft-ietf-trill-rbridge-protocol-00.txt, May 2006. [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, End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", RFC 1001, March 1987. [RFC1884] Hinden, R. and S. Deering, "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. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. IAB Expires February 2007 13 Draft Multilink Subnet Issues December 2006 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3024] G. Montenegro, 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., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3753] J. Manner, Ed., 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. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4380] C. Huitema, "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, February 2006. [SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A., and B. Zill. "IPv6 Scoped Address Architecture", Internet-Draft (Obsolete), March 2005. 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 [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/deplo y/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. IAB Expires February 2007 14 Draft Multilink Subnet Issues December 2006 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 IAB Expires February 2007 15 Draft Multilink Subnet Issues December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). 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 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. IAB Expires February 2007 16