On Mon, Nov 9, 2009 at 10:26 PM, Christian Vogt <[email protected]> wrote: > Let me chime in since you mention my proposal: Can you be a bit more > specific regarding these DNS issues? The idea to avoid them in > Six/One Router was to put both edge (internal) and transit (external) > addresses into the DNS, and to let the address selection mechanisms in > hosts pick an address that works best. With appropriate prefixes for > edge and transit addresses, this would work without host changes.
Hi Christian, Actually, now that you mention it, I'm coming up with a blank as to how you'd get NAT to multihome statelessly at all even assuming that session survivability over failures is not required. In our prior discussions, I always assumed that the remote translator (with his copy of a portion of the Internet's PI to PA map that includes me) would restore my PI address to the packet before delivering it to the endpoint. That's where you get unresolvable DNS issues because folks starting from PA space need to deal with the server's PA addresses while folks starting from PI space need to know the server's PI address but the client isn't asking the authority server; one in a possible chain of referal servers is. Hence Vixie's "dns lies" problem. If the remote translator, lacking my PI to PA map, passes my the PA source address my translator put on the packet all the way to you and my translator passes the PA source address your translator put on the packet all the way to me, we'll end up trying to talk to each other with different IP addresses. A PI client (A) with two ISPs and a PI server (B) with two ISPs. Ip addresses: A: 1 (internal) 2, 3 (after translation into ISP's space) B: 4 (internal) 5, 6 (after translation into ISP's space) Round trip from A to B: A->(1,5)->(2,5)->(2,4)->B->(4,2)->uh oh, how do I choose between 5 and 6? I've discarded the information that site A chose to talk to me at 5 and if I choose 6 by mistake, we'll see: (4,2)->(6,2)->(6,1)->A. A sent a packet to 5 but got back a packet from 6. Hmm. I guess if you add another constraint that a particular PI site can only have one translator then you can do stateful NAT which remembers which address to translate a particular flow back to. Let's run with that assumption for a moment... So, you're going to have regular split horizon DNS system. And outside you're going to give me all PA addresses that will translate in to your PI address. So I get a list of addresses and one of the ISPs is down right now and packets to that address are dropping into a black hole. As an app programmer I'm either going to stall for up to 2 minutes trying that address before I move to the next one, or I'm going to give up on that address early (maybe too early). Or if I'm fancy, I'll make a non-blocking connect and I'll start another non-blocking connect on the next IP address in your DNS response every 50 ms until one of them connects. Then I'll drop the others since I only needed the one. Ouch. That's not so good. Then there's the DNS pinning problem. The javascript security model falls apart if you can change the name to address binding at will. A bad actor DNS server coupled with a web server could effect a slow scan of the address space inside your firewall courtesy of the CEO and his web page with scrolling stock quotes. So, the browser won't change to a server's alternate IP address once it's picked one that works, or if it does it follows some arcane rules to avoid exposing you to a javascript attack. That's not so good either; the user hits reload and he doesn't necessarily get a shot at your other public IP address. Regards, Bill -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
