Subject: RE: A roadmap for end-point identifiers? (was Re: where the indirection layer belongs)

From: "Michel Py" <[email-masked]>
Date: Wed, 10 Sep 2003 09:02:14 -0700

Pekka,

>> Iljitsch van Beijnum wrote:
>> Are you saying that we should make a clear distinction
>> between identifiers and locators, and not have any values
>> that are valid in both realms?

> Pekka Nikander wrote:
> Yes, in the long run.

Would that include going to identifiers that are longer than 128 bits?

> In the short run, we probably have to continue living in a
> world where there is no clear distinction between the two.

Sorry if I ask a stupid question, but the main issue deployment issue
HIP has is basically that every host would need an HIP stack. Since
there is not much you can't do about this, why haven't you pushed the
reasoning further and opted for an extended HIT that would not have some
of the current limitations (background: we did discuss the issue in
Atlanta and one of the things I recalled is that we both wished we had
more bits).

> I do understand your point about the benefits of an
> identifier also being a locator, but I also believe
> that the benefits of clean separation will more than
> pay the drawbacks in the long run. (I don't have any
> analysis or data to support this belief, though.)

I'd be interested in some vague rationale about this.

> Nodes with well-known addresses, such as servers and those
> using stateful configuration, are most vulnerable. Nodes
> that are a part of the network infrastructure, such as DNS
> servers, are particularly interesting targets for attackers,

To put this in context, the paragraph above assumes that the server is
being accessed using the identifier, and that the hackers targets the
id/loc mapping mechanism in order to map the id to _his_ locs, not the
legit ones. 

Did I get this right? And if I did, what difference does it make if the
locators and the identifiers are segregated?

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Sep 2003 12:28:08 +0300

Michel,

[Sorry for the late reply.  Cross-posted to HIPSEC since
  there is the specific question about HIT length.  Please
  adjust your reply list.]

Iljitsch van Beijnum wrote:
>>> Are you saying that we should make a clear distinction between
>>> identifiers and locators, and not have any values that are valid
>>> in both realms?

> Would that include going to identifiers that are longer than 128

[I think I answered this separately already elsewhere.  Anyway.]
No, just making a clear distinction does not necessarily mean
that we have to go into identifiers longer than 128 bits.  On
the other hand, I do think that there are other reasons for going
to primary identifiers that are (considerably) longer than 128 bits.

> Sorry if I ask a stupid question, but the main deployment issue HIP
> has is basically that every host would need an HIP stack.

Yes.  If HIP is a solution for something, the hosts that want
to benefit from that solution have to implement HIP in their
stack.  On the other hand, HIP does not prevent nodes from using
legacy IPv4/IPv6 in parallel with HIP.

> Since there is not much you can't do about [requiring a HIP stack in
> participating hosts], why haven't you pushed the reasoning further
> and opted for an extended HIT that would not have some of the current
> limitations (background: we did discuss the issue in Atlanta and one
> of the things I recalled is that we both wished we had more bits).

Yes, we discussed this in Atlanta.  And yes, I think we could
fairly easily go to e.g. 256 bit HITs, if desired.  However,
the probability of collisions with 126 bit HITs seems to be
low enough so that I don't see any specific reasons to go to
256 bit HITs, at least not yet.

I don't remember any more what might have been the reasons
for having more bits.  Could you please remind me?

Anyway, this is certainly something that needs to be
reconsidered if HIP ever becomes a standards track protocol.

>> I do understand [the] point about the benefits of an identifier
>> also being a locator, but I also believe that the benefits of clean
>> separation will more than pay the drawbacks in the long run. (I
>> don't have any analysis or data to support this belief, though.)
> 

In a separate mail (CC:d to IPv6 list only).

>> Nodes with well-known addresses, such as servers and those using
>> stateful configuration, are most vulnerable. Nodes that are a part
>> of the network infrastructure, such as DNS servers, are
>> particularly interesting targets for attackers,
> 
> To put this in context, the paragraph above assumes that the server
> is being accessed using the identifier, and that the hackers targets
> the id/loc mapping mechanism in order to map the id to _his_ locs,
> not the legit ones.

Actually, not quite.  In its most simple form, it merely states
that if you know someone's address, it is easy to launch a flooding
DoS attack towards that someone.  On the other hand, if you don't
know the address, it is much harder.  But there are also other,
more complex reasons buried within the sentence, if I recall correctly.

And again:  The potential flooding DoS attacks opened by mobility
and multi-address multi-homing are much more serious than the
currently possible ICMP/UDP/TCP SYN DDoS reflection attacks.
Without proper protection, mobility and/or multi-address multi-homing
allow an attacker to redirect whole packet streams, and even keep
them running with a fairly simple bit of acknowledgement prediction.

> Did I get this right? And if I did, what difference does it make if
> the locators and the identifiers are segregated?

If the identifiers and locators are separated, it is no longer
important to defend individual IP address of *most* nodes.  That is,
in the most typical case you don't care what your IP address is,
and if one address doesn't work, you can try to pick a new one.

However, at least DNS servers (or id/loc mapping servers) would
continue to need having stable IP addresses.  Hence, their address
would still need to be protected.

Whether this really presents a difference remains to be fully analyzed.

--Pekka Nikander

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Sep 2003 12:54:51 +0300

Michel,

> I'd be interested in some vague rationale about this.

So, the question is about either using identifiers that
sometimes are also locators vs. using identifiers that
never are locators.  If we could use identifiers that
are always also locators, we would not need this discussion
at all; the current IP addresses should do well.

Now, if we use identifiers that are never locators, the
situation seems to be semantically simple to me.  An
identifier identifies a (potential) end-point of communication.
However, it alone is not enough for communication.  You
also need to get the locator (the address), in some way
or another.

On the other hand, if we use identifiers that are sometimes
also locators, I'm afraid of semantic confusion.  How do
you know if a given identifier can be used as a locator
or not?  If you encode it somehow to the bits, then you
are actually going into the clean separation anyway, and
could can proceed and create distinct APIs, if that is
useful.  If you do not encode the difference into the bits,
then you have to "try" in some way or another.  That is,
you may try to use the identifier as a locator and see
what happens, or use some infrastructure to find out.
These all seem to be complicated.

The reason why some people seem to dislike non-locator
identifiers is that they may be hard to be used for referral.
That is, if you send just an non-locator identifier to
another host in an p2p kind of application, that other
host may not be able to use the identifier to contact
the host.  I think this concern is a consequence of less
than perfect understanding of the situation.

I just want to remind that identification and rendezvous
are different functions.  In my opinion, identifiers
should be used for identification, i.e., to make sure
that the peer is really the end-point that it is thought
to be.  (Hence I also believe that identifiers should be
self-authenticating, i.e., public keys.)   For rendezvous,
we obviously need either a locator or a name that can
be convered into an address.

Given this background, I don't see any immediate drawbacks
from the following approach to referral.  When a host want
to send an end-point identifier to another host, it always
includes either a currently known working address for the
identifier, a name (e.g. DNS name) that can be easily
converted to an address, or both.  Of course, if identifiers
were DNS names, this would always be the case.  On the other
hand, the DNS names do not fulfil the identifiability and
security goals that I have in mind.  Hence, it looks like
that sending an <identifier, address> or <identifier, name>
pair would be a fairly decent practise.

[Sidenote:  Taking another angle, we could even define that
  an identifier is always a <public key, DNS name, signature>
  triplet.  In that way we would have identifiers that are
  both secure (without a PKI) and resolvable.]

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 15 Sep 2003 13:00:51 +0200

On maandag, sep 15, 2003, at 11:54 Europe/Amsterdam, Pekka Nikander 
wrote:

> never are locators.

> situation seems to be semantically simple to me.

Maybe in theory. In practice, when you see a 128 bit value in a place 
where you would expect an IPv6 address, you not only want to know 
whether it's an identifier or a locator (this part would be easy) but 
also if it's used in the context of multihomed communication or in the 
context of single homed communication. That's the hard part. It should 
be possible to make the three (legacy, id and loc) not overlap, but 
that doesn't solve all potential problems. For instance, when a group 
of hosts participate in a group session, the multihoming aware hosts 
would probably exchange the identifiers to new group members, but if a 
host that doesn't support multihoming receives a reference to an 
identifier, it can't do anything useful with it.

> or not?

You can either assume the identifier is a reachable locator (having the 
identifier be an _unreachable_ locator isn't very smart) and use it. 
This is what non multihoming aware systems will be doing anyway. Or you 
can look up the identifier in the mapping database to get the full set 
of locators.

What I'd like to see is doing #1 first, and only do #2 when #1 doesn't 
work. But if you don't like the ambiguity of having an identifier that 
may or may not be a locator, stamp on the letters "ID" in large type in 
a bright color and only use values that you encounter in an identifier 
context only as id. Then do the locator lookup when you need locators. 
The fact that a locator happens to be the same 128 bit value as your 
identifier shouldn't matter.

> than perfect understanding of the situation.

No, it's a backward compatibility issue, as I described above.

>  both secure (without a PKI) and resolvable.]

The usefulness of public key mechanisms for authentication is that it 
moves the authentication checks largely offline: you can see if someone 
is who they claim to be without having to contact some kind of 
authority. Using these mechanisms in cases where the availability of an 
authority can be assumed (i.e., when you can look the whole thing up in 
the DNS) doesn't make much sense to me.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 15 Sep 2003 14:26:27 +0300

Iljitsch,

It looks like that we are speaking about different issues.

I was trying to analyse the long term consequences of
various practises.  I fully agree that we most probably
need to have identifiers that are also locators for quite
some time.  (That's why I think Hinden/Haberman addresses
are probably good, even though they act as locators only
locally.)

Furthermore, I am not so much concerned about multi-homing.
Multi-homing is only one aspect.  Remember that I was not
posting the message to multi6.  There are also other needs for
stable end-point identifiers.

> where you would expect an IPv6 address,

I was not really discussing backwards API issues either.
If we go for a real separation of locators and identifiers,
we will also have to define new APIs in the longer run.
And slightly revised transport protocols, too.
(I know, the need to revise is actually *a* reason for doing
the separation at the transport, e.g. using SCTP.  But there
are other issues that make a separate layer more attractive,
IMHO.)

> you not only want to know whether it's an identifier or
> a locator (this part would be easy) but also if it's used
> in the context of multihomed communication or in the 
> context of single homed communication. That's the hard part. 

Sorry, but now I don't understand your thinking at all.  Firstly,
I still think that if we mix the two, it would be hard to know
which one an item is.  Secondly, I honestly don't understand
why one should see any difference between singly homed or
multi-homed communication.  It really looks like that we are
speaking about really different things.

Would you please clarify?

> identifier be an _unreachable_ locator isn't very smart) and use it. 

To me it looks like that you are going back to the current
situation, where the locators and identifiers are overloaded.

> No, it's a backward compatibility issue, as I described above.

I still don't understand.  I am sorry, but seemingly I just
cannot grasp your reference of thinking.

> authority. 

Indeed...

> Using these mechanisms in cases where the availability of an 

Firstly, we still don't have secure DNS.  Secondly, having to
rely on an authority seems like a bad approach to me.  At least
when compared to one where you don't need to rely on authority.
(Just can't resist:  Could we compare this to the difference
between Aristolean scholastics and Baconian science? :-)

--Pekka Nikander

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Sep 2003 08:31:56 -0400

> converted to an address, or both.

DNS names are not sufficient for rendezvous or referral.
see http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id.html

In a world where IP addresses change without notice, IP addresses
aren't sufficient for rendezvous or referral either.

While there might be reasons to have identifiers instead of locators
other than the fact that IP address-to-host bindings are becoming ephemeral,
the immediate problem is that we don't have good host identifiers that
can be used for rendezvous or referral.  

--

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 15 Sep 2003 19:07:18 +0200

Hi Pekka,

[...]
> identifiers is that they may be hard to be used for referral.

IMHO an important benefit of having locator identifier is that it just works
without additional stuff for a big number of hosts. I mean, regular non
mobile non multi-homed hosts (which i think they are a lot) just do not need
all this stuff. So having locator identifiers just works fine for them.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Sep 2003 00:22:12 +0200

Hi Pekka,

On maandag, sep 15, 2003, at 13:26 Europe/Amsterdam, Pekka Nikander 

> are probably good, even though they act as locators only

We may indeed be talking about different aspects of this huge 
multi-faceted problem/opportunity.

I think unique local addresses can make for good identifiers that are 
also locators, but only if you make the assumption they're only used as 
reachable legacy addresses or locators if there is nothing else 
available. If you're not going to be able to reach the identifier as a 
locator, your _really_ want to know that immediately so you can proceed 
to do a locator lookup rather than first timeout on a single homed 
compatible connect. This implies that when two different organizations 
merge their networks clients will continue to use the PA addresses if 
these are available. It also means those addresses are of little use 
for legacy operation.

> stable end-point identifiers.

Like what?  :-)

Multihoming is the most pressing problem because there is no good 
alternative.

> And slightly revised transport protocols, too.

Are you sure we won't be seeing IP version number depletion before that?

What exactly do you want to change about the APIs and transport 
protocols?

> the separation at the transport, e.g. using SCTP.

Note that SCTP is cool in some regards but it in no way does a 
locator/identifier separation. Actually SCTP only makes things worse as 
you now have even more addresses to worry about at the application 
level.

>> in the context of multihomed communication or in the context of 
>> single homed communication. That's the hard part.

> which one an item is.

The question here is whether we're going to see those locators and/or 
identifiers outside of a locator of identifier context, and, if we do, 
whether it's important that we can regain such a context.

> Secondly, I honestly don't understand

Not so much multihomed or single homed, but mulithoming (loc/id) aware 
or non multihoming aware.

>> You can either assume the identifier is a reachable locator (having 
>> the identifier be an _unreachable_ locator isn't very smart) and use 
>> it.

> situation, where the locators and identifiers are overloaded.

Not really. An identifier is fixed, a locator is subject to change. 
That doesn't mean they can't be the same at one time or another, as 
long as the value can be changed in the places where it's a locator 
while it stays the same in the places where it acts as an identifier.

>> authority can be assumed (i.e., when you can look the whole thing up 
>> in the DNS) doesn't make much sense to me.

> Firstly, we still don't have secure DNS.

The DNS is secure enough more than 99% of the time.

> Secondly, having to

I agree that the current way of doing it where I go ask some root 
nameservers to give me a pointer to my neighbor can be pretty pathetic 
at times. On the other hand it's the only way to find unknown 
correspondents that makes sense.

> between Aristolean scholastics and Baconian science? :-)

Feel free... Me, I'm more of the Cartesian persuasion when it comes to 
this.

 From another message:

> I think that most of the threats and much of the solution
> model would most probably apply also to SCTP ADD-IP and, of course,
> also other multi-address multi-homing solutions.

You're assuming a view of the world that is very much MIP-inspired. 
There are other ways to do it. One would be a distributed database 
where the id->loc mappings are kept for everyone to find, another is 
setting up shared state at the start of an association and use that to 
authenticate address jumps. Then, unless you're dealing with a man in 
the middle, you can be sure you're still talking to the same person as 
before.

Iljitsch

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 17 Sep 2003 15:22:17 +0300

Iljitsch,

>> I was not really discussing backwards API issues either. If we go
>> for a real separation of locators and identifiers, we will also
>> have to define new APIs in the longer run. And slightly revised
>> transport protocols, too.
 >
> <snip> 
 >

Well, I do not exactly /want/ to change the APIs or tranport protocols.
I only *anticipate* that due to mobility, multi-address multi-homing,
and intermittend connectivity, we end up making changes to the
transport protocols, anyway.  I also anticipate that if we take
the id/loc separation to its logical end, we will create a new
set of APIs that will slowly replace the current socket APIs in
new applications.

>>> you not only want to know whether it's an identifier or a locator
>>> (this part would be easy) but also if it's used in the context of
>>> multihomed communication or in the context of single homed
>>> communication. That's the hard part.
> 
>> Sorry, but now I don't understand your thinking at all.  Firstly, I
>> still think that if we mix the two, it would be hard to know which
>> one an item is.
> 
> identifiers outside of a locator of identifier context, and, if we
> do, whether it's important that we can regain such a context.

Sorry, but I still don't understand.  What is "a locator of identifier
context"?

> while it stays the same in the places where it acts as an identifier.

That really sounds like Mobile IP to me.  You explicitly seem
to expect that some identifiers will (most of the time) work
as locators.  That may work for the common multi-homing cases
today, but it fails to address the most common multi-homing
case tomorrow:  mobile devices that have multiple radio
interfaces that they use at the same time.

> The DNS is secure enough more than 99% of the time.

YMMV.  Especially with DynDNS.

<REALLY-OFF-TOPIC>

> Feel free... Me, I'm more of the Cartesian persuasion when it comes
> to this.

Ah, that explains a lot.  :-)  I gave up the idea of the
Cartesian theatre already a few years ago.  You really
must start reading Dennet and Dawkings.  :-)

</REALLY-OFF-TOPIC>

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Sep 2003 21:55:38 +0200

On woensdag, sep 17, 2003, at 14:22 Europe/Amsterdam, Pekka Nikander 

> transport protocols, anyway.

I see. I'm 100% with Jim here.

> Sorry, but I still don't understand.  What is "a locator of identifier

Sorry, Dutch bleeding into English. I have the nasty tendency to type 
"of" when I mean "or". ("Of" is Dutch for "or".)

What I mean: is it likely we'll be looking at 128 bit values and wonder 
whether those are identifiers or locators? I think there will (nearly) 
always be enough context to know which we're dealing with.

> That really sounds like Mobile IP to me.

Strange.

> You explicitly seem to expect that some identifiers will (most of the 
> time) work as locators.

If we design them that way, certainly.

> That may work for the common multi-homing cases

Then don't use identifiers that are also reachable locators. However, 
in this case you probably have the problem that you can't put the 
locators in a mapping system beforehand.

> YMMV.  Especially with DynDNS.

Dynamic DNS is so secure that _I_ can't even dynamically change my 
zones.  :-)

>>> (Just can't resist:  Could we compare this to the difference between 
>>> Aristolean scholastics and Baconian science? :-)

> must start reading Dennet and Dawkings.  :-)

Ok, I'll put them on my list. But generally I like the somewhat older 
stuff better as I'm always amazed by the bizarre stuff they come up 
with.  :-)  Compared to that things like Putnam's brains in a vat are 
almost a cop-out.

The Descartes reference is towards the "doubt everything" doctrine in 
his meditations, by the way. Not a bad rule when doing network 
security...

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 15:34:25 -0700

Keith,

KM> DNS names are not sufficient for rendezvous or referral.

 Here are the arguments about the names, themselves, that you put forward:

KM>     * Incompatible with existing transport protocols.

If you mean that they are too long to be carried in IP packet headers, you are
of course correct.  If you mean something else, please explain.

However, your concern presupposes that the identifiers must be carried in
those protocol -- or rather, that they must be carried in them frequently.

KM>     * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to a host.

So?  What problem does that cause?  Specifically, please provide a usage
example that would cause a problem.

KM> Instead it refers to a service (as in imap.example.com or www.example.com)
KM> which might map to numerous hosts.

And it might not.  So?  Again, please provide a usage scenario that is
problematic.

KM>  There can also be many domains
KM> associated with a single host and yet be semantically different;

How is this a problem?

KM> What this means among other things is that existing domain names that we
KM> use cannot be expected to be host identifiers.

It depends upon how they are used.

KM>  Even when they are
KM> sufficient to identify a host for initial connection purposes, resolving
KM> the same DNS name again may not produce a locator for the same host as
KM> before.

You are assuming all sorts of semantics to the use of a DNS string that might
or might not be true, for any specific proposal to use domain names.

KM> * Not organized favorably. Existing DNS names are organized according to a
KM> hierarchy of administrative entities,

This is a strength, not a weakness.  If the requirement is for a
globally-registered and unique string, there is not other administrative model
for which we have global experience.  Feel free to cite a counter-example.

KM>  and write access to DNS RRs is also
KM> organized in this fashion.

Whether frequently written RRs is required is, again, dependent upon what
proposal is made.

KM>  The components of domain names are usually
KM> intended to be recognizable by humans, and humans therefore attach meaning
KM> to those names.

This is a feature that serves to improve the mnemonic potential of the
strings.  So?

KM>  This further implies that those administrative entities
KM> often want to restrict use of their domains, so that their names aren't
KM> associated with behavior that they cannot control.

I cannot even guess what you mean by the above.

KM> Of course, it would still be possible to create a new tree of domain names
KM> that did not have these characteristics, but this would remove what many
KM> see as the primary advantage of using DNS names - the ability to avoid
KM> creating new infrastructure.

depends upon the nature of the new registration policies.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 22:21:54 -0400

On Wed, 17 Sep 2003 15:34:25 -0700
Dave Crocker <[email-masked]> wrote:

> If you mean that they are too long to be carried in IP packet headers, you
> are of course correct.  If you mean something else, please explain.
> 
> KM>     * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to
> KM>     a host.
> 

Name EXAMPLE.COM maps to hosts B and C.  Hosts B ausing addresses B1 and C1,
respectively.  Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses
B1, and starts talking to it.  The application now has some state that is only
accessible to host B.   

For some reason the connection gets broken.  Maybe host B changes its
address from B1 to B2.  A needs to re-establish a connection to host B -
host C will not work because the application now relies on state that only
B can access.  EXAMPLE.COM does not name host B uniquely; it names the
service provided by hosts B and C, so it is not suitble for an endpoint
identifier to refer to B.  What is really needed is a unique name for each
host that is stably bound to the host, and which is different from the
DNS name used to identify the service.

> KM> associated with a single host and yet be semantically different;

Service names X, Y, and Z resolve to host A.  Service names W, X, and Y
resolve to host B. A process on host A is talking with one on host B.  They
need to provide a referral to a process on host C that lets C communicate with
 each of them.  What names do they give to C? Note that applications really
have no way of knowing either the semantic bindings of DNS names (what they're
supposed to mean to humans).  Just because a name resolves to an address
of a particular host does not mean that it's valid to use that name in a
referral.  For that matter, there's often no way for an application to know
what names will resolve to a particular host - but even if the app did know
this it would not mean that the application was justified in using a
particular name in a referral.  Whether it's valid to use the name in a
referral depends on what the name was intended to mean.

> It depends upon how they are used.

A wide variety of uses for DNS names is now well established; it would be 
very difficult to restrict this variety of use in a significant way.

> You are assuming all sorts of semantics to the use of a DNS string that
> might or might not be true, for any specific proposal to use domain names.

The above arguments are assuming that we'd be using the same DNS names for
hosts/services that we're already using.  Could you create a different set
of DNS names (e.g. a different class or different TLDs, or *maybe* different
RRs) and insist that they be bound explicitly to hosts so that you can
use them in referrals?  Maybe, but it's very hard to get people to use 
human-readable names the way you want them to.  (I've got the scars from the
URN wars to prove it)

> KM> * Not organized favorably. Existing DNS names are organized according to
> KM> a hierarchy of administrative entities,
> 
> globally-registered and unique string, there is not other administrative
> model for which we have global experience.  Feel free to cite a
> counter-example.

The problem is not so much that the names are assigned in a hierarchy, but the
fact that the existing hierarchy isn't a good model for how real-world hosts
are used.

> KM> intended to be recognizable by humans, and humans therefore attach
> KM> meaning to those names.
> 

So it means that there are inevitably conflicts over uses of those names
when a host (or its owner) has multiple roles.  If you want an identifier to
be bound to a host (and you need it to be, given the other problems) forcing
that host to live at some point in a human-meaningful hierarchy creates
conflicts because it won't always be serving in the role that goes along with
the human meaning.

To take a familiar example, lots of people are now encouraged (sometimes
forced) to use multiple email addresses because their employer doesn't want
their personal mail to be associated with the employer's domain name. 

Keith

---

From: "C i j u O. B a b y" <[email-masked]>
Date: Thu, 18 Sep 2003 13:04:20 +0530

Dear All,

I am involved in the development of an application with IPv6

protocol support. I encountered a problem which i will explain .

Suppose i want to connect to a Server Socket through the interface

index X, i have to use the Scope_Id (member of struct sockaddr_in6)as X-1

if the server is running on the same machine as the client runs.

But if the server is running on a different machine, i can connect it with
scope index X.

Why does this anomaly happen?

Here X is the index that i got from the rtnetlink calls.

My machine is Redhat 7.2 with only one network interface card.

Please help me with your replies . Also please respond if my query is not
clear .

Regards

Ciju O. Baby

---

From: "Keith Moore" <[email-masked]>
Date: Fri, 19 Sep 2003 10:59:39 -0400 (EDT)

Dave,

You're simply wrong.  The scenarios I described are things that
applications do today using IP addresses as endpoint identifiers,
extrapolated to the world where DNS names are used instead.

I won't claim that it's impossible to use DNS names for endpoint
identifiers.  I do claim, and have explained in detail, why:

- using existing DNS names is a bad idea (due to overloading)
- using the DNS lookup system is a bad idea (due to performance issues)

You have the habit of dismissing anything that you don't understand as
irrelevant.  This is just another example.  Frankly it's getting old.

Keith

Dave Crocker said:
> KM> Name EXAMPLE.COM maps to hosts B and C.  Hosts B ausing addresses B1
> and C1,
> KM> respectively.  Host A looks up EXAMPLE.COM, gets addresses B1 and C1,
> chooses
> KM> B1, and starts talking to it.  The application now has some state that
> is only
> KM> accessible to host B.
> KM> For some reason the connection gets broken.  Maybe host B changes its
> KM> address from B1 to B2.  A needs to re-establish a connection to host B
> -
> KM> host C will not work because the application now relies on state that
> only
> KM> B can access.  EXAMPLE.COM does not name host B uniquely;
>
>
> I am guessing that you have not read the MAST proposal and have not been
> noting the details that a number of us are seeking about actual
> requirements
> for an endpoint identifier.. I'm suspecting you also are not familiar with
> the
> other proposals.
>
> So, yes, you have invented a scenario that uses domain names in a way that
> will not work.  Unfortunately, no one is proposing such a broken scenario.
>
> So let me rephrase the question more simply and more rigidly:
>
>      What is it that _requires_ specifying using domain names in a way
> that
>      causes problems?
>
> If that question is not clear enough, then try:
>
>      What is _inherent_ in domain names that prevents their use as
> endpoint
>      identifiers?  Inherent, not merely "possible".
>
> It is always possible to create a broken design.  Citing such an example
> is
> not overly helpful.
>
> However I really should thank you. Much of these discussions have been
> marked
> by attempts to make design choices based on very abstract issues, rather
> than
> on looking on plausible and probable actual usage. This makes much of the
> discussion fundamentally not grounded, both literally and figuratively.
>
> We now have quite a few concrete proposals and specifications. We should
> make
> a point of using these data points as concrete examples of the solution
> space.
>
> d/
> --

---

From: "Eugene M. Kim" <[email-masked]>
Date: Thu, 18 Sep 2003 13:36:33 -0700

Hello,

Comments inline below:

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 17, 2003 7:21 PM
Subject: Re: A strawman analysis on locator identifiers vs. non-locator
identifiers (was Re: A roadmap for end-point identifiers?)

> DNS name used to identify the service.

How about B saying in the earliest possible stage of conversation with
A: `Okay, I don't know what name you looked up in DNS to reach me, but
in the future please use this domain name (that uniquely identifies me)
to reach me again later'?  This could, but need not, happen in the
application layer; some other layer that handles the id-loc mapping
could do this.

My assumption is that each host has knowledge about what domain name is
its unique identifier.  Host/site administrators can configure one into
each host using various ways such as (heaven forbid) manual
configuration, or DHCP e.g. by looking up the client's link-layer
address in a link-layer-address-to-identifier table and, if not found in
the table, defaulting to the link-layer address combined with the
network identifier to form one like
`EUI64-003048FFFE234C67.MARKETINGNET1.EXAMPLE.COM'.

Then it really comes down to the application figuring out what the
identifier for the host it is running on.  gethostname(3) comes to mind
first; if the common practice dictates that it's already being used for
something else (e.g. a service identifier), we could invent and propose
something else like confstr(_CS_HOSTID) in 4.4BSD.

> referral depends on what the name was intended to mean.

Please see the above.

> human-readable names the way you want them to.  (I've got the scars
from the

How about making the name used as an identifier (at least to those ones
that configure it to DNS zones) suggest `No, this isn't a typical domain
name you could do anything you wish; don't overload this for anything
else'?  One example could be a SRV RR with _HOSTID._IP as the
_Service._Proto part.  IMO, actually a SRV-like syntax is ugly to human
eyes (because it starts with an underscore =p) so DNS administrators are
less tempted to overload that name for other purposes.

> fact that the existing hierarchy isn't a good model for how real-world
hosts

Could you (give a pointer to some documents that) elaborate on the
subject?

Regards,
Eugene

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Sep 2003 14:05:15 -0700

Keith,

>> example that would cause a problem.

KM> Name EXAMPLE.COM maps to hosts B and C.  Hosts B ausing addresses B1 and C1,
KM> respectively.  Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses
KM> B1, and starts talking to it.  The application now has some state that is only
KM> accessible to host B.   
KM> For some reason the connection gets broken.  Maybe host B changes its
KM> address from B1 to B2.  A needs to re-establish a connection to host B -
KM> host C will not work because the application now relies on state that only
KM> B can access.  EXAMPLE.COM does not name host B uniquely;

I am guessing that you have not read the MAST proposal and have not been
noting the details that a number of us are seeking about actual requirements
for an endpoint identifier.. I'm suspecting you also are not familiar with the
other proposals.

     What is it that _requires_ specifying using domain names in a way that
     causes problems?

     What is _inherent_ in domain names that prevents their use as endpoint
     identifiers?  Inherent, not merely "possible".

It is always possible to create a broken design.  Citing such an example is
not overly helpful.

However I really should thank you. Much of these discussions have been marked
by attempts to make design choices based on very abstract issues, rather than
on looking on plausible and probable actual usage. This makes much of the
discussion fundamentally not grounded, both literally and figuratively.

We now have quite a few concrete proposals and specifications. We should make
a point of using these data points as concrete examples of the solution space.
     
d/