IETF Logo Mail Archive

Re: Path MTU Discovery

Ran Atkinson <rja@inet.org> Tue, 11 February 1997 05:02 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14384 for ipsec-outgoing; Tue, 11 Feb 1997 00:02:19 -0500 (EST)
Date: Tue, 11 Feb 1997 04:58:44 +0000
From: Ran Atkinson <rja@inet.org>
Subject: Re: Path MTU Discovery
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>, Ran Atkinson <rja@inner.net>
Cc: Ben Rogers <ben@ascend.com>, Dan McDonald <Dan.McDonald@Eng.sun.com>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <9702110403.AA85679@aurora.cis.upenn.edu>
Message-ID: <Chameleon.855637367.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

--- On Mon, 10 Feb 1997 23:02:35 -0500  "Angelos D. Keromytis" <angelos@AURORA.CIS.UPENN.EDU> wrote:

> I think that, if not mandate copying the DF bit, the new drafts should
> at least present the benefits of doing so and provide guidelines to
> anyone who wants to have his implementation allow PathMTU. Or it could
> be a separate document altogether.

If one treats the outer IP/ESP as a link-layer, then not copying the DF bit
does not break Path MTU Discovery.  The MTU of the IPsec tunnel is defined
by the IPsec implementation at present.  

In any event, I think it would be useful for the next set of drafts to
be clear on this matter.  I'm personally indifferent about what the final
result is.

Ran
rja@inet.org
speaking only for himself

v2.29.0 | Report a Bug | By Email | System Status