Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09

From: "C. M. Heard" <[email-masked]>
Date: Tue, 11 Apr 2017 14:31:30 -0700

On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote:
> Major issues:
>
> - Section 4.8. "Defining New Extension Headers and Options":
>
> It says new hop-by-hop headers must never ever defined. This is problematic,
> as this closing the door forever, even if future instances of the IETF do
> would like to wish to define new hop-by-hop headers. A better way would have
> to say "that new hop-by-hop headers must have IETF consensus".

If a new extension header with hop-by-hop behavior were defined,
it would require a router or other forwarding device to look
beyond the header immediately following the base IPv6 header,
possibly even arbitrarily deep into an IPv6 header chain. That's
not backward compatible with the existing specification, which was
written the way it was to limit the amount of header processing
required in the forwarding path.

Can you provide an example of anything that can be done with a
new hop-by-hop extension header that cannot also be done with
a new hop-by-hop option?

> - Section 4.8. "Defining New Extension Headers and Options":
>
> Also the „not recommended“ to define new extension headers looks strange,
> especially with the phrase "There has to be a very clear justification". The
> term "clear justification" is not an exact engineering specification. Why
> not using "technical protocol specification and real word use case required,
> plus IETF consensus"?

We could perhaps make this clearer by stating that a new extension
header must not be defined unless it can be proven that the desired
functionality cannot reasonably be provided either by a new
destination option or by a new upper layer protocol, but I'm not
convinced that it's that much of an improvement - there's that
pesky word "reasonably," which still implies an exercise of
engineering judgment, which you seem to want to avoid.

For a necessarily imprecise analysis of which of the existing
extension headers meet the "cannot reasonably be provided"
criterion, please see

https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html

Mike Heard

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Apr 2017 18:41:58 +0200

Hi Mike,

> Am 11.04.2017 um 23:31 schrieb C. M. Heard <[email-masked]>:
> 

Given the current hop-by-hop header is partially not usable, everything…

I thinking would be to basically replace/deprecate the old one and define a new one.

> https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html

I have to say I find this phrasing also to be useful. I guess the real point is to recommend to rather use a destination option if possible than defining a new extension header.

Mirja

> 
> Mike Heard
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art