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 secure networks. Secured names can only be registered by the owner and they are protected with a certificate and a digital signature.
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 (SHA) 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 uniquely 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.
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 registering node. The CPA is a self-signed certificate that provides authentication protection for the PNRP ID and contains application endpoint information (addresses, protocol numbers, and port numbers).
Therefore, the name resolution process consists of resolving a PNRP ID to a CPA. After the CPA is obtained, communication with desired endpoints can begin.
PNRP Name Resolution
When a peer wants to resolve the peer name to its address, protocol, and port number, it constructs the P2P ID based on the peer name. The peer examines the entries in its own cache for an entry that matches the P2P ID. If found, the peer sends a PNRP Request message to the peer and waits for a response. This behavior ensures that the peer node with which to communicate is active in the cloud.
If not found, the peer sends a PNRP Request message to the peer that corresponds to the entry that has a P2P ID that most closely matches the P2P ID being resolved. The node that receives the PNRP Request message examines its own cache. If found, it forwards the request to the intended node and the intended node sends a response back through the request path. If not found, it sends a PNRP Request message to the peer that corresponds to the entry that has a P2P ID that most closely matches the P2P ID being resolved, and so on until the correct peer is found.
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 the Figure 4. 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 4 An example peer-to-peer network
When Peer A wants to resolve 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. |
|
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. |
Peer B forwards the request to the IP address that registered the PNRP ID of 800 (Peer E). Although Peer B has an entry for Peer E in its cache, the existence of the cache entry does not assure that Peer E is currently available on the network. |
|
5. |
Peer E sends a response back to Peer B. |
|
6. |
Peer B sends a response back to Peer A. |
This process is shown in Figure 5.
To prevent loops in the forwarding of PNRP Request messages, the message contains the list of peers that have already forwarded the request.
While the PNRP Request message is being forwarded, its contents are used to populate caches of nodes that are forwarding it. When the response is sent back through the return path, its contents are also used to populate node caches.