Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT)

[Bob Hinden <[e-mail]>]

Spencer,

> On Oct 27, 2017, at 10:03 AM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> This isn't my area of expertise, my actual area, or my ballot thread, but ...
> 
> On Fri, Oct 27, 2017 at 11:41 AM, 神明達哉 <[e-mail]> wrote:
> At Thu, 26 Oct 2017 21:43:42 -0700,
> Ole Troan <[e-mail]> wrote:
> 
> > It might be worth noting that if it is inclusive or exclusive has
> > absolutely zero consequence for the protocol.
> 
> FWFIW, an implementation that I know of adopts the "inclusive" version
> of "between" (it doesn't support 6man-maxra so it still only conforms
> to RFC4861):
> 
>     MAYHAVE(val, "rltime", rai->rai_maxinterval * 3);
>     if ((uint16_t)val && ((uint16_t)val < rai->rai_maxinterval ||
>         (uint16_t)val > MAXROUTERLIFETIME)) {
>         syslog(LOG_ERR,
>             "<%s> router lifetime (%" PRIu32 ") on %s is invalid "
>             "(must be 0 or between %d and %d)",
>             __func__, val, ifi->ifi_ifname, rai->rai_maxinterval,
>             MAXROUTERLIFETIME);
>         goto getconfig_free_rai;
>     }
> (https://github.com/freebsd/freebsd/blob/master/usr.sbin/rtadvd/config.c)
> 
> But, more important, I agree with Bob and Ole in that "inclusive" vs
> "exclusive" shouldn't cause an interoperability problem since hosts
> are not supposed to reject an RA for a particular value of router
> lifetime:
> 
>       Router Lifetime
>                      16-bit unsigned integer.  The lifetime associated
>                      with the default router in units of seconds.  The
>                      field can contain values up to 65535 and receivers
>                      should handle any value, while the sending rules in
>                      Section 6 limit the lifetime to 9000 seconds.  [...]
> 
> If anything, if we now "clarify" it to mean "exclusive", at least one
> implementation will now become technically non-compliant.  So, while
> my primary suggestion is not to do anything about it, if we really
> need to say something, I'd suggest clarifying "whether this 'between'
> is inclusive or exclusive does not matter in terms interoperability
> and is left to implementations".
> 
> If the precise meaning of the boundaries set by a MUST requirement doesn't actually matter, I'm not understanding why this is a MUST ...  Adam can speak for himself, but that's what *I* would be confused about.

Adam’s Discuss was for concern about an interoperability problem if an implementation choose to pick 65534 or 65535 seconds for the default router lifetime in the RA it sends.  Both are legal values so will be accepted by the hosts receiving the RA.  The host receiving the RA uses the lifetime to timeout the a default router entry.  A one second difference in 18.2 hours is inconsequential.

The way this works is routers will send RAs well before the timeout happens.  RFC4861 specifies the max and min times when RAs should be sent, and it doesn’t get close to the boundary.

If our goal is to ensure interoperability, I don’t see an interoperability issue here.  I note that RFC4861 where this language comes from is very widely implemented.

Bob

> 
> Spencer, who might or might not be Asking For A Friend
> 
> --
> JINMEI, Tatuya
> 
>