Re[2]: Path MTU Discovery

"Whelan, Bill" <bwhelan@nei.com> Tue, 11 February 1997 22:47 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21049 for ipsec-outgoing; Tue, 11 Feb 1997 17:47:16 -0500 (EST)
Date: Tue, 11 Feb 1997 17:48:33 -0500
From: "Whelan, Bill" <bwhelan@nei.com>
Message-Id: <9701118557.AA855712066@netx.nei.com>
To: ben@ascend.com, Dan.McDonald@Eng.sun.com, Ran Atkinson <rja@inet.org>
Cc: angelos@aurora.cis.upenn.edu, ipsec@tis.com
Subject: Re[2]: Path MTU Discovery
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Ran,

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

Funny, but a couple of months back when I started a mailing list discussion 
due to my confusion about how to implement AH on a secure gateway, someone 
pointed me to IP-in-IP.  Then it all made sense to me.

The model I've been using is to compare the source and destination 
addresses to the tunnel end points.  If they are not equal, use IP-in-IP 
then apply ESP/AH transport mode.

You're right that the IPSec RFCs do not cite RFC 1853 specifically, but the 
text surrounding tunnel mode IPSec (as well as a lot of the mailing list 
discussion) sure looks like IP-in-IP to me!

Bill Whelan