Re: [tcpm] Extending TCP option space

[Wesley Eddy <[e-mail]>]

On 8/31/2011 2:13 PM, William Allen Simpson wrote:
> On 8/31/11 9:57 AM, Pasi Sarolahti wrote:
>> TCP's option space has been under increasing demand recently, with new
>> option-space hungry extensions such as MPTCP, and some recent ideas in
>> the research domain. In the past there have been some discussion about
>> mechanisms to extend the option space, and an extension option was
>> proposed in draft-eddy-tcp-loo, but since then these efforts have died
>> down. I'm wondering if there would be any interest in the tcpm
>> community to resume this work.
>>
> Already done, already tested. RFC-6013.
>
>
>> I recall that re-segmenting middleboxes were mentioned as one
>> potential problem for such extension, and there might be other
>> problems. Nevertheless, I would find it useful, if there was an RFC
>> that a) documented the known problems with option space extension; and
>> b) defined an option format and assigned the needed type codes, to
>> enable experimentations with larger than 40-byte option space.
>>
> I'm using options 31 and 32. See
> https://tools.ietf.org/html/draft-simpson-tcpct-api-04

AD hat on ...

Just so there is no confusion:
- those numbers have *not* been allocated from IANA
- picking your own numbers and notifying IANA later is *not* the process
- RFC 6013 specifically says that it uses 253 and 254, which is not
   consistent with the draft linked to above

There is a sentence in section 9.3 of RFC 2780 that says:
    Values in the Option Kind field are assigned following an IESG
    Approval or Standards Action process.
This in no way suggests that people select their own kind numbers
and then notify IANA later.  Vendors and others who are disregarding
this are being anti-social and making the Internet more brittle in
the long term.  Honest mistakes are one thing, but please let's
learn from them and stop continuously making them, as this problem
has come up several times in the recent past.

-- 
Wes Eddy
MTI Systems