Here is the comprehensive Proposal for Integrated Automated Peering in Yggdrasil

[rongzedong]

Proposal: Cryptographically-Secure Automated Peering (CSAP) for Yggdrasil

1. Introduction

Currently, establishing Wide Area Network (WAN) peering in Yggdrasil requires manual exchange of public IPv6 addresses and static configuration of Peers or addPeer commands via the Admin API. This "Manual Peering" becomes a bottleneck when endpoints use dynamic IPv6 addresses or when nodes move across networks.
The CSAP (Cryptographically-Secure Automated Peering) proposal introduces a mechanism to use the existing Yggdrasil overlay as a signaling plane. It allows nodes to automatically exchange their physical endpoints and establish direct, low-latency connections (e.g., via QUIC) without manual intervention.

2. Core Objectives

• Zero-Config WAN Peering: Automate the discovery of physical endpoints across the internet.
• Identity-Bound Security: Replace pre-shared tokens with Ed25519 signatures derived from native Yggdrasil Node Keys.
• On-Demand Routing Optimization: Trigger direct peering attempts only when the Yggdrasil engine detects traffic routing toward a specific target.
• Resilience to IP Churn: Automatically update Peer URIs when a node's physical IPv6 address changes.

3. Implementation Mechanism

A. Signaling via Overlay
When a node needs to optimize a route to a target 200::/7 address, it sends a Discovery Packet through the existing multi-hop Yggdrasil path. This packet contains:

1. Initiator's Physical Endpoint: [IPv6]:Port.
2. Timestamp: To prevent replay attacks.
3. Cryptographic Signature: Signed by the Initiator’s Node Private Key.

B. Identity Verification
Since Yggdrasil IPv6 addresses are cryptographically derived from Public Keys, the Receiver can:

1. Extract the Public Key from the Initiator’s Yggdrasil IPv6 address.
2. Verify the Signature against the metadata.
3. Ensure the request is authentic before executing an internal addPeer command.

C. Proposed Configuration (Opt-in)

# New section in yggdrasil.conf
AutoPeering: {
  Enabled: true
  # Define which prefixes are allowed to trigger auto-peering
  AllowedPrefixes: ["200::/7"] 
  # Preferred protocol for the direct link
  Protocol: quic 
  ListenPort: 9000
}

4. Feature Comparison

Feature	Native Multicast Beacon	Manual WAN Peering	Proposed CSAP (Auto-Peering)
Network Scope	Local (L2)	Global (L3)	Global (L3)
Configuration	Zero-config	Heavy manual entry	Zero-config (Opt-in)
Trust Model	Implicit (Local wire)	Explicit (Manual URI)	Cryptographic (Node Keys)
IP Persistence	LAN-only	Breaks on IP change	Self-healing
Trigger	Periodic Broadcast	Static/Admin API	On-Demand (Traffic-driven)

5. Feasibility & Security Analysis

• Security (Anti-Flooding): By requiring a valid Ed25519 signature tied to a Yggdrasil identity, the system rejects "Peering Flooding" from unauthorized external IPs. Rate-limiting can be applied per NodeID.
• Protocol Choice: Using QUIC for the automated peer link provides superior performance over lossy WAN links and better NAT traversal compared to standard TCP/TLS.
• Backwards Compatibility: This operates as a side-channel signaling mechanism; nodes without this feature simply ignore the discovery packets, maintaining standard routing.

6. Conclusion for Developers

Integrating CSAP into the Yggdrasil core (or as a standard sidecar) transforms the network from a static mesh into a dynamic, self-optimizing fabric. It leverages the strongest asset of Yggdrasil—its cryptographically bound addressing—to solve the most common UX pain point: manual peering.

[zhoreeq]

@rongzedong recommend a good AI agent that can automatically close all AI generated issues