Stuart Henderson writes:
 > interesting; if my understanding of this and the RFC that the referenced
 > 'touch' draft was published as (rfc3884), at one end you can configure one
 > side in *transport* mode carrying ipip encapsulated packets - gif(4) with
 > net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual.

That's the idea, though the IKE daemon on the transport+IPIP side has
to actually offer tunnel mode or the other end will typically reject
the negotiation.


 > this could be useful for either running routing protocols over IPsec, or
 > for redistributing IPsec "routes" into an IGP (the latter being something
 > I've been wondering about how to handle in some way that's a little more
 > flexible than "configure all of concentrator X's tunnels within 10.X/16
 > and all of concentrator Y's tunnels within 10.Y/16...)

It is useful for all of the above.

Reply via email to