accel-ppp.git/accel-pppd/ipv6, branch 1.15.0

ipv6: remove obsolete three-server DNS limit

2026-10-05T23:19:48+00:00

The legacy limit matches RFC 6106's recommendation that hosts treat three learned RDNSS addresses as sufficient. That was host-side repository guidance, not a limit in the RADIUS, DHCPv6, or RDNSS encodings. RFC 8106 obsoletes RFC 6106 and explicitly removes the recommendation to limit learned RDNSS addresses to three, leaving the number to local policy. It instead recommends the ability to store at least three addresses when DNS information comes from multiple sources. Store both configured and per-session servers in reusable contiguous arrays. Start with a four-address, 64-byte allocation, grow geometrically, retain capacity across reload or reauthorization, and free session storage only at teardown. Bound advertised lists by actual DHCPv6 and router-advertisement packet space. Warn when servers have to be dropped for lack of room, as the fixed limit used to, skip the DNS search list rather than write it past the end of a full advertisement, and drop the stale three-server wording from the [ipv6-dns] documentation. Link: https://github.com/accel-ppp/accel-ppp/commit/4f562467dbdf819395e138617c2a057e02595b9e#r197212083 Link: https://www.rfc-editor.org/rfc/rfc6106.html#section-5.3.1 Link: https://www.rfc-editor.org/rfc/rfc8106.html#section-5.3.1 Link: https://www.rfc-editor.org/rfc/rfc8106.html#appendix-A

ipv6: use a dedicated type for per-session DNS

2026-10-05T23:18:41+00:00

DNS-Server-IPv6-Address carries a full IPv6 address, so storing it in ipv6db_addr_t also carried an unused prefix length and flags. Introduce dedicated DNS list and address types so the representation matches the data. Suggested-by: Vladislav Grishenko <566150+themiron@users.noreply.github.com> Link: https://github.com/accel-ppp/accel-ppp/commit/4f562467dbdf819395e138617c2a057e02595b9e#r197215804

ipv6_nd: do not overrun the advertisement buffer with prefix information

2026-10-05T23:18:41+00:00

The prefix information options are written into a fixed 1024 byte pool buffer with no bound at all, one 32 byte option per address on the session. A session carrying more than about thirty addresses therefore writes past the end of the buffer. Skip the prefix information of the addresses which no longer fit and warn about them. The loop also installs the addresses on the interface, so keep doing that regardless of how much room is left in the advertisement.

dhcpv6: reject malformed options and bound relay replies

2026-09-07T19:08:04+00:00

Reject duplicate Rapid-Commit/AFTR options, validate AFTR labels, and limit relay nesting. Measure reply space from the allocation, propagate allocation failure through reply builders, and encode relay lengths correctly. Adapted from Ritika Chopra's accel-ppp-ng PR #40, T8473/T8474/T8475. Upstream already has the status, AFTR-printing and inner relay bounds fixes. Co-authored-by: Ritika Chopra

utils: centralize unaligned integer accessors

2026-09-01T06:08:47+00:00

dhcpv6: validate option and relay boundaries

2026-09-01T05:55:54+00:00

Enforce fixed option prefixes centrally, bound nested relay messages to their declared payload, require one valid Relay-Message, and decode ORO and diagnostic fields without unaligned or oversized reads.

Merge pull request #351 from nuclearcat/various-fixes-on-compiler-warnings

2026-09-01T05:52:55+00:00

Various fixes on compiler warnings

ipv6: assign DNS servers per session from RADIUS

2026-08-12T07:42:35+00:00

The ipv6_nd and ipv6_dhcp modules could only advertise the DNS servers configured in [ipv6-dns], the same set for every subscriber. RFC 6911 defines DNS-Server-IPv6-Address (attribute 169) for exactly this, and the attribute was already in the shipped dictionary and in attr_defs.h; nothing read it. Give struct ap_session an ipv6_dns list, filled by the radius module from that attribute, and have both modules advertise it when the session has one: in the RDNSS option of the router advertisements, and in the DNS_SERVERS option of DHCPv6 replies. Sessions without a list of their own keep getting the configured servers, so nothing changes for anyone not sending the attribute. The selection is a single ipv6_dns_get() shared by both modules rather than a copy in each: they already duplicate the whole [ipv6-dns] parser, and two copies of a precedence rule are two chances to drift. It caps what it returns, so neither the RDNSS option length (one byte, in units of 8) nor the router advertisement buffer can be pushed around by what a RADIUS server sends. The radius module caps at the same 3 servers as [ipv6-dns] accepts and warns once when a reply carries more. An Access-Accept which carries the attribute replaces the whole previously assigned list rather than appending to it, so a re-authorized session ends up with the servers of the latest reply and not with a concatenation. One which does not carry it leaves the current list alone, which is how the IPv4 MS-Primary-DNS-Server attribute already behaves. ipv6_dns_test.c covers the selection: assigned wins over configured, empty list means "nothing assigned" rather than "no DNS", the cap holds for both sources, and a caller with no room gets nothing rather than a stomped buffer. Wired into the ASAN/UBSAN workflow. Inspired by the per-session IPv6 DNS support in accel-ppp-ng (commit 2df6eb99), reimplemented against mainline's ap_session and ipdb types.

dhcpv6: read the elapsed time and preference options at their real width

2026-08-10T06:43:09+00:00

print_time() read a 32 bit word out of the Elapsed Time option, which RFC 8415 21.9 defines as exactly two octets, and clients include it in almost every message they send. With verbose enabled that is a two byte read past the option on every DHCPv6 transaction: ERROR: AddressSanitizer: heap-buffer-overflow READ of size 4 in print_time dhcpv6_packet.c:499 The value was not byte swapped either, so what got logged was not the elapsed time. Read two octets, convert them, and copy them out rather than dereferencing a pointer into the packet that need not be aligned. print_uint8() has the same shape, so check the length there too before reading the Preference octet.

dhcpv6: fix end pointer of an encapsulated relay message

2026-08-10T06:42:23+00:00

opth->data already points past the option header, so adding sizeof(*opth) again counted it twice and left endptr four bytes beyond the end of the Relay-Message option, and possibly beyond the received packet. The bounds check at the top of the option loop is written against that endptr, so on the next pass it accepted an option header that lies outside the buffer and read opth->len from it. ASan on a Relay-Forward packet: ERROR: AddressSanitizer: heap-buffer-overflow READ of size 2 in dhcpv6_packet_parse dhcpv6_packet.c:158 The end of the relayed message is the option payload, nothing more.