Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 27 Jul 2020 09:30:21 +0000

Hi Fernando,
The more messages I have sent to you - the less confident I am in the next one comment, but anyway.
1. All these new staff would need more OAM tools. May be such simple as "ping for SRv6", may be much more complicated (is anything exist to ping BIER data plane?). Network Admin (or Planning department) should research what is available for the tools that they have decided to activate.
2. Some EH are not practical without proper OSS tools (example: iFit)
IMHO: it could be one additional section X (numbering in the root).
It is probably very relevant, because draft has "v6ops" in the middle of the name.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 26 июля 2020 г. 8:46
To: IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)

Folks,

We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers".

The I-D is available at: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt

Your feedback will be appreciated.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Date: Sat, 25 Jul 2020 22:28:50 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Gert Doering <[email-masked]>, Geoff Huston <[email-masked]>, Warren Kumari <[email-masked]>, Nick Hilliard <[email-masked]>

A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
has been successfully submitted by Fernando Gont and posted to the IETF repository.

Name:		draft-gont-v6ops-ipv6-ehs-packet-drops
Revision:	04
Title:		Operational Implications of IPv6 Packets with Extension Headers
Document date:	2020-07-25
Group:		Individual Submission
Pages:		15
URL: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
Htmlized: 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04

Abstract:
    This document summarizes the security and operational implications of
    IPv6 extension headers, and attempts to analyze reasons why packets
    with IPv6 extension headers may be dropped in the public Internet.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jul 2020 06:46:09 -0300

Eduard,

> The more messages I have sent to you - the less confident I am in the next one comment, but anyway.

?

> It is probably very relevant, because draft has "v6ops" in the middle of the name.

I'm not sure what's the point you are raising.

Essentially, operators employ devices that need to access L-4 
information for doing a bunch of things (EMCP, enforcing ACLs, etc.). 
The structure of IPv6 packets makes accessing such information 
challenging. In some cases, devices are unable to access such 
information. In other cases, they might be able to do so provided the 
packet goes through the slow-path (all this depending, to some extent, 
on the EH-chain length). Ultimately, in many of these cases (if not 
all), operators have no other option than to drop the offending packets.

This is a general issue of IPv6 EHs.

Yes, depending on the tools you might need support for this or that. BUt 
how does that change the discussion we're having in the document?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 27 Jul 2020 09:56:11 +0000

Hi Fernando,
May be me misunderstood the point of the draft in 1st place.
I do see it as a warning list for potential issues that admin should research a little deeper before he/she would enable some EHs.
IMHO: You could be very brief about solutions (because draft could bloat to the size on Internet), but the list of all issues to check should be more or less full.
Or it would be small value from the draft. IMHO.
Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 27 июля 2020 г. 12:46
To: Vasilenko Eduard <[email-masked]>; IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - OAM

Eduard,

?

Essentially, operators employ devices that need to access L-4 information for doing a bunch of things (EMCP, enforcing ACLs, etc.). 
The structure of IPv6 packets makes accessing such information challenging. In some cases, devices are unable to access such information. In other cases, they might be able to do so provided the packet goes through the slow-path (all this depending, to some extent, on the EH-chain length). Ultimately, in many of these cases (if not all), operators have no other option than to drop the offending packets.

Yes, depending on the tools you might need support for this or that. BUt how does that change the discussion we're having in the document?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jul 2020 07:17:23 -0300

> I do see it as a warning list for potential issues that admin should research a little deeper before he/she would enable some EHs.

Nope.

What this document tries to do is to shed some light into why packets 
with EHs are largely dropped in the public Internet.

And essentially it notes that in many cases operators don't have many 
other options.

RFC7872 (as well as other studies referenced in our draft) have provided 
data about the extent to which packets with EHs are dropped in the 
public Internet.

And this document elaborates on the operational reality that many 
operators have not much of a choce than resorting to dropping them.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 27 Jul 2020 11:03:44 +0000

Hi Fernando,
Then may be OAM is out of the scope (for this draft).
It is definitely not the reason for a drop itself,
But It may be needed to investigate drop reason.
If "drop reason" is not needed to be investigated ...
Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 27 июля 2020 г. 13:17
To: Vasilenko Eduard <[email-masked]>; IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - OAM

Nope.

What this document tries to do is to shed some light into why packets with EHs are largely dropped in the public Internet.

And essentially it notes that in many cases operators don't have many other options.

RFC7872 (as well as other studies referenced in our draft) have provided data about the extent to which packets with EHs are dropped in the public Internet.

And this document elaborates on the operational reality that many operators have not much of a choce than resorting to dropping them.

Thanks,