[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Survey on proposed IPv6 multi-homing mechanisms
Hi Marcelo,
[cross-posting to mobile-ip list]
marcelo wrote:
>
> Hi,
>
> We have been working on a survey of proposals related to IPv6 multi-homing.
> We think that this could be a good input for a discussion about
> which of these ideas can be valuable, and need to be further developed.
> We have included all the mechanisms that we have found. If there are other
> mechanisms, please let us know. We have also includes some advantages and
> concerns about the mechanisms, but we think that discusion will really
> disclose much more points.
[...]
> 5. Mobility mechanisms
>
> Another proposal presented in [DUPNOT] is based in the use of IP
> mobility mechanisms. The main idea is to use the care-of-address
> assignation mechanism to switch between delegated addresses in case of
> failure. Suppose that there is an established communication between
>
> Survey on multi-homing mecanisms 7
>
> hostA belonging to the multi-homed site and hostB, somewhere in the
> Internet, as shown in figure 4.
>
> ___________________________________________
> | Internet |
> | hostB |
> |___________________________________________|
> | |
> | |
> +----+ +----+
> |ISPA| |ISPB|
> |BRA | |BRB |
> +----+ +----+
> | |
> link1 | | link2
> __|____________________________|___
> | RA RB |
> | | | |
> | ------------------------------- |
> | | |
> | hostA |
> | PrefA:Prefsite:hostA |
> | PrefB:Prefsite:hostA |
> | |
> |___________________________________|
>
> Figure 4: Mobility mechanisms
>
> The established connection is being routed through ISPA and
> PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are
> followed in order to preserve communication:
> - HostA packets contain the home address destination option with
> PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so
> that for every device on the path source address is
> PrefB:Prefsite:hostA and only hostB replaces this source address by
> PrefA:Prefsite:hostA.
> - HostA sends a binding update containing PrefB:Prefsite:hostA as a
> care-of address. Note that that authentication header is needed in
> this packet.
> - HostB sends a binding acknowledgement. This packet and all next
> packets are sent with PrefA:Prefsite:hostA as final destination
> (included in a routing header) and PrefB:Prefsite:hostA as next
> destination (included as destination address). Consequently, all
> packets are sent towards HostA using ISPB, and address "translation"
> is done when packets reach HostA.
>
> Mechanism Evaluation:
>
> Advantages:
>
> - The mechanism provides complete fault tolerance.
> - It uses existing protocols.
> - It allows ISP selection for load sharing.
>
> Survey on multi-homing mecanisms 8
>
> Concerns
>
> - Needs Mobile IP implementation on destination host. So, modifications
> in external hosts are needed to achieve internal multi-homing.
> - Mobile IP security mechanisms impose the use of authentication header,
> raising complexity.
>
>
Currently, Mobile IP WG has to come up with a solution to establish
security associations between the MN (host A) and the CN (host B). SA
establishment using public key infrastructure is assumed to not be
available everywhere and with all CNs.
The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak
but strong enough for the purpose) mechanism that involves a home agent
during the key exchange. The validity of the MN's binding of the home
address is verified by the CN by sending packets via the home network.
The home agent address belongs to the same prefix as the MN's home
address, i.e. PrefA:Prefsite::.
If no SA is set up prior to the failure of ISPA, the key exchange will
fail since the CN can't send packets through the home agent any more.
/Mattias