[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec re-defining IP-in-IP
[CC'ed back out to both ipsec and iesg]
Karen Seo <kseo@BBN.COM> writes:
> In writing the architecture section 5.1.2 "Header Construction
> for Tunnel Mode", we tried to conform to RFC 2003. I thought
> we'd only added clarifications, e.g., the footnote about src and
> dest addresses or the table entry saying the protocol in the
> outer header could be AH, ESP, or a routing header (not just 4
> as stated in RFC 2003). Could you tell us what you are
> concerned about that we've "redefin"ed?
I'm not concerned that you have defined anything differently than in
RFC 2003. My concern is that we are redefining (duplicating the
definition of) the protocol. If the protocol is defined in two
locations, anyone wishing to update RFC 2003 would also have to update
the IPsec architecture draft. Twice as much opportunity for problems
to arise -- AND the added confusion of (possible) differences between
the IPsec Protocol 4 encapsulation and the Internet Standard IP-in-IP
Protocol 4 encapsulation.
I feel that Protocol 4 (IP-in-IP) encapsulation ought to be defined in
only one place. If we (the IPsec community) want to use it, we
should reference the standard document. If we need something
different, then we should choose a different protocol number to
describe it. If we merely need clarifications to RFC 2003, then they
should be made in a successor to RFC 2003, and not in a completely
unrelated (for non-IPsec folks) document.
ben