Re: [tsvwg] UDP options and header-data split (zero copy)

[Joe Touch <[e-mail]>]

Right, but for UDP the receive MTU is the one we care about. 

Joe 

> On Aug 1, 2021, at 3:05 PM, Michael Tuexen <[e-mail]> wrote:
> 
> 
>> 
>> On 1. Aug 2021, at 23:43, Tom Herbert <[e-mail]> wrote:
>> 
>>> On Sun, Aug 1, 2021 at 2:24 PM Joseph Touch <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> On Aug 1, 2021, at 2:19 PM, Tom Herbert <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> On Sun, Aug 1, 2021, 12:42 PM Joseph Touch <[e-mail]> wrote:
>>>> 
>>>> 
>>>> ...
>>>> Had we limited the option length as a few suggested when this work started, we would not have FRAG.
>>>> 
>>>> We don’t know what others are, but we also don’t know that the first frag will have hundreds of bytes of available space either.
>>> 
>>> 
>>> Actually, we do know that. The minimum MTU in IPv6 is 1280 and the minimum MTU for IPv4 is 576.
>>> 
>>> 
>>> The min MTU for IPv4 is 68..
>> 
>> Per RFC791 it's 576 bytes.
> RFC 791 makes a requirement on the receiver, not on the links.
> 
> Page 25 of RFC 791 reads:
> 
>    Every internet module must be able to forward a datagram of 68
>    octets without further fragmentation.  This is because an internet
>    header may be up to 60 octets, and the minimum fragment is 8 octets.
> 
> Therefore, the min MTU for IPv4 is 68.
> 
> Best regards
> Michael
>> 
>>> 
>>> If someone we're so inclined they could fill up the first fragment packet with nothing but options and start the payload in the second. That means you'll have at least 520 bytes for options.
>>> 
>>> 
>>> That includes BOTH per-fragment and per-reassembled datagram options.
>>> 
>>> But all this is academic since there's no use case other than DoS attack that would need anything close to that much space.
>>> 
>>> 
>>> That was true until FRAG too.
>>> 
>>> Again, this is a new decision - to limit the option space.
>> 
>> I don't know what that means.
>> 
>>> 
>>> Joe
>> 
>