Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-options issues from IETF 104)

[Joe Touch <[e-mail]>]

We can - there are a few ways to do this:
- pick one KIND and let it say that the next 3 bytes indicate the next KIND and 2-byte length
- use a subset of the range of KINDs, reserved in advance, for this purpose

Note that code points are already assigned to mimic TCP:
0 is already in use
254 is already reserved for experiments
255 is already reserved, likely to extend the KIND space itself

It might be reasonable to use 255 for this purpose because it inherently extends the KIND space anyway.

Joe

> On Jul 18, 2019, at 5:45 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> Ah so, I guess the document editors canm work out what is best to do.
> 
> My wish was to systematically allow larger options to be possible.
> 
> Gorry
> 
> On 18/07/2019, 13:41, [e-mail] wrote:
>> Re-,
>> 
>> 0/1 are illegal values. These values MUST NOT be used. A receiver will discard them systematically.
>> 
>> With the proposed approach: 254/255 are legal values... but with a special meaning.
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : Gorry Fairhurst [mailto:[e-mail]]
>>> Envoyé : jeudi 18 juillet 2019 14:26
>>> À : BOUCADAIR Mohamed TGI/OLN
>>> Objet : Re: Options larger than 255 (was RE: [tsvwg] draft-ietf-udp-
>>> options issues from IETF 104)
>>> 
>>> I don't mind the choice of codepoint, my understaning was zero was an
>>> invalid length, and an easy thing to test in code. Choosing 254 or 255
>>> seems less obvious to me, but if there are good reasons, just say...
>>> 
>>> Gorry
>>> 
>>> On 18/07/2019, 12:48, [e-mail] wrote:
>>>> Re-,
>>>> 
>>>> Associating a meaning with Len=0 as proposed by Joe may not be
>>> intuitive. An alternate approach would be:
>>>> * 'Len' only covers the option data field (that is, 'kind' and 'Len'
>>> fields are not covered. The overall option length can be easily inferred).
>>>> * Associate a meaning with one of the two values we grabbed:
>>>>   - 254 or 255: a 16-bit extended length field follows
>>>> 
>>>> Cheers,
>>>> Med
>>>> 
>>>>> -----Message d'origine-----
>>>>> De : tsvwg [mailto:[e-mail]] De la part de Gorry
>>> Fairhurst
>>>>> Envoyé : jeudi 18 juillet 2019 12:22
>>>>> À : [e-mail]
>>>>> Cc : tsvwg
>>>>> Objet : Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
>>>>> 
>>>>>> Gorry
>>>>> P.S. I like the idea to explicitly allow options longer than 255 bytes?
>>>>> - This seems useful for fragmentation and would be an easy addition,
>>>>> someone suggested using 0 option length to indicate a 16b length field,
>>>>> which could make total sense. As in:
>>>>> 
>>>>> https://mailarchive.ietf.org/arch/msg/tsvwg/B4oeZkpagdl4gkAMDCFW7F1A7_8
>>>>> 
>>>>> Gorry
>