>>>>> On Fri, 17 Oct 2003 17:40:52 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> The attached below is a issue list to make necessary updates on
> RFC2462 (Stateless Address Autoconfiguration).
I've slightly revised the list mainly based on comments received so
far. (Some URLs do not seem to be available...sorry about that)
I'm going to propose how to address (or not address) the issues in
separate threads. A general rule (as I understood it) is:
- changes should basically be clarifications or obvious bug fixes
- do not break compatibility with existing implementations
- do not introduce new features
Of course, some issues may still be controversial in terms of the
basic rule. We'll discuss such issues later to get a consensus.
Thanks,
p.s. if I clearly missed something that was commented on the list or
privately, please let me know.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
Easy ones (which will only need some editorial works):
1. A minor typo
by Ignatios Souvatzis, Dec. 1998
http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html
(already fixed in rfc2462bis-00)
2. Dead Code in Addrconf DOS Algortim Prevention
by Jim Bound, Nov 1998
http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html
3. 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.
4. Unclear text about StoredLifetime
by jinmei, Aug 2001
http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html
need to clarify the text.
5. Remove references to site-local addresses
===
Issues that may require some discussion, but will not be very hard to
get consensus:
6. 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?
7. 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
8. 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
9. 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.
Erik thought "it is quite reasoanble that implementations that have
stable storage retain their addresses and expiry times (preferred
and valid) whether the addresses were acquired using RFC 2462 or DHCP."
11. IEEE 802.11 devices do not meet a requirement described in RFC2462
As pointed out in draft-park-ipv6-dad-problem-wlan-00.txt
===
Issues that may be controversial:
12. 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
The first NS for a DAD is usually not the first packet from the
sending node, since an MLD report should usually sent before the NS.
13. 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, various delays in DAD, etc.
many people, many times
14. Possible Denial of Service Attack
by Ken Powell, Feb 2000
What if a malicious node intentionally sends prefixes for other LANs?
It kills communication from the attacked link to the other LAN.
There seemed to be no clear consensus.
(The SEND req draft does not seem to talk about this issue.)
15. 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
We have three occurrences in RFC2462 related to this issue. The
first two do not have RFC2119 keywords:
- Section 4 (PROTOCOL OVERVIEW)
a managed address configuration flag indicates whether hosts should
use stateful autoconfiguration
- Section 5.2 (Autoconfiguration-Related Variables)
(M flag)
The flag indicates whether or not addresses are to be configured
using the stateful autoconfiguration mechanism.
(O flag)
The flag indicates whether or not information other than addresses
is to be obtained using the stateful autoconfiguration mechanism.
- Section 5.5.2 (Absence of Router Advertisements)
If a link has no routers, a host MUST attempt to use stateful
autoconfiguration to obtain addresses and other configuration
information.
16. 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
17. 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
18. Avoiding interface failure upon DAD failure
(mainly) by Jari Arkko, May 2003
RFC2462 says in Section 5.4.5 (When Duplicate Address Detection
Fails) that:
A tentative address that is determined to be a duplicate as described
above, MUST NOT be assigned to an interface and the node SHOULD log a
system management error. If the address is a link-local address
formed from an interface identifier, the interface SHOULD be
disabled.
Jari pointed out the latter requirement may be too strong. However,
the latest mip6 draft leaves this as "ND extensions".
draft-ietf-mobileip-ipv6-24.txt says in B.6 (Neighbor Discovery
Extensions) that:
For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be useful
for link-local, care-of, and home addresses.
19. If RFC2462 requires 64bit IFID
by several people, several times.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
