[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA-BOF] RE: [Mip6] Re: A list of issues for RFC2462 update
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: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org] On
> Behalf Of Vijay Devarapalli
> Sent: Friday, October 24, 2003 10:12 AM
> To: jinmei@isl.rdc.toshiba.co.jp; Soliman Hesham
> Cc: ipv6@ietf.org; mip6@ietf.org
> Subject: [Mip6] Re: A list of issues for RFC2462 update
>
>
> 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.
> > jinmei@isl.rdc.toshiba.co.jp
> >
> >
> > 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
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www.ietf.org/mailman/listinfo/mip6
>
>