Subject: Re: [v6ops] IPv6 Extension Headers in the Real World

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 08:00:44 +1300

fwiw I think this is very useful information and should be polished
and published. I have no strong opinion whether it should be published
via v6ops or as an Independent Submission RFC.

Regards
   Brian

On 30/09/2014 17:50, Fernando Gont wrote:
> Folks,
> 
> Earlier in September we published a revision of our I-D "IPv6 Extension
> Headers in the Real World"
> (<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world>).
> 
> At this point in time, we're interested in knowing whether our I-D is of
> value for the IPv6 ops community, such that we can decide whether to
> continue working/improving it. Additionally, if there's anything you
> think we've missed in the document, we'd like to hear from you.
> 
> Overall, our I-D is meant to provide a reality-check with respect to the
> issues surrounding IPv6 Extension Headers and their use on the public
> Internet. More specifically, its goals are:
> 
> 1) Provide data regarding support of IPv6 EHs in the real world.
> 
>     This is interesting data to refer people to (e.g., folks
>     developing protocols) regarding the extent to which IPv6 EHs
>     are usable on the public Internet (at least with web, mail, and
>     name servers).
> 
> 
> 2) Summarize the issues associated with IPv6 EHs (performance, security,
> etc.)
> 
>     This is of use for folks concerned with the issues surrounding
>     IPv6 EHs, and covers practical issues.
> 
> 
> 3) Summarizes the implications of the aforementioned filtering.
> 
>     For example, if you're designing a protocol that is meant to
>     work on the public Internet, you may want to provide some fall-back
>     mechanism that does not employ IPv6 EHs.
> 
>     Yet another of the implications is the security issue that has
>     been discussed on-list: if e.g. IPv6 fragments are dropped and you
>     can be tricked into generating them, you may be subject to a DoS
>     attack.
> 
> 
> 4) Flag possible further work
> 
>    Here we try to flag areas where the further work may be needed,
>    such as adding fall-back mechanisms to some existing protocols,
>    or avoiding the use of IPv6 EHs where possible.
> 
> 
> Thanks!
> 
> Best regards,

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Oct 2014 16:33:30 -0400

On Tue, Sep 30, 2014 at 12:50 AM, Fernando Gont <[email-masked]> wrote:
> continue working/improving it.

Yes please!

Burying our heads in the sand and pretending that they all work fine
in no way helps with V6 deployment.

Having users and operators get burnt because they didn't know about
issues with EH simply leads to people turning off v6 - once bitten,
twice shy...

W

>  Additionally, if there's anything you
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
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: Merike Kaeo <[email-masked]>
Date: Wed, 1 Oct 2014 13:40:53 -0700

On Oct 1, 2014, at 1:33 PM, Warren Kumari <[email-masked]> wrote:

> twice shy…

Might I may a recommendation to also include IPsec wg for some of this discussion and/or mobility
groups.  They are the *only* EH that I know that in the real world might actually be used.  Most
specifically the RH EH Type2 that's used in mobile environments and then the AH/ESP for IPsec.

You may want reach *customers* who are not necessarily 'operators' who are utilizing the EHs.

Just a suggestion :)  The biggest PITA for all vendors are EH….it's my litmus test for all vendors
to see if they REALLY have an IPv6 implementation.  

Caveat - I haven't kept up with this work….will try and read latest draft in next few days

- merike

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Oct 2014 15:35:35 -0700

There is no need for multiple documents on this topic. This information
should be rolled into draft-gont-opsec-ipv6-eh-filtering-02

Joe

---

From: Tim Chown <[email-masked]>
Date: Wed, 1 Oct 2014 23:44:43 +0100

I'd argue a separate  'problem statement' is a better approach.

--
Tim

> On 1 Oct 2014, at 23:35, Joe Touch <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Oct 2014 15:52:05 -0700

> I'd argue a separate  'problem statement' is a better approach.

If the IETF were developing a new protocol, yes.

But in this case we have operational observations and operational
recommendations. The two are tightly coupled; the latter makes no sense
without the former anyway.

I don't see "here's what I saw" and "here's what to do about it" as
separately useful.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 01 Oct 2014 23:10:03 -0700

> I don't see "here's what I saw" and "here's what to do about it" as

+1

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Oct 2014 20:30:27 +0900

> I don't see "here's what I saw" and "here's what to do about it" as

In theory having separate documents is useless.

In practice having separate documents is extremely useful, because it turns
out that it's much easier to agree on "here's what I saw" than on "here's
what to do about it". In a consensus-oriented body like the IETF, there's
no output until people agree, so attempting to document both a problem and
a solution at the same time can take months or even years longer than
documenting the two separately.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 2 Oct 2014 11:51:50 +0000

I would think that if it’s much easier to agree on “here’s what I saw”, then it would work better if the first draft includes the problem statement, and then later drafts flesh out “here’s what to do about it”.  Even in practice, simply agreeing on the nature of the problem, is of limited value without the knowledge of solutions, or even the knowledge that a solution may not exist yet.  Even if there are multiple solutions to a problem, it is always important to state the problem that each solution is designed to solve when presenting any solution.

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, October 2, 2014 6:30 AM
To: Joe Touch
Cc: [email-masked]; V6ops Chairs; IPv6 Operations; Fernando Gont
Subject: Re: [v6ops] IPv6 Extension Headers in the Real World

On Thu, Oct 2, 2014 at 7:52 AM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
I don't see "here's what I saw" and "here's what to do about it" as
separately useful.

In practice having separate documents is extremely useful, because it turns out that it's much easier to agree on "here's what I saw" than on "here's what to do about it". In a consensus-oriented body like the IETF, there's no output until people agree, so attempting to document both a problem and a solution at the same time can take months or even years longer than documenting the two separately.

---

From: Tim Chown <[email-masked]>
Date: Thu, 2 Oct 2014 14:13:03 +0100

> I would think that if it’s much easier to agree on “here’s what I saw”, then it would work better if the first draft includes the problem statement, and then later drafts flesh out “here’s what to…

Indeed. As an author of the ‘what I saw’ it seems appropriate to document an issue that others can discuss and decide what action(s) to take.  

So separation of authorship is one thing.

Another is that there might be multiple ‘here’s what to do about it’ documents, as there have been with other operational problem statements. There might be Informational or BCP documents in v6ops suggesting mitigation methods, and/or there might be protocol changes through 6man.

Tim

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2014 08:03:54 -0700

You all might consider that "what to do about it" is already being
proposed as a WG doc in OPSEC.

So I disagree with the entire logic of the idea of sequential
publication in this case. It only opens up continued need for
coordination between WGs.

Joe

On 10/2/2014 6:13 AM, Tim Chown wrote:
> On 2 Oct 2014, at 12:51, Metzler, Dan J <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> I would think that if it’s much easier to agree on “here’s what I
>> saw”, then it would work better if the first draft includes the
>> problem statement, and then later drafts flesh out “here’s what to do
>> about it”.  Even in practice, simply agreeing on the nature of the
>> problem, is of limited value without the knowledge of solutions, or
>> even the knowledge that a solution may not exist yet.  Even if there
>> are multiple solutions to a problem, it is always important to state
>> the problem that each solution is designed to solve when presenting
>> any solution.
>>
> 
> Indeed. As an author of the ‘what I saw’ it seems appropriate to
> document an issue that others can discuss and decide what action(s) to
> take.  
> 
> Another is that there might be multiple ‘here’s what to do about it’
> documents, as there have been with other operational problem statements.
> There might be Informational or BCP documents in v6ops suggesting
> mitigation methods, and/or there might be protocol changes through 6man.
> 
> Tim

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Oct 2014 17:27:03 +0000

On Oct 2, 2014, at 8:03 AM, Joe Touch <[email-masked]> wrote:

> So I disagree with the entire logic of the idea of sequential publication in this case. It only opens up continued need for coordination between WGs.

One solution to that would be to discuss both documents in the same working group. I’m open as to which.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 3 Oct 2014 09:33:45 +0000

I think perhaps I was a bit vague in my previous email, so just to clarify my point.

I would point out that my comments below imply that there is only one document under consideration for both "here's what I saw" and "here's what to do about it".
The problem statement and the solution are still presented in the same document.  "If" a problem statement or "here's what I saw" is presented in a separate document without a solution, purely for the sake of agreeing on the problem in a short period of time, typically I would expect another draft of the document to come along later with both "here's what I saw" and "here's what to do about it", and replace the previous one; not that you would maintain the two in separate documents.

The idea that there might be a document under discussion in two separate WGs at the same time is really a separate discussion, and it's based purely the idea that two WGs are considering the same problem that determines the need for coordination between WGs; not the number of iterations (drafts) of a document.  I would hope that cooperation or coordination between WGs would happen just because it makes sense when you're both considering solutions to the same problem.  That's true regardless of how many drafts are created.

Thanks,

- Dan

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 2, 2014 10:04 AM
> To: Tim Chown; Metzler, Dan J
> Cc: Lorenzo Colitti; [email-masked];
> V6ops Chairs; IPv6 Operations; Fernando Gont
> You all might consider that "what to do about it" is already being proposed
> as a WG doc in OPSEC.
> 
> So I disagree with the entire logic of the idea of sequential publication in this
> case. It only opens up continued need for coordination between WGs.
> 
> Joe
> 
> >> I would think that if it's much easier to agree on "here's what I
> >> saw", then it would work better if the first draft includes the
> >> problem statement, and then later drafts flesh out "here's what to do
> >> about it".  Even in practice, simply agreeing on the nature of the
> > Indeed. As an author of the 'what I saw' it seems appropriate to
> > Another is that there might be multiple 'here's what to do about it'

---

From: Fernando Gont <[email-masked]>
Date: Fri, 03 Oct 2014 11:17:19 -0300

Hi, Dan,

On 10/03/2014 06:33 AM, Metzler, Dan J wrote:
> I would point out that my comments below imply that there is only one
> document under consideration for both "here's what I saw" and "here's
> what to do about it".

Just for clarification's sake: One might be tempted to assume that one
should/can codify the "here is what I saw" into the same document as the
"here is what to do about it" because the former is simply the "problem
statement" which will be addressed by the later.

However, I'm of the idea that that is an over-expectation.

> The problem statement and the solution are
> still presented in the same document.  "If" a problem statement or
> "here's what I saw" is presented in a separate document without a
> solution, purely for the sake of agreeing on the problem in a short
> period of time, typically I would expect another draft of the
> document to come along later with both "here's what I saw" and
> "here's what to do about it", and replace the previous one; not that
> you would maintain the two in separate documents.

The advice on filtering need not relate into a solution to the "here is
what I saw". For instance, I'm of the idea that if you want your
protocol to be able to work on the public Internet, it must be able to
operate without IPv6 EHs. IMO, I see the advice on filtering as
something "necessary, but not sufficient", if you want.

The advice on filtering is one of the action items resulting from the
"here's what we saw". But as noted on our I-D, there should be others,
like the IETF looking at which protocols rely on IPv6 EHs, and making
sure they can still work in the presence of packet filtering.

And you certainly do not want the "here's what we saw", "here's how we'd
like you to filter packets with EHs", "here's what the IETF should
consider when designing new protocols", because they tend to be rather
orthogonal, and also targeted at different communities.  -- the guy
doing the packet filtering is likely different from the guy developing
new protocols, etc.

> The idea that there might be a document under discussion in two
> separate WGs at the same time is really a separate discussion, and
> it's based purely the idea that two WGs are considering the same
> problem that determines the need for coordination between WGs; not
> the number of iterations (drafts) of a document.  I would hope that
> cooperation or coordination between WGs would happen just because it
> makes sense when you're both considering solutions to the same
> problem.  That's true regardless of how many drafts are created.

FWIW, I think that each of the related documents is clearly scoped. And
while it's nice to announce a document in all the relevant wgs, one can
always note that "discussion is expected to happen at this or that wg".
There have been so many instances of documents that might have happened
at two or three different wgs, and I don't think there has been a need
for "special coordination" among them -- but I guess I might be wrong.

Thanks!

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2014 11:53:46 -0700

> doing the packet filtering is likely different from the guy developing

The coupling of these determines how you act. It determines whether you
can filter safely, only when under threat or in a particular
environment, or should not filter under any circumstances.

And that's why it's dangerous to split these out. These should not be
targeted at different communities without a single, coherent context of
both what is known to happen, what the risks are, and the recommendations.

Ultimately, we need an Internet whose behavior is coherent, not based on
potentially interfering communities perceived as being orthogonal.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 03 Oct 2014 16:03:21 -0300

> environment, or should not filter under any circumstances.

Have you checked the eh-filtering I-D
(drfat-gont-opsec-ipv6-eh-filtering)? Because it has all that analysis
in the document itself

> both what is known to happen, what the risks are, and the recommendations.

That's all in one I-D. OTOH, the I-D of the subject line is about
empirical observations.

> potentially interfering communities perceived as being orthogonal.

You want have coherent Internet, because even when we can provide
advice, at the end of the day its each operator's business what they do
with their own network. -- in the same way that some networks break
PMTUD, while others don't.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Sun, 5 Oct 2014 14:01:19 +0100

> both what is known to happen, what the risks are, and the recommendations.

And I think it works the other way - it’s cleaner to express an observation or problem statement, and then leave the community to decide what action, if any, to take. At the very least here there’s a clear warning sign about expectations for the successful transport of IPv6 packets using EHs, end to end.

There’s many examples of IETF problem statements documented independently of solutions/BCP/informational guidance.

> potentially interfering communities perceived as being orthogonal.

Perhaps better to say communities with different perspectives. But your choice language makes a point.

RFC7045 is good in my view, but is not yet where we are at. Part of that is a default filtering setting by the vendor community. Vendors also have a part to play in how EHs are handled in general, e.g. the observations are that longer EH chains lead to more drops.

And there is an operational community aspect from how default settings may be changed, or set in a way that may cause problems. There’s many sites who don’t follow RFC4890 for example, whatever the defaults provided by vendors might be.

And there’s a community that designs new protocols that might choose to use EHs. While the sfc WG has made it clear that any use of EHs there is within a constrained/limited environment (and not across the Internet at large), perhaps others are taking a more hopeful view…

But the point remains, documenting the observations/problem independently allows discussion in those other communities - vendors, operators and protocol designers - without trying to pre-empt that in a single document. I’m not saying there’s a right or a wrong way, but I think it’s better to be able to take stock from a clean problem statement/set of observations, than try to do everything in one go.

It’s a shame the IETF91 BoF cutoff just went by - a non WG-forming BoF might have been a good way to tease these issues out. 

Tim

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Oct 2014 08:27:29 -0700

> On 3 Oct 2014, at 19:53, Joe Touch <[email-masked]> wrote:
...
> RFC7045 is good in my view, but is not yet where we are at. 

Which raises an additional point. The ink on that is barely dry. What
changed that warrants looking at this again so soon? BOTH docs ought to
address that (this doc mentions that RFC only in passing in the intro,

...
> But the point remains, documenting the observations/problem
> independently allows discussion in those other communities - vendors,
> operators and protocol designers - without trying to pre-empt that in a
> single document. I’m not saying there’s a right or a wrong way, but I
> think it’s better to be able to take stock from a clean problem
> statement/set of observations, than try to do everything in one go.

That ship sailed with RFC7045.

Right now, we're not talking about a hypothetical sequence of docs.
We're talking about operational recommendations that have already been
offered as a WG doc in OPSEC a few weeks ago this AND now this doc in V6OPS.

> It’s a shame the IETF91 BoF cutoff just went by - a non WG-forming
> BoF might have been a good way to tease these issues out.

The only people who really need to be at that meeting right now are the
ADs and chairs of OPSEC and V6OPS.

Although I appreciate that everyone thinks that "this can be
coordinated", we're seeing ample evidence to the contrary. It's useful
to note here that NEITHER DOC REFERENCES THE OTHER, despite being
written by the same author (which begs the question of "end run").

If this is left to the WGs, then the WGs need to decide if they can
manage each of these documents in the isolation the context that already
has been allowed to exist and is already promoted by the author - or if
that can *only* happen in a single doc.

Joe

---

From: Jen Linkova <[email-masked]>
Date: Thu, 2 Oct 2014 01:02:43 +0200

> should be rolled into draft-gont-opsec-ipv6-eh-filtering-02

I agree that those two documents d overlap - especially in the section
of ipv6-ehs-in-real-world  which discusses the security implication of
filtering (I believe it's a very good idea to add either such section
or a reference to this draft to opsec-ipv6-eh-filtering-02). I'm not
so sure if both documents should be merged as one is documenting the
operational experience and the current situation while another one is
providing some recommendations.

-- 
sincerely yours,
Jen Linkova a.k.a Furry
Network Engineer
Brandschenkestrasse 110, 8002 Zurich, Switzerland
Company Identifikationsnummer: CH-020.4.028.116-1
This email can contain confidential information.If you received this
email by mistake, do not pass it to third parties and delete all
copies and enclosures, and let us know that it has been delivered to
wrong address. Thank you.

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Oct 2014 08:44:38 -0700

On 10/6/2014 8:27 AM, Joe Touch wrote:
...
> written by the same author (which begs the question of "end run").

Correction: the latest OPSEC doc does cite the V6OPS one in a throw-away
sentence of the intro, but fails to explain in detail how the two docs
are linked.

(it also cites "recent studies" - plural - even though only the authors'
own study is the only one cited)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Oct 2014 15:28:22 -0300

> written by the same author (which begs the question of "end run").

Joe, if you feel like making an ad-hominem accusation, at the very least
state what the basis of your accusations are. This is not the first time
you do it. Last recent one was based on seconding Fred Baker's claim
that I had requested adoption of this document to two set of wg chairs
-- which was simply *not true*. Making such assertions in public, based
on your own personal assumption's (or someone else's) (and without
apologizing in those cases where it is easy to prove that something
wasn't true), does not seem like a good way forward or even fair.

That said, there are different sets of authors in each doc that you
mentioned. I happen to be a co-author of all such documents. But I'm not
"the author". If you think that one document should reference another,
but did not, maybe it was just an error? Maybe when writing the I-D, the
other document had not yet been written? Maybe something else other than
a conspiracy theory?

If you infer some sort of Machiavellian plan regarding this document, I
just say "there isn't any". If you wonder, this is how each I-D was born:

the eh-filtering I-D is simply an IPv6 version of RFC7126. We got
RFC7126 done, and the IPv6 part was missing. That's how this I-D was born.

OTOH, draft-gont-v6ops-ipv6-ehs-in-real-world was born (later) when
trying to codify and summarize what we had been discussing at the IEPG
meetings (for more than a year now).

> that can *only* happen in a single doc.

As noted quite a few times, there have been many cases where there's has
been overlap among wg groups. For instance, anything that has to do with
ipv6 opsec can fit either v6ops or opsec. I personally don't see that as
a problem.

Thanks,