Subject: RE: A list of issues for RFC2462 update

From: Soliman Hesham <[email-masked]>
Date: Thu, 23 Oct 2003 22:12:46 -0400

Vijay, 

Yes, this issue is the same as issue 11 for the 
RS. I'll add that to the list.

Thanks,
Hesham

 > -----Original Message-----
 > From: Vijay Devarapalli [mailto:[email-masked]]
 > Sent: Thursday, October 23, 2003 9:12 PM
 > To: [email-masked]; Soliman Hesham
 > Cc: [email-masked]; [email-masked]
 > Subject: 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.
 > > 					[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
> --------------------------------------------------------------------

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 25 Oct 2003 14:51:59 -0400

Dear JinHyeock,

I will go offline with you as I think we need to deep dive technically and it will take many emails for you and I to parse this via email is my guess.  Given the IETF ADs and Chairs wish to reduce email flow and on our members mail inboxes I suggest we go offline and technicallly work out our disconnects and assumptions about MD requirements for RAs.  Then come back to the IPv6 WG when we are done with the results. As we are both implementors this will be a very useful discussion and integration of our views. As a note the DNA BOF is very important I agree, I will be there if I am alive at that time.

Respectfully,
/jim

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JinHyeock Choi
> Sent: Saturday, October 25, 2003 10:57 AM
> To: [email-masked]
> Dear Jim
> Thanks for your detailed comments.
> 
> I may not be clear enough. This I-D assumes the scenario of a 
> host moving from one link 
> to another. In many cases, the term 'a host/node' is actually 'an MN'.
> 
> Kindly find my in line comments.   
> 
> > Comments on this draft.  I am unclear but it may be this 
> work needs to 
> > be done in the mipshop WG within the Internet Area as I believe all 
> > that is required to resolve the problem statement in this draft is 
> > policy to use the current ND 2461 mechanisms and the extended ND 
> > mechanisms in MIPv6.  As the WG may realize I do not 
> support merging 
> > MIPv6 ND changes back into to RFC 2461 so do not see need 
> for that.  
> > If this spec is to define and clarify the policy for use of the new 
> > prefix option in MIPv6 ND to set RA R bit then I suggest that 
> > discussion be in mipshop WG where that is their focus.
>  
> Thanks for your advice. It was not clear to me which WG had 
> mandate over this work. 
> 
> > 1. Introduction
> >     
> >    Movement detection (MD) is one of a series of stages in 
> > accomplishing
> > 
> >    MIPv6 handover. As defined in the MIPv6 specification [MIPv6], 
> >    detection of movement is accomplished through reception 
> of Router 
> >    Advertisements (RAs) and Neighbor Advertisements (NAs), and 
> >    comparison of these messages with previously received router 
> >    information.
> > 
> > Layer 2 can also note movement detection and more reliable 
> and faster 
> > today.
> 
> Layer 2 can only detect Link layer change. Layer 2 may act as 
> a hint but can't confirm 
> movement. For example, layer 2 by itself can't check the 
> (partial) reachability of current 
> default router.  
>   
> [Omitted]     
> > 2.1 Link local scope of Router Address
> >  
> >    The router address contained in an RA message is 
> link-local scope. 
> >    Neighbor Discovery [RFC 2461] only advertises a router's 
> link-local 
> >    address, by requiring this address to be used as the IP Source 
> >    Address of each Router Advertisement. Hence its 
> uniqueness can't be 
> >    guaranteed outside of a link-instance.
> > 
> > This is not true if the R bit is set then the full IP address is 
> > available and why it was put as option in MIPv6.  But, for 
> most nodes 
> > on a link the default is that routers do not need to supply 
> the full 
> > IP address in RAs.  But, there is a means and support to 
> resolve this 
> > problem for Mobility.
> 
> I agree that R bit can solve this issue but the above part is 
> to describe the problems. 
> You present the solution too early. :-)  
>  
> [Omitted]  
> >    For this, a host checks whether the prefix of its IP 
> address is in 
> >    the Prefix Information Option of Router Advertisement 
> messages. But 
> >    an unsolicited Router Advertisement message can omit 
> some prefixes 
> >    for convenience, for example to save the bandwidth.
> > 
> > Then that network will suffer and if the nodes require 
> those prefixes 
> > it is not an ommission of 2461 but bad network configuration and 
> > planning by the user.
> 
> In case of multiple prefixes on a WIRELESS link, it may take 
> too much bandwidth to 
> advertise all the prefixes all the time.  
>      
> >    So, checking the prefixes in an RA, an MN may make false 
> assumption 
> >    that the prefix of its current IP address is not 
> supported in a new 
> >    link, while that prefix is just omitted in that particular RA.
> > 
> > But this is not the fault of 2461 and the R bit works when used and 
> > routers supporting MNs into its network should use the R 
> bit.  There 
> > is no problem.
> 
> R bit by itself can't solve this problem. After Movement, if 
> an MN can still hear its 
> current default router (confirmed with R bit), it can assume 
> that its CoA is still valid. 
> But if an MN doesn't hear its current default router, MN is 
> in a trouble described 
> above. 
>   
> >    Moreover, even though a RA message contains all the Prefix 
> >    Information Options, a host has no way to know it. There is no 
> >    indication.
> > 
> > Why?  Sure they do?
> 
> When a RA arrives, an MN can't be sure that it contains all 
> the prefixes. There always is 
> a possibility that a prefix may be omitted in this particular RA. 
>      
> >    Hence, a host can't be sure that the prefix of its current IP 
> > address
> > 
> >    is not supported on the current link, even though the 
> prefix is not 
> >    contained in an RA message.
> > 
> > There are clear administration rules for MN support for ND 
> and MIPv6 
> > Extensions to ND. The problem is do we not feel MIPv6 
> documented these 
> > well enough or not?
> >     
> >    The problem is 1) an RA may omit some Prefix Information 
> Options and 
> >    2) even it has all the Prefix Information Options, there is no 
> >    indication that it does.
> > 
> > I cannot parse the conclusion for 2) at all?
> 
> As I described above, there is no indication in a RA which 
> notifies this RA contains all the 
> prefixes. 
> 
> >    The possible solution for the above is the RA with  
> >    1) All the Prefix Information Options and  
> >    2) The indication that it contains all the Prefix Information 
> >       Options.
> > 
> >    For 2), we may define a new bit in an RA message. We 
> will give more 
> >    detail in 3.1.
> > 
> > This is not necessary and has been resolved by MIPv6.
>     
> Actually mobileip WG doesn't feel that MD is under its work 
> scope either. A new WG, 
> DNA, currently BoF, will do this. . 
>      
> > 2.3 Lack of Solicitation Acknowledgement
> >     
> >    In Router Advertisement messages, there is no 
> solicitation bit, as 
> > in
> > 
> >    Neighbor Advertisement. So when a node receives a RA, it 
> can's be 
> >    sure it's the reply to its Router Solicitation. To confirm bi-
> >    directional reachability, an additional NS/ NA exchange is 
> > mandatory.
> > 
> > Do not agree.  When a node gets an RA it then begins 
> communication.  
> > If that communications fails then the router is down and must be 
> > retried or must locate another router.  The IPv6 
> architecture did not 
> > implement such reacability with routers for a good reason 
> and that is to support
> > reduced discovery messages and bandwidth on an IPv6 link.   
> 
> Correct me if wrong. But RFC 2461 mandates hosts to confirm 
> reachability with its default 
> router. After movement, hosts have to confirm reachability 
> and it entails NS/ NA exchange.
>      
> [Omitted] 
> >    According to [RFC 2461], a router may advertise prefixes 
> with L=0 
> > and
> > 
> >    A=1. This implies that stateless address autoconfiguration is 
> > allowed
> > 
> >    for these prefixes [RFC 2462]. It is possible to show 
> that in the 
> >    absence of Address State on routers or ND proxying, duplicate 
> >    addresses may be configured for a global address, when 
> an address 
> >    owner exists on another link of the same subnet.
> > 
> > This is point the draft missed early on.  Routers cannot 
> provide same 
> > prefixes to two separate links.
> 
> This point we'd better clarify. I think that Routers can 
> provide the same prefix to two separate 
> links when L bit if off. Kindly check the following example. 
> 
> A router has two interfaces to which two separate link are 
> attached. For those interfaces, the 
> router advertise the same prefix A:: with L bit off. There is 
> nothing in RFC 2461 which bans this. 
> 
>                           ____
>                          |        |
>                          |   R   |________________ 
>                          |____|            A::
>                              |
>                              |  A::
>                              |
>       
> I think that the usage of the prefix with L bit off is a 
> little ambiguous. We'd better clarify it. 
>  
> > 3. RA Optimized for Movement Detection
> >     
> >    Our goal is to design an RA in such a way that an MN can 
> detect its 
> >    movement efficiently, quickly and precisely with as 
> little signaling 
> >    as possible. As described above, the information contained in a 
> >    current RA message is inconsistent and incomplete for movement 
> >    detection. The following proposals seek to facilitate efficient 
> >    movement detection by including all the necessary 
> information in an 
> >    RA message.
> > 
> > There is no reason for this design and the problem has been 
> solved by 
> > MIPv6.
> 
> Unfortunately this problem has not solved by MIPv6. Neither 
> MIP6 WG is to work on it. 
> DNA is to design a solution and, I think, this is a part of it.  
>  
> > 3.1 Complete RA
> >     
> >    Since routers may neglect to send all prefixes in every 
> > advertisement,
> >    it is difficult for an MN to determine whether it is 
> attached to a 
> >    different subnet, when an RA received without its currently 
> >    configured prefix.
> >     
> >    Even though an RA contains all the Prefixes, an MN has no way to 
> > know
> > 
> >    it. There is no indication. So still ambiguity remains.
> >  
> > Sure it does if the R bit is set for a router or L bit for host 
> > notification.
>      
> We have a disagreement here. R bit and L bit talk only about 
> just one prefix. They don't say 
> anything about the collection of all prefixes. I don't know 
> how, with L and R bit, an MN can 
> be sure a particular RA contains all the prefixes. 
> 
> >    If a router is able to send an indication that the RA it sends 
> >    contains all of the valid prefixes for a link-instance, then 
> >    reception of an RA which contains a different set of prefixes 
> >    indicates the presence of a different subnet.
> > 
> > This is to much overhead and the R bit already does this far better 
> > and why MIPv6 WG converged on the support of this new prefix option 
> > and why the IPv6 WG supported the change.  This draft is trying to 
> > reinvent that solution and it is not necessary.
> 
> IMHO, the purpose of R bit and Complete bit is different.  
>      
> [Omitted] 
> >    For efficient Movement Detection, we propose a RA with  
> >    1) AR's global IP address using R bit  
> >    2) All the options (including all the Prefix Information 
> Options) 
> >    3) The indication that it has all the options (Complete bit) 
> >    4) S bit (Solicitation bit) to confirm reachability 
> without NS/ NA 
> >       exchange
> > 
> > I don't agree with the reachability suggestion but all the others 
> > exist today and what is needed is to define a policy when all this 
> > must execute.
> 
> There is nothing for 3), to indicate the completeness of a RA.  
> 
> Another thanks for your detailed and helpful comments. It 
> clarifies my thoughts. 
> 
> Best regards
> 
> JinHyeock
> 
>   ÂŠ®™ŠŠ¦z®š²¶Ez†³Ãz®jjŠŠ
> 
LR��(�H��
躙��X��X��*o�'�~��٢�+-��b��^�笶�m��?�0�'�~���f��f��X��)ߣ���