Subject: RE: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU transmission text)

From: Soliman Hesham <[email-masked]>
Date: Mon, 23 Jun 2003 21:40:35 -0400

> > Doesn't this seem silly when we could simply say in
 > > the current spec something like: "if you don't need
 > > to check for address duplication then no need
 > > for the following messages ..." ?
 > >
 > 
 > No, I don't see how the NAR would be able to
 > 
 > - stop proxying, and start forwarding packets if it only received an
 >    NA with O=0. (Predictive scenario)
 > - create a ND cache entry when there isn't one when it receives
 >    an NA with O=0. (Reactive case)
 > 
 > I have read the optDAD draft. It is not clear to me how a 
 > node (router)
 > can distinguish between any NA and an NA that the MN sends 
 > after attaching
 > to a new link in order to be able to unambiguiously create a ND cache
 > entry.
 > If it can, it is already modifying ND.

=> Ok, let's discuss it when you had time to read
the optDAD or aDAD drafts.

 > >
 > > - It adds further complexity. More messages => more complexity.
 > >
 > 
 > How does NAR determine when to create an ND cache entry and
 > when not to do so when it receives an unsolicited NA ?
 > 
 > 
 > > - The amount of messages is not justified by the rarity
 > >   of this event.
 > 
 > How many messages are there ??

=> See below.

 > 
 > >
 > > - It makes sense to mention in the draft that some
 > >   messages (e.g. HI/HAck, F-NA) do not make sense
 > >   when a DAD optimisation is being used.
 > >
 > 
 > Even when DAD optimization is used,
 > 
 > - HI and Hack are needed so that the NAR can proxy
 >    the address (and not invoke NS) and buffer packets
 >    (instead of sending Destination Unreachble) for
 >    the predictive case

=> Proxy for what purpose?? You must be assuming that the 
handover will take an extremely long period of time so 
that the NAR would have to avoid NSs for the MN's 
new CoA. 

 > - something like FNA is needed to allow the NAR to
 >     create a ND cache entry unambiguously.

=> ND does not prohibit adding a new entry when O=0.
I think the NA message will only be dropped if there 
were no traffic for the MN or if another entry was already
there for another node. If the NAR had sent one NS and 
the MN didn't receive it (because it hadn't made
it to the new link yet), the unsolicited NA from the 
MN will fix that. If you agree with this, it seems
to me that there is no need for explicit FMIPv6 signalling.

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2003 19:10:29 -0700

> the optDAD or aDAD drafts.

I have read optDAD. I don't understand how NAR can
distinguish between an NA that should create an ND cache
entry and the one that should not.

>  > How many messages are there ??

Ok.

> that the NAR would have to avoid NSs for the MN's

What is extremely long/short ? Without pre-scanning,
WLAN link swithching is at least few hundred milliseconds.
Even with pre-scanning, it is about 100 milliseconds.
So, if the FBU has been sent to PAR, and voice packets with
20 ms inter-packet separation are arriving, then there are at least
5 packets at NAR. What should NAR do ?

It is hard to assume that handover delay will always be
smaller than the inter-packet separation..

> => ND does not prohibit adding a new entry when O=0.

Ofcourse when it is a solicited NA.

> there for another node. If the NAR had sent one NS and

Section 7.2.6.  Sending Unsolicited Neighbor Advertisements.

".. If the Override flag is set to
   one, neighboring nodes will install the new link-layer address in
   their caches.  Otherwise, they will ignore the new link-layer
   address, choosing instead to probe the cached address."

> MN will fix that. If you agree with this, it seems

7.2.5.  Receipt of Neighbor Advertisements

"When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target."

> to me that there is no need for explicit FMIPv6 signalling.

I am still trying to figure out how we can leave ND unmodified
using only NA.

-Rajeev

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 24 Jun 2003 13:37:03 +1000

>    address, choosing instead to probe the cached address."

Hmmm.  This doesn't entirely agree with Secion 7.2.5.  I won't
quote all of it here, but it does include the phrase:

	"Note that the Override flag is ignored if the entry is in
	the INCOMPLETE state."

If there is traffic queued for the MN, there will be an INCOMPLETE
entry.  And so the NA(S=0, O=0) will follow the rules of 7.2.5
and upgrade the entry to STALE.

> I am still trying to figure out how we can leave ND unmodified

I'm not 100% sure what you mean by that, but I hope the above
answers your question.  If not, please let me know.

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Jun 2003 12:56:55 +1000

Hi Rajeev,

> entry and the one that should not.

I think that it is relatively straight forward
to determine which NA messages are to be believed
based on the PCoA and the prefix of the link.

Either the PCoA can be sent in an NA
(which would obviously be just a copy of FNA function)
or the Router could watch for the IID from the PCoA
with the on-link prefix.  This would work well with O=0
even though there is no explicit solicitation.

This has significant benefits over the RS approach since
RS's have semantics which overwrite NC entries when SLLAO's
are included.  This could be a significant issue if an
MN arrived on a network where FMIPv6 is not supported.

I'm not sure that the 'M' message you mentioned has the
same semantics now though.

I'm not recommending using NA this at this stage, it is
just an illustration of how a system which already had
prior warning about handover (i.e. it has packets queued
for the MN) could use NA.

[email cut]
>    recipient has apparently not initiated any communication with the

Don't you love "SHOULD be silently discarded"?

To me it means nodes MAY not discard if they have good reason.

> I am still trying to figure out how we can leave ND unmodified

I think the advantage is that all the nodes who aren't interested
(aren't FMIPv6 ARs) will be ignoring this message.

You can even set extra options which FMIPv6 routers are
interested in, or use the PCoA in the NA.  I don't think
it will hurt.

This is just a guess though.

Greg

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Jun 2003 12:02:18 -0700

Hi Greg,

> based on the PCoA and the prefix of the link.

Sure. But that would mean a change to NA right ?
FNA carries the PCoA BTW..

> even though there is no explicit solicitation.

Could you clarify from which message the router would
watch for IID ?

> MN arrived on a network where FMIPv6 is not supported.

Yes. Lets' leave RS out!

> same semantics now though.

M is a re-hash of FNA. The semantics are the same. The
format may need to be revised. What I would like to be able to do is
allow FBU encapsulation within M. As I have mentioned, this
has the benefit of dropping FBU if the router detects a conflict
while creating the ND entry. How can we do this ?
Currently, FNA is an option. I am proposing that it be carried
as a Destination Option. That way, there _can_ be a Next Header
pointing to the FBU packet.

Does this make sense ?

> for the MN) could use NA.

OK.

> (aren't FMIPv6 ARs) will be ignoring this message.

They will (should) ignore M (FNA) too.

> This is just a guess though.

hmm.. May be we should avoid more options. Good guess
anyway..

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Jun 2003 12:12:50 -0700

Hi Nick,

> and upgrade the entry to STALE.

IF there is an entry, unsolicited NA can at least update the LLA.

When there is no entry, such as when there was no prediction,
unsolicited NA does not create a new entry. Right ?
This is what the proposed text is trying to address. When the
MN is sending FBU, also create an ND cache entry (via a re-hash
of FNA) so that when packets start arriving from PAR, the NS-NA
round-trip on the new link is avoided.

> answers your question.  If not, please let me know.

Well, the question is (repeating, sorry): when there is no cache entry,
how can NAR create one using the existing unsolicited NA. From Greg's
response, you probably need more information, which is what I have
been trying to convey (that a modified NA, aka FNA is needed).

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Jun 2003 12:57:21 -0700

> pointing to the FBU packet.

Sounds sensible to me given the existing FMIP design.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Jun 2003 18:27:38 -0700

Nick 'Sharkey' Moore wrote:

> On 2003-06-24, Rajeev Koodli wrote:
> >
> > how can NAR create one using the existing unsolicited NA.
>
> If the router speaks unmodified RFC2461/2, you can't.
>
> > From Greg's
> If you wanted your router to do something with the unsolicited NAs
> sent by Optimistic DAD for addresses not in INCOMPLETE, you'd have
> to modify the router to cache these entries, perhaps with an extra
>

But, this seems to contradict your statement above that with unmodified
ND, you cannot create cache entries with unsolicited NA.
The problem is router has no means to distinguish NA sent by an oDAD
node from a vanilla NA when there is no entry whatsoever in its ND cache.

-Rajeev

> state CACHED or something.  This would, I reckon, be a smaller change
> than modifying the router to understand a whole new message.
>
> (If you can't make any modifications to the router, Optimistic DAD
> will still work, at the expense of an extra NS/NA exchange.)
>
> -----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 25 Jun 2003 11:57:24 +1000

> node from a vanilla NA when there is no entry whatsoever in its ND cache.

Does it need to?  RFC2461 7.2.5 says "If no entry exists, the
advertisement SHOULD be silently discarded".  There's no particular
reason why a router shouldn't 'cache' _any_ unsolicited NAs, if 
it wants to.

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 25 Jun 2003 10:37:01 +1000

-----Nick

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2003 07:59:59 -0700

> will still work, at the expense of an extra NS/NA exchange.)

Is the amount of change really an issue? Remember, we're talking about an
experimental protocol.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Jun 2003 08:39:43 -0700

> reason why a router shouldn't 'cache' _any_ unsolicited NAs, if

Well, I would like to specify more clearly for FMIPv6 the
semantics, rather than having to silently ignore "SHOULD be
silently discarded" :-)

-Rajeev