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

From: "Narayanan Vidya-CVN065" <[email-masked]>
Date: Mon, 24 Oct 2005 12:10:13 -0400

> 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.

OK. So, what is the destination address for DHAAD? 

> > 
> > 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.
> 
> 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)?
> 

Typically, I have seen DNS-based HA discovery to use say,
"mip6.domain1.com", where the MN belongs to domain1.com. If the MN is
trying to discover an HA in the local domain it is connected to, it
could simply use a service-based discovery using "mip6" as the service
name - in this case, a HA locally present in that domain would be
returned. If the MN is discovering a home agent in its domain, it would
use the former. It already knows its domain (for other purposes) and
"mip6" is a well-known prefix in this case. 

Vidya

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

---

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

> OK. So, what is the destination address for DHAAD?

The DHAAD Request would be sent to a 'reserved' address that is derived
from the home link prefix, called 'all HAs for DHAAD".  The HAs select
amongst themselves a 'leader' and only one of them replies back, using
src IPv6 address as its own globally unique IPv6 address (not the
'reserved' address).

Example of such reserved address could be
3ffe:dddd:eeee:aaaa:fefff:ffff:ffff:ffee (note the common part
                    fefff:ffff:ffff:ffee)

Every HA on the home link would have the address
3ffe:dddd:eeee:aaaa:fefff:ffff:ffff:ffee assigned to its interface and
do NA for it as if it were a normal IPv6 address, and it would also have
 assigned its globally unique IPv6 address (derived from
3ffe:dddd:eeee:aaaa:EUI-64).

The HAs select amongst themselves a leader with the tool that MIP6
provides which is the H bit in the RA a HA sends on the link.

> "mip6" is a well-known prefix in this case.

"For other purposes"?  How does it auto-configure that domain1.com
without having IP up?  IP must be up for that auto-configuration to
work, otherwise it will have to be handwritten on the mobile somehow.

Just some remarks...

Alex

---

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

=> this is not enough different from the current DHAAD, i.e., in
place of the routing choice for the anycast group member, you propose
to elect a HA master. All the IPsec issues remain.

   
   
=> for the election I propose to use the HA with the lowest IID...

If we'd like to make the non-anycast DHAAD compatible it is better
to use another well known address and to give it to the master.
But this is very similar to VRRP and there is already a VRRP/HA I-D
so I believe we should first look at this I-D which seems a good
complement to the HA-switch stuff (VRRP is transparent and should be
more efficient but can only switch the HA instance, not the whole HA,
IMHO both don't address the same problem).

Regards

[email-masked]

---

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

> to elect a HA master. All the IPsec issues remain.

I'm not sure I understand.  Isn't it possible for MN to have an SA with
'all HAs for DHAAD' address?

Remark that the HA that replies back to MN (1) is not necessarily the HA
that is going to 'serve' the MN and (2) will use its own global unicast
address as src of DHAAD Reply so IPsec would be fine.

Again, this working assumes that all HAs have the same coherent list of
HAs and priorities and that any HA may send back to MN the DHAAD Reply,
and the HA that sends the Reply is not necessarily the HA that is first
priority.  But the MN will use the HA Address that is the first priority
in the received list of HA addresses.

> => for the election I propose to use the HA with the lowest IID...

Well, it sounds as a good practical idea to me.  An HA may use all the
IIDs from all received H-bit RAs to build a common ordered list.  Or
otherwise the HAs may use manually pre-configured priority information
to be sent in the RAs.

> IMHO both don't address the same problem).

I have to check that.

Alex

---

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

=> two cases:
 - it is an anycast address so it can't be used as a source address, etc,
   and IPsec problems still apply.
 - it is not an anycast address, i.e., it is assigned to a box which can
   use it as a standard unicast address during a reasonable time.
   There is no more IPsec problems but a direct VRRP-like solution
   seems to be better as it solved all the problems.

=> no because to make IPsec happy the destination of the request and
the source of the reply must be the same. And I don't speak how
to setup the IPsec SA pairs...

=> we agree: current DHAAD design is not stupid, it has only two real
problems:
 - the DHAAD idea itself is in danger because HA assignment is better
 - the current mechanism has some operational issues, mainly its lack
   of reasonably easy security and the spurious but common ICMP filtering.
My draft is about the second but the first is more critical and drastic...

   > => for the election I propose to use the HA with the lowest IID...
   
   Well, it sounds as a good practical idea to me.

=> the idea is from OSPF and its Designated Router.

   An HA may use all the
   
=> as you've mentioned the priority is not used for replying to
requests.

   I have to check that.
   
=> VRRP is very fine for transparent failover (note that IMHO failover
is more important than load balancing and a good failover mechanism
should be as transparent as possible), and it is the only proposal
for this function (HA-switch can move the service, including to
another part of the infrastructure, for server maintenance for instance,
but can't help in case of server crash).

Regards

PS: in IPsec the only difficult thing to do with redunctant servers is
the anti-replay function but as we know it is not critical for MIPv6,
i.e., it always take times for the BU sequence number to wrap out
in standard conditions (increment by one and not a zillion of BUs
per seconds). So IMHO the VRRP-like idea should work for MIPv6
(BCEs) and IPsec (SAs).

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 18:24:05 +0200

>    seems to be better as it solved all the problems.

I see, so a reserved address that is not anycast could help DHAAD.

> to setup the IPsec SA pairs...

Oh?  That's tough indeed.  So the src address of DHAAD Reply should be
that reserved non-anycast address then.

>  - the DHAAD idea itself is in danger because HA assignment is better

By "HA assignment" you mean HA Switch message and draft?  If yes, that
draft alone does not help for bootstrapping IMHO.  If DHAAD can be made
to work with non-anycast addresses then DHAAD+MPD is a good idea to do
bootstrapping simple (MPD is Mobile Prefix Discovery).

> My draft is about the second but the first is more critical and drastic...

I don't see anything critical or drastic in HA assignment being proposed
as better than DHAAD.  It can complement DHAAD and work together with it
(HA Switch, DHAAD Req, DHAAD Reply).  I don't think HA Switch is about
to remove DHAAD altogether.

If DHAAD disappears altogether it's because it's bound to anycast
addresses and nobody cared to put on paper the non-anycast DHAAD that
works ok on at least two implementations.

> but can't help in case of server crash).

I think I agree, although my experience with VRRP is very limited.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 20:24:01 +0200

>  - the DHAAD idea itself is in danger because HA assignment is better
   
   By "HA assignment" you mean HA Switch message and draft?

=> no, I mean a HA assignment mechanism in general, including
(i.e., mainly :-) any still to be invented mechanism.
HA switch message is fine but is clearly *re*-assignment.

   If yes, that
   
=> I don't understand why MPD is for when you have HA discovery/assignment
(the mobile prefix is simply the prefix of the HA address)... I should
have missed something, for instance there is more than one MP?

   as better than DHAAD.

=> the question is drastic, i.e., if the answer is yes all discussions about
the best DHAAD mechanism are lost bits...

   It can complement DHAAD and work together with it
   (HA Switch, DHAAD Req, DHAAD Reply).  I don't think HA Switch is about
   to remove DHAAD altogether.

=> HA assignment should as it will give no choice, i.e., nothing to
discover.

=> I make a difference between the DHAAD function and the current
mechanism. Here the first question is about the function and the
second about the mechanism.

=> I have a (bad in fact :-) experience with HSRP which is the
Cisco proprietary protocol before VRRP.

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 20:51:16 +0200

Francis, please allow me slight remarks, don't take as corrections.

> have missed something, for instance there is more than one MP?

"MP" could be misinterpreted as "Mobile Prefix" which isn't.

MPD is more like: Mobile       Prefix Discovery, a prefix discovery
performed by a mobile.

There's only one MPD.

DHAAD doesn't provide a prefix length field in DHAAD Reply, so the MN
can't know it.  MPD is the equivalent of local RS/RA for a MN that is
away from home.

For bootstrapping, MN could do DHAAD to get the HA's full address and
then interrogate that HA with MPD Sol and get Response, and then call
the stateless address autoconfiguration functions easily.

HA-Switch and DHAAD+MPD could also be used when the home link is
re-numbered.

> the best DHAAD mechanism are lost bits...

I agree.

[... snip because I don't know]

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 21:38:54 +0200

> have missed something, for instance there is more than one MP?
   
=> I mean Mobile Prefix for MP.

=> it is.

=> but in fact the prefix length is 64 bits so this is not enough
to explain the necessity of MPD.

=> this is a very unlikely event.

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 22:47:08 +0200

>    "MP" could be misinterpreted as "Mobile Prefix" which isn't.

Well, the Prefix is the prefix of a fixed home link, advertised in fixed
RAs sent by its routers.  A "Mobile Prefix" would be more like the
prefix of the Mobile Network Prefix which moves together with the moving
network, I think.

But ok, it's also like a "Mobile Network" moves or is fixed depending
who one talks to.

> to explain the necessity of MPD.

Well, ok.  When plens are shorter than 64bits please pad with 0s between
prefix and IID, and don't use these zeros as network identifier.

> => this is a very unlikely event.

Well, ok, a discussion could be held about what are the minimal parts of
MIP6 which are really necessary and in what contexts.

Alex