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

From: Soliman Hesham <[email-masked]>
Date: Mon, 23 Jun 2003 20:49:41 -0400

> > So to conclude, do you think there is some analysis
 > > (theoritical or experimental) that can show that OptDAD
 > > will not help FMIPv6 ? If there is, it would be very helpful
 > > if you or someone else could share that with us.
 > >
 > 
 > Again, what is proposed is re-using existing messages to
 > achieve the desired objective. Yes, FNA has been around :-)

=> To answer this and your other email. When I said "new"
I meant not in any existing RFC. I don't care which rev
of the draft included it or who was the editor for the draft.
I was not accusing you of a crime! I'm simply stating that
we could do without some of the messages in the draft and it
is worth making them optional. It's better to discuss
whether this is feasible than to debate history.

 > I agree with Basavaraj, Greg and Youn-Hee Han that we should
 > proceed with the FMIPv6 mechanism while also allowing DAD
 > optimizations to work with FMIPv6.

=> So how will we allow it to work with FMIPv6? Do
we invalidate/update the future FMIPv6 RFC when Opt DAD
comes out?? 
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 ..." ?

 > 
 > Regarding your question above: I am not claiming that optDAD
 > or _any_ other DAD optimization scheme cannot help FMIPv6. 

=> Ok so we agree with this.
   I
 > am only saying that for FMIPv6 it is one of the things, something you
 > seem to agree.  

=> Agreed.

    FMIPv6 has proposed a method to handle NCoA
 > configuration. Can you prove that it is sub-optimal to OptDAD or
 > any other variant ?

=> I didn't say it was suboptimal for detecting address
allocation. I'll summarise my comments on the current
mechanism (compared to using a DAD optimisation) as 
follows:

- It adds further complexity. More messages => more complexity.
- The amount of messages is not justified by the rarity
  of this event.
- 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.

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2003 18:21:07 -0700

> we invalidate/update the future FMIPv6 RFC when Opt DAD

Well, that's for the entire working group to decide.

> 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.

> allocation. I'll summarise my comments on the current

It is not sub-optimal in terms of delay, nor in terms of the messages
either :-)

> - 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

How many messages are there ??

>   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
- something like FNA is needed to allow the NAR to
    create a ND cache entry unambiguously.

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Jun 2003 18:35:13 -0700

>   when a DAD optimisation is being used.

what optimistic DAD? there is no spec that works currently.
nothing standardised.

from draft-moore-ipv6-optimistic-dad-02.txt

>    It may be desirable for a Neighbour, for example the router, to
>    rapidly establish communication with the newly configured ON. To do
>    so, it must learn of the ON's arrival as soon as possible.  To avoid
>    having to wait for Neighbour Discovery, the ON may wish to send
>    unsolicited Neighbour Advertisements (with Override set
>    appropriately), but for this to be effective the Neighbour must
>    either:
> 
>    * be expecting the ON to arrive (eg: due to predictive mechanisms),
>         and thus already have a NC entry for the peer, in state
>         INCOMPLETE.

notice the word "predictive" there? if the new Access Router
is not expecting the optimistic node on the link, it does
not create a neighbor cache entry for the MN. this is 
because the Neighbor Advertisement sent by the opimitistic
MN has the overide bit set to 0.

what is the predictive mechanism here? I can only think of 
HI-HACK exchange.

this draft doesnt even have a home. the new WG is not
formed yet. it is a bit weird to say "HI-HACK is optional 
because there might a fugure optimistic DAD mechanism 
defined in an yet to be formed WG".

the mobile needs to be able to do the following after moving 
to a new link

1. send packets to nodes off link
2. receive packets from nodes off link
3. send packets to nodes on link
4. receive packets from nodes on lnk.

draft-moore does not solve (2). the only thing new in 
draft-moore is how it solves (3). 

for (1), the mobile node sends packets to the default router.
the MAC address of the default router was obtained through a
router advertisement. but this does not work if the router
advertisement did not contain the source link layer address
option.

for (2), an unsolicited NA from the mobile node creates a
neighbor cache entry at the access router. but this works
only if a predictive mechanism has already warned the 
access router to expect a mobile node to show up.

for (3), the mobile node sends a packet to the defaul router.
but an ICMP redirect from the default router creates a neighbor
cache entry for the destination on link. this is new.

for (4), the mobile node can respond to neighbor solicitations
from other nodes on the link.

draft-moore does not work without a predictive mechanism.
Nick, Greg, please correct me if I am wrong.

Vijay

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 24 Jun 2003 12:42:19 +1000

G'day Vijay ...

> from draft-moore-ipv6-optimistic-dad-02.txt

Hurrah!  Someone actually read it!

> >    rapidly establish communication with the newly configured ON.
[...]
> MN has the overide bit set to 0.

That's right.  If the router _doesn't_ already have traffic 
waiting for the MN, because it _isn't_ doing prediction,
this won't work.  But if it doesn't have traffic waiting,
it doesn't need to work.  The MN can still send the BU,
and when the Router does have traffic for the MN, the 
NS/NA message will work (even while Tentative)

Prediction is an option which OptiDAD interoperates with, in short.

> defined in an yet to be formed WG".

Well, that's a bit frustrating to me too!  I'd love to get
it adopted by one splinter or another.  It's been kicked
around in MobileIP WG and IPv6 ...

> draft-moore is how it solves (3). 

Erm, no.  It solves (1 mostly), (2), (3), and (4).

> advertisement did not contain the source link layer address

True.  A router is allowed to omit the SLLAO for load balancing
purposes.  A router which omits SLLAO won't work with the current
draft of OptiDAD.  I have no idea whether the ommission of SLLAO
is a common practice, so maybe someone can enlighten me ...

It's possible there's a way around it ... I'll have a think
about this for a possible -03.

> access router to expect a mobile node to show up.

If any packet is received for the MN at the NAR, the 'normal'
neighbour discovery process will happen, the router will create
a NC entry and communications will proceed.

> cache entry for the destination on link. this is new.

Yep, that seemed a neat way to do it!

> Nick, Greg, please correct me if I am wrong.

Well, hopefully the above text clarified that it will indeed
work without a predictive mechanism.

We've also coded up a mostly complete implementation for Linux,
and tested it as part of our work on non-predictive handovers.
I presented the results of this work at IETF 56 too.  It worked :-)

(Thanks for reading the draft though!)

-----Nick

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Jun 2003 19:38:40 -0700

> Hurrah!  Someone actually read it!

:)

> NS/NA message will work (even while Tentative)

ah.. I hadnt thought about the NS/NA exchange, when I 
sent the mail. the extra NS/NA exchange will create a
neighbor cache entry. agreed. it might be good to 
better explain "the predictive mechanisms" phrase used
in your draft.

> Prediction is an option which OptiDAD interoperates with, in short.

okay. and here we are trying to figure out if optiDAD
works with FMIPv6 prediction. FMIPv6 prediction could
cause problems, if the packets from the PAR start
arrving at the NAR, before the MN shows up. the NAR
would do a couple of neighbor solicitations, get no
response, delete the INCOMPLETE neighbor cache entry
and send a ICMP unreachable message to the PAR. 

> Erm, no.  It solves (1 mostly), (2), (3), and (4).

agreed.

> is a common practice, so maybe someone can enlighten me ...

it is. saves some bytes over the air because the router
advertisements are periodic.

> about this for a possible -03.

I think it is reasonable to mandate including source link 
layer address option if the router is an access router and 
is expecting mobile nodes to attach to it.

Vijay

---

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

On 2003-06-24, Vijay Devarapalli wrote:
>
> it might be good to  better explain "the predictive mechanisms"
> phrase used in your draft.

Will do.

> and send a ICMP unreachable message to the PAR. 

Yeah, true.  I've been assuming that the time taken to fail out
on Neighbour Discovery is longer than handover time.
I think that that time is (MAX_MULTICAST_SOLICIT * ReTransTimer),
eg: by default it's 3000 ms. (okay so the last NS will be
sent at 2000ms)

If the L2 handover can't complete within 2000ms, we can't really
hope for fast performance at L3 either!

> > Erm, no.  It solves (1 mostly), (2), (3), and (4).

Oh good.  I've been thinking about more complete solutions to
(1) as well, trying to see if the Optimistic Node can solicit
for the router's SLLA without breaking anything.  I'm not
convinced it can safely RS, because [RFC 2461 6.2.6]:

	"Whether or not a SLLAO is provided, if a NC entry for the 
	solicitation's sender exists (or is created) the entry's
	IsRouter flag MUST be set to FALSE."

So a collision with a router would potentially confuse other nodes.
On the other hand, I'm not sure that that rule is terribly wise --
why shouldn't a Router send RSs if it wants to?

But I digress ...

> advertisements are periodic.

Mmmph.  Well, I guess with some of the very fast RA rates people
have been discussing it might be worth saving a few bytes, but
it does mean that every new node will have to solicit this
information later ... 

> is expecting mobile nodes to attach to it.

Sounds fair to me!  NB: Optimistic DAD falls back gracefully:
if the SLLAO is ommitted, the ON will just have to wait until
its address is not longer Tentative.

-----Nick

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 11:29:01 -0700

the implementations I have seen take the following seriously.

RFC 2461.

   While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  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.  When a queue
   overflows, the new arrival SHOULD replace the oldest entry.  Once
   address resolution completes, the node transmits any queued packets.

the ND queue is very small typically.

> eg: by default it's 3000 ms. (okay so the last NS will be

I think the ReTransTimer would be far less an ethernet/802.11.
not 1000 ms.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 16:51:58 -0700

Nick 'Sharkey' Moore wrote:
> 
> On 2003-06-25, Vijay Devarapalli wrote:
> Well, the default for RetransTimer (the host variable) is
> RETRANS_TIMER (the protocol constant).  While RETRANS_TIMER
> "may be overridden by specific documents that describe how IPv6
> operates over different link layers" [RFC2461], RFC2464 doesn't
> mention changing it.

exactly. it depends on the link layer.

> 
> RetransTimer is also used in DAD, and everyone seems happy to assume
> 1000ms there.  After all, it's not meant to represent L2 RTT, but
> rather an upper bound on the time it might take a device (think embedded)
> to receive a packet, wake up, think about it, fire up it's
> transmitter, wait for a slot and send it's reply.
> 
> Linux 2.4.18 has "net/ipv6/neigh/default/retrans_time = 100" (jiffies,
> 100 jiffies = 1000ms).
> FreeBSD/KAME has "#define RETRANS_TIMER 1000 /* msec */".

thats kind of dumb. the retransmit trimer has to be
different for ethernet, FDDI, 6over4, your favorite 
link layer... doesnt make a lot of sense if it is the 
same for all link layers.

> So, I think it's a fair assumption that the time taken to fail
> out on Neighbour Discovery is longer than handover time.

I think I have to disagree. :(

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 17:31:40 -0700

Nick 'Sharkey' Moore wrote:
> That would be the RFC 2464 "Transmission of IPv6 Packets over Ethernet
> Networks" that I was referring to.  It doesn't mention changing
> RETRANS_TIMER.
> 
> A quick grep doesn't show it up in any of RFC 2467 (FDDI), 2470 (Token
> Ring), 2491 (NBMA), 2492 (ATM), 2497 (ARCnet), 2529 (6over4),
> 2590 (Frame Relay), 3146 (IEEE 1394), 3316 (2G,3G) either.
> 
> Tell me if I've missed anything.

I guess you havent. and that probably explains why 
everybody just leaves it at 1000 ms. but it really makes 
no sense assuming the same RTTs for all link layers.

Vijay

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 26 Jun 2003 10:30:25 +1000

On 2003-06-26, Greg Daley wrote:
> >RETRANS_TIMER (the protocol constant).
> 
> I think that this is currently under the control of
> the network Administrator.

Yep, the host variable is.  I'm just arguing that RETRANS_TIMER,
which supplies the default value for RetransTimer, doesn't
currently change per link layer.

And until we update RFC 1149 for IPv6, it probably won't.

-----Nick

---

From: Greg Daley <[email-masked]>
Date: Thu, 26 Jun 2003 10:31:51 +1000

Hi Vijay,

> exactly. it depends on the link layer.

I think that Sharkey's point was that
IPv6 over Ethernet doesn't change the RetransTimer.

If ethernet doesn't change the timer, why would
802.11 (a,b,c,d...) change it?

My guess is that in the fixed network case
(and wireless links are fixed networks, unless
people go roaming) there's no perceived value in
changing RETRANS_TIMER.  (since DAD only occurs once (?),
NUD is unlikely to be an issue unless a local server
goes down?)

Guidance would have to come from those actually
interested in the effects of these timers: us.

> same for all link layers.

Even if it is dumb, no document in the IETF re-defines
the RETRANS_TIMER/RetransTimer values.

> I think I have to disagree. :(

If you want to change the state of the
specifications, then we'll have to do some work.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 17:36:09 -0700

> specifications, then we'll have to do some work.

ofcourse not. the different IPv6-over-foo RFCs dont 
recommend any default RTTs. I dont know why. there 
probably was a reason. maybe they left it to the
implementations.

but it is still dumb if you in your IPv6 implementation 
assume 1000ms RTT for every link layer.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Jun 2003 09:48:35 +0200 (CEST)

> I've actually never seen AdvRetransTimer set to a value
> other than zero (default: use RETRANS_TIMER).
> If we want people to set these values lower to handle mobility, then
> it will be necessary to recommend this in a document.

Having the routers advertise a non-default number would only make a
difference when a RA is received on the new link before the host performs
DAD. I don't know if this will be the case during movement.
But it might help with DAD for subsequent, non-link-local addresses.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Jun 2003 09:54:39 +0200 (CEST)

> no sense assuming the same RTTs for all link layers.

RetransTimer doesn't try to capture the RTT of the link - if it did
the number for Ethernet could be much lower.
Instead it is based on the existing ARP experience of spacing ARP requests
for the same IP address 1 second apart (I think this is the number many ARP
implementations use).

The main use for RetransTimer is for address resolution where multiple
NSs are sent before giving up. Spacing those to closely together would 
negate the added robustness of trying multiple times since the loss of NSs
could be caused e.g. by temporary overloading of the link which last for
many maximum packet times on the media.

Perhaps the desire to optimize DAD (faster but lower probability of capturing
duplicates) means we should introduce a separate timer for DAD instead
of reusing RetransTimer.

  Erik

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 26 Jun 2003 18:59:49 +1000

> duplicates) means we should introduce a separate timer for DAD instead

I'd say it's a similar situation.  For DAD, we're not just worried
about the L2 Round Trip Time, we also care about devices waking
themselves up, deciding to act, firing up their transmitters,
getting a word in edgeways and responding.  After all, we're 
talking about mobile devices, which are unlikely to be running at
full power/speed while they're idle.

The DAD timeout isn't a big problem, assuming Optimistic DAD anyway.

-----Nick
-- 
"What fun is being 'cool' if you can't wear a sombrero?" -- Hobbes

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 26 Jun 2003 09:03:17 +1000

-----Nick

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Jun 2003 14:08:22 -0700

> the number for Ethernet could be much lower.

I thought the retransmission timer for Neigbor 
Solicitation could be set to a smaller value if needed
based on the link layer being used. its kind of confusing
that the same RetransTimer is used for a lot of different
purposes.

> for the same IP address 1 second apart (I think this is the number many ARP

a question, Erik. is there an event which will trigger a 
node to send out the second Neigbor Soliticitation for 
the same address sooner than the RetransTimer? and even
if such an event occurs will the node delay for 
RetransTimer milliseconds or send another Neighbor
Solicitation immediately?

> duplicates) means we should introduce a separate timer for DAD instead

that would be a good idea. currently the same timer value
is used for both DAD and address resolution.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Jun 2003 14:27:24 +0200 (CEST)

> based on the link layer being used. 

It could. But the thinking when RFC 2461 was written was that there might be
very slow link layers where 1 second would be too small.

> Solicitation immediately?

There is no such event.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Jun 2003 13:38:00 -0700

> > Solicitation immediately?

so if the NAR sends out a Neighbor Solicitation for the 
mobile's newCoA and there is no reply (because the MN 
hasnt showed on the link yet), the NAR wont retry for 
another 1000 ms. if the mobile node shows up on the link 
after the first Neighbor Solicitation, it has to wait for 
1000 ms for the NAR to send another Neighbor Solicitation, 
reply with a Neighbor Advertisement and create a REACHABLE
neighbor cache entry at the NAR, right?

Erik, if you missing the context, we are discussing 
OptiDAD here. the NAR sends out an Neighbor Solicitation 
because the FBU to the PAR caused the PAR to start 
forwarding packets to the NAR. if NAR sends a Neighbor 
Solitication before the mobile node shows up, then we have 
a problem?

if the mobile node misses the first Neighbor Solicitatoin
then it would take 1000 ms to create a REACHABLE neighbor
cache entry. OTOH, a message like FastNA from the mobile 
node creates a REACHABLE neigbor cache entry immediately.

Vijay

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Sat, 28 Jun 2003 10:39:43 +1000

> neighbor cache entry at the NAR, right?

Okay, what the Optimistic DAD draft says is:
|
| * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited
| Neighbour Advertisement to All Nodes when it first configures
| an address.

In the next draft, that'll be upgraded to a "SHOULD if you've
send prediction messages, MAY otherwise" just to clarify
one case where you probably SHOULD.

Okay, with Optimistic DAD on the MN and an UNMODIFIED router,
what would happen in this case is:

1. NAR receives traffic for NCoA due to prediction mechanism
2. NAR creates INCOMPLETE cache entry and sends an NS.
3. MN arrives, begins Optimistic DAD configuration, sends
	unsolicited NA.
4. NAR sees NA, and upgrades it's INCOMPLETE entry to STALE.
5. NAR sends received packets to NCoA and does NUD _in_parallel_.

It's mentioned in section 2 of the Opti-DAD draft, I'll try
and clarify this in more detail in a future version and add
it to the 'Cases' section too.

NUD proceeding in parallel will introduce one more NS/NA(S=1)
message pair a few seconds later.

Hope that helps clarify things,

-----Nick

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 29 Jun 2003 22:37:10 -0700

> one case where you probably SHOULD.

that would be good.

> it to the 'Cases' section too
> 

okay.

Vijay

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 30 Jun 2003 18:04:58 +1000

> okay.

Okay, so now we've got that sorted, what do you reckon about
Hesham's proposal to simplify Fast signalling?

-----Nick

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Jun 2003 10:21:46 -0700

> Hesham's proposal to simplify Fast signalling?

convince IPv6 folks that OptiDAD is the way to go. (infact
I will support you on this). once they are convinced, we
can simplify FMIPv6 signaling. untill then, we stick to the
current FMIPv6 spec.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 30 Jun 2003 11:52:02 -0700

> I will support you on this). once they are convinced, we

Count me in as well :-)

> can simplify FMIPv6 signaling. untill then, we stick to the

I am just not convinced that the current oDAD spec will work
efficiently when there is no ND entry at the router. Unsolicited NA in
this
scenario is a waste. Furthermore, there is additional round-trip due
to NS-NA when packets do arrive.
FNA provides an indication to the router to create an entry
when there isn't one. So, the message does not go waste and
avoids a round-trip. It also helps detect duplicates, if any, at the
router.

The above scenario happens when the MN moves without sending
FBU or when it has not received FBack.

When there is an ND entry in INC state, I agree that unsolicited NA
will allow packet forwarding, even though there is still a round-trip
of messages in parallel.
This scenario is applicable when the MN has received the FBack.
The purpose of FNA here is to move the entry directly to REACHABLE
so that the additional round-trip messages are avoided.

FNA is not very different from unsolicited NA, O=0. It needs a
discriminator to request creating an ND cache entry at NAR. So,
a flag to NA would do. To encapsulate FBU within FNA however
requires that FNA is not ICMP. The proposal is to make it a
Destination Option.

-Rajeev

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Jul 2003 08:47:41 +1000

> > I will support you on this). once they are convinced, we

Excellent!  Good to get some momentum behind the damned thing.

> this scenario is a waste.

It's true that the unsolicited NA is a waste in this situation, 
but on the other hand they're small packets and frankly 802.11
is pretty wasteful to start with.  Other L2s (eg: telephony stuff)
may be more number-of-messages-critical (I remember discussing this
with James in Yokohama) but then they're generally rather friendlier
to handovers anyway.

> avoids a round-trip. It also helps detect duplicates, if any, at the

Yeah, the big reason for Optimistic DAD is that it can work on
an unmodified access router, admittedly at a penalty in extra
signalling.

Either (a) traffic gets to NAR before MN sends that unsol NA,
or (b) it doesn't.

We've ccvered (a) in this thread.

In (b) there will be no NAR NC entry and so the NAR SHOULD ignore
the unsolicited NA.  Either traffic will arrive due to the 
prediction mechanism, or the MN will promptly send a BU back to
it's HA/MAP/CNs which will send traffic through to NCoA.
Either way, when traffic gets to NA, NAR will NS for NCoA and MN
to reply with an NS (O=0, S=1), which will upgrade the NC entry
from INCOMPLETE to REACHABLE.

> so that the additional round-trip messages are avoided.

Yeah, and I think that's the difference.  Optimistic DAD is an
attempt to make all this work ON AN UNMODIFIED NAR at the expense
of a couple of extra round-trips.  I think it's important that
we get a practical handover protocol which will work in Starbucks :-)

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Jul 2003 08:54:08 +1000

On 2003-06-30, Vijay Devarapalli wrote:
> can simplify FMIPv6 signaling.

So, Erik, what WG do you reckon it actually belongs in and how
can I go about convincing people to actually read it?

-----Nick

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 30 Jun 2003 16:19:44 -0700

> we get a practical handover protocol which will work in Starbucks :-)

Good applicability statement. If you don't wish to change the
router, run reactive with BU to the old router.

-Rajeev