[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]]

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

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.





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 
wrote:




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)



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?