Subject: Re: [tcpm] Extending TCP option space

From: Wesley Eddy <[email-masked]>
Date: Thu, 01 Sep 2011 09:56:46 -0400

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

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Sep 2011 10:09:52 -0400

On 8/31/11 4:26 PM, Joe Touch wrote:
> On 8/31/2011 11:13 AM, William Allen Simpson wrote:
> Thanks for letting us know. I'll let IANA to mark those as (further) unauthorized uses.
>
Already told this list long ago, and already told IANA even longer ago.
But thanks for getting IANA to add them to its listing?

> In the meantime, please stop and use the experimental options until you get an assignment, IMO.
>
No.  They don't work.  There are too many conflicts -- as you well know,
and has already been documented and discussed on this list.

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Sep 2011 10:48:32 -0400

> has come up several times in the recent past.
Either that, or the IESG is "being anti-social and making the Internet
more brittle in the long term."

Many organizations now, some of them very large, are ignoring the IESG
(and thence IANA).  At least we tried to engage the IESG.  Waste of time,
but still we tried....

The IESG has repeatedly broken the social compact.  They seem to think
they have a lever of control (protocol numbers), but that's only true to
the extent that *everybody* agrees the IESG is relevant.

"Rough consensus and running code."

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Sep 2011 07:54:34 -0700

On 9/1/2011 7:09 AM, William Allen Simpson wrote:
...
> and has already been documented and discussed on this list.

The only way they don't work is if you've deployed an experiment outside 
a controlled environment AND haven't used a nonce to differentiate your 
experiment from others.

The former is a requirement of an experiment. The latter was discussed 
on this list.

If that's still not enough for you, YOU'RE NOT RUNNING JUST AN 
EXPERIMENT - you are ***contaminating*** the Internet with a protocol 
that is squatting on a scarce and reserved community resource -- and 
need to stop.

Joe