Re: Another field for traffic selector?

["Scott G. Kelly" <scott@airespace.com>]

Aside from the question of deferring this, I think there's a larger
question pertaining to whether the spec needs to solve this at all. I've
seen this problem (overlapping address space) solved by using
per-customer tunnels, and static nat'ing the private addresses at either
end when the customers want to interact (extranet scenarios). I really
don't see why everyone's ipsec implementation must be modified to
accommodate someone's aversion to per-customer tunnels.

If I'm missing something, please let me know.

Scott

Michael Thomas wrote:
> 
> Radia Perlman - Boston Center for Networking writes:
>  > 2) Why does it need to go into IKEv2?...because otherwise there's
>  > no way to route the packets, if the IP addresses in the customer
>  > nets overlap.
> 
> This evades the real question. Why does this need
> to be part of the base spec? There's lots of world
> hunger that IKEv2 doesn't solve. Why can't this be
> deferred for later consideration, rather than an
> ill-advised last minute addition?  If IKEv2 does
> not lend itself to such additions, maybe we asking
> ourselves how we can make IKEv2 more amenable to
> these kinds of additions rather than loading up
> the kitchen sink blindly.
> 
>             Mike