Subject: Re: Thinking differently about names and addresses

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 1 Apr 2003 18:14:13 -0500

> From: Keith Moore <[email-masked]>

    > it does need to provide such mechanisms in order to provide useful
    > endpoint identifiers.

I don't think you can make such a blanket statement without some more
analysis. For example:

    > without a mechanism to map the endpoint identifier to an IP address,
    > such identifiers are useless in referrals between application
    > components. 

This is not so. Read again what I said before:

  If you construct the protocol interactions such that you don't *need* to
  be able to look up the "identity->address" mapping (which is what HIP
  does - in general, by providing the identity->address mapping used in any
  given transaction as part of the initiation thereof), there's no problem.

So if I have a system which doesn't provide a directory of mappings from
endpoint identifier to addresses, then in the case you cite, when I refer one
application component to another, all I need to do is either:

- i) provide some other name, one that can be mapped into both identifier and
  address, or
- ii) pass the other party both the identifier and a current, working address
  for that endpoint.

This is not to say I *advocate* a system which doesn't have such a directory
of identifier->address mappings; I don't have any religion one way or the
other on that. Maybe it's a good idea overall, maybe it's not.

I can't think of an example offhand of a complete transaction where I *have*
to have it, though.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Apr 2003 18:49:13 -0500

>   given transaction as part of the initiation thereof), there's no problem.

that's like saying that if I write my protocols so that I never use referrals,
then there's no problem with the inability to do referrals.

of course, writing my protocols so that I never use referrals drastically
limits what I can do with the network.   for instance, DNS could not exist.
but never mind the lost functionality, we can at least pretend we have a clean
model.

> endpoint identifier to addresses, then in the case you cite, when I refer
> one application component to another, all I need to do is either:
> 
> - i) provide some other name, one that can be mapped into both identifier
> and address, or

thus reducing the problem to a different unsolved problem.

> - ii) pass the other party both the identifier and a current, working
> address for that endpoint.

thus requiring me to continue to use IP addresses in referrals.

Keith

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Apr 2003 08:39:30 +0200

> thus requiring me to continue to use IP addresses in referrals.

actually this is a fairly common tactic; the X.500 directory used to have 
that (binding a PSAP with the distinguished name of a remote MTA), and the 
DNS does it (delivering an A record, often derived from "glue", as 
additional data when sending back an NS record as a referral).

when done with care, the recipient of such a referral can handle all 3 
cases:

- this is an identity I know, and have communication with. Forget the 
address; I don't need it.

- this is an identity I know, where my current communication address 
doesn't work. Contact at the new address, and verify that you've reached 
the right endpoint.

- this is an identity I don't know. Contact at the given address, and 
verify.

I liked HIP the first time I saw it (a long time ago). I'm still waiting to 
see an application that uses it; if it's good enough to be successful at 
all, it should be able to be successful in a small market niche; if it's 
successful in a market niche, it could possibly take over the Internet.

but that first application can be a high hurdle.....

                      Harald

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Apr 2003 08:06:53 -0500

> actually this is a fairly common tactic;

indeed.  or at least, this isn't the first time it's been seen (and my
now-expired I-D describing the best way for apps to deal with NATs mentioned
something similar).  but it doesn't really solve the problems associated with
ambiguous addresses.  it still doesn't provide a reliable way to talk to that
host in the presence of ambiguous addresses.  it only keeps you from
mistakenly talking to the wrong host when two hosts use the same address.