Re: NAT66 : A first implementation

[Philip Craig <philipjcraig@gmail.com>]

On Fri, Jul 15, 2011 at 9:15 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Thursday 2011-07-14 18:27, Terry Moës wrote:
>>Multi-Homing. One network can be a client of several ISPs in order to
>>ensure redundancy or in order to reduce costs. These different ISPs
>>will assign the client different prefixes. However, it can be desired
>>that the client does not have to modify the topology of his subnet each
>>time he switches from one ISP to another.
>
> When switching the provider, consider:
>
> - If ISP2 blocks packets with source address SRC1, you are busted. NAT
> won't fix your problem:
>
> - reason 1: NAT is applied per CT and does not automatically change
> while a CT exists.
>
> - reason 2: Even if it did, packets of your connection would suddenly
> have SRC2, and the remote side would reject it with TCP RST, because it
> only knows a connection with SRC1.

I don't see how either of those reasons apply to the situation. The goal
here is to have multiple ISP links, and use them for redundancy and/or
load balancing at a connection level, not to have the same connection go
over both links.

So neither of those reasons stops you from:
- creating a new connection via ISP2 using SRC2
- using multiple connections from SRC1 and SRC2 simultaneously

IPv4 NAT allows you to do the above without needing multiple addresses
on your internal network, and without needing each client on your
internal network to choose which ISP to use for each connection.
It also ensures that the reply packets come back on the same link.

Maybe IPv6 has solved that problem, but I'm not aware of how.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html