Subject: Re: Site local

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 3 Dec 2002 16:46:36 +0100

On fredag, nov 29, 2002, at 05:38 Europe/Stockholm, Tony Li wrote:

>
> Hope you're feeling better.

Yupp!

> In particular, what I was suggesting was that the separation of
> locators and identifiers would greatly simplify the (perceived)
> problem that is driving site local addresses anyway.  A site would
> get global identifiers immediately and then when they connect to
> the net (or change connections), they would only change the locator
> part.
>
> By itself, that seems like a lesser win.  However, if the architecture
> is tweaked so that the site's global locators are only known to the
> site's border routers, then the only changes that need to be done
> are very trivial.
>
> In short, someone else has another motivation for the same 
> architectural
> flexibility that a group here has been asking for all along.

Ok, I am more or less with the idea of locator+identifier. What I am 
worried about is the effects of this on the applications.

My main reason for being against anything that could lead down a NAT 
road (and I am worried that any attempt besides assigning global 
addresses everywhere will lead there) is that I have seen the effects 
this has had on delaying deployment of new services and creating 
problems at end sites.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 4 Dec 2002 10:37:05 +0100 (CET)

> addresses everywhere will lead there)

Tony already addressed this, but let me offer a different spin:

The problem with NAT is not that the addresses in the IP header are
changed. The problem with NAT is that you're not talking to who you
think you are talking to. And if you don't know, you can't tell someone
else, so it becomes impossible to set up new connections in a different
way than from the same source to the same destination as the current
session. So this breaks pretty much everything except stuff that follows
a simple client/server model.

In a identifier/locator system, the endpoints are always aware of the
identifiers. Since such a system isn't here yet, we can make this a very
hard requirement. Changing the locators around is then no longer an
issue.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 6 Dec 2002 17:13:04 +0100

> a simple client/server model.

It even breaks that. See SIP through NAT. See IP-Sec through NAT, etc.

> hard requirement. Changing the locators around is then no longer an
I am still worried about some of the application protocols, but I am 
not a applications guy. So I still think we should get this run through 
the applications area.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 9 Dec 2002 19:52:11 +0100 (CET)

On Fri, 6 Dec 2002, Kurt Erik Lindqvist wrote:

> > hard requirement. Changing the locators around is then no longer an issue.

> not a applications guy. So I still think we should get this run through

Well, let's create something that we feel comfortable showing others
first.

I don't think the application part is all that complex. Either you are a
sender or a receiver. The sender sets up a session or packet. The most
important information here is the destination address/name and port, but
the sender may also specify a source. The sender fires off a TCP session
or a (UDP) packet. Meanwhile, the receiver has started listening on an
address/port. A packet or session request comes in. The receiver looks
at the source address/port and decides whether to accept the
session/packet.

All reasonably simple. The problems start when one or both ends (or a
third and so on end) of the communication puts information about the
addresses and ports in a protocol but these addresses/ports aren't the
ones aren't the real ones because they are changed somewhere along the
way.

If we create new identifiers for the applications to work with and make
sure those aren't changed in the middle at any point, we should be fine.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 15 Dec 2002 20:58:03 +0100

> Well, let's create something that we feel comfortable showing others

More to the list of situations, how would we support multicast in this 
model? Do we need to?

> sender or a receiver. The sender sets up a session or packet. The most

Well, the same goes for NAT and applications still don't work :)

> at the source address/port and decides whether to accept the

Well, my worry is that we (I at least) don't understand all application 
designs well enough to make the claim that the above model would hold 
as a benchmark.

I still think we should have the applications group look at the 
proposals and make a comment on them.

- kurtis -