Subject: [mobile-ip] Mobile IPv6 Issue 154: ND Constants (Router Solicitation)

From: Greg Daley <[email-masked]>
Date: Thu, 05 Dec 2002 14:14:28 +1100

I'm interested in reaching a consensus and getting text
for this issue.

There seems to be two sets of constants:

RA Multicast Advertisement Intervals.
(MinRtrAdvInterval, MaxRtrAdvInterval).

RS Retransmission constants.
    (Delaying 0 to MAX_RTR_SOLICITATION_DELAY
             before sending RS)
    Retransmitting RS's more often than is
             mandated in RFC2461

To date most of the discussion has been on RA intervals,
but also there's some need for agreement on RS constants
in the MIPv6 draft.

the discussion summary is here:
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue154.txt

I'll be sending out two emails, tackling each message [RA|RS]
separately.

(jari: do we need a separate issue for RS?)

Here is a list of issues as I see it.

There are two main issues with Router Solicitation:

* MIPv6 defines a set of retransmission parameters for router
   solicitations in section 7.6.

   These only provide guidelines as to how many retransmissions,
   are possible, not strict minimums.

   I'm not sure of the specific reasoning for these modifications,
   or any experience people may have for these issues.
   At this stage, I'd be inclined to move it to a new document,
   if there's no strong performance effect.

Recommendation: Remove 7.6 unless people have a strong operational
     need.

* There has been some discussion, mainly with regard to FastRA,
   about the presence of a random delay up to
   MAX_RTR_SOLICITATION_DELAY (1 second in rfc 2461),
   before either sending a DAD or a Router Solicitation packet.

   This variable is specified by RFC 2461 in order to stop
   bombing of access networks on link up/RA reception.

   In MIPv6 it is only mentioned with respect to DAD.
   since most MIPv6 nodes will be doing DAD on RA reception,
   this is a potential issue, but only when the MN has definitely
   moved to a new link, rather than any time (so it is MN
   movement related).

   The contentious issue is whether MN's perform RS on link-up
   triggers, which could have some impact on (unspecified..)
   link layers, since the MN's could do this every time they
   attach to a network, regardless of whether the L3 prefix is
   changed (although this also applies somewhat to DAD, when
   many nodes move L3 simultaneously and receive their first RA)
   Both of these cases can occur in the case of base-station failure,
   although the impact of the simultaneous RS is unknown (as
   distinct from L2 probing and association).

   At this stage, MIPv6 does not mention shortening the delay before
   Router Solicitation.  Since there is no way for a generic MIPv6
   MN to know why they are moving networks (and solve the bombing
   problem), I suggest that we leave any reference to the timer
   out of MIPv6 draft.

   In this case, we rely on the strength of the SHOULD from 2461,
   and whether implementors follow that specification.  If a solution
   becomes available in the future which removes this (potential)
   danger, then we can specify that along with other optimizations.

Recommendation: No Change in MIPv6.