Subject: Re: draft-carpenter-6man-ext-transmit-01.txt

From: Bill Jouris <[email-masked]>
Date: Sun, 17 Feb 2013 16:05:32 -0800 (PST)

At this point, it seems like the best thing to do is draft two separate proposals: 
1)   list extension headers, and 
2)   a separate one to deal with firewalls and how they deal with extensions.  

That way, we can get the first one thru fairly quickly (it doesn't seem like there is actually much room for controversy there, but that may be naive on my part).  And then focus more narrowly on the second one in the rest of this discussion. 

Bill

> Just to focus on one area at the moment: 
> 
>>> If an extension proves itself safe, easily parse-able, and useful, it
>>> will be transported over the public Internet. If it doesn't, it will get
>>> dropped.
>> At the moment this is impossible. There is no place for firewall
>> implementors to find a master list of all well-defined extension headers
>> and no way for site IT managers to configure firewalls to block or allow
>> specific extension headers. So there is no way for a new extension
>> header to prove itself safe and viable. It's pure Catch 22.
> 
> My personal view is that it is very useful to have a single IANA registry that lists all IPv6 extension headers.  I would like to think I am fairly knowledgable about IPv6, and it's hard for me to find them all.  This is a win independent of what policy we recommend that firewall/middlebox/etc. vendors support.  Let's not loose that.

Indeed. That is one of the two proposals in the draft.

The other proposal is to specify what firewalls should do to make extension
headers deployable (subject to site policy). I think this is complementary to
the oversized-header-chain draft, which is necessary to remove some cases
that are unreasonable for any firewall to handle.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Feb 2013 11:12:49 +0000

Bill,

> 2)   a separate one to deal with firewalls and how they deal with extensions.  

This isn't going to happen before IETF86, because of deadlines. We'll see
whether it's necessary after the next version is discussed.

   Brian