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. [EMAIL PROTECTED]
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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
