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

From: "C. M. Heard" <[email-masked]>
Date: Tue, 21 Jul 2015 19:07:11 -0700

On Tue, 21 Jul 2015 20:38:49 +1200 Brian E Carpenter wrote:
> On 21/07/2015 19:18, C. M. Heard wrote:
> > > 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.
> >
> > I agree that the behavior in this case should be configurable, but I would
> > be quite comfortable with the default configuration being to drop packets
> > containing options that have become deprecated.
>
> That is a modification to the existing standard for extension headers
> (RFC 7045) which says:
>
>    Forwarding nodes that operate as firewalls MUST conform to the
>    requirements in the previous section in order to respect the IPv6
>    extension header architecture.  In particular, packets containing
>    standard extension headers are only to be discarded as a result of an
>    intentionally configured policy.
>
> An option header is a standard extension header, even if it contains
> a deprecated option. So for compatibility with RFC 7045 the default
> configuration cannot be to drop deprecated options, unless we add an
> "Updates: 7045" and corresponding words in the text.

Good point.  Does that argument apply to the following text as well?

   A node that processes the contents of an extension header MUST
   discard the corresponding packet if it contains any defined options
   that are not meant for the extension header being processed.
...
   A node that processes the contents of an extension header and
   encounters an undefined (unrecognised) IPv6 option MUST react to such
   option according to the highest-order two bits of the option type, as
   specified by Section 4.2 of [RFC2460].

The first paragraph is meant to deal with situations where an option meant
only for a hop-by-hop options header appeares within a destination options
header or vice-versa.  RFC 2460 and RFC 7045 are silent about this.  The
second paragraph says that intermediate nodes that process options should
react as RFC 2460 specifies for end nodes.

Also, it seems to me that the first of the following two paragraphs trumps
the second:

   Experimental IPv6 options SHOULD be treated in the same way as
   standard IPv6 options, including an individually configurable discard
   policy.
...
   A node that processes an IPv6 extension header MAY discard a packet
   containing any experimental IPv6 options.

How about eliminating the second pargraph?

//cmh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jul 2015 01:04:43 -0300

Hi, Mike,

>    that are not meant for the extension header being processed.

I'd say "Not here.. since in this case such combination leads to an
invalid packet".

> react as RFC 2460 specifies for end nodes.

This last paragraph seems fine, too.

> How about eliminating the second pargraph?

This seems to be in line with RFC7045, which says:

   Experimental IPv6 extension headers SHOULD be treated in the same way
   as standard extension headers, including an individually configurable
   discard policy.  However, the default configuration MAY drop
   experimental extension headers.

Although the use of SHOULD and MAY for the same thing amy be confusing...

Thoughts?

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