Subject: RE: Changing RS Reply Timing for Mobile IPv6

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 9 Oct 2002 13:01:50 -0500

I'm not sure that we are loosening that.  The rest of the quoted 
 paragraph reads:
 
   "If a host has already performed
    a random delay since the interface became (re)enabled (e.g., as part
    of Duplicate Address Detection [ADDRCONF]) there is no need to delay
    again before sending the first Router Solicitation message."
 
 I took the paragraph as meaning that the RS should be delayed when the 
 host first comes up to avoid synchronization with other devices after 
 some abnormal event, but that movement is part of normal operation, 
 not expected to be synchronized with other hosts and so the delay is 
 not required.  Any thoughts?

You are right

---

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

James,

Thanks.  I will ask our folks to do the same and see if we see the same.
Will take me some time.

/jim

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2002 10:41 AM
To: Bound, Jim; Brett Pentland; Thomas Narten
Cc: [email-masked]
Subject: Re: Changing RS Reply Timing for Mobile IPv6 

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

> 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: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 15:27:57 -0500

Hi James,

Amazing Brian Haley and I were just talking this a.m. as this concerns
our worrk to.  We like what you and Optimistic DAD propose but we also
are responsible for these "wired" boxes.  That is what we concluded too.
We can't see a case where an 802.11b AP is just another interface to a
wired-link but will be its own link.  So I think that is a good idea.
And will avoid the entire problem I sent and to Nick privately on the
Optimistic DAD (which I think adds great value to the FastRA reqs too).

thanks

/jim
[Have you ever seen the rain coming down on a sunny day]

> Sent: Tuesday, October 29, 2002 12:39 PM
> To: Bound, Jim; Thomas Narten
> Hi Jim,
> I hear your concerns quite clearly.
> 
> One possibility would be to make the FastRA and Optimistic 
> DAD work specific to MIPv6 wireless access routers, and 
> therefore not a general IPv6 router enhancement. I think this 
> would address your concern about impacting current wired 
> router product plans. It really is only for mobility, as a 
> wired host rarely to never changes its link.
> 
> That would move the work to the MIP group, as a separate but 
> complementary item to the current FMIPv6 work. The optimized 
> MIPv6 work is still not quite ready for prime time, but it is 
> getting there. Of course, this would require approval of the 
> ADs, MIP WG chairs, and MIP WG.
> 
> How does that sound?
> 
>             jak
> 
> To: "James Kempf" <[email-masked]>; "Thomas Narten" 
> <[email-masked]>
> Sent: Tuesday, October 29, 2002 7:39 AM
> >    ........................................Determination of
> >    how this router is designated is outside the scope of this
> >    document. An RA that is immediately unicast to the sender rather
> >    than delayed is known as a "fast RA".
> >
> > I do not believe it should be outside the scope of this draft.  I 
> > think it imperative that this be defined clearly and a 
> method proposed 
> > before FAST RA can be bought into by IPv6 implementors.
> >
> > I also believe at this time the IESG should require a 
> fairly good set 
> > of reports from multiple implementations of this and other 
> proposals 
> > for wireless efforts that want to change DAD parameters and extend 
> > attributes to ND and Stateless Addrconf.  Right now the only work 
> > within this space that has received the test of fire at 
> UNH, ETSI, or 
> > TAHI as examples is MIPv6.  These tests beat hard on IPv6 
> > implementation enhancements as was just done for MIPv6 D-18 
> in Sophia 
> > Antipolis at ETSI.  I would suggest to the IESG doing any 
> changes to 
> > ND or Addrconf without serious hard core testing from this work is 
> > dangerous.
> >
> > If you, I, and others believe this is important then the 
> code will get 
> > done for this and Optimistic DAD and show up at the tests.  
> Otherwise 
> > this is purely a research and at best AD exercise.  IPv6 is 
> now being 
> > deployed we cannot mess with DAD or Addr Conf in casual 
> ways any more 
> > than we do with IP (for v4), TCP, or RTT algrorithm for TCP as 
> > examples.
> >
> > I also believe all these efforts should begin to think like 
> MIPv6 has 
> > and that is they are separate documents and I strongly am 
> against any 
> > enhancments to ND or Addrconf from Fast RA, Optimistic DAD 
> etc.  They 
> > should be new RFCs.
> >
> > All this also presents new security problems too that does 
> not exist 
> > in current ND and Addrconf on wired links.  The base reason is that 
> > these mess with the ND architecture and wired links that are 
> > firewalled or PKI protected are more insulated than say 
> 802.11b. That 
> > being said I would like to see all security sections for this work 
> > define what new security problems exist simply because of this 
> > behavior not just say exists now in DAD or whatever.
> >
> > None of these options should be permitted for wire links 
> (status quo) 
> > at all. That gives me an idea at least how the router to do Fast RA 
> > should be defined.
> >
> > I would also like to see hard core router or switch "PRODUCT" 
> > developers comment on this work and other work.  I know 
> routing code 
> > but not like those that build ASICs and the like. I would 
> like to hear 
> > them say the pain and gain they feel or see from this strategy.
> >
> > /jim
> > [Have you ever seen the rain coming down on a sunny day]
> >
> >
> >
> 
>