Warren, FYI -
#2 - IP-in-IP is the most typical case where a lack of fragmentation support causes problems. This isn’t a rare case; it’s the basis of IPsec tunnels and part of the reason why it’s impractical to simply deprecate this capability. #3 - while it might be worth noting even more devices that are broken, it’s equally worth noting in the same breath that these are broken behaviors. #4 - a middlebox is any device that relays IP packets but violates RFC1812 by modifying parts of the packet beyond the IP header hop count, checksum (IPv4), and certain IP options. It is, almost by definition, a bug “in the flesh”. Joe > On Aug 7, 2019, at 2:58 PM, Warren Kumari via Datatracker <[email protected]> > wrote: > > 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 > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
