Thanks for reviewing. Comments inline below.
Gorry Fairhurst wrote:
Please see comments below on the current draft.
Best wishes,
Gorry
(Matt - could you post to the list if this "bounces", I'm working from my
laptop as I travel to the IETF and don't have access to my other "gf"
account from here).
--------------------
* The title does not contain the abbreviation: PLPMTUD - this would greatly
help people searching titles to locate the RFC.
* page 11, section 4, para 2.
"limited clock stabilities"
- the scenario and implications of this is not clear.
There are devices that can deliver packets of a certain size with some
probability depending on the packet's size and other factors such as
temperature. Such devices should use an MTU sufficiently low such that
they can reliably (for some definition of reliably) deliver packets of
that size. The text could probably be a little clearer here.
* page 16, section 6.1, para 3.
- Mention is made of SACK blocks, it would be good to also cite RFC4341,
DCCP-CCID2:
DCP CCID 2 uses an ACK Vector that provides information equivalent
to that transmitted in a TCP SACK option.
We haven't put anything specifically about DCCP in this doc. We might
consider doing so (it wasn't ready yet before), but it could also be a
separate draft. We can talk about this...
* page 18, section 7.2 (and section 7.7, 8)
- I like the use of 512 as an acceptable common minimum MTU in the current
IPv4 Internet, but this is by no means a required value. If PLPMTUD sets
this as a minimum, what can be done if the discovery fails to find a path
that supports this MTU? It would be a shame to have this "black-holed".
Allowing PLPMTUD to drive the PMTU of a flow down to the minimum for IPv4
appears to me to expose a much bigger DoS threat. IPv4 ICMP messages which
suggest such small MTUs may be a big performance hinderance to hosts and
routers.
We're not specifying any real change to how ICMPs are processed. Most
systems today have a configurable lower bound on MTU, and that's not
likely to change. However, with black hole detection described in 7.7
(lowering MTU in response to persistent timeout), you can actually
support even smaller MTUs while maintaining the limit on ICMPs.
One other option available only in IPv4, would be to enable "IP Router
Fragmentation - but clearing the DF bit". Is this good, evil or acceptable?
I think that qualifies as evil. ;)
Packets sent with the DF bit set usually have zeroed IP ID fields, and
reassembly would be impossible. Unless the router also set the IP ID,
but then you're getting yourself into a mess... per address-pair state,
etc. in the router.
* Section 7.6.
- This section does not make use of RFC2119, it seems that some of these
cases should use "SHOULD" or "MUST". Was this intentional?
Yes. We felt like 2119 language here was unnecessarily strict for most
of this section, as it's describing a somewhat flexible method that
might have room for future refinement. I think all the really critical
stuff has 2119 language.
* Page 21, section 7.6.1, first para
- So what must the node do when the reported result of a probe is successful
for a smaller PMTU than that which is currently in use. Is this a case where
the probe should be treated as successful, but the probe value should be
ignored?
In such a case, it wouldn't be entirely ignored -- you still set
search_low, while eff_pmtu remains the same. So, it doesn't have an
immediate observable effect, but you do make a state change.
* Page 27
- I don't particularly like the idea of probing the return path MTU at the
same time as the forward path MTU (i.e. Using an ECHO mechanism). There does
not seem to be any need for a sender to know the MTU of the return path...
For example, a corner case in the use of ICMP-ECHO-REQUEST to probe for
bandwidth is that this actually performs a bi-directional test for the PMTU
probe size. Paths exist that have assymmetric properties (e.g. Scenarios
described in RFC3449), where the response to the probe mail fail, even
though the PMTU in the forward direction was accepted. Section 10.4 also
talks about the idea of probing the return path.
Probing both paths is less than ideal, but is conservative in that if
the probe succeeds, you know the forward path is capable. We view pings
as a sort of last resort if you can't do anything else.
* Page 27, final para
(e.g., 1kBytes or less)
- Is this thinking directed to IPv4?
- Would this better be 512B for IPv4 and 1280 for IPv6 to be consistent with
earlier?
This is describing an initial eff_pmtu, not a search_low (which would be
512 or 1280) like described in the initial values section. If you are
using ipv6, something larger than 1k would be appropriate, so we could
change the text to "(e.g., 1280 bytes or less)". OTOH, it's not
unreasonable to try 1k regardless of protocol. It saves you from
needing separate config values for both ipv4 and ipv6. This text is
really only a hint, not specifying anything. We can try to clarify this
better.
* Security Considerations
- See above. IMHO, it is worth stressing the performance vulnerability of
setting an outrageously small PMTU size in IPv4.
Possibly. We're not really specifying changes to the ICMP processing
though, so that might not be in scope. I guess it couldn't hurt to
mention it?
Thanks again for the comments. Will pull in the nits and try to fix up
some of the muddy parts.
-John
_______________________________________________
pmtud mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud
