Both `Welcome.ip` (field 2) and `Welcome.home` (field 7) are documented as "4 raw bytes" but do not specify endianness. `Peer.ip` (pong.proto field 1) explicitly says "four raw bytes (network byte order)", establishing the pattern. A developer reading only `welcome.proto` has no stated byte-order contract for the two fields.
The absence matters because `Welcome.ip` is used to configure the TUN interface source address, and `Welcome.home` is compared against the client's local IP to detect NAT. An implementation that uses host byte order (little-endian on x86) instead of network byte order would configure a reversed IP address, causing the tunnel to send malformed packets or silently misreport NAT state.
Add "network byte order" to the comments of both fields in `welcome.proto`, mirroring the wording already present in `Peer.ip`.
Both `Welcome.ip` (field 2) and `Welcome.home` (field 7) are documented as "4 raw bytes" but do not specify endianness. `Peer.ip` (pong.proto field 1) explicitly says "four raw bytes (network byte order)", establishing the pattern. A developer reading only `welcome.proto` has no stated byte-order contract for the two fields.
The absence matters because `Welcome.ip` is used to configure the TUN interface source address, and `Welcome.home` is compared against the client's local IP to detect NAT. An implementation that uses host byte order (little-endian on x86) instead of network byte order would configure a reversed IP address, causing the tunnel to send malformed packets or silently misreport NAT state.
Add "network byte order" to the comments of both fields in `welcome.proto`, mirroring the wording already present in `Peer.ip`.