Subject: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 15:01:48 -0800

Folks,

I did a presentation on the topic at the IEPG meeting earlier this week.
It provides some concrete data regarding IPv6 fragmentation and
Extension Header filtering on the Internet.

The slideware is available at:
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>

Certainly there's *much* more work to be done in this area, but I
thought that this could be good food sfor some of the discussions that
we were having on the topic.

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Nov 2013 23:27:12 +0000

Hi,

Also as per the IEPG discussion, the results I had in conjunction with a summer MSc project student can be summarised as follows. 

The headline is that he saw a 37.7% failure rate for the Fragmentation Header (alone), a bit better than Fernando’s results, but still not good.

He tested the top 1,000 IPv6-enabled Alexa sites.
He used the scapy toolkit which supports the four main extension header types (routing, fragmentation, destination and hop-by-hop)
He tested
a) valid combinations of those 4 extension headers as per RFC 2460
b) other non-valid combinations
c) duplicated extension headers
d) fragmentation header
Primarily TCP tests, doing HTTP GET requests.

For single extension headers, acceptance was
Routing header 63.9%
Frag header 62.3%
Hop by hop header 60%
Destination option header 15.8% 
When using no extension headers, success rate was 100%
When using multiple headers, the rates fall markedly, not dissimilar with Fernando’s numbers for longer headers.

About 120 sites accept all four types of extension headers. 

A small number of sites accepted illegal combinations/ordering of extension headers.

A more detailed set of results is being pushed to a conference paper.

I now have another student taking this further, and validating the above results, so feel free to contact me off-list if you’re interested.

Tim

On 4 Nov 2013, at 23:01, Fernando Gont <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 00:32:00 +0100 (CET)

> we were having on the topic.

"Operators are known to filter IPv6 fragments". This kind of writing 
implies intent, right? Most of the "filtering" I would say is due to 
default device behavior, where no intent exists on the operator. So I'd 
rather see this changes to "IPv6 fragment header packets are having a 
severely degraded network experience" or something like that.

Otherwise, great work. I would like to see traceroute or alike done with 
these kinds of packets headers also, to see where packets are dropped.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 16:00:53 -0800

> "Operators are known to filter IPv6 fragments". This kind of writing

Isn't there a v6ops I-D with similar wording?

> implies intent, right? 

mm... as far as discussion on a number of forums went, apparently
there's intent to do so.

> Most of the "filtering" I would say is due to
> default device behavior, where no intent exists on the operator.

Data? References?

> So I'd

Well, the preso is out there, already. :-(

> these kinds of packets headers also, to see where packets are dropped.

Yep. This is in my TODO list. Hopefully we will cooperate with Tim
(Chown) et al to take these measurements further.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 01:08:18 +0100 (CET)

> Isn't there a v6ops I-D with similar wording?

I opposed to this wording in there as well.

If one deploys a 6500/7600/SUP720 and configures IPv6 on it today, it'll 
slow-path every IPv6 packet with a fragmentation header. Default 
behaviour.

I have no idea how much of the behaviour your're seeing is caused by this 
default behaviour, but I'd venture to guess a lot.

> mm... as far as discussion on a number of forums went, apparently 

Oki, I haven't seen these.

> Data? References?

http://seclists.org/nanog/2011/Sep/1076

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Nov 2013 11:12:43 +1100

> mm... as far as discussion on a number of forums went, apparently

There is also often no intent.  The defaults drop fragmented packets
any you have to explicitly pass them.

> > default device behavior, where no intent exists on the operator.

*BSD firewall drop by default.  For all flavours of firewall supported.
e.g. ipfw, ipf.
 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Nov 2013 16:20:22 -0800

> *BSD firewall drop by default.  For all flavours of firewall supported.

pf reassembles IPv6 fragments by default.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Nov 2013 00:31:50 +0000

Hi, if the network is dropping fragments we are just going to have
to fix it. Tunnels are an example of a packetization layer that
requires fragmentation.

Thanks - Fred
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Nov 2013 16:41:56 -0800

+1

The same measurement with IPv6 used to say "IPv6 packets won't get 
through most of the time".

If you see a bug, fix and/or report it ;-)

Joe

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 02:25:28 +0100

> to fix it. Tunnels are an example of a packetization layer that

does the above results show the _network_ dropping fragments, or the end host or a system closely associated with the end host dropping extension headers?

cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Nov 2013 01:31:00 +0000

> does the above results show the _network_ dropping fragments, or the end host or a system closely associated with the end host dropping extension headers?

For mine, the test was simply whether the HTTP request solicited a response.

I’ll check on the ICMPv6.

Tim

---

From: Jen Linkova <[email-masked]>
Date: Tue, 5 Nov 2013 03:11:54 +0100

> For mine, the test was simply whether the HTTP request solicited a response.

It could be verified by checking the hop limit from the your machine
to the server you are testing and then vary the hop limits of probe
packets - so you can see when you stop receiving 'time exceeded'.

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 17:47:32 -0800

On 11/04/2013 04:31 PM, Templin, Fred L wrote:
> to fix it. 

I guess we didn't have a good success rate with ICMP{v4,v6} filtering
for PMTUD to be reliable?

Not that I like it, but... it's not that easy to fix something that is
not under your control.

That said, I have a few ideas to provide some help in that direction.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 17:45:53 -0800

Hi, Ole,

On 11/04/2013 05:25 PM, Ole Troan wrote:
>> Hi, if the network is dropping fragments we are just going to
>> have to fix it. Tunnels are an example of a packetization layer
>> that requires fragmentation.
> 
> does the above results show the _network_ dropping fragments, or
> the end host or a system closely associated with the end host
> dropping extension headers?

So far, I have not measured that, but will do.

In any case, the interesting (and unfortunate) data if the chances of
success when you use extension headers or fragmentation are in the
scale of "unlikely". :-(

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 03:20:54 +0100 (CET)

> for PMTUD to be reliable?

I have to oppose to this one as well. Filtering means intent (right?). 
Lots of PMTUD problems are not intentional, they are caused by other 
reasons, like L2 MTU mismatch on links so packets are dropped silently 
without the operator noticing. Some are also caused by misconfigured load 
balancers etc (the ICMP message is lost due to bad implementation, not due 
to active decision to filter).

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Nov 2013 02:21:25 +0000

On 5 Nov 2013, at 02:11, Jen Linkova <[email-masked]> wrote:

> packets - so you can see when you stop receiving 'time exceeded’.

Modifying traceroute itself to slip in some extension headers might be useful?  Much as you can check DSCP rewrites, for example.

Tim

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 03:23:01 +0100

Fernando,

> success when you use extension headers or fragmentation are in the

I'm not sure you can draw that conclusion without knowing where the fragments are dropped.

e.g. you are not saying that fragmented packets will be dropped anywhere on the link between your home and mine, are you?
I'm for example not concerned about a web server or load balancer that sets TCP MSS to 1220 and then drop fragments.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Nov 2013 02:24:30 +0000

Hi Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 5:48 PM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [v6ops] Some stats on IPv6 fragments and EH filtering on the Internet
> 

Unfortunately, that seems to be the case.

> That said, I have a few ideas to provide some help in that direction.

Any ideas would be helpful!

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 18:45:29 -0800

Hi, Pedro,

On 11/04/2013 05:53 PM, Pedro Torres wrote:
> Tim/Fernando,
> 
> Wow! I'm scared of these results!
> (If that was the intention, it worked!)

The intention certainly wasn't to scare anyone -- for instance, I didn't
expect these results ot be that bad.

The goal of this measurements was to get some data regarding on where
we're standing with respect to IPv6 fragmentation and extension headers.

This is just data that is useful and should keep in mind when developing
protocols and/or extensions.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Nov 2013 02:50:41 +0000

> we're standing with respect to IPv6 fragmentation and extension headers.

And to encourage further measurements, which I think Fernando will do via his scripts (which I think are part of his wider set of IPv6 tools) and which a student here will do via use of and/or extending scapy.

We can then get some idea of where the problems exist, and whether, for example, there are ICMPv6 messages returned or the packets are simply being dropped.

> protocols and/or extensions.

Indeed, or when writing docs like the one Ron is authoring on extension header handling.

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Nov 2013 02:57:34 +0000

Hi Tim and Fernando,

> > protocols and/or extensions.

We already have at least one protocol that requires IPv6 fragmentation
(RFC2473) and I'm sure there are others.

> Indeed, or when writing docs like the one Ron is authoring on extension header handling.

Or SEAL also. But, SEAL simply takes the existing precedent set by RFC2473.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 19:00:04 -0800

On 11/04/2013 06:23 PM, Ole Troan wrote:
>> 
>> In any case, the interesting (and unfortunate) data if the
>> chances of success when you use extension headers or
>> fragmentation are in the scale of "unlikely". :-(
> 
> e.g. you are not saying that fragmented packets will be dropped 
> anywhere on the link between your home and mine, are you?

I'm certainly not. All tests were against web servers.

> I'm for example not concerned about a web server or load balancer 
> that sets TCP MSS to 1220 and then drop fragments.

Certainly, there's much more testing to be done (this is even stated in
the slideware :-) ). That said, you might still be concerned about the
case you meantion -- at least in theory, that case might arise in a
NAT64 (?) case.

Also, one of the main points of this slideware is that its not just
fragments that are dropped, but extension headers in general.

In any case, my goal of sharing the results is to trigger discussion
and encourage further testing, rather than coming up with scary or
bold statements.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 18:49:08 -0800

> Modifying traceroute itself to slip in some extension headers might be useful?  Much as you can check DSCP rewrites, for example.

FWIW, I'm in the process of updating the toolkit to support this sort of
thing.. Should have something along these lines shortly.

Thanks,

---

From: Jen Linkova <[email-masked]>
Date: Tue, 5 Nov 2013 04:23:02 +0100

-v6ops@ to minimize the noise

> thing.. Should have something along these lines shortly.

It would be interesting to do such measurements using Atlas but AFAIR
it does not have an option to send packets with extension headers..
Just curious - have you contacted RIPE Atlas guys? I could ask them if
you think it makes sense.

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Nov 2013 03:38:26 +0000

> you think it makes sense.

While I love the idea of the Atlas project, and have a probe myself, I tried asking them whether I could do just basic HTTP monitoring with my probe, and that wasn’t possible, so I’m not optimistic that a general probe user could just add such tests. 

I suspect it would need some significant code updates from the developers. But measuring probe to probe would certainly be useful, so it would be nice to see at some point… some of the Atlas people are here, so we might get some idea of a timeline if it is possible… :)

Tim

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 10:59:51 +0100

Fernando,

> and encourage further testing, rather than coming up with scary or

splendid.

it would be very interesting to know where filtering is done.
my assumption is that it isn't done in what I call the Internet infrastructure,
but close to the hosts (edge), or in the hosts themselves.

pretty tricky to measure that from afar though.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Nov 2013 11:50:21 +0100

Hi,

> pf reassembles IPv6 fragments by default.

Not on FreeBSD, as far as I'm aware.  They have not yet imported these
bits from OpenBSD :-(  (and the state of pf(4) in FreeBSD 9.x isn't so
good anyway, with rdr being broken for IPv6, too...)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Vesna Manojlovic <[email-masked]>
Date: Tue, 05 Nov 2013 11:53:43 +0100

Hi Tim, all,

On 05-nov.-13 04:38, Tim Chown wrote:
> While I love the idea of the Atlas project, and have a probe myself,
>  I tried asking them whether I could do just basic HTTP monitoring
> with  my probe,
> and that wasn’t possible, so I’m not optimistic that a general probe
>  user could just add such tests.

Currently, indeed, we do not support HTTP measurements for regular users 
-- while it is technically possible, and some researchers have done 
measurements project with very controlled parameters -- the policy of 
"allowed" targets is still under discussion.

> I suspect it would need some significant code updates from the
> developers. But measuring probe to probe would certainly be useful,

While not all the probes might be good targets, we have introduced
RIPE Atlas anchors specifically with this in mind -- willing targets, 
that also can take more measurements with regards to bandwidth.

Please see the list of features here:
https://atlas.ripe.net/about/anchors/
& here:
https://atlas.ripe.net/doc/anchors

> so it would be  nice to see at some point… some of the Atlas people
 > are here, so we might get some idea of a timeline if it is possible… > :)

We have few of the requests related to IPv6 & HTTP already on the 
roadmap, and we are waiting for more community input to help us 
prioritize them.
http://roadmap.ripe.net/ripe-atlas/

 From this discussion, I have noted
  +1 for HTTP measurements
  +1 for IPv6 extension headers
  "probe to probe" measurements

Please send your detailed suggestions to "MAT-WG" mailing list --
Measurements, Analysis & Tools:
http://www.ripe.net/mailman/listinfo/mat-wg/

Thank you,
Vesna

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Nov 2013 12:36:09 +0000

> pretty tricky to measure that from afar though.

as Mike Abrahamsson said, if you have cisco sup720 (or anything with a
PFC3) in the path, then you have serious problems with frags.  As an
operator you need to make a decision between dropping all frags in hardware
(chassis-wide), passing all frags in hardware (chassis-wide, noting that
this removes control plane protection for v6 frags), or slow-pathing the
frags via the RP (thereby opening up the RP to being trashed).  From an
operational point of view there is really only one option.

You could say that this is an operator problem and they get what they
deserve for running equipment of this era, but realistically these devices
will be running on the internet until the heat death of the universe.

Nick

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 13:47:08 +0100

Nick,

> will be running on the internet until the heat death of the universe.

yes, I should have included something about "barring software bugs".
if you use one of these in the Internet core I cannot see any other choice than to
allow forwarding of fragments. 

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Nov 2013 12:50:14 +0000

> allow forwarding of fragments. 

no, drop!  Because otherwise your infrastructure is wide open to control
plane attacks with ipv6 frags, with no means of defence!  If that happens,
then your entire network falls over.

Nick

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 13:54:08 +0100

Nick,

> then your entire network falls over.

why don't you filter out packets on the edge destined to your router's addresses?
instead of what's effectively breaking IPv6 service across the network.

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Nov 2013 13:07:55 +0000

> instead of what's effectively breaking IPv6 service across the network.

you can use infrastructure acls if they are handled carefully and don't
depend on implicit "deny any any" (which has special handling for the
"platform ipv6 acl fragment hardware").  But in order to implement this you
need to protect every single link network connected to your PFC3s.  If your
addressing plan is designed with this in mind, it's feasible.  If you have
a very large network or if you've not handled your link address assignments
very carefully, it's often not practical because it means dynamically
maintaining huge access lists on every single device on the network.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2013 04:21:11 +1300

> maintaining huge access lists on every single device on the network.

I think Homer Simpson has a word for this situation.

We *really* aren't going to deprecate fragmentation because of one
model of broken kit, are we?

   Brian

---

From: Jared Mauch <[email-masked]>
Date: Tue, 5 Nov 2013 10:31:08 -0500

> model of broken kit, are we?

I think the challenge here is that Cisco doesn't care to fix the problem
inherent in their software/hardware integration issue here.  There is no
structural correction of the defects in the software and nobody there takes
ownership to correct it.

I've sadly seen this play out time and time again without anyone fixing basic
infrastructure items that need correction.  They're unable to as it impacts
too many sub-platforms/internal consumers of the code that don't see the value
as it's not adding revenue.

Many of these headers (eg: hop-by-hop) are comparable to IPv4 features that
are ignored or dropped by firewalls and routers (Eg: source-route, ecn, etc).

Without an explicit standard that says things MUST be supported that we can
cite in RFP/RFI and broad coalition of purchasers it's difficult or impossible
to change things.  Places like Cisco are too big to steer and correct the
bad behavior.  I would love to be proven wrong, but years of experience tell
me it's not going to get better.

- Jared

---

From: joel jaeggli <[email-masked]>
Date: Tue, 5 Nov 2013 07:31:03 -0800

> model of broken kit, are we?

Do you think there’s one model of broken kit?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 05 Nov 2013 15:37:03 +0000

> I think Homer Simpson has a word for this situation.

"grim reality"?

> model of broken kit, are we?

flicking the question around, how much will it cost operators to upgrade
these boxes, and are they prepared to make this investment in order to fix
a problem which for the most part has a minimal impact on their networks
because 50% of web sites don't accept fragments anyway.

These devices are ubiquitous on the internet.  The IETF should ignore them
at their peril.  As Joel says, they're not the only box with problems, but
they are one of the problem contributors in the core.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2013 04:45:29 +1300

> Do you think there’s one model of broken kit?

Only one has been reported here. Of course I doubt if it's the only one
but it is very widely deployed.

> me it's not going to get better.

I don't think there's any doubt whatever that fragmentation is a mandatory
part of the IPv6 standard. For the rest of the extension headers, the
requirement is in the RFC Editor queue and the new IANA registry
is already in place at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

   Brian

---

From: [email-masked]
Date: Tue, 05 Nov 2013 16:57:17 +0100 (CET)

> because 50% of web sites don't accept fragments anyway.

Speaking only for myself and the network I know best: I have some
boxes that cannot inspect "sufficiently far" into the IPv6 packet.
These boxes will eventually be replaced as part of normal network
buildout/renewal. There's no way I'm going to ask management for
funding to replace these boxes *just* because they are suboptimal
for IPv6.

> they are one of the problem contributors in the core.

Agreed.

Steinar Haug, AS 2116

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Nov 2013 16:30:04 +0000

Hi, we can't deprecate IPv6 fragmentation; tunnels need it.

Thanks - Fred

---

From: Simon Perreault <[email-masked]>
Date: Tue, 05 Nov 2013 09:14:48 -0800

> they are one of the problem contributors in the core.

Won't they just disappear gradually, being replaced by newer boxes in 
the normal course of events?

Looks like a problem that will fix itself in time.

Simon

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 18:27:10 +0100 (CET)

> Looks like a problem that will fix itself in time.

I agree. I think it's good that there is documentation on current 
behaviour seen in the wild, but also would be interesting to hear about 
testing with current generation devices and how they perform.

Perhaps time for a rfc6204 style document for certain aspects? :P

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Nov 2013 10:29:28 -0800

On 11/5/2013 7:31 AM, Jared Mauch wrote:
> to change things.

RFC2460 Sec 4.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Nov 2013 18:53:12 -0800

Hi, Michael,

> I opposed to this wording in there as well.

Then I apologize -- I kind of assumed some sort of intention based on
that I-D. So.. point taken.

That said, the meat is in stats. :-)

> slow-path every IPv6 packet with a fragmentation header. Default behaviour.

But slow path != drop.

> I have no idea how much of the behaviour your're seeing is caused by
> this default behaviour, but I'd venture to guess a lot.
> 

Quickly skimming through the discussion it looks like a decision is made
to drop -- albeit for reasonable reasons. Am I missing something?

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Nov 2013 15:05:00 +0100 (CET)

>> slow-path every IPv6 packet with a fragmentation header. Default behaviour.

Since this platform does few megabits/s in slowpath, it's pretty close. 
Most reasonable people will deploy CoPP here and set low policer limits 
for this kind of traffic.

> to drop -- albeit for reasonable reasons. Am I missing something?

I'm sure there are some who set it to drop, and some set it to forward 
(both for good reasons), and some don't know and leave the default.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Nov 2013 11:05:58 -0800

> instead of what's effectively breaking IPv6 service across the network.

my routers actually do process unsolicited packets from from the internet (icmp echo for example, packets of any variety with a ttl of 1) and do need the control plane acl that reflects that.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Nov 2013 11:15:41 -0800

> my routers actually do process unsolicited packets from from the internet (icmp echo for example, packets of any variety with a ttl of 1) and do need the control plane acl that reflects that.

Why is passing ICMP echos to the CP acceptable, and passing fragments to 
the CP is not acceptable?

Simon

---

From: Pedro Torres <[email-masked]>
Date: Mon, 4 Nov 2013 23:53:38 -0200

Tim/Fernando,

--
Pedro

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Wed, 6 Nov 2013 14:01:40 +0100

Hi Fernando,

> we were having on the topic.

We had some some bugs in path MTU handling in the linux IPv6 stack which
will get resolved with the next stable kernels.

If such an experiment is repeated I would suggest keeping a tcpdump of
the traffic and an ip -6 monitor route log while doing this experiment.

I currently don't know if we report path MTU events back up to user space,
and if not, it will be hard to do so because that would confuse user space
routing daemons which already listen for route change notifications. But
for such an experiment I could provide such a patch. It would be nice
that we don't drop path mtu discovery on such busy boxes because of
regular routing garbage collector pressure or just because of bugs.

Greetings,

  Hannes

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 18 Nov 2013 21:50:39 +0000

Folks,

Fernando presents two studies in <http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. The second study is more interesting to me, because duplicate addresses are removed.

The following are a few questions regarding Fernando's second study:

1) Fernando observes that 41% of sites discard fragmented packets. However, in a similar study (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf) only 10% of sites discarded fragmented packets. I wonder why the two studies yield such divergent results.

2) Fernando observes that 44% of sites discard packets containing an 8 byte destination header, while 89% of sites discard packet containing 1 kilobyte of extension headers. Because the first number (44%) is so high, can I conclude that the second (89%) is insignificant.

Could it be that extension header length is a non-issue, because so many sites filter packets containing extension headers, regardless of their length?

                                                          Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: Monday, November 04, 2013 6:02 PM
> To: [email-masked]; IPv6 Operations
> Subject: Some stats on IPv6 fragments and EH filtering on the Internet
> 
> Folks,
> 
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Nov 2013 17:35:25 +1300

> 1) Fernando observes that 41% of sites discard fragmented packets. However, in a similar study (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf) only 10% of sites dis…

Well, that depends on whether there are significant differences between the
observation points and/or the set of target sites for the two studies. There's
certainly no law of physics that prevents both measurements being correct.

> Could it be that extension header length is a non-issue, because so many sites filter packets containing extension headers, regardless of their length?

I don't think so. We've just agreed on an update to RFC 2460 that, if it is
adopted by middleboxes, will fix or at least clarify the issue of what
happens to short extension headers. We need to wait a few years to see
if that happens, of course. That seems to me to be quite disjoint from
the issue of whether boxes that inspect extension headers have big
enough buffers, and distinct again from whether they handle fragmented
headers. I think there are three problems, needing three solutions.

   Brian
                                                          Ron

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 19 Nov 2013 15:29:00 +0000

Brian,

I see your point. If we fix the problems associated with extension headers, people will configure their middle-boxes to allow them. So, if we repeat Fernando's experiment in a few years, we may see very different results. 

You say that there are three distinct problems. I am aware of the following:

- the tiny fragment problem (addressed by draft-ietf-6man-oversized-header chain)
- the long header chain problem (addressed by draft-kumari-6man-long-headers)

What is the third problem?

                                              Ron

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, November 18, 2013 11:35 PM
> To: Ronald Bonica
> Cc: Fernando Gont; [email-masked]; IPv6 Operations
> > Fernando presents two studies in <http://www.iepg.org/2013-11-
> ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. The second study is
> more interesting to me, because duplicate addresses are removed.
> >
> > 1) Fernando observes that 41% of sites discard fragmented packets.
> However, in a similar study
> (http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-
> thesis.pdf) only 10% of sites discarded fragmented packets. I wonder
> why the two studies yield such divergent results.
> 
> Well, that depends on whether there are significant differences between
> the observation points and/or the set of target sites for the two
> studies. There's certainly no law of physics that prevents both
> measurements being correct.
> 
> > 2) Fernando observes that 44% of sites discard packets containing an
> 8 byte destination header, while 89% of sites discard packet containing
> 1 kilobyte of extension headers. Because the first number (44%) is so
> high, can I conclude that the second (89%) is insignificant.
> 
> > Could it be that extension header length is a non-issue, because so
> many sites filter packets containing extension headers, regardless of
> their length?
> 
> I don't think so. We've just agreed on an update to RFC 2460 that, if
> it is adopted by middleboxes, will fix or at least clarify the issue of
> what happens to short extension headers. We need to wait a few years to
> see if that happens, of course. That seems to me to be quite disjoint
> from the issue of whether boxes that inspect extension headers have big
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Fernando Gont
> >> thought that this could be good food sfor some of the discussions
> >> that we were having on the topic.
> >>
> >> Thanks,
> >> --
> >> Fernando Gont

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2013 08:26:56 +1300

> What is the third problem?

 - middleboxes that don't deal with all header types (addressed by draft-ietf-6man-ext-transmit)

   Brian