Subject: Comments on draft-gont-6man-ipv6-opt-transmit-01

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2015 16:08:53 +0200

Hi,

A few comments:
1) Section 3 of your draft states:
"[RFC2460] requires destination
   hosts to discard the corresponding packet if the option is unrecognised."

AFAIK RFC2460 requires the action that must be taken if a particular
options is not recognized depends on the Option Type (so, if the
Option Type is set to '00', the node skips over this option and
continue processing the header).

2) The same Section 3 says:
"A node that processes the contents of an IPv6 extension header SHOULD
   discard the corresponding packet if it contains any options that have
   become deprecated."

I'd say it might break connectivity. Let's say tomorrow we deprecate
an option X and suddenly intermediate routers start blocking my
traffic because they are already aware of the option being deprecated
while my hosts and servers have not been updated yet....I'd suggest
smth about a configurable policy and replace SHOULD with MAY.

And, finally...What your draft does is it provides very nice
summary/digest of other RFCs in regards to EH options. So the same
information may be obtained of spending a lot of time digging through
many RFCs which defines options and applying some common sense...I
agree that it is very good idea to have a clear guidance on how to
validate options. My concern is that next time an option is
introduced/updated/deprecated your draft immediately becomes
inaccurate. Therefore I do love the idea of a registry summarizing the
options status and headers they are allowed in. And I love the idea of
having such a table being dynamically updated.
So, my question is: can we just go ahead with updating
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
and say in your draft 'if an option appears in the wrong header, it is
recommended to discard such a packet'?
Or...maybe...can we just get
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
and let implementers to decide how to deal with unexpected
header/option combinations?

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jul 2015 00:33:09 -0300

Hi, Jen,

Thanks so much for your review! -- Please find my comments in-line...

> continue processing the header).

The text actually says :

"  In the case of some options meant to be included in IPv6 extension
   headers other than Hop-by-Hop Options, [RFC2460] requires.."

> smth about a configurable policy and replace SHOULD with MAY.

I'm personally fine with that.

> many RFCs which defines options and applying some common sense...

Not really: existing documents do not consider the case of forwarding
devices or middleboxes processing options in e.g. DO header. -- this I-D
is essentially RFC7045 for IPv6 options (which were cnsidered out of
scope for RFC7045).

Besides, "applying common sense" is not really applicable.  Folks that
implement protocols need not be protocol specialists, and usually
aren't. It's we that should be crystal clear, and provide the
corresponding advice.

> I
> inaccurate. 

I guess that, in such case, the newly-specified option RFC could contain
an "Updates" pointing to out document.

> Therefore I do love the idea of a registry summarizing the

The corresponding table could be moved to the "IANA Considerations"
section...

> recommended to discard such a packet'?

(thinking out loud) Yes.

> header/option combinations?

Please no. This causes (unnecessary) non-deterministic behavior (in the
best case) , or to interoperability problems (in the worst case) when
implementers are required to make decisions for stuff that they may not
know in detail.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 10:13:34 +0200

[Moving this thread to the 6MAN mailing list. [email-masked]]

cheers,
Ole

> On 22 Jul 2015, at 5:33 , Fernando Gont <[email-masked]> wrote:
> 
> Hi, Jen,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jen Linkova <[email-masked]>
Date: Wed, 22 Jul 2015 12:14:48 +0200

> an "Updates" pointing to out document.

If, as you said above, the goal is to provide a clear advice to people
who are not protocols specialists, I believe that keeping all
information in one place serves our purpose much better than
sending them down a long chain of cross-references of RFCs..

>> recommended to discard such a packet'?

great ;) It would make the document:
- shorter
- always up-to-date (as the only thing we need to ensure is that any
new options are properly and in time added to the IANA registry)

To clarify the details I propose:
- update http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
- add the text saying that 'any new options are to be added to the registry'
- allow packets with the invalid combinations of options being dropped;
- if an unrecognized (incl. deprecated) option is encountered, a
router must behave as RFC7045 and 2460 say.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jul 2015 09:38:46 -0300

Hi, Jen,

> - add the text saying that 'any new options are to be added to the registry'

Will do.

> - allow packets with the invalid combinations of options being dropped;

Do you mean MAY drop SHOULD drop, or MUST drop? -- I'd say "MUST drop"
since this is clearly a violation of the spec. Thoughts?

> router must behave as RFC7045 and 2460 say.

Will do.

Thanks!

Best regards,