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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Sun, 6 Feb 2022 16:58:20 +0000

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 <[email-masked]> On Behalf Of Justin Iurman
> Sent: Wednesday, 29 December 2021 15:09
> To: Erik Kline <[email-masked]>
> Cc: Marcus Ihlar <marcus.ihlar=[email-masked]>; IPv6 List
> <[email-masked]>; [email-masked]
> 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 [email-masked] wrote:
> > +6MAN WG, just as an FYI
> >
> > On Fri, Dec 17, 2021 at 7:39 AM Marcus Ihlar
> > <marcus.ihlar=[email-masked]> 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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ippm
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Justin Iurman <[email-masked]>
Date: Mon, 7 Feb 2022 14:07:08 +0100 (CET)

Hi Frank,

LGTM, thanks for this. I think this document is ready to progress.

Justin

On Feb 6, 2022, at 5:58 PM, Frank Brockners (fbrockne) [email-masked] wrote:
> 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
>

---

From: Marcus Ihlar <[email-masked]>
Date: Tue, 15 Feb 2022 16:45:54 +0000

Hi IPPM,

This WGLC is concluded and we see clear support for progressing the document.

Thanks to everyone who has contributed with feedback and to the authors for addressing the feedback in a revision.

Best regards,

Marcus Ihlar

From: Marcus Ihlar
Sent: den 17 december 2021 16:39
To: [email-masked]
Subject: WG Last Call for draft-ietf-ippm-ioam-ipv6-options

Hello IPPM,

This email starts a Working Group Last Call on draft-ietf-ippm-ioam-ipv6-options.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-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