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 ek.ietf@gmail.com wrote:
> +6MAN WG, just as an FYI
> 
> On Fri, Dec 17, 2021 at 7:39 AM Marcus Ihlar
> <marcus.ihlar=40ericsson.com@dmarc.ietf.org> 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-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
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------