Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

FWIW, I support Brian's proposed text.

On Tuesday, November 7, 2017, Brian E Carpenter <brian.e.carpenter@gmail.com>
wrote:

> On 08/11/2017 00:20, Tim Chown wrote:
> > Hi,
> >
> >> On 6 Nov 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com
> <javascript:;>> wrote:
> >>
> >> Hi Fernando,
> >>
> >> On 07/11/2017 07:02, Fernando Gont wrote:
> >>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
> >>>> On 03/11/2017 04:26, C. M. Heard wrote:
> >>>>> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca
> <javascript:;>> wrote:
> >>>>>
> >>>>>>
> >>>>>> C. M. Heard <heard@pobox.com <javascript:;>> wrote:
> >>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:
> >>>>>>>> Yet we skip other extension headers in order to find the ULP.
> >>>>>>
> >>>>>>> Not so. An end node that encounters an unrecognized extension
> header
> >>>>>> is
> >>>>>>
> >>>>>> Both AH and IPIP are well known and recognized extension headers.
> >>>>
> >>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and
> Protocol 41
> >>>> is otherwise known as IPv6. (That's why it's also called
> IPPROTO_IPV6).
> >>>> In RFC8200 terms that makes it an "upper-layer header". Strictly
> speaking,
> >>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer
> header.
> >>>
> >>> Based on the std, anything that is unknown is an EH. In the context of
> >>> RFC8200/FC2460, there's only:
> >>>
> >>> * Known EHs
> >>> * Known ULP
> >>> * Unknown EHs
> >>
> >> Yes, that's what the text says but I wish we'd fixed it in 8200 to
> >> acknowledge that there is a 4th case (Unknown ULP) and that it
> >> cannot be distinguished from the 3rd case. Acknowledging that is
> >> much better than ignoring it. I'm happy with Ole's suggestion that
> >> this (and the resulting ICMP 1 behaviour) should be mentioned in
> >> 6434bis - as a clarification, not a new invention.
> >
> > This seems a reasonable approach to me.  Would you like to propose text,
> Brian?
>
> After this:
>
> 5.1.  Internet Protocol Version 6 - RFC 8200
>
>    The Internet Protocol Version 6 is specified in [RFC8200].  This
>    specification MUST be supported.
>
>    Any unrecognized extension headers or options MUST be processed as
>    described in RFC 8200.
>
> insert something like:
>
>    Note that it is impossible for a node to distinguish between an
>    unrecognized extension header and an unrecognized upper layer
>    protocol. Therefore, a node will behave in the same way for
>    either of these cases, in particular by returning an ICMP
>    Parameter Problem message with code 1 ("unrecognized Next Header
>    type encountered") even for an unrecognized upper layer protocol.
>
> (Protocol 41 is not special in this regard.)
>
>  - Brian
>
> >
> >> I also agree that there are enough potential issues in unexpected
> >> IPv6-in-IPv6 that is deserves its own draft.
> >
> > I’d agree. The same with header insertion for that matter. Focus on the
> issues and how/if they can be mitigated and in which contexts.
> >
> > Tim
> >
> >>
> >> Regards
> >>   Brian
> >>
> >>> with the last one being the default branch :-)
> >>>
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org <javascript:;>
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
>
>

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492