Multi-Link Subnet Issues
RFC 4903

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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