[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: null encryption
"Bryan Gleeson" <BGleeson@shastanets.com> wrote:
>As used with VPNs, there are a lot of requirements for a
>generic tunneling protocol, over and above the need to
>encapsulate data packets. For example to reduce the
>configuration burden of setting up lots of tunnels, a
>signalling protocol that allows the establishment and
>negotiation of tunnel attributes is very useful. IPSEC
>(IKE) and L2TP have such a signalling protocol. GRE
>and IP/IP (RFC2003) do not.
That's not the right comparison. If you were to compare apples to
apples you'd have to compare ESP or AH with GRE and IP/IP
(they're just encapsulation schemes, not signalling protocols).
Signalling in all of these cases is a separate
protocol. For ESP/AH it is IKE. Similarly,
Mobile IP (rfc2002) defines a registration protocol which set up tunnels
using IP/IP or GRE or Minimal Encapsulation.
However, mobile ip does not address all that one
needs to set up general tunnels. We
proposed a superset called
TEP (draft-ietf-mobileip-calhoun-tep-01.txt) for that reason.
>...Also a multiplexing field
>that allows multiple tunnels to be set up between the same
>two endpoints is very useful (to support different VPNs
>for example). Again IPSEC (via the SPI field) and L2TP
>(via the tunnel-id, call-id fields) have such a
>multiplexing field, but GRE and IP/IP do not.
GRE has a 32 bit key field that can be used for this
purpose. TEP allows its negotiation via the tunnel id.
>
The ability
>to send opaque and multiprotocol frames across an
>IP backbone is also not addressed by IP/IP.
that's what gre is for.
-gabriel