Subject: Re: A list of issues for RFC2462 update

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 04 Nov 2003 11:09:31 +0900

>>>>> On Thu, 23 Oct 2003 18:11:55 -0700, 
>>>>> Vijay Devarapalli <[email-masked]> said:

> 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.

Thanks for the pointer.  I'll add this to my local issue list.

(Note to everyone: this does not mean I'm going to propose a change on
RFC2462 to address this.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 4 Nov 2003 08:52:10 -0800

> solicitation 
> > for DAD and then 1 second before DAD completes. the Binding Update 
> > cannot be sent until then.

Please re-read the above RFC-2462 requirement closely:
"If the Neighbor Solicitation is the first message to be sent from an
interface after interface (re)initialization..."

The DAD NS in this case is *NOT* the first message to be sent, the RS
is. Therefore, you do not need the random delay prior to sending the DAD
NS in this case. The same random delay before sending the RS can apply
to the DAD NS (because it is sent after the RS).

That's the way we implement it currently, and it causes us to fail a
couple of TAHI tests :-( but we believe we are 100% compliant with the
RFCs w/ regards to implementing it this way.

Thanks.
- Ed Remmell
Elmic Systems, USA

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 10 Nov 2003 14:31:17 +0900

>>>>> On Fri, 17 Oct 2003 17:40:52 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> 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

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.