Re: Path MTU Discovery

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

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14089 for ipsec-outgoing; Mon, 10 Feb 1997 22:52:16 -0500 (EST)
Date: Tue, 11 Feb 1997 03:46:02 +0000
From: Ran Atkinson <rja@inet.org>
Subject: Re: Path MTU Discovery
To: Ben Rogers <ben@ascend.com>, Dan McDonald <Dan.McDonald@Eng.sun.com>
Cc: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702081237.HAA24954@carp.morningstar.com>
Message-ID: <Chameleon.855633160.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

Ben,

  It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP
RFCs.  This is not an accident.  With IPsec, one is not performing IP-in-IP.
Rather, one is performing IP-in-AH or IP-in-ESP.  The IP-in-IP RFCs don't
include IPsec within their scope.

  It was quite intentional that this was done.  It is equally intentional
that the IPsec RFCs haven't been citing the IP-in-IP RFCs.

  In effect, ESP tunnel mode uses the outer IP as a link-layer.  Copying
DF bit is not prohibited for IPsec tunneling, but neither is it required
for IPsec tunneling.

Ran
rja@inet.org
who wrote the relevant IPsec RFCs...