Subject: Companion to RFC 7045 for options (was: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt)

From: "C. M. Heard" <[email-masked]>
Date: Fri, 22 Aug 2014 07:39:59 -0700 (PDT)

[ 6man added to cc: list ]

Fernando, I would have to agree that there is a need for a 
standards-track document doing for options what RFC 7045 did for 
extension headers.  The current rules in RFC 2460 for intermediate 
systems are:

(a) Inspect options in a hop-by-hop options header; process known 
options as specified in the document defining the option, otherwise 
take the action indicated in the upper two bits of the option code.

(b) Pass destination options transparently; do not inspect them or 
filter packets based on them.

There really aren't any provisions for intermediate systems to 
filter IPv6 packets on the basis of the options they contain.  That 
is not consonant with oft-repeated operational requirements.  The 
new document that you propose would need to provide for such 
filtering.  When that is done, the above rules are (IMHO) a 
reasonable starting point for deault behavior, modulo refinements 
such as discarding packets with options that appear in the wrong 
kind of options header.

Mike Heard

On Fri, 22 Aug 2014, Fernando Gont wrote:
> On 08/21/2014 12:57 PM, C. M. Heard wrote:
> > 
> > For one thing, I think you agreed that the advice should be to 
> > discard packets with options that appear in the wrong kind of 
> > options header. 
> 
> After giving this one some thought, I'd say that my take is that the
> best option is to produce a 6man document that specifies the default
> processing of options, such that we complement RFC7045 (which does that
> for IPv6 extension headers). -- this had been suggested by Brian
> Carpenter already.
> 
> After all, advice of the kind "Drop this packet if it contains two
> Router Alert options is really a default setting, rather than something
> an operator would configure".
> 
> In the worst case scenario (if the 6man document doesn't fly there, we
> may incorporate such defaults in this document).
> 
> Thoughts?
> 
> Thanks!
> 
> Best regards,
>