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

successful (i.e., one or more IP addresses are found associated with the name "mfp1"), then the process stops and no further steps are performed. In looking at Figure 2, a question immediately arises - What is a cache and why is it used? A cache is typically a RAM based table that allows the resolver to quickly resolve names for an application if the names have been previously resolved. For instance, an example application called X resolves the name "mfp1" to the IP address of 169.254.20.1. A little later, a second application Y tries to resolve "mfp1". It would be very slow if each name resolution request had to generate network traffic to get a response. By caching it - storing it temporarily in memory - the resolver can quickly return the IP address associated with the name "mfp1". Another example is the "hosts" file stored in the SystemRoot\System32\Drivers\Etc directory. This file is parsed and its contents loaded in the DNS cache so that the file doesn't have to be opened and parsed for each name resolution request, which would also slow down the name resolution process. With these details behind us, let's look at the name resolution process for the command "ping mfp1" in depth using Figure 1 as our network. We'll assume that the hosts file has been loaded into the DNS cache and that Vista1 is at the default configuration for DNS and WINS, which is consistent with Figure 1 - Link Local. • 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 and these two requests are sent again. Again, there is no response. • Step 5: Vista1 checks the NetBIOS name cache. "MFP1" not found. • Step 6: Not Done. There is no WINS configuration. • Step 7: Vista1 sends a NetBIOS Name Query over IPv4 to the subnet broadcast address of 169.254.255.255. There is a response!! • Step 8: not performed. Even if Step 7 was not successful, Step 8 would not be performed because LMHOSTS lookup is disabled by default. The name resolution algorithm, the network environment, and the protocols supported by the network devices determined that the name "mfp1" mapped to the IP address of 169.254.20.1 and adds this name to IP address mapping to the NetBIOS cache. The returned IPv4 address to the ping program results in the ping program sending an ICMP Echo Request from 169.254.20.2 to 169.254.20.1. In short, the ping will be processed over IPv4 in this scenario. Phew! That was a lot of work for a simple ping request. What happens if the user types "ping mfp1" again? Essentially, Steps 1-5 only now the name and IP address for "mfp1" is in the NetBIOS cache, so Step 5 completes successfully. Using our ad-hoc conference setup shown in Figure 1, we have determined that connectivity between Vista and an HP MFP would be done using IPv4. Let's assume that another conference room down the hall has a similar setup. What would happen with two link local networks connected by a router? Refer to Figure 3 - Two Link Local Networks. 8