Subject: RE: noid and applications (generic requirements from applications)

From: "Tony Li" <[email-masked]>
Date: Thu, 13 Nov 2003 12:48:30 -0800

Patrik,

That is going to be exceedingly difficult.  As long as we
are using IP addresses in applications and we are hiding
the actual reachability of the address from the application,
we are guaranteed to be allowing an application to pass along
an unreachable address.

Note that this is a result of the layering violation of
passing around an IP address in the application.  Asking us
to warp the world to support architectural mistakes strikes
me as suboptimal.

Regards,
Tony

|  -----Original Message-----
|  From: Patrik Fältström [mailto:[email-masked]] 
|  Sent: Thursday, November 13, 2003 8:08 AM
|  To: Erik Nordmark
|  Cc: Tony Li; [email-masked]
|  Subject: Re: noid and applications (generic requirements 
|  from applications)
|  
|  
|  On 2003-11-13, at 08.49, Erik Nordmark wrote:
|  
|  >> Of course, if we're going to open an implementation, we might want
|  >> to make the point of referral the FQDN, not the locator(s).
|  >
|  > Yes. Especially with noid, where the multihomed node needs 
|  to have a 
|  > FQDN,
|  > this makes a lot of sense.
|  
|  This is ok for an application which of course should use the 
|  FQDN, but, 
|  even when using whatever "thing" the application uses to 
|  establish the 
|  connection (which it gets via the FQDN) that should be 
|  usable without 
|  knowledge of the network topology. I guess one can formulate 
|  it as it 
|  must have features like:
|  
|    (A=B) and (B=C) gives (A=C) where '=' is "can communicate with"
|  
|  and
|  
|    (A->B) gives (B->A) where '->' is "can send data to"
|  
|      paf
|  
|

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2003 23:26:36 +0100

Tony,

Doesn't this objection also apply to passing an FQDN around,
since FQDNs can also be unreachable, due to 2-faced DNS
and the like?

In other words, referral is a very deep problem in the
non-transparent network that we sometimes still describe as
"the Internet." I suspect this is a problem that multi6 is
unable to solve; we should simply not make it worse.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2003 16:46:54 -0600

> since FQDNs can also be unreachable, due to 2-faced DNS

What would be the logic of making something unreachable using twofaced 
DNS? I thought the point was to make sure that different people connect 
to different hosts when they try to connect to an FQDN. The situation 
where one side of the DNS produces something useful while the other 
doesn't is either unintended, which is the risk you run by abusing 
technology in this way, or is intended in which case there isn't a 
problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2003 03:49:19 +0100

> technology in this way, or is intended in which case there isn't a

I don't mean there would be any logic. My point is that just as
you can make a mess by referring unrouteable addresses, you can make
a mess by referring inaccessible FQDNs.

If server.example.com sends a referral for internal-only.example.com 
to client.example.org, it is no different from sending a referral to 
FEC0::27. Neither referral makes sense, but both might happen if 
server.example.com doesn't know any better.

   Brian

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 14 Nov 2003 08:25:29 -0600

> to warp the world to support architectural mistakes strikes

The reason I ask is because I want to know what we will get at the end 
of the day with the noid proposal.

Today, the idea is that the IP address as well as the FQDN is globally 
unique and have the properties described.

What I understood from the noid draft is that what we today call IP 
addresses (what is above L2, used in the arp requests etc) can be 
rewritten and because of this doesn't have the properties above.

My question was whether the new identifier will have the properties 
above, so an application instead of doing layering violations on 
FQDN+IP should do the same kind of violations on FQDN+Identifier?

Else it will be extremely hard to "fix" protocols like ftp and 
everything which controls RTP streams.

I think the discussion whether those protocols are designed in a 
correct or wrong way will not help, as you and myself possibly have the 
same view -- even though there are rumors there are differences in how 
hot it is in hell.

IF the above properties are valid for at least one of the identifier 
"layers" in noid, fixing applications and protocols we have today will 
be much easier.

    paf

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2003 15:49:20 +0100 (CET)

> rewritten and because of this doesn't have the properties above.

Perhaps I don't understand what the properties mean, but I don't
see any significant change compared to today.

What noid does it to introduce sets of locators as a new concept,
with the layers under the transport protocols treating the set as a
unit.

When multihoming and there are failures of a path it is true that a single
locator might not be useful; the path to that locator might have failed.
Having the FQDN or the locator set provides the ability to communicate
in the precense of such failures.

Whether the glass is half-full or half-empty in this case is a question of 
perspective. 
Without any multihoming solution today with multiple addresses 
assigned to a host, a single address/locator would fail when there is a
path failure and there is no recourse for the applications/ulp.
Introducing the ability to use a FQDN or locator set provides a mechanism
to repair this.

But if you compare this with introducing a new ID name space (e.g. hashes
of public keys) and a system which securely and efficiently can lookup
such identifiers, then the fqdn+locator set approach is clearly inferior
from the apps perspective. But designing and deploying such a mapping
system would take time and deployment incentives are far from clear. 

The SIM document presents a possible middle ground. It talks about the ability 
to introduce the new name space now, with the hope that the mapping system can
be designed and deployed later. Until the mapping system is in place
applications that wish to do referals need to carry both the ID plus a
snapshow of the locator set (with at least one working locator).

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2003 13:41:14 +0100

Patrik,

In NOID the transport layer and above aren't aware that the locator
is rewritten. So I don't see that part of your concern.

More fundamentally, you say

> unique

Unfortunately that certainly isn't true of addresses today and we still have to
fight hard for it to be true of IPv6 addresses tomorrow. It's a dangerous
assumption. However, there's no reason FQDNs should be non-unique. 

    Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Nov 2003 21:34:02 +0100

On fredag, nov 14, 2003, at 03:49 Europe/Stockholm, Brian E Carpenter 

> server.example.com doesn't know any better.

Although I agree with Brian, this is a real case problem. Very much the 
same that was discussed with site-locals (but let's not go there right 
now). However, I am not sure this is an issues that we need to solve. 
As Iljitsch says, if people have a broken set-up, things will break. 
But I think this should be documented.

- - kurtis -

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 18 Nov 2003 03:27:07 +0100

> is rewritten. So I don't see that part of your concern.

Good. I just wanted someone else to say so, because when I read the 
noid draft that was not clear to me.

> assumption. However, there's no reason FQDNs should be non-unique.

Let me rephrase myself.

In the real world, this is of course not true, BUT, protocols we have 
(FTP, SIP etc) believe it is true.

If the noid identifier is "more globally unique" than IPv4 addresses, 
then I can see not objection from apps people but very strong support 
for noid.

    paf