Add support for multi pref64 in rtadvd and rtadvctl
Details
To test, you need to configure
your rtadvd.conf with a pref64 prefix:
bridge0:\
:raflags="oal":rltime#600:\
:addr="2a01:e140:cafe::":prefixlen#64:\
:pref640="2a01:e140:dead:ff::":\
:pref641="3fff::":pref64len1#64:then simply check the rtadvctl show output.
Also verified with tcpdump.
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 69823 Build 66706: arc lint + arc unit
Event Timeline
Convert action_show_pref64 from int to void and use assertion to address @zlei comment.
| usr.sbin/rtadvctl/rtadvctl.c | ||
|---|---|---|
| 630 | RFC 8781 states in section 5: "This option may appear more than once in an RA" Looking at rtadvd.h it is a list but as I much as I understand here, we would always only print a single prefix? | |
| 631 | What's the point of a separate printf here compared to doing that in action_show_pref64()? File style? | |
| usr.sbin/rtadvctl/rtadvctl.c | ||
|---|---|---|
| 630 | Unfortunately, the current implementation does not work that way. | |
| 916 | 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. | |
| usr.sbin/rtadvctl/rtadvctl.c | ||
|---|---|---|
| 916 | Yes, referencing the RFC that would explain where the values come from should be good enough. | |
Here is the output sample of rtadvctl:
% mdo rtadvctl -v show bridge0: flags=<UP,TRANSITIVE,PERSIST> status=<RA_SEND> mtu 1500 DefaultLifetime: 10m MinAdvInterval/MaxAdvInterval: 3m20s/10m AdvLinkMTU: <none>, Flags: MO, Preference: low ReachableTime: 0s, RetransTimer: 0s, CurHopLimit: 64 AdvIfPrefixes: yes Next RA send: Thu Jan 15 00:58:25 2026 Last RA send: Thu Jan 15 00:58:06 2026 Prefixes (1): 2a01:e140:1234:5678::/64 (CONFIG, vltime=30d, pltime=7d, flags=LA) DNSSL entries: spmzt.net (ltime=15m) PREF64: 2a01:e140:cafe:ff::/96 (ltime: 3m45s) 2a01:e140:dead:ff::/64 (ltime: 3m45s)
@bz: I also tested it and I can confirm that it works using wireshark.
@zlei: I had to rollback the assert part, as there's no need for p64_enabled anymore. so I removed it.
@glebius should these minor changes to the manual be approved by the manpages group?
I also found a bug related to flag inconsistency. However, I will fix it in another revision.