[Int-area] draft-bonica-intarea-frag-fragile-01

[C. M. Heard]

Draft authors,

Thanks for putting this draft together.

*Major comments*:

In Section 5.1, Transport Layer Solutions, please note that there is work
in progress on fragmentation at the UDP layer and cite
draft-ietf-tsvwg-udp-options
<https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options>.

In Section 6.1, DNS, please note that draft-ietf-tsvwg-udp-options
<https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options> may offer
an *incrementally
deployable* solution to the problem of oversize DNS responses. As far as I
know, this specific use case is not yet documented in any I-D, but the
basic idea is that a client would indicate its willingness to accept a
UDP-fragmented response by including in its (unfragmented) request a UDP
options trailer with the FRAG option as specified on page-15
<https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-02#page-15>
of draft-ietf-tsvwg-udp-options.
A server that does not implemented UDP options would ignore the options
trailer and use IP-layer fragmentation for large responses; a server that
implements UDP options would use UDP-layer fragmentation for large
responses.

*Minor Comments*:

Section 2.2, Upper-layer Protocols, says:

Upper-layer protocols can operate in the following modes:

o Do not rely on IP fragmentation.

o Rely on IP source fragmentation only (i.e., fragmentation at the
source node).

o Rely on IP source fragmentation and downstream fragmentation
(i.e., fragmentation at any node along the path).
Upper-layer protocols running over IPv4 can operate in the first and
third modes (above). Upper-layer protocols running over IPv6 can
operate in the first and second modes (above).


The first sentence of the last paragraph above is incorrect. In fact upper
layer protocols running over IPv4 can operate in the second mode by
instructing the IP layer to do source fragmentation and set the DF bit on
outgoing packets. I won't argue if you point out that most APIs don't
support this mode, but the fact is that the protocol allows for it.

Section 4.4, Security Vulnerabilities: please cite RFC 3828 in addition to
RFC 1858 in both places where the latter is cited.

I have (belatedly) read the comments on the int-area list and I think that
both Joe Touch and Mikael Abrahamsson make some very good points.

Again, thanks for putting the draft together.

Mike Heard

[Joe Touch]

FWIW
.

Upper layer protocols can also do their own source-frag if they send IP over raw sockets.

Joe

Post by C. M. Heard
o Do not rely on IP fragmentation.
o Rely on IP source fragmentation only (i.e., fragmentation at the
source node).
o Rely on IP source fragmentation and downstream fragmentation
(i.e., fragmentation at any node along the path).
Upper-layer protocols running over IPv4 can operate in the first and
third modes (above). Upper-layer protocols running over IPv6 can
operate in the first and second modes (above).
The first sentence of the last paragraph above is incorrect. In fact upper layer protocols running over IPv4 can operate in the second mode by instructing the IP layer to do source fragmentation and set the DF bit on outgoing packets. I won't argue if you point out that most APIs don't support this mode, but the fact is that the protocol allows for it.

[Mikael Abrahamsson]

Hi,

as promised in v6ops, I will suggest text. The current -01 text is:

7.2. For Network Operators

As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB
messages unless they are known to be forged or otherwise
illegitimate. As stated in Section 4.5, filtering ICMPv6 PTB packets
causes PMTUD to fail. Many upper-layer protocols rely on PMTUD.

So perhaps text along these lines:

--
As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB messages
unless they are known to be forged or otherwise illegitimate. As stated in
Section 4.5, filtering ICMPv6 PTB packets causes PMTUD to fail. Operators
MUST ensure proper PMTUD operation in their network, including making sure
the network generates PTB packets when dropping packets too large compared
to outgoing interface MTU.

Many upper-layer protocols rely on PMTUD.
--

I have also encountered lots of people who think that as long as they do
MSS capping, they don't have to worry about anything. Should we include
text on their behalf?

Another thing, I would like to see text somewhere (perhaps 7.1) that
states that protocols/applications should do PLMTUD. I would like to see
TCP having this default on in all operating systems.