I'd prefer to convert this into an assertion, given this static function is invoked only by function action_show() and follows the condition rai->rai_pref64.p64_enabled.

Then no need to return a zero.

I agree moving the printf inside action_show_pref64() is better.

Can you please write down a comment that would explain the arbitrary numbers.

Unfortunately, the current implementation does not work that way.
We did not use TAILQ_HEAD inside the struct rainfo the way we have done for other options, such as prefix, rdnss, or dnssl.
Given that our current implementation doesn't provide the ability to use multiple pref64 options at the same time, I will probably have to abandon this revision and start implementing it the standard way, as stated in RFC 8781 section 5, in rtadvd.
I'll try to implement as you said.

The thing that comes to my mind is:

/* RFC 8781 Section 4: Map PLC values to prefix lengths */

The RFC 6052 uses a table to describe the values, as there isn't a straightforward algorithm to implement the mapping.
I have mapped the PLC 0 to 96, and since the other values have a fixed spacing (8-bit), I was able to calculate the rest.

Yes, referencing the RFC that would explain where the values come from should be good enough.

Just style but usually I/we'd sort; not sure what style.9 thinks about this these days.

struct pref64 *prf64;
uint16_t *prf64_cnt;
char ntopbuf[INET6_ADDRSTRLEN];
char ssbuf[SSBUFLEN];
char *p;
int i;
uint16_t prf64len;

That if seems unnecessary given the for loop will otherwise just never be executed?

Not entirely true anymore as you may already have added a pref64 to the tailq and may add more but I think it's fine.
If we wanted to do anything we could print the address as well to known which entry? Just an idea, nothing you have to do.

No spaces between casts:

prf64->p64_sl = (uint16_t)(uint64_t)val64;

I am also not sure if you need the (uint64_t) in between?

This seems wrong. If I am correct you only have one prf64_cnt at the beginning of the buffer and nothing further inter-spaced before/after each record?

In theory that should be "len" as well but there seems to be a possibility in the code that if the count of entries changes between the loops all other kinds of things go wrong as well; seems to not be a concern in this code anywhere (just looked up backwards at dns as well).

This last line is probably a copy&paste error.

Why not use the well known NAT64 prefix here in the example? 64:ff9b::/96
Also do you want to specify a pref64len as well?

Maybe put the pref63 on its own line as well to make it more clear?

You're right, unfortunately none of the KAME code follows our style.
That's why I'm reusing their order of variables declarations.

I thought the same myself. It feels unnecessary. I removed this line before and then rollback it as I didn't want to touch their style.
I will remove it if others also feeling the same.

Nice catch. I'll see what can I do for it.

Again it's clearly style violation and the second cast is not required at all. But they've used the exact double casting over and over in the code.

You're right. I'll fix that.

I don't think I can do it cleanly. pref64 and pref640 are separate entries, and if I use i to log with its options number, like this:

syslog(LOG_ERR, "prefix (%d) length %" PRIi64

For users who use pref64 instead of pref640, it would report prefix (-1) in the syslog.
If I want to remove pref64 option number in case of -1, it would unnecessarily complicate the code.
However, if you think it's better to have it, I can do that.
Personally, I don't really see the value in doing so.

I can use WKP, but this version was shorter and as you know it's not necessary to use WKP in NAT64.
At least, I never use WKP in my infra because at the end you've to advertise that prefix to be reachable.
Personally, I prefer to use my own prefix to not populate my LSDB with routes that I don't own.

I will update the example prefix to WKP. But I will not include pref64len as IMHO may suggest people to use pref64len option even for 96 prefix length which is the default value.
I also will put this prefix into its own line.

I am just thinking that a more detailed example will let the not too IPv6-firm user less puzzled. Alternatively can you expand the doc prefix to something which resembles a mask /96 and isn't all-zero, like was done for the addr= line above?

IMHO, this version is good for a basic example. But I think you're right.
I also was struggling to understand how to write a rtadvd.conf config file.
Maybe we could add another detailed example to this manual to make this less confusing and let people know that they actually can use letter flags?
For example:

re0:\
  :raflags="al":rltime#600:\
  :addr="3fff:cafe::":prefixlen#64:\
  :rdnss0="2620:fe::9":rdnss1="2620:fe::fe":\
  :dnssl="freebsd.org":

What do you think?

I mean:

re0:\
  :raflags="al":rltime#600:\
  :addr="3fff:cafe::":prefixlen#64:\
  :rdnss0="2620:fe::9":rdnss1="2620:fe::fe":\
  :dnssl="freebsd.org":\
  :pref640="64:ff9b::":pref641="3fff:64::":pref64len1#32:
`

Aiuc?