PNRP and pnrp.net


The other day I read a forum post explaining that it was easy to block PNRP traffic at the edge of the network – just block all traffic headed to pnrp.net.  I worry about the user’s motivation for blocking PNRP (peer-to-peer networking and illegal music sharing are not synonymous!) but I feel the need to clear up this misconception and explain *.pnrp.net names.  Blocking traffic sent to pnrp.net will NOT stop pnrp.


 


DNS / Host Name Encoding


If you weren’t already aware, pnrp names can be resolved in your existing Windows applications if they formatted to look like DNS names.  We call this DNS encoding.  DNS encoding is needed for a number of reasons.


For one thing, pnrp names consist of Unicode characters.  Historically, host names could consist of only ASCII letters, numbers and hyphens.  To play nicely, we convert PNRP names to punycode during DNS encoding.  Punycode makes Unicode strings host name friendly.  More information about punycode can be found on the ietf website if you’re interested (http://tools.ietf.org/html/rfc3492).


If you’ve read the pnrp whitepaper, you’ll know that a pnrp name consists of an authority followed by a friendly string known as the classifier.  In DNS, it’s usually the other way around.  That is, the rightmost portions of the name are considered the most authoritative.  To maintain the status quo, we swap the authority and classifier when dns encoding and add on the suffix .pnrp.net.  A pnrp name would read classifier.authority.pnrp.net.


We prefix the letter ‘p’ to a converted authority if it does not begin with a letter because a dns label cannot begin with a number.  We drop the authority altogether if you’re publishing an unsecured name.


There are a couple of functions for converting between peer name and host name encodings.  Our api function PeerNameToPeerHostName converts from pnrp to hostname encoding and PeerHostNameToPeerName does just the opposite.  You can also use the netsh p2p pnrp peer show convertedname command.


 


Demonstration


A demonstration will help you believe me.  Let’s use netsh to publish a name in pnrp.  We’ll then convert it to host encoding.  Finally, we’ll use it in an application:  ping!


 


Register a name                                                                      


We can use the netsh p2p pnrp peer add registration command to register a name.  Be careful though – a pnrp registration only lasts as long as the registering application.  If you call netsh p2p pnrp peer add registration from the command line, netsh will start, register the name the immediately exit … unregistering the name!  Instead, register the name by following these steps:


1.        Start netsh


C:\>netsh


netsh>


 


2.        Switch to the p2p pnrp peer context by typing p2p pnrp peer


netsh>p2p pnrp peer


netsh p2p pnrp peer>


 


3.       Register the name by typing add registration 0.yourName


netsh p2p pnrp peer>add registration 0.tylerTesting


Peer name has been registered in all clouds


Ok.


 


4.       Leave the netsh window open!  If you exit netsh, the registration will be torn down.


 


Convert to host name format


In a separate command prompt, convert to host name encoding using the netsh p2p pnrp peer show convertedname command.


C:\>netsh p2p pnrp peer show convertedname 0.tylerTesting


DNS Name: tyleresting-v2a.p0.pnrp.net


 


Use your DNS encoded peer name!


The easiest test is ping.  Try it!


C:\>ping tyleresting-v2a.p0.pnrp.net


 


Pinging tyleresting-v2a.p0.pnrp.net [2001:0:4136:e37a:104f:3e94:bc57:5e99] from
2001:0:4136:e37a:104f:3e94:bc57:5e99 with 32 bytes of data:


Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms 


Ping statistics for 2001:0:4136:e37a:104f:3e94:bc57:5e99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),


Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


 


Under the hood


Finally, we get to the misconception that I set out to clear up.  Microsoft is not hosting some kind of DNS to PNRP gateway behind pnrp.net.  We’re actually doing a pnrp resolution on your computer when you use a DNS encoded peer name.


Getaddrinfo is the function most applications call to resolve a host name to an ip address.  Getaddrinfo is protocol independent and calls into multiple name space providers.  DNS and Netbios are two very old examples.  PNRP has a namespace provider too.  If it sees a request to resolve a name ending in .pnrp.net, it converts the name from host encoding to pnrp encoding, then uses the pnrp service to do a lookup.  So you see blocking out connections to .pnrp.net really won’t do much.


As always, email me if you have questions.


Have fun!


Tyler


Tylbart at Microsoft.com


Comments (3)

  1. Kevin Hoffman has continued his series about peer-to-peer networking. You can find an index of his posts

  2. But wouldn’t blocking either pnrpv2.ipv6.microsoft.com or pnrpv21.ipv6.microsoft.com at least prevent registration/resolution within the global cloud?

    Not that anyone should want to do that.

  3. Anonymous says:

    Part of the problem is that when the stack does not support PNRP, foo.pnrp.net resolves to the IPv4 address 65.55.39.12 which seems to redirect you to a Bing search… This is a serious problem.