Subject: Re: [mobile-ip] Resolution for issue #198

From: Marc Hasson <[email-masked]>
Date: Mon, 20 Jan 2003 12:57:11 -0800 (PST)

I like #5 better than anything else I've heard to resolve this issue
so far and it seems pretty easy to implement.

   -- Marc --

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 21 Jan 2003 13:30:38 -0600

Hi Pascal,

 Note that the MN DAD'ing its own home address as opposed to the HA's 
 also gets him the LLA of the HA, with no change in ND, and with the 
 additional value of checking the home address for a real duplication.

MK>> This solution should work fine.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2003 09:51:43 -0000

I like it too :)

But the angle I hadve here is about the states the MN keeps whether it's
at home or not. The way I see it, the "rightful" DAD should always
succeed. This includes the case where the MN chooses a different HA
after reboot, while NOT at home. That new HA will DAD and in my view,
the DAD should succeed. That means that the old HA should silently yield
on DAD.

The good thing is that this approach also helps on homecoming, hence the
discussion. It actually makes it quite straighforward if we manage to
work out the details of the semantics of "less then assigned" (on the HA
after BU), and "more than tentative" on the MN...

Pascal

> -----Original Message-----
> From: gabriel montenegro [mailto:[email-masked]] 
> Sent: mercredi 22 janvier 2003 10:37
> To: Greg O'Shea
> Cc: Mobile IP Working Group
> Subject: Re: [mobile-ip] Resolution for issue #198
> 
> 
> I personally like your idea, but the WG seems to have
> decided not to pursue it this time around. so knowing
> what we know today (who knows if this'll change during
> last-call) we have to make sure real, non-virtual home
> links are supported...
> 
> -gabriel
> 
> Greg O'Shea wrote:
> > This issue has generated a lot of traffic and (re)fine(d) 
> ideas, which 
> > is good, but I must point out that the suggestion at the 
> root of this 
> > discussion (December 23) was to completely eliminate many of these 
> > contrivances rather than to stimulate their development.
> > 
> > At this point I am not convinced that support for real home nets is 
> > necessary or worthwhile, and hence I do not believe it should be 
> > mandated. I am planning to make support for real home networks a 
> > configurable feature of my experimental implementations.
> > 
> > Aside: I was persuaded to reiterate my original point by friends at 
> > the University of Lancaster. They are deploying MIPv6 and 
> have decided 
> > to make all of their home nets virtual.
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2003 11:02:46 -0000

So the MN is going to BED as soon as it comes back home?

I must say I like it :)

Mostly if the rules are that a HA releases the address and the BCE upon
that flow, which is the desired effect anyway. As Francis mentioned, we
have to worry about IPv6 WG reaction, and maybe your approach will get a
better reception from their side since it's somewhat cleaner.

Let me summarise:

My initial approach (new states): no change in signalling, but potential
ambiguity. Change in ND states semantics.
Gabriel's proposal: new clean signalling, same old ND states, yet new
reaction on the signalling (HA yields).

Is that correct?

Pascal

> Sent: mercredi 22 janvier 2003 11:00
> To: Pascal Thubert (pthubert)
> Cc: Ville Nuorvala; Mobile IP Working Group
> Pascal Thubert (pthubert) wrote:
> > There's still the question of the lost state. If the MN lost the HA 
> > address (only has home prefix coded in), then upon the DAD 
> failure, it 
> > has to figure out whether this is a HA that it binded with in some 
> > past, or a real duplication.
> 
> I think this is the crux of the problem: we're overloading 
> DAD with new semantics. Totally ignoring politics and turf 
> jurisdictions for a moment (yes, Francis may have a point 
> here), the sensible thing is to always be very explicit about 
> what you're doing.
> 
> So in the interest of avoiding ambiguity, perhaps we should 
> just own up to the fact that what the MN does when coming 
> back home is not DAD, but BED (binding entry detection). And 
> make sure a BED can't be confused for a DAD or anything else.
> 
> BED is not DAD. It's not better or worse. It doesn't replace 
> it, both have a time and a place. So for example, ICMP code=1 
> could be used to effect this clear distinction on a packet 
> otherwise equivalent to the MN's DAD on its home address, 
> with a similar code in the HA's response. It would also aid 
> monitoring the link for sanity, etc.
> 
> Would this perhaps avoid the need for adding more states to 
> address configuration as you suggest?
> 
> -gabriel
> 
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2003 13:40:54 -0000

Hi Ville:

This all makes a lot of sense :)

We see that issues 172 and 198 may be fixed together, either at BED time
or later with a bind update. In both cases, we have a broad solution.
The only issue against the former was linked of potential DOS (from
Francis, we're discussing it offline at the moment). The latter has a
degree of complexity.

We have to figure out which approach is more reasonable is dig in for
the details. Personally, I still prefer the HA to yield at BED time.
Comments?

Pascal
> From: Ville Nuorvala [mailto:[email-masked]] 
> Sent: mercredi 22 janvier 2003 13:14
> Cc: [email-masked]; Mobile IP Working Group
> Subject: RE: [mobile-ip] Resolution for issue #198
> 
> 
> On Wed, 22 Jan 2003, Pascal Thubert (pthubert) wrote:
> 
> For a proxied address the Override flag SHOULD be set to zero 
> in the NA. If we can rely on all implementations doing this, 
> we could probably use this as a clue to the nature of the DAD failure.
> 
> > But then what are the source/dest IPv6 addresses in the 
> bind updates?
> 
> How about if we have the HA reply to the DAD with the same 
> home agent address originally used by the MN for its home 
> registration? If this address is inserted into the source 
> address field of the proxy NA, the MN could extract both the 
> LLA and the IPv6 address of the HA from it. This way the MN 
> would always have all the addresses it needs to deregister 
> with the old HA.
> 
> Actually, if we extrapolate a bit, we might have a HA-to-HA 
> sync protocol Jari mentioned in issue 172!
> 
> If the MN's HoA is already protected by another HA, the new 
> HA could actually record the source address from the proxy NA 
> it receives.
> 
> It could then check the address against its Home Agents list 
> to make sure the sender is a HA. If the sender is a HA its 
> address could be sent as a suboption in its DAD failed ACK 
> message to the MN.
> 
> With the help of this, the MN could then try to deregister 
> with its old HA before re-registering either with it or the new HA.
> 
> I'm not a security expert so I don't know if there are any 
> IPSec/IKE related problems with this, but perhaps someone 
> with better knowledge in this area could comment?
> 
> Just a thought...
> 
> 
> Ville
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jan 2003 08:33:09 -0000

Pascal Thubert (pthubert)" wrote:
> > address (only has home prefix coded in),
> 
> it has the prefix stored, but lost the HA information?
> come on...

This occurs plainly with DHAAD support. 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: mercredi 22 janvier 2003 20:08
> Cc: [email-masked]; Ville Nuorvala; Mobile IP Working Group
> "Pascal Thubert (pthubert)" wrote:
> > 
> > address (only has home prefix coded in),
> 
> it has the prefix stored, but lost the HA information? 
> come on.....
> 
> > then upon the DAD failure, it
> > past, or a real duplication. Hopefully it's a HA so the optimistic 
> > behavior is to send a bind update to deregister, and retry DAD 
> > afterwards. But then what are the source/dest IPv6 addresses in the 
> > bind updates?
> > 
> > Suggestion 1) source is unspecified, target is home 
> anycast, MAC layer 
> > dest is LLA from DAD, no ACK. Suggestion 2) source is unspecified, 
> > target is MN home address, MAC layer dest is LLA from DAD, no ACK.
> > Suggestion 3) source is MN home address, target is MN home 
> address, MAC
> > layer dest is LLA from DAD, ACK. The HA detects the 
> duplication. Since
> > the duplication is associated with the deregistration, it 
> removes the
> > address from its interface and gets rid of the binding cache. HA
> > installs the neighbor with the source LLA and the MN home 
> address in the
> > ND cache as STALE and responds to the BU.
> 
> BUs from MN to HA have to have HoA and HA's address. IPsec 
> SPD uses these addresses and the HA drops unauthenticated BUs.
> 
> Vijay
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Jan 2003 07:22:37 -0000

> There seems to be a problem in above.  Sending RS requires 
> the use of the link-local address, which could create DAD 
> clash.  So it seems one must wait for a unsolicited RA, right?
> 
> Doesn't seem like the best way forward to me..
> 

The MN can not do much till it built a CareOf anyway. So an RA is needed
before anything happens, right?

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: samedi 25 janvier 2003 07:58
> To: Erik Nordmark
> Cc: [email-masked]; Pascal Thubert (pthubert); Ville Nuorvala; 
> Mobile IP Working Group
> On Sat, 25 Jan 2003, Erik Nordmark wrote:
> > > We know what the draft already says. Are you proposing to 
> open a new 
> > > last call issue on whether movement detection to detect if the MN 
> > > has reached home should be deserialized and run in 
> parallel with the 
> > > DAD/BED? This would optimize moving back home. But since this is 
> > > probably not the most common movement, why bother?
> > 
> > My point is that since you don't know that you've moved home until 
> > you've run movement detection and received at least one RA, 
> then for 
> > *all movements* you need to defer the DAD until after receiving at 
> > least one RA. Thus the serialization will happen for all movements
> > in order to handle the rare event of moving home.
> > 
> > 	Send RS
> > 	Wait for RA
> > 	Are we on home link?
> > 		Send funky DAD or BED
> > 	else
> > 		Send regular DAD
> > 
> > Or am I missing something?
> 
> There seems to be a problem in above.  Sending RS requires 
> the use of the link-local address, which could create DAD 
> clash.  So it seems one must wait for a unsolicited RA, right?
> 
> Doesn't seem like the best way forward to me..
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>