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