Subject: Re: [mobile-ip] Issue #23 and Issue #30

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Jun 2002 16:55:41 +0200

I might be missing something, but I'm not 
   sure that your steps below will work.
   
=> they did work.
   
   => If the HA does not defend the MN's link-local address
   while it's away, how can you send a dereg if 
   someone else took the MN's link-local address?
   
=> if someone else took your link-local address you are in the same
situation as when you boot and attach to a link where someone else
have taken your link-local address...

[email-masked]

PS: I tried to move this discussion on the IPv6 mailing-list
(topic DAD or DIIDD).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Jun 2002 17:11:01 +0200

I should clarify: My expectation is that the home agent should
   ONLY defend the mobile node's link-local address, not its other
   addresses.  Then, by implication, the other addresses will be
   unavailable to nodes on the link because they can't form the
   link-local address to start with.
   
=> if you follow the discussion (?) on the IPv6 mailing-list,
this is a clear claim of the DIIDD option.

Regards

PS: I am not in favour of nuking DIIDD: I'd like to first choose between
DAD and DIIDD then to nuke the loser.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Jun 2002 17:13:54 +0200

Hi Charlie, I can not think of any at this point. Eliminating the
   requirement (of link-local address defence by HA) would simplify HA
   design.
   
=> I don't think so: I believe for HA design DAD and DIIDD are roughly
equivalent. The only little problem is that they are not compatible...

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Jun 2002 17:29:45 +0200

> RFC3041 says that a node can generate a new iid
   > and does DAD for _that_ address which uses the
   > new iid. Since this is typically not a link local
   > address, you could get a conflict if the HA
   > does not defend all addresses.
   
   The problem is that RFC 3041 should require any
   such node to first acquire rights to the link-local
   address.  I hope that is viewed as an omission, and
   one which can be quickly repaired.
   
=> this point is clearly at the advantage of the DIIDD option
but don't forget a direct consequence of to choose DIIDD is the MN
returning back to home should use an alternative IID (a RFC 3041 one
for instance) because its `own' IDD is defended by the HA until
the deregistration succeeds: this is clean, easy to implement/understand
but costs a DAD (oups, a DIIDD :-) for the temporary IID check in all cases...

Regards