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 ]
Brian E Carpenter
brian.e.carpenter at gmail.com
Wed Jun 17 03:24:03 CEST 2015
On 17/06/2015 07:02, Jen Linkova wrote: ... > (shameless plug) a group of enthusiasts have just submitted a new > version of document which discusses exactly this problem: > > https://tools.ietf.org/html/draft-wkumari-long-headers-03 > > Comments are appreciated... In REQ-2 on HbH headers, you say: > The forwarder MUST > process each option as specified in Section 4.2 of [RFC2460]. That aspect of RFC 2460 was fundamentally changed by RFC 7045. And of course this is the issue addressed by draft-baker-6man-hbh-header-handling. Personally I still think RFC 7045 is the most realistic on this point, but Fred would like things to get better ;-). I'm sure other things in the long-headers draft need revising as a result of RFC 7045, since its whole topic is the handling of extension headers ("This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.") Y'all also need to take account of RFC 7112, which forbids fragmented header chains. Brian
- 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 ]