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

Re: Bakeoff summary

itojun,

As the attached almost-two-years-old email details, rfc2393bis is
answering RFC2407 'host-dependent default assumption when the
encapsulation attribute isn't defined', by defining the default to be
transport mode.

The change is included in the rfc2393bis I-D from the first version,
submitted in September 1999.  

Regards,
avram>           


itojun@iijlab.net wrote:

[...]

 >
 >problem areas
 >
 >ipsec
 >ipcomp - some problems?
 >        minor fragmentation issues
 >        diff between ike spec and ipcomp spec - encapsulation mode

[...]

=== 

Date: Fri, 17 Sep 1999 07:12:43 -0700 (PDT)
From: Abraham Shacham <shacham@cisco.com>
To: ippcp@external.cisco.com, ipsec@lists.tislabs.com
Subject: rfc2393bis

Following the threads on ipsec and ippcp mailing lists
since the publication of RFC2393 in December 1998, and 
the hallway discussion in Oslo with some of the ippcp
mailing-list members, draft-shacham-ippcp-rfc2393bis-00.txt --
(ippcp wg exists no more, therefore no draft-ietf naming) --
intends to update RFC2393 with the following clarifications:

[...]

3. Negotiations in the context of IPSec

[...]

3.3 Definition of encapsulation mode in the context of DOI, 
including answering RFC2407 'host-dependent' default 
assumption when the encapsulation attribute isn't defined:

     Encapsulation Mode
     [...] 
        If unspecified, the default value shall be assumed to be
        unspecified (host-dependent).

[...]

351c369,372 === #3 ===
<    Identifiers.
---
 >    Identifiers.  To suggest a non-default Encapsulation Mode (such as
 >    Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode
 >    attribute.  If the Encapsulation Mode is unspecified, the default
 >    value of Transport Mode is assumed.
Follow-Ups: