RE: Thinking differently about names and addresses

["Tony Hain" <[e-mail]>]

Dave Crocker wrote:
> TH> Send a name.
> 
> Some sort of identifier, perhaps. The details are something 
> we all need to discuss (and define) separately, quietly, and 
> carefully.

Any other identifier will need to have all the properties of the FQDN,
as well as have a secure mechanism for the owning node to update the
binding to the current set of topology locators. 

> 
> 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.

It is derived from the position that applications shouldn't know about
topology. In general I agree, but that means they need to stop dealing
with topologically significant entities.

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

That is not clear, but in any case the deployed Internet is not the same
as it was 25 years ago. From RFC 791;
    A distinction is made between names, addresses, and routes [4].   A
    name indicates what we seek.  An address indicates where it is.  A
    route indicates how to get there.  The internet protocol deals
    primarily with addresses.  It is the task of higher level (i.e.,
    host-to-host or application) protocols to make the mapping from
    names to addresses.   The internet module maps internet addresses to
    local net addresses.  It is the task of lower level (i.e., local net
    or gateways) procedures to make the mapping from local net addresses
    to routes.
Mapping names to addresses is a simple task. One could argue that it was
so simple that apps took the shortcut of using the 'where' to also
define the 'what'. That does not mean the requirement for apps to keep a
clear context for 'what' is a new requirement. 

> 
> 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".

In the Internet of 25 years ago, there were no filters that limited
scope, so an app could get away with passing around mixed 'what'/'where'
tags. The current world exposes that shortcut, and arguably identifies
its failures. 

> 
> 
> >> 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 
> TH> understanding 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.

I understand the intent here, but passing information outside its realm
of applicability is broken. Turn on the wayback machine and consider the
effect of passing a bitnet address across the gateway, or an internet
address back. The receiver must have a context or the identifier is
meaningless. The same is true with passing IP addresses outside of a
filtering router, no matter which prefix is being used.

> 
> 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.

The multi6 list recently had a long discussion on this point.
Unfortunately that effort is all about creating yet another layer of
mapping between names and addresses, but misses the point that it
requires all of the binding security and update processes that are
already defined for DNS.

> 
> 
> >>          - 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 
> TH> 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.

I am not arguing that all apps need to know about topology, just those
that insist on passing around topology locators. Basically, the app
needs to know what it is doing.

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

Again from 791;
    Care must be taken in mapping internet addresses to local net
    addresses; a single physical host must be able to act as if it were
    several distinct hosts to the extent of using several distinct
    internet addresses.  Some hosts will also have several physical
    interfaces (multi-homing).
If apps didn't keep straight how to deal with hosts with multiple
physical interfaces, they would fail to operate. To some degree, that
means keeping track of topology. I agree the filtering came later, but
the basic requirement has been there all along.


> 
> 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.

It is not a new kind of address, it is RFC 1918 in a single block. In
general apps should not need to treat SL differently. The only time it
becomes a problem is when the app passes an address rather than a name.
As long as the source of name to address mapping is providing
topologically correct answers, the app can be oblivious. 

> 
> 
> TH> I can't parse this. In any case if an application is passing 
> TH> topology 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.

Sorry for the repetition. It has become habit in response to the
repetitive FUD on the SL discussions.

> 
> 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.

I understand the desire for the apps to simply pass information to a
peer, and in the network of 25 years ago that worked. Unfortunately for
the network of today it doesn't. Something needs to keep the information
consistent with the deployed network, and if apps don't want to do that
then they should use names and let the name resolution process sort out
reality.

> 
> 
> >>          (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 
> TH> can deal with them. If they are ambiguous, there is no 
> way to pass 
> TH> them 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. 

This is part of the FUD & confusion propegated through the presentation
to the apps area, as well as those who simply want to pretend that local
scope addresses don't exist. The reality is that two networks that use
ambiguous addresses can't just route to each other, because the routing
protocol can't sort out the ambiguity. Where the multiparty app issue
comes in is when the networks have both SL & global addresses, and the
global addresses are routed to each other. In this case, the name to
address mechansim needs to keep the SL mappings in the correct realm of
applicability, and apps that pass addresses need to do the same.

> If that were 
> NOT intended, there would be no need for a special mechanism.

In the general case there is no need, but the FUD makes it sound like
every app will have to change.

> 
> 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.)

This is the intent, and as long as the address references stay within
the appropriate scope, applications can treat them as any other address.
Also, having a well-known prefix allows apps that want to stay on the
inside of a known filter to figure that out. For example, the file
sharing process can choose to only bind to the filtered address so that
it is not globally reachable, while other processes on the same machine
can use an available global scope address. Some argue that this can be
done with appropriate router filters, which it can as long as the router
can do fast deep packet inspection to find the port #, and that the
network manager knows all the possible port #'s for apps that should be
filtered. It is much simpler to put the policy decision at the endpoint
where it is needed. 

> 
> 
> 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?

Topology changes quickly, but the topology locator currently does not.
There have been discussions about changing locators more rapidly than
DNS can handle, but whatever happens there will have to deal with the
need to securely update the globally distributed caches, so it won't
happen much faster than DNS could with appropriate operational
adjustments.

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

Agree, but why do that rather than tell X to look up Y? For you to
figure out who to ask would be a big deal, but X already knows how to
resolve names that are appropriate for its perspective.

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

Ready or not, it needs to happen.

> 
> 
> 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.
> 

I agree that a record doesn't indicate reachability, so I wasn't crisp
because the part you cut off was my point. In the X, Y example above, if
there wasn't a record for Y available to X, it would know that without
waiting. 

Tony