Subject: [arch-d] Thoughts about addresses, or why the overall architecture affects routing.

From: Pekka Nikander <[email-masked]>
Date: Sun, 19 Nov 2006 15:14:26 +0200

(These are all old thoughts, but perhaps I've got something wrong.   
Or perhaps I'm missing something altogether.  Besides, it looks like  
some people are failing to remember the implication, below.)

In the note below, I use the term "address" in its routing-related  
meaning, i.e., I'm referring to a piece of data that is affixed to a  
packet for the purposes of affecting its forwarding through the network.

 From an information placement point of view, the current prefix- 
encoding hop-by-hop routing architecture can be considered to be mid- 
way between pure source routing and pure host-based routing.

In a pure source routing architecture, the source node encodes each  
next hop to the packet.  Consequently, the packet contains all  
information needed for forwarding.  No state at all needed in the  
middle boxes; you can hardly even call them routers, as they become  
pure forwarders.  (I know, such an architecture is unrealistic; I'm  
simplifying in trying to make a point.)

In a pure host-based routing architecture, the addresses have no  
structure at all and contain no forwarding information.  For example,  
they could be random.  Each router separately resolves the address  
into the next hop, potentially using all bits from the address.  Full  
network topology and host location information is needed at each  
router.  Host-based routing is used in MANETs, and scale badly.  The  
recent SIGCOMM ROFL paper explores some of the limitations as seen in  
the light of current technology.
http://project-iris.net/irisbib/papers/flatlabels:sigcomm2006/paper.pdf

In the current architecture, the addresses encode some network  
topology information into the routing prefix, thereby reducing the  
amount of information needed to be stored at the routers or  
forwarding tables.  The closer the prefixes match with the actual  
network topology, the bigger savings.  From a mathematical point of  
view, one could say that the better the topology of the addressing  
space can be matched with the topology with of the network, the less  
information needs to be stored elsewhere.

 From here we get into two factors on how addresses do matter to  
routing:

1. If there are external forces (such as difficulty of renumbering)  
that make it hard to change addresses as needed, it becomes harder to  
maintain the match between the addressing topology and the real  
network topology.

2. The way we use the bits in the address to create the topological  
addressing space affects the ways we can match the address space with  
the network topology.

I will skip the second issue for now.  It is an important one, but  
can be studied in relative isolation from the larger architecture.    
For example, using other than tree structures to store network  
topology information into addresses might be something that might  
help with the pressures on the global routing table.  However, my  
understanding of the graph theory is insufficient so that I could  
suggest anything sensible there.

Considering the first issue, we can isolate a largish number issues  
in the overall architecture that make addresses more rigid or more  
agile.  I won't go into examples; most of us know enough of them.   
However, from an economic point of view, I still maintain that the  
current APIs are the main issue in the medium, 10-20 years, perspective.

But what I find most important, for the sake of the current  
discussions, the implication from above:

If we can change the overall architecture, either fundamentally or  
through some kind of shim-patch hack, so that the applications become  
isolated from the addresses used by the routing and forwarding  
system, it becomes easier to change the addresses as needed.  That,  
in turn, makes it easier to make the address space topology to match  
with the network topology.

That's the reason why the overall architectural discussion matters,  
even to the current crisis of "the routing system [growing] beyond  
what is maintainable."  It will not provide any short term remedy  
("symptomatic solution"); for that we've now got the separate mailing  
list, see:
http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ 
msg00638.html

But I regard the larger architectural discussion as a necessity to  
make any progress with the larger problems, hopefully eventually  
reaching a longer-term solution ("fundamental solution").  For that  
discussion, we seem to have a plethora of needs or "requirements",  
many of which are fuzzy or hard to nail down exactly.  Therefore I  
find it easier to discuss in terms of concrete architectural  
structures, like what I did in my previous message:
http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ 
msg00657.html

--Pekka Nikander

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

---

From: John Day <[email-masked]>
Date: Sun, 19 Nov 2006 08:45:39 -0500

For the most part, I agree totally with you.  The fundamental problem 
here as laid out but not pointed out in Saltzer's paper (RFC 1498) is 
that we have been operating with half an addressing architecture.

Second, I would suggest that progress could be made if we were more 
careful about how use the word "topology" and not use it when we mean 
"graph."  Which I believe you did a couple of times.

Take care,
John

At 15:14 +0200 2006/11/19, Pekka Nikander wrote:
>From an information placement point of view, the current 
>prefix-encoding hop-by-hop routing architecture can be considered to 
>be mid-way between pure source routing and pure host-based routing.
>
>structure at all and contain no forwarding information.  For 
>example, they could be random.  Each router separately resolves the 
>address into the next hop, potentially using all bits from the 
>address.  Full network topology and host location information is 
>needed at each router.  Host-based routing is used in MANETs, and 
>scale badly.  The recent SIGCOMM ROFL paper explores some of the 
>limitations as seen in the light of current technology.
>From here we get into two factors on how addresses do matter to routing:
>
>that make it hard to change addresses as needed, it becomes harder 
>to maintain the match between the addressing topology and the real 
>network topology.
>
>addressing space affects the ways we can match the address space 
>through some kind of shim-patch hack, so that the applications 
>become isolated from the addresses used by the routing and 
>forwarding system, it becomes easier to change the addresses as 
>needed.  That, in turn, makes it easier to make the address space 
>topology to match with the network topology.
>
>("symptomatic solution"); for that we've now got the separate 
>mailing list, see:
>http://www1.ietf.org/mail-archive/web/architecture-discuss/current/msg00638.html
>
>http://www1.ietf.org/mail-archive/web/architecture-discuss/current/msg00657.html
>
>--Pekka Nikander
>
>

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 23 Nov 2006 16:04:54 -0600

Pekka Nikander [mailto:[email-masked]] wrote:
> In the current architecture [...]
> From a mathematical point of

Perhaps somebody with better mathematical understanding could comment...

When I envision an Internet with lots of network-hierarchy, I understand
your statement to mean that aggregation is possible if addressing and
connectivity are essentially aligned. But when I envision an Internet
with no hierarchy this is no longer true. (As an extreme example,
picture an Internet where every AS was directly connected to every other
AS; compression of the address space through aggregation is only
possible at the expense of path information.) Of course, the current
Internet is somewhere in between. But who knows about the future?

It seems to me that this relationship between connectivity and routing
system size could be made explicit: must we inherently make assumptions
about the relationships between networks in order to produce a more
scalable routing and addressing architecture?

Cheers,
-Benson

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 24 Nov 2006 12:02:19 -0800 (PST)

> scalable routing and addressing architecture?

As a user I want:
1. an IP address pool assigned to me for a lifetime
2. a selection of competing networks to put my traffic on for as long/short as I
chose
3. a complete control on what goes out with my source addresses
4. an assurance that what is coming in has come from its true originator
5. an ability to prevent receiving from unwanted senders

Thanks,

Peter

> scalable routing and addressing architecture?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: John Day <[email-masked]>
Date: Fri, 24 Nov 2006 15:14:04 -0500

Aw shucks!  You don't want much, do you!?  ;-)

As for the first one, let me ask you something.  Is your postal 
address the same as the place you were born?  And before you tell me 
your phone number follows you around, refer back to previous emails 
on this list.  Your phone number isn't a point of attachment address.

The others are not that hard.  Although, I would say 3 is your problem. ;-)

Take care,
John

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 24 Nov 2006 14:09:27 -0800 (PST)

> address the same as the place you were born?

I did not mention geography on purpose because depending on the finalized
architecture it may or may not play a critical role. If it does then when I change
geography I just give up old addresses and get new ones at the new geography. In
this context geography must be something significant like e.g. a continent.
This is kind of neat to have id+locator to follow you around. Isn't it what the
mobility is about?
Wrt a phone number it follows me when I travel. I like the feature and the number
and want to keep it this way.

> Although, I would say 3 is your problem.
These are just requirements for the end product.

Thanks,

Peter

> >>  scalable routing and addressing architecture?

____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

---

From: John Day <[email-masked]>
Date: Fri, 24 Nov 2006 17:19:10 -0500

>and want to keep it this way.

Those are application names, not addresses.

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Nov 2006 23:28:28 -0500

hmmmm me too.
/jim 

> -----Original Message-----
> From: Peter Sherbin [mailto:[email-masked]] 
> Sent: Friday, November 24, 2006 3:02 PM
> To: Schliesser, Benson; Pekka Nikander; [email-masked]
> Subject: RE: [arch-d] Thoughts about addresses,or why the 
> overall architecture affects routing.
> 
> > system size could be made explicit: must we inherently make 
> > assumptions about the relationships between networks in order to 
> > produce a more scalable routing and addressing architecture?
> 
> As a user I want:
> 1. an IP address pool assigned to me for a lifetime 2. a 
> selection of competing networks to put my traffic on for as 
> long/short as I chose 3. a complete control on what goes out 
> with my source addresses 4. an assurance that what is coming 
> in has come from its true originator 5. an ability to prevent 
> receiving from unwanted senders
> 
> Thanks,
> 
> Peter
> 
> > When I envision an Internet with lots of network-hierarchy, I 
> > understand your statement to mean that aggregation is possible if 
> > addressing and connectivity are essentially aligned. But when I 
> > envision an Internet with no hierarchy this is no longer 
> true. (As an 
> > extreme example, picture an Internet where every AS was directly 
> > connected to every other AS; compression of the address 
> space through 
> > aggregation is only possible at the expense of path 
> information.) Of 
> > course, the current Internet is somewhere in between. But 
> who knows about the future?
> > 
> > system size could be made explicit: must we inherently make 
> > assumptions about the relationships between networks in order to 
> > produce a more scalable routing and addressing architecture?
> > 
> > Cheers,
> > -Benson
> > 
> > 
> > 
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>

---

From: David Conrad <[email-masked]>
Date: Sun, 26 Nov 2006 22:18:35 -0800

Peter,

I find this sort of list is very useful.  A couple of questions:

On Nov 24, 2006, at 12:02 PM, Peter Sherbin wrote:
>> assumptions

Which of these are you willing to pay?

a) a periodic (e.g., monthly) "routing fee" to offset the costs of  
your "IP address pool" being "globally" announced?
b) redeploy all software/firmware on your network?
c) have limited in your visibility into inter-AS network topology  
(that is, would you be willing to give up traceroute as a usable tool  
and lose the ability to use source address as a way of determining a  
network path)?

To be clear, you're going to have to pay one way or another  
(TANSTAAFL).  There may be other costs or alternatives I'm not  
listing.  I'd be interested in understanding what flexibility there  
is in paying for a change in architecture from your perspective.

> 2. a selection of competing networks to put my traffic on for as  

Presumably you want this ability without renumbering (that is, you  
can have (1) today if you use your ISP's address space).

> 3. a complete control on what goes out with my source addresses

Presumably, in as much as you have the ability today.  Or do you mean  
something else?

> 4. an assurance that what is coming in has come from its true  

Again, this has a cost.  If IPSEC is used, there is a complexity and  
performance hit.  Is that acceptable?

> 5. an ability to prevent receiving from unwanted senders

Same question as #3.

Thanks,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 26 Nov 2006 22:18:35 -0800

Peter,

Same question as #3.

Thanks,
-drc

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 27 Nov 2006 10:45:01 +0200

Peter,

A very interesting list of requirements.

While I like very much David's questions about what you would be  
willing to pay for and what not, and would like to see your answers  
to them, I'd like to ask a few more questions, from a slightly  
different point of view.  The reason I'm asking these question is  
that we (or at least I) would understand what users *really* want,  
and not only what they think they want, in the terms of the current  
architecture, so that those *real* needs could be fulfilled by the  
future architecture(s).

> 1. an IP address pool assigned to me for a lifetime

Why, exactly?  Are you trying to avoid a cost or a number of costs?   
What are the costs then?  (Note that I am not only talking about  
monetary costs but also things such as re-education of users, time  
required from administration, errors involved in renumbering leading  
to loss of productivity, etc.

Basically, my understanding is that today users want to have their  
"own" IP addresses due to the costs involved in changing the IP  
addresses.  However, I have relatively poor understanding of what are  
the *exact* costs involved.

Secondly, I suspect there may be other issues but costs, but I have  
no good idea what.

> 2. a selection of competing networks to put my traffic on for as  

What would you imagine to be the smallest desirable shortest time?   
One day?  An hour?  Change providers per-packet bases, on sub-second  
time-scale?

On other words, into who small time scales do you think we would need  
to go in order to deconstruct the current switching costs, thereby  
leading to a more even market and presumably lower prices?

> 3. a complete control on what goes out with my source addresses

This is something that I don't understand at all.  I am sorry.

What is the motivation for this requirement?  To put it bluntly, why  
do you care in the first place what goes into the source address?

[For the background, you may want to consider an half-tongue-in-the- 
cheek papers by us:
Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses  
Considered Harmful," in Hanne Riis Nielson (ed.), Proceedings of  
NordSec 2001, Sixth Nordoc Workshop on Secure IT Systems, November  
1-2, Lyngby, Denmark, Technical Report IMM-TR-2001-14, pp. 54-68,  
Technical University of Denmark, November 2001.]

> 5. an ability to prevent receiving from unwanted senders

These I have no further questions on, other than those by David,  
i.e., how much you would be willing to pay for them.  Again, when you  
consider "how much", I think it would be instructive to think about  
all costs, not only money.

--Pekka Nikander

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 27 Nov 2006 09:05:09 -0800 (PST)

Pekka, I will try to address yours and David's questions

> Why, exactly?

The assumption is that IPv6 addresses will be used primarily to automate processes
and/or run real time databases of dispersed items on private networks both
enterprise and individual. Hence renumbering must be avoided. Address pools will be
large, e.g. for an individual about /80 (roughly 3 times the number of cells in
human body), for an enterprise about /46 (based on 17 billion humans with /80 each).
Understanding that not all individuals and enterprises will ask for the above but
those who ask should be able to get it.

The big question (under discussion here) is how routing will support global
announcement of the above (assuming that about 98% of traffic will remain private).

> What are the costs then?

EU incurs costs:
1. to set / run a private network
2. to send packets outside a private network (these are reflected in providers' fees
where competition makes prices acceptable).

Cost model assumes that:
1. originator owns the information
2. originator has a need to move that information within or outside of her network
3. originator must cover cost for moving her packets

Providers on their side are supposed to capture the amount of traffic from each
sender for billing.

> addresses.

There are at least two drivers to keep addresses unchanged, which does not preclude
not-owning them:
1. Re-numbering could be very time consuming, i.e. costly
2. No dependency on a provider, which stimulates creation of long term processes,
services, etc.

> > 2. a selection of competing networks to put my traffic on for as  
> > long/short as I chose
> 

The model: I turn on a mobile device and a screen shows: Network A $/min, B $$/min,
C $$$/min. I select to place a call via B's network because I like their pricing.
For my next call I may choose the network C because their price is better. In
addition to pricing there are other considerations to stay with a provider for a
longer period:
- network based services they offer
- customer support
- billing, etc.

> leading to a more even market and presumably lower prices?

A basic cost driver in a voice world was/is 1min of call. In a packet world it is 1
bit, which could be expressed in MB, GB, etc.

> This is something that I don't understand at all.  I am sorry.

Private network operator (individual or business) collects data from/through that
network. All this information is proprietary to its collector.
E.g. a fridge company collects statistics on how I use the device and what do I keep
in there. I could buy into an argument that they need the data to adjust fridge
settings remotely for my benefit. For that purpose the company uses IP addresses
from their pool. Packets from my fridge will have company's source address and the
company will get a bill from my provider if they use my connection to send their
data. The company may also supply a fridge with their own connection.
When I have a home network and I monitor my pet in the backyard, my kid in school,
my boat in marina 50 miles away I need to be sure that all packets with the source
address from my pool are authentic.

> do you care in the first place what goes into the source address?

That the source is authentic and has not been compromised.

> > 4. an assurance that what is coming in has come from its true  

IPv6 enables end-to-end security, which is an opportunity for manufacturers to build
it into devices. For providers this is an opportunity to collect more because longer
overhead drives more traffic. But at some point overhead may become prohibitive.
E.g. from my understanding in G.729.a VOIP overhead is about 80%, which makes G.711
with about 67% more appealing. 

Thanks,

Peter

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 28 Nov 2006 13:13:10 +0200

Peter,

Taking your answers and trying to generalise them to apply any  
networking architectures, not only the current one, how wrong would I  
be, from your point of view, if I restated your requirements in the  
following way?  Note that I'm using the same numbering as you did in  
your original message.

1. Application-level identifiers assigned for a lifetime
    [Originally: an IP address pool assigned to me for a lifetime]

These identifiers must work with all applications, with addressable  
application entities dispersed at all levels, ranging from private  
individual to global distributed applications.  These identifiers  
should be completely independent from access providers, and not  
change when the network connectivity changes.  They should outlive  
any "mobility" situations, independent on time scale.

The primary motivation for their persistency is to avoid the costs  
incurring from they being changed, since such identifiers would be  
located through the systems in various odd locations.

[Due to us having only the socket APIs today, and nothing more  
abstract in wider acceptance, most people seem to think today that  
the only choice for such identifiers are IP addresses.  To an extend  
I agree; that's the very reason why we have suggested an experimental  
allocation; see draft-laganier-ipv6-khi-05.txt.]

2. Independent dynamic choice of providers for incoming and outgoing  
traffic
    [Originally:  selection of competing networks...]

It should be possible to dynamically select the best network for any  
incoming and outgoing traffic, using any local policies based on such  
factors as per-packet-or-per-bit cost, delay, bandwidth, utilisation,  
etc.

One aim of such ability would be to smoothen the markets and lowering  
entry barriers.  By being able to easily and dynamically select the  
carriers, even small customers together would have more purchasing  
power, thereby leading to lower overall prices and less price  
discrimination.

3-4. Full origin authentication and privacy about the origin of  
incoming traffic
      [Originally: 3. complete control on what goes out with my  
source addresses
                   4. an assurance that what is coming in has come  
from its true originator]

The end-receiver (organisation) of any incoming traffic should have  
reasonable assurance that the traffic is coming from a known (or an  
easily traceable source), while the immediate upstream access  
providers should have no information from whom the traffic is coming  
from.

This is one aspect of a balanced privacy/accountability that I have  
stated elsewhere several times.  Basically, we seem to need more  
privacy and more accountability, simultaneously.

[Incidentally, I happen to believe that the source address would be a  
completely wrong vehicle for such property, even in the current  
architecture.]

5. The ability to limit traffic incoming from unwanted / untraceable  
senders
    [Originally: an ability to prevent receiving from unwanted senders]

Related to the item 3-4, if there is incoming traffic whose origin is  
not know, or cannot be easily traced, or is otherwise unwanted based  
on its source, it should be easy to prevent that traffic from  
arriving.  Indeed, such traffic should be stopped as close to its  
source as possible.

[Ditto.]

--------

What I still don't see is how much a) money, b) trouble, and c) pain  
people would be paying for any of the above mentioned properties.

--Pekka Nikander

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 28 Nov 2006 12:11:34 -0800 (PST)

Pekka,

This generalization looks great. Thank you.

> arriving.  Indeed, such traffic should be stopped as close to its  

Regarding unwanted traffic as an EU I need an option to look safely at the message
and if I do not like it I has to be able to drop all packets from that source on
arrival. Let cyberpolice worry about the malicious source.

> people would be paying...

Those properties are expected features of the product. It would be still the same
Internet with costs determined by the amount of traffic crossing networks.
Hardware / software could be gradually upgraded on three fronts as per your earlier
message.

Thanks,

Peter

 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited