Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> > IMHO You would want to use the source address based routing
> > when you don't want to use source address rewriting.
> > There are some situations where you don't want the rewrite to
> > take place and you want source address based routing.
> > I can think of the following:
> > - The external host don't support M6
> > - The M6 context has not been established yet
> > - An ULP hint made the M6 layer to select a different path, so
> > you want to let the host select the ISP and not the routing system
>
> I understand why the first bullet doesn't want source rewriting, but from
> that it doesn't follow that source address based routing is needed.

Sorry, you are right.
You don't want source address rewriting and you need an ingress filtering
compatibility mechanism, which could be source address based routing. There
are other options for this as decribed in Christian's draft, such as
- a routing header (or tunnel) initiated from the host
- an icmp source address error from the exit routers back to the host
- tunnels between exit router (sort of source address based routing limited
to the exit router)

>
> The second case can be made to handle rewriting by carrying the
> identifiers explicitly in those packets. This has the cost of
> additional overhead during the M6 context establishment, but might have
> benefits in terms of more quickly being able to detect failures during
> that establishment; need to understand the details in that tradeoff.
>

Ok.

And the third case could be also addressed with some of the mechanisms
mentioned above, i guess that source address based routing or routing header
can be used for this case. ICMP and tunnel between exit router are not good.

So, backward compatibility with non M6 enabled host require a alternative
mechanism to source address rewriting. ULP hints would also require it. And
packets exchanged before context establishement would also benefit from it.
The identified mechanisms to provide this would be source address routing or
a routing header.
Do you agree with this summary?

[...]
> I don't understand what pieces of the total routing system
> needs to be changed to support source address based routing, so I'm not
> sure this makes any sense.

Ok.

The question here is whether every multi-homed ISP will be able to get an
allocation or it will have to obtain addresses form its upstream providers,
right?

Well let's assume that it will obtain addresses from their upstream
provider.
Let's asume that ingress filtering will be in place, ok?

Now, how would you deal with this without source address based routing?

Let's start with ingress filtering compatibility:
the options were:
- source address based routing. besides the multihomed site all isps that
don't have its own allocation would need to implement it
- routing header. this would require n addresses in the routing header, one
per upstream isp than don't have its own allocation, imposing extra
overhead, and besides, i am not quite sure how the end host would discover
the addresses of all the exit routers in the the path ( i am not sure how it
will find out n, neither)
- icmp back to the host. You have already mentioned some security concerns
about letting externally generated ICMPs influence the path selected by
hosts
- tunnel between exit router. well, i guess that this would be really
complex, since you would require tunnels between all exit router of the isp

If you want to support ULP hint mechanism you only have the first two
options.

So, IMHO even if not all the multihomed isps won't get a direct allocation
from the rirs, source address based routing seems the simplest option.

Regards, marcelo

>
>   Erik
>