On Friday 2011-07-15 07:48, Philip Craig wrote: >On Fri, Jul 15, 2011 at 9:15 AM, Jan Engelhardt <jengelh@xxxxxxxxxx> 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.[...] >> >>[...About the problems, but also possibilities, about switching >>the link of a connection's packets in the middle of the connection...] > >[...] The goal here is to have multiple ISP links, and use them for >redundancy/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. Without the knowledge of which address will be chosen, a client will sooner or later run into ETE problems because it does not know which address to write into its data stream. Always assume that this data stream is armored (visible, but unmodifiable without breaking a signature) or even encrypted (invisible, implies armored). >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. Well, I am thinking about whether MIP or a form thereof could be of use. (Answer: not directly, because a server cannot realistically have two routes to two different fd00::1.) [ BTW Terry: fec0::/ that you are using in your NAT66_slides.pdf are deprecated since 2004. ] What we want: ETEC, i.e. webserver can potentially backconnect (subject to any firewalling rules) to an arbitrary port of 1. the src address of the packet and/or 2. the address(es) contained in the armored data stream. Step 1. To satisfy point 1, NAT bindings are supposed to be a 1:1 binding (i.e. ignoring all L4 components // L4 wildcard). NAT bindings may be created on the fly as a packet traverses the NAT device. Whether that is stateful or stateless is left to the implementation. Step 2. A client may send addresses inside the data stream. The client shall emit a DST header containing a 2-tuple of addresses used in the armored/encrypted communication procedure, e.g. <i-address, p-address> <fc00::1, fc00::1> afterw. <fc00::1, 2001:db8::1> (I chose DST so that it is not stripped at a router. A HBH header that each router reproduces would do the same, though that would probably need extra routing software support.) During NAT traversal, only the p-address is changed. A server can now substitute "fc00::1" appearing in the datastream by "2001:db8::1" to be able to connect. Naturally, this needs application support, and given there are already a handful of solutions with application support, maybe this is not as ideal as one of such preexisting solutions. Anyhow, the upside is that this would only require application support at the receiver side, which means that a client does not need to discover its own addresses in advance (like UPNP/IGD if I read it right). The issue with in-advance address discovery would be that it may be outdated again once used. Also, the header approach does not need protocol modifications. Step 3. Since I guess some people will whine again that their oh-so-secret internal addresses that mean nothing to the outside world are visible, the client can actually utilize fake addresses in both the armored data stream, and the DST header. <::2, fc00::1> afterw. <::2, 2001:db8::1> Since the application support is already given by step 2, this step is practically for free. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
