Subject: Re: [mobile-ip] Why not tunnel instead of RTH2 and HAO?

From: Pekka Savola <[email-masked]>
Date: Tue, 1 Apr 2003 08:06:51 +0300 (EEST)

On Mon, 31 Mar 2003, Markku Savela wrote:
> In draft-ietf-mobileip-ipv6-21.txt, chapter 9.3.2 it says that if node
> has a binding cache entry for the destination, it uses routing header
> type 2.
> 
> Additionally, I suppose that it can in such case assume other end has
> also binding cache entry, and thus Home Address option is used. So,
> the packet would look as
> 
> IP: dst=CN-care address
>     src=my-care address
>     RTH2: CN-home address
>     HAO: my-home address
>     Payload
> 
> Total header size: IP(40) + RTH2(24) + HAO(24) = 88
> 
> Now, I'm just wondering, why not just tunnel?
> 
> IP: dst=CN-care address
>     src=my-care address
> IP: CN-home-address
>     my-home-address
>     Payload
> 
> Total header size IP(40) + IP(40) = 80.
> 
> Tunneling would be at least 8 bytes shorter overhead? And scrapping
> the HAO and RTH2 would make RFC many pages shorter? :-)
> 
> Am I missing something (still new on this mobile-IP 6 thingy)?

One problem here is that then all IPv6 nodes with CN functionality would 
have to accept tunneled packets from everywhere.  That's *bad*.

Of course, this could be mitigated slightly by making a connection with
binding update and similar mechanism -- so that the tunnels would always
have "an endpoint" and not be open to the world.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Apr 2003 12:53:36 +0300

> From: Vijay Devarapalli <[email-masked]>
> you are new to mipv6? didnt you implement it 3 years back? :-)

No, I've only worked with IPv6 and IPSEC.

I started this topic because I was sort of "stress testing" the
architecture by imagining the worst possible combinations: MIP6 +
IPSEC in following scenario between two nodes:

a) nodes protect the traffic between each other using IPSEC
b) nodes use IPSEC between care addressess (maybe behind security gateways)
c) node is at home
d) node is away from home

and any combinations of above.

Analysing combo a + b + d. With (d) alone the current MIP6 gives

IP: dst=CN-care address
    src=my-care address
    RTH2: CN-home address
    HAO: my-home address
    <other ext headers>
    Payload

When adding a + b (on outbound, I run IPSEC both before and after
MIP6), where should the IPSEC headers go? Seems only way is

IP: dst=CN-care address
    src=my-care address
    IPSEC-b
    RTH2: CN-home address
    HAO: my-home address
    IPSEC-a
    <other ext headers>
    Payload

Where is the policy checking occurring for IPSEC-a and IPSEC-b at
receive end? As everything before Payload is just extension headers,
both seem to fall at same place, and this is confusing...

IP: dst=CN-care address
    src=my-care address
    IPSEC-b
    RTH2: CN-home address
    HAO: my-home address
    IPSEC-a
    <other ext headers>
--- < policy check for a and b!
    Payload

On the other hand, if we assume the "tunneling MIP6", the IPSEC
headers would be as follows

IP: dst=CN-care address
    src=my-care address
    <other ext headers>
    IPSEC-b
    <other ext headers>
IP: CN-home-address
    my-home-address
    <other ext headers>
    IPSEC-a
    <other ext headers>
    Payload

And, as IP-in-IP is technically transport/upper layer, the policy
checking becomes very deterministic

IP: dst=CN-care address
    src=my-care address
    IPSEC-b
--- policy check for b
IP: CN-home-address
    my-home-address
    IPSEC-a
--- policy check for a
    Payload

I would strongly prefer IPSEC to be independent of MIP6 (and of any
other future protocol addition), and thus I've some reluctance against
a lot of new special handling for the IPSEC due to MIP6.

I'm not sure who is the culprit for the mess: IPSEC or MIP6. I do
think that scrapping HAO and RTH2 and replacing them with tunneling
would make the current IPSEC work as is (if your system is capable of
running the outbound packets through IPSEC twice).

However, I'm not proposing this at this stage. Just expressing some
thoughts I have...

ps. I cannot find any messages later than january 2003 from mobile
mailing list archive (http://playground.sun.com/mobile-ip/). Is it
broken?

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 01 Apr 2003 20:12:30 +0900 (JST)

Hi,

From: Markku Savela <[email-masked]>

> MIP6), where should the IPSEC headers go? Seems only way is

No. If you want protect packets using transport mode IPsec between
nodes, the packets look like:

IP: dst=CN-care address
    src=my-care address
    RTH2: CN-home address
    HAO: my-home address
    IPSEC-a
    <other ext headers>
    Payload

IPsec is applied against the below packet:

IP: dst=CN-home address
    src=my-home address
    RTH2: CN-care address
    HAO: my-care address
    <other ext headers>
    Payload

After you have gotten an IPseced packet, you should exchange addresses
(HoA and CoA, CN-home and CN-care).

I'm not sure what kind network you are thinking of.  Maybe the network
graph is helpful for this discussion.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Apr 2003 15:24:55 +0300

> From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= <[email-masked]>

> graph is helpful for this discussion.

Ok, I said was thinking of extreme worst case :-) Dig this..

MN-AGENT --|                      |
           |                      |-- CN-AGENT
           |--MN-HOME-SG          |
           |                      |
                                  |
                      CN-HOME-SG--|

MN ---|                           |
      |                           |-- CN
      |               CN-CARE-SG--|

MN to talk with MN-AGENT (home) you need

  IPSEC between MN and MN-HOME-SG
  IPSEC between MN and MN-AGENT

MN to talk with CN directly

  IPSEC betwen MN and CN
  IPSEC between MN and CN-CARE-SG

MN to talk with CN via MN-AGENT (tunneled)

  IPSEC between MN and CN
  IPSEC between MN and MN-HOME-SG
  IPSEC between MN and MN-AGENT

  (additionally, of course, the MN-HOME-SG needs to IPSEC with
  CN-CARE-SG, but thats outside MIP6 :-)

[well, who would put HOME AGENT behind a security gateway? If one does
that, one could probably drop the IPSEC between MN and MN-AGENT, or
assuming some VPN, MN would actually be "virtually at home" -- as said
I was just tinkering with extreme cases]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Apr 2003 15:49:18 +0300

> I was just tinkering with extreme cases]

Yes. By the way, we've had some (mostly off-list) discussions about
looking at "remote access IPsec" and "mobile IPv6 ipsec" and doing
something in that space as a later follow-up. For now, the
current specifications keep the IPsec model of just one step
IPsec processing (even if multiple IPsec headers are added),
and the idea of looking at the original packet for the policy
checks.

Jari

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 01 Apr 2003 23:04:29 +0900 (JST)

Hi,

> Ok, I said was thinking of extreme worst case :-) Dig this..
 
The above configuration is very tough...
I think no one talks (at least explicitly) about such a configuration.

With the current MIP6 spec, I think the packet format will be as
follows.  I'm not sure if this solves what you think ambiguous,
though...

>   IPSEC between MN and MN-AGENT

In this case the packet on the wire will be:

IP: src=MN-care
    dst=MN-HOME-SG
    HAO MN-home
    IPsec (between MN-home and MN-HOME-SG)
    IP: src=MN-care
	dst=MN-AGENT
	HAO MN-home
	IPsec (between MN-home and MN-AGENT)
	Payload

>   IPSEC between MN and CN-CARE-SG

If MN has a binding update entry fro CN-CARE-SG,

IP: MN-care
    CN-CARE-SG
    HAO MN-home
    IPsec (between MN-home and CN-CARE-SG)
    IP: MN-care
	CN-care
	RTHDR CN-home
	HAO MN-home
	IPsec (between MN-home and CN-home)
	Payload

If MN doesn't have a binding cache entry for CN-CARE-SG,

IP: src=MN-care
    dst=MN-HOME-SG
    HAO MN-home
    IPsec (between MN-home and MN-HOME-SG)
    IP: src=MN-home
	dst=CN-CARE-SG
	IPsec (between MN-home and CN-CARE-SG)
	IP: src=MN-home
	    dst=CN-care
	    RTHDR CN-home
	    IPsec (between MN-home and CN-home)
	    Payload

>   IPSEC between MN and MN-AGENT

IP: src=MN-care
    dst=MN-HOME-SG
    IPsec (between MN-care and MN-HOME-SG)
    IP: src=MN-care
	dst=MN-AGENT
	IPsec (between MN-care and MN-AGENT)
	IP: src=MN-home
	    dst=CN-care
	    RTHDR CN-home
	    IPsec (between MN-home and CN-home)
	    Payload

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Apr 2003 18:39:38 +0300

This is getting very detailed and long. Most will probably just get
glazed eyes or headache from reading this... :-)

> 	IPsec (between MN-home and MN-AGENT)

Hmm.. that extra HAO surprised me. I expected the outer IPSEC to
happen without knowledge of MIP6, just standard IPSEC SG tunneling,
which hits after MIP6 has been processed. (Obviously, this requires
the MN identifies itself to the MN-HOME-SG by something that is not
it's current care-of address -- standard "roadwarrior problem"?).

IP: src=MN-care
    dst=MN-HOME-SG

and just for reference, if HAO is not used, but everything is
tunneled, the packet would be

IP: src=MN-care
    dst=MN-HOME-SG

Above is Not a pretty sight either... yes, HAO would save something
here.

> 	IPsec (between MN-home and CN-home)

Again, that extra HAO is unexpected by me. I thought

IP: MN-care
    CN-CARE-SG
    IPsec (between MN-care and CN-CARE-SG)
    IP: MN-care
	CN-care
	RTHDR CN-home
	HAO MN-home
	IPsec (between MN-home and CN-home)
	Payload

and without HAO/RTH it would be

IP: MN-care
    CN-CARE-SG
    IPsec (between MN-care and CN-CARE-SG)
    IP: MN-care
	CN-care
	IP: CN-home
	    MN-home
	    IPsec (between MN-home and CN-home)
	    Payload
 
> 	    IPsec (between MN-home and CN-home)

Ok, removing extra HAO:s, but even before it doesn't look right? Some
CN-CARE-SG's need to be replaced with MN-AGENT.

IP: src=MN-care
    dst=MN-HOME-SG

When MN-HOME-AGENT forwards the tunneled packet to CN-care, the IPSEC
between MN-HOME-SG and CN-CARE-SG is dealt between them, and not a
concern of MIP6. (not going into messy detail of how does it know the
CN-CARE-SG address from CN-CARE address -- let's just assume CN and MN
belong to co-operative organizations, which have the IPSEC SG's and
authoritations properly configured :-)

And, without HAO and RTH:

IP: src=MN-care
    dst=MN-HOME-SG
	    IP: src=MN-Home
		dst=CN-home

Yes, again a bit of loss there.

> 	    IPsec (between MN-home and CN-home)

Umm.. from where did CN-care appear? MN does not in this case have the
binding cache entry for CN. I think above would just be

IP: src=MN-care
    dst=MN-HOME-SG
	    dst=CN-home

What happens next at MN-HOME-AGENT, ugh... I think I give up at this
point. Gets tougher than ever..

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 02 Apr 2003 21:21:24 +0900 (JST)

I'm not discouraging the discussion, but, I don't think it is better
to continue HAO/RTHDR vs tunneling discussion for **current spec**.
Maybe next step mobility is the right place to raise such an idea...
I (and many other implementers, I guess) want to focus on implementing
current spec.  Even now, I have a lot of TODO left in my
implementation :-)

Anyway,

> it's current care-of address -- standard "roadwarrior problem"?).

Ah, yes.  You are right.  Please foget the extra HAO from my examples.

> 	    IPsec (between MN-home and CN-home)

You right, again.  I misunderstood the example network and SG
configuration.

> binding cache entry for CN. I think above would just be

I have assumed MN has a BC.  If MN already has received a binding
update from CN, MN may have a binding cache for CN.  Even in this
case, packets are tunneled if MN do not send a binding update to CN
yet.  There are 4 patterns:

1) BC(for CN) doesn't exist && BUE(for CN) doesn't exist
2) BC(for CN) exists && BUE(for CN) doesn't exist
3) BC(for CN) doesn't && BUE(for CN) exists
4) BC(for CN) exists && BUE(for CN) exists

The example I have written is for 2) and what you have expected is 1).

> 	    IPsec (between MN-home and CN-home)

For case 1), yes, your example is the correct one.

---
Keiichi SHIMA

---

From: Thomas Narten <[email-masked]>
Date: Tue, 08 Apr 2003 06:41:29 -0500

> Now, I'm just wondering, why not just tunnel?

A valid question, and one that has been raised before.

Have a look at the following expired drafts, for instance:

     draft-deering-ipv6-encap-addr-deletion-00.txt
     draft-nordmark-mobileip-mipv6-hindsight-00.txt

At this point in time, it's a little on the late to change
this. Bottom line is: would the delay in getting the spec out the door
to make these changes be worth the benefit? I would suspect that most
people would say no. (And would Jari be tempted to say, "no thanks, if
the WG wants this, time for another editor? :-)

Thomas

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 8 Apr 2003 08:25:18 -0700

Thomas -

>      draft-nordmark-mobileip-mipv6-hindsight-00.txt

How do I get a copy of these, since they've expired?

> people would say no.

quick answer: undecided, but hurry up and finish it ;-)

It isn't worth the extra complexity of having to support two different
mechanisms to do the same thing. If you are referring to replacing RTH2 and
HAO with tunneling, and then entirely removing RTH2 and HAO from the MIPv6
spec, then perhaps this might be a reasonable change to consider.

There is an advantage to using RTH2 and HAO - you know for certain that
these extension headers are being used by MIPv6 route optimization. With
tunneling, you don't know this, because generic IPv6 tunnels can be used for
other purposes. Also, it seems like the tunneling only works in the
direction from the CN to the MN (i.e. replacing the type 2 Routing Header),
unless it is acceptable to have the following encapsulation to replace the
HAO:

outer tunnel header:
source address: MN care-of address
destination address: CN address

inner tunnel header:
source address: MN home address
destination address: CN address (same destination as for outer tunnel
header)

If you did this, then you could also replace the use of the HAO in the BU
that the MN sends to the HA with a similar encapsulation. One advantage of
doing this tunneling is that it wouldn't require the address swapping that
is currently needed to make sure that the right IP address selectors are
passed to IPsec in the send-path.

It might be difficult for us to implement MIPv6 route optimization using
tunneling, because we implement generic IPv6 tunnels as interfaces in our
routing tree. However, it turned out that we couldn't implement the BCE or
the BUL in our routing tree anyways, so I suspect that we could probably
hack our current implementation to do tunneling instead of RTH2 and HAO, and
it wouldn't be much different than our current hacks for RTH2 and HAO in the
send-path. So, ultimately I could go either way on this, but I wish you'd
finalize this soon as we want to release a product based on this spec ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 08 Apr 2003 20:54:00 +0200

Ed Remmell wrote:
>...So, ultimately I could go either way on this, but I wish you'd

It is finalized for this rev of the spec. This, as well as all the
other potential tweaks and changes are to be addressed later, perhaps
in another working group, according to discussions in mipcharter.
For this spec we're not replacing something that works with something
else that works.

-gabriel

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 8 Apr 2003 19:09:34 -0700

>      draft-nordmark-mobileip-mipv6-hindsight-00.txt

"There is also one idea that could be added to Mobile IPv6 at a later
   stage, which is to make the movement detection more explicit.  The
   idea is to configure the routers on each link to advertise a single
   global IPv6 address as the "identity" of the link in each Router
   Advertisement.  This can be done by defining a new Neighbor Discovery
   option.  Thus a Mobile Node when it receives a Router Advertisement
   can immediately tell whether it has moved - the global identity will
   be different for each link."

Yes, this would be a big improvement if only it were possible...
hindsight is 20/20

- Ed

---

From: Greg Daley <[email-masked]>
Date: Wed, 09 Apr 2003 15:21:46 +1000

Hi Ed,

Why isn't it possible?
It may be possible to put this in a Movement Detection Draft,
if that's a good way forward.

It's obviously an opt-in message, and could be used
by any node which understands it to ensure good
Movement Detection performance.

Greg D.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 9 Apr 2003 09:51:07 -0700

Greg -

> Why isn't it possible?

I've already asked (see below #1) that the requirements on the use of the
"R" bit of the RA Prefix Information Option be tightened up a bit to make
that information more useful for MN move detection, but I've received no
indication from this list that any change will be made to the MIPv6 spec to
add stronger requirements wording about the use of this bit. If it isn't
done now before MIPv6-aware routers are deployed, it is too late, since
apparently it is nearly impossible to mandate any changes to an already
deployed network. That's essentially why it isn't possible, IMHO. The
requirements on the use of the "R" bit currently in the spec do not ensure
that when this option is used in RAs that it will be consistent in all RAs
sent by the same router, thus IMHO is it practically useless currently for
generic MN move detection (OK, so in some specific deployments of MIPv6
where a service provider/etc. has complete control over their own network,
they can tighten things up a bit so that this "R" bit option is used
consistently and thus can be used for MN move detection in that instance,
but in general, the requirements on the use of the "R" bit are too loose
currently for a generic MN implementation).

> Movement Detection performance.

See my comments for issue #278:
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue278.txt

I had a couple of suggestions:

1) For routers that send a Router Advertisement containing a Prefix
Information Option with the "R" bit set indicating that it contains a global
scope address of the router:
once you advertise your global address this way in a RA (solicited or
unsolicited), you MUST continue to advertise that exact same global address
in every single RA you send (solicited or unsolicited) as long as the prefix
of the global address is still valid.

2) All IPv6 routers SHOULD include their global address in the RA as a
Prefix Information Option with the "R" bit set.

I know #2 is controversial because it is suggesting changes to an already
deployed IPv6 network (this came across in the minutes as a MUST, but I've
been saying SHOULD). But #1 should not be controversial, since the "R" bit
is new with MIPv6. My mobile node cannot use the "R" bit for move detection
if this RA prefix information is not consistent. Some router implementation
may decide that if there are multiple global prefixes assigned to a link, in
some RAs they may not include any "R" bit prefix option, in others they may
include one of those options with a global address of the router and then
not be consistent about which global address, then it isn't consistent - if
every single RA that that router sends (solicited and unsolicited) doesn't
have that exact same "R" bit prefix option with that exact same global
router address, my MN implementation cannot use it for movement detection. I
have received back no indication that any change will be made to the MIPv6
spec to tighten up the router requirements for using the "R" bit. So, from
the standpoint of MN move detection, I think it is pretty useless currently.

Around the same time (somewhat unrelated topic), I made the discovery that
one of my assumptions was flawed - generally RAs are sent to a multicast
destination address, even when they are solicited. So, in general there is
no such thing as a solicited RA, or at least a MN can't really tell the
different in most cases between solicited and unsolicited RAs. Only
solicited RAs SHOULD (no guarantee) have the entire set of on-link prefixes
for a link, unsolicited RAs may contain partial/incomplete prefix
information. So, using the prefix information in the RA for move detection
is also not too reliable, again mainly because the information is not
consistent between RAs from the same router. This I can live with, but the
fact that I can't tell the difference between a solicited versus an
unsolicited RA (when in many cases the solicited RA will be sent to a
multicast destination) does make MN move detection a little more difficult.

Consistency of the information in RAs is my main concern, as a MN
implementor. I really want something to be added to the MIPv6 spec at least
for the "R" bit Prefix Information Option to ensure that information is
consistent/complete for all RAs sent by the router that uses it (such a
router must be MIPv6-aware, since the "R" bit is new with MIPv6).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Greg Daley <[email-masked]>
Date: Thu, 10 Apr 2003 12:59:03 +1000

Hi Ed,

I think I understand your points,
but am operating on the principle that MD
is not working sufficiently well in MIPv6 now,
and is not likely to get fixed before we push
the PS button.

A few of the interesting MD optimizations will
require modification of the router infrastructure
in any case, so there is still scope for further
work to be done on access networks, so that on
supporting networks, MN's can determine the
identity of the network as soon as they receive an RA.

Right now we're working on what information is
really needed to identify that a received RA
implies movement.  Nick and I discussed your
idea today.

Form your original idea, I think the identity
was tied to RF propagation. In order to simplify
the concept, I'd prefer to tie an identifier
to a broadcast domain (which may actually be different to
propagation in some circumstances).

Nick and I have tried to distill the operation of the tags,
and how they could assist MD. Please tell me if the
following synthesis describes your concept
well enough.

Any routers in a broadcast domain MAY tag their
RAs with an ID.

An ID is used by a set of routers sharing the
same link to indicate that RAs from any of the
set of routers can be used to identify the
broadcast domain's reachability, if the IDs in
those RAs match.  IDs MUST be unique for any
pair of broadcast domains between which the
MN may move.

A router which sends an RA with an ID MUST
continue to send the ID in every RA while the
ID is still valid for movement detection.

If an MN has formed a CoA on an interface based
on a previously seen RA, and then receives an RA
from a new router on the same interface which
doesn't contain an ID, the
MN SHOULD send an RS to discover if routers
from the currently configured broadcast domain
are still contactable.   This is the case only
if the received RA does not contain the prefix
from which the CoA is configured.

If the MN has formed a CoA from an RA which doesn't
contain an ID, and then subsequently receives an
RA with an ID on the same interface, then the MN SHOULD
configure an RCoA from the set of prefixes in the new RA.
If the currently configured prefix is not in the set
advertised by the RA with the ID, then the MN SHOULD assume
movement has occurred, and perform mobility signalling.

If the MN has a CoA formed from an RA sent with an ID,
and receives an RA with a different ID on the same interface,
it SHOULD assume that movement has occurred if the prefix used
to configure the CoA is not present in the advertised RA.
In this case, a CoA SHOULD be configured from a prefix
advertised in the new RA, and mobility signalling begun.

Here's a quick lookup table:

CurrAR       NewAR
RA TAG       RA TAG     Action
---------------------------------------
ID1           ID1       Keep Address (no movement)
ID1           ID2       address invalid (movement)
  -            ID2       bind new        (movement)
ID1            -        probe RS
  -             -        probe RS

This gives quick movement detection when moving to a
network supporting IDs regardless of whether the
previous network supported IDs.  Also some
robustness in the case of multiple routers is supplied.

The ID's can come from any source which is convenient
to the administrator.  This may be a set of bits from
an address of one of the devices in the broadcast domain,
if this is convenient. I'm not sure I'd mention site-local
as in your previous discussion from issue 278.

Additional controls regarding consistency of prefix/router
address advertisement could be implemented, but may
be unnecessary if the ID is sufficient for MD.
I'm not sure yet.

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 10 Apr 2003 14:29:28 -0700

Greg -

It is awesome that you actually responded to my email! Thanks! So, I will
take the time to thoughtfully respond to yours.

> and is not likely to get fixed before we push

Hmmm...
Beacons can make the handovers fast enough for voice.
I think having consistency of the information in the RA is the main issue:
sometimes the RA contains all of the on-link prefix information, sometimes
it doesn't, and it is hard for the MN to tell the difference. With that in
mind, we should include some text in the current draft that makes the new
"R"-bit prefix information option consistent in RAs sent by routers that use
that option - that seems perfectly reasonable, since it is an option
specific to MIPv6 (and the spec is still a draft, although it has gone
through IETF last call).
The Advertisement Interval option seems fairly useful, that will help
improve MD.
Apart from the problem with consistency of the prefix information in the
RAs, I don't see anything obviously broken with MIPv6 default MD, apart from
the fact that the handover latency can be pretty slow (considering the 60
msec goal for voice).

> identity of the network as soon as they receive an RA.

Yes. But, please note that it makes a lot of sense for a MN to consider its
current default router as a virtual link, and only consider prefixes as
on-link if they are broadcast by that specific router (and thus only
configure the primary CoA from that same set of prefixes, and when you
switch to a different router if that prefix isn't also broadcast by the new
router you must stop using the old primary CoA). Early drafts (i.e. 18) of
MIPv6 were pretty much "willy-nilly" w/ respect to how the MN should treat
CoAs and prefixes discovered (within the same period of time) from different
routers (i.e. the overlapping coverage areas scenario, or just multiple
routers on the same link broadcasting different prefixes) - it was almost
considered a bonus if you would hear multiple routers and then
auto-configure many CoAs from the information broadcast by those multiple
routers, i.e. "its great that you can discover so many prefixes and use so
many CoAs"! This just will not work corretly. Bi-directional reachability of
the current default router needs to be confirmed by the MN, NUD is a perfect
mechanism for doing this. Depending on what kind of network the MN is
attached to, and whether or not the MN has sufficient L2 triggers, the MN
may be able to hear RAs from a different default router than the one that it
is "locked on to" as its current default router, but until it confirms
bi-directional reachability with that new router, it should not consider
switching from its current default router. In fact, as long as the MN's
"virtual link" to the current default router is still working (NUD will
probe it periodically to reconfirm bi-directional reachability), there is no
need to switch.

> Any routers in a broadcast domain MAY tag their

Yes. It isn't required, but if they do tag it then that information needs to
stay consistent in all RAs sent by the same router (as long as it is still
valid).

> pair of broadcast domains between which the

Not necessary. Per my comments above, I am not planning on using multiple
routers simultaneously, I'm only planning on using a single one at any given
time, and that is my current default router that I have configured my
primary CoA based on the prefixes it is advertising. If there are multiple
routers on the same link, or even on overlapping links (or links that appear
to be overlapping due to insufficient L2 triggers and frequent link movement
by the MN), I could care less if they broadcast the same ID. If they are on
different links and perhaps have the same link-local scope address, then it
would be a real problem if they broadcast the same ID, because then I
couldn't easily tell the difference between them (without having some
kludged algorithm for looking at the prefix information in the RA to tell
the difference, which doesn't seem like it would ever work that well since
it will usually be an incomplete subset of all of the on-link prefixes and
will is likely to be inconsistent between RAs). So, using a global IPv6
address that belongs to the router for this purpose is a good way to go. I
guess it is possible that that global IPv6 address is some form of anycast
address, used to implement load balancing, and multiple routers on the same
link actually share it. In that case, the link-local scope source address in
the RA will help my MN differentiate between them. So, really the
combination of link-local scope source address in the RA and ID is what the
MN would use in this case to track a specific current default router for the
purpose of MD.

> ID is still valid for movement detection.

Yes, that's the key. Otherwise, my MN can't use this ID for move detection.

> from which the CoA is configured.

Actually, the current mechanism of using NUD works perfectly fine. Perhaps
for faster/smoother moves, you want to speed up the equivalent of NUD
probing. The NS/NA exchange is the best method for determining
bi-directional reachability, because the MN can actually confirm that the NA
is the solicited answer to its NS. With the RS/RA exchange, nothing is for
sure, there is no way to tell the difference between a solicited RA and an
unsolicited RA (well, not entirely true - but RFC-2461 pretty much states
that routers will always multicast RAs, even when sending them in response
to a RS).

I'd use the ID in conjunction with the routers link-local scope source
address in the RA to make sure that I'm really tracking the same router. But
what you describe above seems to make sense - instead of sending the RS,
however, I'd initiate immediate NUD probing of my current default router in
this case.

> configure an RCoA from the set of prefixes in the new RA.

Perhaps what you are trying to say is that the MN should prefer to use a
router that includes the ID in its RAs? That sounds reasonable. I'd say the
same should also apply to the Advertisement Interval option. But, if you
aren't saying that the MN should switch to this new router, but that it can
discover prefixes broadcast by the new router even though it is latched on
to a perfectly good bi-directionaly reachable current default router that
doesn't broadcast those prefixes, then I'd strongly disagree - you will run
into the same kinds of problems with this as I described above (i.e. you'll
end up configuring CoAs that you can't use as your primary CoA, and it could
be nasty if the applications tried to use them in that case and/or if the MN
got confused over which CoAs are on-link and which aren't). Of course, it
really does also depend on the physical network characteristics, and whether
or not the MN implements sufficient L2 triggers to be able to detect real
link and possibly even subnet movement w/out needing the L3 mechanisms - but
since I'm developing a general purpose MN (Elmic Systems sells portable ANSI
C implementations of Internet protocols for generic embedded systems), I
can't ignore these other potential issues, since who knows: our MN could be
used in an environment where there are overlapping coverage areas,
interference, and the MN may not implement any L2 triggers to be able to
indicate movement.

> movement has occurred, and perform mobility signalling.

Hmmm... how do we populate that set? How do we make sure that we have a
complete set of on-link prefixes for a given router? I guess you'd have to
solicit the router multiple times so hopefully you get at least one more or
less complete RA containing all of the prefix information, but still this
seems error prone. Using the prefixes this way to detect movement seems
pretty error prone, mainly because of the basic problem that the information
in the RAs is not consistent (i.e. most times it is a incomplete subset).
When beacons are used, I would expect these types of unsolicited RAs to
contain very little information.

> advertised in the new RA, and mobility signalling begun.

Hmmm... I think you can tell from what I've written above that I have
problems with this method.

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 10 Apr 2003 14:32:19 -0700

BTW, please refer to the MIPv6 issue #170, sloppiness about overlapping
coverage areas. I've attached the text.

Thanks.
- Ed

> -----Original Message-----
> From: Ed Remmell [mailto:[email-masked]]
> Sent: Thursday, April 10, 2003 2:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: MD identifiers ? (was Re: [mobile-ip] Why not tunnel
> instead of RTH2 and HAO?)
>
>
> Greg -
>
> It is awesome that you actually responded to my email! Thanks!
> So, I will take the time to thoughtfully respond to yours.
>
> I think having consistency of the information in the RA is the
> main issue: sometimes the RA contains all of the on-link prefix
> information, sometimes it doesn't, and it is hard for the MN to
> tell the difference. With that in mind, we should include some
> text in the current draft that makes the new "R"-bit prefix
> information option consistent in RAs sent by routers that use
> that option - that seems perfectly reasonable, since it is an
> option specific to MIPv6 (and the spec is still a draft, although
> it has gone through IETF last call).
> The Advertisement Interval option seems fairly useful, that will
> help improve MD.
> Apart from the problem with consistency of the prefix information
> in the RAs, I don't see anything obviously broken with MIPv6
> default MD, apart from the fact that the handover latency can be
> pretty slow (considering the 60 msec goal for voice).
>
> Yes. But, please note that it makes a lot of sense for a MN to
> consider its current default router as a virtual link, and only
> consider prefixes as on-link if they are broadcast by that
> specific router (and thus only configure the primary CoA from
> that same set of prefixes, and when you switch to a different
> router if that prefix isn't also broadcast by the new router you
> must stop using the old primary CoA). Early drafts (i.e. 18) of
> MIPv6 were pretty much "willy-nilly" w/ respect to how the MN
> should treat CoAs and prefixes discovered (within the same period
> of time) from different routers (i.e. the overlapping coverage
> areas scenario, or just multiple routers on the same link
> broadcasting different prefixes) - it was almost considered a
> bonus if you would hear multiple routers and then auto-configure
> many CoAs from the information broadcast by those multiple
> routers, i.e. "its great that you can discover so many prefixes
> and use so many CoAs"! This just will not work corretly.
> Bi-directional reachability of the current default router needs
> to be confirmed by the MN, NUD is a perfect mechanism for doing
> this. Depending on what kind of network the MN is attached to,
> and whether or not the MN has sufficient L2 triggers, the MN may
> be able to hear RAs from a different default router than the one
> that it is "locked on to" as its current default router, but
> until it confirms bi-directional reachability with that new
> router, it should not consider switching from its current default
> router. In fact, as long as the MN's "virtual link" to the
> current default router is still working (NUD will probe it
> periodically to reconfirm bi-directional reachability), there is
> no need to switch.
>
> Yes. It isn't required, but if they do tag it then that
> information needs to stay consistent in all RAs sent by the same
> router (as long as it is still valid).
>
> Not necessary. Per my comments above, I am not planning on using
> multiple routers simultaneously, I'm only planning on using a
> single one at any given time, and that is my current default
> router that I have configured my primary CoA based on the
> prefixes it is advertising. If there are multiple routers on the
> same link, or even on overlapping links (or links that appear to
> be overlapping due to insufficient L2 triggers and frequent link
> movement by the MN), I could care less if they broadcast the same
> ID. If they are on different links and perhaps have the same
> link-local scope address, then it would be a real problem if they
> broadcast the same ID, because then I couldn't easily tell the
> difference between them (without having some kludged algorithm
> for looking at the prefix information in the RA to tell the
> difference, which doesn't seem like it would ever work that well
> since it will usually be an incomplete subset of all of the
> on-link prefixes and will is likely to be inconsistent between
> RAs). So, using a global IPv6 address that belongs to the router
> for this purpose is a good way to go. I guess it is possible that
> that global IPv6 address is some form of anycast address, used to
> implement load balancing, and multiple routers on the same link
> actually share it. In that case, the link-local scope source
> address in the RA will help my MN differentiate between them. So,
> really the combination of link-local scope source address in the
> RA and ID is what the MN would use in this case to track a
> specific current default router for the purpose of MD.
>
> Actually, the current mechanism of using NUD works perfectly
> fine. Perhaps for faster/smoother moves, you want to speed up the
> equivalent of NUD probing. The NS/NA exchange is the best method
> for determining bi-directional reachability, because the MN can
> actually confirm that the NA is the solicited answer to its NS.
> With the RS/RA exchange, nothing is for sure, there is no way to
> tell the difference between a solicited RA and an unsolicited RA
> (well, not entirely true - but RFC-2461 pretty much states that
> routers will always multicast RAs, even when sending them in
> response to a RS).
>
> I'd use the ID in conjunction with the routers link-local scope
> source address in the RA to make sure that I'm really tracking
> the same router. But what you describe above seems to make sense
> - instead of sending the RS, however, I'd initiate immediate NUD
> probing of my current default router in this case.
>
> Perhaps what you are trying to say is that the MN should prefer
> to use a router that includes the ID in its RAs? That sounds
> reasonable. I'd say the same should also apply to the
> Advertisement Interval option. But, if you aren't saying that the
> MN should switch to this new router, but that it can discover
> prefixes broadcast by the new router even though it is latched on
> to a perfectly good bi-directionaly reachable current default
> router that doesn't broadcast those prefixes, then I'd strongly
> disagree - you will run into the same kinds of problems with this
> as I described above (i.e. you'll end up configuring CoAs that
> you can't use as your primary CoA, and it could be nasty if the
> applications tried to use them in that case and/or if the MN got
> confused over which CoAs are on-link and which aren't). Of
> course, it really does also depend on the physical network
> characteristics, and whether or not the MN implements sufficient
> L2 triggers to be able to detect real link and possibly even
> subnet movement w/out needing the L3 mechanisms - but since I'm
> developing a general purpose MN (Elmic Systems sells portable
> ANSI C implementations of Internet protocols for generic embedded
> systems), I can't ignore these other potential issues, since who
> knows: our MN could be used in an environment where there are
> overlapping coverage areas, interference, and the MN may not
> implement any L2 triggers to be able to indicate movement.
>
> Hmmm... how do we populate that set? How do we make sure that we
> have a complete set of on-link prefixes for a given router? I
> guess you'd have to solicit the router multiple times so
> hopefully you get at least one more or less complete RA
> containing all of the prefix information, but still this seems
> error prone. Using the prefixes this way to detect movement seems
> pretty error prone, mainly because of the basic problem that the
> information in the RAs is not consistent (i.e. most times it is a
> incomplete subset). When beacons are used, I would expect these
> types of unsolicited RAs to contain very little information.
>
> Hmmm... I think you can tell from what I've written above that I
> have problems with this method.
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 11 Apr 2003 16:57:26 +1000

Hi Ed,

I'm trying to clarify some of the ideas that
I posted to see if we're on the same wavelength
w.r.t. the requirements.

Maybe the standards like language was a bit
premature (and unexplained).

Please see inline for responses.

> Beacons can make the handovers fast enough for voice.

Maybe, depending on the link layer ;)

I was talking about the main issue being quick determination
from received network information that movement has occurred.
This is heuristically based at the moment, and Yourself,
JinHyeock and I have all been looking into this issue closely.

> specific to MIPv6 (and the spec is still a draft, although it has gone

I'm actually thinking that prefixes not being
advertised in unsolicited RAs is less of an issue
than it seems.

Certainly, I don't think it is useful to form a CoA based
on a prefix which isn't one of the first 2 or 3 advertised
by the router in an RA.   If the router wants people to use
these prefixes it will advertise them with its most important
information.  It will also keep advertising these prefixes
so long as they are considered good prefixes, and may
explicitly retract prefixes if it needs (lifetime=0).

Maybe this needs to be more explicity stated in a draft..

This is why I'm not that interested in soliciting an RA in
order to find if my existing prefix is valid (there may be
other reasons to do so though).

Of course, there may be some R-bit issues still in MIPv6,
but I was seeing the problem not as one of individual
routers, since in general we can't make hosts to treat
connections to individual routers as being different to
being connected to a link-local subnet.

> the fact that the handover latency can be pretty slow (considering the 60

Actually, the Advertisement Interval option is only really useful
in the case of unusual (non-handover related) packet loss.  In other
cases (where adjacent networks are configured with the same RA
intervals), the new RA beacons will always arrive before 2*Interval
timeout occurs.

My principle concern is designing MD to work even when
there's a possibility that a second Router on the
link will advertise a different set of prefixes to the
router currently in use.  Your earlier discussions with
JinHyeock about eager bindings illustrated these issues
(and I think illustrated NUD or Router discovery to be
required, in some cases.

What I'm interested in doing is to detect movement without
ND probing.  Once a  decision has been made that movement
may have occurred, bidirectional checks may be done or
subsumed by other actions.

To get to this point we have to be sure that reception of
an RA is sufficient to indicate movement without further
packet transmission.

> probe it periodically to reconfirm bi-directional reachability), there is no

Few hosts will be able to abstract virtual links from their
existing IPv6 implementations.  We're looking for a system
which may be used in all MNs.  This means that rigourous
behaviours will have to be applied to hosts (maybe not how
IETF works), or unambiguous meaning will have to be attached
to signalling.

This means that it will have to work in systems where
connectivity to two links through the same interface is
possible too. This seems to be one of your concerns.

At this stage I agree that NUD is the right tool to check that
you are (still?) connected to a router.  JinHyeock has pointed
this out to me recently.

I don't want to do NUD to the OLD router every time I move,
if I can help it though.  This is because NUD takes too long
in the case of failure.  I want to use NUD to check I can
reach a router which is a good candidate.   This may be
a router I have just received an RA from.

> MN would use in this case to track a specific current default router for the

I think that L2 triggers are a good way of disambiguating
RA's from multiple routers, but understand they're not
always available.

In this case, the ID will never be ambiguous, since it
must be unique on links across the area of interest
(global uniqueness would guarantee this too).
A router address is a good way to go as you say, but
when all the routers share the same concept of a link,
the ID is the same to prevent spurious selection of
routers.

This is once again aimed at performing movement detection
without trying to check the presence of the 'old'
router, which is prohibitive.  Only ID change (or lack
of ID) requires movement detection, and possible ND probing
(in the case where movement cannot be disambiguated).

For the mentioned overlapping links though, they won't share
a broadcast domain. In this case such routers could not share
an ID, and would have different IDs (or none at all?).
Certainly the type of interface used in this case could
have rules to guarantee reachability of the new router
before undertaking mobility signalling, and hysteresis effects
to prevent ping-pong.

> that routers will always multicast RAs, even when sending them in response

Yesterday JinHyeock told me that NUD is better than RD
for this purpose (I'm convinced).  I'm trying to avoid the
probing completely to the old AR, though.  Speeding it up
is fine, if we can prevent harm to the network.

> however, I'd initiate immediate NUD probing of my current default router in

Indeed, the ID && lladdr is valid and costs no more.
When this is specified it is worth mentioning.

> interference, and the MN may not implement any L2 triggers to be able to

Realistically, that is what I am saying (prefer IDs), but Brett Pentland
pointed out that if the prefix of your CoA, advertised by the 'current'
router is also in an RA you receive with an ID, then the 'current'
router implicitly gets an ID tag (it is on the same link).

Preferring IDs is better since reception of a third RA (without an ID) 
after this stage can require probing unless IDs are already in use.

> contain very little information.

As I said earlier, a good router implementation should send
(one/some) PIOs it thinks are important in every RA.  In this
case we don't care if a prefix exists but is not advertised in
normal multicast RA procedures, and will not configure a CoA
from such a prefix.

I don't think this is unreasonable or error-prone,  given the
environment we're talking about.

I hope that this helps clarify some of the reasoning which we've used
in this method.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Apr 2003 15:23:41 +0200 (CEST)

> coverage areas. I've attached the text.

I think at least part of the issues that appear when comparing RFC 2461
and MIPv6 is that RFC 2461 assumes that there is a hard boundary
between different links.

With wireless there might not be a hard limit - it depends on whether
the L2 actually can make such a distinction - and in any case
we've never tried to nail this down.
For instance, in 802.11 one could declare that different SSIDs are
treated as different links from IP's perspective, and that the same
SSID is viewed as one link.

Due to this lack of clarity we end up with the MIPv6 spec sort of treating
each default router as a different link, and sort of treating each
on-link prefix (or is it prefix with the A-bit set?) as a separate link.

If we had a clearer view of what constitutes a separate link for wireless
media we'd have a much better ground to stand on when discussing movement
detection.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Apr 2003 10:13:37 -0700

Erik,

> media we'd have a much better ground to stand on when discussing
movement

The difficulty here, as with many issues in wireless, is that it really
depends on the particular link technology. For 802.11, it is perfectly
possible to have two routers connected up to overlapping sets of access
points and advertising different subnet prefixes. For cellular, this is
not possible.

One thing that might help here is something like a BCP to define what,
from an IP standpoint, is considered to be an optimal (or best) network
configuration for wireless. In 802.11 networks, it is of course possible
to get a clean mapping of subnets to wireless links, and if it turns out
that this is a better configuration for Mobile IP, then perhaps we
should record that.

            jak

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 11 Apr 2003 10:28:29 -0700

Greg -

Please see my responses to your responses inline below.

- Ed

> Maybe, depending on the link layer ;)

Yes. But, what is the goal of MIPv6? I think that supporting VoIP with
seamless handovers is only one of the goals. Many applications will be happy
with handover latencies exceeding 60 msec, even on the order of seconds,
providing there is some kind of fast recovery of their active TCP
connections once the MN comes back on link with a new primary CoA (i.e.
wireless TCP fast retransmits, for example).

If you want to support seamless handovers for VoIP with MIPv6, then you had
better include some optimizations in the link-layer for this, and definitely
use L2 triggers for your MIPv6 MD. Someone posted a cool draft recently
about optimizing 802.11b to include this kind of ID information at the
link-layer, IMHO you should be working MD at that level not at the L3 level.
Then, L2 and below can send a L2 trigger to L3 indicating L3 movement. I
believe this is the draft:
ftp://ftp.nordu.net/internet-drafts/draft-paultan-seamless-ipv6-handoff-802-
00.txt

> JinHyeock and I have all been looking into this issue closely.

This network ID you are talking about having the network broadcast, so that
the MN can quickly determine if it has moved just by listening to these
broadcasts (i.e. it is not any kind of bi-directional reachability
confirmation, more like a beacon with an ID): I have seen exactly this done
before in a real live network implementing a precursor of Mobile IPv4,
specifically it is CDPD (packet data overlay over AMPS cellular). They put
this ID in the MAC layer frame broadcast by the cellular base station
(MDBS), the actual field is called the area group color code. This is how
the M-ES (CDPD MN) can determine that it has executed a L3 move, at the MAC
layer. This is a L2 trigger.

I strongly believe it is wrong to attempt to implement this kind of
trigger/detection at the L3 layer (IPv6, ICMPv6). It belongs in L2 and
below, the protocol layers that have immediate and first-hand knowledge of
the status of the physical layer.

If your specific network MAC and link-layers provide sufficient L2 triggers,
then this can definitely speed up the process of MD when those triggers are
used by MIPv6 MD. Since we are providing a generic MN implementation, we
provide an API that enables the user application to notify our MN of L2 and
L3 movement. We also implement MIPv6 default movement detection, in which
case we call that same API ourselves to notify of L3 movement when we detect
that our current default router has become unreachable per NUD.

> main issue:

Perhaps. I don't have enough experience with this, but I'd expect that if
beacons are used that they will likely not contain any prefix information
since they are being broadcast so frequently that the amount of bandwidth
they consume is likely a consideration.

> being connected to a link-local subnet.

Actually, there are already significant differences between normal host
operation and MIPv6 MN operation. Look at the operation of the MIPv6 MN when
it returns home - that is certainly not normal host operation (note: it is
possible for the MN to forget that it had active bindings, and power up on
the home network getting a DAD failure on its home addresses since the HA is
still defending them - this is something a MN supporting "return to home"
functionality needs to be able to handle, and is certainly not normal host
operation). Assuming you already read the text for MIPv6 issue #170
"sloppiness about overlapping coverage areas", here is my MIPv6 MN design
for that part (which shows you how my MIPv6 MN acts significantly different
from a typical host, and also what I mean by "virtual link" when applied to
the MN's current default router):

1) Use Single Current Default Router Discovered on Mobile Interface
The MN MUST only have a single current default router at a time, which was
discovered on the mobile interface (NOTE: the "mobile interface" could
change - for example, at one point in time the Bluetooth interface might be
the "mobile interface", and later the 802.11b interface would be the "mobile
interface", but at any given point in time there is only one "mobile
interface" in the MN which is used for discovering default routers,
auto-configuring care-of addresses, performing move detection, etc.). For
example, the MN does not switch/alternate between default routers in the
default router list to "load balance" but instead just continues using the
same default router (discovered on the mobile interface) as long as it is
still working and is considered bi-directionally reachable.

2) Restrict/Filter Prefix Discovery and Parameter Discovery to Current
Default Router
The MN only auto-configures prefixes (for CoAs) on the mobile interface
which were discovered by receiving RAs from the current default router (i.e.
the source address of the RA must be the link-ocal scope address of the
current default router). The MN filters Parameter Discovery in the same
manner. Obviously, this same filtering could not apply to Router Discovery,
or the MN wouldn't be able to discover new routers. So, maintainance of the
default router list bypasses this filtering, with the exceptino given in #1
above of sticking with the same current default router as long as possible.

3) Faster Invalidation of Old Prefixes When Switch to New Default Router
Whenever the MN changes its current default router (i.e. as a consequence of
L3 move processing), there is the possibility that it also has to change its
primary care-of address. It may not have actually moved (i.e. L3 move) but
it needs to treat this as a possible move. Therefore, all prefixes
discovered on the mobile interface with the old current default router
should be immediately deprecated (preferred lifetimes set to 0) and should
have their valid lifetimes set by the MN to some low number that allows a
little time for soliciting the new default router and discovering the
complete set of prefixes it is using (i.e. in the solicited RS, which should
contain more complete information), to see if the set of prefixes has
changed. Old prefixes will be expired sooner using this method. When the old
prefix expires, and the MN was using it for its primary CoA, that primary
CoA is invalidate, which is the MN's indication that it needs to
auto-configure and select a new primary CoA from the new set of mobile
interface prefixes (discovered from the new current default router) and then
update the bindings in the HA and CNs that it communicates with to have them
use its new primary CoA.

> intervals), the new RA beacons will always arrive before 2*Interval

??? No, it is still useful even in that case. Part of listening for beacons
is also verifying that they were sent by your current default router. So, if
you receive beacons from a different router, that doesn't count to verify
that you can still hear your current default router.

> router currently in use.

Yup. Apparently, this is a valid network configuration. From the MN
standpoint, it can look exactly like the overlapping coverage areas
scenario. In this case, my MN would treat that 2nd router as a different
virtual link.

> Your earlier discussions with
> ND probing.

Please do it at L2 and below then, and use L2 triggers to communicate that
information to L3. It does not make any sense IMHO for L3 to be determining
what link L2 is attached to purely by listening only, L3 also needs
confirmation of bi-directional reachability which is why ND probing needs to
be used by L3. But, if L2 says "a L3 move just occurred" to L3 in a L2
trigger, then L3 can skip the ND probing, immediately assume its old current
default router is now unreachable, deprecate all prefixes discovered on that
router and set their valid lifetimes to a small value as described in #3
above, and then immediately start soliciting for a new router by sending RS.
That is how it should work. If you are trying to have L3 guess the L2
information without needing L2 triggers to communicate that information, you
will end up with a sloppy solution that may or may not work reliably (and
generally probably won't). Please understand what L2 triggers are for and
use them.

> Once a  decision has been made that movement

> an RA is sufficient to indicate movement without further

I'm in complete disagreement with this approach.

With CDPD, there was a fairly sophisticated way to monitor channels in use
in adjacent RF cells, check the current channel we were locked onto
(connected to a specific MDBS, or CDPD access point) for signal quality
(RSSI, BER, etc.), and check channels in adjacent cells periodically to see
if they offered better signal quality to determine whether or not it was
time to initiate an undirected hop to a better RF channel and MDBS. This was
all accomplished under L3, with *NO* L3 awareness. Actually, with CDPD the
IP mobility part was part of the network/service provider infrastructure,
not part of the MN - the MN kept using the same global home address (w/ no
care-of address) even when switching to a different service provider
network, i.e. even when a L3 move occurred.

There are undirected hops (initiated by the MN), and directed hops
(initiated by the network - I haven't looked into this much yet, but I
believe a lot of the fast handover work has the network directing the
handover). This is fairly mature and well-understand (by the cellular
service providers) technology, but it all occurs UNDER L3. Please do not
attempt to move any of this into L3, it just won't work well (L3 is not
supposed to know about the state of the link-layer, MAC layer, physical
link - excepting through something like L2 triggers, where the
link-layer/MAC directly communicates that information to L3). Please use L2
triggers instead, and look at enhancing L2 to communicate this information
to L3. That is the correct way to do what you are proposing.

> existing IPv6 implementations.

??? MIPv6 already requires ND hacks as it is in MNs that return to home.
What is the difference between doing that versus making some other changes
in ND for implementing this "current default router == virtual link"
behavior that I've described? It is the simplest way to implement the
following requirements that are in the current MIPv6 spec, section 11.5.3
"Using Multiple Care-of Addresses":

"The mobile node 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."

"Whenever a mobile node 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."

Are you planning on implementing these requirements, or just ignoring them
and hoping that the MN implementation somehow works? This clearly affects
Prefix Discovery, and ties it to MD and Router Discovery. This requires some
special code in the MN. The easiest way to implement this is how I described
above, which is to use the current default router to filter Prefix Discovery
(and possibly Parameter Discovery), and then when you switch away from that
current default router you need to make sure that you don't keep any prefix
information you learned from that router when you switch to a new current
default router that doesn't advertise those same prefixes (indicating that
L3 movement has occurred).

> We're looking for a system

Well, this can appear to be the case when the MN is operating on the fringe
between two links that each have marginal signal quality, and keeps
ping-pong'ing back and forth between them, and there are insufficient L2
triggers to tell L3 that that's what is happing, so the MN L3 appears to be
operating on two links simultaneously - about the same as if you had a badly
designed network with overlapping coverage areas using the same RF channels
and interfering with each other, bleeding together into one "super-link"
when in fact they aren't actually.

> you are (still?) connected to a router.  JinHyeock has pointed

Thank you. And that uses ND probing. I'm glad I could change your mind ;-)
Actually, I changed JinHyeock's mind first I believe ;-)

> if I can help it though.

I totally agree, NUD does take too long. If you get a L2 trigger telling you
a L3 move has occurred, you skip NUD, and immediately declare that the
current default router is unreachable - which is really fast.

> This is because NUD takes too long
> reach a router which is a good candidate.

As explained above, you cannot reliably do this kind of stuff at L3, it must
be done at L2 and below where there is immediate and first-hand knowledge of
the state of the physical link, and then communicated to L3 using L2
triggers.

> RA's from multiple routers, but understand they're not

YES! But then when they aren't available, you are stuck with MIPv6 generic
default movement detection (i.e. NUD) which is slow. So, if you want faster
MD, you must have L2 triggers. I see no problem with that, I don't know why
you have a problem with that.

> router, which is prohibitive.

ND probing is prohibitive? I think not.

> Only ID change (or lack

Hysteresis is implemented in L2, not L3. L2 decides to switch links. L3 does
not.

> for this purpose (I'm convinced).

Yippee!

> I'm trying to avoid the
> probing completely to the old AR, though.

Nope. You should not switch to a "new" router if the old current default
router is still perfectly good, i.e. is still bidirectionally reachable.

> Speeding it up

Well, let's see...
1) receive RA from router A, ID is 999
2) switch to router A
3) receive RA from router B, ID is 888
4) switch to router B
5) start at step #1 again, repeat the whole scenario many times in sequence
because router A and router B are actually on the same link and are quickly
sending beacons with different IDs.

End result:
You never get a change to register a new primary CoA, because you keep
switching current default routers too quickly. Therefore, applications
running on the MN experience a total loss of network connectivity. That's
pretty harmful, in fact this is awful.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 11 Apr 2003 11:58:13 -0700

> each default router as a different link

Yes. That's unavoidable, IMO.

> and sort of treating each

??? No, I'm not treating each on-link prefix as a separate link. But, it can
only be on-link if it is discovered using the current default router (which,
as we agree is treated as a separate link). Once I move from that router to
a new router, if I've done a L3 move then very likely (unless it is one of
those weird "non-on-link" prefixes that can't be used for on-link
determination) that prefix is no longer on-link (the way to tell is to check
if the new router advertises that prefix), in which case I must invalidate
that prefix.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 11 Apr 2003 12:18:10 -0700

James -

> points and advertising different subnet prefixes. For cellular, this is

Ahh, but for cellular, it is possible that if the L2 layer doesn't implement
sufficient hysteresis in its channel selection algorithms (assuming that it
can do undirected hops, which in some cases of cellular all hops are
directed by the network), and also if it doesn't provide L2 triggers to
notify L3 of link movement, that L3 could be blissfully unaware of the fact
that L2 is actually switching back and forth between physical links fairly
rapidly (refer to the ping-ponging scenario), and then those 2 links could
look like a single link to L3. That's why L3 needs to lock on to a single
current default router which it has confirmed to be bi-directionally
reachable, treat it as being a virtual link for the purpose of filtering
Prefix Discovery (and perhaps also Parameter Discovery), and then only
switch from it when it has confirmed that it is no longer bi-directionally
reachable. NUD and ND probing works well for this purpose.

Also, w/ regards to move detection being dependent on the link technology, I
completely agree, that's why L2 triggers are needed to communicate link
movement and possibly even subnet movement events to L3. I see nothing wrong
with that. L3 should not be trying to detect link movement on its own - L2
and below is the place where that detection belongs, because the link-layer
and the MAC layer is the part of the stack responsible for selecting the
physical link that the device operates on etc. (or at least knowing when
that link is no longer usable, we assume that this information is then
communicated to some other functional module under L3 that selects a new
channel/link to start operating on and I'd argue that is still part of L2).

> that this is a better configuration for Mobile IP, then perhaps we

See:

Another alternative is to define the appropriate L2 triggers for a given
link-layer. This draft RFC defines a way to implement a 802.11 L2 trigger
for notifying L3 of subnet movement. It requires some (minor?) changes to L2
for 802.11, and some network configuration, but then probably all solutions
that work well for MIPv6 to optimize handovers will require something
similar. My whole point is this work should be done at L2, not L3. L3 needs
to be kept independent of link-layer and physical layer, if possible
(reference IPv6 Address Resolution, which is completely independent of the
link-layer technology). Currently, L3 move detection in the MIPv6 base spec
is independent of the link-layer (excepting the fact that it relies on
seeing RAs - a PPPv6 link likely won't be sending RAs, unless it needs to
support MIPv6 generic move detection, but then PPPv6 link open events could
be used to indicate a L3 move via L2 triggers obviating the need for MIPv6
generic move detection). The fact that MIPv6 can take advantage of L2
triggers is a good thing, that's where you can pull in the link-layer
specific information to optimize move detection. From the above referenced
draft:

"3.1 Instantaneous/Faster Movement Detection
    In this section, we describe how to configure the Extended Service
    Set Identifier (ESSID) of an infrastructure 802.11 network such that
    it includes the L3 identifier/Information of its associated AR or
    network.

    With this embedded identifier (e.g. IP address or prefix
    information), MN can quickly detect movement to a new L3 subnet,
    thus avoiding transmitting unnecessary L3 messages (i.e. Router
    Solicitation/Advertisement) and delays.

    To perform instantaneous movement detection, we recommend that APs
    to include the subnet prefix information for their associated AR
    (Subnet-Router-Anycast-Address) into the ESSID. This recommendation
    allows MN to discover new network when it established a L2
    connection with the new AP in an instantaneous manner."

Thanks.
- Ed

---

From: Markku Savela <[email-masked]>
Date: Fri, 11 Apr 2003 22:18:33 +0300

> From: "Ed Remmell" <[email-masked]>

> as we agree is treated as a separate link).

I'm wondering about the terminology here, namely use of "default
router". In IPv6, the default router is just just one that is
advertising non-zero router lifetime. Not a big deal, but the term
usage might cause confusion, and wrong implementations for strange
configurations.

Nothing prevents following configuration:

  R1: advertises as default router, no prefixes
  R2: advertises the prefixes, but is not default router.

Nodes pick prefixes from Router2, but traffic non-local traffic goes
to Router1. Or, as we had here on office network

  R1: default router, Prefix 1 (A=1, L=1)
  R2: default router, Prefix 2 (A=1, L=1)

A node can pick either router as "default router", but can use both
prefixes for building own address?

Additionally, there may be routers that announce more specific routes
for some destinations (without announcing additional prefixes
themself). Depending on destination, packets maybe directed to
different routers (e.g. nodes may automaticly implement also other
than just default routes).

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 11 Apr 2003 12:43:40 -0700

Markku -

Please read through some of the other emails I sent recently (today,
yesterday) on this thread. I think the key to understanding this is:

Erik Nordmark said:
"I think at least part of the issues that appear when comparing RFC 2461
and MIPv6 is that RFC 2461 assumes that there is a hard boundary
between different links.

With wireless there might not be a hard limit - it depends on whether
the L2 actually can make such a distinction - and in any case
we've never tried to nail this down."

Not only may there be overlapping RF coverage areas (for example), but it is
perfectly valid for there to be overlapping (but distinct - from the
routers' perspectives) networks on the same link. Two different routers may
be broadcasting different sets of prefixes on the same link, this is a valid
network configuration although they do not necessarily consider the other
routers prefixes to be on-link, just their own.

Something more likely is that L2 doesn't implement sufficient L2 triggers to
notify L3 of link movement. L3 can be blissfully unaware that the MN is
moving to different links. This link movement can occur frequently enough
(i.e. "ping-ponging") that the MN actually receives RAs from two different
routers on two different physical links so that they look like they are on
the same physical link when in actuality they aren't.

Our MN will only use a current default router (when MIPv6 is enabled) that
broadcasts a global scope prefix. So, if there are other routers on the link
that do not broadcast prefixes, we don't care, we won't use them.

Thanks.
- Ed

> From: Markku Savela [mailto:[email-masked]]
> Sent: Friday, April 11, 2003 12:19 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: MD identifiers ?
>
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 11 Apr 2003 15:03:04 -0700

I guess the main difference between MIPv6 and RFC-2461 w/ regards to "what
is a link" is that in the case of RFC-2461, if you have different networks
superimposed on the same physical link (i.e. different routers broadcasting
different sets of prefixes), it doesn't matter, because attachment to the
link is a permanent thing, hosts are fixed-end-systems not mobile nodes. In
the MIPv6 case, mobile nodes are moving, so their connectivity to different
physical links will change as they move. Also, with RF, there can be
differences in receive signal quality/signal strength versus transmit signal
quality/signal strength, so even though a mobile node is receiving RAs from
a router, it doesn't mean that its transmissions will be heard by that
router, in which case it really isn't on that specific link. In some cases
of cellular wireless, receive and transmit actually occur on different RF
channels. Also, the access point may have a lot of transmit power whereas
the mobile node may not. Also, there can be interference sources,
self-interference (fading), environmental factors that affect signal
quality. ...

Thanks.
- Ed

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Apr 2003 13:32:32 +0200 (CEST)

> if the new router advertises that prefix), in which case I must invalidate

If we have two routers both advertising the identical set of prefixes,
why would we have to treat that as two links?

Perhaps by "sort of" above is misstated, but I don't think the current
model in the MIPv6 spec is as simple as each router is treated as
a separate link.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 14 Apr 2003 09:34:36 -0700

Erik -

> model in the MIPv6 spec is as simple as each router is treated as

But... consider what processing must be done on the MN to figure out if two
routers it receives RAs from are both on the same link, indicated by them
broadcasting the same on-link prefix in one of the many RAs they broadcast.
How many RAs need to be checked by the MN to make this determination? Over
what period of time? RAs will contain incomplete information. Some RAs, i.e.
responses to a RS, should be fairly complete w/ regards to the prefix
information they contain, but generally there is no way for the MN to tell
the difference from a "solicited" RA and an unsolicited RA, because both are
typically sent to the same multicast destination address. Then there are RAs
that are sent as beacons. I'd expect beacon RAs to contain very little
information, since in some cases they will be broadcast so frequently (i.e.
to speed up MN move detection) that if they contained complete prefix
information they would use up significant bandwidth, so better that they
contain as little information as possible. Then there are other unsolicited
RAs, which are expected to contain incomplete information.

I remember with CDPD (sorry to go off on that tangent, but that's the
relevant part of my experience that I have to compare against) there was a
separate functional module (Radio Resource Management) that managed all of
the M-ES (equivalent to MN) undirected hops. It would process channel lists
sent by each base station containing information on channels in use for CDPD
packet data in the current and in adjacent cells. It would keep all of that
information, in addition to other information obtained via L2 such as
transmit BER, RSSI, etc., in a database in memory, to use to decide when to
do an undirected handover to a new base station and new channel. The
algorithm was fairly complex, and to work well it needed significant field
experience and testing. I'm hoping that the MIPv6 algorithm to keep track of
links, associated routers and on-link prefixes does not need to be this
complex.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Apr 2003 10:14:14 +1000

Hi Erik,

just a quick comment below.

> why would we have to treat that as two links?

I think that this scenario is useful, but Ed and others have
pointed out that the number order and priority of prefixes
which are advertised in an unsolicited RA are not specified
by RFC2461.

If we can guarantee that the prefixes received overlap or
are complete in a received RA (maybe a solicited RA) then
we'll have prefect knowledge about the link from that RA.

> model in the MIPv6 spec is as simple as each router is treated as

Indeed, I think that you are correct.  RFC2461 says itself
that two routers advertising different prefixes on the same
link is correct behaviour.

Use of NUD to disambiguate movement detection can be done
with today's set of assumptions in 2461 and MIPv6.

By developing either stronger advice on deployment of networks
or techniques to provide (pseudo-)guarantees of movement,
we should be able to avoid NUD probing.
I prefer a system which doesn't have a large administrative
overhead, which would occur if all prefixes on a link had
to match or overlap.

Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Apr 2003 12:25:19 +1000

Hi Ed,

Some inline comments below.

> RAs, which are expected to contain incomplete information.

If we assume that receiving one solicited RA (if it can be identified
as such) contains information which uniquely identifies the link,
can the MN use this as a complete movement detection?

The connection has been proven to be bidirectional, and the
link has been identified, which may also identify if the oldAR
is still reachable.  In this case NUD probing is not required,
nor is bandwidth wasted with large beacons.

This is what I think is worth working towards. Today we can
receive a solicited RA in a very short time (if we don't delay RS)
with OptiDAD and FastRA, or with a cached RA on an AP.

> links, associated routers and on-link prefixes does not need to be this

I think that MD is primarily interested in tracking of
CoA validity first (for packet reception) and
second default router choice (for packet transmission).

Since current technology is insufficient for these
purposes in the limited timeframe available to support
real time data, I'm pretty sure that some sort of link
tracking will be required.

I'll only be interested in link-layer approaches if
network layer approaches aren't viable though.

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 16 Apr 2003 08:34:03 -0700

Greg -

> can the MN use this as a complete movement detection?

Yes, but... the only solicited RA that I'm aware of is the response to a RS
sent by the MN that has a unicast destination address that can be confirmed
to belong to the MN, however RFC-2461 recommends against routers sending
that type of RA.

Personally, I don't see what the need is to map a router to a specific link.
It is always possible that due to the "hidden node" scenario that can occur
with RF that nodes that are supposed to be on the same link simply aren't
reachable by the MN due to physical obstacles etc. I think it is sufficient
for the MN to use a single default router at any given time that has been
confirmed to be bi-directionally reachable, and to continue using that
router as long as it is still bi-directionally reachable. Once it isn't, the
MN switches to a new default router, regardless of whether or not it is on
the same "link" doesn't matter at this point (except from the standpoint
that if it is on the same link, it is possible but not guaranteed that it
advertises the same prefixes, in which case the MN may not need to change
its primary CoA).

> nor is bandwidth wasted with large beacons.

Yes. NUD probing should still be implemented as a fallback, however. I'd use
the solicited RA as evidence of bi-directional reachability, and update the
Neighbor Cache entry for the router to indicate that it is REACHABLE.

> with OptiDAD and FastRA, or with a cached RA on an AP.

Sounds reasonable.

> second default router choice (for packet transmission).

Both are important.

> tracking will be required.

Good luck. It seems like the wrong design decision to me, generally protocol
layers are supposed to be kept independent.

I remember that there was a discussion prior to IETF56 about macro-mobility
versus micro-mobility, and how Mobile IPv6 is only appropriate for
macro-mobility but other mechanisms besides Mobile IPv6 should be used for
micro-mobility (to achieve the kind of fast handover performance needed to
support real-time data). I'm not very well read on this topic, but I'd think
you should be since it relates to the work you are doing here.

> network layer approaches aren't viable though.

Fair enough.

Thanks.
- Ed

---

From: Greg Daley <[email-masked]>
Date: Thu, 17 Apr 2003 10:54:10 +1000

Ed Remmell wrote:
> reachable by the MN due to physical obstacles etc.

I think that it's straightforward, that if any node on the fixed
portion of the network is available birdirectionally, then
another node also on the same fixed link, contactable through the
same acces point is reachable.

You are confusing being able to talk bidirectionally to an access point
or wireless terminal with being able to talk to the fixed 
infrastructure, beyond a reachable access point.

Routers which aren't on the same fixed infrastructure are not on the
same link.

> I think it is sufficient

The issue is that current RA techniques do not allow the MN
to determine that a new router is a valid (or invalid) target
for handover due to movement to a new link.
NUD or an additional mechanism is required for that.

> Neighbor Cache entry for the router to indicate that it is REACHABLE.

Indeed.  This is ok, if you can be sure that the RA was sent to
the MN (solicited) rather than received through RA beaconing.

> layers are supposed to be kept independent.

Don't worry about me delving down into the link layer.
I'll try to keep things strictly network oriented.

> you should be since it relates to the work you are doing here.

We've been trying to figure things out for a while, and
may get to a candidate idea soon.
Your feedback and that of others on the list has definitely
been helpful in this regard.

I'm sure we'll discuss this more after Easter.

have a good break.

Greg