On Fri, Feb 10, 2017 at 10:42 PM, Suresh Krishnan <suresh.krishnan@xxxxxxxxx> wrote:
On Feb 10, 2017 11:30 PM, "C. M. Heard" <heard@xxxxxxxxx> wrote:On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).> > but it seems that in practice the Internet breaks the mechanism.
>
> > However it breaks it is a way that seems disruptive to some user> > ICMP for optimization, and arguabl[y] need not be a standard at all.
> > traffic. The document is really guidance one how hosts might use
>Actually, no. You do not have to use PMTUD to avoid black holes.
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.
Other options include:
- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
that can detect packet loss)How does this work for UDP?
Sending packets no larger than 1280 bytes is always an option, and in
the case of UDP-based request-response protocols such as DNS that do
not have connection state, it may be the only feasible option.
Anyway, the point I was trying to make was not to argue about better
or worse methods but rather to dispute the statement that PMTUD is
essential for avoiding black holes. I don't believe that it is. The
draft itself explicitly says that "IPv6 nodes are not required to
implement Path MTU Discovery."
> > My remark about heritage is that this vintage draft is very much aI am afraid that I have to agree with this. Classic PMTUD by itself
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.
is today not enough, but it can be a very useful optimization to
augment other techniques.OK.All true, and my conclusion is that is it should not be promoted to IS.
> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.
What criteria for advancement to IS do you think are not met by this document?
I do not dispute that the document has met the formal criteria for IS in Section
2.2 of RFC 6410. I would argue, however, that its failure to provide a complete
solution for environments where delivery of ICMP messages is not assured
constitutes a significant technical omission for today's Internet, and I note
that per RFC 2026 Section 4.1.1, even a PS "should have no known technical
omissions." What I am asking the community, and the IESG, is whether it is
wise to advance a document with known technical omissions; it seems to me
that the Gen-ART reviewer has raised much the same question.
I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).
If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.Not sure I understand your concern. This is a change log since RFC1981.
And it is a fact that the reference to RFC4821 was added into this draft.
Can you clarify?
My apologies, I wrote that too hastily, before reading the complete change
log, which contains a description of what changed in each draft as the
document proceeded through the WG process. The comment that I should
have made is that many of those details are not useful to readers of an
archival document. Looking at a diff between RFC 1981 and this draft,
the substantive changes pretty much boil down to these:
- In Section 1, added a reference to RFC4821 along with a short
summary of what it does.
- In Section 4, added text to discard an ICMP Packet Too Big message
containing an MTU less than the IPv6 minimum link MTU and removed
the corresponding note specifying actions that were removed from
[I-D.ietf-6man-rfc2460bis].
- In Section 5.2, removed text regarding RH0 (since it was deprecated
by RFC5095) and removed text about obsolete security classifications.
- In Section 5.2, clarified that the tentative PMTU must not be made
smaller that the IPv6 minimum link MTU.
Regarding that last change, I got confused when I was reading the current text
in the draft:
The node then uses the value in the MTU field in the Packet Too Big
message as a tentative PMTU value or the minimum IPv6 next hope MTU
if that is larger, and compares the tentative PMTU to the existing
PMTU. If the tentative PMTU is less than the existing PMTU estimate,
the tentative PMTU replaces the existing PMTU as the PMTU value for
the path.
I initially took the words "minimum IPv6 next hope [sic] MTU" to mean the next
hop MTU of any link on the node, which of course is not what it meant. Maybe
I'm being dense, but it wasn't until I looked at Donald Eastlake's INT-DIR
that the correct meaning finally dawned on me. May I suggest saying instead:
The node then uses the value in the MTU field in the Packet Too Big
message as a tentative PMTU value or the IPv6 minimum link MTU if
that is larger, and compares the tentative PMTU to the existing
PMTU. If the tentative PMTU is less than the existing PMTU estimate,
the tentative PMTU replaces the existing PMTU as the PMTU value for
the path.
In other words, s/minimum IPv6 next hope MTU/IPv6 minimum link MTU/.
That makes the terminology consistent with the rest of the document.
Thanks and regards,
Mike Heard