Subject: [Mipshop] FMIPv6 - Reactive mode operation

From: Subba Reddy <[email-masked]>
Date: Sat, 03 Sep 2005 11:32:43 +0530

Hi,

    I have a question regarding the NAR operation (reactive mode) in the following case. 

MN has sent FBU with NCoA in PAR's link. 
PAR has sent HI to NAR. Assume that NCoA is already in use and 
NAR replied with HAck including alternate CoA. 
MN is moved to NAR's link before receiving FBack. MN will send FNA[FBU] to NAR.

Now, Will the NAR 
1.just matches link layer address of MN and forward the buffered packets (But I think, NAR also verifies NCoA). 
Since FBack is also buffered, MN will receive FBack with the buffered packets and configures alternate CoA.
2.NAR sends RA with NAACK (with alternate CoA) and then forwards the buffered packets

Am I missing something?

Please Clarify me.

Thanks & Regards,
Subba Reddy
_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 03 Sep 2005 10:17:46 +0100

> (But I think, NAR also verifies NCoA).

Well the NAR must somehow ENABLE this nCoA in its NCE (which is done 
through the FNA). However if the FNA maps to a rejected nCoA the NAR's 
NC should not really have any state for the address. Hence the NAR would 
complain with a message of either "comply" (i.e. take the nCoA i give 
you) with the NAACK or "access denied" (i.e. sorry no access). I assume 
you mean this when you refer to a 'match' of the LLA. But as you may see 
(2) is also part of the event..

> packets and configures alternate CoA.

CORRECT! so FBAck is received AFTER the MN configures its nCoA ..so here 
is another one..If FBack is supposed to confirm the validity of the nCoA 
what is the value of sending it on the NAR link IF the new link will 
have to BUFFER it, without really assisting the L3 attachment at the NAR 
at all? (this is irrespective of whether the addr is a duplicate or not)

Let me rephrase the above: what is the point of sending an ACK about the 
nCoA (let alone an alternate CoA) to the NAR link if the MN will find 
the hard way that
      1) the address is already in use (the FNA would have complained 
long time ago - i.e. before the buffered FBack was forwarded to the MN)
      2) More importantly the MN has no guarrantee that its configured 
nCoA address is a valid one. And it expects the FBack as a verification 
of this guarrantee AFTER using the address. I do not see a point in 
verifying something that I will have to verify the HARD way..

The above is basically a race condition whereby the buffered FBU loses 
(its reason for existence) over the hard attachment and nCoA config at 
the NAR.

t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: Subba Reddy <[email-masked]>
Date: Sat, 03 Sep 2005 16:03:50 +0530

Hi Theo,

> you) with the NAACK or "access denied" (i.e. sorry no access).

Section 4 of spec says,

"...
   If the MN receives a Router Advertisement with a NAACK option, it
   MUST use the IP address, if any, provided in the NAACK option.
   Otherwise, the MN should configure another NCoA.  Subsequently, the
   MN SHOULD send an FBU using the new CoA.  As a special case, the
   address supplied in NAACK could be PCoA itself, in which case the MN
   MUST NOT send any more FBUs.
..."

So, as per the above para, MN *SHOULD* send FBU after
configuring new CoA in NAACK option. But in the case that I have
mentioned, MN need not send FBU again.

So, I am wondering,
    1) Is sending RA with NAACK is applicable only for the cases where HI,
HAck exchange has not happened between PAR and NAR (buffered FBack will
contain the new CoA)

or

    2) Since sending FBU is not "MUST" (only "SHOULD"), MN need not
send FBU (in the case that I have mentioned). There by sending RA with
NAACK option is applicable in all reactive cases. But in this case, it may
be
redundant to send the same information twice (NAACK and FBack).

Thanks & Regards,
Subba Reddy

> I assume

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 03 Sep 2005 13:13:01 +0100

Hi Subba,

> mentioned, MN need not send FBU again.

well the 'SHOULD' there IMO indicates that this would be the best 
practice which is not necessaryly mandatory, if the implementor sees 
otherwise. Basically this means we think we are sure this is the case 
unless shown otherwise..

> redundant to send the same information twice (NAACK and FBack).

well the FBU is used for

     0) propagating the statessly configured nCoA to the NAR for DAD 
validation
     1) associating the PCoA with the nCoA for tunnel forwarding purposes

while one can eliminate reason (0), it cannot eliminate reason (1). So 
to me it looks like the FBU remains 'necessary'. Now the strength of the 
argument of 'necessity' for such FBU is proportional to whether DAD will 
take long to complete (prior to sending the FBU) and whether the tunnel 
will save us there anything (i.e. whether it is better to just send the 
normal BU and live with the loss).

In my view (and please convince me of the opposite), sending MN 
response-specific options in an RtAdv is a bad idea since it applies to 
a SPECIFIC MN, since the RAs are sent to a multicast group and thus 
everybody 'listens' with a new can of worms for attacks, and confusion 
for MNs that may have their addresses propagated like that. The argument 
that because 'an IPv6 nCoA address in-use' is VERY rare does not show in 
the slightest if it happens to only ONE node per cell (attention: _not_ 
whether two MNs configured the same address and have the same collision, 
but WHETHER there exist 2 MNs that have been refused their nCoA and were 
provided a new one over the NAAck option). So if it happens to two, who 
is going to use the nCoA address?

t.

---

From: Subba Reddy <[email-masked]>
Date: Sat, 03 Sep 2005 19:00:20 +0530

Hi Theo,

> otherwise. Basically this means we think we are sure this is the case

ok.

> normal BU and live with the loss).

I think, you are mentioning about the case where HI, HAck exchange has
not happened. Is it true?

In the case that I have mentioned, HI, HAck exchange is over.
So the steps 0) and 1), that you have mentioned are already completed.
So MN need not send FBU again.

> for MNs that may have their addresses propagated like that.

I think, RA with NAACK option is sent to unicast address.

>From section 4 of spec,

"...
   2. send a Router Advertisement with the NAACK option in which it MAY
      include an alternate NCoA for use.  This message MUST be sent to
      the source IP address present in the FNA using the same Layer 2
      address present in the FNA.
..."

>The argument

I am not sure, I understand this.
Are you mentioning about 2 MNs with same LLA?
Otherwise, if LLA's are different, then RA will be received by only one MN.

Thanks & Regards,
Subba Reddy

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 03 Sep 2005 15:26:44 +0100

Subba Reddy wrote:
>>>    1) Is sending RA with NAACK is applicable only for the cases where
> 
> HI,
> 
>>>NAACK option is applicable in all reactive cases. But in this case, it
> 
> may
> 
>>>be

well if I recall from your message you said HI/HAck has been effected 
between PAR/NAR..so yes this handshake is long over. But this has not 
been propagated back to the MN through the FBAck. (as you said detached 
before the FBack was received)

> So MN need not send FBU again.

If the FBack has not been received by the MN then the FNA should 
encapsulate an FBU. Now given the fact that the NCoA is not accepted as 
per your scenario, (then the encapsulated FBU should be discarded by the 
  NAR (pg. 13) and thus) no FBU is sent until a new NCoA has been 
configured (either the one from the NAACK option or one configured by 
the MN as per normal).

Assuming that a NEW nCoA must be configured a NEW FBU will be in order 
(otherwise the binding pCoA<->nCoA does NOT make sense, at PAR-NAR). Now 
the FBack is ALREADY stale since a new nCoA had to be configured, and 
the FBack the signal is wasted.. :(  At the same time the MN must send a 
new FBU if it wants a tunnel from the PAR to NAR to happen at all.. so 
this is the light I am hinting under which the FBU is necessary..to 
instate the tunnel from PAR-NAR (for what - and IF - is worth).

>       address present in the FNA.

right I am glad you brought it up with a reference..this is completely 
new semantics in Neighbour Discovery. since we know of either periodic 
OR solicited RtAdvs. I have been trying to stick to ND semantics. What 
was the trigger for this router advertisment??? An FNA? But this is ARP 
semantics (ie. neighbour advert - not even solicitation). So here we are 
with the paradox that from ARP semantics we trigger Router advert 
(essentially Rt discovery) semantics which they denote address 
configuration semantics...nice..

If every protocol does that, then maybe we can imagine the consequences 
about the notion of semantics of Neighbour discovery..

>>is going to use the nCoA address?

You can have two MN with different LLAs and they can receive a RA+NAACK 
option since as I have heard the EUI-64 rule is not the only rule for 
generating an address...is this wrong?  Of course the mere fact that the 
RA has a unicast destination refutes my previous comment. As such you 
are RIGHT there: the RA _will_ be received fine by the MN with a huge 
crack on the semantics structure of ND.. One more like that and such 
semantics will be guesswork..

---

From: Subba Reddy <[email-masked]>
Date: Sun, 04 Sep 2005 11:20:03 +0530

Hi Theo,

> before the FBack was received)

True

> instate the tunnel from PAR-NAR (for what - and IF - is worth).

Since HI, HAck exchange has happened (and NAR has already proposed
new NCoA in HAck, as I mentioned in the case), tunnel formed at PAR
will be between PCoA and new NCoA. FBack is not stale, since it will
contain new NCoA. MN will send FNA[FBU] in NAR's link,
since it has not received FBack. MN will configure new NCoA
after processing NAACK or FBack
(My question is, whether the NAR send RA with NAACK or it will simply
forward the buffered packets?)
MN need not send FBU again.

Thanks & Regards,
Subba Reddy

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sun, 04 Sep 2005 20:42:50 +0100

> will be between PCoA and new NCoA. 

Let me expand my explanation here: If the MN configured proactively an 
address (nCoA1) while at the PAR, and sent it through the FBU to NAR for 
DAD validation, the MN retains that nCoA1 despite the fact that the 
FBack has not arrived at the PAR link; the reason for this is that the 
FBack would be expected to arrive at the NAR and save the day. So that 
nCoA1 is configured at the MN.

Now the fact that this nCoA1 was in-use, it would mean for the PAR that 
it  would have to not setup a tunnel between the PAR-NAR since that nCoA 
was in-use. So the PAR simply sends a ('negative') FBack at both old and 
new link.

Now from what I recall from the spec, the MN since it has not received 
an FBack prior to detachment from the PAR it must resend the FBU 
encapsulated within the FNA. And so it does. However, that nCoA is found 
to be in-use by the NAR. In reaction to that the NAR discards the 
encapsulated FBU (see rfc4068 pg.13)

"When the NCoA corresponding to the FNA message is _not_ acceptable..."

and instead it sends a unicast RA with the NAACK option (which may have 
an alternate nCoA2). If there exists an nCoA2 the MN must accept it; 
otherwise it must configure another nCoA2' which is subject to DAD 
validation. Now as soon as either nCoA2 (or nCoA2') has been accepted 
then the MN SHOULD send an FBU to establish the pCoA->nCoA2 (or nCoA2') 
tunnel (remember that the previous potential tunnel was not supposed to 
be effected since nCoA1 was in-use), otherwise a tunnel for forwarding 
purposes would not exist.. This was the FBU I am talking about (as per 
you indication from section 4, lower part of page 13). There the MN 
*SHOULD* (as you adequately put) send an FBU...

So as best practice under such scenario the FBU should be sent. Now, 
explicitly on the last part of your question:

NAR must send an RA _with_ a NAACK option that. But during such action 
and for that MN there will be _no_ buffered packets (since the tunnel 
could not be established in the first place for nCoA1) _unless_ the PAR 
has considered the alternate (if available) nCoA sent by NAR. As a 
result by the time the unicast RA is sent to the MN with the NAACK 
option only two things can happen:

   1) the PAR enforces the nCoA1' included in the HAck (by NAR) for the 
tunnel binding pCoA->nCoA1'. However if this is the case, the NAR in the 
NAACK option must enforce the _same_ nCoA1' (which the MN must accept) 
so that the tunnel can have a valid termination point!! Only then can 
you have buffered packets...
   2) the MN ignored the nCoA1' and tried to generate one on its 
own..there the buffered packets are lost..

IMHO (1) must happen but I cannot see where there is an explicit mention 
that the PAR-enforced nCoA1' and the NAACK-enforced nCoA1'' are one and 
the same thing...I think Rajeev may want to use the above text to denote 
  the behaviour below somewhere in the 4068bis.

The above in a nutshell say that: (1) NAR must send the RA with NAACK 
which MAY have a new nCoA and then (2) conditionaly in the event of an 
nCoA duplicate, depending on whether the nCoA1' included in the HAck is 
the same with the one in the NAACK to the MN there the FBU need _not_ be 
sent; otherwise it MUST! During that period assuming accurate nCoA1' 
termination on the tunnel, the NAR must commence the forwarding..

t.

FBack is not stale, since it will

---

From: Subba Reddy <[email-masked]>
Date: Mon, 05 Sep 2005 12:11:21 +0530

Hi Theo,

    Please allow me to ask few questions.

Let us assume, MN has proposed NCoA1 proactively in FBU, but NAR has
proposed
NCoA2 in HAck (since NCoA1 is in use).

Now,

1) What is the destination address of FBack (NCoA1 or NCoA2)?
I think it should be NCoA2

2) Will the tunnel is formed at PAR (i.e, between PCoA and NCoA2) after
receiving HAck?
I think Yes.

>From section 4 of the spec (page 13),
"...
   If HAck contains an assigned NCoA, the FBack MUST include it, and the
   MN MUST use the address provided in the FBack.  The PAR MAY send the
   FBack to the previous link to facilitate faster reception in the
   event that the MN is still present.  The result of the FBU and FBack
   processing is that PAR begins tunneling the MN's packets to NCoA.  If
   the MN does not receive an FBack message even after retransmitting
   the FBU for FBU_RETRIES, it must assume that fast handover support is
   not available and stop the protocol operation.
..."

3) Sorry for asking again, I have something which is not clear.
Does the NAR need to send RA with NAACK (with NCoA2)?

If Yes,
    a) How does MN know, for which NAACK (with NCoA), it needs
        to send FBU?
        If I am not missing anything, Option_code value may need to be used
for this purpose.
    b) What is the use in sending FBack to NAR's link, in this particular
case?

Thanks & Regards,
Subba Reddy

---

From: Theodoros Pagtzis <[email-masked]>
Date: Mon, 05 Sep 2005 09:23:05 +0100

> I think it should be NCoA2

if the PAR is to establish a tunnel with a valid termination point, YES 
it must be NCoA2 (otherwise the tunnelled packets will go to another 
node - as nCoA is in use).

> 2) Will the tunnel is formed at PAR (i.e, between PCoA and NCoA2) after

correct

> Does the NAR need to send RA with NAACK (with NCoA2)?

in a nutshell YES!. The NAR is imperative in the case of an nCoA 
duplicate that it signals with the unicast RA (i.e. NAACK option) which 
in this case MUST bear the same nCoA (i.e. NCoA2) for the MN to receive 
the tunnelled packets.

>     a) How does MN know, for which NAACK (with NCoA), it needs

Gotcha..remember that the MN must send the FBU *AFTER* it has configured 
its CoA address (whichever this may be). Remember also that the FBU it 
sent with the FNA got rejected because the NAR had to respond with a 
unicast RA (ND semantics broken) with the NAACK option, etc,etc,..

Now the nice thing about having the same NCoA2 at the PAR binding AND 
the NAACK option, is that that FBU is NOT really needed (since the 
tunnel is piecewise constituted up to (and including) its termination 
point (the MN in question) *CORRECTLY*.

In a nutshell, the FBU is NOT needed IFF the alternate NCoA2 enforced at 
the HAck (and thus the tunnel is set correctly at PAR between 
pCoA-NCoA2) is *identical* to the one enforced in the NAACK option.

>     b) What is the use in sending FBack to NAR's link, in this particular

simply NONE! since the NAACK option would sort it out FIRST. If I 
understand correctly this is where your thinking leads to (in line with 
my previous email answers..)

Here the spec did not think of that situation, so the wording there is a 
bit mixed up. As I have said the FBack at the NAR link is in general a 
waste, since it

          1) trying to denote the acceptance of the nCoA by FBack at NAR 
is a waste of time since NAR would preceed much earlier the FBack receipt
          2) trying to denote the establishment of the tunnel pCoA-nCoA 
by FBack at NAR will have an effect only if the FNA is delayed (since it 
   encapsulates the FBU). But delaying the FNA is definetely a bad idea 
since it delays itself the activation of forwarding (chicken 'n' egg 
situation). So as a result the FBU will be sent anyway (for no duplicate 
nCoA) and the FBack will be wasted..

I would actually like to contribute the above text (and any text from my 
answers) towards the correction of the spec where I have identified we 
have identified a problem.

t.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Sep 2005 13:48:06 +0200

> 2) Will the tunnel is formed at PAR (i.e, between PCoA and NCoA2) after

Yes after received HAck.

But the tunnel endpoint at PAR would be between PAR Address and NCoA2
(and not between PCoA and NCoA2).  The packets inside that tunnel would
be between CN Address and PCoA.  The tunnel endpoint at MN would be
between NCoA2 and PAR Address.

Alex

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 06 Sep 2005 13:49:20 +0100

Alexandru Petrescu wrote:

>(and not between PCoA and NCoA2).
>
yes. thanks for correcting there Alex!

t.

---

From: Subba Reddy <[email-masked]>
Date: Tue, 06 Sep 2005 19:23:28 +0530

Hi  Alex,

> between NCoA2 and PAR Address.

Thanks for correcting.  By mistake, I have written PCoA.

Thanks & Regards,
Subba Reddy

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Sep 2005 16:09:16 +0200

Subba Reddy wrote:

>>> Let us assume, MN has proposed NCoA1 proactively in FBU, but NAR
>>> has proposed NCoA2 in HAck (since NCoA1 is in use).
>>> 
>>> Now,
>>> 
>>> 1) What is the destination address of FBack (NCoA1 or NCoA2)? I
>>> think it should be NCoA2
>>> 
>>> 2) Will the tunnel is formed at PAR (i.e, between PCoA and NCoA2)
>>> after receiving HAck? I think Yes.
>> 
>> Yes after received HAck.
>> 
>> But the tunnel endpoint at PAR would be between PAR Address and
>> NCoA2 (and not between PCoA and NCoA2).  The packets inside that
>> tunnel would be between CN Address and PCoA.  The tunnel endpoint
>> at MN would be between NCoA2 and PAR Address.
> 
> 

Subba, I don't know about mistakes, but this is written in the RFC too:
"To reduce the Binding Update latency, the protocol specifies a tunnel
between the Previous CoA (PCoA) and the NCoA."

There's terminology defined for PCoA but not for the PAR Address, which
could be PARAddr or similar

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 07 Sep 2005 15:43:35 +0300

Alex, Subba,

> between the Previous CoA (PCoA) and the NCoA."

this is an error! It is meant to be ".. specifies a binding between.."
Thanks for catching it. I will enter it in the tracker.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 07 Sep 2005 16:21:37 +0300

> 2.NAR sends RA with NAACK (with alternate CoA) and then forwards the 

NAR should verify [NCOA, LLA], then send RA[NAACK], followed by
buffered packets (including FBack).

FBack is sent in any case (with or without conflict) just to be
consistent with the rest of protocol operation on PAR.

-Rajeev

> Am I missing something?
>  
> Please Clarify me.
>  
> Thanks & Regards,
> Subba Reddy
> 
> 
> ------------------------------------------------------------------------
>

---

From: Subba Reddy <[email-masked]>
Date: Thu, 08 Sep 2005 09:16:13 +0530

Hi Rajeev,

> buffered packets (including FBack).

I have few questions here.

    1) Will the NAR verifies [NCoA, LLA] or [Alternate CoA, LLA]
        after receiving FNA[FBU]?
    2) Does the MN need to send FBU in this case?

Thanks & Regards,
Subba Reddy

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Sep 2005 10:32:28 -0700

>         after receiving FNA[FBU]?

MN does not know the Alternate CoA at this point.

>     2) Does the MN need to send FBU in this case?

Probably a good idea to send (i.e., SHOULD). This is stated on Page 13, 
below FNA processing: "Subsequently, the MN SHOULD send an FBU using the 
new CoA."

Regards,

-Rajeev

---

From: Subba Reddy <[email-masked]>
Date: Thu, 15 Sep 2005 10:01:01 +0530

Hi Rajeev,

> MN does not know the Alternate CoA at this point.

If NAR receives FNA, it needs to verify [Alternate CoA, LLA] and if it
receives
FNA[FBU], it needs to verify [NCoA, LLA].

So NAR needs to parse the packet and know whether it has received
FBU is also or not along with FNA before identifying the host.

Is it a good idea to do like this?

Some text may be needed in the spec to clarify this verification.

> below FNA processing: "Subsequently, the MN SHOULD send an FBU using the

Since PAR has already established the tunnel (in this case),
it may be unnecessary to send FBU again.

If NAR can indicate this in RA with NAACK (probably in NAACK option), MN
need not
send FBU again.

Am I missing something?

Thanks & Regards,
Subba Reddy

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Sep 2005 12:07:26 -0700

> FBU is also or not along with FNA before identifying the host.

I guess I do not understand this..

> If NAR can indicate this in RA with NAACK (probably in NAACK option), MN

It may be an additional transmit, but I don't see it as a problem.

Regards,

-Rajeev

---

From: Subba Reddy <[email-masked]>
Date: Fri, 16 Sep 2005 11:29:03 +0530

Hi Rajeev,

> I guess I do not understand this..

Sorry for not being clear.
Consider the following case

MN has sent FBU with NCoA1 in PAR's link.
PAR has sent HI to NAR. Assume that NCoA1 is already in use and
NAR replied with HAck including NCoA2. PAR has sent FBack to
MN(PAR's link and NAR's link).

Now,
    1. If MN receives FBack in PAR's link, it will send FNA with NCoA2 as
source address
    2. If MN is moved to NAR's link before receiving FBack, it will send
FNA[FBU] with NCoA1 as source address.

So, If NAR receives FNA, it needs to verify [NCoA2, LLA] and if it
receives FNA[FBU], it needs to verify [NCoA1, LLA] to identify the MN.

NAR needs to parse the packet and know whether it has received
FBU is also or not along with FNA before identifying the MN.

    a) Is it a good idea to do like this.
    b) Since NCoA1 is already in use, will it help in identifying the MN
        (in FNA[FBU] case)

> It may be an additional transmit, but I don't see it as a problem.

One thing is additional transmission can be avoided.

There may be a problem with sequence number (which will
also be there in some other cases), as explained below.

Consider the following case
MN has sent FBU with NCoA1 and sequence number #1 in PAR's link.
PAR has sent HI to NAR. Assume that NCoA1 is already in use and
NAR replied with HAck including NCoA2. PAR has sent FBack to
MN(PAR's link and NAR's link) with sequence number #1. PAR has
formed the tunnel and tunneling the packets.

Assume that MN is moved to NAR's link before receiving FBack.
MN has sent FNA[FBU] in NAR's link. NAR has sent RA with NAACK.
NAR will forward the buffered packets (which includes FBack also).
Assume that before receiving the buffered packets, MN has sent FBU
with sequence number #3.

Now MN will drop the first FBack(buffered one) because of sequence
number mismatch. Tunnel will not be formed at MN, since FBack is dropped.
So MN will drop the received buffer packets, till it receives the second
FBack
(i.e, response to the FBU sent form NAR's link).

Similar sequence number problem will be there in all cases where tunnel is
formed at PAR (between PAR address and NCoA), and MN is sending
FNA[FBU] in NAR's link. Since FBU in FNA[FBU] will contain different
sequence number than the sequence number in FBU sent from PAR' link.

Regarding sequence number usage, from sec 6.3.1 of spec,
"      Sequence Number
                     See RFC 3775 [3]."

As per my understanding, in MIPv6, retransmitted BUs will carry
different sequence numbers.

Thanks & Regards,
Subba Reddy

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 10:23:44 -0700

> receives FNA[FBU], it needs to verify [NCoA1, LLA] to identify the MN.

In both the cases, it is only looking at the source IP address (i.e., it 
does not matter whether it is NCoA1 or NCoA2).

> FBU is also or not along with FNA before identifying the MN.

No. You have an mbuf or sk_buf containing both the packets. You first 
process FNA only. If NCoA is in conflict, you drop the inner FBU and 
send NAACK.

>     a) Is it a good idea to do like this.

Since the NCoA is the same on FNA and FBU, there is no need to parse the 
packet.

>     b) Since NCoA1 is already in use, will it help in identifying the MN

It should, right? You are verifying based on source address regardless 
of whether there is FBU encapsulated or not.

> Assume that before receiving the buffered packets, MN has sent FBU

If the MN sent FNA[FBU], why would it send FBU with Seq #3 ?

-Rajeev

---

From: Subba Reddy <[email-masked]>
Date: Sat, 17 Sep 2005 11:24:06 +0530

Hi Rajeev,

> does not matter whether it is NCoA1 or NCoA2).

Since NAR is having 2 IP addresses (NCoA1 and NCoA2) corresponding to MN,
NAR needs to know with which address it needs to compare the source address
of
the received packet.

> If the MN sent FNA[FBU], why would it send FBU with Seq #3 ?

Since MN has received RA with NAACK, it needs to send FBU again.
As per my understanding different FBUs will carry different sequence
numbers.

Thanks & Regards,
Subba Reddy