Hi Izaac/ John, Thanks for the great inputs you provide. I agree we may not see changes in the way packets would traverse the network in either the transport/ tunnel mode.
Like you mention Routing in such topologies is an issue for sure (especially in the Hub and Spoke topology) and there are extensions being worked on to resolve those issues. However the above does not solve the problem of exhaustive IPsec database configurations. It also does not solve the issues of how to handle changing identifiers in the SPD either (as addresses of spokes change). Like the draft mentioned an exhaustive configuration could solve some of the issues, but that would lead to issues with the weakest link the the topology. Thanks, Vishwas On Wed, May 9, 2012 at 9:46 AM, Izaac <iz...@setec.org> wrote: > On Tue, May 08, 2012 at 11:22:07PM -0400, John Leser wrote: > > particular destination seems unworkable. It would be more > > reasonable, and probably more useful, for a client to automatically > > locate the nearest VPN server to itself (that alone would be an > > interesting and potentially useful problem). > > Even this is better served by just letting IP routing handle it through > the use of transport mode. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
