Subject: Review Input: draft-jinchoi-ipv6-cra-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Oct 2003 15:59:10 -0400

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. 

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. 
    
   To detect its movement, an MN should check the (partial) reachability

   of the current AR and the validity of the current IP address. For 
   these, the information in Router Advertisement is essential. But, 
   based on current definitions [RFC 2461], the information contained in

   an RA is inadequate for efficient MD due to inconsistency and 
   incompleteness. 

I do not agree with this statement and believe all that is needed is in
the current RAs for what this draft is requesting (2461 + MIPv6).  In
fact it has been implemented and running in early adopter environments
right now with handhelds.

2. The RA Information Issues 
    
   In this chapter, we describe the problems we encountered while 
   working on Movement Detection and investigate the possible solutions.

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.

ALso MD today is based on Layer 1 and 2 information.  When a MN changes
its link it knows which RA is coming from which link I would postulate
in implementation.
    
   So if it happens that two different router interfaces have the same 
   link-local address, a host can't detect that it has moved from one 
   interface to another by checking the router address in RA messages.

The above needs to state two different links.  Routers are not compliant
to IPv6 if they duplicate link-local addresses on the same link.   
    
   On the other hand, a host can't be sure that its current default 
   router is reachable, even when it can communicate with the router, 
   which has the same address as its current router address. That router

   may be a different one, which, though highly unlikely, happens to 
   have the same link-local address as its current default router. 

Unclear what the above is trying to convey?  If the host can communicate
with a router on its link it is reachable?  If draft is speaking of a MN
the draft needs to say MN not just host, and that specifically if the
link-local address of the router on the new link for the MN is the same
then correct the MN would not know.  But, then these two routers are
being used for MIPv6 and should be using the RA ND extension per MIPv6 R
bit.  Problem solved.
    
   Heuristically, a host can use link-layer addresses in Neighbor cache.

   After link change, if the router address and link-layer address in 
   Neighbor Cache has not changed, i.e. a host can still communicate 
   with those addresses, it's reasonable for the host to assume that 
   current default router is still reachable.  

This is a good point the link-layer address is not the same as the
link-local address and we might want to note that a change in an RA of
the link-layer address could also be used for MD and we should at least
discuss this maybe in mipshop.  But that could be duplicated too.  But
it is a "hint".
  
   Reception of a Router Advertisement with the same on-link global 
   prefix (L=1) from the same router's link-local, may be considered an 
   authoritative indication that the router is still reachable. 

This is not possible in IPv6.  Compliant routers cannot duplicate IPv6
prefixes across multiple links which is why the R bit works. I assume
draft is speaking again about the MN moving to a new link and the draft
saying because the prefixes are the same that is a problem.  That is
what is not possible in a compliant IPv6 2461 network.
    
   Or a router can advertise its global address, by using Router Address

   (R) bit in the Prefix Information option. When set, R bit indicates 
   that the Prefix field contains a complete IP address assigned to the 
   sending router. With the RA with R bit set, a node can check whether 
   it can still hear from its current default router. 

Correct and my point above.

2.2 Omission of Prefix Information 
    
   To check the validity of its IP address, a host should see whether 
   the prefix of its IP address is advertised on the link to which it is

   currently attached. 

Well in so many words that is true but there are implementation
optimizations to avoid that check on every packet transmission as a note
:--) 
    
   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.
    
   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.
 
   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? 
    
   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?
    
   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.  

Both are administrative statements that can be made and suggested for
routers that support MN movement and thus why I feel this work should be
moved to mipshop and create a BCP to define the administration and use
of the new MIPv6 ND extensions.  But we need not add any more bits or
explanation to 2461.
    
   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. 

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.   
    
   It may useful to assign S bit, in the case where we want nodes to be 
   able to determine that they have received a solicited router 
   advertisement. With S bit, a node can confirm reachability with only 
   RS/ RA exchange. 

Same  comment as above.

2.4 Ambiguity of On-link information (L-bit)  
    
   Currently confusion is caused by the attempt to overload on-link 
   prefixes to mean some form of "link identifier". 

This is interpretation and we should make sure it is clear I think it is
very clear and have implemented this code and shipped a product.  So I
am really interested what is not clear.
    
   According to RFC 2461, on-link prefix means that this prefix can be 
   used for on-link determination. A node can send packets directly to 
   an address that falls in the on-link prefix without going through 
   default routers. Any two nodes with the addresses having the same on-
   link prefix can communicate each other at the link layer.

Just states a router is not needed and like prefixes are on link. Router
is not required.
    
   Also RFC 2461 allows the links without on-link prefixes, where all 
   packets would be sent to a default router. Thus as RFC 2461 is 
   designed, it is problematic for the on-link prefixes to be a link 
   identifier. 

This logic is not valid.  The premise does not support the conclusion.
When a link prefix is advertised all that is stated is that a node can
use this prefix for onlink determination.  Because an administrator does
not configure is the problem not ND 2461.
    
   Reception of an RA with the L bit set to zero does not make any 
   claims about the reachability of hosts on the current link. One of 
   the implications of the unset L bit is that the subnet may be 
   available through multiple interfaces on the same router, or through 
   multiple routers on different links.  
    
   One problem with RA message reception where the currently configured 
   prefix is L=0, is that it is impossible to distinguish between RAs 
   received from routers on different links, and L=0 Prefix 
   advertisements received from a different routers on the same link 
   link-local address on the same subnet, until bidirectional 
   reachability checks have been performed with the current router. 

This was and is not the purpose of the L bit set.  The above is not
necessary for this discussion or I am missing the point.
    
   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. 
    
   Even if address state (using DHC or otherwise) is maintained on a 
   router, no current specification requires that hosts re-DAD global 
   addresses while they remain within the subnet, even if routers
change.  
   This means that if a mobile host moves to another link within an IP 
   subnet (with L=0), the router may be unaware that the host has moved,

   and have inaccurate information about which link the hosts are on.  

It is not the job of the router to know what link a host is on.

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.

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.
    
   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.
    
   Moreover if an RA contains all the other options, for example link-
   layer address option, it will speed up movement detection. 

And that can be done per ND today.
    
   We propose to assign a new bit (Complete bit) in RA message to 
   indicate its completeness. When Complete bit is set, it means the RA 
   contains all the options (including all the Prefix Information 
   Options). 

This is non needed state in implementations and adds no value over what
exists currently.
    
   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.

thanks
/jim  

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

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sun, 26 Oct 2003 00:06:42 +0900

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.   

> ND to set RA R bit then I suggest that discussion be in mipshop WG where
 
Thanks for your advice. It was not clear to me which WG had mandate over this work. 

> Layer 2 can also note movement detection and more reliable and faster

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]     
> address in RAs.  But, there is a means and support to resolve this

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]  
> is not an ommission of 2461 but bad network configuration and planning

In case of multiple prefixes on a WIRELESS link, it may take too much bandwidth to 
advertise all the prefixes all the time.  
     
> routers supporting MNs into its network should use the R bit.  There is

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. 
  
>    Information Options, a host has no way to know it. There is no 

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

> 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. . 
     
> 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] 
> 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. 
 
> There is no reason for this design and the problem has been solved by

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.  
 
> Sure it does if the R bit is set for a router or L bit for host
     
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. 

> solution and it is not necessary.

IMHO, the purpose of R bit and Complete bit is different.  
     
[Omitted] 
> today and what is needed is to define a policy when all this must

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
1H>þ°¢¹"ž+¢êfj)bž	b²Ø©¿¨žµú+€fŠx¬¶¶Š÷‘z«ž²Û!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~â¦þ