Subject: [Mip6] Re: A list of issues for RFC2462 update

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

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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

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