feat(router): wip ipv6 only network

[johnae]

No description provided.

[claude]

Claude finished @johnae's task —— View job

---

Pull Request Review: IPv6-Only Network Configuration

Review Tasks

• Read and analyze the modified files
• Review for code quality and NixOS best practices
• Check for potential bugs or configuration issues
• Assess performance considerations
• Identify security concerns
• Evaluate test coverage needs
• Provide comprehensive feedback

---

Summary

This PR introduces IPv6-only network configuration with NAT64 using Jool and DNS64 using CoreDNS. The implementation looks solid but has some areas that need attention before merging.

🟢 Strengths

• Clean transition from dnsmasq to CoreDNS for DNS64 support
• Proper use of systemd-networkd for network configuration
• Good integration of Jool for NAT64 functionality
• Preserved commented code for potential rollback/reference

🟡 Code Quality & Best Practices

1. Unused Configuration Options (modules/router.nix)

   • The upstreamDnsServers option (line 45-48) is defined but never used
   • The disableIPv4 option (line 49-52) is defined but only partially used
   • The dnsMasqSettings option (line 58-61) is no longer relevant with dnsmasq disabled

   Recommendation: Remove unused options or mark them as deprecated with proper migration guidance.

2. Hardcoded DNS Configuration (modules/router.nix:167)

   forward . https://dns.controld.com/1af30lws8zb

   This appears to be a hardcoded ControlD DNS endpoint with what looks like a profile ID.

   Recommendation: Make this configurable via module options to avoid hardcoding sensitive/specific endpoints.

3. IPv4 Handling Inconsistency

   • NAT is conditionally disabled based on disableIPv4 (line 116)
   • But IPv4 forwarding is always enabled (line 207)
   • DHCP configuration for IPv4 is commented out but NAT is still configured

   Recommendation: Clarify IPv4 support strategy - either fully support dual-stack or cleanly disable IPv4.

🔴 Potential Bugs

1. Missing Default Value (modules/router.nix:47)

   upstreamDnsServers = mkOption {
     type = listOf str;
     description = "List of upstream dns server addresses.";
   };

   No default value provided, but the option isn't used anywhere.

2. Missing Default Value (modules/router.nix:51)

   disableIPv4 = mkOption {
     type = bool;
     description = "If ipv4 should be disabled on the local network.";
   };

   No default value for boolean option - will cause evaluation errors if not set.

3. Undefined IP Usage (sagittarius.nix:97)
   The internalInterfaceIP is commented out but the module still references cfg.internalInterfaceIP in multiple places (lines 33, 74, 76).

   Critical: This will cause runtime errors since the IP is used but not defined in the configuration.

🛡️ Security Concerns

1. DNS Over HTTPS Endpoint (modules/router.nix:167)

   • The ControlD endpoint with profile ID 1af30lws8zb is hardcoded
   • This could be a privacy concern if this is a personal profile

   Recommendation: Use environment variables or secrets management for DNS endpoints.

2. Open DNS Resolver (modules/router.nix:165)

   .:53 {

   Binding to all interfaces without restrictions could create an open resolver.

   Recommendation: Ensure proper firewall rules restrict DNS access to internal networks only.

3. Missing Network Isolation

   • No VLAN configuration or network segmentation visible
   • All internal traffic appears to be on the same network segment

   Recommendation: Consider network segmentation for IoT/guest devices.

⚡ Performance Considerations

1. DNS Cache Settings (modules/router.nix:170)

   • Cache TTL of 300 seconds is reasonable but could be tuned based on usage patterns
   • No cache size limits specified for CoreDNS

2. Logging Overhead (modules/router.nix:171)

   • DNS query logging is enabled which could impact performance under high load

   Recommendation: Consider conditional logging or log sampling for production.

🧪 Test Coverage Recommendations

1. IPv6 Connectivity Tests

   • Test IPv6-only clients can reach IPv4-only services via NAT64
   • Verify DNS64 synthesis for A records
   • Test prefix delegation from ISP

2. Fallback Scenarios

   • Test behavior when IPv6 prefix delegation fails
   • Verify DNS fallback if CoreDNS fails
   • Test IPv4 fallback if disableIPv4 is false

3. Integration Tests

   • Test with common applications (web browsing, streaming, gaming)
   • Verify compatibility with various client OS types
   • Test performance under load

📝 Additional Recommendations

1. Documentation

   • Add comments explaining the IPv6-only architecture decision
   • Document the NAT64/DNS64 setup for future maintainers
   • Include network topology diagram or description

2. Migration Path

   • Consider keeping dnsmasq configuration as an option during transition
   • Document how to rollback if IPv6-only causes issues

3. Configuration Validation

   • Add assertions to ensure required network interfaces exist
   • Validate that Jool kernel module is available

4. Monitoring

   • The CoreRAD prometheus endpoint is configured but ensure metrics are collected
   • Consider adding CoreDNS metrics endpoint
   • Monitor NAT64 translation performance

Action Items Before Merge

1. Fix the undefined internalInterfaceIP issue - This is a blocker
2. Add default values for boolean options
3. Make DNS endpoint configurable
4. Add proper documentation
5. Consider adding NixOS tests for the router module

This is marked as WIP, so I assume you're aware of some of these issues. The IPv6-only approach with NAT64/DNS64 is a solid architectural choice, but needs some polish before production use.

[claude]

Claude finished @johnae's task —— View job

---

Pull Request Review: IPv6-Only Network Configuration (Updated)

Review Tasks

• Read and analyze the modified files
• Compare with previous review feedback
• Check if previous issues were addressed
• Identify any new issues
• Provide comprehensive feedback

---

Summary

This updated PR shows progress on the IPv6-only network configuration. Some critical issues from the previous review have been addressed, but several important problems remain that need attention before merging.

✅ Issues Addressed from Previous Review

1. Removed unused disableIPv4 option (modules/router.nix:49-52)

   • Good: The option is now commented out, avoiding the missing default value issue

2. Commented out IPv4 NAT configuration (modules/router.nix:115-119)

   • Consistent with IPv6-only approach

3. Commented out dnsmasq configuration (modules/router.nix:176-197)

   • Clean transition to CoreDNS

🔴 Critical Issues Still Present

1. Undefined internalInterfaceIP Usage (BLOCKER)

The configuration in sagittarius.nix:97 comments out the IP assignment:

# internalInterfaceIP = "192.168.20.1";

But modules/router.nix still uses this value in multiple critical places:

• Line 33: base = ipBase cfg.internalInterfaceIP;
• Line 74-76: Default value is "192.168.1.1" but the ipBase function expects it

Impact: This will cause runtime errors when the router module processes the IP address.

Fix Required: Either:

• Uncomment the IP assignment in sagittarius.nix:97, OR
• Make the IPv4 address handling conditional in the router module

2. Hardcoded DNS Endpoint (modules/router.nix:167)

forward . https://dns.controld.com/1af30lws8zb

This ControlD profile ID remains hardcoded in the module.

Recommendation: Add a configuration option like:

dnsForwarder = mkOption {
  type = str;
  default = "https://dns.controld.com/1af30lws8zb";
  description = "DNS-over-HTTPS endpoint for forwarding queries";
};

3. Unused upstreamDnsServers Option (modules/router.nix:45-48)

This option is defined but never used and has no default value.

Fix: Remove this option entirely since CoreDNS uses DoH forwarding instead.

🟡 Other Issues

1. Mixed IPv4/IPv6 Configuration

• IPv4 forwarding is still enabled (line 207)
• IPv4 address handling code remains active despite IPv6-only goal
• The internalInterfaces structure (lines 31-39) still processes IPv4 addresses

Recommendation: Clarify the migration strategy - is this dual-stack or IPv6-only?

2. Missing Documentation

The transition from dnsmasq to CoreDNS and the NAT64/DNS64 setup lacks inline documentation.

Suggestion: Add comments explaining:

• Why NAT64/DNS64 is needed
• The significance of the 64:ff9b::/96 prefix
• How clients will receive IPv6 addresses

3. DNS Binding Security (modules/router.nix:165)

.:53 {

Binds to all interfaces without explicit access control.

Recommendation: Ensure firewall rules restrict external DNS queries.

🟢 Positive Changes

1. Clean CoreDNS configuration with DNS64 support
2. Proper Jool NAT64 enablement
3. Well-configured CoreRAD for IPv6 router advertisements
4. Prometheus metrics endpoint for CoreRAD monitoring

📋 Recommendations Before Merge

High Priority (Blockers)

1. Fix the internalInterfaceIP issue - The module still requires this value
2. Remove or fix unused options - Clean up upstreamDnsServers

Medium Priority

3. Make DNS endpoint configurable - Move hardcoded ControlD URL to config
4. Clarify IPv4 handling - Document or remove IPv4-specific code
5. Add inline documentation - Explain the NAT64/DNS64 architecture

Low Priority

6. Consider DNS caching configuration - Add cache size limits
7. Review logging configuration - Consider log rotation for CoreDNS

Testing Recommendations

Before removing WIP status:

1. Test with IPv6-only clients connecting to IPv4-only services
2. Verify DNS64 synthesis works correctly
3. Test with dual-stack clients if IPv4 isn't fully disabled
4. Monitor CoreDNS and CoreRAD metrics under load

The architecture looks solid, but the internalInterfaceIP issue must be resolved before this can function properly.

[claude]

Claude finished @johnae's task —— View job

---

Pull Request Review: IPv6-Only Network Configuration (Updated)

Review Tasks

• Read and analyze all changed files
• Compare with previous review feedback
• Check for code quality and best practices issues
• Identify potential bugs
• Assess performance considerations
• Review for security concerns
• Evaluate test coverage needs
• Post comprehensive review feedback

---

Summary

This PR introduces IPv6-only network configuration with NAT64 using Jool and DNS64 using CoreDNS. Good progress has been made since the last review, but a critical blocker remains that will cause runtime errors.

🔴 Critical Blocker

Undefined internalInterfaceIP Runtime Error

In sagittarius.nix:97, the IP is commented out:

# internalInterfaceIP = "192.168.20.1";

However, modules/router.nix:33 still uses this value:

base = ipBase cfg.internalInterfaceIP;

The module provides a default of "192.168.1.1" (line 75), but the ipBase function and subsequent network configuration still process this IPv4 address, which contradicts the IPv6-only goal.

Impact: This will work but creates confusion about whether this is truly IPv6-only or dual-stack.

Recommended Fix:

• Either uncomment the IP in sagittarius.nix, OR
• Make all IPv4 processing conditional with a clear flag like enableIPv4 = mkEnableOption "Enable IPv4 support alongside IPv6";

🟡 Issues to Address

1. Unused Option (modules/router.nix:45-48)

upstreamDnsServers = mkOption {
  type = listOf str;
  description = "List of upstream dns server addresses.";
};

No default value and never used. Remove this option.

2. CoreDNS Configuration (modules/router.nix:170)

Now using Cloudflare's IPv6 DNS over TLS, which is good. However, binding to all interfaces (::):

bind ::

Ensure firewall rules prevent external DNS queries.

3. Mixed IPv4/IPv6 State

• IPv4 forwarding still enabled (line 210)
• IPv4 network configuration still processed (lines 31-39, 104-109)
• NAT commented out but IPv4 infrastructure remains

This creates ambiguity about the actual network architecture.

🟢 Improvements Since Last Review

1. Removed hardcoded ControlD DNS - Now using Cloudflare DNS over TLS
2. Cleaner CoreDNS config - Proper DNS64 with reputable upstream
3. Commented unused options - Shows awareness of needed cleanup
4. Removed disableIPv4 option - Avoids the missing default value issue

📋 Recommendations

High Priority

1. Clarify IPv4 strategy: Either fully support dual-stack or properly disable IPv4
2. Remove unused options: Clean up upstreamDnsServers
3. Document the architecture: Add comments explaining NAT64/DNS64 purpose

Medium Priority

4. Consider DNS redundancy: Add fallback DNS servers
5. Add firewall rules: Explicitly restrict DNS to internal networks
6. Configuration validation: Add assertions for required interfaces

Low Priority

7. Monitor performance: The 300s cache TTL is reasonable but could be tuned
8. Log management: Consider log rotation for CoreDNS

Security Considerations

• ✅ Using DNS over TLS (good for privacy)
• ⚠️ DNS binding to all IPv6 interfaces - ensure firewall configuration
• ✅ Using well-known Cloudflare DNS (reliable and secure)
• ⚠️ IPv4 forwarding enabled despite IPv6-only goal

Testing Recommendations

Before removing WIP status:

1. Test IPv6-only clients accessing IPv4-only services via NAT64
2. Verify DNS64 synthesis for A records
3. Test with various client devices and applications
4. Monitor Jool translation performance
5. Verify CoreRAD router advertisements

Overall Assessment

The architecture is sound and the move to IPv6-only with NAT64/DNS64 is well-executed. The main concern is the ambiguous IPv4 handling - the code suggests dual-stack while the goal appears to be IPv6-only. Clarifying this intent and cleaning up the unused configuration would make this ready for production use.

[claude]

Claude finished @johnae's task —— View job

---

Pull Request Review: IPv6-Only Network Configuration

Review Tasks

• Read and analyze all changed files
• Compare with previous review feedback
• Check for code quality and best practices issues
• Identify potential bugs
• Assess performance considerations
• Review for security concerns
• Evaluate test coverage needs
• Post comprehensive review feedback

---

Summary

This PR implements IPv6-only networking with NAT64/DNS64. Great progress since the last review - the critical internalInterfaceIP issue has been partially addressed. The automatic IPv4 detection for Jool is an excellent improvement. Some issues remain before merging.

✅ Improvements Since Last Review

1. Smart IPv4 Detection (sagittarius.nix:10-55)

   • Excellent implementation that auto-detects public IPv4 from WAN interface
   • Proper error handling when IP can't be detected
   • Clean systemd service configuration

2. internalInterfaceIP Issue Resolved

   • The router module now has a default value (line 75: "192.168.1.1")
   • Works even though sagittarius.nix:146 comments it out
   • This resolves the critical runtime error from previous reviews

3. Cleaner DNS Configuration (modules/router.nix:168-177)

   • Using Cloudflare's IPv6 DNS over TLS
   • Proper DNS64 configuration for NAT64 compatibility
   • Reasonable 300s cache timeout

🔴 Critical Issues

1. Unused Option Without Default (modules/router.nix:45-48)

upstreamDnsServers = mkOption {
  type = listOf str;
  description = "List of upstream dns server addresses.";
};

This option has no default value and is never used. Either remove it or provide a default.

Fix: Delete lines 45-48 since CoreDNS uses hardcoded Cloudflare DNS.

🟡 Code Quality Issues

1. Commented Out Code Clutter

Multiple files have large blocks of commented code:

• alnitak.nix:46-66 (entire router config commented)
• modules/router.nix:49-52, 115-119, 180-201 (old dnsmasq/NAT configs)
• sagittarius.nix:134-150, 174-199 (old config and exporters)

Recommendation: For WIP, this is acceptable, but clean up before final merge.

2. Mixed IPv4/IPv6 State (modules/router.nix)

• IPv4 forwarding enabled (line 211) despite IPv6-only goal
• IPv4 addresses still configured (lines 104-109)
• The ipBase function (lines 24-29) processes IPv4 addresses

Clarification Needed: Is this truly IPv6-only or dual-stack transitional?

3. Hardcoded Network Assumptions

• internalInterfaces structure (lines 31-39) assumes /24 subnet
• No validation that the interface actually exists

🛡️ Security Considerations

1. DNS Binding (modules/router.nix:169)

bind ::

Binds to all IPv6 interfaces without explicit access control.

Risk: Could become an open resolver if firewall rules aren't properly configured.

Recommendation: Ensure networking.firewall.trustedInterfaces (line 82) doesn't expose DNS externally.

2. NAT64 Pool Configuration (sagittarius.nix:33)

Using standard 64:ff9b::/96 prefix is correct and follows RFC 6146.

3. Port Range (sagittarius.nix:40, 45, 50)

Port range 10000-65535 is reasonable for NAT64, preserving lower ports for services.

⚡ Performance Considerations

1. DNS Cache (modules/router.nix:174)

   • 300s TTL is reasonable
   • No cache size limit could cause memory growth under heavy load

2. CoreRAD Monitoring (modules/router.nix:131)

   • Prometheus endpoint enabled - good for observability
   • Consider adding CoreDNS metrics as well

3. Jool NAT64 Performance

   • Dynamic configuration generation adds startup delay but ensures correctness
   • Consider monitoring translation table size

🧪 Test Coverage Recommendations

1. Functional Tests

   • IPv6-only clients reaching IPv4-only services
   • DNS64 synthesis verification
   • Fallback when public IPv4 detection fails

2. Edge Cases

   • Multiple IPv4 addresses on WAN interface
   • IPv6 prefix delegation failure
   • Jool service restart reliability

3. Integration Tests

   • Common applications (web, streaming, gaming)
   • Different client OS behaviors
   • Performance under load

📋 Action Items

Before Removing WIP Status

1. Remove unused upstreamDnsServers option (blocker for evaluation)
2. Document IPv4/IPv6 strategy - clarify dual-stack vs IPv6-only intent
3. Add inline documentation explaining NAT64/DNS64 architecture

Nice to Have

4. Clean up commented code blocks
5. Add CoreDNS metrics endpoint
6. Consider DNS cache size limits
7. Add assertions for required network interfaces

Overall Assessment

Solid progress on the IPv6-only network configuration. The automatic IPv4 detection for Jool is particularly well done. The main blocker is the unused option without a default value. Once that's fixed and the IPv4/IPv6 strategy is clarified, this should be ready for testing.

The NAT64/DNS64 approach using Jool and CoreDNS is architecturally sound and follows best practices for IPv6 migration.

---