6.2 mtu now limits size of incomming packet

[Julian Elischer]

Stephen Clark wrote:
> 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?

not specifically but I would..

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