Re: host or border router

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Wed, 11 Dec 2002, Iljitsch van Beijnum wrote:

> [Peter, I was going to reply to your message but decided against it in
> order to more easily maintain my own train of thought.]

That's ok.  I was going to expand further on the CCS as to how I'd typically
see it deployed.  However there has been little comment on my idea - just
waiting for feedback before expending more intellectual resources on the ideas.

> 
> If we are going to create a multihoming solution that uses identifiers 
> that are usable as IPv6 adresess for end-to-end identification and 
> regular unicast IPv6 adresses that replace the identifiers in transit, I
> see three ways to handle the address replacement:  
> 
> 1. In the end-host 
> 2. In a site border router (SBR)  
> 3. In some kind of middlebox 
> 
>

Whatever solution is deployed, of these 3, I would prefer 1. 

I think there will always be concerns as to whether a SBR will work.  The
problem with what I am propoing is that is isn't optional. it's an all or
nothing idea.  People can opt to use NAT and find a hardware solution that
works.  When they run out of steam, they have to move to real addressing and a
proper network.  Firewalls are much the same.  They function ok when they are
small, but when you get a monster site and you start having to make difficult
choices like making sure it isn't stateful and stuff. 

A middlebox is another point of failure and this would need to be thought
through carefully - can it be made redundant with rapid failover?  Is it
additional hardware cost in an IT world which is starting to count pennies more
than ever?

Since we are trying to design for the future, not for things as we see it now,
I would always prefer a solution that has room to scale.  We should be looking
for solutions where packets are not modified in transit - this is consistent
with IPv6 routing conventions.  That's why doing it in the hosts is starting to
look like the most scalable solution for the long term, but only if we can
constrain the lists of alternative addresses so that the host is not burdened
too much.  If we can get the CCS right, the address twiddling only needs to be
done at connection establishment time and when there is a path failure.  If the
CCS is rugged enough, the host would only need to keep two addresses - the
formal address and the actual address, and trust the CCX to return the right
information.  I still think it's a good idea to authenticate a new address when
it is to be switched over, and keeping the full set of potential MH addresses
is optional for the host.  Whichever way we go, it is important that the
complete list be able to be reconstructed at any point in the lifetime of a
connection - it's a matter of how much the host wants to trust the CCS and how
much MH information it wants to maintain itself.  Perhaps for regular work like
a large web site or somthing, the CCS is adequate, but for mission cirtical
stuff where you want to be absolutely sure you aren't being spoofed (e.g. 
linking exchanges - see later), you do the full MH exchange of addresses at
connection startup and keep the full address lists.

Some more on the CCS - I think that acronym is too overloaded so how about CCX
(Connection Cache eXchange system) but I will continue to use CCS for the time
being. I will refer to nodes in the CCS as exchanges.


I see it as a parasitic system that monitors the BGP system in a read only
manner.  Kind of like an autonomous feedback system for the network, and I'd
visualize it as an organism that has tentacles tapping into border and
transit routers.  An exchange could monitor as many BGP nodes as it feels
necessary and has authority to do so.  Very likely such monitoring will need to
be authenticated to prevent spoofing of CCS information.

Some additional characteristics.  

It would have to push network state information around in some manner and would
also have to be immune to some extent from path failures that it is trying to
prevent - would SCTP be a good candidate here?

Linking exchanges.  

Within a site if an exchange is 1 hop away, we can trust it to the same level
as we already do for ND.  The same applies for adjacent exchanges - if they are
1 hop away, then they can be trusted in much the same way as BGP trusts its own
peers (this assumes that a border router doubles as an exchange).  If an
adjacent exchange is more than one hop away, then I think the traffic should be
authenticated - I don't see this as difficulty because an exchange is a key
infrastructure item and so adding a level of security would prevent hostile
attacks on exchanges.

One advantage over the BGP system is that exchanges can be more highly meshed
than just its neighbors.  It would be possible to mesh exchanges so that a high
degree of path redudancy is maintained so that information can reliably sent. 
However one needs to take care that the right path topology is returned to the
site boundaries so that the correct MH prefixes can be used.

Peter

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210