draft-bonica-6man-frag-deprecate

[Havard Eidnes <[e-mail]>]

Hi,

some comments from this corner, some small, some not so...:


In section 1:

   MTU is a unidirectional metric.  A bidirectional link may be
   characterized by one MTU in the forward direction and another
   MTU in the reverse direction.

I'm sure this is formally true.  However, in practice, I have
never seen a router where you can separately configure the
receive and transmit MTU.  So ... I would remove this altogether;
it may otherwise pave the way for unsuspecting individuals
reading this to create a path MTU discovery black hole by
configuring inconsistent MTUs for devices on the same link.


In section 2.1:

   [Kent87] points out that the reassembly process is resource
   intensive.  It consumes significant compute and memory resources.

Is that argument still valid today?  Is it impossible to engineer an
implementaiton which restricts the memory consumption in order to
improve robustness of the implementation?


Section 2.2 states "Fragmentation Is Rare".  I think this will be
hihgly dependent on your choice of observation points.  E.g. in the
vicinity of an NFS server serving using UDP, I would not be
surprised to see a lot of fragments.  And, as has been mentioned
elsewhere in this discussion, in the vicinity of a DNSSEC-validating
recursive DNS resolver, you would expect to see an increasing
proportion of fragmented UDP traffic as DNSSEC deployment
progresses.


In section 2.2.1, the document appears to dismiss the DNSSEC use of
UDP and fragmentation with "use TCP instead".  I beleive Mark
Andrews in <[e-mail]> stated why
this is far from good enough as an answer.  In addition to TCP PMTUD
being too slow, you have the issue that TCP in general is about 3
times slower than UDP in delivering a DNS response even if PMTUD is
not involved -- I beleive RIPE NCC Labs did a test using their "RIPE
Atlas" probes to check for this, and they came up with 2.5x - 3x as
the slowdown factor.  Additionally there is the vastly increased
need to keep state in DNS name servers by the TCP load which would
result from the abolishment of UDP as a transport for DNS.

On top of this, there is the argument that "firewalls and network
operators may filter DNS over TCP", but I would not use that as an
argument because I consider it invalid -- more on that below.


Section 2.3, "Attack vectors".  Isn't this whole section giving bad
excuses to IP stack implementors for not providing a robust and
well-tested implementation?!?  BTW, I'm wondering whether there is a
spec issue lurking within this area, wrt. invalidating the most
obscure corner cases?


Section 2.4, "Operator behavior".  It is claimed that IPv6 fragments
are being dropped in several places, e.g. by enterprise firewalls or
other environments who want to tightly control what traffic is
passed.  I claim that is's a matter of principle whether we let the
tail wag the dog.  Firewall administrators or other users of the
network may do unwise things when configuring their device, but
should such behaviour be allowed to restrict what becomes
standardized?!?  If that were the case, we might as well all
restrict ourselves to speaking TCP over port 80.


Section 3, "Recommendation".  I question whether you can in fact
make the backward-incompatible change of getting rid of the need for
implementations to support fragment reassembly -- the genie is
already out of the bottle -- has been for quite a while, and I claim
it's already too late to try to put it back in.  So some of the
claimed attack vectors in section 2.3 will also be difficult to get
rid of, as hosts will in all probability have to continue to support
fragment reassembly for quite a while.

At the very least, there's a need to separate the recommendations
for "sending fragments" and "support reception of fragments".


Best regards,

- Håvard