Re: draft-carpenter-ext-transmit

[Brian E Carpenter <[e-mail]>]

On 05/11/2012 14:56, Michael Richardson wrote:
> As I understand draft-carpenter-ext-transmit, the goal is to make sure
> that at least firewalls support the list of extension headers we have
> now.  Not all of them were defined in 2460, and so they aren't all
> supported.
> 
> This document basically says we are done defining extension headers, we
> have a definitive list.

No, it carefully doesn't say that. The issue is this: suppose all the firewall
maintainers in the world do the right thing (as defined by Brian Carpenter).
At that moment we will be fine, because they will behave appropriately for
all the currently defined extension headers.

If somebody registers a new extension header after that, the IANA list will
be updated, so all those firewall maintainers should obediently update again.
That's the fantasy part - it would set the barrier for a new extension header
extremely high

> Bob Hinden said that he felt that the list would not grow very much.  
> I think he would have said the same thing about the v4 protocol field in
> 1990, yet we defined lots of new things afterwards.

The same thing *was* said in the early 1990's for IPv4 options - the
network was already opaque to IPv4 options back then, and it still is.
It is annoying that IPv6 is getting into the same situation.

The protocol field as such is a different story with its own inertia.
The problem here is chaining through the extension headers to *find*
the protocol field in the first place. That's what
draft-zhang-6man-offset-option was about, but nobody seemed to like it.

> Brian says that "this is the best we can do", and I conclude he means
> that we are not able demand that standard format extensions headers be
> skipped.

I mean that clarifying what firewalls SHOULD do is the best chance we have to
improve transparency to extension headers. We cannot stop firewalls doing
their job.

> If Brian is saying that this the definitive list of Upper-Layer-Protocol
> values, and that we may have new extensions, but not new ULPs, then
> maybe this is okay.

No, the two things are disjoint. I am only worrying about extension headers
this time around.

Regards
   Brian Carpenter
   Cell phone during IETF85: [phone]