Brian E Carpenter <brian.e.carpen...@gmail.com> 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.
BC> No, it carefully doesn't say that. The issue is this: suppose
BC> all the firewall maintainers in the world do the right thing (as
BC> defined by Brian Carpenter). At that moment we will be fine,
BC> because they will behave appropriately for all the currently
BC> defined extension headers.
Yes, I got that.
BC> If somebody registers a new extension header after that, the
BC> IANA list will be updated, so all those firewall maintainers
BC> should obediently update again. That's the fantasy part - it
BC> would set the barrier for a new extension header extremely high
Right, which is why I claim that this document is essentially saying we
are done. Like Lorenzo, I wanted to know why firewalls can't skip
extension headers they do not understand.
The issue, as I understand it, is that some of things are not extension
headers with TLV, but are upper-level-protocols, and the firewalls
can't know which ones are ULPs and which ones are TLV-format extension
headers.
So, what I think this document does it acknowledge that we are a state
of "barrier for new extension extremely high", and make sure that in
fact that list is accurate and authoritative.
--
Michael Richardson
-on the road-
pgpFQF4q66aPg.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
