RFC 7931, "NFSv4.0 Migration: Specification Update", July 2016Source of RFC: nfsv4 (tsv)
Errata ID: 4822
Reported By: David Noveck
Date Reported: 2016-10-06
Section 5.8 says:
Note that the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated. Given that it is already highly unlikely that the clientid4 XC is duplicated by distinct servers, the probability that SCn is duplicated as well has to be considered vanishingly small. Note also that the callback update procedure can be repeated multiple times to reduce the probability of further spurious matches.
It should say:
Although the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated, different servers may use the same approach to the construction of such verifiers, raising the probability that two distinct servers might inadvertently assign the same verifier value. The fact that the servers in question have assigned the same clientid4 may raise this probability. In order to guard against the possibility that such assignments might cause two distinct servers to be incorrectly considered the same, the SETCLIENTID procedure mentioned above needs to be repeated. Repeating the procedure once is sufficient to ensure that the successive confirm values SCn, SCn' generated by these repeated SETCLIENTID operations cannot all collide with a verifier previously received by the client when communicating with IPn.
It appears that the original text underestimated the probability inadvertant of duplication of clientid4's and verifiers. Existing servers while conforming to to RFC7530, may generate the same sequence of clientid4's when they all happen to be rebooted at the same time. The new text deals with this possibility and ensures that two different servers cannot be considered the same.