I recently had this exchange with Dan Wing on the BEHAVE list: >> > ... it seems to me >> > that we might consider defining a generic 'referral object', containing >> > more information than just an address, that could be passed among >> > application entities. It could contain TLVs that would provide the >> > semantics of the referred address as well as the raw address bits. >> > >> > Does this seem worth exploring? > > Yes, this could form the basis for very useful guidance to application > designers. ICE does something like this already, but abstracting its > functions up several levels, as you propose, would be useful. > > Something like: "here is my IPv4 address, it goes through a > translator so avoid using it if you can utilize my IPv6 address" > and so on. Brian On 2009-03-20 07:04, 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. IP addresses fail for referrals in a vast number of cases > including 1918 addresses, firewalled networks, certain asymmetric > routing cases, etc. Given the current state of the network, you can > neither recommend nor completely forbid the use of IP addresses for > referrals in applications. (And nowhere in what Lixia said was the > statement that applications MUST NOT use IP addresses for referrals.) > >> 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. > >> 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. 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. > >> 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. (And I still agree with your above > paragraph.) > > pr _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf