[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Results of the IPSEC document reading party

To: ben@Ascend.COM (Ben Rogers)
Subject: Re: Results of the IPSEC document reading party
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Date: Fri, 19 Dec 1997 16:20:01 -0500
cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, ipsec@tis.com
In-reply-to: ben's message of "Fri, 19 Dec 1997 15:48:54 -0500". <199712192048.PAA20633@carp.morningstar.com>
References: <199712192001.PAA25375@dcl.MIT.EDU> <199712192048.PAA20633@carp.morningstar.com>
Sender: owner-ipsec@ex.tis.com

In message <199712192048.PAA20633@carp.morningstar.com>, Ben Rogers writes:
> 
> This is a bad idea, because the tunneling which is proposed in the
> architecture document is _not_ IP-in-IP.  Of note, rfc2003 states:

The encapsulation protocol and algorithms used are independent from the
Payload Type/Next Header/Protocol field. If the Payload is an IPV4 datagram,
then the Payload Type should indicate such, and should be protocol 4.

Having said that, I'll also mention that IPsec tunneling, and RFC 2003
IP-in-IP are trying to solve slightly different problems; note that the
Abstract for 2003 explicitly mentions Mobile IP :-).

-- 
Harald Koch <chk@utcc.utoronto.ca>

References:

Results of the IPSEC document reading party

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>

Results of the IPSEC document reading party

From: Ben Rogers <ben@Ascend.COM>

Prev by Date: RE: a drop/bypass action negotiation issue
Next by Date: IPsecond place?
Prev by thread: Results of the IPSEC document reading party
Next by thread: Results of the IPSEC document reading party
Index(es):
- Main
- Thread