Excerpts from William Herrin on Mon, Nov 16, 2009 09:24:36PM -0500: > A is a client talking to a multihomed server B. > > Ip addresses: > A: 1 > B: 2 (internal) 3, 4 (external) > > Round trip from A to B: > A picks address 3 via DNS. > A->(1,3)->(1,2)->B->(2,1)->[(3,1),(4,1)]->A > > The problem is that A received a return packet from B that might > have been from 3 and might have been from 4. But A has no idea what > to do with a packet from 4. > > Per Michael, the solution is either: > > 1. Stateful NAT. The translator on B's network handles both network > paths and remembers that the communication from A came to > destination 3 so that he can put source 3 back on the outbound > packet. > > 2. Host modification. The inbound NAT adds an IP extension with the > original destination address. The host echos this in the return > packet, providing the outbound NAT with the info he needs to set the > correct external source address.
Another possibility is to decouple establishment of higher layer state from the IP locators the packets come tagged with. For example, if they are using TCP and the correct tokens are provided with SYN etc., then the result of having packets sourced from "unexpected" locators is that endpoints learn new locators that could be used for the session -- not that the session can't be initiated. In general, a number of the problems that routing and addressing face simply go away if the endpoints are told that it's the new millennium and it's time they acted like adults. Endpoints will need to be able to do this anyway, since no matter what you do in particular networks, the endpoints may always end up in a situation where they have to take care of themselves. As long as we're doing long-term architecture (in the rRg), let's set a goal of solving problems where the roots of the problems are. Then we work back from that to provide interim bandaids for curdmudgeonly old endpoints that don't know how to use the new Internet yet. Excerpts from Noel Chiappa on Mon, Nov 16, 2009 10:29:40PM -0500: > > 2. Host modification. ... The host echos this in the return > > packet > > Well, the second is clearly infeasible. It's infeasible because it once again carries locators as payload. The NATs shall always be with you. An endpoint should assume that what it sees of locators may be totally different from what its correspondent sees. > I wonder if we can say that, at an architectural level, wrapping > solutions - or, more generally, any solutions which carry both the > locator and the identifier in the packets - are inherently and > inescapably superior? No :-). Any solution which separates identification from location is superior, but there is no need to carry node-level identifiers in any packet at all. Who benefits from that? Routing and location don't care -- they only benefit from a whole-node identifier if they are trying to solve problems that have been laid on them by the laziness of higher layer functions. Endpoints have all sorts of identification functions, but a whole-node identifier does not satisfy all of them, nor can it alone be used by any of them. Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
