Tyler - MSFT

A question from a PNRP user



I am facing a problem in resolving PNRP name between two machines.


I have two machines with VISTA installed on it .Both the machines have separate broad band internet connection.

PNRP name being registered in one machine is not able to get resolved by other.

I have used

netsh>p2p>pnrp>peer>add reg 0.testingpnrp Global_ in one machine for adding pnrp name.


netsh>p2p>pnrp>peer>resolve 0.testingpnrp in other machine for resolving for resolving.

Both the systems have Global_ cloud active.

Please let me know, how to deal with this situation


Re: Peer-to-Peer Networking Issue with PNRP name resolution

Tyler - MSFT

There are a few more diagnostic tools that can help us understand what¡¯s going on.

netsh p2p pnrp diag ping host <ip address> Global_

This will tell us whether or not the two machines have connectivity. The last step in a PNRP name resolution involves a direct connection between the two computers. If they can¡¯t connect, the name resolution will fail.

Direct connectivity between peers is the cause of almost every name resolution failure. Connectivity can fail for a number of reasons (firewall, Teredo Nat incompatibility, etc.). I can help you work through connectivity problems.

Netsh p2p pnrp peer traceroute <peername> Global_

PNRP communicates with a number of computers in the distributed system when searching for a target. This command will show you the sequence of machines that your computer contacts.

Give those a try and let us know if they help.



Re: Peer-to-Peer Networking Issue with PNRP name resolution


Thanks Tyler,

This works for me.Both the system were responding well while pinging other host.

Further,settings on my machines are:

1>Peer name resultion Protocol

2>Peer networking group

3>Peer networking Identity manager

4>Peer name machine resolution service

all the above services are running.

Ques1:Is it always necessary to have these services running

Seed server being set is


"PNRPSEEDSERVER.CORP.MICROSOFT.COM" seed server i got from http://technet2.microsoft.com/WindowsVista/en/library/8a70907e-9137-4426-a46f-a2d1eeadbd5a1033.mspx mfr=true.

Ques2: Will removing/adding of this seed server effects

when i try

netsh p2p pnrp cloud>sync seed Global_ i get

SOLICIT sent to address: [2002:4........:e385:................................:e385]:3540.
ADVERTISE returned 5 ID(s).

ques3:Here what does first line mean As the address specified is of 6to4 tuneeling tech where as I want my machines to use TEREDO,since i am using two Broad band machines with separate IP and they are behind NAT(restricted type).

Also in the address shown last 4 digits that is e385 keeps changing to e383 or e384 or e382 whenever i run

netsh p2p pnrp cloud>sync seed Global_

Ques4:Why this happens

Can you please help me in this.



Re: Peer-to-Peer Networking Issue with PNRP name resolution

Tyler - MSFT

Hi Sumeet

First, let's get your questions answered.

1. These services are necessary to run various pieces of the peer-to-peer platform. The peer name machine publication service (which I believe is number 4 - correct me if I'm wrong) manages the publication of your Windows Internet Computer Name. I take it you turned this on at some point. You can disable this service, and your WICN, without adversly affecting the rest of the platform and other running applications, but it's a useful service that you can used to find a computer as you move about the internet.

You've probably already seen this, but I'll include it for reference - the WICN instructions: http://www.microsoft.com/technet/network/p2p/wicn.mspx.

2. pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com are the primary seed servers that all Vista machines are configured to use by default. I don't believe that there is currently a seed server active at pnrpseedserver.corp.microsoft.com, so you shouldn't add this to your seed server list.

Seed servers are the first nodes PNRP talks to when entering the distributed system. In a sense, it's the seed server that keeps a cloud of PNRP nodes unified. Everyone in the same cloud bootstraps from one or several well known nodes. If you were to deploy your own seed server, you could create a completely new PNRP cloud cloud. You probably don't want to do this. A resolve in one cloud won't find a registration in another.

I wrote a blog entry about this a while back: http://blogs.msdn.com/p2p/archive/2007/03/18/setting-up-a-private-pnrp-global-cloud.aspx

We put dns entries for two seed servers on Vista for redundancy. You could quite safely delete one of these entries. You can create your own seed server and add it's address to your Vista client, but I'm not sure why you would want to do this. I would advise you against adding seed servers that you learn about by browsing the web.

3. SOLICIT and ADVERTISE are two messages that PNRP uses to bootstrap. When you pnrp ping the seed server, you're actually attempting to bootstrap from it.

We publish 6to4 addresses for the PNRP seed servers because 6to4 addresses are much more stable than Teredo addresses. Each seed server actually has a Teredo interface, but it acts as a host specific relay. When you use your Teredo interface to talk to a seed server, you're actually using the Teredo tunneling protocol.

4. We have multiple machines serving as seed servers. When you query pnrpv2.ipv6.microsoft.com, our server infrastructure hands you back the ipv6 address of a random seed server each time. This helps us load balance and add seed servers over time as PNRP grows in popurity.

I'm very curious about your failed PNRP resolutions. I'd like to see a traceroute from one node to the other. If you don't want to post this information (because it contains IP addresses) feel free to email it to me.

I hope this helps!


Thanks for moving the conversation to the forum by the way.

Re: Peer-to-Peer Networking Issue with PNRP name resolution

Tyler - MSFT

Hi Sumeet. I'm going to assume you got your resolve to work. If you're still having trouble, feel free to post a new question or email me.



Re: Peer-to-Peer Networking Issue with PNRP name resolution


Thanks Tyler,

For me the PNRP name resultion is working now.I think earlier there can be two reasons to have the problem.

1>I was using PNRPSEEDSERVER.microsoft.com as seed server with other default server.

2>Or it can be because when i changed the entry for seed server in registry,i directly copy the seed server name from

http://technet2.microsoft.com/WindowsVista/en/library/8a70907e-9137-4426-a46f-a2d1eeadbd5a1033.mspx mfr=true link where it is


and here no .com is being added at the end of second seed server,which may have lead to the issue.

Let me know if above can be the problems in PNRP name resolution


While synchronizing seed server, some time I get the error as

Destination did not respond <0x80980800>

This error also comes while pinging the host from netsh>¡­.>diagonisitc .Why it is so

Will this effect if at a particular instance my host machine is not able to find the destination

Also the link

http://technet2.microsoft.com/WindowsVista/en/library/8a70907e-9137-4426-a46f-a2d1eeadbd5a1033.mspx mfr=true says

"If the state is active for Global_, and the number of cache entries is 45 or greater, then the PNRP is properly initialized" what does this mean Some time for me the cache entries are lowere than 45.

Does that mean that the application usinig PNRP wont work properly.

Also, on what these cache entries depends on How can we lower or increase this number



Re: Peer-to-Peer Networking Issue with PNRP name resolution

Tyler - MSFT

I'm not a fan of that technet article. I'll see what I can do to clean it up.

Just to be clear to everyone reading: you should never use PNRPSEEDSERVER.CORP.MICROSOFT.COM. The default seed servers are pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com. For best results, don't change these values. If you're interested in setting up a custom cloud, check out our blog post: http://blogs.msdn.com/p2p/archive/2007/03/18/setting-up-a-private-pnrp-global-cloud.aspx.

It's entirely possible to for PNRP to be healthy with well fewer than 45 cache entries. The article is very cautious.

Sumeet, you may still have bad entries for your seed server. "Destination did not respond" means that your computer can't reach the seed server at that time.

Over the last week, seed servers have been taken down one at a time for upgrades. You may have had cached dns information during the upgrade. It's not typical to receive this error and you shouldn't see it going forward if your seed server reg key contains valid entries. Moreover, these sort of upgrades won't block pnrp from bootstrapping, they just make the ping seed diagnostic command a little confusing ;-)

I hope this helps!


Re: Peer-to-Peer Networking Issue with PNRP name resolution


Hi Tyler,

Going ahead....as i have two VISTA machines with separate broad band connection ,when they communicate over IPV6 with tunneling technolgy.....how do we know which tunneling technolgy is being used internally.

When I check the mode for TERDO and 6to4 through netsh,they both are ONLINE.

How can we differentiate between these two



Re: Peer-to-Peer Networking Issue with PNRP name resolution

Tyler - MSFT

Hi Sumeet,

When you publish a name, PNRP pushes several IPv6 addresses into the cloud (provided you have several addresses of course).

The networking stack will automatically choose the best ipv6 technology automatically when you establish a connection to a peer.

If you have two computers, and they both have 6to4 and Teredo, the networking stack will select 6to4 because it's slightly more efficient than Teredo.

Re: Peer-to-Peer Networking Issue with PNRP name resolution


Thanks Tyler,

As I am using 2 separate broad band connection with separate public IP,TEREDO is the only tunneling technology which can be used in order to have communication between these two mchines.

Correct me if wrong...

Can you please tell me the way to use only teredo to communicate between two machines



Re: Peer-to-Peer Networking Issue with PNRP name resolution

Scott Plant - MSFT

To directly answer your questions:

1) In the most restrictive case, of two machines each behind an IPv4 NAT, then yes Teredo is the only IPv6 address that will be available (plus a link local IPv6 address of course).

2) You can use the command ¡°netsh interface ipv6 show prefixpolicies¡± to see the current policies and ¡°netsh interface ipv6 set prefixpolicy¡± to set policies (depending on your system the command might be ¡°netsh interface ipv6 show prefixpolicy"). You ¡°could¡± set the policy to, when available, use Teredo addresses in preference to all other addresses. Typically you would only want to do this for special testing scenarios though. The default policies will use the best (most efficient) address.

To explain further each of these points:

Question 1) Teredo clients communicating with non Teredo IPv6 hosts (e.g. 6to4 hosts)

A client with only a Teredo address can communicate with native IPV6 hosts, 6to4 hosts and IPv6 ISATAP hosts. Do not get the idea that there are different classes of IPv6 address, such that communication may not be possible between say a Teredo address or a 6to4 address. IPv6 transition technologies, dual IPV4/IPv6 stacks and host-specific relays all go together so that it ¡°just works¡±.

Take the example of a server housed in a data center that is providing services to IPv6 applications, such as our seed PNRP server. As is typically done the data center has provided us with a dedicated static IPv4 address. The server (or administrator) selects a 6to4 address based on the IPv4 address and publishes this address in DNS. The address will be in the range 2002::<32 bit IPv4 address of server>::/48 and will never change since our IPv4 address is statically assigned.

So how does a client, which only has a Teredo address, talk to a server that is only publishing a 6to4 address Believe it or not it DOES use Teredo tunneling.

Since the server has a non-Teredo IPv6 address (even a 6to4 address) it is also capable of running a host specific Teredo relay. This link shows briefly how the setup process occurs http://www.microsoft.com/technet/network/ipv6/teredo.mspx#EMOAC (look for the heading ¡°Initial communication from a Teredo client to a Teredo host-specific relay¡±).

Step 2, the echo request forwarded from the Teredo Server to the host we are trying to contact, is the only step that involves sending a packet directly to the 6to4 address. After all the setup work occurs your Teredo client has a tunnel established with the host specific Teredo relay on the seed server. Communication now occurs directly between the two hosts using the Teredo tunnel. On the other side the host specific relay de-encapsulates the Teredo packets as they arrive, checks that the IPv6 address is for a machine local address and feeds the packet directly into the IPv6 stack.

A slight variation is that the Teredo relay might not exist on the actual host. It is possible for dedicated hardware (e.g. routers) to provide Teredo relay services for many hosts by publishing routes to 2001://32. Typically this would only be done on a per-site basis, for commercial and performance reasons.

The above link also provides examples of Teredo clients connecting to other IPv6 address types. The next link is also a good overview of IPv6 transition technologies in general: http://www.microsoft.com/technet/network/evaluate/technol/tcpipfund/tcpipfund_ch15.mspx

Question 2) Address selection

6to4 and Teredo are the main automatic tunneling technologies. A given host may publish a number of types of IPv6 addresses ¨C native IPv6, 6to4, Teredo. Depending on your operating system, configuration and connectivity your client may also support a number types of these addresses.

Since all tunneling technologies involve some inherent overhead, and converting between tunnel types involves some form of relay (be it within a router to a host specific relay), it is desirable to select from the available source and destination addresses a pair that involves the lowest overhead.

The prefix policy table describes the order of precedence for doing this. Unless you are trying to force a particular situation, e.g. for testing purposes, you really would have no desire to change these priorities.

Here are some references regarding address selection:

1) ¡°Winsock SIO_ADDRESS_LIST_SORT IOCTL¡±. http://msdn2.microsoft.com/en-us/library/ms740614.aspx

2) In Vista WSAConnectByName and WSAConnectByList are new APIs that do all the work for you. See http://www.microsoft.com/technet/network/evaluate/new_network.mspx



3) RFC 3834 - http://www.ietf.org/rfc/rfc3484.txt