Internet DRAFT - draft-iab-multilink-subnet-issues

draft-iab-multilink-subnet-issues





Internet Draft                                              D. Thaler 
January 23, 2006                          Internet Architecture Board 
Expires July 2007                         
 
                        Multilink Subnet Issues 
               <draft-iab-multilink-subnet-issues-03.txt> 
                                     
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 (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. 














  
Thaler                    Expires July 2007                         1 
Draft                  Multilink Subnet Issues           January 2007 
 
 
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.........................................12 
   6.   Normative References........................................12 
   7.   Informative References......................................13 
   IAB Members at the time of this writing..........................15 
   Author's Address.................................................16 
   Full Copyright Statement.........................................17 
   Intellectual Property............................................17 
 
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, although [RFC1027] later documented an implementation 
   of a subset of [RFC925]. 


  
IAB                     Expires February 2007                       2 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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 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 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 [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. 
  
IAB                     Expires February 2007                       3 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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 
   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, 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 if 0 means node-local, 1 means link-local" (this of 
  
IAB                     Expires February 2007                       4 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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. 

   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 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 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 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. 

  
IAB                     Expires February 2007                       5 
Draft                  Multilink Subnet Issues           January 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 
   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 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: 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". 


  
IAB                     Expires February 2007                       6 
Draft                  Multilink Subnet Issues           January 2007 
 
 
     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. 

   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. 

  
IAB                     Expires February 2007                       7 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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. 

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, 
   since it secures Neighbor Discovery messages which 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. 

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. 

   The IAB recommends that protocol designers use one of the following 
   two models: 

    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. 

  
IAB                     Expires February 2007                       8 
Draft                  Multilink Subnet Issues           January 2007 
 
 
    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. 

   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 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 
   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 be avoided.  IETF working groups 
   using, or considering using, multilink 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 multilink subnet solution to 
   another model, the following issues should be considered: 


  
IAB                     Expires February 2007                       9 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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 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. 

   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 
  
IAB                     Expires February 2007                      10 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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 to designers and maintainers of APIs 
   that provide a prefix length to applications, that they 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 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 
  
IAB                     Expires February 2007                      11 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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, 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. IANA Considerations 

   This document has no actions for IANA. 

6. 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., "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. 

   [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. 



  
IAB                     Expires February 2007                      12 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   [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.  

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 

   [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. 

  
IAB                     Expires February 2007                      13 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   [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. 

   [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 
             implement transparent subnet gateways", RFC 1027, October 
             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. 

   [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. 

  
IAB                     Expires February 2007                      14 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 
             (IPv6) Addressing Architecture", RFC 3513, April 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.  
             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 
  
IAB                     Expires February 2007                      15 
Draft                  Multilink Subnet Issues           January 2007 
 
 
   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                      16 
Draft                  Multilink Subnet Issues           January 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.  













  
IAB                     Expires February 2007                      17