Subject: [Mipshop] FNA in the current spec

From: Rajeev Koodli <[email-masked]>
Date: Wed, 17 Aug 2005 10:56:57 -0700

Catching up with the good discussion..

BTW, there is an issue tracker for MIPSHOP and
I have created an account for myself for rfc4068bis.
I ask folks to construct the issues and mail them to
me. I will then put them on the tracker at
www.mip4.org/issues/tracker/mipshop

Here is the thinking behind having FNA.

1. Assume that the PAR has processed FBU before the
    MN regains link connectivity with NAR. So, the
    arriving packets at NAR invike Neighbor Discovery,
    setting the state to INCOMPLETE. IF the timing turns
    out to be such that the MN can answer the _first_ Neighbor
    Solicitation, then things are good. In the most likely case,
    such a coincidence cannot be guaranteed :-)
    For the general case, assume that the MN sends Neighbor Advertisement
    unsolicited. Since there is an ND state (INCOMPLETE), it is
    changed to STALE upon receiving the unsolicited NA. The STALE
    entry prompts reachability confirmation before the peer (MN)
    is deemed REACHABLE. (NOTE: it is not clear to me whether an
    unsolicited NA immediately prompts a new NS or the state machine
    waits until the next NS is triggered since address resolution is
    in progress). This means either active probing (sending
    NS, expecting solicited NA) or "forward progress" determination.
    (Section 7.3.1 in RFC 2461). Since no packets have been sent to
    the MN, it is not clear how forward progress, with its limited
    applicability to TCP, is applicable. So, the scenario results in
    a round trip of messages.

    If the MN does not send an unsolicited NA at all, then syncing up
    with NAR is dependent on NS re-transmit timer, which is very long.

2. Assume that the PAR has not processed FBU before the MN regains
    connectivity on NAR. In this case, NAR has no ND state for the MN,
    and hence it will discard the unsolicited NA. When the PAR processes
    FBU and starts tunneling packets to NCoA, NAR will do one round-trip
    of NS - NA processing.

    So, if we are requiring the MN to send an unsolicited NA anyway, why
    not make it such that there is no additional round-trip of (possibly
    delayed) signaling is necessary, and the ND state is set to REACHABLE
    immediately? This was the thinking.

-Rajeev

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 18 Aug 2005 15:41:00 -0400

Hi Emil,

 > Well actually we had the follwoing problem. Once the mn has 
 > sent the FBU 
 > and detaches from PAR's link, the PAR starts forwarding 
 > packets through 
 > its PCoA<->NCoA tunnel. Chances are however that packets 
 > arrive at the 
 > NAR before the MN has completed L2 handover so they trigger 
 > NDisc. NAR 
 > therefore sends an NS (which never gets received by anyone 
 > since mn is 
 > still out) and puts the MN's lla into UNREACHABLE. After the 
 > MN actually 
 > gets on the new link and sends the FNA we try to modify the 
 > entry but 
 > the IPv6 stack (on usagi's linux 2.6.8.1) seems to ignore it 
 > (that has 
 > to do with the fact that fmipv6.org runs in user space) and keeps it 
 > UNREACHABLE until the second NS leaves a second later and the NA is 
 > received. We therefore (wrongly or bugly but bravely) set 
 > MN's LLA to 
 > REACHABLE right after reception of the HI, and this works 
 > quite well for 
 > VoIP and kin. We haven't tried what happens if we do the 
 > same for STALE 
 > - it might very well work. I'll come back to you on that.
 > 

=> This is very interesting, thanks for the feedback. In addition
to trying the STALE case, I'd be interested to know what would
happen if the MN just sends an NA. It seems like this would
work more seamlessly with the ND implementation you have. 

Hesham

 > Cheers
 > Emil

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 22 Aug 2005 12:55:17 -0400

> 
 > => That's a separate issue, i.e. probability of collision
 > in oDAD. Based on the draft-soto analysis we should be more
 > worried about the MN being struck by lightning than we address
 > collision, given a reasonable RNG.
 > 
 > jak>> Well, my friend, if it was me that was on the business 
 > end of that 
 > lightening bolt, I would certainly care. :-)

=> The point is, the probability is so low compared to 
anything else in the system. So, as engineers, we need not worry 
about that. Do you know any wireless link that has BER as low as
10 ^-12 or lower? I don't think so. 

Hesham

 > 
 > jak>> Anyway, this is where some kind of lightweight HI/HAck 
 > could come in. 
 > Maybe we need to revisit how it would work, but it seems 
 > that it is probably 
 > the only way to definitively rule out duplicates.
 > 
 >             jak 
 > 
 > 
 >

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 22 Aug 2005 21:59:10 -0400

>  > The current spec was supposed to handle duplicates.
 > 
 > => The current spec has nothing to do with address duplication.
 > No more than its reliance on DAD, which is defined elsewhere.
 > If address duplication takes place then DAD will take care of it
 > as well as it can (not perfectly).
 > 
 > jak>>>>
 > 
 > Section 5.4 paragraph 3 of RFC 4068:
 > 
 >    In some cases, the NAR may already have the knowledge required to
 >    assess whether the MN's address is a duplicate before the 
 > MN moves to
 >    the new subnet.  For example, the NAR can have a list of 
 > all nodes on
 >    its subnet, perhaps for access control, and by searching 
 > this list,
 >    it can confirm whether the MN's address is a duplicate.  
 > The result
 >    of this search is sent back to the PAR in the HAck 
 > message.  If such
 >    knowledge is not available at the NAR, it may indicate this by not
 >    confirming the NCoA in the HAck message.  The NAR may 
 > also indicate
 >    this in the NAACK option in response to the FNA message.  In such
 >    cases, the MN would have to follow the address configuration
 >    procedure according to [6] after attaching to the NAR.
 > 
 > So, yes, the DA information is not assured, but it can be 
 > used if available.

=> Of course, but it's a far cry from:
 >  > The current spec was supposed to handle duplicates.

The text above is pure handwaving for implementers, it doesn't 
provide a mechanism for handling duplicates.

Hesham