6.2 mtu now limits size of incomming packet

[Stephen Clark]

Chuck Swiger wrote:

>On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
>  
>
>>>I agree with others that MTU means "limit what I transmit".  It  
>>>does not
>>>mean "limit what someone else can transmit to me."
>>>      
>>>
>>Interesting viewpoint.  I disagree with it, but I can't quote any  
>>standard
>>or otherwise to support my view.  You didn't either.
>>
>>Does anyone know of a publicised, authoritative standard that would  
>>clear this up?
>>    
>>
>
>Sure.  RFC-791:
>
>"Fragmentation
>
>     Fragmentation of an internet datagram is necessary when it
>     originates in a local net that allows a large packet size and must
>     traverse a local net that limits packets to a smaller size to reach
>     its destination.
>
>     An internet datagram can be marked "don't fragment."  Any internet
>     datagram so marked is not to be internet fragmented under any
>     circumstances.  If internet datagram marked don't fragment  
>cannot be
>     delivered to its destination without fragmenting it, it is to be
>     discarded instead.
>
>     Fragmentation, transmission and reassembly across a local network
>     which is invisible to the internet protocol module is called
>     intranet fragmentation and may be used [6]."
>
>RFC-879:
>
>"     HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY
>       HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO
>       ACCEPT LARGER DATAGRAMS."
>
>"8.  Maximum Packet Size
>
>    Each network has some maximum packet size, or maximum transmission
>    unit (MTU).  Ultimately there is some limit imposed by the
>    technology, but often the limit is an engineering choice or even an
>    administrative choice.  Different installations of the same network
>    product do not have to use the same maximum packet size.  Even  
>within
>    one installation not all host must use the same packet size (this  
>way
>    lies madness, though).
>
>    Some IP implementers have assumed that all hosts on the directly
>    attached network will be the same or at least run the same
>    implementation.  This is a dangerous assumption.  It has often
>    developed that after a small homogeneous set of host have become
>    operational additional hosts of different types are introduced into
>    the environment.  And it has often developed that it is desired to
>    use a copy of the implementation in a different inhomogeneous
>    environment.
>
>    Designers of gateways should be prepared for the fact that  
>successful
>    gateways will be copied and used in other situation and
>    installations.  Gateways must be prepared to accept datagrams as
>    large as can be sent in the maximum packets of the directly attached
>    networks.  
>
Doesn't this imply if a gateway has 2 interfaces, one with an mtu of 
1280 and the other
with an mtu of 1500 it should accept 1500 on either interface?

>Gateway implementations should be easily configured for
>    installation in different circumstances.
>
>    A footnote:  The MTUs of some popular networks (note that the actual
>    limit in some installations may be set lower by administrative
>    policy):
>
>       ARPANET, MILNET = 1007
>       Ethernet (10Mb) = 1500
>       Proteon PRONET  = 2046"
>
>RFC-894:
>
>"  The minimum length of the data field of a packet sent over an
>    Ethernet is 1500 octets, thus the maximum length of an IP datagram
>    sent over an Ethernet is 1500 octets.  Implementations are  
>encouraged
>    to support full-length packets.  Gateway implementations MUST be
>    prepared to accept full-length packets and fragment them if
>    necessary.  If a system cannot receive full-length packets, it  
>should
>    take steps to discourage others from sending them, such as using the
>    TCP Maximum Segment Size option [4].
>
>    Note:  Datagrams on the Ethernet may be longer than the general
>    Internet default maximum packet size of 576 octets.  Hosts connected
>    to an Ethernet should keep this in mind when sending datagrams to
>    hosts not on the same Ethernet.  It may be appropriate to send
>    smaller datagrams to avoid unnecessary fragmentation at intermediate
>    gateways.  Please see [4] for further information on this point."
>
>And RFCs 1122 and 1191 are also somewhat relevant.  My reading of the  
>above is that ethernet-capable gateways must be willing to accept  
>packets as large as 1500 octets and fragment such traffic to meet the  
>MTU settings as needed, except if DF is set.  If DF is set, but the  
>packet is addressed to the gateway itself, then it should be  
>delivered unfragmented even if that packet exceeded the MTU set on  
>the receiving interface.
>
>For hosts which are not network gateways, one should not assume them  
>to be capable of receiving packets larger than 576 octets, but the  
>TCP MSS option is almost universally available to indicate the  
>appropriate maximum size that host is willing to receive during the  
>3WHS setup...
>
>  
>


-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)