Yoav Nir <y...@checkpoint.com> wrote:
> There is something that I think is missing from all three proposals,
> and that is the handling of duplicate protected networks. As long as we
> live in a predominantly IPv4 world, we have a lot of NATs and a lot of
> RFC 1918 addresses.
That's one of the reasons I think that it should run inside IKE, so that we
don't have issues of how the spokes talk to the "ADS"...
> All this goes out the window the moment you try to connect with other
> administrative domains or worse - merge some administrative
> domains. And a dynamic setup of tunnels runs a high risk of having the
> same network on both sides of the tunnel.
I think that connecting multiple adminstrative domains together just won't
work. You have to go through a HUB machine that does the appropriate
(double?) NAT. Further, you simply have no way to know, when the client
says he wants to talk to 192.168.1.1, which machine they mean.
So:
1) protocol must support IPv6.
2) protocol SHOULD support doing lookups using IPv4-mapped IPv6 addresses
I'm thinking about some variations of RFC 6333
Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
being used, but I have to think about it more.
Consider further how a Teredo-type IPv6 address can incorporate
an IPv4 + port number, and if one then does *ADVPN* for that
address...
3) It's less of a big deal to connect the two adminstrative domains
given ADVPN: one can have as many NAT44 machines as one needs to
get the job done, and they can be distributed into as many data
centres as one likes, because the ADVPN protocol would just
direct the spokes in a consistent and load balanced way.
4) IPv6 traffic goes direct, or goes through a NAT'ess ADVPN router.
One still has the problem that two end systems have difficulty addressing
each other, but potentially the address each gets NAT'ed to that leads to
the other system could concievably be managed by the same ADVPN multi-realm
hub.
> Now, regardless of which solution we choose, it is decided that A
> should send traffic directly to C, skipping B. But that means that A
> should now NAT the packets, because C does not wish to receive
> non-routable IP addresses from a partner. It has its own 192.168.x.x
> addresses within its network. But here's a problem. Regardless of
> whether A does or does not NAT when sending traffic to C, connections
> are going to be severed. Why? Because the source IP address of the
> traffic coming from 'a' changes. Before 'c' got the traffic from B's
> public address. But now it's coming either from 'a''s non-routable
> address, or from A's public address. Either way, TCP connections get
> severed.
What you say is true.
But, if the goal is to shortcut things like media traffic, then it might
be okay. The media setup protocol may be able to deal with the changes to the
addresses/port numbers.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpP94Y78WW0r.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
