6.2 mtu now limits size of incomming packet

[Stephen Clark]

Bill Moran wrote:

>In response to Stephen Clark <Stephen.Clark at seclark.us>:
>
>  
>
>>Bill Moran wrote:
>>
>>    
>>
>>>In response to Stephen Clark <Stephen.Clark at seclark.us>:
>>>
>>>      
>>>
>>>>Sten Daniel Soersdal wrote:
>>>>
>>>>        
>>>>
>>>>>Stephen Clark wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
>>>>>>accept a larger incomming packet.
>>>>>>
>>>>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
>>>>>>1294)
>>>>>>            
>>>>>>
>>>>>That is what to be expected.
>>>>>Incoming interface must have mtu set to the same mtu as all other hosts 
>>>>>on the same L2 network. If mtu is set to the same as all other hosts, 
>>>>>then it is impossible to receive a frame that is too large (assuming 
>>>>>everything works).
>>>>>
>>>>>          
>>>>>
>>>>>>I don't think it worked this way in the past.
>>>>>>
>>>>>>Won't this affect pmtud?
>>>>>>            
>>>>>>
>>>>>Incoming interface must have its mtu set to large enough to receive the 
>>>>>frame. Outgoing interface, on the other hand, can be lower.
>>>>>
>>>>>For pmtud to work you need to be able to receive packets on an interface 
>>>>>with sufficiently set mtu, but the exitting interface can have a lower 
>>>>>mtu configured. Thus the router can accept the incoming packet but may 
>>>>>drop and notify on a frame that is too large to exit the outgoing 
>>>>>interface (assuming DF is set).
>>>>>
>>>>>          
>>>>>
>>>>>>man page for ifconfig says mtu limits size of "transmission" not reception.
>>>>>>
>>>>>>  "mtu n   Set the maximum transmission unit of the interface to n, 
>>>>>>default
>>>>>>          is interface specific."
>>>>>>
>>>>>>            
>>>>>>
>>>>>Perhaps the man author considered reception to be implied?
>>>>>
>>>>>In any case, enforcing this on incoming packets is correct behavior.
>>>>>          
>>>>>
>>>>But shouldn't an icmp be generated back to the system sending the packet 
>>>>that is
>>>>being dropped? This is not happening. So the connection stalls.
>>>>        
>>>>
>>>No.  You're thinking of PMTU, which involves the don't fragment bit and
>>>intermediate routers.
>>>
>>>A packet that exceeds the network maximum MTU is an invalid packet, and
>>>thus should be dropped silently or it could cause a DoS.
>>>      
>>>
>>This is not the behavior FreeBSD 4.9 exhibits. I just tested it. I had a 
>>mtu of 1280 on the
>>rl1 interface and it glady accepted packets of 1460.
>>    
>>
>
>I don't see that as relevant.  I'm sure earlier versions of many parts of
>FreeBSD had bugs.  Take also into account the fact that best practices are
>still evolving.
>
>Let's flip the question around a bit: why would you _want_ the TCP stack
>to accept frames larger than the stated MTU?
>
>  
>
I guess because thats the way it used to work ;-) , and it caused me 
confusion in testing our
updated security appliance that used to be based on 4.9 and now will be 
based on 6.x.

As I am gaining a better understanding of things I don't see it as a 
real problem.

Thanks for you input.
Steve

-- 

"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)