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

[Justin Iurman <[e-mail]>]

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) [e-mail] 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
> 
>> -----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