[zeeshanlakhani]

This began as a normal, ol' doc fix (I've kept the history here, including #364, which has been closed). The external multicast group API endpoints had documented scope that didn't match the handlers. Group and source validation already ran in the handlers, but this moves the checks into the request types themselves, at the deserialization boundary, and revisits the address rules for consistency. This includes relaxing the IPv6 scope rules from the earlier validation branch, preserving flexibility vs forcing some kind of extra Oxide-driven policy.

Then, this review question came along:

Could these documented constraints also be made self-enforcing via newtypes? Your decision whether doing so is worth the API churn and code complexity, but imo it's worth considering.

My response to this grew into newtypes for group addresses, sources, and NAT targets; plus, ASM/SSM request variants. The rollback work
and cleanup account for much of this diff.

Creation requests now check group/source constraints during
deserialization. Updates validate addresses at parse time; source family and SSM validations still run against the group address within the handler(s).

Group addresses (typed as ExternalMulticastIp):

Group addr / condition	Outcome	Spec / qualification
Not multicast	Reject	Group addresses must be multicast.
224.0.0.0	Reject	RFC 1112 §4: "guaranteed not to be assigned to any group", not a MUST NOT; rejected because it can never name a group.
232.0.0.0	Reject	RFC 4607 §4.3: SSM null address.
232.0.0.1–232.0.0.255	Accept	RFC 4607 §4.3: reserved for IANA allocation.
232/8	SSM	RFC 4607 §1.
ff0x::, with all-zero group ID	Reject	RFC 4291 §2.7.1: "reserved and shall never be assigned to any multicast group"; rejected on the same reasoning as 224.0.0.0.
IPv6 scope 0	Reject	RFC 4291 §2.7: reserved; packets must be discarded.
IPv6 scopes 1, 2	Reject	RFC 4291 §2.7: interface-local and link-local traffic cannot be forwarded past those scopes.
IPv6 scopes 3–f	Accept, subject to other checks	RFC 4291 §2.7; RFC 7346. Scope f is reserved; received packets are treated as global scope.
ff04::/64	Reject	Oxide underlay reservation.
Rest of ff04::/16	Accept, subject to other checks	Outside the reserved /64.
Flags ~ R=0, P=T=1, plen=0, either X value	SSM	RFC 4607 §1; RFC 7371 §4.1.2: ff3x and ffbx flag patterns; reserved fields ignored.
IPv6 SSM with nonzero network prefix	Accept	RFC 4607 §1: a system should treat all of ff3x::/32 as SSM. RFC 3306 §6 requires a zero prefix only of the node that's forming the address.
ff3x::4000:0	Reject	RFC 4607 §4.3: reserved SSM null address.
IPv6 SSM group IDs 0–3fff:ffff	Accept	RFC 4607 §1: invalid as SSM addresses (assigned with P=T=0, RFC 3307 §4.1), but a router may drop them, so we don't reject them at the API.
IPv6 SSM group IDs 4000:1–7fff:ffff	Accept	RFC 3307 §4.2; RFC 4607 §4.3: IANA allocation range.
IPv6 SSM group IDs 8000:0–ffff:ffff	Accept	RFC 3307 §4.3.1, §4.3.2 and RFC 10028 §3: dynamic range where host SSM allocation is f000:0–fcff:ffff.
Flags ~ P=1, T=0	Reject	RFC 7371 §4.1.1: P requires T.
Flags ~ R=1 without both P and T	Reject	RFC 7371 §4.2.2: R requires P and T.
Flags ~ R=1 with plen outside range 1–64	Reject	RFC 3956 §4: embedded-Rendezvous Point (RP) prefix-length bounds.
Flags ~ R=1 with RIID=0 (RP Interface ID)	Reject	RFC 3956 §6.3: zero RIID is excluded.
Flags ~ R=1 with derived RP in ::/16, fe80::/10, or ff00::/8	Reject	RFC 3956 §4: unusable embedded RP address.
Prefix-based ff2 bits	Ignored	RFC 7371 §4.1.1, §4.2.1: reserved bits ignored on receipt.
Prefix-based, R=0: rsvd bits	Ignored	RFC 3956 §3: reserved bits ignored on receipt.
Flags ~ R=1: low rsvd nibble becomes RIID	Checked	RFC 3956 §3, §6.3: reject RIID=0.
IANA assignment or an embedded-prefix scope comparison	Not checked	No registry lookup or scope comparison with the embedded prefix.

Exact sources (typed as ExactSource) and request constraints:

Exact source / condition	Outcome	Spec / qualification
Multicast source	Reject	RFC 1112 §6.2; RFC 4291 §2.7: multicast addresses cannot be packet sources.
0.0.0.0, ::	Reject	RFC 1812 §5.3.7 and RFC 6890 for 0.0.0.0, as with 0.0.0.0/8 specified below; RFC 4291 §2.5.2: an unspecified IPv6 source is never forwarded.
127/8, ::1	Reject	RFC 1122 §3.2.1.3; RFC 4291 §2.5.3: loopback sources cannot be forwarded outside the host.
255.255.255.255	Reject	RFC 919 §7; RFC 1122 §3.2.1.3: broadcast addresses cannot be source.
169.254/16, fe80::/10	Reject	RFC 3927 §2.7; RFC 4291 §2.5.6: link-local traffic cannot be forwarded off-link.
0.0.0.0/8	Reject	RFC 1122 §3.2.1.3 permits initialization use; RFC 1812 §5.3.7 recommends against forwarding these sources.
240/4	Reject	RFC 1112 §4: reserved Class E space; the special-purpose registry marks Source=False (RFC 6890 §2.2.2).
::ffff:0:0/96, ::/96	Reject	RFC 6890 §2.2.3 marks the mapped form Source=False; RFC 4291 §2.5.5.1 deprecates the compatible form. This matches OPTE.
100.64/10	Accept	RFC 6598 §4: shared address space is usable within an operator's network.
Source family differs from group family	Reject	Same-family (S,G) check; matches OPTE.
SSM create or supplied update source list: no exact source, or Any	Reject	RFC 4607 §2: SSM requires a source-specific channel.

Includes:

• Exact-source rejection set and same-family checks match OPTE Include subscriptions.
• In the new API version, omitted sources on the update/modification preserve the source filter, while the older endpoints convert this omission to Any (wildcard), which SSM will reject.
• External groups use caller-supplied addresses. No IANA-assignment lookup or embedded-prefix scope check occurs there.
• Regarding rollback, DpdError::Unwind now collects multiple rollback failures. HTTP errors preserve the initial status and use a special ROLLBACK_FAILURE_ERROR_CODE in propagation. Restoration can re-add missing bitmap, replication, and route entries.
• chaos-feature tests inject ASIC failures and check usage counts after rollback, including failures during the rollback op itself.
• dpd-client now maps ExternalMulticastIp and UnderlayMulticastIpv6 to the dpd-types newtypes (via progenitor replace), allowing clients to reject bad addresses when parsing, before a request goes out.

[cfzimmerman]

This PR is large enough that I didn't close-review everything. Please lmk if you'd like me to take a look at any particular changes or if you decide to break this into separate PRs.

Otherwise, I'll approve with the understanding that we'll talk through some of the open questions. And since this is the last open PR I see, here are my thoughts on the stack in total:

---

You have done tremendous work for multicast and have fixed some legit dendrite tech debt along the way. While there's feedback along the margins, this is fantastic, and the goal imo is to validate and merge on a reasonable timeline.

Your CI tests already establish solid confidence. I think the remaining pieces are system-level validation. For both voxel and a rack(lette), we should probably test both multicast and existing network functionality pretty aggressively. Perhaps have an agent write up a torture test suite looking for regressions and bugs? The goal is just to smoke out any possible regressions or subtle issues.

Finally, I'd like to plan out how this will work with R24 and other dendrite PRs. In my understanding, once this merges, we can't uprev omicron's dendrite for other projects until the omicron side of multicast merges. Is that correct? If so, then we should probably synchronize all the dependent multicast merges, right? Otherwise an important bug or security fix could get stranded behind landing multicast in omicron. Please lmk if I'm misunderstanding this.

I appreciate that getting this all merged will require a lot of coordination. Please lmk if you want to discuss or need support landing this stack.