Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Admin Policy

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 1 Aug 2020 17:02:40 +0000

I know from discussion with some carriers that some of them filter out EHs intentionally
To avoid any problems discussed in this draft.
It is definitely the reason for EHs drops, but non-technical. It is probably "Absence of use case".
May be it is the primary reason (in %).
Should it be included into the list? Or we should be silent about non-technical things.
IMHO: it would not be resolved up to the business case would be found.
Additional risk and additional processing capacity should have the reward. It is just business.
Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 31 июля 2020 г. 22:32
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Operational Implications of IPv6 Packets with Extension Headers
        Authors         : Fernando Gont
                          Nick Hilliard
                          Gert Doering
                          Warren Kumari
                          Geoff Huston
                          Will (Shucheng) Liu
	Filename        : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt
	Pages           : 16
	Date            : 2020-07-31

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 07:16:31 -0300

Hello, Eduard,

> It is definitely the reason for EHs drops, but non-technical. It is probably "Absence of use case".

Ultimately, there are technical reasons behind such drops: i.e., any of 
the subsections from Section 6.

Most likely, if EHs were innocuous, even if there wasn't a use case, 
folks could let them through.

While it is true that there are not many use cases for EHs, there are at 
least to important ones: fragmentation and IPsec's ESP. And these two 
get dropped, too.

> Additional risk and additional processing capacity should have the reward. It is just business.

Indeed.

As noted, even for cases where there's a use case (e.g. IPsec ESP), or 
fragmentation (see the numbers for fragment drops for the case of DNS 
servers), packets with EHs are still dropped.

(me thinking out loud, and asking for more thoughts, if you wish)

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Aug 2020 21:35:50 +1000

On Mon, 3 Aug 2020, 20:26 Fernando Gont, <[email-masked]> wrote:

> least to important ones: fragmentation

I expect many network operators drop fragments because they were taught to
do ACLs/packet filters similar to the following:

permit tcp any any eq http
permit udp any any eq dns
deny ip any any

I was back in the day.

The focus is limited to "this is specifically what you need to do to make
what you want to do to make it work" rather than also, "here are the other
issues with what you're doing that you might need to consider".

The fact that the above does what was exactly what was expected e.g. allows
web access, gives an impression that it is 100% correct, and therefore
reinforces that there isn't anything else to consider.

It's only if you either go deeper into how the protocols work e.g. PMTUD,
or break something and have to work out how to fix it, do you learn and
realise issues with examples like above.

It's quite a while since I've looked at any, from what I remember,
practical network operation books and manuals are the same.

Network firewall admins can be a bit worse in the sense that they can be
more paranoid about blocking things they don't understand enough or don't
trust e.g. blocking all of ICMP by default.

I don't think it is as commonly  calculated as people here might think.
It's more "teach just enough to make it work".

and IPsec's ESP. And these two
> get dropped, too.

See above. Unless why ESP and AH should be allowed is taught, it's deny by
default.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 09:25:43 -0300

Hello, Mark,

On 3/8/20 08:35, Mark Smith wrote:
[...]>
> 
> I expect many network operators drop fragments because they were taught 
> to do ACLs/packet filters similar to the following:
> 

You'll not get away with that in IPv6, since it would break ND.

That said, the above (modulo ICMPv6 and fragmentation) might seem 
reasonable on the edge (e.g. enterprise network), but not so much elsewhere.

(From RFC7872, you'll see that not all EHs share the same drop rate. IN 
fact, the drop rates are proportional to the EH len...)

[...]
> more paranoid about blocking things they don't understand enough or 
> don't trust e.g. blocking all of ICMP by default.

When doing sysadmin, I've myself started from a default deny, and 
subsequently allowed things to make stuff work.

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, 3 Aug 2020 13:03:38 +0000

Hi all,
I do not believe that EH would ever be "for free" - it would consume PFE cycles (performance, energy).
Therefore, every EH should have their own separate justification to be turned on.
If we see big drop - it means that justification has not been found yet for particular EH.
If the current situation "for no one"?

IMHO: "EH success" is the situation when small set of EHs would have low drop rate.
IPv6 Architecture should be friendly for this to happen.
Other EHs should not block "chosen" EHs.

Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 3 августа 2020 г. 13:17
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Admin Policy

Hello, Eduard,

On 1/8/20 14:02, Vasilenko Eduard wrote:
> I know from discussion with some carriers that some of them filter out 
> EHs intentionally To avoid any problems discussed in this draft.

Ultimately, there are technical reasons behind such drops: i.e., any of the subsections from Section 6.

Most likely, if EHs were innocuous, even if there wasn't a use case, folks could let them through.

While it is true that there are not many use cases for EHs, there are at least to important ones: fragmentation and IPsec's ESP. And these two get dropped, too.

Indeed.

As noted, even for cases where there's a use case (e.g. IPsec ESP), or fragmentation (see the numbers for fragment drops for the case of DNS servers), packets with EHs are still dropped.

Thanks,
--
Fernando Gont
e-mail: [email-masked] || [email-masked] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 10:35:20 -0300

Hello, Eduard,

> I do not believe that EH would ever be "for free" - it would consume PFE cycles (performance, energy).

In principle, I agree.

The Internet architecture assumes that intermediate systems only need to 
look into the destination address of a packet to make a forwarding 
decision. In such (theoretical) architecture, EHs would be "for free" -- 
or, at the very lest, free for the network (and only possibly expensive 
for the endpoints).

However, the reality is that intermediate systems quite often do need to 
look at layer-4 values to make a forwarding decision. Therein lies the 
problem -- EHs are not "free" anymore.

> IPv6 Architecture should be friendly for this to happen.

The variable-length daisy-chain-like structure of IPv6 packets is, by 
definition, not friendly to intermediate systems that need to find 
layer-4 information.

That's why -- besides possible filtering policies -- EHs are dropped.

Thanks,