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.
