HP 635n HP Jetdirect Print Servers - Practical IPv6 Deployment for Printing an - Page 12

Assuming the user at Vista1 typed "ping mfp1", what will happen in an attempt to find the name to IP address mapping? As reference, please refer back to Figure 2 where Vista's resolver is described. Here are the new steps for the network in Figure 6: • Step 0: The ping application, which on Vista is IP Neutral, internally calls getaddrinfo() with the name "mfp1" • Step 1: The resolver checks the DNS cache. "mfp1" not found. • Step 2: Not done. There is no DNS configuration. • Step 3: The resolver checks the LLMNR cache. "mfp1" not found. • Step 4: Vista1 sends an LLMNR Name Query Request packet over IPv6 using a destination IPv6 multicast address of FF02::1:3 first, then Vista1 sends an LLMNR Name Query Request packet over IPv4 using a destination IPv4 multicast address of 224.0.0.252. There is no response since this HP MFP doesn't support LLMNR. • Step 5: Vista1 checks the NetBIOS name cache. "MFP1" not found. • Step 6: Vista1 checks the WINS server. Since MFP 1 supports DHCPv4 and WINS registration, the name should be found and an IPv4 address is returned and the mapping is added to the NetBIOS name cache. • Step 7: Not Performed • Step 8: Not Performed An important take away in this example is that even though Vista1 and MFP1 are on the same network, a centralized name server was contacted on a different subnet in order to resolve the name. In addition, even if MFP1 was recently powered off before the ping command was executed, the name resolution would still have been successful since the resolution is being carried out by a different server and not by the device itself. The ping would have failed because the device was not operational, but the name resolution would have been successful. Referring to the same Figure, What if the user typed "ping mfp2"? Since "mfp2" is not in the NetBIOS name cache, it would proceed to Step 6 and use WINS just like the "ping mfp1" name resolution. There are some other important take aways with this example: • The router is IPv4 only, so LLMNR over IPv6 packets won't go anywhere except the local subnet. • LLMNR over IPv4 will not be forwarded by the IPv4 router because LLMNR uses link local multicast addresses that are not forwarded by routers. • Should Step 6 fail because "MFP2" was not in the WINS database, NetBIOS over IPv4 uses IP broadcasts which are likely blocked by the IPv4 router and Step 7 would have likely failed as well. Therefore, name resolution would have failed! Essentially, if your HP MFP is on a different network and it is not in a centralized name server such as WINS, name resolution will fail. How can we overcome this failure? Well, we can manually add the entry to the %SystemRoot%\System32\Drivers\Etc\Hosts file. Assuming the IPv4 address of "mfp2" was 192.168.2.100, the entry may look something like this: 192.168.2.100 mfp2 Now, when the hosts file is preloaded into the DNS cache, the name resolution of "mfp2" will succeed. However, manually adding entries to the hosts file is an error prone and high overhead method of making sure name resolution works. It shouldn't be used except in the simplest of networks. Let's look at an even more common setup for an organization - where name resolution has been partially transitioned from WINS to DNS. Refer to Figure 7. 12