is tested, in the same manner as above. Here
.I addr
is as from
-.BR inet_ntop .
-Since this is not completely predictable for IPv6,
-for IPv6 a variant of
+.BR inet_ntop ,
+and
+.I port
+is the (local) TCP or UDP port number, expressed as an unsigned
+integer in the minimal non-zero number of digits.
+.PP
+Thirdly, for IPv6 only: since the textual representation from
+.B inet_ntop
+is complicated to predict, a variant of
.I addr
-is also tested which does not contain any ommitted zeroes or colons.
+is also tested which does not use the double colon abbreviation:
+each 16-byte chunk expressed in the minimal nonzero number
+of hex digits (i.e. with leading zeroes removed), the chunks
+being separated by colons as is conventional.
.PP
-Thirdly, if the question is still unresolved, the file
+Fourthly, if the question is still unresolved, the file
.BI /etc/authbind/byuid/ uid
will be opened and read. If the file does not exist then the binding
is not authorised and
.B ENOENT
.RI ( "No such file or directory" ).
.PP
-In each case above,
-.TP
-.I port
-is the (local) TCP or UDP port number, expressed as an unsigned
-integer in the minimal non-zero number of digits, and
+So for example an attempt by uid 432
+to bind to [2620:106:e002:f00f::21]:80
+would result in authbind calling
+.I access(2)
+on, in order,
+.RS
+.B /etc/authbind/byport/80
+.br
+.B /etc/authbind/byaddr/2620:106:e002:f00f::21,80
+.br
+.B /etc/authbind/byaddr/2620:106:e002:f00f:0:0:0:21,80
+.RE
+If none of these files exist, authbind will read
+.RS
+.B /etc/authbind/byuid/432
+.RE
+and search for a line to permit
+the relevant access; examples of lines which would do so are:
+.RS
+.B 2620:106:e002:f00f::21,80
+.br
+.B ::/0,80
+.RE
.PP
If a read error occurs, or the directory
.B /etc/authbind
lines in
.BI /etc/authbind/byuid/ uid
files are silently ignored (as are lines whose
-.I addr4
+.I addr
has non-zero bits more than
.I length
-from the top) or where
+from the top) or where some
.I min
is larger than
.IR max .