[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bridging non-IP traffic over IPSec
Well, there is NO need for an inner IP header when you use GRE. You
can do either:
1. Use ESP in transport mode, with next header value of GRE.
2. Use ESP in tunnel mode, with next header value of GRE. (Maybe this
is illegal, and tunnel mode requires the next header to be IP? I
don't remember.)
The advantage of GRE in this case is that it is an IP-level protocol,
not a UDP-level protocol. You don't need an IP/UDP header to navigate
there.
You have to configure whatever protocol runs over GRE.
As I noted, Cisco would have to allow GRE to go standards track. (I
don't know if they didn't want it to, or whether working groups
rejected it because they thought tunneling is evil.)
But, bridging is more evil than tunneling. (Been there.) Plus, if
you're briding, you've got to fob in a 14 byte Ethernet header, which
is longer than the minimal GRE header. No gain.
(Also, complaining about any solution in the IPsec space being too
configuration-intensive is "the pot calling the kettle black."
IPsec is already massively configuration-intensive.)
But, let's remember, the "client" (by the time we cut any more
standards) will be whatever Microsoft has already decided to ship in
Windows 2000. If that is PPTP, that WILL be how you talk IPX over
IPsec to Windows. (Whether that's where you want to go today or not.)
The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in
Windows 2000), nobody will be willing to install a different IPsec in
it. (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT
these days? Same will apply to IPsec in Windows 2000.)
Follow-Ups:
References: