Subject: Changing RS Reply Timing for Mobile IPv6

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Oct 2002 09:29:12 -0700

Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS
reply timing:

http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt

I didn't see an announcement from the drafts editor in this group.

In summary, the draft amends RFC 2461 to allow at most one router on a link to
reply immediately to an RS instead of waiting a random amount of time between 0
and MAX_RA_DELAY_TIME. The router is allowed to reply to at most MAX_FAST_RAS
since the last unsolicited multicast is sent. If this number is exceeded, the
router rolls over to scheduling a multicast RA as soon as possible. This is
intended to avoid DoS attacks on the router.

We believe this amendment will be necessary for achieving good handover
performance with standard Mobile IPv6 movement detection. If the mobile node is
capable of detecting when the link changes, it can immediately send an RS rather
than wait for a multicast RA. This can significantly decrease the amount of time
required for movement detection. In addition to theoretical considerations, we
have some amount of implementation experience with the existing movement
detection algorithm to suggest that the RS reply protocol in RFC 2461 could have
moderate to severe performance limiting effects on standard MIPv6 handover.

We would like to have review and discussion of this draft prior to the WG
meeting in Atlanta, and finish up the discussion there, with a goal of making
this a WG document. The Mobile IP working group will be finishing up the MIPv6
draft soon, and we would like to be able to publish this draft in about the same
time frame, so implementors have some guidance.

                    jak

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 08 Oct 2002 13:28:10 -0400

James

I think that the draft is missing a trigger mechanism for a fast RA
response.  What I mean is, that if any node not requiring a fast RA
joins the link, it will use up a fast RA that will potentially cause
delays for a node that would really like a fast answer.

You could take one of the reserved bits from the RS (there are 32 of them)
and turn it in to the fast RA flag.  The node that would really like
a fast answer must set the flag.  The flag will be ignored by routers
that do not support fast RAs (according to 2461).

This doesn't get rid of the malicious node consuming all of the fast
RAs, but it provides the ablility to send the RAs sparingly.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Oct 2002 11:04:37 -0700

Vlad,

Good point. This would work for the normal circumstance, though it would not
deter an attacker, as you point out.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 09 Oct 2002 09:43:12 +1000

Hi Vlad,

I'm not sure that there is a requirement to use a fastra flag.

There may be situations where multiple nodes come up on a link
in the duration between multicast advertisements but this may be
handled by the MAX_FAST_RAS being set high enough to handle this.
In the case where many nodes come up on the link, it may
be more effective to schedule a multicast RA in any case.

I'm pretty sure that there's no problem on a network configured
for fastra to give a few of the advertisements to non-mobile nodes.

I believe that the presence of an 'F' bit in a router solicitation
was discussed when the FastRA came up.  In that solution, nodes
desiring FastRA (MIPv6 MN's?) set the bit in every RS, since they
could not determine whether the network supported FastRA or not,
or (possibly) where they were (otherwise they wouldn't be sending the
RS).

If the bit is used, why wouldn't anyone just ask for fast response
anyway?  Isn't it reasonable to expect that all nodes desire
fastest possible autoconfiguration?

I don't see any reason to create an optimization which only applies
to especially configured subnets (access networks?) and then tell
people not to implement it in clients, since it's for MIPv6 mobile
nodes only.

Greg Daley

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 9 Oct 2002 17:37:56 +0900

Hi

James Kempf wrote

> If the mobile node is
> than wait for a multicast RA.

According to RFC 2461, mobile host should not send RS immediately. Before sending 
RS, it should execute random delay like below. 

"Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."

Are you suggesting that above term should be loosened too? I wonder whether it is 
good idea to change current Neighbor Discovery protocol that much. I am afraid there 
may be side effect like RA overabundance.

Most people will agree that Movement Detection mechanism should be improved. It 
takes too much time for mobile node to detect link-change under current Neighbor 
Discovery protocol.

Hence we need to consider the following 2 items.

1) How to improve Movement Detection Algorithm?
2) How to incorporate the result of 1) to current Mobile IPv6 work?

For 2), MIPv6 implementators should be provided of the results of 1). It will be useful 
to produce an informative draft and make implementators aware of it.

For 1), I think more discussion is needed. And I have proposed an alternative method. 
In the proposal, AP caches Router Advertisement message and sends it to a new 
mobile node as soon as L2 association is made. You can find more details in below.

http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 09 Oct 2002 10:07:45 -0400

Greg

> be more effective to schedule a multicast RA in any case.

This is really the situation.  When the nodes that come up really
need a ultra fast configuration they can request the fast RA.
When the nodes don't care, multiple solicits may answered with a
single multicast RA.

> for fastra to give a few of the advertisements to non-mobile nodes.

Yes, but I consider that wasting resources that could be better used
otherwise.

> fastest possible autoconfiguration?

Not really.  Most stationarry nodes (my workstation, file server, etc...)
don't really need the fast RAs.  They work fine with basic ND mechanisms.
The goal behind the Fast RA draft, as I see it, is to help mobile nodes
identify new links that became available.

> people not to implement it in clients, since it's for MIPv6 mobile

No, we can't tell people not to implement them.  Anyone can implement
anything.  It's just that it has to be implemented to be used.

The way the draft is written right now, a node that may not gain the
full benefit of the fast RA may get a fast response.  That may lead
to condition where a node that really wants a fast RA to get a
delayed multicast RA defeating the point of the draft.

-vlad

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Oct 2002 09:02:28 -0700

> I'm not sure that we are loosening that.  The rest of the quoted
> paragraph reads:
> 
>   "If a host has already performed
>    a random delay since the interface became (re)enabled (e.g., as part
>    of Duplicate Address Detection [ADDRCONF]) there is no need to delay
>    again before sending the first Router Solicitation message."
> 
> I took the paragraph as meaning that the RS should be delayed when the
> host first comes up to avoid synchronization with other devices after
> some abnormal event, but that movement is part of normal operation, not
> expected to be synchronized with other hosts and so the delay is not
> required.  Any thoughts?
> 

Agree.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 9 Oct 2002 10:54:44 -0700

> > expected to be synchronized with other hosts and so the delay is not

Sometimes handovers can also be synchronized (to some extent)
among a set of mobile nodes, for example when they are
traveling in the same transportation vehicle.

alper

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 10 Oct 2002 10:15:14 +0900

Hi Brett

Thanks for your kind comment. 

As you may know, random delay of RS is 'to alleviate congestion' 
as the following states:

" This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."

Therefore, we should examine if there will be congestion in case 
"mobile nodes send RS without delay when they detect link changes".

Two cases come in to my attention.

1) As Alper pointed, sometimes handovers can be synchronized (to 
    some extent) among a set of mobile nodes. In that case, there would 
    be congestion.

2) Sometimes (abnormal) link change occurs without movement. For 
    example, if AP (not AR) recovers from power failure or admin changes 
    AP for new one, mobile nodes will detect link change and send RSs 
    simultaneously. To prevent this, mobile nodes should be able to 
    distinguish normal link change (caused by movement) from abnormal 
    link change (caused by power failure or AP exchange).

With the above reasons, I think there will be congestion without random delay. 

Do you think it's negligible?

Regards,

---

From: Greg Daley <[email-masked]>
Date: Thu, 10 Oct 2002 11:50:01 +1000

Hi Vlad,

> When the nodes don't care, multiple solicits may answered with a

It really depends on your multicast advertisement interval.
We're unlikely to see ANY rs's from fixed nodes within a relatively
short interval (say 10s on networks supporting MN's). So the
only situation where this will be a problem is if the network is
just coming up, and all devices are (re?)configuring their addresses.

In the unlikely event that an MN changes to that network during these
few seconds, if it doesn't do the 'SHOULD wait before sending RS' which
all other nodes will be doing, then it is likely to be one of the
first to receive response in any case.

> Yes, but I consider that wasting resources that could be better used

Since the resource is renewed continuously, we're only talking about
fallback to multicast in the case of DoS or the link coming up.

> identify new links that became available.

As far as I can see, there's only an issue with sharing fastRA's:
When a link comes up and multiple nodes all need access. In this case,
stationary nodes are already running and are just as likely to have
existing conversations as MN's.  They will all need as fast a response
as possible.

> delayed multicast RA defeating the point of the draft.

I'll have to say that I really don't see a problem on links
which have few fixed nodes.  In the case where a router
is configured especially for supporting MN's, I don't think
that there is any harm in generating a fastRA even when it is not
asked for.

Also, I don't see the harm in explicitly requesting fastRA in RS's,
so, any recommendation short of a "MUST NOT reply with fast RA to
packets where 'F' bit is 0" is fine with me.

I'm just trying to make minimal changes to node function.

Greg

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Oct 2002 22:33:01 -0400

> In summary, the draft amends RFC 2461 to allow at most one router on
> a link to reply immediately to an RS instead of waiting a random
> amount of time between 0 and MAX_RA_DELAY_TIME. The router is
> allowed to reply to at most MAX_FAST_RAS since the last unsolicited
> multicast is sent. If this number is exceeded, the router rolls over
> to scheduling a multicast RA as soon as possible. This is intended
> to avoid DoS attacks on the router.

This presumably requires some per-link or per-router configuration?
I.e., how does the "one" router that is allowed respond more quickly
get picked? Given that, putting the words in a standards track doc
seems with regards to how a collection of routers behaves seems a bit
odd. I see that this document just says how this is configured is out
of scope for the document....

Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router
delays a random amount of time between 0 and .5 seconds before
responding. So, on average, .25 seconds. That's not a terribly long
delay. What exactly is the application that  can't deal with this kind
of a delay?

Then there is more to getting link connectivity than just finding a
router. You may have to generate an address, and then invoke DAD.  But
DAD (on an Ethernet) requires a 1 second delay. That's a much bigger
factor than the RS delay. Is this not also an issue?  I.e., what is so
critical about getting an immediate RS but that doesn't also have an
issue with some of the other ND/addrconf/DAD constants. Will
addressing the RS delay alone *really* solve the problem here, and if
not, shouldn't we be thinking about the more general problem and
working on finding a solution that deals with all the potential delay
spots?

Thomas

---

From: "Richard Nelson" <[email-masked]>
Date: Fri, 11 Oct 2002 11:57:57 +1000

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
> delay. What exactly is the application that  can't deal with this kind

Plenty, voice particularly, but it might also kill your TCP transfer.  Also
saying average .25 sec fudges the issue, 10% of the time it will be greater
than .45 sec so users will normally see near the worst case some of the
time.
> issue with some of the other ND/addrconf/DAD constants.

Yep it is a big issue, but there are solutions to that as well.

Will
> working on finding a solution that deals with all the potential delay

Well the general solution is fast handovers and that is being worked on.
But without fast handovers, if you use fast RAs and HMIP and get rid of DAD
somehow, the MIPv6 handover can be a few 10s of milliseconds.  If you have a
fast L2 handover (A big if as it turns out) it is possible that MIPv6
handovers could be really useful even with real time traffic.

Richard.

---

From: Greg Daley <[email-masked]>
Date: Fri, 11 Oct 2002 14:40:27 +1000

Hi Richard & Thomas

I'd just like to indicate that we have seen the delay
for router advertisement to be a significant delay
in MIPv6 handovers, since there is no DAD in the case
where a mobile node moves back to a previously visited
network.

In this case, the RS/RA delay is the biggest factor
in the L3 handover time (dwarfing signalling since we
use HMIPv6).

Even in the case of fast handovers for MIPv6, any delay
before the receipt of an RA can cause performance
degradation, because a node cannot determine if it is on
the correct access network until it receives this
advertisement (and thus cannot finalize its address
acquisition and signalling).

Each of the delays in the handover are discrete issues,
related to the design of the original protocols (which are
good, but not tuned for mobility).

There may be an integrated solution, which gets around
most of these issues, but there are also several simple
modifications which I think should be considered to DAD and
neighbour discovery (where the delays occur). Since they
may be deployed without harm to other systems, nor
complicated reliances on Link-layer technologies.

I think that a co-ordinated approach to these issues
is needed, rather than a single integrated solution.

Greg Daley

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 11 Oct 2002 11:15:38 -0700

Greg,

> where a mobile node moves back to a previously visited

How is that so? Of course the chances of some other
node claiming your node's IP address while it's gone
are even less, but still it is not impossible. So, you can 
choose to not use DAD by taking this risk... Is this what
you mean?

alper

---

From: "Richard Nelson" <[email-masked]>
Date: Sat, 12 Oct 2002 09:39:05 +1000

The short answer is that that is what Linux/MIPL does.  We haven't changed
anything.
The slightly longer answer is that RFCs2461/2462 describe how prefixes are
advertised with a valid lifetime
and that addresses take on that lifetime and can be used until that lifetime
expires.  RFC2461 specifically describes the case where a laptop is
unplugged and is entitled to use its previous address when plugged in again.
The default value for lifetimes is 30 days and infinity is a valid value.

Richard.

----- Original Message -----
From: "Alper E. YEGIN" <[email-masked]>
To: <[email-masked]>; "Richard Nelson"
<[email-masked]>
Cc: "Thomas Narten" <[email-masked]>; <[email-masked]>
Sent: Saturday, October 12, 2002 4:15 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 11 Oct 2002 17:11:38 -0700

> The default value for lifetimes is 30 days and infinity is a valid value.

This lifetime is about "prefix validity". Not "ownership
of an IP address configured based on this prefix".

Any node can attempt to configure any IP address
with a valid prefix. Unless there is another node
defending this address, DAD succeeds, hence IP
address is configured.

In the case of your mobile node being away for a while,
anyone else can claim it's care-of address and configure
it in the absence of your node defending it.

(of course, if there is a home agent on that link, with
this IP address in its binding cache as the home address
of a mobile node, then this home agent can defend the address.
this would be the case if your mobile node is using forwarding
from previous care-of address technique when it moved
to the other visited network)

alper

---

From: "Richard Nelson" <[email-masked]>
Date: Sat, 12 Oct 2002 12:24:41 +1000

What you say is correct of course, but it does not seem to be what current
implementations actually do.

RFC 2462 says "Duplicate Address Detection is performed on unicast addresses
prior to assigning them to an interface..."

If a node returns to an already visited network for which it has defended an
address, does using it again consist of "assigning" it to the interface?  As
you say there is a case why it should, but current implementations, at least
those with which we are familiar, don't work that way.

Richard.

----- Original Message -----
From: "Alper E. YEGIN" <[email-masked]>
To: "Richard Nelson" <[email-masked]>;
<[email-masked]>
Cc: "Thomas Narten" <[email-masked]>; <[email-masked]>
Sent: Saturday, October 12, 2002 10:11 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6

---

From: Greg Daley <[email-masked]>
Date: Mon, 14 Oct 2002 09:04:25 +1000

Hi Alper,

I know it's a risk, especially in Mobile-ip6 case,
but the implementation which we're using (mipl)
doesn't de-configure existing addresses when it
receives an advertisement from a new prefix.
The address is not fully deprecated until the
advertisement lifetime expires.

I'm illustrating what we see if there's no DAD delay,
not necessarily what should be done.

If we have to do full 2461 DAD in every handover
case, even recently visited networks, there's no
way VoIP or real time video services will ever be
deployed in mobile-ip6 environments, using the current
specifications.

RS/RA reply is vital in any case, since until the
RA is sent out, you don't even know if you're on a
different network, where DAD would need to be performed.

There's no use doing DAD just because your link layer
sends you a message saying your link has just come up.

Greg