diff options
Diffstat (limited to 'doc/rfc/rfc1981.txt')
| -rw-r--r-- | doc/rfc/rfc1981.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc1981.txt b/doc/rfc/rfc1981.txt new file mode 100644 index 0000000..56d6b88 --- /dev/null +++ b/doc/rfc/rfc1981.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group J. McCann +Request for Comments: 1981 Digital Equipment Corporation +Category: Standards Track S. Deering + Xerox PARC + J. Mogul + Digital Equipment Corporation + August 1996 + + + Path MTU Discovery for IP version 6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes Path MTU Discovery for IP version 6. It is + largely derived from RFC 1191, which describes Path MTU Discovery for + IP version 4. + +Table of Contents + + 1. Introduction.................................................2 + 2. Terminology..................................................2 + 3. Protocol overview............................................3 + 4. Protocol Requirements........................................4 + 5. Implementation Issues........................................5 + 5.1. Layering...................................................5 + 5.2. Storing PMTU information...................................6 + 5.3. Purging stale PMTU information.............................8 + 5.4. TCP layer actions..........................................9 + 5.5. Issues for other transport protocols......................11 + 5.6. Management interface......................................12 + 6. Security Considerations.....................................12 + Acknowledgements...............................................13 + Appendix A - Comparison to RFC 1191............................14 + References.....................................................14 + Authors' Addresses.............................................15 + + + + + + + + +McCann, Deering & Mogul Standards Track [Page 1] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + +1. Introduction + + When one IPv6 node has a large amount of data to send to another + node, the data is transmitted in a series of IPv6 packets. It is + usually preferable that these packets be of the largest size that can + successfully traverse the path from the source node to the + destination node. This packet size is referred to as the Path MTU + (PMTU), and it is equal to the minimum link MTU of all the links in a + path. IPv6 defines a standard mechanism for a node to discover the + PMTU of an arbitrary path. + + IPv6 nodes SHOULD implement Path MTU Discovery in order to discover + and take advantage of paths with PMTU greater than the IPv6 minimum + link MTU [IPv6-SPEC]. A minimal IPv6 implementation (e.g., in a boot + ROM) may choose to omit implementation of Path MTU Discovery. + + Nodes not implementing Path MTU Discovery use the IPv6 minimum link + MTU defined in [IPv6-SPEC] as the maximum packet size. In most + cases, this will result in the use of smaller packets than necessary, + because most paths have a PMTU greater than the IPv6 minimum link + MTU. A node sending packets much smaller than the Path MTU allows is + wasting network resources and probably getting suboptimal throughput. + +2. Terminology + + node - a device that implements IPv6. + + router - a node that forwards IPv6 packets not explicitly + addressed to itself. + + host - any node that is not a router. + + upper layer - a protocol layer immediately above IPv6. Examples are + transport protocols such as TCP and UDP, control + protocols such as ICMP, routing protocols such as OSPF, + and internet or lower-layer protocols being "tunneled" + over (i.e., encapsulated in) IPv6 such as IPX, + AppleTalk, or IPv6 itself. + + link - a communication facility or medium over which nodes can + communicate at the link layer, i.e., the layer + immediately below IPv6. Examples are Ethernets (simple + or bridged); PPP links; X.25, Frame Relay, or ATM + networks; and internet (or higher) layer "tunnels", + such as tunnels over IPv4 or IPv6 itself. + + interface - a node's attachment to a link. + + + + +McCann, Deering & Mogul Standards Track [Page 2] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + address - an IPv6-layer identifier for an interface or a set of + interfaces. + + packet - an IPv6 header plus payload. + + link MTU - the maximum transmission unit, i.e., maximum packet + size in octets, that can be conveyed in one piece over + a link. + + path - the set of links traversed by a packet between a source + node and a destination node + + path MTU - the minimum link MTU of all the links in a path between + a source node and a destination node. + + PMTU - path MTU + + Path MTU + Discovery - process by which a node learns the PMTU of a path + + flow - a sequence of packets sent from a particular source + to a particular (unicast or multicast) destination for + which the source desires special handling by the + intervening routers. + + flow id - a combination of a source address and a non-zero + flow label. + +3. Protocol overview + + This memo describes a technique to dynamically discover the PMTU of a + path. The basic idea is that a source node initially assumes that + the PMTU of a path is the (known) MTU of the first hop in the path. + If any of the packets sent on that path are too large to be forwarded + by some node along the path, that node will discard them and return + ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such a + message, the source node reduces its assumed PMTU for the path based + on the MTU of the constricting hop as reported in the Packet Too Big + message. + + The Path MTU Discovery process ends when the node's estimate of the + PMTU is less than or equal to the actual PMTU. Note that several + iterations of the packet-sent/Packet-Too-Big-message-received cycle + may occur before the Path MTU Discovery process ends, as there may be + links with smaller MTUs further along the path. + + Alternatively, the node may elect to end the discovery process by + ceasing to send packets larger than the IPv6 minimum link MTU. + + + +McCann, Deering & Mogul Standards Track [Page 3] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + The PMTU of a path may change over time, due to changes in the + routing topology. Reductions of the PMTU are detected by Packet Too + Big messages. To detect increases in a path's PMTU, a node + periodically increases its assumed PMTU. This will almost always + result in packets being discarded and Packet Too Big messages being + generated, because in most cases the PMTU of the path will not have + changed. Therefore, attempts to detect increases in a path's PMTU + should be done infrequently. + + Path MTU Discovery supports multicast as well as unicast + destinations. In the case of a multicast destination, copies of a + packet may traverse many different paths to many different nodes. + Each path may have a different PMTU, and a single multicast packet + may result in multiple Packet Too Big messages, each reporting a + different next-hop MTU. The minimum PMTU value across the set of + paths in use determines the size of subsequent packets sent to the + multicast destination. + + Note that Path MTU Discovery must be performed even in cases where a + node "thinks" a destination is attached to the same link as itself. + In a situation such as when a neighboring router acts as proxy [ND] + for some destination, the destination can to appear to be directly + connected but is in fact more than one hop away. + +4. Protocol Requirements + + As discussed in section 1, IPv6 nodes are not required to implement + Path MTU Discovery. The requirements in this section apply only to + those implementations that include Path MTU Discovery. + + When a node receives a Packet Too Big message, it MUST reduce its + estimate of the PMTU for the relevant path, based on the value of the + MTU field in the message. The precise behavior of a node in this + circumstance is not specified, since different applications may have + different requirements, and since different implementation + architectures may favor different strategies. + + After receiving a Packet Too Big message, a node MUST attempt to + avoid eliciting more such messages in the near future. The node MUST + reduce the size of the packets it is sending along the path. Using a + PMTU estimate larger than the IPv6 minimum link MTU may continue to + elicit Packet Too Big messages. Since each of these messages (and + the dropped packets they respond to) consume network resources, the + node MUST force the Path MTU Discovery process to end. + + Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast + as possible. Nodes MAY detect increases in PMTU, but because doing + so requires sending packets larger than the current estimated PMTU, + + + +McCann, Deering & Mogul Standards Track [Page 4] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + and because the likelihood is that the PMTU will not have increased, + this MUST be done at infrequent intervals. An attempt to detect an + increase (by sending a packet larger than the current estimate) MUST + NOT be done less than 5 minutes after a Packet Too Big message has + been received for the given path. The recommended setting for this + timer is twice its minimum value (10 minutes). + + A node MUST NOT reduce its estimate of the Path MTU below the IPv6 + minimum link MTU. + + Note: A node may receive a Packet Too Big message reporting a + next-hop MTU that is less than the IPv6 minimum link MTU. In that + case, the node is not required to reduce the size of subsequent + packets sent on the path to less than the IPv6 minimun link MTU, + but rather must include a Fragment header in those packets [IPv6- + SPEC]. + + A node MUST NOT increase its estimate of the Path MTU in response to + the contents of a Packet Too Big message. A message purporting to + announce an increase in the Path MTU might be a stale packet that has + been floating around in the network, a false packet injected as part + of a denial-of-service attack, or the result of having multiple paths + to the destination, each with a different PMTU. + +5. Implementation Issues + + This section discusses a number of issues related to the + implementation of Path MTU Discovery. This is not a specification, + but rather a set of notes provided as an aid for implementors. + + The issues include: + + - What layer or layers implement Path MTU Discovery? + + - How is the PMTU information cached? + + - How is stale PMTU information removed? + + - What must transport and higher layers do? + +5.1. Layering + + In the IP architecture, the choice of what size packet to send is + made by a protocol at a layer above IP. This memo refers to such a + protocol as a "packetization protocol". Packetization protocols are + usually transport protocols (for example, TCP) but can also be + higher-layer protocols (for example, protocols built on top of UDP). + + + + +McCann, Deering & Mogul Standards Track [Page 5] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + Implementing Path MTU Discovery in the packetization layers + simplifies some of the inter-layer issues, but has several drawbacks: + the implementation may have to be redone for each packetization + protocol, it becomes hard to share PMTU information between different + packetization layers, and the connection-oriented state maintained by + some packetization layers may not easily extend to save PMTU + information for long periods. + + It is therefore suggested that the IP layer store PMTU information + and that the ICMP layer process received Packet Too Big messages. + The packetization layers may respond to changes in the PMTU, by + changing the size of the messages they send. To support this + layering, packetization layers require a way to learn of changes in + the value of MMS_S, the "maximum send transport-message size". The + MMS_S is derived from the Path MTU by subtracting the size of the + IPv6 header plus space reserved by the IP layer for additional + headers (if any). + + It is possible that a packetization layer, perhaps a UDP application + outside the kernel, is unable to change the size of messages it + sends. This may result in a packet size that exceeds the Path MTU. + To accommodate such situations, IPv6 defines a mechanism that allows + large payloads to be divided into fragments, with each fragment sent + in a separate packet (see [IPv6-SPEC] section "Fragment Header"). + However, packetization layers are encouraged to avoid sending + messages that will require fragmentation (for the case against + fragmentation, see [FRAG]). + +5.2. Storing PMTU information + + Ideally, a PMTU value should be associated with a specific path + traversed by packets exchanged between the source and destination + nodes. However, in most cases a node will not have enough + information to completely and accurately identify such a path. + Rather, a node must associate a PMTU value with some local + representation of a path. It is left to the implementation to select + the local representation of a path. + + In the case of a multicast destination address, copies of a packet + may traverse many different paths to reach many different nodes. The + local representation of the "path" to a multicast destination must in + fact represent a potentially large set of paths. + + Minimally, an implementation could maintain a single PMTU value to be + used for all packets originated from the node. This PMTU value would + be the minimum PMTU learned across the set of all paths in use by the + node. This approach is likely to result in the use of smaller + packets than is necessary for many paths. + + + +McCann, Deering & Mogul Standards Track [Page 6] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + An implementation could use the destination address as the local + representation of a path. The PMTU value associated with a + destination would be the minimum PMTU learned across the set of all + paths in use to that destination. The set of paths in use to a + particular destination is expected to be small, in many cases + consisting of a single path. This approach will result in the use of + optimally sized packets on a per-destination basis. This approach + integrates nicely with the conceptual model of a host as described in + [ND]: a PMTU value could be stored with the corresponding entry in + the destination cache. + + If flows [IPv6-SPEC] are in use, an implementation could use the flow + id as the local representation of a path. Packets sent to a + particular destination but belonging to different flows may use + different paths, with the choice of path depending on the flow id. + This approach will result in the use of optimally sized packets on a + per-flow basis, providing finer granularity than PMTU values + maintained on a per-destination basis. + + For source routed packets (i.e. packets containing an IPv6 Routing + header [IPv6-SPEC]), the source route may further qualify the local + representation of a path. In particular, a packet containing a type + 0 Routing header in which all bits in the Strict/Loose Bit Map are + equal to 1 contains a complete path specification. An implementation + could use source route information in the local representation of a + path. + + Note: Some paths may be further distinguished by different + security classifications. The details of such classifications are + beyond the scope of this memo. + + Initially, the PMTU value for a path is assumed to be the (known) MTU + of the first-hop link. + + When a Packet Too Big message is received, the node determines which + path the message applies to based on the contents of the Packet Too + Big message. For example, if the destination address is used as the + local representation of a path, the destination address from the + original packet would be used to determine which path the message + applies to. + + Note: if the original packet contained a Routing header, the + Routing header should be used to determine the location of the + destination address within the original packet. If Segments Left + is equal to zero, the destination address is in the Destination + Address field in the IPv6 header. If Segments Left is greater + than zero, the destination address is the last address + (Address[n]) in the Routing header. + + + +McCann, Deering & Mogul Standards Track [Page 7] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + The node then uses the value in the MTU field in the Packet Too Big + message as a tentative PMTU value, and compares the tentative PMTU to + the existing PMTU. If the tentative PMTU is less than the existing + PMTU estimate, the tentative PMTU replaces the existing PMTU as the + PMTU value for the path. + + The packetization layers must be notified about decreases in the + PMTU. Any packetization layer instance (for example, a TCP + connection) that is actively using the path must be notified if the + PMTU estimate is decreased. + + Note: even if the Packet Too Big message contains an Original + Packet Header that refers to a UDP packet, the TCP layer must be + notified if any of its connections use the given path. + + Also, the instance that sent the packet that elicited the Packet Too + Big message should be notified that its packet has been dropped, even + if the PMTU estimate has not changed, so that it may retransmit the + dropped data. + + Note: An implementation can avoid the use of an asynchronous + notification mechanism for PMTU decreases by postponing + notification until the next attempt to send a packet larger than + the PMTU estimate. In this approach, when an attempt is made to + SEND a packet that is larger than the PMTU estimate, the SEND + function should fail and return a suitable error indication. This + approach may be more suitable to a connectionless packetization + layer (such as one using UDP), which (in some implementations) may + be hard to "notify" from the ICMP layer. In this case, the normal + timeout-based retransmission mechanisms would be used to recover + from the dropped packets. + + It is important to understand that the notification of the + packetization layer instances using the path about the change in the + PMTU is distinct from the notification of a specific instance that a + packet has been dropped. The latter should be done as soon as + practical (i.e., asynchronously from the point of view of the + packetization layer instance), while the former may be delayed until + a packetization layer instance wants to create a packet. + Retransmission should be done for only for those packets that are + known to be dropped, as indicated by a Packet Too Big message. + +5.3. Purging stale PMTU information + + Internetwork topology is dynamic; routes change over time. While the + local representation of a path may remain constant, the actual + path(s) in use may change. Thus, PMTU information cached by a node + can become stale. + + + +McCann, Deering & Mogul Standards Track [Page 8] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + If the stale PMTU value is too large, this will be discovered almost + immediately once a large enough packet is sent on the path. No such + mechanism exists for realizing that a stale PMTU value is too small, + so an implementation should "age" cached values. When a PMTU value + has not been decreased for a while (on the order of 10 minutes), the + PMTU estimate should be set to the MTU of the first-hop link, and the + packetization layers should be notified of the change. This will + cause the complete Path MTU Discovery process to take place again. + + Note: an implementation should provide a means for changing the + timeout duration, including setting it to "infinity". For + example, nodes attached to an FDDI link which is then attached to + the rest of the Internet via a small MTU serial line are never + going to discover a new non-local PMTU, so they should not have to + put up with dropped packets every 10 minutes. + + An upper layer must not retransmit data in response to an increase in + the PMTU estimate, since this increase never comes in response to an + indication of a dropped packet. + + One approach to implementing PMTU aging is to associate a timestamp + field with a PMTU value. This field is initialized to a "reserved" + value, indicating that the PMTU is equal to the MTU of the first hop + link. Whenever the PMTU is decreased in response to a Packet Too Big + message, the timestamp is set to the current time. + + Once a minute, a timer-driven procedure runs through all cached PMTU + values, and for each PMTU whose timestamp is not "reserved" and is + older than the timeout interval: + + - The PMTU estimate is set to the MTU of the first hop link. + + - The timestamp is set to the "reserved" value. + + - Packetization layers using this path are notified of the increase. + +5.4. TCP layer actions + + The TCP layer must track the PMTU for the path(s) in use by a + connection; it should not send segments that would result in packets + larger than the PMTU. A simple implementation could ask the IP layer + for this value each time it created a new segment, but this could be + inefficient. Moreover, TCP implementations that follow the "slow- + start" congestion-avoidance algorithm [CONG] typically calculate and + cache several other values derived from the PMTU. It may be simpler + to receive asynchronous notification when the PMTU changes, so that + these variables may be updated. + + + + +McCann, Deering & Mogul Standards Track [Page 9] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + A TCP implementation must also store the MSS value received from its + peer, and must not send any segment larger than this MSS, regardless + of the PMTU. In 4.xBSD-derived implementations, this may require + adding an additional field to the TCP state record. + + The value sent in the TCP MSS option is independent of the PMTU. + This MSS option value is used by the other end of the connection, + which may be using an unrelated PMTU value. See [IPv6-SPEC] sections + "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for + information on selecting a value for the TCP MSS option. + + When a Packet Too Big message is received, it implies that a packet + was dropped by the node that sent the ICMP message. It is sufficient + to treat this as any other dropped segment, and wait until the + retransmission timer expires to cause retransmission of the segment. + If the Path MTU Discovery process requires several steps to find the + PMTU of the full path, this could delay the connection by many + round-trip times. + + Alternatively, the retransmission could be done in immediate response + to a notification that the Path MTU has changed, but only for the + specific connection specified by the Packet Too Big message. The + packet size used in the retransmission should be no larger than the + new PMTU. + + Note: A packetization layer must not retransmit in response to + every Packet Too Big message, since a burst of several oversized + segments will give rise to several such messages and hence several + retransmissions of the same data. If the new estimated PMTU is + still wrong, the process repeats, and there is an exponential + growth in the number of superfluous segments sent. + + This means that the TCP layer must be able to recognize when a + Packet Too Big notification actually decreases the PMTU that it + has already used to send a packet on the given connection, and + should ignore any other notifications. + + Many TCP implementations incorporate "congestion avoidance" and + "slow-start" algorithms to improve performance [CONG]. Unlike a + retransmission caused by a TCP retransmission timeout, a + retransmission caused by a Packet Too Big message should not change + the congestion window. It should, however, trigger the slow-start + mechanism (i.e., only one segment should be retransmitted until + acknowledgements begin to arrive again). + + TCP performance can be reduced if the sender's maximum window size is + not an exact multiple of the segment size in use (this is not the + congestion window size, which is always a multiple of the segment + + + +McCann, Deering & Mogul Standards Track [Page 10] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + size). In many systems (such as those derived from 4.2BSD), the + segment size is often set to 1024 octets, and the maximum window size + (the "send space") is usually a multiple of 1024 octets, so the + proper relationship holds by default. If Path MTU Discovery is used, + however, the segment size may not be a submultiple of the send space, + and it may change during a connection; this means that the TCP layer + may need to change the transmission window size when Path MTU + Discovery changes the PMTU value. The maximum window size should be + set to the greatest multiple of the segment size that is less than or + equal to the sender's buffer space size. + +5.5. Issues for other transport protocols + + Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to + repacketize when doing a retransmission. That is, once an attempt is + made to transmit a segment of a certain size, the transport cannot + split the contents of the segment into smaller segments for + retransmission. In such a case, the original segment can be + fragmented by the IP layer during retransmission. Subsequent + segments, when transmitted for the first time, should be no larger + than allowed by the Path MTU. + + The Sun Network File System (NFS) uses a Remote Procedure Call (RPC) + protocol [RPC] that, when used over UDP, in many cases will generate + payloads that must be fragmented even for the first-hop link. This + might improve performance in certain cases, but it is known to cause + reliability and performance problems, especially when the client and + server are separated by routers. + + It is recommended that NFS implementations use Path MTU Discovery + whenever routers are involved. Most NFS implementations allow the + RPC datagram size to be changed at mount-time (indirectly, by + changing the effective file system block size), but might require + some modification to support changes later on. + + Also, since a single NFS operation cannot be split across several UDP + datagrams, certain operations (primarily, those operating on file + names and directories) require a minimum payload size that if sent in + a single packet would exceed the PMTU. NFS implementations should + not reduce the payload size below this threshold, even if Path MTU + Discovery suggests a lower value. In this case the payload will be + fragmented by the IP layer. + + + + + + + + + +McCann, Deering & Mogul Standards Track [Page 11] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + +5.6. Management interface + + It is suggested that an implementation provide a way for a system + utility program to: + + - Specify that Path MTU Discovery not be done on a given path. + + - Change the PMTU value associated with a given path. + + The former can be accomplished by associating a flag with the path; + when a packet is sent on a path with this flag set, the IP layer does + not send packets larger than the IPv6 minimum link MTU. + + These features might be used to work around an anomalous situation, + or by a routing protocol implementation that is able to obtain Path + MTU values. + + The implementation should also provide a way to change the timeout + period for aging stale PMTU information. + +6. Security Considerations + + This Path MTU Discovery mechanism makes possible two denial-of- + service attacks, both based on a malicious party sending false Packet + Too Big messages to a node. + + In the first attack, the false message indicates a PMTU much smaller + than reality. This should not entirely stop data flow, since the + victim node should never set its PMTU estimate below the IPv6 minimum + link MTU. It will, however, result in suboptimal performance. + + In the second attack, the false message indicates a PMTU larger than + reality. If believed, this could cause temporary blockage as the + victim sends packets that will be dropped by some router. Within one + round-trip time, the node would discover its mistake (receiving + Packet Too Big messages from that router), but frequent repetition of + this attack could cause lots of packets to be dropped. A node, + however, should never raise its estimate of the PMTU based on a + Packet Too Big message, so should not be vulnerable to this attack. + + A malicious party could also cause problems if it could stop a victim + from receiving legitimate Packet Too Big messages, but in this case + there are simpler denial-of-service attacks available. + + + + + + + + +McCann, Deering & Mogul Standards Track [Page 12] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + +Acknowledgements + + We would like to acknowledge the authors of and contributors to + [RFC-1191], from which the majority of this document was derived. We + would also like to acknowledge the members of the IPng working group + for their careful review and constructive criticisms. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McCann, Deering & Mogul Standards Track [Page 13] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + +Appendix A - Comparison to RFC 1191 + + This document is based in large part on RFC 1191, which describes + Path MTU Discovery for IPv4. Certain portions of RFC 1191 were not + needed in this document: + + router specification - Packet Too Big messages and corresponding + router behavior are defined in [ICMPv6] + + Don't Fragment bit - there is no DF bit in IPv6 packets + + TCP MSS discussion - selecting a value to send in the TCP MSS + option is discussed in [IPv6-SPEC] + + old-style messages - all Packet Too Big messages report the + MTU of the constricting link + + MTU plateau tables - not needed because there are no old-style + messages + +References + + [CONG] Van Jacobson. Congestion Avoidance and Control. Proc. + SIGCOMM '88 Symposium on Communications Architectures and + Protocols, pages 314-329. Stanford, CA, August, 1988. + + [FRAG] C. Kent and J. Mogul. Fragmentation Considered Harmful. + In Proc. SIGCOMM '87 Workshop on Frontiers in Computer + Communications Technology. August, 1987. + + [ICMPv6] Conta, A., and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 1885, December 1995. + + [IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 1883, December 1995. + + [ISOTP] ISO. ISO Transport Protocol Specification: ISO DP 8073. + RFC 905, SRI Network Information Center, April, 1984. + + [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", Work in Progress. + + [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", + RFC 1191, November 1990. + + + + + + +McCann, Deering & Mogul Standards Track [Page 14] + +RFC 1981 Path MTU Discovery for IPv6 August 1996 + + + [RPC] Sun Microsystems, Inc., "RPC: Remote Procedure Call + Protocol", RFC 1057, SRI Network Information Center, + June, 1988. + +Authors' Addresses + + Jack McCann + Digital Equipment Corporation + 110 Spitbrook Road, ZKO3-3/U14 + Nashua, NH 03062 + Phone: +1 603 881 2608 + + Fax: +1 603 881 0120 + Email: mccann@zk3.dec.com + + + Stephen E. Deering + Xerox Palo Alto Research Center + 3333 Coyote Hill Road + Palo Alto, CA 94304 + Phone: +1 415 812 4839 + + Fax: +1 415 812 4471 + EMail: deering@parc.xerox.com + + + Jeffrey Mogul + Digital Equipment Corporation Western Research Laboratory + 250 University Avenue + Palo Alto, CA 94301 + Phone: +1 415 617 3304 + + EMail: mogul@pa.dec.com + + + + + + + + + + + + + + + + + + +McCann, Deering & Mogul Standards Track [Page 15] + |