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

[Tim Chown <[e-mail]>]

On 3 Oct 2014, at 19:53, Joe Touch <[e-mail]> wrote:

> On 10/3/2014 7:17 AM, Fernando Gont wrote:
>> 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 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.

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.

> Ultimately, we need an Internet whose behavior is coherent, not based on
> 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