Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt

[Joe Touch <[e-mail]>]

Hi, Tom,

On 11/2/2015 6:04 PM, Tom Herbert wrote:
> On Tue, Nov 3, 2015 at 10:48 AM, Joe Touch <[e-mail]> wrote:
...
>>
>>> The option bytes would not be covered by the UDP checksum however.
>>
>> Correct. A separate "trailer checksum" would be required to protect the trailer.
>>
> That's great. Can you add this description to the draft?

Will do.

> One other question. In this model the options are really part of the
> IP payload and not the UDP payload 

Yes, basically.

> (so presumably this solution is not
> UDP specific but can be applied to any protocol). 

It requires a protocol that has a redundant length field. E.g., TCP does
not, in fact few transport protocols do.

> Essentially this
> another way to extend IP 

I don't see that; IP declares a payload size and a protocol type. As far
as IP is concerned the entire payload area belongs to the protocol type
indicated. It's the protocol's decision how to handle that - for TCP,
there's no separate length field (only a header length). For UDP,
there's a *UDP payload* length, which means we can set it smaller than
what IP has set aside and let *UDP* use the rest.

> and so it seems conceivable that these TLVs
> could alternatively be put into an IPv6 extension header to accomplish
> the same effect (at least for IPv6). Have you considered the tradeoffs
> for doing that?

See above. Putting TLVs in the endpoint protocol is already commonly
supported (TCP options are common). TLV parsing support for IPv6 has
been much more difficult to come by in core routers.

Joe