Re: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Justin,

Sorry for the late response. I've just posted a revision (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/07/) which includes the two suggested changes below.

Cheers, Frank

> -----Original Message-----
> From: ippm <[e-mail]> On Behalf Of Justin Iurman
> Sent: Wednesday, 29 December 2021 15:09
> To: Erik Kline <[e-mail]>
> Cc: Marcus Ihlar <marcus.ihlar=[e-mail]>; IPv6 List
> <[e-mail]>; [e-mail]
> Subject: Re: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options
> 
> Hi ippm, 6man,
> 
> I do believe this document is almost ready, though it probably needs a new
> version to address the following review comments.
> 
> 1) In section 4 ("In-situ OAM Metadata Transport in IPv6"), third paragraph, it
> says:
> 
>   "In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly
>    enabled per interface on every node within the IOAM domain.  Unless a
>    particular interface is explicitly enabled (i.e., explicitly
>    configured) for IOAM, a router MUST drop packets that contain
>    extension headers carrying IOAM data-fields.  This is the default
>    behavior and is independent of whether the Hop-by-Hop options or
>    Destination options are used to encode the IOAM data.  This ensures
>    that IOAM data does not unintentionally get forwarded outside the
>    IOAM domain."
> 
> I don't think "a router MUST drop packets" is correct. IOAM options are defined
> with type "00", i.e., skip over this option and continue processing the header.
> Instead, I would rather have something like "a router MUST ignore IOAM
> options". Indeed, you don't want a node to drop packets with IOAM options,
> when not configured, to keep consistency with the behavior of type "00". This is
> the role of a firewall to drop packets if it detects IOAM injections or IOAM leaks.
> 
> New text suggestion:
> 
>   "In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly
>    enabled per interface on every node within the IOAM domain.  Unless a
>    particular interface is explicitly enabled (i.e., explicitly
>    configured) for IOAM, a router MUST ignore IOAM Options.  As
>    additional security, IOAM domains SHOULD provide a mechanism to
>    prevent injections at ingress or leaks at egress."
> 
> Note that the last sentence could be omitted, as consideration #4 (see section
> 5.1) already talks about it.
> 
> 2) Section 5.4.1 ("IPv6-in-IPv6 encapsulation") describes a hacky way to
> encapsulate packets. Instead of using the egress as the outer destination
> address, it uses the same destination address as the inner one. I understand the
> pros of such a technique (i.e., same forwarding path), but it goes against
> RFC2473 and, as a consequence, also against RFC8200. So, I don't think it should
> be part of a standard. Since the "normal" IPv6-in-IPv6 use case is implicitly
> included in the next section (5.4.2, "IP-in-IPv6 encapsulation with ULA"), I think
> section
> 5.4.1 could/should be dropped.
> 
> Thanks,
> Justin
> 
> On Dec 17, 2021, at 10:37 PM, Erik Kline [e-mail] wrote:
> > +6MAN WG, just as an FYI
> >
> > On Fri, Dec 17, 2021 at 7:39 AM Marcus Ihlar
> > <marcus.ihlar=[e-mail]> wrote:
> >>
> >> Hello IPPM,
> >>
> >> This email starts a Working Group Last Call on
> >> draft-ietf-ippm-ioam-ipv6-options.
> >>
> >>
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-optio
> >> ns-06
> >>
> >>
> >>
> >> Please provide feedback by replying to this email with your reviews
> >> and if you think this document is ready to progress, by Friday, January 14.
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Marcus & Tommy
> >>
> >> _______________________________________________
> >> ippm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ippm
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm