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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf