DNA and using 3*MaxRtrAdvInterval [Re: [16NG] Re: Review of the ipv6-over-ipv6cs draft]

[Pekka Savola <[e-mail]>]

On Fri, 2 Feb 2007, JinHyeock Choi wrote:
>> >  DNA for example. For DNA, a host relies on prefixes which were received
>> >  within 3 * Maximum of MaxRtrAdvInterval.
>>
>>  Such behaviour would be incorrect, as RFC2461 says:
>>
>>        AdvDefaultLifetime
>>                       The value to be placed in the Router Lifetime field
>>                       of Router Advertisements sent from the interface,
>>                       in seconds.  MUST be either zero or between
>>                       MaxRtrAdvInterval and 9000 seconds.  A value of
>>                       zero indicates that the router is not to be used as
>>                       a default router.
>>
>>                       Default: 3 * MaxRtrAdvInterval
>>
>>  So it is legitimate to have:
>>
>>   3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000
>>
>>  If what you say is true, DNA specification is incorrect.
>
> I'm not sure why that's incorrect.
>
> First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of
> MaxRtrAdvInterval. (This distinction is sometimes confusing, at least
> to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min
> but MaxRtrAdvInterval may differ from router to router.
>
>        MaxRtrAdvInterval
>                     The maximum time allowed between sending
>                     unsolicited multicast Router Advertisements from
>                     the interface, in seconds.  MUST be no less than 4
>                     seconds and no greater than 1800 seconds.
>
> Second a host simply stops using for DNA operation a prefix which was
> not received within 3 * Maximum of MaxRtrAdvInterval but can keep
> using the prefix as of RFC 2461.
>
> This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale
> prefix information quickly  because prefix lifetime can be quite long,
> days or even weeks, for DNA operation.

OK, it is "correct" in the sense that DNA can certainly, at 3* 
Max_MaxRtrAdvInterval decide that the default router is rather stale 
(at 60% of its maximum lifetime) and stop using it, but Neighbor 
Discovery itself specifies the maximum as 
max{Max_MaxRtrAdvInterval,9000}.

Hence if 3*Max_MaxRtrAdvInverval is felt to be too short a time to 
wake up a dormant host, but 9000 seconds would not be, DNA could be 
fixed to use the rest of the 9000 seconds the same way as ND is 
already using using it.

>> > >  Even if a default route would be lost while in suspend, I don't see
>> > >  this as an issue as immediately when the host gets woken up, the
>> > >  default route could be re-obtained by a) specific RA (if wake up call
>> > >  was sent by the AR -- at the same time or 20ms later) or b) a RS (if
>> > >  host decided to wake up).  Later you also said that when a host gets
>> > >  paged it needs to establish the link, implying that in fact there is
>> > >  some delay before link can be used after paging.
>> > 
>> >  Well... If the AR is configured to send periodic RAs at regular
>> >  intervals (MaxRtrAdvInterval), the AR would end up paging the host and
>> >  waking it up to deliver an RA which is essentially not very useful
>> >  to the host.
>>
>>  If this approach were to be chosen, MaxRtrAdvInterval would be set to
>>  something like 1800 seconds, but for example BS could filter out 80%
>>  of messages, so an RA would only be sent to MS every 8000 seconds.
>>  From the perspective of MS, filtering out RAs is indistinguishable
>>  from it packets getting lost in the network, so this would require no
>>  host modifications.
>
> As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs
> (which happens to be also the Maximum of MaxRtrAdvInterval) and BS
> filters out to deliver RA every 8000 secs.
>
> Then after 5400 secs, from the lack of RAs within 3 * Maximum of
> MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs
> and stop using advertised prefix for DNA operation.

And that is very much due to the way how DNA has been specified, not 
how ND has been specified.  Perhaps DNA should change to look at 
5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than 
just 60% of the maximum.

> If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval,
> filtering out some RAs may give hosts the wrong impression that there
> is something wrong on the router/link.

That's correct in a way, if the hosts are (too) "smart" and e.g., 
report that something odd is going on if there is no RA seen in 30 
minutes.  A dumb host doesn't even need to know what 
Max_MaxRtrAdvInterval and don't care though.

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

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng