Extension headers and firewalls

Cameron Byrne cb.list6 at gmail.com
Sun Jul 22 18:08:26 CEST 2012

On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> hang on - Cameron's statement is ambiguous.
> Does it mean "firewalls blocking legal extension headers should be deprecated"
> or "hosts sending legal extension headers should be deprecated"?

The latter.

Per RFC 2460, firewalls and routers should not be processing extension
headers.  I believe this is also a good case study in what the IETF
can specify and what industry will deliver and use.

To be clear, I do not see any value is carrying forward the path for
more functionality at the internet layer.  The internet layer should
just move packets from A to B (hour glass model, e2e model, ....).
Upper layers are better at handling the things extension headers were
trying to do (mobility, e2e security, max segment size / fragment /
path mtu...).

The solution (extension headers) has not yet found it's problem in 10+
years.  In the meantime, it has created a great deal of confusion.
And now, you have people reading RFC 2460, they think they understand
IPv6, and then go to find out that so much text in 2460 to describe
extension headers is not a reality on the internet.

The intent of 2460 was good, but it did not match the trajectory of
the internet with regards application functionality, security policy,
and packet forwarding architectures evolved.


> One of the problems here, as was mentioned on an IETF list quite recently,
> is that RFC 2460 specifies behaviour *only* for the extension headers
> defined in RFC 2460, and there is no clear list in any RFC or at IANA
> of the current set of legal extension headers. Firewall implementers
> seem to go by RFC 2460 alone.
> This is a gap that needs to be filled by the IETF (imho).
>     Brian
> On 22/07/2012 01:09, Jared Mauch wrote:
>> You might find a lot of support for this I suspect.
>> Jared Mauch
>> On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
>>> Perhaps this functionality should be officially depricated.
>>> CB

More information about the ipv6-ops mailing list