Pete Resnick wrote: > On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: > >> Lixia Zhang wrote: >>> I believe that people in general agree that applications should not >>> use IP address for referrals. >> >> I don't know which people you're referring to there, but that's >> absolutely not the case for application developers. In the current >> internet, use of IP addresses for referrals is essential. > > That IP addresses are currently essential for referral is not mutually > exclusive with the idea that applications should not use IP addresses > for referrals. Let me put it a different way: Many of us look forward to a day when some other token, identifier, structure than an IP address will suffice for referrals from and to anywhere in the network, and this will work so universally and reliably that there will be no need whatsoever to use IP addresses in referrals. However that's an incredibly difficult problem to solve, especially as long as the network contains a large number of NATs in arbitrary locations. At the rate we are going now, I'll be very surprised to see that problem solved before I die. > And in fact every application that uses DNS does exactly that. > > I think that's a rather narrow view of where DNS falls in the architecture. A and AAAA records are address referrals. >> It's all well and good to imagine a world where there would be a clear >> ID-LOC separation. But we've never created such a world, and we don't >> currently have an ID-LOC mapping layer that is good enough to use by >> all applications. > > Yup. In part, that's what LISP is about. Except that LISP doesn't actually define the mechanism to do the mapping (i.e. maintain the bindings and allow them to be queried), and that's the hard part of the problem. At least, it's the hard part of the problem if you believe that ID-LOC separation can solve the problem of referrals in the presence of NATs (and maybe some of the other problems caused by NATs). If you're just trying to solve the routing scalability problem the mapping is somewhat easier to accomplish, but then you need yet another mapping layer to deal with NATs...back to square one. > But I actually think it's incorrect to talk about having "an ID-LOC > mapping layer good enough to use by all applications". If we're > talking about the ideal world, applications should almost never need > to use the mapping layer; they should be able to simply use the ID > (without touching the LOC) and let the routing system deal with > finding a LOC for the ID. That an application would have to actually > deal with the mapping is an artifact of the current state of affairs > where neither the LOC (IP address) or ID (DNS) is good enough to > allow the application to do what it needs to do. Oh it's perfectly fine with me if the mapping isn't dealt with explicitly by applications - provided of course, that it works so well that applications never have a need to deal with it explicitly. There's the rub. >> DNS falls short in many ways. And as long as there is not a universal >> mapping layer that is aware of things like NATs and mobility, and for >> that matter as long as there are devices that impose arbitrary >> limitations on traffic flow (e.g. connections have to be initiated >> from "inside"), there will be a need for applications to deal >> explicitly with IP addresses. Sure it's ugly but it's the best that >> applications can do. > > I'm guessing we're in violent agreement, but NATs and mobility and > "traffic flow limiters" actually make it impossible (viewing it from the > other end) to use IP addresses: Giving a reference to myself using my > own IP address when I am behind a NAT is useless; using a name, if one > is available, is the only way to go. Actually, the internal IP address is not useless at all, as (a) it's still often the best identifer for use with other hosts in the same realm and (b) it is useful to compare with the external IP address (as obtained by STUN or UPnP or by talking to a peer) to determine if one is behind a NAT. Nor is the DNS name the "only way to go" as a DNS query by a peer might or might not yield a useful result, and two-faced DNS doesn't work very well, and there are the usual reliability problems with DNS (especially when making queries through NATs that have buggy DNS proxies). Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf