>>>>> "Michael" == Michael Ko <mich...@huaweisymantec.com> writes:
Michael> If the end system is behind a NAT, then there is no way for
Michael> another end system to address a packet to this end system.
Of course, the machine behind the NAT has to initiate, but there are
numerous ways that this can happen. In particular, given a service like
TURN, HIP, or IKEv2, and a hub to exchange the outside addresses, it is
entirely possible to arrange for things to work.
Michael> Not only is opportunistic encryption impossible, but it is
Michael> also impossible for any communication to be initiated to
Michael> the end system. It may be possible for this end system to
In fact, we've done it.
The problem is that is doesn't scale to the Internet, since the
overlapping RFC1918 address ranges mean that eventually, there is
another 192.168.1.0/24 network that you want to talk to, while you are
on one.
One can pick new addresses for inside the tunnel, but which ones?
We couldn't solve this problem in a way that scaled to the Internet: the
rise of ubiquitous NAT is the reason why RFC4332 died.
While these problems are still challenging in a walled garden, they are
much more tractable. Or, given that it's all inside a tunnel, why not
just use IPv6 addresses on the inside of host to host tunnels?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
