Subject: A list of issues for RFC2462 update

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 17 Oct 2003 17:40:52 +0900

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-masked]

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 24 Oct 2003 11:24:08 +0900

Hello Vijay

I agreed with your mention and this issue is work in progress
at the DNA BOF. A second BOF will be scheduled during
this meeting.

For more reference, please look into this draft.
http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requiremen
t-01.txt

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Friday, October 24, 2003 10:12 AM
> To: [email-masked]; Soliman Hesham
> Cc: [email-masked]; [email-masked]
> Subject: [Mip6] Re: A list of issues for RFC2462 update
> 
> 
> hi,
> 
> 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
> solicitation for DAD and then 1 second before DAD completes. 
> the Binding Update cannot be sent until then.
> 
> > 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.
> > 
> > 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 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6
> 
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 27 Oct 2003 21:39:14 +0900

Dear JINMEI

It seems to me that the following issue needs further clarification. 

I think the prefix of L=0 and A=1  may cause an undetected address duplication.  
Because the currend DAD scheme uses NS/ NA exchange, which can't go over 
a router, a duplicate address may be configured on a separate link, when a router 
advertises a prefix with L = 0 and A = 1. 

Here is an example. Assume a router has two interface which are attached to two 
separate links. It assigns the same prefix A:: to them and advertises the Router 
Advertisement messages with the prefix A:: with L bit (on-link flag) off and A bit 
(autonomous address-configuration flag) on.

                                    +---------+
                         A::       |               |         A::
            ---------+-----+  Router  +-----+---------
                          |         |                |         |
                 A::1   |        +----------+        |  A::1
                          |                                    |
                   +---+---+                    +---+---+
                   | Host1   |                      | Host2  |
                   +-------+                     +-------+

Assume there is a host with address A::1 in the first link. Then another host arrives 
at the second link and forms an address with stateless address autoconfiguration. 
The second host happens to have 1 as its interface id and picks A::1 as its address. 
Then, even though the second host performs DAD, it can not detect the duplicate 
address on the first link. 

The current DAD scheme can guarantee the uniqueness of an address only inside
a link. It uses the Neighbor Solicitation/Neighbor Advertisement message exchange 
to detect duplicate address. Because the messages can't go over a router, DAD may 
not detect a duplicate address in an another link.

there is some discussion on this at Sec 2.4 of 
http://www.ietf.org/internet-drafts/draft-jinchoi-ipv6-cra-00.txt

Best regards

JinHyeockLR¿¬(®H§‚
èº™šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ø©¿