Fred Baker wrote: > > On Mar 23, 2009, at 12:47 PM, Keith Moore wrote: >> I'm arguing that applications need to be able to accept traffic at >> global addresses in order to implement that reliably and without a lot >> of additional complexity. The app doesn't care what the address looks >> like on the wire, but it does (ideally) want the address to be the same >> for each of it its (current and potential) peers. That's by far the >> simplest model for an application to deal with. > > Hmm. There goes mobile IP.
mobile IP, NATs, multiple prefixes advertised for a v6 network, multiple active interfaces for a host - all of these make life more complicated for applications. (you'd hear more screaming about mobile IP from apps developers if it were more widely deployed. you'd also hear screaming about VPNs from apps developers if it weren't common to shut down all other paths to a host whenever it has a IPsec link to a VPN.) > > Tell me this. In the following picture > > > +-----+ | > |ISP 1|--+ > | DMZ | | > /+-----+ | > / | > / +-----+ | +---+ > +---+ / |ISP 2|--+-+ B | > | A +---- The Internet -----+ DMZ | | +---+ > +---+ \ +-----+ | > \ | > \ +-----+ | > \|ISP 3|--+ > | DMZ | | > +-----+ | > > B has three AAAA resource records giving it three different addresses. A > can easily select one by whatever algorithm it is using and use it. As > far as B knows, the one A selected was its ULA. > > It seems like we accomplished your goal....? sort of. B thinks its traffic arrived at a ULA, but B presumably can't use that ULA as a referral address as it won't work everywhere, and B really has no idea whether the ULA is reachable by any particular (current or potential) peer. That might be fine as long as (a) B can obtain a sufficiently stable referral address that works from anywhere (modulo policy), (b) that mechanism for obtaining a referral address works for any application that needs to do referrals, (c) this mechanism works from anywhere in the network that isn't using stable, global addresses, not just from places that are using this particular kind of setup. (in short, we need to define a universal way for apps to do referrals that works no matter where the peers are.) A might see a view of B that has 3 (or fewer) addresses. This is not a big deal, provided all of those external addresses are highly reliable, equally usable, and sufficiently stable, so that A's choice of which external address rarely matters. But those are important conditions that are not always met in practice. >> Whenever a NAT (any kind of NAT) provides additional addresses at which >> an application can accept traffic (and if there's any bias at all such >> that some of those addresses work better than others for a given peer), >> that increases the burden on the application, because it has to make a >> good choice about which source and destination addresses to use. (The >> burden is even worse for P2P apps.) In the extreme case this is about >> reachability, in less extreme cases it's about performance and >> reliability, but it's more-or-less the same issue. > > You're aware that it doesn't take a NAT to provide multiple addresses - > all it takes is a multihomed host. Right? Does a multihomed host have > the issues you are concerned about? If not, why not? yes, it does. and it's one reason that multihomed hosts were rarely used in IPv4 - they tended to break things. >> The application doesn't care about the exact number of the address. >> However it might care that the same address work for all of its peers, >> or that if it opens multiple connections to a peer that they all >> originate at the same address, or that each of its peers to which it has >> an open connection will see the same source address, etc. > > OK. So what you told me was, perhaps, that hairpinning is a concern. hairpinning is certainly necessary. > From my perspective, if a host B' in B's network tries to use one of its > external addresses rather than preferring the address available behind > the DMZ, it didn't correctly execute the algorithm in RFC 3484, which > calls for it to prefer the address most similar to its own. I have never considered RFC 3484 workable. It might almost be reasonable as a default behavior for APIs, but it's clearly not reasonable to insist that all hosts/apps behave that way. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
