[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

INTERNET-DRAFT                                              F. Templin

Expires 25 April 2003                                  25 October 2002

      Neighbor Affiliation Protocol for IPv6-over-(foo)-over-IPv4



   This document proposes extensions to IPv6 Neighbor Discovery for
   IPv6-over-(foo)-over-IPv4 links, where (foo) is either an
   encapsulating layer (e.g., UDP) or a NULL layer. It is essentially a
   lightweight, link-layer mechanism for nodes and routers to establish
   security associations, discover and dynamically re-adjust maximum
   transmission units, and perform neighbor unreachability detection.
   The protocol makes no attempt to ensure reliable message delivery;
   this function is performed by higher-layer protocols, e.g. TCP.

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Templin                           Expires 25 April 2003         [Page 1]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        25 October 2002

1.  Introduction

   The author anticipates a long-term requirement for [IPv6] operation
   over IPv6-over-(foo)-over-IPv4 links, where IPv4 is treated as a link
   layer for IPv6-over-(foo). Neighbors that exchange data over such
   links will need to make the most efficient, robust and secure use of
   the intervening [IPv4] paths possible. The author believes that this
   will require link-layer specific extensions to enable a hybrid proac-
   tive/on-demand neighbor discovery mechanism using bi-directional

   IPv6 nodes and IPv6 routers will need to establish security associa-
   tions, determine and dynamically re-adjust maximum transmission
   units, and perform neighbor unreachability detection using an IPv4
   intranet or internet as the link layer. Although IPv4 fragmentation
   is considered harmful [FRAG][FOLK], the author believes that strate-
   gically adapting to, and minimizing, fragmentation can provide a
   superior solution to strict fragmentation avoidance. Central to the
   design goals is the ability to establish and maintain lightweight,
   link-layer associations between IPv6 neighbors to provide a feedback
   loop. Although these associations take on certain aspects of connec-
   tion-oriented protocols, the author prefers the term "neighbor affil-

2.  Applicability Statement

     - proposes a neighbor affiliation protocol for IPv6 nodes and routers

     - may be useful for IPv6 operations in certain deployment scenarios

3.  Terminology

   The terminology of [IPv4] and [IPv6] apply to this document. The fol-
   lowing additional term is defined:

   neighbor affiliation:
     a lightweight association between IPv6 neighbors

4.  Neighbor Affiliation

   [DISC] specifies mechanisms for IPv6 nodes to discover and maintain
   reachability information about active neighbors. Neighbor Solicitaion
   (NS) and Neighbor Advertisement (NA) messages are normally used for
   this purpose on multiple access, broadcast media. But, when an IPv4

Templin                           Expires 25 April 2003         [Page 2]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        25 October 2002

   intranet/internet is used as the link layer, the underlying network
   is treated as a non-broadcast multiple access (NBMA) media for IPv6,
   and the standard usage for NS and NA messages specified in [DISC]
   does not apply. Thus, an adaptation for the use of these messages for
   IPv6-over-(foo)-over-IPv4 links is specified in this document.

   When multiple IPv4 hops intervene between nodes, [DISC] provides no
   trust basis nor any clear means for the node to monitor the router's
   liveliness, i.e., multicast is not supported. Additionally, the path
   MTU between any two nodes may differ considerably. [FRAG, 3.4] speaks
   favorably for the use of transparent fragmentation, i.e., the use of
   reliable fragmentation and reassembly at a layer below IP. What is
   proposed here is not a firm reliance on such link layer fragmenta-
   tion, but judicious and minimal use so that network utilization can
   be maximized while fragmentation is minimized.

   Since the intervening IPv4 path between nodes is likely to be uni-
   cast-only, we consider only the use of unicast NS/NA messages for
   now. These messages are formatted as specified in [DISC, 4.3-4] and
   always include the source/target link layer address options as appro-
   priate for unicast operation. But, as permitted in [DISC, 4.6.1],
   this document specifies the content and format of the link-layer
   address for IPv6-over-(foo)-over-IPv4.

   The neighbor affiliation proposal entails the following roughly-spec-
   ified algorithm:

    1) The source node creates a unicast IPv6 NS and wraps it in
       a (foo)/IPv4 header. The IPv4 length MAY BE artificially
       inflated to the size of the outgoing link's physical MTU
       if path probing is needed (i.e., the packet is NULL-padded
       beyond the encapsulated RS). The the DF flag is NOT set in
       the IPv4 header. The source link layer address field contains
       a "SYN" indication (format TBD). The NS is then sent to
       the target node, and a state variable for the target
       transitions from "CLOSED" to "NS-SENT"

    2) The target node looks for either full IPv6 NS's or
       IPv4 first-fragments arriving in the reassembly cache (by
       any means necessary). If the first-fragment contains a unicast
       NS, and if the "SYN" bit is set, the IPv4 length of the fragment
       indicates the path MTU from the initiating neighbor. (Any other
       fragments arriving for the IPv4 packet can be discarded.) The
       receiver (which was in the "LISTEN" state) creates a state
       variable in the "NS-RECEIVED" for the initiator, then sends
       a unicast NA to the host with a "Source->Target Path MTU"
       value and a "SYN/ACK" indication encoded in the target link
       layer address (format TBD) using the first fragment's length

Templin                           Expires 25 April 2003         [Page 3]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        25 October 2002

       as the path MTU value. The IPv4 length MAY BE artificially
       inflated to the size of the target's outgoing link (as for
       the NS in step 1) if path probing is needed

    3) The source node receives the NA, by snooping incoming
       IPv4 first-fragments as described above, looks for the
       "SYN/ACK" indication, places the length from the
       "Source->Target Path MTU" field in the destination cache
       for the target, and transitions from the "NS-SENT" state
       to the "ESTABLISHED" state. It then creates a NA message (as
       in 2) which it sends to the target; placing the length of the
       first-fragment in the "Target->Source Path MTU" field and an
       "ACK" indication encoded in the source/target link layer
       address option (format TBD).

    4) The target receives the NA message and transitions from the
       "NS-RECEIVED" state to the "ESTABLISED" state. It writes the
       value in the Target->Source Path MTU option into a destination
       cache entry for the source. The target and source have now
       established a bi-directional link, using the exact mechanism
       specified in [TCP, 3.4]


    - If either end of the affiliation is unable to "snoop" the
      reassembly cache in the manner specified above, it must return
      a minimum path MTU value to the peer that is no smaller than
      the IPv6 MINMTU of 1280 and no larger than can be reasonably
      expected to avoid fragmentation (TBD)

    - If either end of the affiliation chooses not to probe the
      path, it should set a "not probing" indication in the NS/NA
      message (TBD)

    - If either end of the affiliation detects fragmentation of data
      packets at any time, it must send a "fragmentation experienced'
      indication in an unsolicited NA message to inform the other end
      of the new path MTU

    - If fragmentation continues, "fragmentation experienced" messages
      are scheduled to avoid congestion on the return path (i.e.,
      they are sent according to some TBD scheduling algorithm; not
      on receipt of each fragmented packet)

   Left to consider is the fact that "keepalives" are needed to keep the
   affiliation strong. This is done through data packets sent between
   the source and target. Packets between the source and target need to
   carry a "RECENTLY_HEARD" indication signifying that each end of the

Templin                           Expires 25 April 2003         [Page 4]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        25 October 2002

   affiliation is hearing periodic messages from the other. When one end
   of the affiliation has no data packets to send within a "NEIGH-
   BOR_KEEPALIVE" timeout, it sends an unsolicited NA to the other end
   if it wishes to keep the affiliation alive. When one end of the affi-
   laition ceases to hear periodic messages from the other end for a
   "NEIGHBOR_LOST" timeout period, it enters the CLOSED state and either
   sends a new NS to re-establish the affiliation or remains quiet
   unless/until new data packet are Lastly, but most importantly, *all*
   packets are sent with the DF flag NOT set; if either end of the
   affiliation detects fragmentation, an unsolicited NA is sent with the
   newly-detected (reduced) path MTU in the MTU option to inform the

   Nodes may employee a strategy for allowing/disallowing particular
   affiliations, e.g., a router may choose not to answer a solicitation
   from a new host if its state cache is nearly full. Finally, security
   measures should be taken to ensure that the affiliation protocol
   described above is not abused by malicious nodes. Candidate mecha-
   nisms might be an adaptation of TCP "syn cookies" [reference needed]
   or a shared secret between the neighbors.

5.  IANA considerations


6.  Security considerations



   The proposal herin is nearly identical to some presented on the [TCP-
   IP] [MTUDWG] mailing lists, roughly between the period of May 1997
   through May 1990. The original proposal that most closely matches the
   one herein was offered by Charles Lynn on November 17, 1987.

   Earlier works from SRI International propsed a "router affiliation"
   protocol. The term "affiliation" as used in this document was
   directly derived from its use in those earlier works. Two SRI
   researchers who participated in this effort were Barbara Denny and
   Bob Gilligan.

   The author would finally like to acknowledge the founding architects
   of the DARPA Internet protocols, who created the technologies used by
   the millions of nodes on the Internet today and the billions more to
   come in the forseeable future.

Templin                           Expires 25 April 2003         [Page 5]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        25 October 2002

Normative References

   [IPv4]     Postel, J., "Internet Protocol", RFC 791.

   [TCP]      Postel, J., "Transmission Control Protocol", RFC 793.

   [IPV6]     Deering, S., and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460.

   [DISC]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [FRAG]     Kent, C., and J. Mogul, "Fragmentation Considered
              Harmful", December, 1987

   [FOLK]     Shannon, C., Moore, D. and k claffy, "Beyond Folklore:
              Observations on Fragmented Traffic"

   [PROBE]    Mogul, J., Kent, C., Partridge, C., and K. McCloughrie,
              "IP MTU Discovery Options", RFC 1063, July 1988.

   [PMTUD]    Mogul, J. and S. Deering, "Path MTU Discovery",
              RFC 1191, November 1990.

   [MTUDWG]   IETF MTU Discovery Working group mailing list,
              November 1989 - February 1995.

   [TCP-IP]   TCP-IP Mailing list archives,
              May 1987 - May 1990.

Informative References

Authors Addresses

      Fred L. Templin
      313 Fairchild Drive
      Mountain View, CA, USA
      Phone: (650)-625-2331
      Email: ftemplin@iprg.nokia.com

Templin                           Expires 25 April 2003         [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/