Ran and others,
For the case of non-fragmented packets, use of the full 5 input
parameters ought to be mandated.
For the case of fragmented packets, use of reduced inputs that
are available in the IPv6 header alone should be permitted
as an option for implementers.
I think you are making it easier than it really is.
Here's the problem.
The first packet arrives and its small. The router can read the 5-tuple.
All fine so far. Picking
flowid = f(5-tuple)
The next packet arrives, only this time it is fragmented. The router
cannot read the 5-tuple from all fragments. Now, what is the router
supposed to do? Here are its options:
1. Reassemble to find the 5-tuple information. All is fine, except that
its a heavy implementation burden (and a DoS vulnerability).
2. Revert to using 2-tuple for the fragmented packet:
flowid' = f(2-tuple)
Now flowid != flowid' This is really bad, as it means that a normal
packet and a fragmented packet for the same flow would have different
flowids, and might take different routes, be re-ordered, etc.
3. Do some magic matching of fragment identifiers. Again, we can find
the 5-tuple, but now the router has to remember per-session state
(another DoS vulnerability).
Or am I missing something? I think the first-hop router has to set the
flowid in every packet of the flow, doesn't it?
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
