es- sage through the overlay without the contents being parsed (or even visible) by intermediate peers. The header includes no information about specific IP addresses but only includes source and destination peer-IDs as well as some minor option and version flags. Clearly separating the header components necessary for routing from the message contents simplifies processing and increases security. The content of the message is in STUN-based type-length- value (TLV) format, extending a syntax for which many implementers will already have a parser. The flexible contents allow great flexibility in sup- porting a variety of DHT and security algorithms using the same base peer protocol. The protocol supports User Datagram Protocol (UDP), Transmission Con- trol Protocol (TCP), Transport Security Layer (TLS), or Stream Control Transmission Protocol (SCTP) for the underlying transport protocol. New transports can be supported easily. Explicit support for fragmentation is pro- vided, which is required when using UDP. UDP must be supported because TCP may not always be available in the environments this protocol will be deployed in. The protocol supports one-to-many registrations. Fully distributing all of the states required to duplicate the functionality of central servers requires information about different types of resources for the same user: primary con- tact, offline voicemail, security certificate, etc. Furthermore, obtaining a list of the resources available for a particular user requires one-to-many registrations stored in a single location, rather than distributing each type of resource by a separate key. Each key to value mapping has an individual expiration time. Thus, a single key can have both long-lived and transient registrations. Each key to value mapping is individually signed by the registering entity. The pro- tocol allows multiple entities to register under the same key, thus allowing voicemail or other data to be left for another user. Because each message lives as a separate registration, there are 