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