[Int-area] Warren Kumari's Yes on draft-ietf-intarea-frag-fragile-15: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-intarea-frag-fragile-15: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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