Subject: Re: [mobile-ip] FMIPv6: FBU transmission text

From: Gregory Daley <[email-masked]>
Date: Thu, 19 Jun 2003 15:24:38 +1000

Hi Rajeev,

Just a quick comment.

----- Original Message -----
[scenarios cut]
> In the above scenarios, it is clear that a message from the MN
> to NAR is necessary, and such a message should be sent as soon as MN
> connects to NAR. In scenario 1), this message (call it 'M') announces
> MN's presence on the new link to NAR so that packet forwarding to the
> MN can begin. In scenario 2), 'M' requests NAR to begin forwarding
> incoming packets providing NCoA is confirmed. In both the scenarios,
> it is crucial for NAR to have a forwarding entry for NCoA, and
> especially avoid a round-trip corresponding to neighbor discovery. The
> format of 'M' includes NCoA and MN's Link-Layer Address (LLA) in both
> the cases.
> 
> When NAR receives message 'M',
> 
> a) it verifies if an entry exists for NCoA in its proxy neighbor
> cache. If there is, it moves the entry to neighbor cache makes it
> REACHABLE and forwards any buffered packets. Otherwise,
> 
> b) it verifies if an entry exists in neighbor cache for NCoA.
> If there is, NCoA is already in
> use by another host; so NAR sends a Router Advertisement with an
> option indicating that the MN should fall back to reconfiguring its
> address according to RFC 2462. If NAR does not find an entry for NCoA
> in its neighbor cache, it creates an entry for the <NCoA, LLA>
> tuple and makes it REACHABLE.
> [note]
> 
> In b), if there is no entry for NCoA in NAR's forwarding tables, but
> there is already a host on the link with NCoA, NAR will incorrectly
> create an entry. However, such an entry would be over-written when an
> advertisement for the DAD probe is received. When this happens, NAR
> could forward packets to an unintended host. This is the penalty for
> using NCoA while DAD is in progress and is not unique to the mechanism
> described here. Indeed, a simple scan for an existing entry 
> improves the chances of expeditiously detecting duplicates. 
> In any case, it is  useful to bear in mind that the likelihood 
> of a collision actually taking place is insignificant in the
> first place.

I think that the procedure described largely has merit,
but there need not be any distinction in what is sent back to
the MN regarding address config (unless the AR confirms in
FBack that address is pre-DADed, and this would be in the first
message delivered to the MN anyway).

If the Address is not guaranteed to be unique, DAD will have to 
be performed anyway (regardless of the likelihood of collision).
The nAR's job is to not overwrite NC entries.  If DAD is
performed, the MN will learn of the issue from the address owner.  

Optimistic DAD would work fine with this. 

I can't really see why FNA it can't be an unsolicited NA message 
with O=0, NCoA an SLLAO and an option for carrying FBU.  This would
make the entry in the NC only if no entry already existed.

Greg

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Jun 2003 09:49:26 -0700

Hi Greg,

> message delivered to the MN anyway).

If there is a conflict, delivering FBack to NCoA on the
new link is tricky isn't it ? If NAR uses its existing ND cache
entry, it will reach the unintended host. This will happen
if NAR blindly drains its buffer. On the other hand, looking
for FBack in its buffers is costly. In any case, there may not be
any FBack (either lost, or MN never sent FBU from old link).

The message from NAR to MN is sent when there
is conflict.

- scenario 1: if FBAck indicated conflict, the MN performs
   normal address configuration
- scenario 2: MN does not know if NCoA is unique. If there is
    a proxy ND cache entry, NCoA is fine. If there is ND cache
    entry, NCoA is in use already. here, the MN could wait
    for DAD response to learn of the conflict. I am proposing
    we keep an existing message (an RA from NAR with the
    NAACK option) to expedite notification to the MN.

> performed, the MN will learn of the issue from the address owner.

Right. But, a message from NAR should expedite the
address configuration a lot (instead of waiting for NA for
DAD probe).

> Optimistic DAD would work fine with this.

Ok.

> make the entry in the NC only if no entry already existed.

An issue is sending FBU :-) Encapsulating it within message 'M' allows
NAR to drop it if there is an existing entry for NCoA. If you send FNA
first and then send FBU, NAR "somehow" has to screen for FBU to
drop when there is conflict. Unfortunately, you cannot encapsulate
FBU within FNA..

Thanks,

-Rajeev