Re: domain names as end-point identifiers?

[Dave Crocker <[e-mail]>]

Folks,

Thanks for the responses.  I decided to send one, aggregate response, rather
than a flood of smaller ones:


Dredging up some graduate school discussions, I suspect that this topic is
differentiated between the classic "network" model of host to host
communication, versus the "distributed processing" model of process to process
communication.

In the early 70's, for example, the Irvine Ring project (and, by the way,
Netbios, later) use the process-oriented model. For wide-area networking, this
has not gained much traction, at the lower packet-handling levels. (It was
even interesting to watch MIT take over the Irvine work and eliminate the
process addressing function.)

My point is that I'm suspecting some folks are trying to lay a very different
reference model onto the Internet than we have been using for the last 30
years.  Hence, the discussion about multihoming and mobility gets changed into
what is really an effort to change the Internet's communication reference
paradigm.


BEC> If you are looking for stable identifiers for "stacks" (in the
BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely
BEC> that an FQDN is a safe answer.

It is probably worth noting that the NSRG report uses domain names to label
the different stacks, in its own examples and in discussion.  Whatever the
reasons for that choice, I obviously find it interesting that they were used
for that purpose.


BEC> FQDNs are (mis)used in many ways;
BEC> a name like www.example.com certainly doesn't identify a given IP stack
BEC> on a given interface on a given host

1. When someone starts talking about identifying _interfaces_ I suspect they
mean address, rather than 'end point identifier'. On the assumption that that
is not what Brian meant, it's worth having this clarified. I'm confused by
Bill's comment on this: " if there is an entity at a point in the topology,
then the name maps nicely into the DNS". Domain names are not tied to network
topology. They are tied to an administrative "topology", which is an entirely
different thing.

2. If I understand the concern, here, it is that not _all_ domain names are
endpoint identifiers. Erik also raised the point that domain names are used
for different (and inconsistent?) purposes. One might be a host, another a
service.  When there are multiple records returned, they might refer to
alternative systems or they might be alternate paths to the same service.

My question is: so why does that mean that the ones that _are_ EIDs are
not acceptable?  What problems are caused by having multiple uses?


BEC> I don't see that this has any functional advantage over an IPv6 address
BEC> for that stack, and it introduces a DNS dependency for the transport layer.

1. I thought an IPv6 address was an address, not an end-point identifier.  No?

2. The concern about introducing a DNS dependency into a lower layer, like
transport, strikes me as pretty important, too. However, if we invent a new
construct for an EID, we are a) introducing a new global administration
requirement, and b) creating a dependency on it in that lower layer. So the
concern with this new dependency is on the need for an EID, rather than the
fact that it might be a domain name. No?



MT> In the case of mobility and multihoming, you might want a stable
MT> identifier on a per-packet basis which is independent of the routing
MT> layer.

A number of folks clearly have in mind using the identifier in every packet.
My question is:  Why is this needed?  What requires putting the identifier in
every packet, rather than using it a occasional, special points of an
interaction, such as initial rendezvous?



Erik's comments are particularly helpful for considering the requirements that
folks are trying to satisfy:

EN> It might be useful to split your question apart into two questions:
EN> 1. Using current domain names and their mapping to AAAA records

(or A records or even MX records or SRV records?)  At any rate, this is the
rendezvous function.


EN> 2. Using variable length identifiers

Or, to turn this one around, explaining when and why fixed-length IDs might be
needed.


EN> For #1 folks have pointed out that a currently domain names are often used
EN> as service names and not host names, and one can't tell...

my question is what problems are caused by multiple uses for domain names?
how does it break the usage as endpoint ids?


EN> I've also seen statements in the past that current domain name usage isn't
EN> one that guarantees uniqness.

I guess this underscores the need to be clear about the set of problems being
tackled. Let's remember that IP datagrams are pretty basic. There are lots of
very clever, useful things they do _not_ do.

Are we, perhaps, trying to add other functionality to the IP service, beyond
simply providing the current IP service, enhanced to support multihoming and
mobility? For example, are we trying to add extra levels of security to the
basic service, beyond simply making the use of multiple addresses carry the
same, minimal security functions present for current, single-address IP?

The "security" associated with a current, bare-bones mono-address host-to-host
IP exchange is pretty darn small. I'd summarize it as simply being the
assertion that a datagram probably did come from the IP address in the
relevant field of the datagram. That's why MAST only tries to ensure an
equivalent degree of assurance that latter datagrams with different IP
addresses came from the same "system" that sent the first one.  If you really
need stronger security, use IPSEC, TLS, or whatever.

Why do we need more, at the IP level for multihoming or mobility?


EN> One example of this are cases when
EN> www.example.com brings you to different http content from the inside of the
EN> company than from the outside of the company.

Clearly this is an important behavior.  But should it be discerned at the IP
level, or is this better suited to something above, say, transport?


EN> I think all these can be addressed and still use FQDNs as identifiers.
EN> (For instance by having some different RRtype which allows telling "service"
EN> apart from "host".)

Not surprisingly, I agree.


EN> The issues around #2 has to do with how the protocols above IP operate.
EN> If the identifier is only used to establish some state which is only used
EN> when the locators change, then it is possible to have the upper layer protocols
EN> operate on the locators when sending and receiving packets. Thus you'd have
EN> multi-locator ULPs.
...
EN> An alternate approach, which requires fixed length identifiers which can fit
EN> into existing 128 bit fields, is to have a shim layer above IP which handles
EN> id<->locator mappings and have the ULPs operate on the identifiers.

Given the MAST proposal, obviously I favor the latter.  However it's also
clear that I do not believe the EID needs to be in every packet.

I think it is a question of where some state information goes.  One is to have
the ID in every packet, making the IP address irrelevant.  (The packet carries
its own 'state' about the EID.)  The alternative is to have a table of IP
addresses that the EID maps to, and maintain the table in the participating
hosts.  Hence the IP address in the packet indexes to the EID when it is
received.)


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------