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
LR¿¬(®H§‚
躙šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ 0Ö'~Šàþf¢–f§þX¬¶)ߣø©¿
