⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1063.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 2 页
字号:
Network Working Group                                      J.  MogulRequest For Comments: 1063                                   C. Kent                                                                 DEC                                                        C. Partridge                                                                 BBN                                                       K. McCloghrie                                                                 TWG                                                           July 1988                        IP MTU Discovery OptionsSTATUS OF THIS MEMO   A pair of IP options that can be used to learn the minimum MTU of a   path through an internet is described, along with its possible uses.   This is a proposal for an Experimental protocol.  Distribution of   this memo is unlimited.INTRODUCTION   Although the Internet Protocol allows gateways to fragment packets   that are too large to forward, fragmentation is not always desirable.   It can lead to poor performance or even total communication failure   in circumstances that are surprisingly common.  (For a thorough   discussion of this issue, see [1]).   A datagram will be fragmented if it is larger than the Maximum   Transmission Unit (MTU) of some network along the path it follows.   In order to avoid fragmentation, a host sending an IP datagram must   ensure that the datagram is no larger than the Minimum MTU (MINMTU)   over the entire path.   It has long been recognized that the methods for discovering the   MINMTU of an IP internetwork path are inadequate.  The methods   currently available fall into two categories: (1) choosing small MTUs   to avoid fragmentation or (2) using additional probe packets to   discover when fragmentation will occur.  Both methods have problems.   Choosing MTUs requires a balance between network utilization (which   requires the use of the largest possible datagram) and fragmentation   avoidance (which in the absence of knowledge about the network path   encourages the use of small, and thus too many, datagrams).  Any   choice for the MTU size, without information from the network, is   likely to either fail to properly utilize the network or fail to   avoid fragmentation.   Probe packets have the problem of burdening the network withMogul, Kent, Partridge, & McCloghrie                            [Page 1]RFC 1063                IP MTU Discovery Options               July 1988   unnecessary packets.  And because network paths often change during   the lifetime of a TCP connection, probe packets will have to be sent   on a regular basis to detect any changes in the effective MINMTU.   Implementors sometimes mistake the TCP MSS option as a mechanism for   learning the network MINMTU.  In fact, the MSS option is only a   mechanism for learning about buffering capabilities at the two TCP   peers.  Separate provisions must be made to learn the IP MINMTU.   In this memo, we propose two new IP options that, when used in   conjunction will permit two peers to determine the MINMTU of the   paths between them.  In this scheme, one option is used to determine   the lowest MTU in a path; the second option is used to convey this   MTU back to the sender (possibly in the IP datagram containing the   transport acknowledgement to the datagram which contained the MTU   discovery option).OPTION FORMATS   Probe MTU Option (Number 11)      Format              +--------+--------+--------+--------+              |00001011|00000100|   2 octet value |              +--------+--------+--------+--------+      Definition      This option always contains the lowest MTU of all the networks      that have been traversed so far by the datagram.      A host that sends this option must initialize the value field to      be the MTU of the directly-connected network.  If the host is      multi-homed, this should be for the first-hop network.      Each gateway that receives a datagram containing this option must      compare the MTU field with the MTUs of the inbound and outbound      links for the datagram.  If either MTU is lower than the value in      the MTU field of the option, the option value should be set to the      lower MTU.  (Note that gateways conforming to RFC-1009 may not      know either the inbound interface or the outbound interface at the      time that IP options are processed.  Accordingly, support for this      option may require major gateway software changes).      Any host receiving a datagram containing this option should      confirm that value of the MTU field of the option is less than or      equal to that of the inbound link, and if necessary, reduce theMogul, Kent, Partridge, & McCloghrie                            [Page 2]RFC 1063                IP MTU Discovery Options               July 1988      MTU field value, before processing the option.      If the receiving host is not able to accept datagrams as large as      specified by the value of the MTU field of the option, then it      should reduce the MTU field to the size of the largest datagram it      can accept.   Reply MTU Option (Number 12)      Format              +--------+--------+--------+--------+              |00001100|00000100|   2 octet value |              +--------+--------+--------+--------+      Definition      This option is used to return the value learned from a Probe MTU      option to the sender of the Probe MTU option.RELATION TO TCP MSS   Note that there are two superficially similar problems in choosing   the size of a datagram.  First, there is the restriction [2] that a   host not send a datagram larger than 576 octets unless it has   assurance that the destination is prepared to accept a larger   datagram.  Second, the sending host should not send a datagram larger   than MINMTU, in order to avoid fragmentation.  The datagram size   should normally be the minimum of these two lower bounds.   In the past, the TCP MSS option [3] has been used to avoid sending   packets larger than the destination can accept.  Unfortunately, this   is not the most general mechanism; it is not available to other   transport layers, and it cannot determine the MINMTU (because   gateways do not parse TCP options).   Because the MINMTU returned by a probe cannot be larger than the   maximum datagram size that the destination can accept, this IP option   could, in theory, supplant the use of the TCP MSS option, providing   an economy of mechanism.  (Note however, that some researchers   believe that the value of the TCP MSS is distinct from the path's   MINMTU.  The MSS is the upper limit of the data size that the peer   will accept, while the MINMTU represents a statement about the data   size supported by the path).   Note that a failure to observe the MINMTU restriction is not normally   fatal; fragmentation will occur, but this is supposed to work.  A   failure to observe the TCP MSS option, however, could be fatalMogul, Kent, Partridge, & McCloghrie                            [Page 3]RFC 1063                IP MTU Discovery Options               July 1988   because it might lead to datagrams that can never be accepted by the   destination.  Therefore, unless and until the Probe MTU option is   universally implemented, at least by hosts, the TCP MSS option must   be used as well.IMPLEMENTATION APPROACHES   Who Sends the Option      There are at least two ways to implement the MTU discovery scheme.      One method makes the transport layer responsible for MTU      discovery; the other method makes the IP layer responsible for MTU      discovery.  A host system should support one of the two schemes.   Transport Discovery      In the transport case, the transport layer can include the Probe      MTU option in an outbound datagram.  When a datagram containing      the Probe MTU option is received, the option must be passed up to      the receiving transport layer, which should then acknowledge the      Probe with a Reply MTU option in the next return datagram.  Note      that because the options are placed on unreliable datagrams, the      original sender will have to resend Probes (possibly once per      window of data) until it receives a Reply option.  Also note that      the Reply MTU option may be returned on an IP datagram for a      different transport protocol from which it was sent (e.g., TCP      generated the probe but the Reply was received on a UDP datagram).   IP Discovery      A better scheme is to put MTU discovery into the IP layer, using      control mechanisms in the routing cache.  Whenever an IP datagram      is sent, the IP layer checks in the routing cache to see if a      Probe or Reply MTU option needs to be inserted in the datagram.      Whenever a datagram containing either option is received, the      information in those options is placed in the routing cache.      The basic working of the protocol is somewhat complex.  We trace      it here through one round-trip.  Implementors should realize that      there may be cases where both options are contained in one      datagram.  For the purposes of this exposition, the sender of the      probe is called the Probe-Sender and the receiver, Probe-Receiver.      When the IP layer is asked to send a Probe MTU option (see the      section below on when to probe), it makes some record in the      routing cache that indicates the next IP datagram to Probe-      Receiver should contain the Probe MTU option.Mogul, Kent, Partridge, & McCloghrie                            [Page 4]RFC 1063                IP MTU Discovery Options               July 1988      When the next IP datagram to Probe-Receiver is sent, the Probe MTU      option is inserted.  The IP layer in Probe-Sender should continue      to send an occasional Probe MTU in subsequent datagrams until a      Reply MTU option is received.  It is strongly recommended that the      Probe MTU not be sent in all datagrams but only at such a rate      that, on average, one Probe MTU will be sent per round-trip      interval.  (Another way of saying this is that we would hope that      only one datagram in a transport protocol window worth of data has      the Probe MTU option set).  This mechanism might be implemented by      sending every Nth packet, or, in those implementations where the      round-trip time estimate to the destination is cached with the      route, once every estimated RTT.      When a Probe MTU option is received by Probe-Receiver, the      receiving IP should place the value of this option in the next      datagram it sends back to Probe-Sender.  The value is then      discarded.  In other words, each Probe MTU option causes the Reply      MTU option to be placed in one return datagram.      When Probe-Sender receives the Reply MTU option, it should check      the value of the option against the current MINMTU estimate in the      routing cache.  If the option value is lower, it becomes the new      MINMTU estimate.  If the option value is higher, Probe-Sender      should be more conservative about changing the MINMTU estimate.      If a route is flapping, the MINMTU may change frequently.  In such      situations, keeping the smallest MINMTU of various routes in use      is preferred.  As a result, a higher MINMTU estimate should only      be accepted after a lower estimate has been permitted to "age" a      bit.  In other words, if the probe value is higher than the      estimated MINMTU, only update the estimate if the estimate is      several seconds old or more.  Finally, whenever the Probe-Sender      receives a Reply MTU option, it should stop retransmitting probes      to Probe-Receiver.      A few additional issues complicate this discussion.      One problem is setting the default MINMTU when no Reply MTU      options have been received.  We recommend the use of the minimum      of the supported IP datagram size (576 octets) and the connected      network MTU for destinations not on the local connected network,      and the connected network MTU for hosts on the connected network.      The MINMTU information, while kept by the Internet layer, is in      fact, only of interest to the transport and higher layers.      Accordingly, the Internet layer must keep the transport layer      informed of the current value of the estimated MINMTU.      Furthermore, minimal transport protocols, such as UDP, must be      prepared to pass this information up to the transport protocolMogul, Kent, Partridge, & McCloghrie                            [Page 5]RFC 1063                IP MTU Discovery Options               July 1988      user.      It is expected that there will be a transition period during which      some hosts support this option and some do not.  As a result,      hosts should stop sending Probe MTU options and refuse to send any      further options if it does not receive either a Probe MTU option      or Reply MTU option from the remote system after a certain number      of Probe MTU options have been sent.  In short, if Probe-Sender      has sent several probes but has gotten no indication that Probe-      Receiver supports MTU probing, then Probe-Sender should assume      that Probe-Receiver does not support probes.  (Obviously, if      Probe-Sender later receives a probe option from Probe-Receiver, it      should revise its opinion.)      Implementations should not assume that routes to the same      destination that have a different TOS have the same estimated      MINMTU.  We recommend that the MTU be probed separately for each      TOS.   Respecting the TCP MSS      One issue concerning TCP MSS is that it is usually negotiated      assuming an IP header that contains no options.  If the transport      layer is sending maximum size segments, it may not leave space for

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -