--JYK4vJDZwFMowpUq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 04, 2006 at 12:33:46AM -0600, David Young wrote:
> I am trying to understand why one would configure a gre/gif tunnel
> with encapsulation destination equal to the point-to-point destination.
> E.g., on this interface, the encap destination, 10.0.0.2, is the same
> as the point-to-point destination:
>=20
> gre5006: flags=3Dd051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
>         tunnel inet 10.0.0.1 --> 10.0.0.2
>         inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
>         inet6 fe80::a00:20ff:fef9:60ee%gre5006 ->  prefixlen 64 scopeid 0=
x112d
>=20
> To support this configuration, an author resorted to some cleverness that
> it will be *tremendously* difficult to replicate in the New Model GRE,
> which I intend both to simplify GRE, to support IPv6 encapsulation,
> and to repair a bug in route caching[1].
>=20
> Can anybody explain, what is use such a configuration as above?  Is there
> no other way to create a similar network?

I'm sorry for the 6-month delay in following up.

I can't see a reason for the exact above, because the boxes are all on the=
=20
same subnet.

I think a reason for having the inside and outside IPs the same is if you=
=20
have a box that's providing services and is also your tunnel end point.

To be honest, the reasons I can come up with also involve transport mode=20
IPsec. Putting them together, it's like having the hiding of NAT w/o=20
having NAT.

The real reason I could see this is if you had two paths to the other IP,
each with its own border box.  Each one does a gre tunneling some addreses
to the end point, and it uses routing to decide which of your two routers
to send packets back to.

Transport mode IPsec plus GRE produces packets that look the same on the=20
wire as those from Tunnel mode IPsec. The difference is in the attached=20
policy. Transport mode + IP tunnelling lets you add all sorts of routing=20
on top of the tunnels.

Take care,

Bill

--JYK4vJDZwFMowpUq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGQjPrWz+3JHUci9cRAmZEAKCKhnYjoUuMwqnXC1vntCuw+p6oIACdEFd4
tfxFiiXfgKp1mgQSkTgLqg4=
=A+j1
-----END PGP SIGNATURE-----

--JYK4vJDZwFMowpUq--