Monday, September 28, 2026
Transparency Report #016: Dual-Stack Rollout for NTP Service
What are Transparency Reports?
As a community‑operated and governed virtual internet exchange, FurrIX maintains
a commitment to open and honest communication with its members. From time to
time, operational work may occur that affects the exchange or its supporting infrastructure.
When this happens, the FurrIX operations team publishes a transparency report to
ensure all members remain informed. As a hobbyist‑rooted vIX, we aim to keep
communication clear, accessible and practical to the best of our ability.
What Happened
For the past month, FurrIX has operated its public NTP server (time.furrix.zone) as an
IPv6-only node participating in the NTP Pool Project. To expand time synchronization support
for legacy clients, curious onlookers and external parties, the operations team evaluated
enabling IPv4 access for the service.
This has finally made it through a three step process to be instated as a part of our core
fabric. The first step was a proposal via our Discord from the engineer to our governing
board, which was originally IPv6 only. That proposal got wearily expanded to include IPv4
only after the base IPv6 service went live. The board put the proposal to vote and our
handful of members agreed this was the right way forward. Which led to step three, the
actual IPv6 deployment and reaching out to our upstream about the IPv4 side before we
deployed legacy support.
Because public facing UDP/123 services carry an inherent risk of being targeted by botnets for
NTP reflection/amplification floods, FurrIX proactively opened a ticket with our upstream provider
prior to turning on IPv4 traffic in order to give their engineering and legal departments the chance
to review our operations and provide their stance. We outlined our planned destination IP
(204.12.237.197), NAT topology, daemon choice (chrony), fabric level traffic shaping and rate
limits, as well as other deployment details.
Upstream network engineering reviewed and approved the deployment. They confirmed that
operating a public NTP node on our assigned IPv4 allocation is permitted, provided we understand
the possible risk and noted that upstream automated flow-monitoring is active and may step in
automatically should anything become a problem.
Changes to the Exchange
Following upstream clearance, our volunteers enabled dual-stack functionality for the NTP service:
- Upstream Address Forwarding & Firewall Rules:
Configured a destination NAT rule on our Nardoragon router (OPNsense) forwarding inbound
UDP/123 traffic on 204.12.237.197 to the internal VM instance (10.0.5.3) with
registered firewall rules
- Daemon Configuration (chrony):
Updated chrony.conf on the NTP VM to bind to both its IPv6 GUA (2602:f992:e0:c0::3)
and internal IPv4 interface (10.0.5.3). Active application-layer rate limiting
(ratelimit interval 3 burst 8) and restricted command port bindings (bindcmdaddress ::1)
remain strictly enforced
- Bandwidth & QoS Enforcement:
The 6 Mbps inbound/outbound traffic shaper on the FurrIX fabric remains active for all
NTP traffic. This caps peak packet processing at approximately ~6,500 PPS and helps
limit NTP traffic to limit saturation of exchange links or degradation of routing performance
- DNS Updates:
Added an A record (204.12.237.197) alongside the existing AAAA record for
time.furrix.zone
- Registered IPv4 with NTP Pool
Created a server entry for the IPv4 endpoint
Are Exchange Operations Affected?
Not really, I mean at least in the bad sense that most of you worry about.
The NTP service continued operating without interruption on IPv6 during the rollout and
IPv4 queries began arriving upon DNS propagation. Exchange QoS, peering fabrics and
core routing remain completely unaffected.