Subject: [mobile-ip] Issue 88 proposal for resolution

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Oct 2002 13:06:02 -0700

Hello folks,

Issue #88 a long text, but the overall best resolution is
I think not difficult.  Bottom line:

Make a new tunable constant, and (almost) use Brent's text:

>     To accomodate these values the protocol constant
>     MIN_DELAY_BETWEEN_RAS needs to be adjusted:
> 
>      -  MIN_DELAY_BETWEEN_RAS   0.05 seconds

After much discussion, Jari elaborates and reformulates
that option (the first "..." is "also", which word applied
to some previous text I did not replicate here).

> (2) Make MIN_DELAY_BETWEEN_RAS ... configurable
            .......                     This ensures that current
>     characteristics of RAs can be kept by correct configuration.
>     However, a constant needs to change to a configurable variable
>     and this looks a bit funny specification-wise ;-)

I believe this solution is almost fine, and that it is not too problematic
to change a constant to a configurable variable.  It doesn't seem to
be any worse than adding new mandatory functionality for such equipment
that intends to support Mobile IP, and I don't think that the presence
of such routers would damage pre-existing equipment.

For the funny-looking typography, we could use lower case
instead and then specify that the lower-case variant obsoletes
the upper-case constant from RFC 2461.

If this solution is acceptable, then I think we should also
make the proposal known on the IPv6 mailing list for their
comment, since we are dealing with modification to RFC 2461
which is a product of that working group.

Regards,
Charlie P.

=======================================================================

For convenience, I append the issue text from the website, but do
not include any further comments.

Background: Brett Pentland writes:

> I was just wondering if anyone can
> confirm that the protocol constant "MIN_DELAY_BETWEEN_RAS" defined in
> RFC2461 as 3 seconds only relates to multicast RAs sent in response to
> an RS and thus is unrelated to the configuration variable
> "MinRtrAdvInterval" for unsolicited multicast RAs which is redefined
> in the Mobile IPv6 I-D.
> 
> -----
> 
> Jari Arkko writes:
> 
> MIN_DELAY_BETWEEN_RAS concerns any RA sent to the all nodes multicast
> address, solicited or unsolicited.
> 
> MinRtrAdvInterval concerns unsolicited RAs. These would also be sent
> to the all nodes multicast address.
> 
> We redefine MinRtrAdvInterval in the MIPv6 I-D. It would seem that
> MIN_DELAY_BETWEEN_RAS must also be redefined. Was that your concern?
> 
> -----
> 
> Brett Pentland writes:
> 
> Yes, that was my concern.  I just wasn't sure if it was valid since the
> only place MIN_DEALY_BETWEEN_RAS is mentioned in rfc2461 is in section
> 6.2.6, "Processing Router Solicitations".
> 
> -----
> 
> Jari Arkko writes: Here's proposed text for 7.5
> 
>    ...
>    need to hear its Advertisements), the router SHOULD be configured
>    with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value,
>    to allow sending of unsolicited multicast Router Advertisements more
>    often.  Recommended values for these limits are:
> 
>     -  MinRtrAdvInterval       0.05 seconds
> 
>     -  MaxRtrAdvInterval       1.5 seconds
> 
> =>
> 
>    ...  need to hear its Advertisements), the router SHOULD be
>    configured with smaller MinRtrAdvInterval, MaxRtrAdvInterval, and
>    MIN_DELAY_BETWEEN_RAS values, to allow sending of unsolicited
>    multicast Router Advertisements more often. Recommended values for
>    these limits are:
> 
>     -  MinRtrAdvInterval       0.05 seconds
> 
>     -  MaxRtrAdvInterval       1.5 seconds
> 
>     -  MIN_DELAY_BETWEEN_RAS   0.05 seconds
> 
> -----
> 
> Brett Pentland writes: Yes, that covers it, however
> [Min|Max]RtrAdvInterval are router configuration variables while
> MIN_DELAY_BETWEEN_RAS is a protocol constant so perhaps they should be
> treated separately since, if I understand corrcetly,
> MIN_DELAY_BETWEEN_RAS is not some thing that a user is able to select
> him/herslf. How about something like:
> 
>     ...  need to hear its Advertisements), the router SHOULD be
>     configured with smaller MinRtrAdvInterval and MaxRtrAdvInterval
>     values, to allow sending of unsolicited multicast Router
>     Advertisements more often. Recommended values for these limits
>     are:
> 
>      -  MinRtrAdvInterval       0.05 seconds
> 
>      -  MaxRtrAdvInterval       1.5 seconds
> 
>     To accomodate these values the protocol constant
>     MIN_DELAY_BETWEEN_RAS needs to be adjusted:
> 
>      -  MIN_DELAY_BETWEEN_RAS   0.05 seconds
> 
> Having said that, perhaps it would be better if MIN_DELAY_BETWEEN_RAS
> did only apply to solicited RAs or was a configuation variable since
> changing it to 0.05s means that a node can cause up to 20 solicited RAs
> per second to be generated by a router without the administrator being
> able to intervene.
> 
> -----
> 
> Jari Arkko writes: This text looks good.
> 
> About MIN_DELAY_BETWEEN_RAS: RFC 2461 seems to say that it only
> applies to RAs sent to all-nodes mc address. As this is what we intend
> to do with RtrAdvInterval variables, isn't this already correct the
> way it is? Or are you saying that if in this specific box our configs
> are for the intervals in the second class, the new value for the
> constant dictates that the node will be responding 20 times in any
> case? How bad is that? I realize that for some links this may be
> trouble some, but the pre-condition for this problem to occur is a
> badly behaving host, right?
> 
> (Perhaps I'm just trying to find excuses to not change it to a config
> variable. Specification-wise such a change looks a bit weird.)
> 
> -----
> 
> Brett Pentland writes: Yes.  Perhaps I don't understand the
> relationship between the Mobile IPv6 draft and the existing RFCs.
> Does changing the value of MIN_DELAY_BETWEEN_RAS in this document
> become a change to the protocol constant for all IPv6 routers
> implementing neighbour discovery regardless of whether they have any
> interest in mobile IPv6 or just for those that implement RFC????
> mobile IPv6?  If the former, then a network administrator who is not
> interested in mobile IPv6 might configure a router to send RAs every 3
> seconds, say, but a badly behaved host could cause that router to
> generate all-hosts multicast RAs every 0.05 seconds.  This seems
> undesirable to me, but I admit I don't have a good feel for what is
> acceptable along those lines.  (Note: the same situation exists if a
> network operator buys a router that happens to support mobile IPv6
> even though he has no interest in it).
> 
> PS.  MIN_DELAY_BEWTEEN_RAS is only mentioned in RFC2461 in section 6.2.6
> Processing Router Solicitations.  If if were clarified that it only
> applies to all-hosts multicast RAs sent in response to RSs (and not
> unsolicited RAs) then it doesn't need to be ammended and the problem
> goes away.
> 
> -----
> 
> Jari Arkko writes:
> 
> Brett Pentland wrote:
> 
> > Yes.  Perhaps I don't understand the relationship between the Mobile
> > IPv6 draft and the existing RFCs.  Does changing the value of
> > MIN_DELAY_BETWEEN_RAS in this document become a change to the protocol
> > constant for all IPv6 routers implementing neighbour discovery
> > regardless of whether they have any interest in mobile IPv6 or just for
> > those that implement RFC???? mobile IPv6?  If the former, then a network
> 
> I believe the value of the constant changes for those nodes that
> implement the new MIPv6 RFC.
> 
> > administrator who is not interested in mobile IPv6 might configure a
> > router to send RAs every 3 seconds, say, but a badly behaved host could
> > cause that router to generate all-hosts multicast RAs every 0.05
> > seconds.  This seems undesirable to me, but I admit I don't have a good
> 
> Yes, this could happen.
> 
> > feel for what is acceptable along those lines.  (Note: the same
> > situation exists if a network operator buys a router that happens to
> > support mobile IPv6 even though he has no interest in it).
> 
> Yes. LIke you, I don't have a clear picture if this is OK or not OK.
> 
> > PS.  MIN_DELAY_BEWTEEN_RAS is only mentioned in RFC2461 in section 6.2.6
> > Processing Router Solicitations.  If if were clarified that it only
> > applies to all-hosts multicast RAs sent in response to RSs (and not
> > unsolicited RAs) then it doesn't need to be ammended and the problem
> > goes away.
> 
> Yes. That was the intent of the text, I believe, given that they
> have configuration variables as well.
> 
> So, in conclusion we have the following options:
> 
> (1) Just lower the MIN_DELAY_BETWEEN_RAS constant and suffer
>     the possibility that hosts induce too many RAs even if the
>     config vars are set high.
> 
> (2) Make MIN_DELAY_BETWEEN_RAS also configurable (or invent a
>     new configuration variable). This ensures that current
>     characteristics of RAs can be kept by correct configuration.
>     However, a constant needs to change to a configurable variable.
> 
> -----
> 
> Jari Arkko writes: Issue 88
> (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue88.txt)
> was about the need to lower one of the RFC 2461 constants,
> MIN_DELAY_BETWEEN_RAS because otherwise we couldn't set the router
> advertisement interval (MinRtrAdvInterval) default low enough. So, we
> agreed that this needs to be done.
> 
> However, Brett has brought up an additional complication. RFC 2461 states:
> 
>    "... consecutive Router Advertisements
>    sent to the all-nodes multicast address MUST be rate limited to no
>    more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds."
> 
> This applies to both solicited and unsolicited RAs. In order
> to make MinRtrAdvInterval low enough, we must lower MIN_DELAY_BETWEEN_RAS
> as low as well. However, as a side effect of this we apparently will
> make it possible for also solicited RAs to be generated more often.
> 
> Assume that the administrator has not followed the recommended
> values (say, due to the link characteristics) and is using a higher
> value for MinRtrAdvInterval. Now, since MIN_DELAY_BETWEEN_RAS
> is a constant, not a configuration variable, a host that generates
> many RSes will be able to generate an RA every 0.05 seconds.
> 
> Is this a problem or not? We have the following options:
> 
> (1) Just lower the MIN_DELAY_BETWEEN_RAS constant and suffer
>     the possibility that hosts induce too many RAs even if the
>     config vars are set high.
> 
> (2) Make MIN_DELAY_BETWEEN_RAS also configurable (or invent a
>     new configuration variable). This ensures that current
>     characteristics of RAs can be kept by correct configuration.
>     However, a constant needs to change to a configurable variable
>     and this looks a bit funny specification-wise ;-)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Oct 2002 14:31:32 -0700

Hello folks,

Since there has not been any discussion to the contrary,
I will apply the following changes to the draft and consider
the issue to be closed.

New text in Section 12. Protocol Constants:

      MinDelayBetweenRAs       0.05 seconds
               ..............   
   
   The value MinDelayBetweenRAs overrides the value of the protocol
   constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12].

Regards,
Charlie P.