Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00

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

Tom,


> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Dienstag, 19. November 2019 12:24
> To: Frank Brockners (fbrockne) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> 
> On Mon, Nov 18, 2019 at 7:47 PM Frank Brockners (fbrockne)
> <[e-mail]> wrote:
> >
> > Hi Xiao,
> >
> >
> >
> > thanks for following up. Apparently the behavior described in
> > draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we speculated in
> > the IPPM WG meeting yesterday, but the desired behavior that we
> > arrived at after WG discussions in 6man and with several IPv6 experts.
> > See
> > https://github.com/inband-
> oam/ietf/commit/48175cf89de6369a4d01017ec80c
> > 07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't forward an
> > IOAM packet unless configured to do so.”)
> >
> > This behavior for IPv6 is to ensure that packets with IOAM do not accidentally
> leak from a domain that employs IPv6.
> >
> > This also means for IPv6, things are more constrained than what is stated in
> the more generic draft-ietf-ippm-ioam-data-08.
> >
> Frank,
> 
> Per the draft-ietf-ippm-ioam-ipv6-options-00 the act bits are 00 which means
> "skip over this option and continue processing the header". So if a router doesn't
> support IOAM, I believe other act bits like maybe
> 01 would be necessary to enforce the rule of “Don't forward an IOAM packet
> unless configured to do so.” Of course, nodes may also ignore HBH options
> completely per RFC8200 which means even such packets might be forwarded
> out of the domain anyway. 

...  the current text is a for a more specific case, i.e. you have a router that *does* understand IOAM and receives a packet with IOAM on an interface that is not configured for IOAM. 
The conclusion from earlier discussions was to drop the packet - per the current text. This leaves default processing of unknown option types untouched - i.e. processing would happen per RFC 8200.

Frank


So trying to guarantee packets won't be forwarded
> out of the domain at all edge routers may be a futile effort. An alternative would
> be that the source SHOULD only use IOAM when it knows the destination is in
> the domain, and a firewall MAY be applied at the domain edge to drop packets
> with IOAM.
> 
> Tom
> 
> >
> >
> > Cheers, Frank
> >
> >
> >
> >
> >
> >
> >
> > From: ippm <[e-mail]> On Behalf Of [e-mail]
> > Sent: Montag, 18. November 2019 13:18
> > To: [e-mail]
> > Subject: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
> >
> >
> >
> > Hi Frank,
> >
> >
> >
> > Repeat what I said on the mic this morning as below.
> >
> >
> >
> > In section 3 of draft-ietf-ippm-ioam-ipv6-options-00 it says:
> >
> > "Unless a particular interface is explicitly enabled (i.e. explicitly   configured)
> for IOAM, a router MUST drop packets which contain extension headers carrying
> IOAM data-fields."
> >
> > But in section 4.4 of draft-ietf-ippm-ioam-data-08 it says:
> >
> > "If not all nodes within a domain are IOAM capable, IOAM tracing information
> (i.e., node data, see below) will only be collected on those nodes which are
> IOAM capable.  Nodes which are not IOAM capable will forward the packet
> without any changes to the IOAM-Data-Fields."
> >
> > It seems they're not in alignment.
> >
> >
> >
> > Best Regards,
> >
> > Xiao Min
> >
> > _______________________________________________
> > ippm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ippm