Re: RDNSS sanity checks (was Re: 6MAN WG Adoption Call: draft-gont-6man-nd-opt-validation-01)

[Tomoyuki Sahara <[e-mail]>]

>> In Section 10 (about RDNSS option) of this document:
>> 
>>>   The Lifetime field specifies the maximum time in seconds that a node
>>>   may use the IPv6 addresses included in the option for name
>>>   resolution, with a value of 0 indicating that they can no longer be
>>>   used.  If the Lifetime field is not equal to 0, it MUST be at least
>>>   1800 (MinRtrAdvInterval) and at most 3600 (2*MaxRtrAdvInterval).  If
>>>   the RDNSS option does does not pass this validation check, it MUST be
>>>   ignored.  However, the rest of the ND message MAY be processed.
>> 
>> The maximum value of the lifetime field should be larger.
>> 
>> Although the description above is consistent with RFC6106 (says the value
>> of lifetime field SHOULD be <= 2*MaxRtrAdvInterval in section 5.1), it is
>> too short because only a few packet losses removes DNS server information
>> from hosts on the subnet as described in
>> draft-gont-6man-slaac-dns-config-issues-00.
>> 
>> The suggested "default" value in the draft is 5*MaxRtrAdvInterval.  The
>> "maximum" value must be larger than it.  I don't have any good technical
>> reason, but I propose 10*MaxRtrAdvInterval which is twice the default
>> value.
> 
> The thing here is that since s document is all about validation of
> incoming packets (as opposed to how you set the Lifetime for the packets
> you send I'm not sure what we can do about this *in this document*). May
> be this calls for resurrecting draft-gont-6man-slaac-dns-config-issues-00?

Yes.  I think the draft provides a reasonable and practical solution for an
operational problem caused by too short lifetime value in RFC6106.

And if the sentence "If the Lifetime field is not equal to 0, it MUST be ...
at most 3600 (2*MaxRtrAdvInterval)" remains unchanged in this document, it
will prevent operators configuring their routers to send RFC6106 options
with lifetime greater than 3600, because he expects client PCs will ignore
the options according to this validation rule.  So I suggested larger
maximum value here.  Or, the validation rule should be removed for now.


Thanks,
Tomoyuki