[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A list of issues for RFC2462 update



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

> -----Original Message-----
> From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On 
> Behalf Of JinHyeock Choi
> Sent: Saturday, October 25, 2003 10:57 AM
> To: ipv6@ietf.org
> Subject: Re: A list of issues for RFC2462 update
> 
> 
> 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
躙XX*o'~٢+-b^笶m?0'~ffX)ߣ