Subject: RE: [saad] About saad

From: "Michel Py" <[email-masked]>
Date: Thu, 16 Oct 2003 08:59:22 -0700

> James Kempf wrote:
> IPv4 still has the node identifier v.s. routing locater
> conflation problem for addresses, however.

Can you explain "conflation" please?

Michel.

_______________________________________________
Saad mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/saad

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Oct 2003 09:07:52 -0700

An IP address acts in two roles:

1) As a node or endpoint identifier to the transport layer for an end to end
conversation.

2) As a locator for routing packets to a particular topological location.

If a host is not mobile, there is no difficulty. However, for mobile hosts,
there needs to be some way of separating out the two,  because when the host
moves to a different subnet, the original IP address can no longer be used
as a routing locator.  Mobile IP uses one method (the home address becomes
the node identifier, the care of address becomes the routing locator), HIP
uses another (the HID is the node identifier, the IP address is the routing
locator) and MAST uses yet another (a case-based node identifier, the IP
address as routing locator).

            jak

----- Original Message ----- 
From: "Michel Py" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Geoff Huston"
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 16, 2003 8:59 AM
Subject: RE: [saad] About saad

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Oct 2003 15:13:30 -0400

>2) As a locator for routing packets to a particular topological location.

actually, I will argue that the endpoint identifier is the dns name. That 
has problems in that

  - it needs to be able to name a service and get the address of the most 
serviceable instance of a computer offering it to the requestor; it 
currently simply offers *an* address of a list of addresses from which the 
requestor needs to choose at random

  - it presumes a global address space (there is no concept of "source 
route to this gateway address and then to that private address", or the 
obvious generalization)

  - A list of other things I will think of just after I send this email

But it in fact acts to identify the intended endpoint.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Oct 2003 15:37:34 +0200

This raises a meta-question in my mind.

How are we going to prevent this list simply repeating all the discussion
that took place in the NSRG and elsewhere?

The reasons why FQDNs are imperfect EIDs have been listed quite recently
(on one of the IPV6 lists I think).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: "James Kempf" <[email-masked]>
Date: Fri, 17 Oct 2003 08:31:49 -0700

Fred,

The DNS is a node identifier, but it currently can't be used by the
transport layer as a connection endpoint identifier.

There are have also been some experimental proposals (viz. Cheriton's TRIAD
work) to use DNS names for routing.

            jak

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Oct 2003 13:38:11 -0400

>transport layer as a connection endpoint identifier.

And neither can a interface address, at least not in the same way. As you 
noted, one could use a MIP Home Address as a CEPID, because it is invariant 
across interface failures, routing changes, and motion.

>There are have also been some experimental proposals (viz. Cheriton's 
>TRIAD work) to use DNS names for routing.

Yes. If you believe that names should be in the application layer and 
addresses should be in the network layer, moving names down is as 
problematic as moving addresses up, for the same reason.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 17 Oct 2003 15:10:23 -0400

Brian,

BEC> The reasons why FQDNs are imperfect EIDs have been listed quite recently
BEC> (on one of the IPV6 lists I think).

As a proponent of using domain names as endpoint identifiers -- for those
situations requiring only occasional exchanges -- I have put some effort
into looking for the discussions that argue against their use.

My goal is, of course, to then try to refute the arguments.  If I can't
find convincing counter-arguments, I'll change my advocacy.

So far, I have not found arguments that are pragmatic and operational.
The arguments against domain names have primarily been based on
principles and aesthetics. These are important for guidance, but should
not get in the way of pragmatics.  New namespaces are expensive,
particularly when they need global administration.

What I am looking for are arguments that explain how use of domain names
as EIDs "will not work" or arguments that explain how use of them will
break other things.

I've even tried to ask such questions in a few venues. Sadly, responses
that attend to pragmatics have not been forthcoming.

So, if there is a discussion that really explains the pragmatic problems
with using domain names, I would greatly appreciate being pointed at it.

Failing that, I'm afraid that, yes, this list should discuss the
question.

Let me prime the pump:

1. Concern: Domain names are overloaded; they get used for too many things
already.

Response:  So?  What problems are caused by this and how does it prevent
them from being used as EIDs? How will using them as EIDs -- and we can
skip over the argument that they already _are_ EIDs, for the moment --
break any of the other uses for domain names?

2. Concern: DNS administration is difficult

Response: But it exists and it works. Persistent names need
administration. Why is something new going to be easier? What can't the
mechanisms that make it easier be applied to the DNS? Why won't adding
them to DNS be substantially easier than creating a new, global
administrative mechanism?

3. Concern: Domain names are inefficient to use

Response: If they must be used in every packet, that is true.  If they
must be used only occasionally, such as at the start of an association
or at major state change events, then the bit-inefficiency of domain
names is irrelevant to the overall efficiency of the service that is
using it.

4. Concern: Domain names are administered by a different entity than the
folks who administer IP operations

Response: Is this a turf war?  Is there some reason to believe that
having the new namespace administered by another group is somehow going
to make the new names trivial to administer, compared with domain names?
The mere fact that the new namespace _might_ be administered by a
different group does not guarantee that the reality of administering it
is any better than the reality of administering domain names.

5. Concern: Not all machines have domain names.

Response:  _No_ machines have whatever the alternative might be.

And so on.

OK.  Consider the pump primed.

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 17 Oct 2003 13:00:16 -0700

Dave,

So, as I understand it (and having read through the MAST paper), what you
are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which
the FQDNs are used for global node identification initially to set up a more
compact temporary node identifier.

Is that right?

            jak

---

From: Dave Crocker <[email-masked]>
Date: Fri, 17 Oct 2003 16:10:41 -0400

James,

JK> So, as I understand it (and having read through the MAST paper), what you
JK> are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which
JK> the FQDNs are used for global node identification initially to set up a more
JK> compact temporary node identifier.

JK> Is that right?

That is remarkably more concise (compact) than I have been saying, but I
think the answer is yes.

In particular, I have not been noting explicitly is the relationship
between the two identifiers. Your description is very helpful. Thanks!

d/

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Oct 2003 15:50:10 +0200 (CEST)

> break any of the other uses for domain names?

It isn't the domain names per-see that are the issues but any implied
semantics of having multiple AAAA records for the same RRset.

For instance, the AAAA RRset for www.example.com might return 5 addresses.
Does that mean that that those are different locators for the same
stack/entity, 5 separate stacks, or some combination?
Additional information in the DNS, or some negotation protocol between the
endpoints can presumably be used to resolve this question.

> administration. 

Depending on your definition of "administration" this might not be the
case for statistically unique and cryptographically verifiable identifiers
(also known as CBIDs or hashes of public keys).
Any node could generate a 128 bit ID by generating a public/private key
pair and doing the SHA1 hash of the public key; doesn't require any
name space administration.

> Why is something new going to be easier? What can't the

There is an aspect called "the DNS is inefficient to use" which
doesn't seem to be part of your #3.
Using domain names while preventing the redirection attacks that are
implicit in any attempt to make ULP communication survive locator changes
implies that some more DNS lookups will be performed.
Understanding the performance of using the DNS for such
a lookup (with and without DNSsec) with schemes based on CBIDs is
definitely a worth-while effort.
 
> is any better than the reality of administering domain names.

There is a level 9 meta-issue related to this.
If a new rooted, hierarchical name space is needed somebody needs
to be appointed to control and operate the root of that namespace.
Resolving the food fight of who should be in control might take some
time.

FWIW neither using the DNS as in MAST or using flat CBIDs have this
problem.

> Response:  _No_ machines have whatever the alternative might be.

Question is how hard it would be to add them.

I could get a CBID for my machines at home in a few seconds (the time
it takes to generate the key pair). Convincing the ISP to assign me a domain
name would take a lot longer.

Thus if both ends of the communication need a domain name this might be an
impediment for deployment.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2003 19:33:12 +0200

> For instance, the AAAA RRset for www.example.com might return 5 addresses.

And might return different addresses on consecutive calls, if round robin
load sharing is in use. And the addresses returned might well be virtual,
i.e. dynamically assigned to a particular server at packet-delivery time.

So what such an FQDN actually refers to (except itself) is fuzzy indeed.

   Brian