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