Subject: RE: Changing RS Reply Timing for Mobile IPv6

From: "Bound, Jim" <[email-masked]>
Date: Wed, 16 Oct 2002 11:19:56 -0400

James,

Have you actually tested this with implementation?  Or is this
theoretical debate?

Thanks
/jim

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, October 15, 2002 5:40 PM
To: Brett Pentland; Thomas Narten
Cc: [email-masked]
Subject: Re: Changing RS Reply Timing for Mobile IPv6 

Thomas,

> Seems to me then that this document is a bit narrowly scoped and may 
> even miss the point. Don't we need to look at the overall problem and 
> then see what can be done to address the overall problem adequately? 
> In general, I don't know that its all that useful to focus on a narrow

> part of a bigger problem unless the bigger problem is sufficiently 
> understood that the point solution is understood to be an important 
> and useful component of it.  How do we know that this change will make

> any significant difference in practice given the general problem?
>

You are right that this document is fairly narrowly scoped. To solve the
full problem, it requires other parts of the ND process, specifically
DAD, to be accelerated as well. Additionally, as was brought up on the
list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As
was also brought up on the list, this can lead to congestion when mobile
nodes move in concert, or when an access point crashes.

The FMIPv6 work is certainly a more comprehensive solution, however, the
currently understanding of how FMIPv6 would work together with 802.11 is
not encouraging. There is, of course, an argument about how much the
IETF should modify its specifications to be implementable on a specific
link layer. However, for  802.11 to work well with FMIP, there would
either need to be a major change in the current firmware implementations
for anticipated handover, or an additional protocol would be needed
between the AP and the AR for conveying the reassociation link up
trigger to the AR, or some special kind of security association would be
required between the old AR and the MN in order to do unsolicited FBU
signaling from the AR to the MN. The IETF can do some work on the last
two of these but the first one is entirely controlled by the IEEE and,
worse, by card manufacturers who may or may not implement given that
IEEE has no standard.

So the deployment alternative with ND as defined in RFC 2461 and the
base FMIPv6 document if one wants faster 802.11 handovers is to set
MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero.
Near term, this is likely to be what people do. With this deployment,
not only could the above two problems with congestion occur, but the
router is now subject to DoS attacks. The advantage of the proposal in
draft-khalil-ipng-fastra-00.txt is that the authors believe it would
reduce the potential for DoS attacks.

Whether or not this is enough of an improvement over the RS reply
algorithm as defined by RFC 2461 to standardize, is something for WG and
the IESG to decide.

            jak

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Oct 2002 08:40:50 -0700

Jim,

We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses
the 802.11 reassociate for a link up trigger to cause the RS. There is a
substantial decrease in packet loss, on the order of the router beacon. This
requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We
have not implemented the optimization described in the draft yet.

            jak

----- Original Message -----
From: "Bound, Jim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Brett Pentland"
<[email-masked]>; "Thomas Narten" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 16, 2002 8:19 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6

---

From: "Richard Nelson" <[email-masked]>
Date: Thu, 17 Oct 2002 20:46:33 +1000

We have implemented and tested it.  Greg Daley was modifying radvd for hmip
so he added this as well.  We have combined it with link layer signalling to
trigger router solicitations (Nick and Bretts work).  The combination of
HMIP, triggered RS, fast RA and HMIP is very effective in an 802.11
environment L3 handover is much shorter than L2.  In the absence of fast
handover support we think this is a good solution.   We will be publishing
test results soon although we could put some preliminary ones up on a
website if anybody wanted to see them.

Richard.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Bound, Jim" <[email-masked]>; "Brett Pentland"
<[email-masked]>; "Thomas Narten" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 17, 2002 1:40 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6