Subject: RE: [mobile-ip] FMIPv6 Address confusion

From: Soliman Hesham <[email-masked]>
Date: Wed, 25 Jun 2003 20:30:08 -0400

I think that you might not have read section 7.2.5 of 
RFC 2461 carefully enough.

 > my general comments are that
 > 
 > - I do not see HI/Hack as optional for the
 > scenario when MN is able to  send FBU from old
 > link ("predictive"). The NAR needs to not do ND,
 > and send Dest Unreachable, until MN shows up on
 > new link.

=. That can't happen unless the handover will take
a couple of seconds. The NAR will retransmit several
times as per 2461. Most likely the NAR will send one
NS before the MN arrives and the unsolicited NA will
add an entry. Basically, the above is not correct.

 > 
 > - I do not see how a router can create an ND cache entry,
 > when there isn't one, using a 2461 unsolicited NA. 

=> If an entry is in INCOMPLETE, because there is 
incoming traffic then it will create an entry based
on unsolicited NAs. If there is no INCOMPLETE entry
then there is no traffic, so who cares.

   I might even say
 > you agree that at least a flag is needed to distinguish. This is
 > FNA.

=> No, I was talking about the reactive case and after
reconsidering I found I was wrong.

 > > Therefore, when it arrives at the new link, assuming
 > > that it has active sessions, traffic will be waiting
 > > at the NAR. Typically, the L2 handover (break before
 > >
 > 
 > If you are using standard ND, why would traffic wait at
 > NAR ? If no one answers NS, NAR sends Dest Unreachable
 > isn't it ?

=> After several attempts. The default is something like
3 secs if memory serves me right. Check the defaults
in 2461.

 > > make) will take longer than the path between PAR and
 > > NAR. Therefore, the NAR would have already sent an
 > > NS (address resolution) for the MN's NCOA before it arrived and
 > > will create a cache entry in INCOMPLETE state. If the MN sends
 > >
 > 
 > Since the L2 handover delay takes longer wrt to path delay
 > between PAR and NAR, the MN would not be there to answer
 > NAR's NS. So, why would it create the ND entry ?

=> I'm failing to explain this. Here is another attempt:
We agree that PAR-NAR path is "shorter" than L2 HO time.
So, we agree that the NAR will send an NS before the MN
attaches (typically). 
The NAR will wait for a reply (see above) and queue packets
in the meantime after setting a NC entry to INCOMPLETE. 
If the MN shows up within 3 sec it will send an unsolicited
NA to the AR, which _will_ update the NC entry and communication
continues. See section 7.2.5 in RFC 2461 

 > > an unsolicited NA as soon as the link is up, it will
 > > create a Neighbour cache entry (for the NCOA) and traffic
 > > will be forwarded.
 > > In this scenario, I can't see any advantages for
 > > having HI/ack FNA/ack
 > 
 > First, there is no dependency on L2 handover timing versus
 > path delay between PAR and NAR. 

=> Yes of course, I agree. Please see above.

 > 
 > Second, you don't require ND queue to be larger. Only the
 > FMIP buffer needs to be bigger.

=> In this scenario there is no FMIP buffer, only
the normal ND queue.

 > 
 > Third, NAR proxies NCoA in case some node tries
 > to capture it.

=> OptDAD.

---deleted part of email, already explained above-------

 > Finally, there is no Ack for FNA proposed. Only NAck, when
 > there _is_ conflict is proposed.

=> Ok, NACK then.

 > 
 > >
 > >
 > > How long is the queue? How large is the buffer in the
 > > current draft? Implemnentation issues. RFC 2461 makes
 > > no requirements here.
 > 
 > Queue size is one issue. Why should NAR buffer instead
 > of replying with Dest Unreachable, 

    a standard 2461 behavior, is the primary issue.

=> Standard RFC 2461 does _not_ do what you're saying.
Where did you read this in RFC 2461?

 > > In this scenario, there is no change in the NAR. Standard
 > > 2461.
 > >
 > 
 > Proxying an address, standard HA feature, plus buffering is
 > what is needed otherwise.

=> Plus opening ingress filter plus implementing HI/ACK, 
F-NA/NACK, plus potentially adding NC entries based on
the above messages, depending on how you implement it.

 > 
 > 
 > >
 > > 2. The reactive case can be broken down into two
 > >    subcases:
 > >       a. MN received Pradv before moving
 > >       b. MN didn't receive Pradv before moving
 > >
 > > a. In this case, the MN could send the BU right after
 > > it connects to the new link. Of course this is done
 > > after configuring an address with OptDAD. The normal traffic flow
 > > will force the NAR to do address resolution as usual.
 > > Again, standard 2461 stuff.
 > >
 > 
 > So, here NAR would do NS and NA when packets arrive. Since
 > FMIPv6 is an optimization, we can save this round-trip, and I
 > don't believe that the cost (i.e., FNA) is unreasonable.

=> As I explained to Basavaraj, you might not even get
NS/NA on some links. E.g. see RFC 3314, RFC 3316.

 > 
 > > But please don't tell me "The DNA BoF handles OptDAD"
 > > or "OptDAD is not an RFC". I'm only interested in having
 > > a technical discussion.
 > >

---Cut---

 > 
 > I have heard that this discussion has been "too technical" :-)

=> That's a good sign :)

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 Jun 2003 08:16:14 -0700

Hesham,

> add an entry. Basically, the above is not correct.

Can you explain to me why it is preferable to have the router retransmitting
NSs on the wireless link when the MN is not there rather than signaling up
front that the MN is coming with HI/HAck and not sending anything on the
wireless link until the MN arrives?

            jak

---

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

> add an entry. Basically, the above is not correct.

umm.. Two things above. NAR to not do ND, and sending
Dest Unreachable. The former happens when packets arrive
(which we agree) and the latter happens depending on relative
timing (which we may have slightly different perspectives).
But, what is not correct here ?

> on unsolicited NAs. If there is no INCOMPLETE entry

From 7.2.5 again, for unsolicited NA, an existing
entry in INCOMPLETE state is set to STALE. This implies
the router would invoke NUD for reachability confirmation.

The concluding paragraph in 7.2.5 states..

"The above rules ensure that the cache is updated either when the
   Neighbor Advertisement takes precedence (i.e., the Override flag is
   set) or when the Neighbor Advertisement refers to the same link-layer
   address that is currently recorded in the cache.  If none of the
   above apply, the advertisement prompts future Neighbor Unreachability
   Detection (if it is not already in progress) by changing the state in
   the cache entry."

Clearly, O=0 in the NA in question. And, since the router has no
LLA for the MN, the cache update (to REACHABLE) does not
happen. So, this sets the state to STALE which would
force the router to send NS again, anticipating MN to respond with
NA, S=1. This is an additional round-trip.

In general, I have not seen 2461 recommending creating ND cache
entries in REACHABLE state for unsolicited NAs. I reckon this is
because reachability confirmation burden is always on the sender of
the packet. More knowledgeable folks please correct.

> then there is no traffic, so who cares.

Well, after the MN attaches, creating an entry at NAR saves
a round-trip when packets arrive.

> 3 secs if memory serves me right. Check the defaults

But, the packets still keep arriving. Standard 2461 recommends
keeping the ND buffer small.

"The queue MUST hold at least one
   packet, and MAY contain more.  However, the number of queued packets
   per neighbor SHOULD be limited to some small value."

It even recommends how packets should be dropped.

"When a queue
   overflows, the new arrival SHOULD replace the oldest entry."

This is not just an implementation issue. Many "standard" existing
implementations keep the buffer to 1-2 packets.

> continues. See section 7.2.5 in RFC 2461

See above regarding setting the entry to STALE and a subsequent
round-trip that ensues.

The timing issue is something we need to discuss further.

> => In this scenario there is no FMIP buffer, only

It's my turn to failure (to explain). Let's say that packets
come to some address A for which NAR does NS. This is
_standard_ ND and hence has a small queue. When packets come
to NCoA, and since MN is not on-link, why should the ND
queue be larger during the NS probe for NCoA. How can you
implement this without making the queue larger in the first
place ?

Through HI, NAR knows that it has to buffer packets and
not invoke NS in the first place.

>  > Third, NAR proxies NCoA in case some node tries

How does optDAD help if a normal node tries to grab the
exact address the off-link MN is trying to prospectively
use ?

> Where did you read this in RFC 2461?

Do you mean it buffers the incoming traffic beyond the
recommended small size ? Or do you mean it will not send
Dest Unreachable if it cannot find the destination ?
I guess I was not clear enough in saying that buffering 1-2
packets until address resolution completes, at the end of
which it returns Dest Unreachable if that's the case, is a standard
behavior.

> the above messages, depending on how you implement it.

Ingress filtering ? HI and HAck are needed.
FNA and NA are identical, except for being able to distinguish
when to create ND cache entry when none exists.
I don't understand the comment above adding NC entry.
NACk for FNA is only sent when there is a conflict. We can
even make it optional (to allow the MN to quickly re-configure).

> NS/NA on some links. E.g. see RFC 3314, RFC 3316.

I think we need to stick some consistent mental reference
during discussion. If we cannot even consider NS/NA, what
is the relationship to "standard ND", optDAD, "creating
ND cache entry for unsolicited NA" etc ? :-)

-Rajeev