Subject: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt)

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Mar 2015 02:08:38 +0100

Folks,

At the IETF meeting in Hawaii we presented
draft-gont-v6ops-ipv6-ehs-in-real-world. Folks seemed to be in favor of
an I-D providing real-world data about the extent to which packets with
EHs are dropped in the Internet, but didn't support having the I-D
provide advice on this topic.

We have revised the I-D. Lots of things were corrected and/or clarified.
And all such text the wg was not in agreement with has now been removed.

The new rev is available at:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt>

Please do let us now if you have any feedback.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt
Date: Sun, 08 Mar 2015 22:36:09 -0700
From: [email-masked]
To: Will Liu (Shucheng) <[email-masked]>, J. Linkova
<[email-masked]>, Shucheng LIU (Will) <[email-masked]>, Tim
Chown <[email-masked]>, Tim Chown <[email-masked]>, Fernando
Gont <[email-masked]>, Fernando Gont <[email-masked]>, J.
Linkova <[email-masked]>

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

Name:		draft-gont-v6ops-ipv6-ehs-in-real-world
Revision:	02
Title:		Observations on IPv6 EH Filtering in the Real World
Document date:	2015-03-08
Group:		Individual Submission
Pages:		15
URL:
http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/
Htmlized:
http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-in-real-world-02

Abstract:
   This document presents real-world data regarding the extent to which
   packets with IPv6 extension headers are filtered in the Internet (as
   measured in August 2014), and where in the network such filtering
   occurs.  The aforementioned results serve as a problem statement that
   is expected to trigger operational advice on the filtering of IPv6
   packets carrying IPv6 Extension Headers, so that the situation
   improves over time.  This document also explains how the
   aforementioned results were obtained, such that the corresponding
   measurements can be reproduced by other members of the community.

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

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

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Mar 2015 14:56:02 +0000

> Please do let us now if you have any feedback.

Interesting.  Where did you take the measurements from?

Nick

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Mar 2015 14:06:36 +0100

I don’t think you can equate ‘real world’ with ‘public servers’.

to me it seems the draft documents what should be expected. public servers doesn’t accept packets that aren’t part of the service they offer.

what is it you find unexpected in the behaviour you have found?

I’m concerned about this draft. I think it will be used to justify claims that fragmentation, extension headers or new transport protocols cannot be deployed, but as far as I can see it does no such thing.

if you wanted to see how extension headers are treated end to end in the Internet, then measure that.

cheers,
Ole

> On 10 Mar 2015, at 2:08 , Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Mar 2015 14:00:44 +0000

On 12/03/2015 13:06, Ole Troan wrote:
> to me it seems the draft documents what should be expected. public
> servers doesn’t accept packets that aren’t part of the service they
> offer.

i suspect the points being made here are that:

1. within the terms of the methodology used, results are observed.

2. if end points on the v6 internet attempt to connects to these systems
where the packets are configured to use EHs, those connections may fail as
a direct result of using EHs.

3. this appears to be a problem at both the core and edge of the ipv6 internet

These are important issues and need to be addressed.

Although it needs a good deal more work, I'd like to see v6ops adopting
this ID.

Nick

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Mar 2015 14:09:23 +0000

Hi,

> On 12 Mar 2015, at 14:00, Nick Hilliard <[email-masked]> wrote:
> 

The point is that this draft captures and distills the results of a number of different measurements taken by different groups. These have been presented at IEPG over recent IETFs, by at least Fernando, Jen, and myself.

The results are of concern, but there is an implied call for further measurements and analysis. I agree that Fernando’s original assertions in the draft were too strong too early, but there is an important issue here. I also don’t think the results can be discounted on the basis that Ole makes. Remember the principles that Brian’s RFC requires - these are not (yet) being implemented. How specific servers handle various EHs (with nothing on the path) can be demonstrated by running the tests between clients and servers on the same link.

Tim

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Mar 2015 16:24:16 +0100

Nick,

> 1. within the terms of the methodology used, results are observed.

right. the methodology seems to detect a site/system filtering policy. for an analogy, try to run those measurements against any of my hosts inside the Cisco corporate network. you’ll find that all UDP gets filtered. can you or should you draw any general conclusions from that? I think not.

> a direct result of using EHs.

sure, is that a problem?

> 3. this appears to be a problem at both the core and edge of the ipv6 internet

I can’t find anything in the draft showing that the core of the Internet is applying this filtering policy.

> Although it needs a good deal more work, I'd like to see v6ops adopting

I also think it is important to measure IPv6 EH behaviour in the Internet. I’m concerned about the methodology used here, and I think the text way overstates the problem. (there might be a problem of course, but then a better methodology should be used).

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Mar 2015 21:16:04 +0000

On 12/03/2015 15:24, Ole Troan wrote:
> right. the methodology seems to detect a site/system filtering policy.
> for an analogy, try to run those measurements against any of my hosts
> inside the Cisco corporate network. you’ll find that all UDP gets
> filtered. can you or should you draw any general conclusions from that?
> I think not.

exactly, which was why the first question I asked about this draft revision
was where the measurements were taken from.  As you point out, this is
critically important.

>> 2. if end points on the v6 internet attempt to connects to these
>> systems where the packets are configured to use EHs, those connections
>> may fail as a direct result of using EHs.
> 
> sure, is that a problem?

I'd be inclined to think that if a connection fails due to a mechanism
which is or should be invisible to end users (e.g. fragmentation) then yep,
that's a problem.

this was mentioned in the draft:

> Secondly, our results indicate that a significant percentage of such
> packet drops occur in transit Autonomous Systems.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Mar 2015 10:32:05 +1300

> which is or should be invisible to end users (e.g. fragmentation) then yep,

Very much so. The reason I got interested in this problem in the first
case was the discovery that to use certain extension headers between
two experiment-specific servers on the Internet, it was necessary to
literally bypass the site firewalls at both ends. And these results show
failures not only at the end-AS but also in a noticeable fraction
of cases at an intermediate AS. So the choice of servers is a bit beside
the point.

True, a much more widespread set of tests, probably using dedicated
test boxes, would be needed to get a statistically valid assessment.
But we already know that there's a widespread pattern of failure.

Whether the IETF can do more about this than RFC 7045 is another
question entirely.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Mar 2015 23:08:33 +0100

> literally bypass the site firewalls at both ends. And these results show
                                 ^^^^^^^^^^^^
well, there’s your problem.

> of cases at an intermediate AS. So the choice of servers is a bit beside

that’s a more interesting case. with a relatively large uncertainty.
presumably we could take some of these paths from the data set and ask the suspected dropping providers what’s going on?

> But we already know that there's a widespread pattern of failure.

I think it has to be shown that this isn’t end-AS firewall policy.

> Whether the IETF can do more about this than RFC 7045 is another

apart from dropping HBH I would be quite surprised if there were any transit AS operators thinking that filtering fragments was acceptable for a functioning Internet. let’s get some more real data on what’s really going on.

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Mar 2015 22:27:23 +0000

> I think it has to be shown that this isn’t end-AS firewall policy.

as it stands, I'm happy that there is enough data in the draft to show that
this isn't solely an edge problem.

> I would be quite surprised if there were any transit AS operators
> thinking that filtering fragments was acceptable for a functioning
> Internet.

transit operators have been doing this for years.  One reason they might do
it is CoPP limitations on the PFC3 supervisor card on the c6500/7600
platform.  Although this kit is well past its useful lifetime, there are
lots of these boxes in operation on many networks, including many of the
well-known "tier 1" transit operators.

Nick

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Mar 2015 23:35:07 +0100

Nick,

> well-known "tier 1" transit operators.

yes, so that example would definitely be in the misconfiguration/software/hardware bug category.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Mar 2015 11:42:10 +1300

>> I think it has to be shown that this isn’t end-AS firewall policy.

And/or load balancers that barf on extension headers. I agree that
end-AS middleboxes are a large part of the problem (but see Nick's
point below).

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Mar 2015 22:52:09 +0000

On 12/03/2015 22:35, Ole Troan wrote:
> yes, so that example would definitely be in the
> misconfiguration/software/hardware bug category.

If this is the best approach we can close down this discussion on the spot
and declare the entire issue to be a problem relating to misconfiguration,
bugs or both.  The standards are clear on the requirement to support IPv6
EHs so if operators / vendors aren't following it properly then surely
that's out of scope for the IETF?

Or we could acknowledge that there is a problem, look into the causes and
see if it's worth doing something about it with a view to fixing it in the
long term.

I'm inclined to think that the latter is a more sensible approach.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 13:54:00 +0100

> Interesting.  Where did you take the measurements from?

For the results we've published in the I-D, the tests were performed
from host Slovenia. Same results were obtained when redoing the tests
from Brazil.

And measuring things from the UK, and even (distributed) with the RIPE
probes gives the same results.  -- this is not surprising, since the
drops do not happen close to the origin, but rather at the Dest AS or
transit ASes.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 14:04:09 +0100

> I don’t think you can equate ‘real world’ with ‘public servers’.

Well, public servers are part of the real world. What we meant is that
this I-D gives results from actual measurements.

FWIW, if anyone is concerned about the title, we could update it. I
personally don't think it's needed... but I wouldn't be opposed to do so.

> servers doesn’t accept packets that aren’t part of the service
> they offer.

Well, in order for options to be incrementally deployable, they should
be allowed. When it comes to IP options, I'm not sure I consider them
to be "part of the service".

Fragmentation, in particular, is a core part of IP.

> I’m concerned about this draft. I think it will be used to justify 
> claims that fragmentation, extension headers or new transport 
> protocols cannot be deployed, but as far as I can see it does no
> such thing.

Me, I see the results as "there is a problem here". That's it. There
are other efforts (Brian and Sheng's RFC7045, the I-D we published on
option transmission aimed at 6man, e.g.) that indeed try to help in
improving the state of affairs (rather than "ban" EHs).

> in the Internet, then measure that.

host-to-servers is certainly part of that. Certainly measuring
client-to-clients would also be nice -- and that's in the works
through the use of RIPE atlas. However, that would be *additional*
data as opposed to *stuff to replace what's currently in the I-D*.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 14:06:57 +0100

On 03/12/2015 04:24 PM, Ole Troan wrote:
> I can’t find anything in the draft showing that the core of the 
> Internet is applying this filtering policy.

"Drop rates by non-dest AS"?

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 14:13:07 +0100

On 03/12/2015 11:08 PM, Ole Troan wrote:
>>  of cases at an intermediate AS. So the choice of servers is a
>> bit beside the point.
> 
> that’s a more interesting case. with a relatively large
> uncertainty. presumably we could take some of these paths from the
> data set and ask the suspected dropping providers what’s going on?

I can provide the list of ASes if you folks wish (I recently updated
the tools such that they inform the dropping ASes... os the list is
readiliy available).

> apart from dropping HBH I would be quite surprised if there were
> any transit AS operators thinking that filtering fragments was
> acceptable for a functioning Internet. let’s get some more real
> data on what’s really going on.

What's (specifically) the data that you're looking for? -- I'm not
objecting, but rather asking so that ew can produce whatever you think
is missing.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 14:16:22 +0100

On 03/12/2015 11:52 PM, Nick Hilliard wrote:
> bugs or both. 

mm. does that really solve the problem?

Whether there's a bug, misconfiguration, or something else that prevents
me form using EHs, seems rather irrelevant -- at the end of the day, no
matter the specfic cause, you cannot use EHs in those networks.

> The standards are clear on the requirement to support IPv6

Fully agree.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 14:26:28 +0100

Hi, Silvia,

On 03/13/2015 08:28 AM, Silvia Hagen wrote:
> I totally understand all those issues, limitations, practices and
> concerns. I am concerned about a tendency in the discussions to try
> to make up and adjust standards for vendor limitations, configuration
> issues, hardware bugs etc. And I think that is the wrong way to go. I
> do believe that when it comes to architectural things like EHs the
> working groups should stick to the design and the architecture and
> help and expect the market to implement it properly. It is not a
> working group/IETF problem if hardware have limitations, if firewall
> administrators decide to drop EHs etc.... We should stick to the
> original design and let this be their issue to solve by developing
> mechanisms which support the future protocol and its architecture. 

I sympathize with the idea. However, I should note that there are areas
where "proper implementation" doesn't seem to be on the horizon.
Specific example: support of IPv6 header chains of arbitrary lengths (at
least a packet full of EHs). Most of the architectures I recall checking
enforce a limit on theIPv6 header chain. -- and it seems to be a
"chicken and egg" problem: It's hard to believe that a router vendor
will put money into something that is currently not required by any
protocols (in practice). And of course you cannot relly on such
full-sized EH chains if there's no support for them.

FWIW, I'm not in favor of "banning" EHs, but I'm rather all for
improving the current state of affairs.

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Mar 2015 15:26:01 +0000

> drops do not happen close to the origin, but rather at the Dest AS or

ok great.  I had assumed it was from multiple start points.  The source
ASNs and any filtering between the source hosts and the upstream links
(even if there is none) should be mentioned in the draft because it's an
important part of the experiment methodology.

Nick

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Mar 2015 17:23:51 +0000

> On 13 Mar 2015, at 15:26, Nick Hilliard <[email-masked]> wrote:
> 

I agree. And a very fair point. There may be commonalities to certain points of origin. That said, it is possible to benchmark local filtering by tests to specific external services that can be seen to work.

I’d add that not all results are black and white. As an example, you can see drop rates increase as certain header chain lengths increase. 

Perhaps we can further clarify the methodology in response to comments so that we can have people run the tests from a wider set of observation points. And/or release the code used.

We have held bar BoFs between those running the experiments at previous IETFs, e.g. London. We can do more of that too, if people are interested.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Mar 2015 22:03:45 +0100

Nick,

On 03/13/2015 04:26 PM, Nick Hilliard wrote:
> ok great.  I had assumed it was from multiple start points. 

FWIW, a much more distributed set of measurements (with RIPE Atlas) were
done, and the results were along the same lines.

> The source

FWIW, while not included in the I-D, for the measurements included in
the I-D we also measured the number of hops from the Destination system
where the packet drop occurs, etc. And the filtering does not hppen at
the source. That why reproducing the measurements form a different
location (or doing a more distributed set of measurements with RIPE
Atlas doesn't get you different results).

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Mar 2015 13:28:05 +1300

On 14/03/2015 02:26, Fernando Gont wrote:
> least a packet full of EHs). 

And chip-level hardware designers will explain to you exactly why this
is a painfully expensive thing to do at line speed. This stuff was
designed by software people at the tail end of the 32-bit minicomputer
era, and things looked different to them^H^H^H^Hus than they do to a
21st century chip designer.

At some point we might get lucky and someone will actually design RFC 7045
chips... but remember that one of the things we had to put in that RFC
was:
   The list of standard and experimental extension header types is
   maintained by IANA (see Section 4), and implementors are advised to
   check this list regularly for updates.
Even when I drafted that, I could hear my chip designer friend laughing
heartily.

   Brian

> Most of the architectures I recall checking

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 15 Mar 2015 23:06:34 +0000

Fernando, Jen and Tim,

This is indeed a very important topic that deserves the full focus of the
Internet at large (read beyond IETF == to operator groups such as NANOG).
This topic is SO important that I would appreciate an improved version of
it (and I can work with you on this).

Beside the very much needed refresh (Summer 2014 is a long time ago):
- should explain how the range of 'dropped by intermediate AS' is computed?
- should specify which kind of fragments were used? If first fragment was
without enough of layer-4 information, then I am happy with 100% drop :-)
(thanks Fernando for your RFC allowing this paranoid behavior :-) )
- detecting the dropping AS is really really tricky (look for academic
papers on router aliasing). Did the test use 'slow testing'? Security
cautious operators are rate-limiting their ICMP generation, so,
testing/scanning too fast could trigger this rate-limiting
- at some point of time (probably outside IETF), you should made the 'wall
of shame' public to incentive dropping AS to change behavior

Minor comments:
- as expressed by others, testing Alexa/well-known domains is probably not
giving a realistic view (too many CDN or SLB for those domains)
- testing from a couple of sites (or from RIPE Atlas going through
residential routers) may bias the output result
- also testing against 1 million site and weighting google.com on the same
level of vyncke.org is also providing some bias
- dropping HbH is OK for me, dropping destination header is less, so,
vastly different measurement angles
- unsure how to handle the above though :-)
- I made several quick and dirty tests (www.vyncke.org/sr.php) and I am
way more positive than your outcome. Still wondering why and looking
forward to analyzing this with you :-)

Finally, I would have hoped to see 100% packet drop for HbH ;-)

Let's talk if not at Troopers, or V6 World Congress then in Dallas ! :-)

A very much needed piece of work,

-éric

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Mar 2015 01:07:39 +0100

Hi, Eric,

Thanks so much for your feedback! Please find my comments in-line...

> Beside the very much needed refresh (Summer 2014 is a long time ago):

[FWIW, the refresh is in the works... Actually, done, but not yet
incorporated such that we could meet the submission cut-off deadline]

> - should explain how the range of 'dropped by intermediate AS' is computed?

Something else other than what's in Section B.2?

> (thanks Fernando for your RFC allowing this paranoid behavior :-) )

We will clarify this. FWIW, they were normal/legitimate fragments.

> papers on router aliasing).

Any specific one we should be aware of?

> Did the test use 'slow testing'? Security

Yes. Also, when the probe type is != from ICMP, then the final
destination would respond (e.g. TCP SYN/ACK or TCP RST), and hence this
wouldn't be considered a packet drop.

> of shame' public to incentive dropping AS to change behavior

Heads-up: I've updated the tools to provide the list of dropping ASes. I
guess that the transit ASes could be put in a "wall of shame". However,
when it comes to destination ASes, there are more valid reasons to drop
EH-enabled packets...

> giving a realistic view (too many CDN or SLB for those domains)

FWIW, we do drop duplicate addresses for the tests. Hence each IPv6
address is measured once (no matter how many domains employ it/them).

> residential routers) may bias the output result

While this is certainly possible, packet drops are not ocurring at the
surce, but rather at transit or destination ASes. Chainging the surce of
the probes to different locations seem to agree with this view.

> level of vyncke.org is also providing some bias

I'd say that both are meaningful measurements, but they represent
different things. One ma want t measure the % of sites that support EHs
(no matter which site), or a kind of "weighed" measurements, where
"popular sites" count more than one. In this case, we were trying to do
the former.

> forward to analyzing this with you :-)

Are your results publicly-available?

> Finally, I would have hoped to see 100% packet drop for HbH ;-)

Same here :-)

> Let's talk if not at Troopers, or V6 World Congress then in Dallas ! :-)

Yes. :-)

Thanks!

Best regards,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 16 Mar 2015 07:07:44 +0000

Hello Fernando, 

Thanks for your detailed reply. See in-line for remaining comments/answers

>Something else other than what's in Section B.2?

Re-reading B.2 with fresh eye => OK it is enough to understand

>Any specific one we should be aware of?

Look for papers around "Alias resolution", there is even one by University
of Maryland on "UAv6" where specific IPv6 tricks were used.

>Are your results publicly-available?

No, they were more ad-hoc based on locations where I am travelling... So,
not enough samples to be worth but until now is was always 100% success
when no firewall where in the path (probably about 50 tests only).

-éric

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 09:29:35 +0100

Brian,

> 21st century chip designer.

that is not how I recall history.
I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware, cause routers aren’t supposed to be doing that.

has anything changed in the last 15-20 years? I didn’t think there was IETF consensus to modify protocols to be easier on middleboxes.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 10:07:38 +0100

Fernando,

> objecting, but rather asking so that ew can produce whatever you think

I’m looking for data identifying where filtering is done _not_ by design.
and where filtering is done not by the end-points / end-sites (although that demarcation can be a little blurry, e.g. in case of ISP controlled CPEs with broken firewalls).

cheers,
Ole

---

From: [email-masked]
Date: Mon, 16 Mar 2015 10:15:28 +0100 (CET)

> I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware, cause routers aren$,1ry(Bt supposed to be doing that.

Looking at it from an operational point of view, as far as I can see
my routers have two options:

- Either they can skip past (in hardware) IPv6 headers until they
reach the relevant upper layer header (UDP, TCP, ICMP etc). This may
or may not imply full IPv6 header parsing.

- Or they have to drop the packet.

This of course also implies that the size of the IPv6 headers must be
compatible with how far my routers can peek into the packet.

Steinar Haug, AS 2116

---

From: George Michaelson <[email-masked]>
Date: Mon, 16 Mar 2015 10:20:18 +0100

Ole, the average diameter in AS hops is 4. There's two origin-as, and
approximately 2 intermediate AS.

That means that 50% of the average AS path *is* the origin, where filtering
happens. Either my origin, our your origin.

You're hunting for a small amount of middle filter with a huge problem of
edge filter surely?

On Mon, Mar 16, 2015 at 10:15 AM, <[email-masked]> wrote:

> > I vividly recall a conversation with Steve back in 1998 or 1999 when he
> got confronted with this, stated that it was a design feature. extension
> headers are designed to be hard to parse in hardware, cause routers
> aren�1ryt supposed to be doing that.
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 12:06:01 +0100

> Ole, the average diameter in AS hops is 4. There's two origin-as, and approximately 2 intermediate AS.
> 
> That means that 50% of the average AS path *is* the origin, where filtering happens. Either my origin, our your origin.
> 
> You're hunting for a small amount of middle filter with a huge problem of edge filter surely?

possibly. I would be hunting for places where filtering is done and where it isn’t a conscious policy to do so.

I could certainly imagine services like e.g. google where they know exactly the service profile and MTU, and would filter accordingly. identifying services like that doesn’t appear very interesting. we’re not going to change their mind anyway (nor do I think it is the IETF’s business to do so).

I think you’re right in pointing out that AS level is not the right granularity.
e.g. as a home user I’d like to find out if my ISP filters, or if my ISP run CPE filters, or random transit provider filters.

cheers,
Ole
> > I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware, cause routers aren�1ryt supposed to be doing that.
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 12:07:16 +0100

>> I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware, cause routers aren�$,1ryt supposed to be doing that.
> 

why would you want  your routers to look deeply into _my_ packets?

cheers,
Ole

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 05:59:15 -0700

> why would you want  your routers to look deeply into _my_ packets?

same reason as in v4:

There's not enough entropy in the ip header for hashing

Application of l4 acls means finding the header.

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 14:40:38 +0100

Joel,

> There's not enough entropy in the ip header for hashing

if it is for ECMP then I think Steinar’s measure were a little brutal.

> Application of l4 acls means finding the header.

yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the middle of the network.
are you saying there is equipment out there that tries to do ECMP, fails to find the 5 tuple and drops?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Mar 2015 12:31:38 +0100

On 03/16/2015 12:07 PM, Ole Troan wrote:
>> This of course also implies that the size of the IPv6 headers
>> must be compatible with how far my routers can peek into the
>> packet.
> 

You're assuming that between source and destination there are only
RFC1812-like IPv6 routers. But devices enforcing ACLs, firewalls,
load-balancers and the like usually end up having to look into your
packets.

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Mar 2015 09:54:46 -0400

> load-balancers and the like usually end up having to look into your

Why on earth would an ISP enforce ACLs?

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 06:57:32 -0700

> yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the middle of the network.

If you reason about a network, and the doesn't include the existence of
acls on the edges then your model is pretty bad.

> are you saying there is equipment out there that tries to do ECMP, fails to find the 5 tuple and drops?

While I would expect all sorts of abberant behavior from a failure to
hash like all those flows groomed onto one link I would not expect drops
from a router. a load balancer on the other hand absolutely.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 07:01:01 -0700

> Why on earth would an ISP enforce ACLs?

Lets live in the real world shall we?

http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Mar 2015 14:05:05 +0000

> yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the

There are many legitimate reasons to have l4 ACLs in the core.  Joel
pointed out iACLs.  I'll point out Flowspec and router control plane
policing / RE firewalling rules.

> yes, but I wouldn’t expect my packets to be subject to L4 ACLs in the
> middle of the network. are you saying there is equipment out there that
> tries to do ECMP, fails to find the 5 tuple and drops?

no, much worse.  it tries to do ECMP, fails to find a functional n-tuple,
then jams all the traffic  down the same bundle member, overloads that link
and causes apparently arbitrary third party packet loss.

Nick

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 15:07:31 +0100

Joel,

> acls on the edges then your model is pretty bad.

if you have followed the thread, I’m assuming there is network policy applied close to the two endpoints.
there seemed to be indication that there might be filtering done outside of the administrative domains of the two endpoints, I would be interested in knowing and understanding more about that.

I’m also assuming that whatever e.g. cisco IT does with their firewalls isn’t something the IETF can do anything about.

> from a router. a load balancer on the other hand absolutely.

right, but load balancers are in my view a part of the “service”.  and I’m not particularly concerned about those not letting through any other packets than those that are part of the service. (which seems to be a large part of Fernando’s tests).

cheers,
Ole

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 07:18:15 -0700

On 3/16/15 7:07 AM, Ole Troan wrote:
>> If you reason about a network, and the doesn't include the
>> existence of acls on the edges then your model is pretty bad.
> 
> if you have followed the thread, I’m assuming there is network policy
> applied close to the two endpoints. there seemed to be indication
> that there might be filtering done outside of the administrative
> domains of the two endpoints, I would be interested in knowing and
> understanding more about that.

You definition of close to the endpoints and mine may vary, there are
certainly L4 acls applied in residential ISPs, datacenter network
operators and even transit ISPs  at places other than ingress from the
customer for reasons of manageability convenience or scalability.

Anyone who has employed flowspec either in their own network or at the
behest of a customer has probobaly installed an l4 acl someplace other
than the customer edge.

> I’m also assuming that whatever e.g. cisco IT does with their
> firewalls isn’t something the IETF can do anything about.
> 
>> 
>>> are you saying there is equipment out there that tries to do
>>> ECMP, fails to find the 5 tuple and drops?
>> 
>> While I would expect all sorts of abberant behavior from a failure
>> to hash like all those flows groomed onto one link I would not
>> expect drops from a router. a load balancer on the other hand
>> absolutely.
> 
> right, but load balancers are in my view a part of the “service”.
> and I’m not particularly concerned about those not letting through
> any other packets than those that are part of the service. (which
> seems to be a large part of Fernando’s tests).
> 
> cheers, Ole
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Mar 2015 15:22:55 +0100

Joel,

> behest of a customer has probobaly installed an l4 acl someplace other

I would be interested in identifying the other cases, not the “at the behest of a customer” case. the IETF shouldn’t prohibit people from breaking their Internet connection. ;-)

cheers,
Ole

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 07:31:11 -0700

On 3/16/15 7:22 AM, Ole Troan wrote:
> Joel,
> 
>> Anyone who has employed flowspec either in their own network or at
>> the behest of a customer has probobaly installed an l4 acl
>> someplace other than the customer edge.
> 
> I would be interested in identifying the other cases, not the “at the
> behest of a customer” case. the IETF shouldn’t prohibit people from
> breaking their Internet connection. ;-)

If you have to match on a particular header for a source or destination
prefix and you can't find it, the baby goes out with the bathwater.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Mar 2015 15:23:44 +0000

> http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

All right... all right... but apart from infrastructure ACLs, DDoS
management, working ECMP and other hash-based load-balancing
implementations, customer requests for filtering, implementation of
edge-to-core customer sanitisation filters and route-processor protection,
what do we need functional ipv6 L4 packet for??!?

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Mar 2015 12:36:53 -0400

> http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

Ah, so the reason that an ISP would enforce ACLs is because of a protocol with a lousy security model that is only fixable (and even then, not very) with the help of firewalls.   Fair enough--I had developed a blind spot about this issue because it's been broken for so long and we've been reflexively avoiding the brokenness for so long.

But essentially what's happening here is that we are seeing a design flaw at layer 7 forcing brokenness at layer 3.   Oops.   Maybe we should stop reflexively working around this problem and seriously figure out how fix it, so that twenty years from now we no longer need a broken layer 3.

---

From: [email-masked]
Date: Mon, 16 Mar 2015 18:19:23 +0100 (CET)

> But essentially what's happening here is that we are seeing a design flaw at layer 7 forcing brokenness at layer 3.   Oops.   Maybe we should stop reflexively working around this problem and seriou…

I'm all for that. However, I cannot afford to wait 20 years for a fix
to the problems. My priorities, as I see them:

1. Protect my network.
2. Within reason, protect my customers.
3. Move traffic to and from my customers, in a semi-optimal way.

You'll notice that the free-flowing IPv4/IPv6 traffic some people here
seem to want is *not* priority number one.

In the current Internet environment, "protect my network" is likely to
stay on top for the foreseeable future. If that means ACLs and similar
tools at other places in the network than just the edges - so be it.

Steinar Haug, AS 2116

---

From: Warren Kumari <[email-masked]>
Date: Mon, 16 Mar 2015 18:35:47 +0100

> seem to want is *not* priority number one.

See:

Why Operators Filter Fragments and What It Implies
draft-taylor-v6ops-fragdrop-02

https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02

We keep threatening to bring this back from the dead -- perhaps we'll
finally do so...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Mar 2015 10:39:13 -0700

On 3/16/15 9:36 AM, Ted Lemon wrote:
> Ah, so the reason that an ISP would enforce ACLs is because of a
> protocol with a lousy security model that is only fixable (and even
> then, not very) with the help of firewalls.   Fair enough--I had
> developed a blind spot about this issue because it's been broken for
> so long and we've been reflexively avoiding the brokenness for so
> long.
> 
> But essentially what's happening here is that we are seeing a design
> flaw at layer 7 forcing brokenness at layer 3.   Oops.   Maybe we
> should stop reflexively working around this problem and seriously
> figure out how fix it, so that twenty years from now we no longer
> need a broken layer 3.

Maybe, by I don't dictate the business logic of consumer ISPs and
neither does the IETF. I do however appreciate when operators make good
faith efforts to deal with attractive nuisances that are otherwise
negative externalities for the rest of the internet.

I do consider that if the situation gets better their behavior may change.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Mar 2015 14:09:55 -0400

> negative externalities for the rest of the internet.

No argument here.

> I do consider that if the situation gets better their behavior may change.

Yup, that was my point.   I guess a pretty obvious point, but I hadn't really thought of it that way until reading your previous reply.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Mar 2015 08:14:31 +1300

> I vividly recall a conversation with Steve back in 1998 or 1999 when he got confronted with this, stated that it was a design feature. extension headers are designed to be hard to parse in hardware…

That's true too: Steve's position was that middleboxes are evil and therefore
should not be considered during the design. So it wasn't a consideration,
whereas convenient parsing on a VAX was. The point is, the resulting design
is very *inconvenient* for hardware protocol engines.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 17 Mar 2015 14:52:44 +0100 (CET)

> 3. Move traffic to and from my customers, in a semi-optimal way.

Please also add 4. "Protect the Internet from your customers". This is 
something too many miss.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 17 Mar 2015 07:10:58 -0700

On Mar 17, 2015, at 6:52 AM, Mikael Abrahamsson <[email-masked]> wrote:

> Please also add 4. "Protect the Internet from your customers". This is something too many miss.

I for one am really glad that we are getting operational reality input.   Thank you.  FWIW, I'm sitting next to Fernando at a security conference we are both at
and I had offered to help with this draft.  This was a few months ago.  What I see is that we are in need of some additional measurements and that
will happen.  I would love to see some added input on this list in how to improve measurements rather than the criticism of just how current measurements
have been done.  Collectively gathering operational realities is a good thing for added input on how to deal with EHs.  And FWIW, I am not in favor of
deprecating EHs since that is too drastic but we as a community have to understand where they are practically used and where they are dropped for
reasons that some deem as necessary.

- merike

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 26 Mar 2015 14:37:41 +0000

Merike and Fernando,

As I wrote a couple of comments on the methodology, I do not mind joining
your test campaign ;-)

Let's talk perhaps here in Dallas?

-éric

On 17/03/15 15:10, "Merike Kaeo" <[email-masked]> wrote:

>>>>so long and we've been reflexively avoiding the brokenness for so long.
>>>> 
>>>>figure out how fix it, so that twenty years from now we no longer need
>>>>a broken layer 3.
>>> 
>I for one am really glad that we are getting operational reality input.
>Thank you.  FWIW, I'm sitting next to Fernando at a security conference
>we are both at
>and I had offered to help with this draft.  This was a few months ago.
>What I see is that we are in need of some additional measurements and that
>will happen.  I would love to see some added input on this list in how to
>improve measurements rather than the criticism of just how current
>measurements
>have been done.  Collectively gathering operational realities is a good
>thing for added input on how to deal with EHs.  And FWIW, I am not in
>favor of
>deprecating EHs since that is too drastic but we as a community have to
>understand where they are practically used and where they are dropped for

---

From: Merike Kaeo <[email-masked]>
Date: Thu, 26 Mar 2015 07:47:53 -0700

Sounds good.

Warren/Joel…I think resurrecting work on Why Operators Filter Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a good idea :)

- merike

[list may get duplicate of this message since first attempt was blocked due to using email I didn't use to subscribe to list…..apologies in advance]

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Mar 2015 15:53:05 +0100

> Warren/Joel…I think resurrecting work on Why Operators Filter Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a good idea :)

Do we really need to resurrect a draft which covers one particular EH
filtering while we are working on a draft which covers EHs in general?

-- 
SY, Jen Linkova aka Furry

---

From: Merike Kaeo <[email-masked]>
Date: Thu, 26 Mar 2015 08:38:21 -0700

> filtering while we are working on a draft which covers EHs in general?

:)   There's the option of resurrecting and expanding on the document that describes why EHs in general are dropped and does not only speak to Fragmentation Headers.

IFF there is interest in more work on general case of Why Operators Filter EHs - probably best to keep as separate document.  I think.  I was debating with myself as to whether I'd prefer to read it in one single document (here is what's measured, here's why EHs are dropped in practice by operators, advice on operational practices).  But I haven't decided for myself yet since there is merit in just keeping a measurement document separate so that the problem statement can be kept separate from any recommendations, which will be wiggly at best.

- merike

---

From: joel jaeggli <[email-masked]>
Date: Thu, 26 Mar 2015 17:52:38 -0500

> Warren/Joel…I think resurrecting work on Why Operators Filter Fragments (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a good idea :)

it might be time, though I expect it won't be super warmly received either.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 27 Mar 2015 00:35:32 +0000

> it might be time, though I expect it won't be super warmly received either.

I'm interested in seeing this document revived if the data in
draft-gont-v6ops-ipv6-ehs-in-real-world can establish with reasonable
confidence that there is a problem.  If a problem is established, then the
scope of this document should be widened to include all ipv6 EHs rather
than solely concentrating on fragments.

Nick

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 27 Mar 2015 13:49:49 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Merike Kaeo
> Sent: Thursday, March 26, 2015 10:38 AM
> To: Jen Linkova
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [v6ops] IPv6 EHs in the Real World (Fwd: New Version Notification
> for draft-gont-v6ops-ipv6-ehs-in-real-world-02.txt)
> 
> 
> >> Warren/Joel...I think resurrecting work on Why Operators Filter
> >> Fragments
> >> (https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02) may be a
> >> good idea :)
> >
> :)   There's the option of resurrecting and expanding on the document that
> describes why EHs in general are dropped and does not only speak to
> Fragmentation Headers.
> 
> IFF there is interest in more work on general case of Why Operators Filter EHs -
> probably best to keep as separate document.  I think.  I was debating with
> myself as to whether I'd prefer to read it in one single document (here is what's
> measured, here's why EHs are dropped in practice by operators, advice on
> operational practices).  

I'd like to see information about "why" Operators Filter EHs as well, and to what extent each operator in the survey does this.  I don't think that's represented well in any past discussions or documents.  However, that information can't be gathered by just probing to see where they are dropped.  There would have to be significant effort put into tracking down the "why".
I think we all know there is a lot of fear and uncertainty focused around EHs in general.  (Some of it might be warranted, and some not.)  I'm a little apprehensive about drawing conclusions simply based on the fact that filtering exists, without regard to the consideration of why the filtering happens, and who is pushing the filtering.

A more constructive outcome, if a problem exists, would lead to only filtering or whitelisting EHs of specific desired types, and perhaps recommendations of when it is appropriate to filter a specific EH, and then ultimately when it's not appropriate to filter EHs.  

The ultimate question is, should such an effort show that there is a problem, will anything actually be done to try to improve the situation.  If that is not part of the goal, then I have a lot less interest.

Thanks,

- Dan Metzler

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Mar 2015 09:00:45 -0500

Le 27/03/2015 08:49, Metzler, Dan J a écrit :
> I'd like to see information about "why" Operators Filter EHs as well,

I dont work for an Operator, but it is reasonable to expect operators to 
filter Routing Headers.

These are not used by any application and open a signficant security risk.

I personally see it as a valuable feature (RH) for flexibility, yet 
often operators think differently, sometimes to end-user benefit.

Alex

  and to what extent each operator in the survey does this. I
don't think that's represented well in any past discussions or
documents. However, that information can't be gathered by just probing
to see where they are dropped. There would have to be significant effort
put into tracking down the "why".
> I think we all know there is a lot of fear and uncertaintyfocused around EHs in general.  (Some of it might be warranted, and some 
not.)  I'm a little apprehensive about drawing conclusions simply based 
on the fact that filtering exists, without regard to the consideration 
of why the filtering happens, and who is pushing the filtering.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 27 Mar 2015 15:02:01 +0000

>I dont work for an Operator, but it is reasonable to expect operators to

And blocking any new deployment of mobile IPv6 or another one? I guess
that you actually wanted to write RH-0 (RFC 5095) :-)

>These are not used by any application and open a signficant security risk.

For a transit provider which does not need to inspect/parse the EH, the
risk is reduced to well identified threats:
- HbH causing CPU usage (but control plane policing or simply ignoring
them are good mitigation techniques)
- IF a layer-4 ACL is required, THEN indeed EH parsing can cause problem
on some routers.

In short, this topic is of high interest

-éric

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 27 Mar 2015 15:23:49 +0000

And, as I could not refrain from sending some packets from the Internet to
my laptop using the TWC connectivity and packets with EH are actually
dropped by TWC :-O

See below
- RH with a new type => ICMP is generated (disappointing)
- RH with type 0 => dropped (excellent)
- HbH => dropped (excellent)
- Destination Option => dropped (disappointing)

2001:1998:0:8::f the router generating the ICMP (and probably dropping the
other ones) uses an address of TWC ;-)

Sorry Lee :-)

-éric

>>> icmp_data="Test SRH [email-masked]"
>>> 
>>> route=[]
>>> route.append("2001:db8::dead:beef")
>>> route.append(dst)
>>> 
>>> 
>>> 
>>>packet=IPv6(dst=dst,hlim=255)/IPv6ExtHdrRouting(addresses=route,segleft=
>>>0,type=4)/ICMPv6EchoRequest(data=icmp_data,id=RandShort())
>>> sr1(packet,retry=0, timeout=2)
Begin emission:
.Finished to send 1 packets.
...............*
Received 17 packets, got 1 answers, remaining 0 packets
<IPv6  version=6L tc=0L fl=0L plen=120 nh=ICMPv6 hlim=50
src=2001:1998:0:8::f dst=2001:41d0:8:e1a2::1280 |<ICMPv6DestUnreach
type=Destination unreachable code=Communication with destination
administratively prohibited cksum=0x48d7 unused=0x0 |<IPerror6  version=6L
tc=0L fl=0L plen=72 nh=Routing Header hlim=244 src=2001:41d0:8:e1a2::1280
dst=2001:67c:370:152:1610:9fff:fed8:b063 |<IPv6ExtHdrRouting
nh=ICMPv6len=4 type=4 segleft=0 reserved=0L addresses=[
2001:db8::dead:beef, 2001:67c:370:152:1610:9fff:fed8:b063 ]
|<ICMPv6EchoRequest  type=Echo Request code=0 cksum=0x7317 id=0x469
seq=0x0 data='Test SRH [email-masked]' |>>>>>
>>> 
>>> 
>>>packet=IPv6(dst=dst,hlim=255)/IPv6ExtHdrRouting(addresses=route,segleft=
>>>0,type=0)/ICMPv6EchoRequest(data=icmp_data,id=RandShort())
>>> sr1(packet,retry=0, timeout=2)
Begin emission:
Finished to send 1 packets.
Received 287 packets, got 0 answers, remaining 1 packets
>>> 
>>> 
>>>packet=IPv6(dst=dst,hlim=255)/IPv6ExtHdrHopByHop(options=PadN(optdata='A
>>>'*20))/ICMPv6EchoRequest(data=icmp_data,id=RandShort())
>>> sr1(packet,retry=0, timeout=2)
Begin emission:
.Finished to send 1 packets.
Received 443 packets, got 0 answers, remaining 1 packets
>>> 
>>> 
>>>packet=IPv6(dst=dst,hlim=255)/IPv6ExtHdrDestOpt(options=PadN(optdata='A'
>>>*20))/ICMPv6EchoRequest(data=icmp_data,id=RandShort())
>>> sr1(packet,retry=0, timeout=2)
Begin emission:
.....Finished to send 1 packets.
Received 676 packets, got 0 answers, remaining 1 packets

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 27 Mar 2015 19:01:29 +0000

> I dont work for an Operator, but it is reasonable to expect operators to filter Routing Headers.
> 

</chair>

I understand the security risk, I think; that’s discussed in RFC 5095. I’ll note, however, that the RFC doesn’t address “routing headers”; it addresses “routing headers of type 0”. The Segment Routing header is a Routing Header, and trashing all Segment Routing traffic because we have an issue with RH0 traffic seems a trifle extreme.

I get a little antsy is it being filtered by a system other than the one in the destination address or a system acting as a firewall. The operator doesn’t necessarily know what network the address is in, or whether there might be a private arrangement between networks that use his network as transit to communicate. I would want the transit domains to not be applying transitive policy to their customer’s or peer’s traffic without their knowledge.

---

From: George Michaelson <[email-masked]>
Date: Fri, 27 Mar 2015 14:06:03 -0500

On Fri, Mar 27, 2015 at 2:01 PM, Fred Baker (fred) <[email-masked]> wrote:

>
> I get a little antsy is it being filtered by a system other than the one
> in the destination address or a system acting as a firewall. The operator
> doesn’t necessarily know what network the address is in, or whether there
> might be a private arrangement between networks that use his network as
> transit to communicate. I would want the transit domains to not be applying
> transitive policy to their customer’s or peer’s traffic without their
> knowledge.
>

Well said. +1 to sentiment.

That said, the work exposing the risks of EH right now are pretty extreme.
If you release packets into the wild with EH, you can expect significant
packetloss. And its not apparent how you can know in advance the risk.

-G

---

From: Merike Kaeo <[email-masked]>
Date: Thu, 26 Mar 2015 07:43:55 -0700

Sounds good.

- merike

---

From: joel jaeggli <[email-masked]>
Date: Fri, 27 Mar 2015 21:59:31 -0500

yeah understood

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2015 16:22:45 +1300

> I understand the security risk, I think; that’s discussed in RFC 5095. I’ll note, however, that the RFC doesn’t address “routing headers”; it addresses “routing headers of type 0”. The Segment Rout…

This is laid out precisely in RFC 7045*, so you can tell any operator
that trashes all RH packets that they are in violation and the protocol
police are very angry with them.

    Brian

* "The IPv6 Routing Header Types 0 and 1 have been deprecated.  Note
   that Type 0 was deprecated by [RFC5095].  However, this does not mean
   that the IPv6 Routing Header can be unconditionally dropped by
   forwarding nodes.  Packets containing standardised and undeprecated
   Routing Headers SHOULD be forwarded by default.  At the time of
   writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
   experimental Routing Header Types 253 and 254 [RFC4727].  Others may
   be defined in the future."