[ 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, > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
