Subject: RE: tunneling [Was: Agenda for Vienna]

From: "Tony Li" <[email-masked]>
Date: Wed, 21 May 2003 01:02:27 -0700

|    > |    I don't think we can make informed decisions about the
|    > |    architectural
|    > |    approach unless we know how well each approach is going to
|    > |    work out. That's why I keep going into detail.
|    
|    > This is a common trap.
|    
|    So then there must be a reason why it's hard to avoid it.  :-)

Good engineers are detail oriented.  Even when they shouldn't be.

|    Didn't we kinda sorta agree that loc/id is our collective favorite 
|    architecture and that the rest is either flawed, should be 
|    worked on 
|    elsewhere or no interest in working on it as a group?

I think that you and I agreed that.  However, if we are to truly build
WG consensus on this issue, it's only fair that we allow supporters
of alternatives to speak their piece.  I'm hoping that if there are
any such folks, they will speak up, so that we are not accused later
of shouting them down.

|    Even though we get a bit sidetracked from time to time, I 
|    think we're 
|    having a very useful discussion on the identifier 
|    semantics and mapping 
|    mechanisms right now.

I think that the cart belongs behind the horse.  Until we get rough 
consensus on the architecture and make a decision, all other energies
are a distraction from that milestone.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 May 2003 12:02:26 +0200

Tony is correct, we need to take the big decisions first. So, I think we
have these options to consider:

1. For really big enterprises, leave the RIRs to set a policy that
allows such enterprises to get a /32 and negotiate appropriately
with ISPs. No work for the IETF.

2. Design a multi-address based solution, where an enterprise would 
have multiple PA prefixes and some technology would be added to support 
address selection. draft-de-launois-multi6-naros-00.txt
might be the starting point.

--> this is a conservative approach. It doesn't change anything in
    the addressing or routing architecture. We could write a WG
    charter for this quite easily.

3. Design a two-level solution, in which a locator is used
for routing and an identifier is used end2end (and possibly 
for local routing). There are several sub-options:

3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping.
    In this case, both the locator and the identifier can be standard
    addresses, the identifier perhaps being something like
    draft-hinden-ipv6-global-local-addr-00.txt.

3.2 Splitting the address into two fields, and swapping routing prefixes
    en route (a.k.a. GSE)

3.3 Swapping & restoring addresses en route. Again, both the identifier 
    and locator can be standard addresses.

3.4 Carrying the identifier, whatever it is, in an extension header.

All of these carry the need for locator mapping. Actually, the multi-address 
method also needs equivalent mapping information, it's just a bit hidden. 
So that seems to be our fundamental piece of magic. 800 numbers, anybody?

It seems to me we can plausibly pursue all three of the above approaches,
with 1) being immediate, 2) being medium term and any of 3) being long term.

4. Transport layer solution. My belief is that TCP is too entrenched for
this to be a reasonable approach.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 May 2003 11:16:58 +0100

This looks good.   For #2, Christian also presented a 4-6 stage plan that
would enable such a solution.  I haven't read launois-multi6-naros-00 yet,
maybe it is similar to Christian's proposal.

If we have concensus on this, we could build and agenda around it.

But I am very aware there are other proposals, which should be allowed a
fair shout (or which may go their own commercial way anyway ;)

Tim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 May 2003 13:25:39 +0300 (EEST)

> this to be a reasonable approach.

I think we need to realize that these four options solve different 
problems, and not all of them completely.

Based on a quick look, it seems to me that:

 - being able to switch ISP's without renumbering: 1), 3.2), maybe others
 - redundancy due to link failures etc.: 1), maube 2), maybe 3)
 - connection survivability (internal connections, external connections) 
1), 4), maybe some of 3)
 - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe 
1), 2)
 - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3)

I can summarize this at least to:
 - even if we modify all the transport layers to be address-agile, it's 
not enough.
 - if we need connection survability (some might not), it needs to be 
coupled with some other solution which provides capabilities for it (ie. 
multiple addresses), or inherently provides it (PI address, GSE?)

So, I must conclude we must be very, very careful in determining our 
options (and what exactly those options are good for).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: marcelo bagnulo <[email-masked]>
Date: 21 May 2003 12:53:08 +0200

Hi Brian,

I would say that these three are not _options_ but three approaches that
we should follow since the three of them are needed (i do not know if
this is what you meant)

Immediate solutions for big sites (option 1) and for small sites (option
2).

Long term solution Option 3 we have to discuss which one of them (or
others)

I think we have to do the three of them and i think this is a good
roadmap.

Thanks for the writing,
regards, marcelo 

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: marcelo bagnulo <[email-masked]>
Date: 21 May 2003 12:56:00 +0200

Hi Pekka,

I agree that different sites will have very different requirements, so i
think that within the short term solutions, multiple complementary (not
competing) mechanisms are needed, so that a site can choose which
mechanism to implement in order to satisfy their particular needs.

Regards, marcelo

---

From: "Michael H. Lambert" <[email-masked]>
Date: Wed, 21 May 2003 08:42:24 -0400

> mechanism to implement in order to satisfy their particular needs.

And for each solution there needs to be a good understanding of its 
performance implications.  A viable mechanism over DSL might not be when 
used over gigabit ethernet.

Michael

---

From: Olivier Bonaventure <[email-masked]>
Date: 21 May 2003 15:07:58 +0200

Michael,
> used over gigabit ethernet.

For NAROS, Cédric de Launois has evaluated its performance by simulating
the performance of the proposed protocol on a one-day trace of all the
IPv4 traffic of our University (about 8000 hosts in the site and 200
GBytes of traffic, i.e. 20 Mbps on average over the whole day). This
evaluation shows that the NAROS approach scales well. You can find more
details on this evaluation in the following submitted paper :

http://www.info.ucl.ac.be/people/delaunoi/paper/naros.pdf

Best regards,

Olivier Bonaventure

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 May 2003 16:14:57 +0200

But if every NAROS message needs to be digitally signed to
prevent spoofing, that might change.

   Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: 21 May 2003 16:33:08 +0200

> prevent spoofing, that might change.

The study measures the number of NAROS requests sent by clients to the
NAROS server. With the site considered, the peak was about 300 messages
per minute, but usually 100 requests per minute during the business
hours. It should be noted that the study was done on a site without
firewall and where we receive lots of port scans that significantly
contribute to the load of the NAROS server. Of course, the CPU load
would be higher if the requests sent by the client or the responses sent
by the server need to be authenticated.

However, there are several features of NAROS that may improve the
scalability of the solution. First, the NAROS server is only used by the
clients inside the site. This means that if the site has a firewall
(this was not the case in our study), the firewall could easily block
all packets sent towards the NAROS server. 
Second, the NAROS server does not maintain any state about the clients
and it is based on UDP. This means that several hosts could act as a
NAROS server by listening to an anycast address. This could easily
decrease the per-server load.

Best regards,

Olivier Bonaventure

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 May 2003 10:40:44 +0200

> are a distraction from that milestone.

 From the mailinglist and previous discussions, I would say we have, or 
are very close to having WG consensus on loc/id mapping. Is this 
something that we should bring to the table for the second session in 
Vienna and vote on? Or should we have this sorted before then?

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 May 2003 15:00:55 +0200

On woensdag, mei 21, 2003, at 18:43 Europe/Amsterdam, Christian Huitema 

> I personally like conservative approaches.

:-)

Me, I'm al in favor of conservatism as long as it doesn't get in the 
way of progress.

> As for multi-addressing itself, naros addresses one of the issues, i.e.
> the choice of addresses by multi-addressing aware hosts.

Christian, could you (again) send some pointers to what it is you're 
talking about when you say "multi-adressing"? (It has been a long time 
since Atlanta.) Obviously all IPv6 hosts know about having more than 
one address. Which immediately poses the problem of both source and 
destination address selection. NAROS is a good approach to start 
solving this problem but there is more work to be done there, IMO.

It occurs to me that the address selection problem isn't so different 
between loc/id and other multiaddress solutions. It's just that in 
loc/id it isn't as vital to get it right as you can change your mind 
later.

So it's probably useful to make something that can help with address 
selection, regardless whether a host implements naive multiaddressing, 
your proposal or loc/id.

On woensdag, mei 21, 2003, at 12:25 Europe/Amsterdam, Pekka Savola 

>  - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3)

Ok, let's have a look here.

First of all, what is "switching" ISPs? Dropping an existing ISP should 
be trivial: just disconnect and stop your routers from advertising the 
prefix. This should work well even with current implmentations because 
IPv6 applications are reasonably smart in trying several addresses 
until they find one that works. (They have to try v6 and fall back to 
v4 anyway, so multiple v6 isn't that much more work.) Adding a new ISP 
isn't all that hard either: add connectivity, start prefix 
announcements and change the DNS.

There is one caveat, though: access filters. More on that later.

And obviously all of this assumes you can work with multiple ISPs to 
start with. That means either hosts know how to select the right source 
address (in practice that means they must have a routing table) or 
source address dependent routing. NAROS or something similar could help 
here for traditional multiaddressing. Note that source address 
dependent routing (SADR) is superior as this survives routing changes 
where a certain destination is suddenly preferred over ISP 2 rather 
than ISP 1. Without SADR your session dies. Loc/id can solve this with 
heuristics and/or rewriting source addresses at egress, which is of 
course even better.

The same thing but worse happens when a link or ISP fails. Only loc/id 
can save your ongoing sessions then. Note that for many applications 
(web browsing and normal length email) this isn't much of an issue as 
the layer 4 sessions are very short. But then sometimes they are long 
(downloads) so we can't ignore this problem. (If you need an hour to 
transfer a file then 55 minutes of connectivity over one ISP and no 
failover is actually worse than no connectivity: then you wouldn't have 
wasted your time.)

There are many ways to traffic engineer. Something like NAROS that also 
looks at the destination address would be a good way. Selectively 
dropping TCP SYNs to get hosts to connect over the other line would be 
another. With loc/id + SADR we are in traffic engineering heaven as it 
becomes possible to load balance a single session over more than one 
ISP.

So I'd like to reserve two of Tony's maximum of 9 top level subsystems:

- a mechanism to order possible combinations of source and destination 
addresses (locators) on expected connectivity and "cost"

- a mechanism to determine the actual connectivity properties of a 
source and destination address (locator) pair

On the filtering thing:

If we do loc/id in the host firewalls have a hard time seeing who 
packets are really coming from. Who they are going may also be a 
problem but this one should be solvable as you can control the 
who<->where mapping in your own site, but obviously there is no way to 
know about this for the entire net. And even if we don't do loc/id, 
filtering on remote addresses is evil as it makes renumbering virtually 
impossible.

But do we really need the option of filtering on remote addresses?

I'm saying we don't. However, this means people will have to use other 
authentication mechanisms, such as IPsec or TLS. Is this reasonable?

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 18:24:43 +0300 (EEST)

On Thu, 22 May 2003, Iljitsch van Beijnum wrote:
> First of all, what is "switching" ISPs? 

Having a PI address which is globally reachable: not having to change 
addresses used by hosts in your site if you wish to change your network 
service provider.

> Dropping an existing ISP should 

Uh, oh.  It isn't as simple as that, and gets even more complicated the
bigger the site becomes.  I can the required operations in my home network
manually in 10-15 minutes, maybe; and I have just one router and a few
computers.

But I'm not as optimistic about bigger sites..
 
> than ISP 1. 

Indeed.

> Without SADR your session dies. Loc/id can solve this with 

I'm not sure how loc/id could solve this (by guessing to try another 
locators when one doesn't get acks, I suppose), but no matter.
 
> can save your ongoing sessions then. 

Nope.  Heard of "multihoming at site-exit routers"?

Of course, this doesn't help you if the whole ISP melts down (and not just 
their border router towards you or whateveR).  But that's IMO such a rare 
occurrence with real ISP's that you shouldn't be too worried.

> becomes possible to load balance a single session over more than one 

I'd like to agree that the traffic engineering with more specific route 
advertisements is rather lousy tool at best.. but the options seem to be 
to do it with that way or in the application layer (with some 
application-specific intelligence and redirection) at the moment..
 
> know about this for the entire net. 

Agree.

> And even if we don't do loc/id, 

Maybe not -- but on on remote identities -- might be useful.

One thing is sure: network managers won't want to relinquish security 
control of their nets to the hosts, or host operating systems.  This may 
be mitigated by the new distributed end-host firewalls WG, though -- but I 
haven't had time to look at the direction they're heading.