Subject: RE: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 24 Oct 2005 18:28:46 +0200

> => IMHO load balancing should not be provided by a DHAAD mechanism
> but by HA assignment or HA-switch.

I agree that HA-switch is needed (not only for load balancing), but if
an DHAAD mechanism already supports load balancing, signaling overhead
and delay can be saved by skipping a subsequent HA-switch. If MNs
frequently bootstrap with new HAs (e.g., when always using local HAs),
the saved signaling overhead and delay might be significant. 

>    Wouldn't it be possible to integrate HA discovery and 
> assignment somehow
>    in an IKEv2 exchange,
> 
> => this is the Security Gateway discovery issue. It is in the scope
> of the IPsec WG but I am afraid we should not wait for a solution
> from them, on another hand it has to be secure and IPsec people
> should be better...
> 
>    similar as HoA assignment is integrated in IKE
>    exchange in the bootstrapping solution? E.g., the first IKE message
>    (IKE_SA_INIT) sent by MN would have anycast address as destination
>    address (reply and all other IKE messages use unicast addresses as
>    source/destination) and the Configuration Payload in the 
> IKE_AUTH may
>    contain an HA address for assignment to MN (only used if 
> the HA that
>    received the anycast IKE_SA_INIT shall not be used, e.g., 
> because this
>    HA is overloaded). 
>    
> => note this is in fact Security Gateway assignment.

o.k., good to know. That sounds like an efficient (low signaling
overhead+load balancing support) and secure HA discovery/assignment
mechanism, but unfortunately it is not yet available.

>    > - AFIK, there is no way currently standardized to securely update
>    > anycast routing except to manually insert host routes 
> into the subnet
>    > router handling the anycast address. So maintaining an 
> anycast address
>    > would require extra maintenance effort, manually inserting and
>    deleting
>    > the routes when HAs are added or deleted.
>    
>    Interesting point, but isn't such a mechnism needed for almost all
>    anycast-based protocols? I.e., isn't there a need for such a
>    standardized mechanism anyway?
>    
> => no, the anycast-based protocols are request/reply protocols so
> they don't need responder stability.

Yes, but I think James point was that the subnet routers have to know
which hosts have configured which anycast addresses. RFC1546 (page 5)
discusses some possible solutions and proposes to advertise configured
anycast addresses to routers by using multicast (possibly with an
enhanced IGMP):

"Hosts which wish to receive datagrams for a particular anycast
   address will have to advertise to routers that they have joined the
   anycast address.  On shared media networks, the best mechanism is
   probably for a host to periodically multicast information about the
   anycast addresses it supports (possibly using an enhanced version of
   IGMP).  The multicast messages ensure that any routers on the network
   hear that the anycast address is supported on the local subnet and
   can advertise that fact (if appropriate) to neighboring routers.
   Note that if there are no routers on the subnet, the multicast
   messages would simply simply ignored.  (The multicasting approach is
   suggested because it seems likely to be simpler and more reliable
   than developing a registration protocol, in which an anycast server
   must register itself with each router on its local network)."

After quickly searching for anycast in RFC3376, I guess IGMP doesn't
support that.

Regards,

Kilian

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 18:42:55 +0200

> but by HA assignment or HA-switch.
   
=> I should have written "HA assignement or HA re-assignment like
HA-switch".

   I agree that HA-switch is needed (not only for load balancing),

=> yes, we should get HA-switch deployed before DNSSEC (:-).

   but if
   an DHAAD mechanism already supports load balancing, signaling overhead
   and delay can be saved by skipping a subsequent HA-switch.

=> HA-switch is re-assignment. It has a higher overhead if there is
no assignment but it can do dynamic load balancing, i.e., balance the
load after the initial phase.

   If MNs
   
=> local HAs is a better case of HA assignment (i.e., there can be
a mechanism available on this case but not general).

   
=> I'll be more optimistic: there is no general already specified
mechanism.

   
=> anycast and multicast are two variations of the same destination
group addressing. IMHO anycast is a bit easier because there is no
collision issue on replies.

Regards

[email-masked]