Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Mar 2015 17:24:37 +0100

Folks,

Since the question as been asked, hereby I'm providing a heads-up about
our finding regarding transit ASes that are filtering IPv6 EH-enabled
packets. -- sme folks my be willing to double-check with the relevant
people, and possibly inquire the reasoning behind the filtering decision.

Here we are just consider "best-case scenarios" (please see
draft-gont-ipv6-ehs-in-real-world for a definition of what we mean by that):

* Folks filtering packets with Dest Options EHs

             AS  2119 (TELENOR-NEXTEL Telenor Norge AS,NO)
             AS   286 (KPN KPN International / KPN Eurorings,NL)
             AS  3356 (LEVEL3 - Level 3 Communications, Inc.,US)

* Folks filtering packets with HBH EHs:
    (0.31%): AS   174 (COGENT-174 - Cogent Communications,US)
    (1.89%): AS   286 (KPN KPN International / KPN Eurorings,NL)
    (1.13%): AS  1273 (CW Cable and Wireless Worldwide plc,GB)
    (14.42%): AS  1299 (TELIANET TeliaSonera International Carrier,SE)
    (0.31%): AS  1764 (NEXTLAYER-AS next layer
Telekommunikationsdienstleistungs- GmbH,AT)
    (0.38%): AS  3257 (TINET-BACKBONE Tinet SpA,DE)
    (81.50%): AS  3356 (LEVEL3 - Level 3 Communications, Inc.,US)
    (0.31%): AS  5588 (GTSCE T-Mobile Czech Republic a.s.,CZ)
    (0.31%): AS  6695 (DECIX-AS DE-CIX Management GmbH,DE)
    (0.94%): AS  8218 (NEO-ASN Neo Telecoms S.A.S.,FR)
    (0.31%): AS  8447 (TELEKOM-AT A1 Telekom Austria AG,AT)
    (0.31%): AS  8767 (MNET-AS M-net Telekommunikations GmbH, Germany,DE)
    (0.31%): AS  9063 (SAARGATE-AS VSE NET GmbH,DE)
    (0.19%): AS 12389 (ROSTELECOM-AS OJSC Rostelecom,RU)
    (0.19%): AS 16086 (DNA DNA Oy,FI)
    (0.63%): AS 20676 (QSC-1 QSC AG,DE)
    (0.19%): AS 29470 (RETNNET-AS CJSC _RetnNet_,RU)
    (0.19%): AS 34984 (TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR)
    (0.31%): AS 36623 (HGTLD - VeriSign Global Registry Services,US)

* Folks filtering Fragments

 AS  6939 (HURRICANE - Hurricane Electric, Inc.,US)
 AS 34779 (T-2-AS T-2, d.o.o.,SI)

FWIW, this post should not be considered a "wall of shame", but, if
anything, a "wall of reality".

Thanks!

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

---

From: "Metzler, Dan J" <[email-masked]>
Date: Tue, 17 Mar 2015 16:48:47 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Tuesday, March 17, 2015 11:25 AM
> To: [email-masked]
> Subject: [v6ops] Non-dest ASes dropping EH-enabledIPv6 packets
> 
> Folks,
> 
> Since the question as been asked, hereby I'm providing a heads-up about our
> finding regarding transit ASes that are filtering IPv6 EH-enabled packets. -- sme
> folks my be willing to double-check with the relevant people, and possibly
> inquire the reasoning behind the filtering decision.
> 
> Here we are just consider "best-case scenarios" (please see draft-gont-ipv6-
> ehs-in-real-world for a definition of what we mean by that):
> 
>  AS  6939 (HURRICANE - Hurricane Electric, Inc.,US)  AS 34779 (T-2-AS T-2,
> d.o.o.,SI)
> 
> 
> FWIW, this post should not be considered a "wall of shame", but, if anything, a
> "wall of reality".

Just an observation:
Nobody will ever do anything to remove themselves from a, "wall of reality".  They might if it is a public "wall of shame".
Personally I think a larger discussion needs to be had about whether it is appropriate to be filtering traffic, (read high level packet inspection) in the "middle" of the internet, or not.  If that is an expectation, then the design needs to accommodate that.

If the expectation is that packet filtering should not be done in the "middle" of the internet, then this is a "wall of shame", and that is the "reality" of it.

It seems like we keep having the same argument over and over, sometimes.

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

---

From: [email-masked]
Date: Tue, 17 Mar 2015 18:31:49 +0100 (CET)

> If the expectation is that packet filtering should not be done in the "middle" of the internet, then this is a "wall of shame", and that is the "reality" of it.

Possibly not appropriate to v6ops - but just to inject some IPv4
perspective into the current discussion, we filter several of the
following types of IPv4 traffic at our borders:

- Ongoing attack IP sources.
- Spoofed traffic sourced from our own IP addresses.
- Source routed packets.
- Tiny fragments (RFC 1858).
- DNS queries to our resolvers.

In addition to the above, there are several other groups of traffic
that we significantly rate limit at our borders.

Filtering is most certainly *not* limited to IPv6 EHs.

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Mar 2015 08:31:02 +1300

>> * Folks filtering packets with Dest Options EHs
...
>> * Folks filtering packets with HBH EHs:
...
>> * Folks filtering Fragments
...
> Personally I think a larger discussion needs to be had about whether it is appropriate to be filtering traffic, (read high level packet inspection) in the "middle" of the internet, or not.  If that…

I think before that point, there's more analysis needed. I thought up
various possible scenarios for the above "filters", times three because
there are three classes of header:

1. I am filtering these packets because I think they are evil.
2. I am filtering these packets because my box does that by default.
3. I am filtering these packets because my box does that by design.
4. I am filtering these packets because they make my box go slow.
5. I am filtering these packets because they break my ECMP.
6. Oh, am I filtering those?
7. What's an extension header?

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Mar 2015 10:14:39 +1100

Yet HE passes fragmented IPv6 to me down their tunnels so I would
suspect a configuration error / bad hardware / bad defaults rather
than a deliberate action to block fragmented traffic.

10:11:16.500396 IP6 2001:470:1f00:820:1cef:4d27:1e8a:d270.57814 > 2001:4f8:0:2::19.domain: 2586+ [1au] ANY? isc.org. (36)
10:11:16.943513 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (0|1232) domain > 57814: 2586*- 27/0/13 RRSIG, SPF, RRSIG, RRSIG, DNSKEY, DNSKEY, RRSIG[|domain]
10:11:16.943865 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (1232|1232)
10:11:16.944107 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:1cef:4d27:1e8a:d270: frag (2464|888)

Mark

In message <[email-masked]>, Brian E Carpenter writes:
> > Nobody will ever do anything to remove themselves from a, "wall of reality"
> .  They might if it is a public "wall of shame".
> > Personally I think a larger discussion needs to be had about whether it is 
> appropriate to be filtering traffic, (read high level packet inspection) in t
> he "middle" of the internet, or not.  If that is an expectation, then the des
> ign needs to accommodate that.
> 
> > If the expectation is that packet filtering should not be done in the "midd
> le" of the internet, then this is a "wall of shame", and that is the "reality
> " of it.
> > 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 17 Mar 2015 23:27:36 +0000

> than a deliberate action to block fragmented traffic.

given HE's high level of clue about ipv6, I would suspect that this is
deliberate and that HE have what they would consider to be sound technical
reasons for dropping ipv6 fragments.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Mar 2015 10:43:18 +1100

> reasons for dropping ipv6 fragments.

The only way to answer this is to ask HE.  Since I don't have any
evidence those that have the evidence should do the asking.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 18 Mar 2015 10:20:31 +0100 (CET)

> packets. -- sme folks my be willing to double-check with the relevant

Again, I want to object to using the term "filtering". "Filtering" for me 
implies intent. They might be dropping EH packets without intending to do 
so, because they are simply unaware that their chosen platform does this. 
Same thing with fragments.

Or do you have indications that this is being done intentionally?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Mar 2015 23:50:36 +0000

> On Mar 17, 2015, at 4:27 PM, Nick Hilliard <[email-masked]> wrote:
> 

I think something got lost in translation there. Mark is saying that he receives fragments from HE, and Nick thinks they are dropping fragments.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 20 Mar 2015 10:25:40 +0000

On 19/03/2015 23:50, Fred Baker (fred) wrote:
> I think something got lost in translation there. Mark is saying that he
> receives fragments from HE, and Nick thinks they are dropping
> fragments.

Fernando made the claim that HE are dropping frags in message-id
[email-masked]

I should have been more careful to enclose what I said in "If HE are
filtering frags, then ..."

The data isn't clear.  I've run a couple of frag tests from devices which
transit through a local HE pop, and there doesn't seem to be a problem.

Fernando, can you provide some data to support your claim?

Nick