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]