[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A list of issues for RFC2462 update



Vijay, 

Yes, this issue is the same as issue 11 for the 
RS. I'll add that to the list.

Thanks,
Hesham

 > -----Original Message-----
 > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]
 > Sent: Thursday, October 23, 2003 9:12 PM
 > To: jinmei@isl.rdc.toshiba.co.jp; Soliman Hesham
 > Cc: ipv6@ietf.org; mip6@ietf.org
 > Subject: Re: A list of issues for RFC2462 update
 > 
 > 
 > hi,
 > 
 > here is another issue. it involves both 2461 and 2462.
 > 
 > RFC 2461 says
 > 
 >     Before a host sends an initial solicitation, it SHOULD delay the
 >     transmission for a random amount of time between 0 and
 >     MAX_RTR_SOLICITATION_DELAY.
 > 
 > RFC 2462 says
 > 
 >     If the Neighbor Solicitation is the first message to be 
 > sent from an
 >     interface after interface (re)initialization, the node 
 > should delay
 >     sending the message by a random delay between 0 and
 >     MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].
 > 
 > lets assume a Mobile Node moves and attaches to a new
 > link. it does router discovery and configures a Care-of
 > address. the mobile node cannot send a Binding Update
 > until it completes DAD for the Care-of address. these
 > two random delays (before router discovery and before
 > DAD) contribute a lot to the movement detection delay.
 > I think this needs to be fixed.
 > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst
 > case scenario, it could be 1 second before a sending
 > router solicitation, one second before sending neighbor
 > solicitation for DAD and then 1 second before DAD
 > completes. the Binding Update cannot be sent until then.
 > 
 > we had a long discussion on the Mobile IP mailing list.
 > some argued that this needs to be done only when the
 > interface is initialized and not when the mobile node
 > attaches to a new link. others argued that this random
 > delay is essential to avoid a DAD storm if a bunch of
 > mobile nodes move at the same time.
 > 
 > there is some discussion on this at
 > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue230.txt
 > 
 > Vijay
 > 
 > 
 > JINMEI Tatuya / ???? wrote:
 > > Hello,
 > > 
 > > The attached below is a issue list to make necessary updates on
 > > RFC2462 (Stateless Address Autoconfiguration).
 > > 
 > > To make this list, I've grepped the ipngwg/ipv6 ML archives from
 > > Jan. 1998 with the keywords "2462" and "stateless," and picked up
 > > issues that seem to be related to this update.  Of course, I'm not
 > > claiming the keywords are enough, and even if they are, I may have
 > > missed something important.
 > > 
 > > Thus, any corrections/additions are welcome.  I'd 
 > apologize in advance
 > > the list is not necessarily very readable, but I believe 
 > it provides
 > > some hints to start discussion.  I'll collect comments on the list,
 > > and edit a new internet draft which will basically be a copy of
 > > RFC2462 with the issue list.
 > > 
 > > Due to a lack of time to the cut-off date of an initial draft, I
 > > don't think I can propose any resolutions to the issues.  
 > So, please
 > > concentrate, at the moment, on completing or correcting the list,
 > > rather than to discuss how to solve particular ones.
 > > 
 > > Thanks,
 > > 
 > > 					JINMEI, Tatuya
 > > 					Communication Platform Lab.
 > > 					Corporate R&D Center, 
 > Toshiba Corp.
 > > 					jinmei@isl.rdc.toshiba.co.jp
 > > 
 > > 
 > > Easy ones (which will only need some editorial works):
 > > 
 > > - A minor typo
 > >   by Ignatios Souvatzis, Dec. 1998
 > >   http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html
 > > 
 > > - Dead Code in Addrconf DOS Algortim Prevention
 > >   by Jim Bound, Nov 1998
 > >   http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html
 > > 
 > > - A corner case about inbound NA processing
 > >   by Richard Draves (via TAHI test), Jun 2000
 > > 
 > >   There was a consensus on the behavior, but the text is not clear.
 > >   Need to update.
 > > 
 > > - Unclear text about StoredLifetime
 > >   by jinmei, Aug 2001
 > >   http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html
 > > 
 > >   need to clarify the text.
 > > 
 > > ===
 > > 
 > > Issues that may require some discussion, but will not be 
 > very hard to
 > > get consensus:
 > > 
 > > - Source address selection issues wrt deprecated addresses
 > >   mainly by Richard Draves, several times.
 > >   e.g. which should be preferred between a deprecated address and
 > >   smaller-scope address?
 > > 
 > > - Deprecated address handling (the semantics of "new 
 > communication" is
 > >   not very clear)
 > >   by itojun, Nov 2000 and Aug 2002
 > > 
 > >   There seemed to be a consensus on a text proposed by 
 > Thomas Narten:
 > >   http://www.atm.tut.fi/list-archive/ipng/msg05182.html
 > > 
 > >   Erik Nordmark made a related point (what if an 
 > application specifies
 > >   a deprecated address as a source address):
 > >   http://www.atm.tut.fi/list-archive/ipng/msg05311.html
 > > 
 > >   There seemed to be no discussion on this, but we may need to
 > >   consider this as well.
 > > 
 > > - Semantics about the L=0 and A=1 case
 > >   by Fred Templin, Feb 2003
 > > 
 > >   Thomas Narten said he did not see the need for further
 > >   clarification (which I agree on):
 > >   http://www.atm.tut.fi/list-archive/ipng/msg07820.html
 > > 
 > > - Conflict with the MLD spec about random delay for the 
 > first packet
 > >   by Greg Daley, May 2005
 > >   http://www.atm.tut.fi/list-archive/ipng/msg09614.html
 > > 
 > > - Using stable storage for autoconfigured addresses
 > >   by Erik Nordmark, Jun 2002
 > >   http://www.atm.tut.fi/list-archive/ipng/msg04383.html
 > > 
 > >   There seemed to be no discussion on this.
 > > 
 > > ===
 > > 
 > > Issues that may be controversial:
 > > 
 > > - DAD related issues
 > >   inconsistency in the text (mixture of SHOULD and MAY)
 > >   by itojun, Jun 2001
 > > 
 > >   What about the link partitioning case
 > >   by Pekka Savola, Jun 2001(?)
 > > 
 > >   omitting DAD, DAD vs DIID, etc.
 > >   many people, many times
 > > 
 > > - Possible Denial of Service Attack
 > >   by Ken Powell, Feb 2002
 > >     What if a malicious node intentionally sends prefixes 
 > for other LANs?
 > >     There seemed to be no clear consensus.
 > > 
 > > - The semantics of the M/O flags
 > >   by several people, several times.  Points from Ralph Droms in Mar
 > >   2003 seems to be a good starting point:
 > >   http://www.atm.tut.fi/list-archive/ipng/msg03047.html
 > > 
 > >   a. the text needs to be updated to use RFC 2119 keywords
 > >   b. which keywords?
 > >   c. what is "the stateful configuration protocol"?
 > >   d. if the answer to "c" is DHCPv6, should RFC 2462 more
 > >      explicitly reference the configuration-only version
 > >      of DHCPv6 in the description of the 'O'flag?
 > > 
 > >   Adam Machalek also pointed out some inconsistency about mandatory
 > >   level of the stateful configuration protocol:
 > > 
 > >   http://www.atm.tut.fi/list-archive/ipng/msg04363.html
 > > 
 > > - Whether a (not a host) router can autoconfigure itself 
 > using RFC2462
 > >   (or bis) including
 > >     if a router can configure a global address by 
 > stateless autoconf
 > >     if a router can configure a link-local address in a 
 > way described
 > >     in RFC 2462
 > >     if a router can configure itself about "other" configuration
 > >     information
 > > 
 > >   by several people, several times
 > > 
 > > - If we need a 'not-yet-ready' status of an autoconfigured 
 > address to
 > >   help renumbering operation
 > >   by Fred Baker, Apr 2003
 > >   http://www.atm.tut.fi/list-archive/ipng/msg09394.html
 > > 
 > > - Avoiding interface failure upon DAD failure
 > >   (mainly) by Jari Arkko, May 2003
 > >   related to mip6.  (the latest draft leaves this as "ND 
 > extensions")
 > > 
 > > - If RFC2462 requires 64bit IFID
 > >   by several people, several times.
 > > 
 > > - Issues raised in the send requirement draft.
 > >   (Sorry, I've not gone through the send requirement 
 > draft.  So there
 > >   may or may not be issues from the draft that need to be 
 > added here)
 > > 
 > > 
 > --------------------------------------------------------------------
 > > IETF IPv6 working group mailing list
 > > ipv6@ietf.org
 > > Administrative Requests: 
https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------