Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

Fred Baker <> Fri, 03 February 2017 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF8DE12950A for <>; Fri, 3 Feb 2017 12:58:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L-4Bb7_JXETX for <>; Fri, 3 Feb 2017 12:58:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3FF0129506 for <>; Fri, 3 Feb 2017 12:58:43 -0800 (PST)
Received: by with SMTP id 14so9462238pgg.1 for <>; Fri, 03 Feb 2017 12:58:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tf9T9QPNsVorgh1gryaLawU/9nmWzv9QhXAb2mvEsG0=; b=qlVdnWJMs943z7xYcKbihcdGnK4fxNptMbwFVR/X5x6q84Ei5DYlitAmHtRi+Ze7kB snPtr1Hh++YRXTXrLK5uo29JEr89RxsQD7nFJyw5iQiESdhF6N7xrzn08bp6FpM+MGUJ RtG0ZcEq0uOTeHmfuqdZxGNLyCywvC1H/s6qnjbTR0j3Kmi3MwiEe3FFdL4h9NWDuj3m ayK1+VwHNDQKZTYvB8ksoWs2IEUwd6DhiWMvaUXsOdKg7EqPEifk3ORkt35JdMBBnpv+ ws/8MwmQ+sgsT/i+m1E4Xubt11nZ9UUIjx5X73JdWfuy1yFRwsVP9PGJoo39RFZgYRC+ fIrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tf9T9QPNsVorgh1gryaLawU/9nmWzv9QhXAb2mvEsG0=; b=h6tvx88DmliTeZQXkutcj0qCiaTZL4V1sFPGdFa8jfzcEsqZncFOJVz35iUc0ekYLz YtyIvZUfJXDCiLhmIYD2pYDZCSA5SVOy/DrCRjPfL6AAq/FMDaG7clmsQAZSCZtpu8Kl Up6wGOvAeRSkzJRVT7YIROI7CsXuIlkwN43rKo+R+JWcLf5rucu5+MnpxFr6gnkYuv44 MCobkPMpsNLoNmjPEnQAaYMcRsfphns+IL6ARii/0UmgqAOE3igoA/ybtljW+rP7A0Ew h3oezICPejcPKoD2d+Wbibbki7ZXkLxsvjaiyvpTxfRAxvYzY7aKmwAYbREuP5TQHZMv wfdA==
X-Gm-Message-State: AIkVDXJxrj13asVE+zwEKCdB2I9cuvDlbYP2KMSzW20Qs1yKc7fd+ERyfTTz33rd5fxMJg==
X-Received: by with SMTP id 21mr20691064pfz.46.1486155523234; Fri, 03 Feb 2017 12:58:43 -0800 (PST)
Received: from ?IPv6:2001:4f8:3:65:61e5:c889:2e8d:2230? ([2001:4f8:3:65:61e5:c889:2e8d:2230]) by with ESMTPSA id e13sm69948971pgf.48.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 12:58:42 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
From: Fred Baker <>
In-Reply-To: <>
Date: Fri, 3 Feb 2017 12:58:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Fred Templin <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: "" <>
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: Fri, 03 Feb 2017 20:58:45 -0000

On Feb 3, 2017, at 12:11 PM, Templin, Fred L <> wrote:
> A note about RFC4821. We think it will work for end-to-end MTU determination and
> black hole avoidance, but from discussions on intarea we now no longer think it will be
> applicable to tunnel endpoints. That is because the tunnel ingress is not the source
> of the original packets - it is only the source of the tunneled packets and the RFC4821
> probes. And, if the original packets (once admitted into the tunnel) travel a different
> path than the probes the system could black hole.
> Is this worth an errata to RFC4821?

I guess my question is "what in 4821 would you like to see changed". 4821 says, in effect, "try a number of different trial PMTU values in a rational sequence, and use the largest that seems to work". As you say, the tunnel endpoint doesn't implement the TCP, and therefore doesn't implement 4821 directly, at least for that purpose. However, if the system sending it packets does, the existence of the tunnel merely forces the 4821 algorithm to choose a smaller number. 4821 in the endpoint that *does* implement TCP should have the right result.

So, with the possible exception of adding one or more appendices saying "X in the network can cause the algorithm to choose a smaller number", I don't see what in a potential 4821-bis would be different. In such a case, I don't see the case for an erratum; an erratum is a request for a change.

A change I might suggest, which is not an error but an optimization, would suggest trying the first few values (IP message size 9000, 1500, 1400, and 1280?) in the same RTT, and deducing from the first Ack received which one got through first (in that sequence, the host might not try 9000 because it is configured for something shorter, try 1500 and have it not go through a tunnel, but have 1400 and 1280 work. It would get an Ack saying that it expected the next octet to be N+1400, or possibly an Ack pointing to N+1280 and another pointing to N+1400). Rather than waiting for retransmission timeouts, make it all happen in the first RTT.