Hesham,
Do you anticipate that the changes in FMIPv6 for access routers will be in all
IPv6 routers?
jak
----- Original Message -----
From: "Hesham Soliman (EAB)" <[EMAIL PROTECTED]>
To: "'James Kempf'" <[EMAIL PROTECTED]>; "Bound, Jim" <[EMAIL PROTECTED]>;
"Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 29, 2002 10:08 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
>
> > 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.
>
> => The problem is there is no such thing as wireless access
> routers being bound to MIPv6 optimisations. The routers
> we have in IETF meetings are wireless, but there is no IP
> mobility going on.
>
> I think Jim's concerns (not you the other Jim :) ) can be
> handled because Fast RA and optimistic DAD do not change anything
> on the wire. In fact, Fast RAs have no impact on hosts at all.
> I agree with Jim Bound that you should mention how the
> designated router is known, but this can be done by
> manual config as a default mechanism.
>
> Optimistic DAD needs to be analysed carefully to make sure
> that the failure cases are rare and do not justify killing
> optimistic DAD. I think this analysus is ongoing.
>
> Hesham
>
> 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
> >
> > ----- Original Message -----
> > From: "Bound, Jim" <[EMAIL PROTECTED]>
> > To: "James Kempf" <[EMAIL PROTECTED]>; "Thomas Narten"
> > <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Tuesday, October 29, 2002 7:39 AM
> > Subject: RE: Changing RS Reply Timing for Mobile IPv6
> >
> >
> > > James,
> > >
> > > ........................................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]
> > >
> > >
> > >
> >
> > --------------------------------------------------------------------
> > 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]
--------------------------------------------------------------------
