On Oct 27, 2010, at 1:35 PM, Fred Baker wrote: > > On Oct 27, 2010, at 9:08 AM, Keith Moore wrote: >>> I still don't understand the reason you need your *external* addresses >>> apart from populating DDNS. >> >> That app still needs an address that functions as a referral address for any >> host to which it might need to make a referral. And the app has no way of >> knowing which realms those hosts are in. So basically it needs a global >> address. > > Well, and it needs to supply both IPv4 and IPv6 addresses when appropriate, > and there may be multiple of each that might be relevant. To me, that > translates to "DNS Name".
The DNS name doesn't really solve the problem, at best it just moves it. In one case, peer B gets a list of IPv4 and/or IPv6 addresses from peer A. In another case, peer B gets one or more DNS names from peer A which can be used to obtain a list of IPv4 and/or IPv6 addresses. Either way, peer B still has the problem of figuring out which of those addresses to use given that there might be NATs, firewalls, ALGs, interception proxies, traffic shapers, etc. in the way; and that some of the addresses which were useful in peer A's scope might not be useful in peer B's scope. > If it really has to be a literal, which I already pointed out has some > brain-deadness related to IPv4 and IPv6 routing (the fact that you and I both > have an IPv[46] address doesn't mean that the network has a route that > connects them, even if the addresses are global). But that is not is not its > *own* address; it is the address of a neighbor. The referral doesn't have to be a literal in all cases, but a DNS name is not a general solution that applications developers can use. DNS wasn't designed for this, and in practice it's just too dysfunctional in too many ways for this. (And it is an Extremely Bad Idea to try to make DNS smart enough to do address selection on behalf of hosts/apps. That would be like trying to live on the fourth story of a house of playing cards.) >> There are lots of problems with relying on DNS to do referrals which have >> been reiterated several times. The bottom line is that DNS is one way of >> doing referrals which is suitable in many cases, but far from suitable for >> every case. > > If you are adamant that the web/sip/whatever referral can't be a DNS name, > will you allow the referring host to look it up in DNS? As noted, DNS will > have the external addresses of any system it has a name for. see above. A DNS name is not a general solution. It's certainly not suitable for widespread use in SIP. If you try to insist that all apps use DNS for referrals you're basically requiring all apps that do referrals to maintain their own DNS space (probably with a separate zone for each instance of the app) and generate/distribute credentials for every instance of their app. DNS doesn't even begin to have the kind of support that is needed for that - existing DNS servers, resolvers, and libraries aren't written to handle that, it would make the apps extremely fragile to various kinds of attack, DNS doesn't have suitable RR types, DNS's TTL-based caching mechanism isn't well suited for this, some ISPs block DNS updates from port 53, it wouldn't work on an isolated LAN or other ad-hoc network, etc., etc. It's a complete non-starter. >>> In private email to someone else that was requesting that hosts implement >>> the expired SAF virtual interface functionality, I said the following. Tell >>> me, if you would, where I'm wrong? >> >> You cannot impose NAT > > In several statements here you make the statement "you...impose NAT". Note > that I am, and Margaret is, doing nothing of the kind. Network operators are > trying to solve a very real problem, one that has been articulated in detail, > and Margaret and I are providing a tool to enable them to do that. Absent the > problem, the solution isn't needed and won't be deployed. The folks on this > list that have been telling you that they plan to deploy something are > telling you they have a problem that needs to be solved. I certainly acknowledge that the problem NAT66 is trying to address really does need to be solved. But in the process of trying to solve it what you're also trying to do is get IETF endorsement for a kind of NAT (think slippery slope), and you're also trying to do that without addressing many of the problems that NATs are well known to cause for applications (think bad precedent). I also agree that we need NAT46 and NAT64 for transition purposes, and I acknowledge that (whether it makes good technical sense or not) there is market demand for other kinds of NAT. So I accept that we're going to have some amount of NAT (and also multiple kinds of NAT) in the network for the forseeable future. What I think we probably need to do, then, are the following: - Define a single, standard, mechanism that applies regardless of which kind of NATs are being used, that lets applications cope. This includes things like finding an global transport address that's associated with an internal transport address, creating bindings (subject to policy) that allow incoming connections, maintaining bindings in stateful NATs, destroying bindings when they're no longer used, hooks to allow both application and host OS access to such functions, support for split NAT, etc. (for there to be a single standard mechanism it has to be more versatile than NAT66 needs) - Standardize such NATs as are found to be strictly necessary, but do so in such a way that minimizes the harm done by NATs (e.g. by requiring support for hairpinning or something similar) and by requiring support for the above mechanism. - Continue to work to provide better solutions to the problems that NATs purport to solve, so as to encourage adoption of better alternatives. > I agree that host upgrades should not be required. That is the reason that > Margaret and I are proposing a solution that doesn't require host upgrades > that we know of. But it does require host upgrades. Not to the host OS, perhaps, but the apps on the hosts still have to be changed. You can't expect apps to work without change in a world where some of their peers need one kind of address and other of their peers need an address from a different realm, and the apps have no good way of finding out which addresses work where. I mean, ideally, in a NAT66 world apps that do referrals could always use their external addresses, and the NATs would be required to do hairpinning. But even that is suboptimal for both the router and the LAN. You also want the apps to be able to find their peers even if they find themselves disconnected from their external network access - so long as those peers are reachable of course. The NAT shouldn't have to be reachable for that to work. >> Ideally, the application doesn't want to fool with address selection. But >> unless the host stack and/or network do a good job of getting packets from >> the source to the destination, via an effective route and without corrupting >> those packets, some applications are forced to deal with such things. > > "Happy Eyeballs". > http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6. If the > socket API were rationally designed, what it is saying would be buried in a > connect_to_name() call that was handed a name and returned a connected socket > or an error. I agree that the OS should supply this. The socket API isn't > designed that way; the application is forced to supply the missing code. > Sorry, not my choice. I believe that this is being discussed in apparea. I appreciate the intent, but the approach is very naive. Often it's not a question of whether IPv4 or IPv6 is broken. They're both broken in different ways, the kind of breakage depends on the source-destination address pair, and the optimal choice depends both on the specific kind of application and kind of breakage. You'll get vastly different results using native ipv4 with a local destination address, linklocal ipv4 address, native ipv4 with a global destination address, native ipv4 with one of the addresses behind a NAT, native ipv4 with both addresses behind different NATs, 6to4 addresses, teredo, ipv6 using tunnel broker, linklocal ipv6, global ipv6. ULIAs, host VPNs, mobile IP, all throw other wrenches into the works. There is no way to "rationally design" this into the socket layer because the host/socket library simply doesn't have the kind of information required to make these decisions at the granularity that is needed. (generally, neither does the app, but at least the app knows what kind of service it needs, which is more than the socket API knows.) And the reason the socket API doesn't have that kind of information is because the network wasn't designed to provide that kind of information to hosts. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
