Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04 Sat, 11 February 2017 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58722129593; Sat, 11 Feb 2017 14:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dVmqmwQla--v; Sat, 11 Feb 2017 14:59:27 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id AE01212958D; Sat, 11 Feb 2017 14:59:27 -0800 (PST)
Received: from ([]) by with ESMTP; 11 Feb 2017 22:59:27 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 7599AD788D; Sat, 11 Feb 2017 14:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=ty5fPjcZy3Nqg4Wh6SbLO0l06G4=; b= c6ke+e30wx7UHQTss69syLtR7aoTuYqWAULKxvGY2I6d4le/C4EwfRIf3o3I+JP1 tHGssg2v8UezsgBKcm59nXVPSB1tUAKrnNB7NnUbw2n4I3GZiyCGmKvfWL12F7wP M6eAhNEZlZVa+nm5LpG7zDTFXujQPzR/gJ0I0pivk3Y=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=HM/MU5WH+IaRS1pyphKk8Bo 0jSy80P2hXL7B/gGR9S/4TmJvBAzgz9GDRuSYeGvuAzReLhulq8E3OmofIK2uDWU mWHp3LdzcFKU9diLHGiqLEh5V+MPRFa3DyT20UTneWFacMmJla0h5Nx88kzZknGb 9etswSQloDgOxZSl1piI=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id F3440D788A; Sat, 11 Feb 2017 14:59:25 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id C207089992FC; Sat, 11 Feb 2017 23:59:21 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6588FB4B-F8B2-4090-85F1-F52B0F22C020"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
Date: Sat, 11 Feb 2017 23:59:20 +0100
In-Reply-To: <>
To: "C. M. Heard" <>
References: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>, IETF <>, Gen-ART <>, Suresh Krishnan <>, Stewart Bryant <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Feb 2017 22:59:29 -0000

> 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.

Yes, but DNS tend to use IP fragmentation that suffers an order of magnitude worse fate than ICMP messages. ;-)

> 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."

That's correct. But it then must restrict itself to sending packets at the minimum MTU size.
You cannot implement RFC2473 (IP in IP) without PMTUD for example.


> 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.

For IPv6, because of the removal of fragmentation by intermediate nodes, failure to provide a path where ICMP message delivery is assured is a considered a configuration error.


"We observed that for IPV4 between 4% and 6% of the paths between the vantage points and our experimental setup filter ICMP PTB packets. For IPV6 this was between 0.77% and 1.07%. Furthermore, we found that when IPV4 Domain Name System (DNS) servers do not act on the receipt of ICMP PTB packets, between 11% and 14% of the answers from these DNS servers are lost. For IPV6 DNS servers this was between 40% and 42%. Lastly, we found that for IPV4 approximately 6% of the paths between the vantage points and our experimental setup filter IP fragments. For IPV6 this was approximately 10%."

From that data it looks like we have been quite successful. ICMPv6 PMTUD is treated a lot better (about a 1% loss) than its IPv4 counterpart.
Unless better data exists I tend to conclude that the claim that the Internet breaks PTUMD for IPv6 is a myth.

Fragmentation on the other hand...
And please don't get me wrong, I think we have a big job to do on MTU issues. I just don't see data showing that PMTUD isn't doing what it was designed to do.

Best regards,