IP Fragmentation Considered Fragile
draft-ietf-intarea-frag-fragile-17

It's very seldom that I ballot Yes on a document for which I'm not the Responsible AD, but this is important enough that I'm doing so; unfortunately there are are some bits which make me uncomfortable though, and so I spent a while in the unusual situation of trying to decide between DISCUSS and YES - after looking at the author list and responsible AD I'm sure that my comments will be considered, and so I'm balloting Yes.


1: "Legacy protocols that depend upon IP fragmentation SHOULD be updated to remove that dependency."
I really don't like the  SHOULD here -- while I fully agree that legacy protocols should be update, the RFC2119 usage feels weird - it's unclear exactly who it is aimed at (everyone? the people who wrote the legacy protocols? some mythical cleanup author?)

2: I'm unclear why IP-in-IP tunnels are called out at the top / in the Introduction. There is a whole section (Packet-in-Packet Encapsulations) where I think it would go better -- I see no harm in having people have to read down to there to note this.

3: "NOTE 2: A non-fragmentable packet can be fragmented at its source. However, it cannot be fragmented by a downstream node.  An IPv4 packet whose DF-bit is set to 0 is fragmentable.  An IPv4 packet whose DF-bit is set to 1 is non-fragmentable.  All IPv6 packets are also non-fragmentable."
I have a few issues with this:
3.1: I'm not really sure a non-fragmentable packet can be fragmented at its source -- the packet *can* be fragmented but I'd say that that is before it has become non-fragmentable. It's entirely possible that I'm missing something obvious here, but a skim of 791 didn't show me what....
3.2: This may be a corner case, but some tunneling gear seems happy to ignore the DF bit when it is doing reassembly on the far side of the tunnel -- the logic seems to be that as long as what goes into the tunnel matches what comes out it doesn't matter what actually happens *inside* the tunnel. 
3.3: Related  to this - most tunneling gear (and many firewalls) allow you to clear the DF bit in packets -- for example, cisco has the 'crypto ipsec df-bit clear' command, Junos allows you to do 'services ipsec-vpn rule myvpn term stomp_on_df then clear-dont-fragment-bit;', iptables lets you 'iptables -t mangle -A POSTROUTING -j DF --clear' 
3.2 and 3.3 are common enough that I think that they deserve mention.

4: What do you mean by middle box in section 6.3?
Yes, I know what is commonly called a middlebox, but I don't know of a good reference -- as an example, I've got some honkin' big routers which do stateless firewall filtering -- these are covered by 3.7, but are they also middleboxes, and if not, why not?! (Note, my personal belief is that they aren't, but I cannot really point to why, other than "I know a middlebox when I see one". 
There is a discussion on some of this in "Why Operators Filter Fragments and What It Implies" (draft-taylor-v6ops-fragdrop-02), but this also uses the term middlebox without defining it.

Nits:
A: Whlie -- While

I also support Alissa’s DISCUSS.

Thank you for this document.  Among other helpful things, it includes
the most clear and memorable description of the distinction between
PMTUD and PLPMTUD that I've heard yet, which I expect I will even be
able to remember for the next time I need it.

Section 2.1

   Each link is constrained by the number of bytes that it can convey in
   a single IP packet.  This constraint is called the link Maximum
   Transmission Unit (MTU).  Whlie the end-to-end Path MTU is the size
   of a single IPv4 header, IPv4 [RFC0791] requires every link to
   support at least a specified MTU (see NOTE 1).  IPv6 [RFC8200]

I don't understand what "the end-to-end Path MTU is the size of a single
IPv4 header" means
nit: s/Whlie/While/ 

Section 3.2

It might be worth another sentence to codify that sending the fragments
of a message to different next hops will end poorly.

Section 3.8.1

   The effect of rate limiting may be severe, as RFC 4443 recommends
   strict rate limiting of IPv6 traffic.

nit: s/IP/ICMP/

Section 4.1

nit: s/User Data Protocol/User Datagram Protocol/

Section 4.2

nit: s/is sufficiently small is sufficiently small/is sufficiently 
small/

Thanks for writing this document! I think this will be a very useful reference also for us ADs!

Also thanks for addressing all the comments of TSVART early review (and thanks for Gorry for this really good and detailed review!). I'm not certain if the following comment from that review was finally resolved. Can you maybe double-check with Gorry:

From Gorry's mail on May 29
">> Section 4.6
>> You may find it useful to check and refer to the following IPv4 specs that relate to the use of fragments:
>> - Please note the recommendation to check details and cite RFC6864 on IPv4 Fragment ID.
>> - Please note the recommendation to check and cite RFC 4787 on NAT handling of IP fragments.
> I'm hard pressed to say what changes you would suggest, or what section you want to see a reference in. To be very honest, a two minute timeout makes a 
> lot of sense in an Internet in which a packet requires a significant portion of a second to transmit; in a megabit-to-gigabit Internet, the corresponding 
> interval is probably measured in seconds or, at most, tens of seconds. In any event, I would want to see data supporting the recommendation.
>
> Please be more specific.

RFC 6864 is in the references - which I think is good. Perhaps a way to resolve my comment would be for section 2.1 to mention IPID and then cite RFC6864. I'd be happy to see more text on this topic, but I suspect it is sufficient to simply ensure the reader is aware that these RFCs impact fragmentation. I was imagining something like this:

The set of IPn fragments comprising a complete IPv4 datagram all carry the same non-zero value in the IPID field. RFC 6848 describes issues relating to the handling of the IPv4 ID field in middleboxes. Section 10 and 11 of RFC 4787 describes best current practice for handling fragmentation in network devices performing Network Address Translation (NAT)."

And one more minor comment:
Se 6.1: "In these cases, the protocol will continue to
   rely on IP fragmentation but should only be used in environments
   where IP fragmentation is known to be supported."
Should this "should" be a "SHOULD"?