Thinking differently about names and addresses

[Dave Crocker <[e-mail]>]

Tony,

>> Let's assume that there is a FooBar server in SiteA.  If
>> another node in SiteA (NodeA) is communicating via a 
>> multi-party application to a node in SiteB (NodeB), and wants 
>> to refer NodeB to the FooBar server in SiteA, what does it do?

TH> Send a name.

Some sort of identifier, perhaps. The details are something we all need
to discuss (and define) separately, quietly, and carefully.

It is actually orthogonal to Site Local, though Site Local has
engendered the discussion.

In any event, please note that the suggestion that applications are
required to use names, rather than IP addresses, is new.

Completely new.

As in, it has not been part of the Internet architecture for the past 25
years.

So we all should be a tad careful about claiming that failure to use
that enhancement represents a failure.  A new idea that is good is good,
but failure to use that idea previously is not "broken".


>> If this is IPv6 with site-local addressing, NodeA may be
>> speaking to the FooBar server using a site-local address.  
>> What happens if NodeA sends that site local address to NodeB?

TH> Any app that sends topology locator information without understanding
TH> the topology is broken.

If it is trying to use it in terms of the topological information, you
are right.

However it is usually just carrying it as an opaque identifier. This is
not such an unusual or broken behavior as one might think. Using an
upper layer for context storage of strings that are meaningful to a
lower layer -- but not to the higher one -- is a well-accepted practise.

So, we now get an unusual opportunity for network layer folk and apps
layer folk to again consider the difference between naming and
addressing. Maybe we can get John Shoch to remind us of the
fundamentals. (The URI/URN confusion on this point has been a continuing
source of frustration.) The problem is that addresses are (transient)
unique identifiers, so we sometimes use them without knowing they are
addresses.


>>          - It doesn't give a good answer for what the application
>>                  should do if it only has one address available
>>                  for the referral, and it is not of sufficient scope.

TH> It absolutely does. When an app knows there is an insufficient scope,

I guess the point that it is a new requirement -- to expect an app know
about topology -- is not registering clearly enough. Perhaps it is a
reasonable requirement, but it is a major one and it is one that is
certainly not well enough understood.

There is nothing obvious, simple or historical about this requirement.

So discussion of it needs to be on a rather different basis than
inventing a new kind of IP address and then, belatedly, passing up the
requirement to apps that they deal with it differentially.


TH> I can't parse this. In any case if an application is passing topology
TH> locator information, it has to understand the topology.

Tony, I could be wrong, but I suspect that constantly repeating the same
mantra will not help any of us who are not yet enlightened to achieve
the nirvana that you are espousing.

On the other hand, it is certainly effective at making clear that our
own efforts to enlighten YOU of our own nirvana are falling far short.


>>          (1) Routing protocol issues/complexity, such as the need to
>>                  handle ambiguous addresses in routing exchanges and
>>                  the need to maintain site "convexity".  

TH> Either the addresses are ambiguous to the routing protocol, or it can
TH> deal with them. If they are ambiguous, there is no way to pass them
TH> around, so the 'need' is fabricated at best.

Clearly that is not true for Site Local addresses, or they would not be
called Site Local. Clearly the idea behind Site Local is that two
different sites can use the same addresses, while both sites are able to
reach each other. If that were NOT intended, there would be no need for
a special mechanism.

So in the context of the global Internet, those addresses are ambiguous.
Yet they are expected to be routable (within the scope of their
respective sites.)


TH> DNS passes around topology locators. Keeping it ignorant of the real
TH> topology is the poor architectural choice.

Topology changes very fast.  DNS changes very slow.

How do you propose to handle this mismatch?


TH>  If the app developers really
TH> want to keep the apps simple, they must pass around names, and let the
TH> infrastructure component tasked with keeping track of reality do the
TH> work. If apps insist on passing around topology locators rather than
TH> relying on DNS, they must understand the reality of the network they are
TH> describing.

Hmmmm.  There IS a rather interesting thought this suggests to me, namely that
an app should be able to query some service by saying something
like "I want to give destination X a reference to destination Y, please
give me the reference to Y that I should use."

The nature of that service and of the reference(s) then becomes the
discussion.


TH> The IAB really needs to take a hard look at the disconnect between the
TH> DNS as defined for the network of 20 years ago, and the real networks
TH> deployed today. No matter which prefix is used, there are addresses that
TH> have a scope limited by the filtering rules of the network manager.

Oh boy.

About 10 years ago, or so, I suggested that the IAB consider adjusting
the Internet architecture to the reality of administrative boundaries
for more than addressing. Firewalls were already a factor and NATs were
coming up fast.

Perhaps we are now ready for that topic.


TH> Passing these around only serves to confuse apps, because DNS claims
TH> that the node is accessible by a particular topology locator,

Strictly speaking, the DNS does not signal reachability.

It simply gives a strong hint about an address that stands some chance
of being reachable.


d/
--
 Dave Crocker <mailto:[e-mail]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>, <fax:[phone]>