RE: Multihoming experiment

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Hi Iljitsch,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Iljitsch van Beijnum
> Enviado el: martes, 15 de julio de 2003 14:20
> Para: multi6@ops.ietf.org
> Asunto: Multihoming experiment
>
>
> A few observations on Christian and David's multihoming experiment:
>
> This means source address dependent routing,

I would say that source address based routing is one of the options, as
mentioned in Christian?s draft.

I guess that the point here is which element has the knowledge to decide
which exit path to use.

One option is to maintain current paradigm, where the routing system within
the site decides which exit will be used by the packet. In this case, we
need that the routing system informs the host which source address the host
has to include in the packet, so that it is compatible with the ingress
filtering that is configure in the exit path that has been selected by the
routing system. There is simple solution for this that is included in
Christian?s draft and it has also been mentioned several times by F. Dupont
and which is to define a new ICMP source address redirection message. So the
hosts select a source address and the routing system carries the packet to
an exit router. If the source address is compatible, then ok the packet is
forwarded. If the source address is incompatible with the exit selected,
then the router issues the ICMP message indicating that an alternative
source address has to be used.

The other option is to asssume that the exit path is defined by the host,
this would be the case where policies are defined within the host (for
instance configuring the policy table defined in rfc 3484 or the other
option is consulting the NAROS server) In any case, the exit router
selection is no longer performed by the routing system looking at the
destination addres, but it has been already performed by another system,
(host, NAROS) when the source address was selected. At this point, the
routing system inside the site becomes very simple: it only has to look the
source address prefix and forward the packet to the correct exit.I think
this can actually be an interesting feature, i mean, routing table of the
router inside the site will only have as many entries as exit paths. I agree
that there are no routing protocols currently defined for handling this kind
of source address based routing, but perhaps this should not be so
difficult, considering that the complexity has been moved somewhere else (to
the element that selects the source address)
We have been discussing these issues with Cedric and we are considering to
work on some of these issues to see how it would work and see possible
limitations.

Comments?

Regards, marcelo & Cedric


but I don't think this
> term is used anywhere. The consequence of this is that sites that
> implement this CANNOT use any form of dynamic routing. Also, I'm afraid
> there will be traffic engineering problems because of RFC 3484 for
> hosts that implement this. For instance, if at some point the RIRs use
> up 2001::/16 and they start giving out address space from 2003::/16, a
> host with a 2001:: and a 2003:: address will use the router that
> announces the 2001:: prefix for all traffic to 2001::/16 which would be
> nearly all of the IPv6 internet.
>
> And note well, from RFC 3484:
>
>     Well-behaved applications SHOULD iterate through the list of
>     addresses returned from getaddrinfo() until they find a working
>     address.
>
> Applications that don't implement this will have to wait for a prefix
> to become deprecated to switch to the other one, so the multihoming
> benefits for those applications would be even smaller.
>
>