design of a real routing v. endpoint id seperation

Sun Oct 16 17:18:37 UTC 2005

How about something like this.

A chunk of ipv6 space is carved off. This is assigned to multihoming 
desiring sites.

All routers {can | should } filter this space from their tables 
completely by default - except the single prefix covering the entire space.

A customer with a prefix assigned from this chunk has to connect with an 
  ISP who has

* a Very Large Multihoming (to handle scaling concerns) router somewhere 
in its network that peers to other ISP Very Large Multihoming routes.

ISP operating a VLMrouter to offer multihoming service to their 
customers would originate the entire multihoming space prefix to their 
customers AND to all their peers.

These would have ALL the prefixes from the Multihoming Space.

* the customer would peer with the VLMrouter, receive no routes and 
advertise their prefix.

* source routing allowed on ingres IF the destaddr is in the multihoming 
space AND the route-option is the Very Large Multihoming router

* source routing is allowed within the ISP network

The VLMrouter would make a SOURCE routing decision, putting a source 
route destination to the customer.

* The ISP allows egress source routed packets

What this means is that there are 2 tables on the internet, the table 
that ALL internet routes need have (like today) and the table that only 
an ISP offering access to multihoming need have. The ISP offering such 
access would only need, say one box per POP or so.

So the scaling problem becomes much smaller in scope. Now only ISP 
wishing to offer multihoming services need to track the multihoming 
table. Additionaly, the tables are actually halved, the VLMrouter need 
not contain the normal internet routes and vice versa.

The downside is that an ISP performing as multihoming table hoster would 
be a magnet for traffic that would possibly transit in and out.

Smaller multihoming hosting ISPs would probably try to prepend the 
prefix mightily, or arrange not to originate it at all, and simply 
receive prefix source routed from an ISP they connect to who also hosts 
multihoming hosting AND originates the prefix.

No changes to stacks, endpoint nodes or anything else needed.
(if source routing still works in ip6?)
Some source routing filtering capabilities needed for border patrolling

something like this

config-if#ip source-routing prefix-list multihoming-prefixes 
access-group allowed-source-routes

Joe