On Mon, Nov 03, 2014 at 02:38:23PM -0800, Jarno Rajahalme wrote: > > On Nov 3, 2014, at 2:03 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Wed, Oct 29, 2014 at 03:12:02PM -0700, Jarno Rajahalme wrote: > >> 1. Flows with an explicit match on nw_frag, where the LATER bit is 1: > >> Prohibit setting transport header fields (port numbers) with > >> set_field or move, or using such a field as a source in a move. > >> > >> 2. Flows that wildcard the nw_frag LATER bit: At flow translation > >> time, detect the fact that the packet/flow has no transport header, > >> and (silently) do nothing when translating a set_field, set_tp_src, > >> set_tp_dst, or reg_move action that reads or writes on transport > >> headers. nw_frag is exact matched, so non-LATER packets deal with > >> the transport ports as before. > >> > >> 2. alone would suffice for correct behavior, but 1. seems like a right > >> thing to do, anyway. > >> > >> Finally, we add tests testing the new behavior. > >> > >> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > > > > The subject line is much too long. Break it after the first sentence? > > > > Oops. Will do. > > > I think that this new constraint is really just a refinement of the > > prerequisites for MFP_TCP, MFP_UDP, and MFP_SCTP, so I would expect > > mf_are_prereqs_ok() to change instead of mf_check__(). > > > > OK. > > > In IPv6, even the first fragment is not guaranteed to carry the > > transport port. Have you had any thoughts about how to handle IPv6? > > Not yet :-) Looking at the documentation of OFPC_FRAG_NX_MATCH: > > * - OFPC_FRAG_NX_MATCH (a Nicira extension): Similar to > OFPC_FRAG_NORMAL, > * except that TCP and UDP port numbers should be included in fragments > * with offset 0. > > It seems that the only way to implement this mode with IPv6 is to drop > fragments of TCP/UDP/SCTP packet that have 0 offset, but do not contain the > transport header port numbers. I?m not aware of legitimate traffic that would > be harmed by this. > > Thoughts?
I guess that we should start with your patch and worry about IPv6 later. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
