Subject: [mobile-ip] FMIPv6: FBU transmission text

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Jun 2003 19:08:19 -0700

Hello folks,

here is the description, perhaps suited for the
Overview section. I ask that you read the
whole text before begining your comments.
Recent reading of the draft itself is also helpful :-)

Thanks,

-Rajeev

The following two scenarios capture the protocol operation.

1) The MN receives FBack on the previous link. This means PAR has
processed FBU, exchanged HI for HAck before sending FBack to the
MN. When NAR accepts NCoA, which should overwhelmingly be the case, it
begins to proxy the address until it processes the MN's
announcement. The MN has to announce its presence as soon it connects to

NAR in order to be able to receive packets immediately. Note that
until NAR receives a notification from the MN, it does not perform
neighbor discovery for NCoA by virtue of being a proxy for that
address. Hence, NAR cannot forward any incoming or buffered packets
until it learns of the MN's presence on the new link.

When NCoA is not accpetable to NAR, FBack provides an indication as
such. The MN falls back to a new address configuration after
connecting to NAR. It may then send an FBU to PAR from the new link.

2) The MN does not receive FBack on the previous link. This covers two
sub-scenarios. First, the MN has sent FBU, but has left the link
before FBack could be received. Second, the MN has not sent FBU in the
first place, or FBU is lost. In both the cases, NCoA is not confirmed
and FBU processing by PAR cannot be assumed. Furthermore, NAR would
have no neighbor cache entry for NCoA in the second case. So,
immediately after connecting to NAR, the MN needs to establish a
forwarding entry at NAR for NCoA and (re)send FBU.

In the above scenarios, it is clear that a message from the MN
to NAR is necessary, and such a message should be sent as soon as MN
connects to NAR. In scenario 1), this message (call it 'M') announces
MN's presence on the new link to NAR so that packet forwarding to the
MN can begin. In scenario 2), 'M' requests NAR to begin forwarding
incoming packets providing NCoA is confirmed. In both the scenarios,
it is crucial for NAR to have a forwarding entry for NCoA, and
especially avoid a round-trip corresponding to neighbor discovery. The
format of 'M' includes NCoA and MN's Link-Layer Address (LLA) in both
the cases.

When NAR receives message 'M',

a) it verifies if an entry exists for NCoA in its proxy neighbor
cache. If there is, it moves the entry to neighbor cache makes it
REACHABLE and forwards any buffered packets. Otherwise,

b) it verifies if an entry exists in neighbor cache for NCoA.
If there is, NCoA is already in
use by another host; so NAR sends a Router Advertisement with an
option indicating that the MN should fall back to reconfiguring its
address according to RFC 2462. If NAR does not find an entry for NCoA
in its neighbor cache, it creates an entry for the <NCoA, LLA>
tuple and makes it REACHABLE.
[note]

In b), if there is no entry for NCoA in NAR's forwarding tables, but
there is already a host on the link with NCoA, NAR will incorrectly
create an entry. However, such an entry would be over-written when an
advertisement for the DAD probe is received. When this happens, NAR
could forward packets to an unintended host. This is the penalty for
using NCoA while DAD is in progress and is not unique to the mechanism
described here. Indeed, a simple scan for an existing entry improves the

chances of expeditiously detecting duplicates. In any case, it is useful

to bear in mind that the likelihood of a collision actually taking place
is
insignificant in the first place.

As a further optimization for scenario 2) above, this document
proposes that the FBU be carried as an encapsulation within message
'M'. So, the MN would include FBU (with source IP address set to NCoA)
within 'M' whenever an FBack has not been received. When NAR processes
'M', normal IP forwarding would transmit FBU to PAR if no conflict
 is found for NCoA in NAR's forwarding table. If there is address
conflict, NAR drops the inner IP packet. The result is to establish a
forwarding entry at NAR and to forward FBU to PAR
using a single packet. An additional advantage of such encapsulation
is that the router is not required to respond to 'M' unless there is a
conflict. If FBU were sent independently and without waiting for a
response to 'M', the likelihood of misdirecting packets to an
unintended host increases whenever there is address conflict. With
encapsulation, if NAR finds an existing entry for NCoA, it simply
drops the FBU thus avoiding the collision.
When stateful address configuration is used, NAR may buffer the FBU
packet until NCoA is confirmed.

The message 'M' is a re-formatted version of the existing message
FNA. The type of the message is changed from an ICMP option to IPv6 with

Destination option to carry NCoA and LLA and facilitate carrying an
FBU packet as encapsulation.

The name for message 'M' is open :-)

[note] Alternatively, when stateful address configuration is used, NAR
engages in protocol operation to obtain an address for the MN and it
may use NCoA as a proposed address in this operation. Details TBD.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jun 2003 10:19:37 -0700

> connecting to NAR. It may then send an FBU to PAR from the new link.

How about substituting this for the last paragraph:

    When NCoA is not acceptable to NAR, FBack provides an indication why.
    The MN performs new address configuration after moving to the new
    link, by default as described in RFC 2462 or using stateful address
    configuration, but possibly using other mechanisms. The MN may then
    send an FBU to PAR from the new link if route optimization and home
    agent binding update have not yet completed.

I also think it would be sensible to add in a single paragraph after the
above text:

    Receipt of an FBack on the old link establishes an invariant: the MN
knows that
    either the proposed NCoA is valid on the new link or it isn't.

> forwarding entry at NAR for NCoA and (re)send FBU.

How about:

    If the MN does not receive FBack on the previous link, there are
    two possibilities:

    a) In predictive handover, the MN has sent the FBU on the
    previous link, but has left
    the link before the FBack could be received or the FBU was
    dropped.

    b) The MN did not send the FBU on the old link. This might
    be because the link layer does not support predictive handover,
    or it might be because the MN did not have enough time prior
    to moving to the new link to send the FBU.

    In both cases, the NCoA has not been confirmed and  FBU
    processing by PAR cannot be assumed. Immediately
    after moving to the new link, the MN must establish
    a neighbor cache entry at NAR for NCoA and send an
    FBU to PAR to initiate the tunnel.

> insignificant in the first place.

I find this description somewhat confusing. I don't see any difference
between a proxy neighbor cache and a neighbor cache. The issue seems fairly
simple to me. There are three possibilities: predictive handover succeeded
and the NAR is defending the address and has a neighbor cache entry for the
MN's NCoA, predictive handover failed or was not possible and there is an
existing node with a neighbor cache entry having the proposed NCoA (most
unlikely but possible), or predictive handover failed or was not possible
and there is no neighbor cache entry for the proposed NCoA. These should be
reflected in the state of the neighbor cache itself.

Note that in the third case, given the existing RFC 2461 definition of how
the neighbor cache is managed, its possible that there is a node on the link
but the neighbor cache entry is timed out. So, the FMIP spec needs to talk
about managing the neighbor cache somewhat differently to minimize this
possibility.

> may use NCoA as a proposed address in this operation. Details TBD.

I am not confortable with calling the piggybacking of M and FBU an
encapsulation. I don't know of any other protocol that works this way, and
it feels to me a bit like a hack. I view this as similar to the case of
piggypacking a BU along with traffic to avoid having to send two different
messages in route optimization. That is, M is piggybacked on the FBU. In
both cases, it is an optimization, and an MN could choose to send the
message separately or it could choose to piggyback.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Jun 2003 12:14:46 -0700

Jim,

I will answer your questions below. And, I will have
a look at your suggestions to improve text.

> between a proxy neighbor cache and a neighbor cache. The issue seems fairly

The difference is when you have a proxy ND cache entry, you defend
that address and do not invoke NS if packets arrive for the address
you are defending.

> and the NAR is defending the address and has a neighbor cache entry for the

In this case, you don't create a ND cache entry. Doing so would mean
potentially invoking NS when packets arrive from PAR. Instead, you create
a proxy ND cache entry and begin defending the address if some host
attempts to configure the address you are defending. (you = NAR).

> reflected in the state of the neighbor cache itself.

This is what I have tried under a) and b) in my text.

> about managing the neighbor cache somewhat differently to minimize this

This is the case when you don't want to wait for DAD to finish. A scan
through the ND cache of the router minimizes the possibility of a conflict
with another node, but it does not eliminate it.

> message separately or it could choose to piggyback.

You could call it that way. Actually, FBU is inside M only when FBAck
has not been received. As I outlined, it is both an optimization and serves
to avoid the damage in case there is a collison. That is, if NAR finds an
entry,
it drops FBU. If you did this independently, i.e., sent M first and then FBU,
NAR would have to "somehow" screen for FBU to drop it if NAR found a
conflict when processing 'M'.

Thanks,

-Rajeev

ps: optimizations could be called hacks, and have been called before :-)

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jun 2003 13:05:33 -0700

> that address and do not invoke NS if packets arrive for the address

Right but it seems to me  what you want is an additional state in the
neighbor cache entry, say PROXIED, and not a brand new conceptual data
structure. And define state transitions to the usual states defined in RFC
2461. In fact, I believe an earlier draft of FMIP was so written (if I
recall correctly).

> ps: optimizations could be called hacks, and have been called before :-)

Um, right. What I meant by "hack" was, encapsulation as an option in another
message. There are ways to do "encapsulation" (c.f. BU piggybacking on
traffic) that don't have the feeling of a hack, and then there ways that do.
I think we ought to try to stick to MIPv6 standard mechanisms (header
options for example).

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Jun 2003 15:32:39 -0700

> structure. And define state transitions to the usual states defined in RFC

I think it is better to speak of proxy ND entry and ND entry; both could
be part of the same data structure. I guess proxy ND entry should be
general enough, at least for MIP folks.

> 2461. In fact, I believe an earlier draft of FMIP was so written (if I

It was set to INCOMPLETE, which I believe is not accurate.

> I think we ought to try to stick to MIPv6 standard mechanisms (header

If you say that BU piggybacking is an acceptable form of encapsulation,
this should be as well (perhaps even more so). Control packet within a data
packet versus
control packet within a control packet. Here, forwarding of
inner control packet depends on processing of outer control packet
and is crucial for performance. Ofcourse a single packet would have
been desirable, but that would necessitate separate FBU formats
for predictive and reactive scenarios.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jun 2003 15:38:14 -0700

> for predictive and reactive scenarios.

Again, the details are important. Are you proposing the following:

        IPv6 header : ICMP header : M : <option: FBU>

or:

        IPv6 header : M header option : FBU

or something else?

        jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Jun 2003 16:27:01 -0700

>         IPv6 header : ICMP header : M : <option: FBU>

This won't work since NAR needs to forward FBU alone..

>         IPv6 header : M header option : FBU

[IPv6 header: src=NCoA, dst=NAR, NH=Dest-opts]
[Dest-opts:NCoA, LLA, NH = IPv6]  <--- 'M'
[IPv6 header, src = NCoA, dst = PAR, NH = Mobility Header]  <--- FBU

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jun 2003 16:34:19 -0700

Ok.

            jak

---

From: "Xiaoming Wang" <[email-masked]>
Date: Mon, 23 Jun 2003 11:52:12 +0900

Hello, Rajeev,

The new version is to solve issues surrounding ingress filtering, but it
introduces the issue of possibility of duplicate address. The draft should
put extra consideration on this issue. Although it is argued that
duplication is very rare, and don't need to consider that 1% possibility out
of 99%, it seems it is considered in the new version, where NAR should
examine its forwarding table for simple check of duplication.

My suggestion is: it's better to remove this simple check. AFAIK, this
simple check is not really simple. Instead, it's time consuming and
unacceptable for a router. Since we assume that duplication is very rare,
why not omit this time consuming check for performance improvement for 99%
possibility.

Regards,

xiaoming

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rajeev Koodli
> Sent: Thursday, June 19, 2003 11:08
> To: [email-masked]
> Subject: [mobile-ip] FMIPv6: FBU transmission text
>
>
> Hello folks,
>