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

Bob Hinden <> Sat, 04 February 2017 18:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55BB7129448; Sat, 4 Feb 2017 10:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 O_qqbTtIBBBd; Sat, 4 Feb 2017 10:50:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A523D1293FE; Sat, 4 Feb 2017 10:50:13 -0800 (PST)
Received: by with SMTP id v77so73981617wmv.0; Sat, 04 Feb 2017 10:50:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YbVdLTWPozJiLnXSmDSJDBTCcjv73Zt//r73E9xeSw0=; b=FXbLCLwSP+0RPdZ53QYZ1cJ3ve0rE6+rAyIt8+a2kSWuIR3ktz57FwBW1JHwgphn59 ObPuPt7/AYvVUQdpsYsMAvwyz5QTy29yqbHQIjz7UB6cVgJ31O9JJOmm1Jn+CVIbsFug qBIY7lJEAtKsqg/kUYAyHVgWX6R3BI/D/5A3GRNjiYWZo0po4XHm3mPCOYI26dNHYHwN 25R4VOn+rkKy25xwzWyKhCQwZl3pbtInTgAldsJRvTZNk3V8x22EYd5RmHDrZKyUFVIy oV9WJp6qDAOsxvITZUGfdrg4vYT0Qv63tu4RJ+sUmBIFh+h9YSyt/QSu3k43lLTpJ55A HSSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YbVdLTWPozJiLnXSmDSJDBTCcjv73Zt//r73E9xeSw0=; b=oY/s+ljQShoMIO7VBzkZLgxgYqd8pDM0OMpwSnHoaaPu6JP/Y71t0+4BQmyJO+qQMm IITEJI2VBDfVU4KEymw2gtnap7tfqvDlQp9xgsr0h2r1XZgfNA3JA+0hT0nmYfjCNcPU twi063Qg8DwhGWRS4KTgV7WNO5iHjBAOkBPy9TCRh9eEah5KKEiIa5fzuDETvODubZqy z5mjJubHM/YWJXXIc2LvbGOKh46//5ABwy2Qf2Vij1i0EIsdshRR3i9GGSgn4Fmv0OM+ bQV5Axuq1iAR4uP5ewTi8b5kgsgdN5qVtbxUSb3RFf1S5wvv3fOwkyW2cBMTe6RYPk9e u6Dg==
X-Gm-Message-State: AMke39mt+CHz0CuzDAHLTgNtHKTpByAHhZ18FSj8rNSc3Gq842OqY3edyKMZFnZmVeQg8Q==
X-Received: by with SMTP id c141mr2988413wmd.12.1486234212151; Sat, 04 Feb 2017 10:50:12 -0800 (PST)
Received: from ?IPv6:2601:647:4d01:db10:9541:744d:33b2:2904? ([2601:647:4d01:db10:9541:744d:33b2:2904]) by with ESMTPSA id k4sm3783889wmf.22.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Feb 2017 10:50:11 -0800 (PST)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_78F5415F-3BD7-4F43-92C3-919784D39E49"; protocol="application/pgp-signature"; micalg=pgp-sha512
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
Date: Sat, 4 Feb 2017 10:50:04 -0800
In-Reply-To: <>
To: "Eggert, Lars" <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: IPv6 List <>, IETF <>, Bob Hinden <>, "" <>, "" <>, Fernando Gont <>, "" <>
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, 04 Feb 2017 18:50:15 -0000


> On Feb 4, 2017, at 10:40 AM, wrote:
> Lars,
>>> My apologies: my comments were probably misleading. Certainly, this
>>> document is simply RFC1981 to Std, and hence recommending RFC4821 would
>>> be kind of ou of scope, here.
>>> That say, one might wonder to what extent, and for the general Internet,
>>> RFC1981 can be considered succesful (given the filtering of ICMP
>>> messages). -- i.e., at this point in time you wouldn't rely on RFC1981
>>> (icmp-based pmtud) for path-mtu discovery.
>> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.
> While I'm all in favour of PLMTUD. It doesn't seem like a complete solution.
> PMTUD on the other hand supports all protocols on top of IP.
> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.

In addition to what Ole says here, I don’t think rfc1981bis is the right place to describe this.  6MAN is working on an update to IPv6 Node Requirements ( ).  I think is a better place to describe the relationship between PMTUD and PLMTUD, where they work and don’t, and what the current recommendations are.  I hope you will contribute to that work.