[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A list of issues for RFC2462 update
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.
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
Easy ones (which will only need some editorial works):
- A minor typo
by Ignatios Souvatzis, Dec. 1998
- Dead Code in Addrconf DOS Algortim Prevention
by Jim Bound, Nov 1998
- 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
need to clarify the text.
Issues that may require some discussion, but will not be very hard to
- Source address selection issues wrt deprecated addresses
mainly by Richard Draves, several times.
e.g. which should be preferred between a deprecated address and
- 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:
Erik Nordmark made a related point (what if an application specifies
a deprecated address as a source address):
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):
- Conflict with the MLD spec about random delay for the first packet
by Greg Daley, May 2005
- Using stable storage for autoconfigured addresses
by Erik Nordmark, Jun 2002
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:
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:
- 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
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
- 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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6