[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: [Ran Atkinson: Re: Results of the IPSEC document reading party]
From: "Theodore Y. Ts'o" <tytso () MIT ! EDU>
Date: 1997-12-22 4:11:26
[Download RAW message or body]
Ran sent the following comment to me, and has given me permission to
forward it on to the ipsec list.
- Ted
------- Forwarded Message
Date: Sat, 20 Dec 97 05:56:12 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Results of the IPSEC document reading party
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199712192001.PAA25375@dcl.MIT.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Ted,
Regarding "Tunnel Mode" issues:
IPv6 has its own protocol number assigned by IANA (41).
That (41) is the number that should be in the Next-Header field
when IPv6 has been encapsulated inside tunnel-mode IPsec.
The note to the list seemed confused on this, but all known
IPsec+IPv6 implementations do as I indicate above.
When IPv4 is encapsulated inside tunnel-mode IPsec, then
the Next-Header should have (4) which is the protocol
number for IP-in-IP. Again, to the best of my knowledge
this is how all extant IPv4+IPsec implementations work.
Folks wishing to tunnel Ethernet frames within IPsec might
wish to consider using a Next-Header of 97, which has
been assigned as Ethernet-in-IP by IANA.
Note also that Protocol number 0 has in fact been assigned
by IANA to the "IPv6 Hop-by-Hop Option" and hence ought
not be used by an IPsec implementation for some other
(hence non-interoperable) purpose. Some folks have mumbled
about using Protocol number 0 for magic purposes, hence
my concern.
Thanks,
Ran
rja@home.net
------- End Forwarded Message
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic