Re: Source address selection in IPv6 multihomed multi-addressedsites

[lek <sponpitk@ratree.psu.ac.th>]

Hello Cedric,

    I wonder in any solution impling source address based routing
that is it possible to use routing header instead of using
source address based routing. If it could, I think using routing
header is easier than source address based routing.
    Please correct me if I misunderstood.

Regards,
Pornpitak.


On Wed, 16 Jul 2003, Cedric de Launois wrote:

> These are my random thoughts about source address
> selection in IPv6 multihomed multi-addressed sites.
>
> I believe this problem needs to be resolved to get
> a complete IPv6 multi-addressing multihoming solution.
> We assume here that the providers perform ingress
> filtering.
> I'm here only looking to solutions where the source
> address selection is not made by applications, but it
> is done "automagically". However, for all these solutions,
> it is possible to imagine some mechanism where the
> applications can overload the automatic behaviour.
>
> Here is my understanding of the different solutions
> proposed.
>
> * A solution is to perform source address based routing
>    inside the multihomed site. The packets are always
>    routed to the site exit router corresponding to the
>    source address used.
>
>    Pros: - no new option/protocol
>          - no modification to hosts
>          - no tunnel
>          - routing efficiency (dumb routing) ?
>
>    Cons: - possibly very bad load-balancing if all the
>            hosts choose the same source address (and this
>            is what they'll do with RFC3484 !) +
>            no way to engineer the traffic if no additionnal
>            mechanism is used
>          - source address based routing has probably
>            much more implications than what it is
>            expected. This needs to be studied further.
>
>    My point of view : maybe source address based routing
>    is not something desirable. Anyway, source address based
>    routing alone is not sufficient.
>
> * Another solution is to establish tunnels between the
>    site exit routers. When a packet with a wrong source
>    address is received by a site exit router, it is
>    tunneled to the right exit router.
>
>    Pro : no modification to hosts
>    Cons: - a tunnel, reducing the MTU
>          - no way to engineer the traffic
>
>    My POV: I think this solution is too rigid and
>    that a solution based on an ICMP source redirect can
>    lead to a better solution without adding much more
>    cost.
>
> * A third solution is that a host first try a source
>    address (at random?). If the source address is not
>    correctly chosen (e.g. the link is down), then a
>    new source ICMP redirect is sent by the site exit
>    router to the host.
>    This ICMP message tells the host which source address
>    to use.
>
>    Pro : no tunnel
>    Cons: - modifications needed on the hosts
>          - at first look, difficult to engineer the
>            traffic with this mechanism
>
>    My POV: I think this solution is the most credible
>    when the site is small and doesn't need complex
>    policies. However I think the ICMP source redirect
>    message should also contain a prefix associated to the
>    source, like in the NAROS response messages. This would
>    allow the host to fill its policy table step by step.
>    This approach has to be reserved for small sites with
>    few requirements.
>
> * A fourth solution is that a service (NAROS) tells the
>    hosts which source address to use.
>
>    Pro : - the most complete solution since it allows any
>            kind of traffic engineering
>          - no tunnel
>    Cons: - also the most complex solution since it
>            requires changes in the hosts and to set up
>            a new service
>          - implies source address based routing
>
>    My POV: isn't that too complex for small sites ? Maybe.
>    Is there a need to manage complex requirements is
>    host-centric multihomed sites ? Probably. Anyway, the
>    solution has the advantage of being rather complete. At
>    the price of complexity.
>
> * A fifth solution is that the hosts know which source
>    address to use thanks to DHCP. When they boot, they
>    receive a full policy table from their DHCP server.
>    This policy table contains informations about which
>    destination is accessible through which site exit router
>    etc.
>
>    Pros: - no tunnel
>          - easy configuration
>    Cons: - requires a new DHCP option. Modifications to
>            host are needed
>          - complex traffic engineering not supported
>          - no dynamic, how to react to a failure ?
>          - implies source address based routing
>
>    My POV: seems to rigid for me. At almost the same price,
>    we can get the same features + dynamic with the ICMP
>    solution.
>
> * A sixth solution is that a host tries to detect
>    by itself which source address to use. A proposition
>    is that a host maintain by itself one or more full BGP
>    tables so that it can deduce the source address to use.
>
>    Pro : no tunnel
>    Cons: - waste of computer resources (how much ?)
>          - no easy configuration
>
>
> Any comment/suggestion/correction ?
>
> Cédric
>
>
>