Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

["C. M. Heard" <[e-mail]>]

On Wed, Jul 17, 2019 at 9:21 AM Tom Herbert <[e-mail]> wrote:
> On Wed, Jul 17, 2019 at 9:06 AM C. M. Heard <[e-mail]> wrote:
> > It may be reasonable to set some lower bounds on what a conforming
> > implementation is obliged to accept -- something along the lines of
> > the requirement in RFC 792 that "[a]ll hosts must be prepared to
> > accept datagrams of up to 576 octets (whether they arrive whole or
> > in fragments)." But that does not need to be -- and in general should
> > not be -- baked into the protocol structure. Capabilities change, and
> > increased limits can find their way over time into new implementations,
> > but not if the protocol structure imposes an artificial ceiling.
> >
>
> Mike,
>
> See Section 5.3 of RFC8504. This text should be adaptable to any
> stateless protocol containing TLVs.

Yes, something along those lies was what I had in mind.

> Side note: UDP options should define both PAD1 and PADN to be
> consistent with HBH, Dest, and SR options. Preferably PAD1 would have
> type 0 and PADN would have type 1 which would facilitate reuse of the
> existing parsing loop.

If 8-byte alignment is desired, then PADN saves work. It's not as useful
if 4-byte alignment is all that's wanted; doubtless that's why it was
left out of the IPv4 and TCP option design. I would have no problem with
adopting the more modern IPv6 conventions.

Mike