RFC 6975 specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. This signalling does not alter server behaviour, rather it just provides a means to server operators to collect data on client algorithm support to assist in planning future algorithm selection.

The format of the associated EDNS options is defined in RFC6975, Section 3 as follows:

 0                       8                      16
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                  OPTION-CODE                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                  LIST-LENGTH                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |       ALG-CODE        |        ...            /
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

i.e. a 16-bit count, followed by a sequence of 8-bit algorithm numbers.

The use of SHA-1 in NSEC3 is essentially light-weight obfuscation to discourage casual zone walking. Implementation and adoption of successor algorithms seems unlikely, and would in also be most counter-productive. Therefore, while the N3U option is defined here, it is best left unused. As of February 2020, the IANA registry of NSEC3 hash algorithms lists just SHA-1:

This is not expected to change.