Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC

[Havard Eidnes <[e-mail]>]

Some perhaps non-nit comments (I sent the nits privately):

Under section 2.1, Possible Causes:

   Some filtering and dropping of fragments is known to be done for
   hardware, performance, or topological considerations.

That's quite vague, I think it could stand with some more details.


The entire section 2.1.1. "Stateful inspection" is about problems with
resource exhaustion in middleboxes or end-system firewalls.
Implementations which willingly devote unlimited resources to fragment
reassembly display a severe lack robustness, and IMHO should not be
used as justification for why we can't use fragments.  Yes, I'm
suggesting that one can forego the specified 60s fragmentation
reassembly timeout in the case of resource shortage of a fixed pool.


Under section 2.1.2. Stateless ACLs:

   Stateless load balancing schemes may
   hash fragmented datagrams from the same flow to different paths
   because the 5-tuple may be available on only the initial fragment.
   While rehashing has the possibility of reordering packets in ISP
   cores it is not disastrous.  However, in front of a stateful
   inspection device, load balancer tier, or anycast service instance,
   where headers other than the L3 header -- for example, the L4 header,
   interface index (for traffic already rehashed onto different paths),
   DS fields -- are considered as part of the hash, rehashing may result
   in the fragments being delivered to different end-systems

AFAIK the use of a 5-tuple which includes the L4 header to compute a
hash to make a forwarding decisions among otherwise equal paths is an
implementation optimization only, it is not something which is
explicitly prescribed by our standards.  Therefore, I'll claim that
applying this logic to fragments, causing packet delivery to different
hosts for initial and subsequent fragments (e.g. in the case of a load
balancer) is an incorrectly applied optimization, also known as a bug.


Under section 2.1.3. Performance considerations

   Leaving aside these incentives towards fragment dropping, other
   considerations may weigh on the operator's mind.  One example cited
   on the NANOG list was that of a router where fragment processing was
   done by the control plane processor rather than in the forwarding
   plane hardware, with a consequent hit on performance.

Is this about traffic directed at the one of the local addresses of
the router?  "Of course", one needs to be careful about letting
fragments from anywhere from passing into the data-plane / control-
plane bottleneck (but you could conceivably allow fragments from a
small controllable subset, e.g. your iBGP neighbors etc.)  The impact
of having limited ability to send fragments from any source to the
routers should be minimal, if noticeable at all.

Or is this about traffic passing through the router?  If so, doesn't
that discussion belong under section 2.1.2?


In section 2.1.4. Other considerations you say:

   It is common practice [RFC6192] to recommend that control-plane
   ACLs protecting routers and network devices be configured to drop
   all fragments.

Well, there exists an informational RFC [6192] which contains an
example policy and also some detailed discussion about handling of
fragments.  I don't think it in sum says what is said here, though.


Best regards,

- Håvard