Summary

Adds a predefined extension type for IP addresses, assigned to extension type -7.

• IPv4 → fixext 4 (0xd6), 4-byte payload
• IPv6 → fixext 16 (0xd8), 16-byte payload
• Address stored in network byte order (big-endian)

The address family is determined solely by payload length (4 vs 16), so there is no discriminator byte and no ambiguity. Because the layout matches struct in_addr / struct in6_addr, encoding and decoding are a direct byte copy — no inet_pton/inet_ntop, no string parsing. That is the entire motivation: parsing and (especially) formatting textual IPv6 is comparatively expensive, and shipping addresses as text wastes wire space.

Design decisions

• Address only. No port, no prefix length / netmask, no IPv6 zone (scope) identifier. A zone id is a host-local artifact (an interface index or name) that is meaningless to a remote peer, so it is intentionally excluded rather than encoded on the wire. Applications needing these can compose them with the address in an application-defined structure.
• Canonical IPv4. Encoders SHOULD use the 4-byte form and SHOULD NOT emit an IPv4-mapped IPv6 address (::ffff:0:0/96) in the 16-byte form when a 4-byte encoding is possible, so each address has one canonical encoding.

Type code choice

-1 is Timestamp. Type codes -2 through -5 are currently contested by multiple outstanding extension-type PRs (e.g. #340 UID/UUID, #338 length encoding, #304 geographic coordinate, #248 / #249 big numbers). -7 sidesteps that range to avoid collisions, leaving -6 as a buffer for those proposals to settle.