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

Versions: 00 01

INTERNET-DRAFT                                              F. Templin
                                                                 Nokia

Expires 30 April 2003                                  30 October 2002

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

                    draft-templin-v6v4-ndisc-01.txt

Abstract

   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 neighbors to establish security
   associations, discover and dynamically re-adjust maximum receive unit
   (MRU) estimates, and perform 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-
   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



   Copyright Notice

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





Templin                           Expires 30 April 2003         [Page 1]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


1.  Introduction

   The author anticipates a long-term requirement for [IPv6] operation
   over IPv6-over-(foo)-over-IPv4 links, where (foo)-over-[IPv4] is
   treated as a link layer for IPv6). 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 extensions to enable a hybrid proac-
   tive/on-demand neighbor discovery mechanism using bi-directional
   links.

   IPv6 nodes will need to establish security associations, determine
   and dynamically re-adjust maximum receive unit (MRU) estimates, 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 strategically adapting
   to and minimizing fragmentation can provide a superior solution to
   strict fragmentation avoidance. Central to the design goals is the
   ability for neighbors to establish and maintain lightweight, link-
   layer associations to provide a continuous feedback loop. Although
   these associations take on certain aspects of reliable transport con-
   nections, the author prefers to refer to them as "neighbor affilia-
   tions".


2.  Applicability Statement


     - proposes a neighbor affiliation protocol for IPv6 neighbors
       on IPv6-over-(foo)-over-IPv4 links

     - works with either automatic or configured tunnels

     - may be useful for IPv6 operations in certain deployment scenarios

     - may extend to future IPv6 applications beyond the case of
       IPv6-over-(foo)-over-IPv4


3.  Terminology

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

   neighbor affiliation:
     a lightweight association that enables robust, efficient and
     secure bi-directional links between IPv6 neighbors




Templin                           Expires 30 April 2003         [Page 2]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


4.  Neighbor Affiliation Protocol

   When multiple IPv4 hops intervene between nodes, [DISC] provides no
   trust basis (i.e., neighbors are not on the same connected LAN seg-
   ment) nor any specification for the nodes to monitor each other's
   reachability (i.e., multicast is not supported). Moreover, the path
   between any pair of neighbors is mutually exclusive from other on-
   link neighbors and may change over time. Thus, the maximum packet
   size a node A can receive from neighbor B may differ from the amount
   it can receive from neighbor C; even though all three nodes techni-
   cally share the same "link". These issues are addressed through
   lightweight neighbor affiliations that are established on-demand and
   maintained proactively as long as they are in active use.

   [DISC] specifies mechanisms for IPv6 nodes to discover and maintain
   reachability information for active neighbors. Neighbor Solicitation
   (NS) and Neighbor Advertisement (NA) messages are normally used for
   this purpose on multiple access, broadcast media. But, when an IPv4
   intranet/internet is used as the link layer, the standard multicast
   mechanisms do not apply. For the purpose of this specification, uni-
   cast NS/NA messages are formatted as specified in [DISC, 4.3-4], and
   ALWAYS include a source/target link layer address option (even though
   [DISC] does not require these options for unicast operation). Also,
   as permitted in [DISC, 4.6.1], this document specifies the format of
   link-layer address options for use in IPv6-over-(foo)-over-IPv4
   links. The following subsections describe the neighbor affiliation
   protocol and specific adaptations of the mechanisms in [DISC] in
   detail:


4.1.  Affiliation Establishment

   Neighbor affiliations are established using the following algorithm.
   The algorithm assumes that a source has a unicast packet to send to a
   target and invokes address resolution ([DISC, 7.2]):

    1) The source sends an NS message to the target with a specially
       formatted source link layer address option containing a "SYN"
       indication. The source creates a neighbor cache entry for the
       target, and transitions from the "CLOSED" to the "SYN-SENT"
       state

    2) The target receives the NS and notices that it includes a
       source link layer option containing a "SYN" indication. The
       target creates a neighbor cache entry for the source and
       records the physical interface the NS arrived on. The target
       transitions from the "LISTEN" to the "SYN-RECEIVED" state,
       then sends a unicast Solicited NA to the source. The NA



Templin                           Expires 30 April 2003         [Page 3]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


       includes a target link layer address option that contains a
       "SYN/ACK" indication and a "Maximum_MRU" option initialized
       to the maximum receive unit (MRU) of the physical interface
       recored above

    3) The source receives the Solicited NA and notices that it
       includes a target link layer option containing a "SYN/ACK"
       indication. It records the physical interface the NA arrived
       on and places the "Maximum_MRU" value in the target's neighbor
       cache entry. (This value is also optionally written into the
       destination cache entry(s) for the IPv6 destination address(es)
       of any packets waiting for address resolution completion
       [DISC, 7.2.2]. The "Maximum_MRU" value represents the current
       upper bound for the maximum packet size the target is able to
       receive, i.e., the MRU of the target's physical interface

       Next, the source transitions from the "SYN-SENT" to the
       "ESTABLISHED" state and sends a unicast Solicited NA to the
       target, i.e., the source treats the received NA as an
       "NS equivalent". The NA includes a target link layer
       address option that contains an "ACK" indication and a
       "Maximum_MRU" option initialized to the MRU of the physical
       interface recorded above

    4) The target receives the Solicited NA and notices that it
       includes a target link layer option containing an "ACK"
       indication. It places the "Maximum_MRU" value in the cache
       for the source and transitions from the "SYN-RECEIVED" to
       the "ESTABLISED" state. The target and source have now
       established a bi-directional link using the exact mechanism
       specified in [TCP, 3.4] and are said to be "affiliated"


4.2.  Affiliation Maintenance

   Neighbor affiliations are established on-demand in response to packet
   transmissions, as described above. Once established, the neighbors
   work together to proactively maintain the affiliation as long as it
   is being actively used by either or both endpoints.  When the affili-
   ation is no longer needed, it is allowed to expire with stale cache
   entries eventually garbage-collected.

   Since the "Maximum_MRU" values exchanged in the affiliation estab-
   lishment phase only convey information about the maximum packet size
   each node can receive from neighbors on the same physical link, a
   mechanism is needed to detect whether an MRU reduction is incurred by
   the intervening IPv4 path.  To satisfy this requirement, each neigh-
   bor MUST monitor its IPv4 reassembly cache to detect packets being



Templin                           Expires 30 April 2003         [Page 4]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


   fragmented by the network. The size of the largest fragments arriving
   from a particular neighbor indicates the "Current_MRU" that can be
   accepted, and this value needs to be conveyed back to the neighbor
   causing the fragmentation (see below).

   Additionally, since the Neighbor Affiliation Protocol does not ensure
   reliable data delivery, no periodic acknowledgements are sent as in
   [TCP]. [DISC, 7.3] accepts hints from upper layer protocols of "for-
   ward progress" as reachability confirmation, but such indications may
   not be present when one (or both) of the neighbors are routers or
   when only "unidirectional" traffic (e.g., UDP-based continuous media
   streams) is present. Thus, the proactive maintenance process requires
   periodic transmission of "keepalive" messages.

   Of paramount importance is the fact that data traffic arrival conveys
   unidirectional link state information only. In particular, the fact
   that node A is receiving packets from node B only guarantees that the
   unidirectional link B->A is operational (and vice-versa for A->B). In
   other words, it is insufficient for A to receive packets from B and
   for B to receive packets from A; in addition, A MUST KNOW THAT B IS
   RECEIVING ITS PACKETS AND VICE-VERSA.

   In order to satisfy the above affiliation maintenance requirements,
   each node MUST implement the following keepalive algorithm:

    - if one or more data packets were received from an affiliated
      neighbor within the past N seconds, send the neighbor an
      unsolicited Neighbor Advertisement containing a target link
      layer address option with a "Current_MRU" option set to the
      size of the largest fragments arriving from the neighbor.
      If no fragmentation is taking place, "Current_MRU" is set
      to "Maximum_MRU". (Note that "Maximum_MRU" may change over
      time, e.g., due to routing fluctuations, so it too must
      be included in the NA.)

    - if no unsolicited NAs have arrived within the past N seconds
      even though packets have been sent to the neighbor, mark the
      affiliation as "stale".


4.3.  Fulfilling Contractual Obligations

   When a pair of neighbors engages in an affiliation as specified in
   the previous subsections, they effectively engage in a mutual con-
   tract that requires vigilance to maximize robustness and efficiency
   while doing no harm to each other or to the intervening network path.
   Mandatory contractual obligations include:




Templin                           Expires 30 April 2003         [Page 5]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


    - the packets a neighbor sends to its peer MUST be no larger
      than the peer's "Current_MRU" estimate

    - all packets SHOULD be sent with the IPv4 DF flag NOT set;
      regardless of their size

    - each node SHOULD attempt to maximize network utilization
      by periodically increasing the estimate for its neighbor
      to "Maximum_MRU" as long fragmentation remains below
      "harmful" levels

    - each neighbor MUST take preemptive measures to reduce
      fragmentation if it reaches "harmful" levels

   Preemptive measures to reduce harmful fragmentation (see "What con-
   stitutes harmful fragmentation?" below) include sending unsolicited
   NAs and ICMPv6 "packet too big" messages as appropriate. When a node
   detects harmful fragmentation, it MUST send a gratuitous unsolicited
   NA to the offending peer (as described in the previous section) with-
   out waiting for the normal affiliation maintenance timeout period.
   Nodes should employ a strategy to rate-limit such gratuitous NAs,
   since a RTT "burst" of fragmented packets may be in the pipeline.

   When fragments are lost such that a packet cannot be reassembled, the
   receiver MUST generate an ICMPv6 "packet too big" message, provided
   the first-fragment was not lost. The "packet too big" message encodes
   the length of the first-fragment in the MTU field and encapsulates as
   much of the IPv6 packet contained in the IPv4 first-fragment as pos-
   sible [ICMPv6, 3.2]. This message provides the peer with a transmit
   failure indication so lost data can be retransmitted.

   Note that [FRAG, 3.4] speaks favorably for the use of "transparent
   fragmentation", i.e., the use of reliable fragmentation and reassem-
   bly at a layer below IP. What is proposed here is essentially trans-
   parent link layer fragmentation with judicious and mitigated use so
   that network utilization is maximized while fragmentation is mini-
   mized.  In this sense, fragmentation in and of itself is NOT cause
   for alarm and rash actions - as long as both ends of the neighbor
   affiliation honor their contractual obligations and adapt their
   behavior appropriately.


4.4.  What Constitutes "Harmful" Fragmentation?

   In 1987, [FRAG] made an early assertion that fragmentation was harm-
   ful, and in 2002 the quantitative studies in [FOLK] concluded that
   this assertion is still true today. Even in today's Internet (where
   nodes by-and-large have correct fragmentation/reassembly



Templin                           Expires 30 April 2003         [Page 6]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


   implementations) fragmentation causes "slow-path" processing in
   routers and network performance degradation when the loss unit (a
   fragment) is smaller than the retransmission unit (a packet or seg-
   ment). [FOLK] observed that the principal contributors to fragmenta-
   tion in the Internet are continuous media applications (e.g., media
   players and interactive games) and tunnel ingress points with miscon-
   figured MTUs. Both produce UNMITIGATED and PERSISTENT fragmentation
   when no path MTU discovery feedback occurs, and it is ONLY this sort
   of fragmentation that this author believes should be considered harm-
   ful.

   Both [FRAG] and [FOLK] failed to note that the fundamental cause of
   unmitigated and persistent fragmentation are senders which disobey
   the robustness principle, i.e., nodes that are not "conservative in
   what they send". But, the contractual obligations of nodes that par-
   ticipate in the neighbor affiliation protocol specified in this docu-
   ment provide the necessary means for eliminating harmful fragmenta-
   tion. While fragmentation is an integral mechanism for efficient path
   probing in the specification, it's use is an appropriate and miti-
   gated application of the receiver's side of the robustness principle,
   i.e., be "liberal in what you receive".


4.5.  Willingness to Affiliate

   When a node initiates a neighbor affiliation as described in the pre-
   vious subsections, it may find that its peer either does not support
   the protocol or is otherwise unwilling to affiliate. In the former
   case, the NA that a peer returns in response to the initial NS will
   either not contain the "SYN/ACK" indication or not contain a target
   link layer option at all. In this case, the initiating node may:

     1) Safely estimate that the peer's MRU is the IPv6 MINMTU
        of 1280 bytes

     2) Bravely estimate that the peer's MRU is something larger
        than IPv6 MINMTU, e.g., 1480 bytes)

     3) Assume that the peer is unreachable, e.g., if no reasonable
        MRU estimate is possible or if a security association is
        required

   The MRU estimate MUST take into account that tunneled traffic is one
   of the primary contributers to harmful fragmentation in the Internet
   today [FOLK]. Nodes MUST honor the robustness principle of "be con-
   servative in what you send and liberal in what you receive" in all
   cases.




Templin                           Expires 30 April 2003         [Page 7]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


   Nodes may employee a strategy for allowing/disallowing particular
   affiliations, e.g., a router or server 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 affili-
   ation protocol described above is not abused by malicious nodes. Can-
   didate mechanisms might be an adaptation of TCP "syn cookies" [refer-
   ence needed] or a shared secret between the neighbors.


4.6.  Source/Target Link Layer Option Format

   The NS/NA messages used for the neighbor affiliation protocol always
   encode the Source/Target Link Layer Address option, as specified by
   [DISC, 4.6.1]:

         0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |     Type      |    Length     |    Link-Layer Address ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   The "Type" is encoded exactly as in [DISC, 4.6.1] and the Length is
   always 1 for the purpose of this specification. But, the link-layer
   address field has the following special format:

             (octets 2-3)        (octets 4-5)        (octets 6-7)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |S|A|  Reserverd    |    Current_MRU    |    Maximum_MRU    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Thus, the "SYN" and "ACK" flags, the "Current_MRU" and the "Maxi-
   mum_MRU" values can be exchanged between affiliating neighbors, as
   required by the specification.


5.  Operational Considerations

   Nodes that establish neighbor affiliations on IPv6-over-(foo)-over-
   IPv4 links must observe the following operational considerations:


5.1.  Default Maximum Transmit Unit (DFLT_MTU)

   IPv6-over-(foo)-over-IPv4 interfaces may be configured over one or
   more underlying physical interfaces for IPv4. The default maximum
   transmit unit (DFLT_MTU) for an IPv6-over-(foo)-over-IPv4 interface
   is the maximum MTU of all underlying physical interfaces for IPv4
   minus the sum of all header sizes required for IPv6-over-(foo)



Templin                           Expires 30 April 2003         [Page 8]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


   encapsulation.

   For example, if a multi-homed host has an Ethernet interface and an
   FDDI interface, the maximum MTU for underlying physical interfaces is
   4352. If the encapsulation is IPv6-over-UDP, then:

    DFLT_MTU = 4352 - 40 (sizeof(ipv6_hdr)) - 8 (sizeof(udp_hdr)) = 4304

   Obviously, the DFLT_MTU value may be overestimated for some traffic
   on multi-homed hosts with heterogeneous interfaces. But, read fur-
   ther.


5.2.  Per-Neighbor Maximum Transmit Unit (NBR_MTU)

   As neighbor affiliations are established, the MRUs for "frequently
   accessed" neighbors are established in the destination cache. The
   destination cache entry for an active neighbor's MRU is always chosen
   as the MTU for that neighbor (NBR_MTU). When no destination cache
   entry exists, the DFLT_MTU is used.


5.3.  TCP MSS

   When a TCP connection is initiated to an on-link neighbor, the TCP
   MSS is initialized to (NBR_MTU - 40) if a destination cache entry
   exists; else (DFLT_MTU - 40). (40 = 20bytes for TCP header plus
   20bytes for IPv4 header). The TCP SYN segment carries the MSS option
   and initiates the neighbor affiliation process if no affiliation cur-
   rently exists (i.e., the TCP SYN segment is contained in the first
   packet out.) The neighbor affiliation may reduce the NBR_MTU value in
   the destination cache while the SYN packet waits on the Address Reso-
   lution queue. But, the system will self-correct when the peer
   responds with an MSS option in the SYN/ACK, since the peer will have
   up-to-date MRU information from the neighbor affiliation.


5.4.  Adaptation to Overestimated DFLT_MTU, NBR_MTU

   When a packet is sent to a neighbor based on an overestimated
   DFLT_MTU or NBR_MTU, an ICMPv6 "packet too big" message is generated
   locally and the too-big packet is dropped. Upper layers will retrans-
   mit the data based on the reduced MTU specified in the packet too big
   message.







Templin                           Expires 30 April 2003         [Page 9]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


5.5.  Implementation Alternatives

   Obviously, the cleanest implementation would entail in-kernel instru-
   mentation of the IPv4 reassembly cache and intervention in the spe-
   cific IPv6-over-(foo)-over-IPv4 device drivers that will use neighbor
   affiliation. But, an alternative is to write an application that uses
   the Berkeley Packet Filter (libpcap) to monitor the fragments that
   enter the host and generate the NS/NA messages necessary to support
   the protocol outside of the context of the kernel. In this way, the
   neighbor affiliation protocol can be easily deployed on nodes with
   existing "vanilla" IPv6-over-(foo)-over-IPv4 tunnel drivers.


6.  Rationale for this Approach

   One might reasonably ask why the approach in this document is recom-
   mended instead of the current practices specified in
   [PMTUDv4],[PMTUDv6]. When IPv6 uses (foo)-over-IPv4 as a link layer,
   ICMPv6 "Packet Too Big" messages can only be produced by the tunnel
   encapsulator and decapsulator (i.e., the two IPv6 neighbor nodes),
   while ICMPv4 "Fragmentation Needed" messages are produced by the
   intervening IPv4 routers. But, the ICMPv4 messages are not readily
   translated into ICMPv6 since they are only guaranteed to include up
   to 8 bytes of the too big packet's data (i.e., not enough information
   to determine the IPv6 header).

   One possible solution is to cache the IPv6 packets at the encapsula-
   tor and match them up with any ICMPv4 "frag needed" messages that are
   delivered by the IPv4 network. But, this creates a state scaling
   issue - especially when the encapsulator is an IPv6 router. Also, an
   encapsulating router would need to retransmit the data in the too-big
   packets on behalf of the final destination, i.e., act as a "proxy"
   for the final destination - but, this would require the router to
   understand the semantics of the packetization layer of the original
   source when it receives ICMPv4 "frag needed" messages from the IPv4
   network.

   Finally (and most importantly) IPv4  routers in the path between the
   encapsulator and decapsulator cannot be trusted to reliably deliver
   ICMPv4 "frag needed" messages - they can be lost due to network con-
   gestion or filtering firewalls, and they can be forged by an attacker
   since the end nodes have no trust basis with the IPv4 routers. The
   only acceptable means is to engage the IPv6 endpoints in a neighbor
   affiliation as described in this document.







Templin                          Expires 30 April 2003         [Page 10]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


7.  IANA considerations

   N/A


8.  Security considerations

   This document provides a potential platform for integrating secure
   neighbor discovery mechanisms.

Acknowledgements

   The proposal herin is nearly identical to some presented on the TCP-
   IP discussion group [TCP-IP] and IETF Path MTU Discovery Working
   Group [MTUDWG] mailing lists, roughly between the period of May 1997
   through May 1990. The earliest proposal that most closely matches the
   one herein was offered by Charles Lynn on November 17, 1987. Others
   (e.g., Fox, Bohle, 1989, etc.) proposed combining the basic mechanism
   described by Lynn with transport layer protocols, e.g., TCP. To the
   best of the author's knowledge, this document presents the first sug-
   gested combination of the Lynn proposal with Neighbor Discovery.

   Earlier works from SRI International proposed 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 acknowledges those who participated in discussions on the
   NGTRANS and V6OPS mailing lists between August and October 2002 for
   helpful insights.

   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.

Normative References

   [ICMPv6]   Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463.

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

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




Templin                          Expires 30 April 2003         [Page 11]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


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

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

   [PMTUDv6]  McCann, J., Deering, S. and J. Mogul, "Path MTU
              Discovery for IP version 6", RFC 1981, August 1996.

   [MTUDWG]   IETF MTU Discovery Working group mailing list,
              gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log,
              November 1989 - February 1995.

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

   [TCP-IP]   TCP-IP Mailing list archives,
              http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip,
              May 1987 - May 1990.

Informative References

Authors Addresses

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

APPENDIX A: Historic Evolution of PMTUD

   The topic of Path MTU discovery (PMTUD) saw a flurry of discussion
   and numerous proposals in the late 1980's through early 1990. The
   initial problem was posed by Art Berggreen on May 22, 1987 in a mes-
   sage to the TCP-IP discussion group [TCP-IP]. The discussion that
   followed provided significant reference material for [FRAG].  An IETF
   Path MTU Discovery Working Group [MTUDWG] was formed in late 1989



Templin                          Expires 30 April 2003         [Page 12]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


   with charter to produce an RFC. Several variations on a very few
   basic proposals were entertained, including:

    1. Routers record the PMTUD estimate in ICMP-like path probe
       messages (proposed in [FRAG] and later [PROBE])

    2. The destination reports any fragmentation that occurs for
       packets received with the "RF" (Report Fragmentation) bit
       set (Steve Deering's 1989 adaptation of Charles Lynn's
       Nov. 1987 proposal)

    3. A hybrid combination of 1) and Charles Lynn's Nov. 1987
       proposal (straw RFC draft by McCloughrie, Fox and Mogul
       on Jan 12, 1990)

    4. Combination of the Lynn proposal with TCP (Fred Bohle,
       Jan 30, 1990)

    5. Fragmentation avoidance by setting "IP_DF" flag on all
       packets and retransmitting if ICMPv4 "fragmentation needed"
       messages occur (Geof Cooper's 1987 proposal; later adapted
       into [PMTUDv4] by Mogul and Deering)

   Option 1) seemed attractive to the group at the time, since it was
   believed that routers would migrate more quickly than hosts.  Option
   2) was a strong contender, but repeated attempts to secure an "RF"
   bit in the IPv4 header from the IESG failed and the proponents became
   discouraged. 3) was abandoned because it was perceived as too compli-
   cated, and 4) never received any apparent serious consideration. Pro-
   posal 5) was a late entry into the discussion from Steve Deering on
   Feb. 24th, 1990.  The discussion group soon thereafter seemingly lost
   track of all other proposals and adopted 5), which eventually evolved
   into [PMTUDv4] and later [PMTUDv6].

   In retrospect, the "RF" bit postulated in 2) is not needed if a "con-
   tract" is first established between the peers, as in proposal 4) and
   a message to the MTUDWG mailing list from jrd@PTT.LCS.MIT.EDU on Feb
   19. 1990. These proposals saw little discussion or rebuttal, and were
   dismissed based on the following the assertions:

     - routers upgrade their software faster than hosts

     - PCs could not reassemble fragmented packets

     - Proteon and Wellfleet routers did not reproduce
       the "RF" bit properly in fragmented packets

     - Ethernet-FDDI bridges would need to perform fragmentation



Templin                          Expires 30 April 2003         [Page 13]

INTERNET-DRAFT         V6-V4 Neighbor Affiliation        30 October 2002


       (i.e., "translucent" not "transparent" bridging)

     - the 16-bit IP_ID field could wrap around and disrupt
       reassembly at high packet arrival rates

   The first four assertions, although perhaps valid at the time, have
   been overcome by historical events leaving only the final to con-
   sider. But, [FOLK] has shown that IP_ID wraparound simply does not
   occur within several orders of magnitude the reassembly timeout win-
   dow on high-bandwidth networks.









































Templin                          Expires 30 April 2003         [Page 14]


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