Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U)

From: Margaret Wasserman <[email-masked]>
Date: Mon, 5 Feb 2007 15:49:28 -0500

[I have not seen this come out on the list yet.  Apologies for any  
duplicates.]

Hi All,

On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote:
> You clearly need to be able to invalidate a network layer handle
> if the upper layer entity migrates; and then you have to pay the
> lookup overhead.

I agree.  One thing I've been struggling with, though, is whether  
this lookup should happen in the end-node or in the network...

My thoughts on this topic have favored a two-tiered routing approach,  
which would allow us to highly optimize and evolve the global routing  
infrastructure without affecting end-nodes and local networks.

I have been trying to work out the details of an architecture where  
the two end-points of a connection use local end-point addresses to  
refer to each other, while the network uses global locators for routing.

The same, globally unique, centrally allocated (?) IPv6 addresses are  
used by the end-nodes on both ends, but they will only be routable  
within their own local network.  Those identifiers are translated  
into globally-routable locators within the network by routers at the  
local/global boundary, and the original end-point identifiers are  
stored in an extension header.

The global locators are _not_ unique, per end-node identifiers.  They  
identify (and provide the information needed to route to) another  
border router that is taking responsibility for delivering traffic  
for a particular set of end-node addresses.  There would a one-to- 
many mapping from a global locator to end-point-addresses, and a one- 
to-one mapping of an end-point address to a global locator.

This is intended to be a tiered routing approach, not an id/loc split  
technology.  Both the end-point addresses and the global locators  
have the property of both identifying an entity and providing  
topological information about how to route to it (locally in the case  
of end-point addresses, globally in the case of global locators).

This approach is essentially identical to IP-in-IP tunneling, with  
optimized headers.

This approach has some similarities to NAT, but with several  
differences that would eliminate the problems caused by NAT:

(1) The local address space is unique (not overlapping) and centrally  
allocated (you can tell who owns it).
(2) State for mapping the local addresses (end-point identifiers) to  
global locators is held in a global system, like global routing  
tables, not held only on local translators.
(3) The original end-point addresses in the packet remain in the  
packet and are restored to their original location at the other end.
(3) Nothing inside the outer IP header needs to be translated.

I think that it has several benefits that make it interesting to  
think about:

(1) It requires no changes to end-nodes.  Applications use DNS to get  
end-point identifiers, as they do today.
(2) Most routers would not have to change, even within the global  
routing domain.  They'd just route on the packet as it was presented  
to them.  Only boundary routers would need to know about this  
mechanism, and they would only perform the transformation for packets  
addressed directly to them.
(3) Local traffic would "just work" as it does today -- no extra look- 
ups or translations.

There are still a lot of things that I have to work out before I'll  
be confident that this approach could be used in a scalable and  
useful way, but I think it is something to think about...

A few areas for discussion are:

(1) How are the endpoint addresses mapped to global locators at the  
local/global boundary?  How is this mapping information propagated  
and updated when the mapping changes?  (This problem is similar to  
the problems faced be routing protocols today.)
(2) What are the security implications of this approach, and what is  
needed to prevent this from becoming a great way to inject apparently  
local packets and/or do other types of spoofing?

Margaret

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 5 Feb 2007 13:06:49 -0500

Hi All,

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Feb 2007 17:10:43 +0100

Margaret,

You'll definitely want to read draft-farinacci-lisp,
although it may give you some terminology concerns.
(It's likely to be discussed on the RAM list.)

     Brian

On 2007-02-05 19:06, Margaret Wasserman wrote:
> I agree.  One thing I've been struggling with, though, is whether this 
> lookup should happen in the end-node or in the network...
> 
> I have been trying to work out the details of an architecture where the 
> two end-points of a connection use local end-point addresses to refer to 
> each other, while the network uses global locators for routing.

<snip>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 7 Feb 2007 06:58:34 -0500

> (It's likely to be discussed on the RAM list.)

Thanks for the pointers, to the draft and to the list (which I had  
somehow failed to join).

I saw your discussion of this document on the other list, and I'll  
hop over there.  I just wanted to make one point here, though...

The two proposals are similar in many ways.

The biggest difference between lisp and my approach (other than the  
fact that Dino has written a nice document, and I've written a  
cryptic e-mail) is that, in my approach, the packet remains an IP  
packet.  The only routers that have to change are the ones at the  
local/global boundary, not all of the global domain routers.

Also, in my approach, it might be possible to make this work (perhaps  
only for IPv6, because it has the header extension mechanism? and  
perhaps only as well as NAT?) when only one end implements the  
transformation, by having the global locators and the end-point  
addresses have the same value for hosts on networks that don't  
implement the new mechanism.  I'm still working out the details of  
that part...

Margaret

---

From: Peter Tomsu <[email-masked]>
Date: Mon, 26 Feb 2007 14:35:57 +0100

Margaret,

I could not agree more !

Peter

On 05.02.2007, at 21:49, Margaret Wasserman wrote:

> My thoughts on this topic have favored a two-tiered routing  
> approach, which would allow us to highly optimize and evolve the  
> global routing infrastructure without affecting end-nodes and local  
> networks.
>
> The same, globally unique, centrally allocated (?) IPv6 addresses  
> are used by the end-nodes on both ends, but they will only be  
> routable within their own local network.  Those identifiers are  
> translated into globally-routable locators within the network by  
> routers at the local/global boundary, and the original end-point  
> identifiers are stored in an extension header.
>
> The global locators are _not_ unique, per end-node identifiers.   
> They identify (and provide [email-masked]>
From: Peter Tomsu <[email-masked]>
Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d]
	[Off-topic]Furtherthoughts: about systems theory and the theory U)
Date: Mon, 26 Feb 2007 14:35:57 +0100
To: Margaret Wasserman <[email-masked]>
Cc: [email-masked], [email-masked]

Margaret,

I could not agree more !

Peter

On 05.02.2007, at 21:49, Margaret Wasserman wrote:

> My thoughts on this topic have favored a two-tiered routing  
> approach, which would allow us to highly optimize and evolve the  
> global routing infrastructure without affecting end-nodes and local  
> networks.
>
> The same, globally unique, centrally allocated (?) IPv6 addresses  
> are used by the end-nodes on both ends, but they will only be  
> routable within their own local network.  Those identifiers are  
> translated into globally-routable locators within the network by  
> routers at the local/global boundary, and the original end-point  
> identifiers are stored in an extension header.
>
> The global locators are _not_ unique, per end-node identifiers.   
> They identify (and provide the information needed to route to)  
> another border router that is taking responsibility for delivering  
> traffic for a particular set of end-node addresses.  There would a  
> one-to-many mapping from a global locator to end-point-addresses,  
> and a one-to-one mapping of an end-point address to a global locator.
>
> This is intended to be a tiered routing approach, not an id/loc  
> split technology.  Both the end-point addresses and the global  
> locators have the property of both identifying an entity and  
> providing topological information about how to route to it (locally  
> in the case of end-point addresses, globally in the case of global  
> locators).
>
> (1) The local address space is unique (not overlapping) and  
> centrally allocated (you can tell who owns it).
> (2) State for mapping the local addresses (end-point identifiers)  
> to global locators is held in a global system, like global routing  
> (1) It requires no changes to end-nodes.  Applications use DNS to  
> get end-point identifiers, as they do today.
> routing domain.  They'd just route on the packet as it was  
> presented to them.  Only boundary routers would need to know about  
> this mechanism, and they would only perform the transformation for  
> packets addressed directly to them.
> (3) Local traffic would "just work" as it does today -- no extra  
> look-ups or translations.
>
> (2) What are the security implications of this approach, and what  
> is needed to prevent this from becoming a great way to inject  
> apparently local packets and/or do other types of spoofing?
>
> Margaret
>
>
>

---

From: JFC Morfin <[email-masked]>
Date: Mon, 26 Feb 2007 21:57:30 +0100

Peter,
I think that OPES could be an elegant solution offering the best of 
both (no change on the host, etc.). An additional advantage is that 
the DDDS service to resolve the routing information (whatever the 
system) could be performed by what I call a ONES (open network 
extended service). This means that it would be managed by OPES 
call-out hosts operating as one or several overlaying networks.

Let take Lisp for example, it could be used only if the destination 
has an OPES supporting Lisp dcapsulation. This is intelligence but:

1. it is not within the network but at the edge

2. the job is to maintain information among call-out servers about 
OPES status. These hosts are regular hosts, using the dumb network in 
a standard way (or a dedicated system, up to the operator). If the 
result is that the user supervisors I propose come up with a route 
instead of a destination address, this can permit to reduce the load 
and cost on routers (these routers could be supported by an OPES 
linked to the ONES, its host managing their tables dynamically).

What is of interest is that such an architecture can be implemented 
without disturbing the network architecture. One could imagine each 
ISP building its own ONES (or adhering to a consortium) to manage its 
foreign relations. With all the mutual back-up possibilities such an 
approach would allow.

jfc

PS. Due to the positions that a certain number of countries are 
taking (starting with the USA) there are most probably three 
priorities to address that will receive an increasing support at IGF, 
WTO, local laws: multilingualism (not globalisation's 
internationalisation), multitopology support (permitting multi-tier 
legal enforcement), user's choice of the routing itinerary (limitting 
the risks of interception).

At 14:35 26/02/2007, Peter Tomsu wrote:
>>global routing infrastructure without affecting end-nodes and local networks.
>>
>>The global locators are _not_ unique, per end-node 
>>identifiers.  They identify (and provide the information needed to 
>>route to) another border router that is taking responsibility for 
>>delivering traffic for a particular set of end-node 
>>addresses.  There would a one-to-many mapping from a global locator 
>>to end-point-addresses, and a one-to-one mapping of an end-point 
>>address to a global locator.
>>
>>in the case of end-point addresses, globally in the case of global locators).
>>
>>I think that it has several benefits that make it interesting to think about:
>>
>><mailto:[email-masked]>[email-masked]