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

From: "Narayanan Vidya-CVN065" <[email-masked]>
Date: Mon, 24 Oct 2005 11:46:50 -0400

Hi Alex,
 
> Let's compare to RO.  RO is a solution when MN and CN can't 
> use IPsec/IKE because PKI may not be deployed everywhere.
> 
> Same with non-anycast DHAAD, probably.  DNS-based HAD is a 
> solution when DNSSEC is deployed everywhere, otherwise use 
> non-anycast DHAAD, no?
> 

This is just my ignorance - what is non-anycast DHAAD? :) 

> > Also, it moves away from having to configure the home network prefix
> 
> Yes, but it enforces the configuration of (textual variations 
> of) "home.com".  A real advantage for DNS-based easying the 
> bootstrapping would have been if there was nothing to pre-configure.
> 

When you are doing discovery based on service name - say, "mip6" - this
is equivalent to zero config - it is a well known service name and
doesn't really require per-MN configuration. 

> > and removes the limitation of dynamic HA assignment within the same 
> > subnet, both of which are big pluses in my mind.
> 
> One may see multiple-subnet HAs for a single MN as a big 
> plus, but it is not at all clear whether a MN could continue 
> using the same HoA after changing its HA from one subnet to 
> another.  And, if when the MN switches its HA on another link 
> is changing its HoA as well - it is equivalent to running 
> DHAAD with a different subnet prefix.

Here, we are talking about two different aspects. I was referring to HA
assignment during bootstrapping, which can be done across subnets - so,
load balancing across subnets or assignment based on geographic
proximity becomes feasible. You are talking about a HA switch, that may
happen after a particular HA has been assigned. This seems to be a
different beast that needs to be tackled separately. But, yes, for a HA
switch, it still needs to be ironed out whether an MN can actually
continue to use the same HoA. 

Vidya

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 17:50:23 +0200

> This is just my ignorance - what is non-anycast DHAAD? :)

Sorry, term just been invented minutes ago, it's like having a version
of DHAAD without using anycast addresses, because current DHAAD delies
on anycast addresses and IPsec can't run with them.

> doesn't really require per-MN configuration.

My turn to be ignorant, is it like MN could interrogate local DNS
telling it "give me the address of my HA"?  What would DNS use to
identify that MN and send it back its proper HA (and not some other MN's
HA)?

Alex

---

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

=> what I don't understand is how the MN gets first the non-anycast
address? If it has already a HA and wants just to get other available
HA IMHO HA-switch (as a re-assignment mechanism) is a better solution.

   > doesn't really require per-MN configuration.
   
=> I disagree a bit: you need a name (FQDN) to query about.

=> a property of the DNS (and of the current DHAAD but this could be changed)
is the answer should never rely on who sends the question or where it comes
from. So "my HA" doesn't make sense, but of course "myHA.example.com"
or "...msp.example.com" do.

Regards

[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 20:31:07 +0200

Francis Dupont wrote:

> Sorry, term just been invented minutes ago, it's like having a 
> version of DHAAD without using anycast addresses, because current 
> DHAAD delies on anycast addresses and IPsec can't run with them.
> 
> address?

Well, if we say that the non-anycast address is reserved somehow, then
it is sufficient for the user of MN to preconfigure the home prefix on
it, manually somehow.  Then add to it the 'reserved' feff:ffff:ffff:ffee
(which is not anycast) and it obtains a reserved IPv6 address that says
"all HAs on the home link for DHAAD".

> If it has already a HA and wants just to get other available HA IMHO 
> HA-switch (as a re-assignment mechanism) is a better solution.

Well, DHAAD Reply contains a list of HAs ordered by priorities.  Once it
has that list the MN could switch to another one, provided of course
that the HAs have their BCs synched.

>> When you are doing discovery based on service name - say, "mip6" - 
>> this is equivalent to zero config - it is a well known service name
>>  and doesn't really require per-MN configuration.
> 
> identify that MN and send it back its proper HA (and not some other 
> MN's HA)?
> 
> => a property of the DNS (and of the current DHAAD but this could be 
> changed) is the answer should never rely on who sends the question or
>  where it comes from. So "my HA" doesn't make sense, but of course 
> "myHA.example.com" or "...msp.example.com" do.

I agree, the user still has to pre-configure "example.com" on mobile.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 14:45:13 +0200

=> I don't believe the BCs should be synched. In (any) DHAAD reselection
or HA-switch, the MN knows it will use a different HA so it will start
a new bootstrapping phase. But if the HA change is transparent (i.e.,
if the MN doesn't know it is switching from a HA to another one, note
this seems to imply the HA address stays the same so a VRRP-like
mechanism) the BCs and IPsec state must be synched or synchable.

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 14:49:21 +0200

Francis Dupont wrote:
>> If it has already a HA and wants just to get other available HA
>> IMHO HA-switch (as a re-assignment mechanism) is a better solution.
>> 
> 
> Well, DHAAD Reply contains a list of HAs ordered by priorities.  Once
> it has that list the MN could switch to another one, provided of
> course that the HAs have their BCs synched.
> 
> => I don't believe the BCs should be synched. In (any) DHAAD
> reselection or HA-switch, the MN knows it will use a different HA so
> it will start a new bootstrapping phase.

I agree.

> But if the HA change is transparent (i.e., if the MN doesn't know it
> is switching from a HA to another one, note this seems to imply the
> HA address stays the same so a VRRP-like mechanism) the BCs and IPsec
> state must be synched or synchable.

Right.

Alex