welcome.proto field 2 delivers the tunnel IP as four raw bytes:
bytes ip = 2;
// IPv4 address (4 raw bytes) assigned to the client inside the tunnel
// for the lifetime of this session. The client uses it as the source
// address of every encapsulated IP packet.
Configuring a TUN interface requires both an address and a prefix length — the OS needs the network boundary to set up routing correctly (e.g. ip addr add 10.0.0.5/24 dev tun0). The Welcome message delivers only the address; the prefix length is absent from the protocol.
Without a prefix field every implementation is forced to hardcode the subnet out-of-band. A mismatch between implementations (say, one assumes /24 and another assumes /30) silently produces wrong routing tables: packets destined for peers on the same logical subnet leave the tunnel and go to the public Internet instead.
Add a uint32 prefix = N field to Welcome carrying the CIDR prefix length (1–32). The Node should populate it alongside ip on every successful Auth. Clients that receive a prefix of zero should treat the assignment as malformed and disconnect.
welcome.proto field 2 delivers the tunnel IP as four raw bytes:
Configuring a TUN interface requires both an address and a prefix length — the OS needs the network boundary to set up routing correctly (e.g.
ip addr add 10.0.0.5/24 dev tun0). The Welcome message delivers only the address; the prefix length is absent from the protocol.Without a prefix field every implementation is forced to hardcode the subnet out-of-band. A mismatch between implementations (say, one assumes /24 and another assumes /30) silently produces wrong routing tables: packets destined for peers on the same logical subnet leave the tunnel and go to the public Internet instead.
Add a
uint32 prefix = Nfield toWelcomecarrying the CIDR prefix length (1–32). The Node should populate it alongsideipon every successful Auth. Clients that receive a prefix of zero should treat the assignment as malformed and disconnect.