Extension headers and firewalls

[Cameron Byrne]

On Jul 22, 2012 9:25 AM, "Brian E Carpenter" <brian.e.carpenter at gmail.com>
wrote:
>
> On 22/07/2012 17:08, Cameron Byrne wrote:
> > 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.
>
> Except for HbH options (which I think we can agree are a mistake)
> forwarding boxes are supposed to *ignore* extension headers. They
> aren't supposed to *discard* them.
>

Agreed, that is what the rfc says.

But implementers have explicitly choosen that they will not ignore them for
the reasons i explained below. Also alluded to below is the limited role of
the ietf.

More generally, industry will not make any changes without business
justification and will not make security or performance trade offs for the
sake of an rfc. This is only my observation of the emergent evolution of
the internet technologies.

Internet evolution (critcal mass of implementers) has selected 128 bit
addresses.

Just like evolution of humans has selected bipedalism and not tails.

CB

>     Brain
>
> 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.
> >
> > CB
> >
> >
> >> 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
> >>>>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120722/cf1afe6c/attachment.html