Re: [tsvwg] design assumptions - draft-ietf-udp-options

[Joe Touch <[e-mail]>]

FWIW, #5 Frag is a driving case for DNSSEC to allow UDP messages larger than the min MTU to traverse NATs. IP

And it should never interact with IP fragmentation any more than TCP segmentation does. 

#6 is required to enable #5.

And thus far, #8 is required to support #5 in a way that satisfies #2.

I.e., the ones I listed can’t be teased out the way you’re suggesting.

Joe

> On Jul 17, 2019, at 7:46 AM, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Joe,
> 
> IMO, the core requirements are #1, #2, #3, #4, and #7. 
> 
> #7 should be mandatory feature. 
> 
> 5#, 6#, and #8 are nice-to-have. I would even prefer if those are covered in a separate specification. For example, I'm not sure whether FRAG will be useful and how it can interacts with IP fragmentation.  
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : tsvwg [mailto:[e-mail]] De la part de Joe Touch
>> Envoyé : mercredi 17 juillet 2019 02:31
>> À : tsvwg
>> Objet : [tsvwg] design assumptions - draft-ietf-udp-options
>> 
>> Getting back to the core design assumptions:
>> 
>> 1- support options
>> 2- allow at least some options to be silently ignored by legacy receivers
>> (to enable ‘“optionally enhanced” exchanges)
>> 3- allow at least some options to be required
>> 4- allow the options themselves to be protected
>> 5- support for fragmentation/reassembly
>> 6- support for MTU discovery
>> 7- support (optional?) middlebox checksum/payload length bug traversal
>> 8- support LITE, i.e., where some of the payload is not covered by at
>> least some checksum processing
>> 
>> AFAICT:
>> 
>> #7 requires a CCO-like sum, but it MUST he calculated AFTER all other
>> options are populated (it depends on the value of ALL other options and
>> surplus data)
>> 
>> #8 can depend on everything except CCO (it doesn’t need to protect CCO),
>> but it depends on the value of all other options and needs to be computed
>> next-to-last (or last if CCO isn’t present)
>> 
>> And we need a way to know:
>> 	- for #7, whether CCO is included or not used (at user’s peril, but
>> to allow for transmitters to avoid work)
>> 	- for #8, when to end the options (either a length field OR a EOL
>> flag)
>> 
>> Are there any other design requirements?
>> 
>> Joe
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>