James, Have you actually tested this with implementation? Or is this theoretical debate?
Thanks /jim -----Original Message----- From: James Kempf [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 5:40 PM To: Brett Pentland; Thomas Narten Cc: [EMAIL PROTECTED] 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 PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
