This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/

[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

sthaug at nethelp.no sthaug at nethelp.no
Fri Jun 19 09:39:11 CEST 2015

> >> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).
> > 
> > It would certainly make *me* happier$,1s&(B
> 
> done.
> RFC7112.

As I wrote in another mail,

> It may be relevant to ask for RFC 7112 support next time we're doing
> an equipment RFQ (in a few years).
...
> But until RFC 7112 support is available, I believe we will
> see a significant amount of breakage for IPv6 extension headers - and
> header chains will be limited to significantly less than 1280 bytes.

And until such support is available, we have to deal with the current
mess. Which may imply more filtering than some people would like.

Steinar Haug, AS 2116

Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[ ipv6-wg Archives ]