On 29/06/2013 01:25, Havard Eidnes wrote: > 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.
True, but of course *path* MTU may well be unidirectional, if the forward and reverse paths are different. PMTUD definitely has to allow for asymmetry, which is what counts for fragmentation. Brian > > > 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 <[email protected]> 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
