Ed Remmell writes: I've noted a general sloppiness in draft 19
regarding how the MN should handle the scenario of overlapping
coverage areas, specifically how to go about selecting the primary CoA
in this scenario. This also applies to other scenarios which
approximate the L3 behavior of the MN being attached to multiple IPv6
links simultaneously.

Recommended solution:

Section 11.5.2 says the right thing, but is incomplete:
"After detecting that it has moved from one link to another (i.e., its
current default router has become unreachable and it has discovered a new
default router), a mobile node SHOULD form a new primary care-of address
using one of the on-link subnet prefixes advertised by the new router."

Section 11.5.1 also says the right thing, again incomplete:
"For example, a mobile node MAY use signal strength or signal quality
information (with suitable hysteresis) for its link with the available
routers to decide when to switch to a new primary care-of address using that
router rather than its current default router (and current primary care-of
address)."

However, the following wording should be removed from section 11.5.3,
because it is misleading:
"A mobile node SHOULD select a primary care-of address from among those
care-of addresses it has formed using any of these subnet prefixes, based on
the movement detection mechanism in use, as described in Section 11.5.1."

This should be replaced with a new requirement, which can either go in
section 11.5.2 or section 11.5.3:
"The MN MUST ensure that its primary care-of address always has a prefix
that is considered on-link by its current default router (i.e., advertised
by its current default router in a solicited Router Advertisement); this may
require the MN to either change its primary care-of address and/or its
current default router."

Those are the important modifications that I think really need to be made to
this draft. Here are some additional changes that could be made to provide
additional guidance to implementors:

New requirements text, add to section 11.5.3:
"Whenever a MN determines that it is no longer reachable through a given
link, it SHOULD invalidate all care-of addresses associated with address
prefixes that it discovered from routers on the unreachable link which are
not in the current set of address prefixes advertised by the (possibly new)
current default router."

"The MN MAY choose to restrict auto-configuration of care-of addresses to
use only those prefixes it discovers by receiving Router Advertisements from
the current default router."

Justification:

On a given physical link there may be overlapping subnets, each with their
own router(s). Per RFC-2461, section 6.2.7.  Router Advertisement
Consistency:
"Note that it is not an error for different routers <on the same link> to
advertise different sets of prefixes."

This is similar to the "Overlapping RF Coverage Areas" scenario, i.e. it
could be possible (although undesirable) for two RF link layers to be on the
same channel and received by the same MN simultaneously (or, if insufficient
L2 triggers are provided, it might appear that way to L3, i.e. the
ping-ponging case).

This "Overlapping RF Coverage Areas" scenario is even mentioned in draft 19
section 11.5.2 as a seemingly acceptable situation:
"Furthermore, since a wireless network interface may actually allow a mobile
node to be reachable on more than one link at a time (i.e., within wireless
transmitter range of routers on more than one separate link), a mobile node
MAY have care-of addresses on more than one link at a time."

It seems to me like there are two problems in draft 19, not explicit
problems per se, but lack of detail and suggestions of how to do things
(i.e. auto-configure as many CoAs as you want, on as many overlapping links
as you want, it doesn't matter what link the prefixes that you use to
auto-configure CoAs come from, just pick any old one and use it as your
primary CoA) that can be misleading:

1) It does matter where the CoAs come from, and more importantly where your
primary CoA came from. This is because when you move to a new link that
doesn't advertise those prefixes, you want to invalidate all of the CoAs
that you previously auto-configured that have the old prefixes which are not
advertised by the new default router. This isn't really discussed in draft
19.

2) The overlapping RF coverage areas scenario is very misleading - you may
only be able to hear some of those other routers on those other links, you
may not actually be able to transmit successfully to them. Just because you
can hear any old router, you don't want to necessarily be auto-configuring
CoAs from the prefixes that it advertises, because you may not be able to
transmit successfully on that link. I'm assuming the scenario of overlapping
RF coverage areas here, which means you can hear/receive on multiple links
simultaneously, but that doesn't mean that you can successfully transmit on
all of those links.

Section 6.2.3 of RFC-2461 additionally says:
"However, when responding to a Router Solicitation or while sending the
first few initial unsolicited advertisements, a router SHOULD include all
options so that all information (e.g., prefixes) is propagated quickly
during system initialization."
This says that to ensure you get a complete set of subnet prefixes from a
router, you must solicit the router. An unsolicited RA may not contain the
complete set, but a solicited RA should.

So, what I want to handle is the case where the MN has its interface
attached to functionally two different IPv6 links/subnets at the same time
(or at least it appears that way to L3). According to RFC-2461, when I
solicit the router with a RS, the solicited RA should contain the complete
set of subnet prefixes that that router supports for this link. What if
there is another router that appears to be (or even is) on the same link
which broadcasts an entirely different set of prefixes? According to
RFC-2461, this is not an error, so then I must handle it. According to draft
19, this situation may happen due to overlapping RF coverage areas, which is
treated as an acceptable situation.

The MN could get pretty confused, if it has auto-configured a primary CoA
belonging to a router which isn't its current default router and which isn't
on the same link (anymore, although it appeared to be for awhile), since it
isn't going to necessarily know to invalidate that CoA and then pick a new
primary CoA. Perhaps the solution is obvious to all of the MN implementors
out there but I would have liked to have seen more detail about this in the
specification. For example, there is no requirement on the MN or hint in the
specification that says that when the MN switches to a new default router,
any prefix that it auto-configured using the old default router now needs to
be invalidated if it isn't in the full set of prefixes advertised in the
solicited RA sent by the new default router when it is solicited by the MN.
That is part of what I was missing.

---------------------

Ed Remmell adds: I'm somewhat surprised I didn't get any response to
this (but then I am the impatient type...). Perhaps it is difficult to
understand what the problem really is.

From the justification section of this problem report: "The MN could
get pretty confused, if it has auto-configured a primary CoA belonging
to a router which isn't its current default router and which isn't on
the same link (anymore, although it appeared to be for awhile), since
it isn't going to necessarily know to invalidate that CoA and then
pick a new primary CoA."

There is a big problem if this occurs: if the MN is using a primary CoA that
is no longer on-link, it will never receive packets sent to that primary
CoA. The only way to guarantee that the primary CoA is on-link is to
syncronize it with the current default router (which you are monitoring for
your move detection, i.e. bi-directional reachability confirmation of your
current default router means that you are still on-link and haven't moved),
which is what my proposed requirements changes ensure happens.

There can also be a problem due to ingress filtering if you try to use a
primary CoA to send packets through your current default router if the
prefix of that primary CoA isn't one of the prefixes advertised by that
current default router; this could cause your current default router to drop
all packets that you send with that source address.

Also, this is relevant to some of the stuff I've been seeing about source
address selection w/ regards to Mobile IPv6. You want to be certain that if
you use a CoA, it comes from a router that is currently bi-directionally
reachable. The only router that you must monitor to confirm bi-directional
reachability (per draft 19) is the current default router, all other routers
are suspect. Just because you can hear some other router's transmissions
because it might be on the same link or on an overlapping link (i.e.
overlapping coverage areas, or ping-ponging), doesn't mean that it can hear
your transmissions, i.e. does not guarantee bi-directional reachability.
Lots of weird things happen with RF, it is messy. Being able to
auto-configure lots of different CoAs from lots of different overlapping
links that you appear to be simultaneously attached to is not a bonus, it is
downright scary actually, because lots of things can go wrong if you aren't
careful. Personally, I'm happy just to stick with using a single primary CoA
for everything, and keeping that primary CoA in sync with whomever my
current default router is at the time by making sure that the prefix of my
primary CoA matches one of the advertised prefixes of my current default
router.

'nuff said. If you don't think this needs clarification in the Mobile IPv6
specification for MN implementors, then I'm OK with that, because we've
already figured out the correct thing to do in our MN implementation. I was
just trying to share ;-)

---------------------

Ed Remmell writes: proposed text changes to draft 19:

> the following wording should be removed from section 11.5.3,
> because it is misleading:
> "A mobile node SHOULD select a primary care-of address from among those
> care-of addresses it has formed using any of these subnet
> prefixes, based on
> the movement detection mechanism in use, as described in Section 11.5.1."
>
> This should be replaced with a new requirement, which can either go in
> section 11.5.2 or section 11.5.3:
> "The MN MUST ensure that its primary care-of address always has a prefix
> that is considered on-link by its current default router (i.e., advertised
> by its current default router in a solicited Router
> Advertisement); this may
> require the MN to either change its primary care-of address and/or its
> current default router."
>
> New requirements text, add to section 11.5.3:
> "Whenever a MN determines that it is no longer reachable through a given
> link, it SHOULD invalidate all care-of addresses associated with address
> prefixes that it discovered from routers on the unreachable link which are
> not in the current set of address prefixes advertised by the
> (possibly new)
> current default router."
>
> New requirements text, add to section 11.5.3:
> "The MN MAY choose to restrict auto-configuration of care-of addresses to
> use only those prefixes it discovers by receiving Router
> Advertisements from
> the current default router."

---------------------

Jari Arkko writes: 

>>the following wording should be removed from section 11.5.3,
>>because it is misleading:
>>"A mobile node SHOULD select a primary care-of address from among those
>>care-of addresses it has formed using any of these subnet
>>prefixes, based on
>>the movement detection mechanism in use, as described in Section 11.5.1."
>>
>>This should be replaced with a new requirement, which can either go in
>>section 11.5.2 or section 11.5.3:
>>"The MN MUST ensure that its primary care-of address always has a prefix
>>that is considered on-link by its current default router (i.e., advertised
>>by its current default router in a solicited Router
>>Advertisement); this may
>>require the MN to either change its primary care-of address and/or its.
>>current default router."

Looks OK to me.

>>New requirements text, add to section 11.5.3:
>>"Whenever a MN determines that it is no longer reachable through a given
>>link, it SHOULD invalidate all care-of addresses associated with address
>>prefixes that it discovered from routers on the unreachable link which are
>>not in the current set of address prefixes advertised by the
>>(possibly new)
>>current default router."

Ok.

>>New requirements text, add to section 11.5.3:
>>"The MN MAY choose to restrict auto-configuration of care-of addresses to
>>use only those prefixes it discovers by receiving Router
>>Advertisements from
>>the current default router."

I'm not sure why we need this. Aren't the two above changes already enough?

---------------------

Ed Remmell writes: Yes, I agree with you, the other two changes are
enough. I was just including the 3rd "MAY" as a note/hint to
implementors, but it isn't really needed.

---------------------

---------------------

---------------------

---------------------