Subject: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Aug 2005 14:22:31 +0200

Hello,

I am not sure whether this issue has been already raised, sorry if so.

Encapsulating FBU into an FNA may not be a very good idea.  FNA is an
option in the Mobility Header, whose 3775-specified Payload Proto is
IPPROTO_NONE.  That means it can't encapsulate anything.

It is true that 3775 says "Payload Proto [...] intended to be used by a
future extension" but only to further refer to a non-existent Appendix B.1.

Any thoughts?

Alex

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

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 9 Aug 2005 22:02:17 +0900

Hello,

I came up against the same situation during implementing FMIPv6.
All current MIPv6 implementations don't accept the encapsulated FBU.

Changing 3775 may work because the last header is still MH.
And sending FBU and FNA separately works fine on my implementation.

I personally prefer to send it separately, because it's more easy
to implement, we don't need to modify 3775.

regards,
Koshiro

---

From: "Junghoon Jee" <[email-masked]>
Date: Tue, 9 Aug 2005 22:18:00 +0900

Hi Koshiro and Alex,

What about using FBU solely without FNA ?
Some implication from the FMIPv4 draft, "Adapting Mobile IPv6 Fast Handovers
for IPv4".

Regards,
Junghoon 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Koshiro MITSUYA
> Sent: Tuesday, August 09, 2005 10:02 PM
> To: Alexandru Petrescu
> Cc: [email-masked]; Koshiro MITSUYA
> Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
> Mobility Header (FNA)
> 
> 
> Hello,
> 
> I personally prefer to send it separately, because it's more 
> easy to implement, we don't need to modify 3775.
> 
> regards,
> Koshiro
> 
> 
> 
> > It is true that 3775 says "Payload Proto [...] intended to 
> be used by 
> > a future extension" but only to further refer to a non-existent 
> > Appendix B.1.
> >
> > Any thoughts?
> >
> > Alex
> >
> >

---

From: Subba Reddy <[email-masked]>
Date: Tue, 09 Aug 2005 18:59:32 +0530

Hi Alex & Koshiro,

    Section 6.3.3 of RFC 4068 (FMIPv6) says,
"....
When the Mobility Header Type is FNA, the Payload Proto field
   may be set to IPv6 to assist FBU encapsulation.
......"

It may not be a good idea to send FNA and FBU independently.
Because
1. As of now, in FMIPv6, NAR will not send acknowledgement, if the
NCoA in FNA is not in use.
2. It will cause delay. First MN needs to send FNA and needs to get
RA with NAACK, then only it can send FBU.

If we use encapsulation, one round trip time between MN and NAR can be
saved.

Thanks & Regards,
Subba Reddy

---

From: Subba Reddy <[email-masked]>
Date: Tue, 09 Aug 2005 19:06:35 +0530

Hi Junghoon,

> What about using FBU solely without FNA ?

If MN has sent FBU in PAR's link, and if it has not received FBack,
there can be two possibilities

1. Tunnel is not established between PCoA and NCoA, because FBU itself might
be lost.
2. All the message exchange happened successfully (FBU,HI,HAck), but by the
time PAR sends
FBack MN might have moved to NAR.

In the second case, if MN sends FNA, MN can receive the packets immediately.
Since MN don't
know whether message processing is successful or not, it will send FNA[FBU].
So this will cover
both the cases.

If we send only FBU, NAR don't know, when to forward the packets.

Thanks & Regards,
Subba Reddy

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Aug 2005 08:47:59 -0700

I think we need to fix this in 3775bis. While sending the two separately is
fine to get things working, the whole point of FMIP is to speed up handover,
and there is already too much traffic during subnet switching. Adding
another message isn't going to help.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Aug 2005 08:51:20 -0700

If oDAD is used, is FNA really needed?

            jak

----- Original Message -----
From: "Subba Reddy" <[email-masked]>
To: "Junghoon Jee" <[email-masked]>; "'Koshiro MITSUYA'"
<[email-masked]>; "'Alexandru Petrescu'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 09, 2005 6:36 AM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

---

From: Subba Reddy <[email-masked]>
Date: Tue, 09 Aug 2005 21:23:16 +0530

Hi Jak,

> If oDAD is used, is FNA really needed?

I think, atleast to notify NAR about MN arrival, so that
NAR can forward the buffered packets, we need
some message(FNA). This may be done by some
other means like L2 trigger at NAR, if available.

Thanks & Regards,
Subba Reddy

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Aug 2005 09:23:29 -0700

But if the MN sends out the oDAD NS right after sending the FBU, then the AR
will see it, right?

            jak

----- Original Message -----
From: "Subba Reddy" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Junghoon Jee"
<[email-masked]>; "'Koshiro MITSUYA'" <[email-masked]>;
"'Alexandru Petrescu'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 09, 2005 8:53 AM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

> > > 2. All the message exchange happened successfully (FBU,HI,HAck), but
by
> > the

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Aug 2005 12:00:41 +1000

Hi James,

> But if the MN sends out the oDAD NS right after sending the FBU, then the AR

There's currently no reason a router would process the NS,
as it's not subscribed to the multicast group for the solicited nodes
address.

Routers are typically configured all-multicast, though, so it should
at least see the frame (as long as the snooping switches aren't horribly
broken).

If we want the router to process these, then it's possibly a significant
modification of the existing ND processing (may require kernel
support??).

That's not to say it can't be done, or tested though.

Greg

>>>Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header
>>
>>(FNA)
>>
>>>
>>>>Hi Junghoon,
>>>>
>>>>
>>>>
>>>>1. Tunnel is not established between PCoA and NCoA, because FBU itself
>>>
>>>might
>>>
>>>>be lost.
>>>>In the second case, if MN sends FNA, MN can receive the packets
>>>
>>>immediately.
>>>
>>>>Since MN don't
>>>>know whether message processing is successful or not, it will send
>>>
>>>FNA[FBU].
>>>
>>>>So this will cover
>>>>both the cases.
>>>>
>>>>>Some implication from the FMIPv4 draft, "Adapting Mobile IPv6 Fast
>>>>
>>>>Handovers
>>>>
>>>>>for IPv4".
>>>>>
>>>>>Regards,
>>>>>Junghoon
>>>>>
>>>>>
>>>>>>All current MIPv6 implementations don't accept the encapsulated
> 
> FBU.
> 
>>>>>>And sending FBU and FNA separately works fine on my
> 
> implementation.
> 
>>>>>>>I am not sure whether this issue has been already raised,
>>>>>>
>>>>>>sorry if so.
>>>>>>
>>>>>>>Encapsulating FBU into an FNA may not be a very good idea.
>>>>>>
>>>>>>FNA is an
>>>>>>
>>>>>>>option in the Mobility Header, whose 3775-specified Payload
>>>>>>
>>>>>>Proto is
>>>>>>

---

From: Subba Reddy <[email-masked]>
Date: Wed, 10 Aug 2005 08:53:56 +0530

Hi Jak,

> But if the MN sends out the oDAD NS right after sending the FBU, then the
AR

True. One problem may be that for every NS, NAR needs to look into buffering
database
(i.e, buffered packets). If we send FNA or special message, NAR can compare
for only
that message.

Thanks & Regards,
Subba Reddy

(FNA)

---

From: Subba Reddy <[email-masked]>
Date: Wed, 10 Aug 2005 08:59:12 +0530

Hi Jak,

> another message isn't going to help.

I think, if we use, oDAD, then sending the two message (FNA & FBU)
separately will work. One thing is that, if the tunnel is established
already
(MN has sent FBU in PAR's link, but has not received FBack, but HI,
HAck message exchange is completed), MN may be unnecessarily sending FBU.

Thanks & Regards,
Subba Reddy

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 10 Aug 2005 12:49:23 +0530

Hi,

http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt
In the above draft, FNA is not required, FBU is sent directly to
PAR without being encapsulated in the FBU.

Section 4
.....
   4.  The MN receives a DNA Router Advertisement, determines change in
       subnet, configures new care of address and makes the address
       optimistic [2].
   5.  The MN sends a Fast Binding Update (FBU) to the Previous Access
       Router (PAR) directly without being encapsulated in FNA.
.....

Even though this draft talks about the reactive handoff with DNA, in 
principle
the FNA can be avoided (I think).

-Syam

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 07:49:29 -0700

MLDv2 requires routers to listen to all multicast addresses:

   For each interface over which the router operates the MLD protocol,
   the router must configure that interface to listen to all link-layer
   multicast addresses that can be generated by IPv6 multicasts.  For
   example, an Ethernet-attached router must set its Ethernet address
   reception filter to accept all Ethernet multicast addresses that
   start with the hexadecimal value 3333 [RFC2464]; in the case of an
   Ethernet interface that does not support the filtering of such a
   multicast address range, it must be configured to accept ALL Ethernet
   multicast addresses, in order to meet the requirements of MLD.

(Section 7 of RFC 3810)

Since FMIP is requiring changes in the router anyway, it can require MLDv2
as a base.

            jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Subba Reddy" <[email-masked]>; "Junghoon Jee"
<[email-masked]>; "'Koshiro MITSUYA'" <[email-masked]>;
"'Alexandru Petrescu'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 09, 2005 7:00 PM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

(FNA)

---

From: Greg Daley <[email-masked]>
Date: Thu, 11 Aug 2005 12:30:28 +1000

Hi James,

> Since FMIP is requiring changes in the router anyway, it can require MLDv2

I agree that reception of ICMPv6 multicast packets will occur
and we can assume MLDv2.  In that case it may be possible
to have the modifications in user space, for
example on a raw/ICMPv6 socket.

We just need to determine if the processing operations are
simple enough (probably if my assumption above is correct??)
and if the behaviour of the MN is predictable in terms of
packet ordering with the oDAD NS.

It has previously been argued that the DAD NS isn't time critical
for optimistic hosts.   Does it make sense to tie this to the
critical path for FMIPv6 hosts (since they'd have to do DAD anyway,
and it would be nice to have a single link seizure for both
announcement and DAD initiation - apart from MLD reports that is)?

Greg

>>>But if the MN sends out the oDAD NS right after sending the FBU, then
> 
> the AR
> 
>>>will see it, right?
>>