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

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

Hi Fernando,
You did mention "implementation-dependent" in security section. But majority of people would bypass security section on the 1st pass of reading your draft.
Except security people, others would look to functionality 1st, them may be security (may be not:-(). Hence, you almost ignore "implementation-dependency" in such a way (putting it into security section).
I propose to introduce additional 5.x, because (IMHO) "implementation-dependency" is the biggest problem in this draft - it is related to money/expenses (especially to replace hardware).
It would be even bigger problem on next years with proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of IPv6 headers extensibility.
People need to check hardware (and software) capability far in advance, or else could be negative surprise. Warn them.
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:38:52 -0300

Hello, Eduard,

On 27/7/20 06:22, Vasilenko Eduard wrote:
> Hi Fernando, You did mention "implementation-dependent" in security
> section. But majority of people would bypass security section on the
> 1st pass of reading your draft. Except security people, others would
> look to functionality 1st, them may be security (may be not:-().
> Hence, you almost ignore "implementation-dependency" in such a way
> (putting it into security section).

Not sure what you mean...

> I propose to introduce additional
> 5.x, because (IMHO) "implementation-dependency" is the biggest
> problem in this draft - it is related to money/expenses (especially
> to replace hardware). It would be even bigger problem on next years
> with proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of
> IPv6 headers extensibility. People need to check hardware (and
> software) capability far in advance, or else could be negative
> surprise. 

What would you expect us to cover in such section, other than what we 
already cover in Section 5.1.1. (Packet Forwarding Engine Constraints)?

Thanks!

Cheers,
-- 
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 10:01:03 +0000

>> What would you expect us to cover in such section, other than what we already cover in Section 5.1.1. (Packet Forwarding Engine Constraints)?
It is better to move this story into separate section before security discussion.
Make this story visible.
It is relevant not just to security.
It is expenses - the biggest restriction in business.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 27 июля 2020 г. 12:39
To: Vasilenko Eduard <[email-masked]>; IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency

Hello, Eduard,

> 5.x, because (IMHO) "implementation-dependency" is the biggest problem 
> in this draft - it is related to money/expenses (especially to replace 
> hardware). It would be even bigger problem on next years with 
> proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of

What would you expect us to cover in such section, other than what we already cover in Section 5.1.1. (Packet Forwarding Engine Constraints)?

Thanks!

Cheers,

---

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

> It is better to move this story into separate section before security discussion.

Point taken. We will try to discuss this stuff much earlier in the draft.

Thanks!

Cheers,
Fernando

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jul 2020 09:03:05 -0700

> It would be even bigger problem on next years with proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of IPv6 headers extensibility.

I really hope by " abuses of IPv6 headers extensibility" you meant "
uses of IPv6 headers extensibility".

> People need to check hardware (and software) capability far in advance, or else could be negative surprise. Warn them.

Within several IETF working groups we have been pointing out all the
issues around these "negative surprises" for several years, like
middebox protocol non-conformance and ossification (see discussions
about extension headers, discussions about IP fragmentation,
discussion about using alternative transport protocols, and wider use
of encryption). Instead of just warning people that things probably
won't work, can vendors fix these problems? For instance, RFC8200
allows intermediate nodes to ignore HBH EH. Has this been implemented
by router vendors in lieu of dropping packets with or relegating them
so some slow path that basically renders them useless?

Tom