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

Re: IPsec re-defining IP-in-IP?



>I am a bit concerned as to the redefinition of IP-in-IP tunneling
>within the proposed IPsec architecture document.  One of the reasons
>RFC1825 was able to remain much smaller and simpler than the current
>document was that it seems to have been content leaving tunneling to
>the folks working on tunneling, while security was handled by the
>folks working on security.  As such, I see no need to more or less
>duplicate the information in RFC2003.
>
>I would suggest that an explicit description of what to do with IP
>protocol 4 ought to be defined in only one location.  We (the IPsec
>WG) need it to provide a tunneling capability.  MobileIP needs it to
>satisfy some very funtamental needs in their protocol.  There is no
>reason that we cannot share the same document.  If we don't then we
>run the risk of not knowing what to do within an IP stack in the event
>that the two documents diverge.  We might end up making the
>interpretation of IP protocol 4 context dependent, the "IPsec protocol
>4" used whenever our parsing engine finds a protocol 4 in an AH or
>ESP, and the "RFC2003 protocol 4" in all other cases.
>
>ben


Agreed!  In fact, since RFC 2003 is already a Proposed Standard, 
it is already the official protocol 4, so any other similar protocol
defined by IPsec would need to be a different protocol number.
Before we get into such an escalation of essentially redundant 
protocol number assignments, if there is some reason that RFC 2003
doesn't do what IPsec needs (or any other protocol that needs
IP-in-IP-like behavior), we should talk about it.  If there are 
some minor revisions that can be made to 2003, please let us (the
Mobile IP Working Group, who defined 2003) know about it.

					Dave


Follow-Ups: References: