Share via

Peer Name Resolution Protocol

On This Page

PNRP Clouds
Peer Names and PNRP IDs
PNRP Name Resolution
Scaling Peer Name Resolution with a Multi-Level Cache
PNRP Name Publication
PNRP Cache Initialization
Using PNRP in Application Development
Related Links


In peer-to-peer environments, peers rely on name resolution systems to resolve each other's network locations (addresses, protocols, and ports) from names or other types of identifiers. Peer-to-peer name resolution has been complicated by transient connectivity and shortcomings in the Domain Name System (DNS).

The Microsoft® Windows® Peer-to-Peer Networking platform solves this problem with the Peer Name Resolution Protocol (PNRP), a secure, scalable, and dynamic name registration and name resolution protocol first developed for Windows XP and then upgraded in Windows Vista™. PNRP works very differently from traditional name resolution systems, opening up exciting new possibilities for application developers.

PNRP has the following properties:

  • Distributed and serverless for incredible scalability and reliability

    PNRP is almost entirely serverless (servers are required only for bootstrapping). PNRP easily scales to billions of names. The system is fault tolerant and there are no bottlenecks.

  • Effortless name publication without third parties

    DNS name publication requires updates to DNS servers. Most people must contact a server administrator. This takes time and incurs costs. PNRP name publication is instantaneous, effortless, and free.

  • Real time updates

    DNS relies heavily on caching to improve performance. Unfortunately, this means names cannot be reliably updated in real time. PNRP is much more efficient than DNS and can process updates almost instantaneously. Name resolutions will never return stale addresses, making PNRP an excellent solution for finding mobile users.

  • Name more than just computers

    A PNRP resolution includes an address, port, and possibly an extended payload. With PNRP you can name more than just computers. You can also name services.

  • Protected name publication

    Names can be published as secured (protected) or unsecured (unprotected) with PNRP. PNRP uses public key cryptography to protect secure peer names against spoofing.

PNRP Clouds

PNRP uses multiple clouds, in which a cloud is a grouping of computers that are able to find each other. PNRP provides two clouds:

  • The global cloud corresponds to the global IPv6 address scope and global addresses and represents all the computers on the entire IPv6 Internet. There is only a single global cloud.

  • The link-local cloud corresponds to the link-local IPv6 address scope and link-local addresses. A link-local cloud is for a specific link, which is typically the same as the locally attached subnet. There can be multiple link-local clouds.

A third cloud, the site-specific cloud, corresponds to the site IPv6 address scope and site-local addresses. This cloud has been deprecated, although it is still supported in PNRP.

Peer Names and PNRP IDs

A peer name is an endpoint for communication, which can be a computer, a user, a group, a service, or anything else that you want to resolve to an IPv6 address. Peer names can be registered as unsecured or secured. Unsecured names are just text strings that are subject to spoofing, as anyone can register a duplicate unsecured name. Unsecured names are best used in private or otherwise protected networks. Secured names are protected with a certificate and a digital signature. Only the original publisher will be able to prove ownership of a secured name.

PNRP IDs are 256 bits long and are composed of the following:

  • The high-order 128 bits, known as the peer-to-peer (P2P) ID, are a hash of a peer name assigned to the endpoint.

    The peer name of an endpoint has the following format: Authority.Classifier. For secured names, Authority is the Secure Hash Algorithm 1 (SHA1) hash of the public key of the peer name in hexadecimal characters. For unsecured names, the Authority is the single character "0". Classifier is a string that identifies the application and can be any Unicode string up to 150 characters long.

  • The low-order 128 bits are used for the Service Location, which is a generated number that identifies different instances of the same P2P ID in the same cloud.

The 256-bit combination of P2P ID and Service Location allows multiple PNRP IDs to be registered from a single computer. Figure 1 shows the structure of P2P and PNRP IDs.

Figure 1. P2P and PNRP IDs

For each cloud, each peer node manages a cache of PNRP IDs that includes both its own registered PNRP IDs and the entries cached over time. The entire set of PNRP IDs located on all the peer nodes in a cloud comprises a distributed hash table. It is possible to have entries for a given PNRP ID located on multiple peers. Each entry in the PNRP cache contains the PNRP ID, a certified peer address (CPA), and the IPv6 address of the publishing node. The CPA is a self-signed certificate that provides authentication protection for the PNRP ID and contains application endpoint information such as addresses, protocol numbers, and port numbers.

Therefore, the name resolution process for PNRP consists of resolving a PNRP ID to a CPA. After the CPA is obtained, communication with desired endpoints can begin.

There are two different methods of performing PNRP name resolution based on the version of PNRP. PNRP version 1 was included in Windows XP Service Pack 2 (SP2), Windows XP Professional x64 Edition, and Windows XP with Service Pack 1 (SP1) and the Advanced Networking Pack for Windows XP. It used a recursive system for name resolution, and is not discussed in this paper. PNRP version 2 was redesigned in for Windows Vista and Windows XP Service Pack 3 to reduce network bandwidth by using an iterative approach to name resolution. The two versions of PNRP are not compatible.

PNRP Name Resolution

PNRP name resolution uses the following two phases:

  • Endpoint determination

    In this phase, a peer that is attempting to resolve the PNRP ID of a service on a peer computer first determines the IPv6 address of the peer that published the PNRP ID of the PNRP service running on that peer.

  • PNRP ID resolution

    After locating and confirming the availability of the peer with the PNRP ID corresponding to the PNRP service of the desired endpoint, the requesting peer sends a PNRP Request message to that peer for the PNRP ID of the desired service. The endpoint sends a reply confirming the PNRP ID of the requested service, a comment, and up to 4 kilobytes of additional information that the requesting peer can use for future communication. For example, if the desired endpoint is a gaming server, the additional data can contain information about the game, the level of play, and the current number of players.

During endpoint determination, PNRP uses an iterative process for locating the node that published the PNRP ID, in which the node performing the resolution is responsible for contacting nodes that are successively closer to the target PNRP ID.

To perform name resolution in PNRP, the peer examines the entries in its own cache for an entry that matches the target PNRP ID. If found, the peer sends a PNRP Request message to the peer and waits for a response. If an entry for the PNRP ID is not found, the peer sends a PNRP Request message to the peer that corresponds to the entry that has a PNRP ID that most closely matches the target PNRP ID. The node that receives the PNRP Request message examines its own cache and does the following:

  • If the PNRP ID is found, the requested peer replies directly to the requesting peer.

  • If the PNRP ID is not found and a PNRP ID in the cache is closer to the target PNRP ID, the requested peer sends a response to the requesting peer containing the IPv6 address of the peer that corresponds to the entry that has a PNRP ID that most closely matches the target PNRP ID. From the IP address in the response, the requesting node sends another query to the IPv6 address referred to by the first node.

  • If the PNRP ID is not found and there is no PNRP ID in its cache that is closer to the target PNRP ID, the requested peer sends the requesting peer a response that indicates this condition. The requesting peer then chooses the next-closest PNRP ID.

The requesting peer continues this process with successive iterations, eventually locating the node that registered the PNRP ID.

For example, Peer A has entries for its own PNRP ID (200) and the PNRP ID of 450 and 500. The set of peer nodes is shown in Figure 2. An arrow from one node to another means that the node from which the arrow originates has an entry in its cache for the node to which the arrow is pointing.

Figure 2. An example peer-to-peer network for PNRP endpoint determination

When Peer A wants to determine the endpoint for the PNRP ID of 800, the following process occurs:

  1. Because 500 is numerically closer to 800, Peer A sends a PNRP Request message to the node that registered the PNRP ID of 500 (Peer C).

  2. Peer C does not have an entry for the PNRP ID of 800 and does not have any entries that are closer to 800. Peer C sends a response back to Peer A indicating that it could not find an entry closer to 800.

  3. Because 450 is the next numerically closer PNRP ID to 800, Peer A sends a PNRP Request message to the node that registered the PNRP ID of 450 (Peer B).

  4. Because Peer B has an entry in its cache for the PNRP ID of 800, it sends the IPv6 address of Peer E to Peer A.

  5. Peer A sends a PNRP Request to Peer E.

  6. Peer E sends a positive name resolution response back to Peer A.

This process is shown in Figure 3.

Figure 3. PNRP endpoint determination example

After endpoint determination, Peer A sends a PNRP name resolution request for the service with which Peer A wants to establish communication to Peer E. Peer E sends back a response that contains optional data about the service for the requesting application.

Scaling Peer Name Resolution with a Multi-Level Cache

To keep the sizes of the PNRP caches small, peer nodes use a multi-level cache, in which each level contains a maximum number of entries. Each level in the cache represents a one tenth smaller portion of the PNRP ID number space (2256). The lowest level in the cache contains a locally registered PNRP ID and other PNRP IDs that are numerically close to it. As a level of the cache is filled with a maximum of 20 entries, a new lower level is created. The maximum number of levels in the cache is on the order of log10(Total number of PNRP IDs in the cloud). For example, for a global cloud with 100 million PNRP IDs, there are no more than 8 (=log10(100,000,000)) levels in the cache and a similar number of hops to resolve a PNRP ID during name resolution. This mechanism allows for a distributed hash table for which an arbitrary PNRP ID can be resolved by forwarding PNRP Request messages to the next-closest peer until the peer with the corresponding CPA is found.

Figure 4 shows an example of this multi-level caching scheme for a number space of 1000 entries (0-999) in which each level of the cache represents 10 percent of the number space and can only store 4 entries (each tick mark represents a cache entry).

Figure 4. An example multi-level cache

The result of this multi-level caching scheme is that each peer does not have to store a large amount of cache entries. Even for a large number of PNRP IDs, the local storage and network traffic to resolve an arbitrary PNRP ID is not substantial.


Figure 4 is a simplification of the PNRP number space, which is actually a circular name space (the first number after 999 in this example is 0.)

To ensure that resolution can complete, each time a node adds an entry to the lowest level of its cache, it floods a copy of the entry to all the nodes within the last level of the cache.

The cache entries are refreshed over time. Cache entries that are stale are removed from the cache. The result is that the distributed hash table of PNRP IDs is based on active endpoints, unlike DNS in which address records and the DNS protocol provide no guarantee that the node associated with the address is actively on the network.

PNRP Name Publication

To publish a new PNRP ID, a peer performs the following:

  • Sends PNRP publication messages to its cache neighbors (the peers that have registered PNRP IDs in the lowest level of the cache) to seed their caches.

  • Chooses random nodes in the cloud that are not its neighbors and sends them PNRP name resolution requests for its own P2P ID. The resulting endpoint determination process seeds the caches of random nodes in the cloud with the PNRP ID of the publishing peer.

PNRP version 2 nodes do not publish PNRP IDs if they are only resolving other P2P IDs. The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerNet\PNRP\IPV6-Global\SearchOnly=1 registry value (REG_DWORD type) allows you to specify that peers only use PNRP for name resolution, never for name publication. This registry value can also be configured through Group Policy.

PNRP Cache Initialization

To initialize the PNRP cache when a peer node starts up, the node can use the following methods:

  • Persistent cache entries

    Previous cache entries that were present when the node was shut down are loaded from hard disk storage.

  • PNRP seed nodes

    PNRP allows administrators to specify the addresses or DNS names of PNRP seed nodes that contain CPAs for current participants in the cloud.

  • Simple Service Discovery Protocol

    PNRP nodes are required to register themselves using the Universal Plug-and-Play (UPnP) Simple Service Discovery Protocol (SSDP). A node joining a cloud can use an SSDP Msearch message to locate nearby SSDP nodes.

Using PNRP in Application Development

In Windows Vista, Windows Peer-to-Peer Networking applications can access PNRP name publication and resolution functions through a simplified PNRP application programming interface (API). With the simplified PNRP publication API, you do not have to specify the clouds with which to register the name and addresses. The PNRP component in Windows Vista will automatically determine the appropriate clouds to join and the addresses to publish within the clouds.

For highly simplified PNRP name resolution in Windows Vista, PNRP names are now integrated into the getaddrinfo() Windows Sockets function. To use PNRP to resolve a name to an IPv6 address, applications can use the getaddrinfo() function to resolve the Fully Qualified Domain Name (FQDN), in which name is peer name being resolved. The domain is a reserved domain in Windows Vista for PNRP name resolution.


For a name publication and resolution mechanism, Windows Peer-to-Peer Networking uses PNRP. PNRP is an efficient, protected, low cost, dynamic protocol that uses an iterative, serverless method for name resolution.

See the following resources for additional information: