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

three seconds for a response, then goes to the next IPv4 address. A total of 25,000 IPv4 addresses must be checked (100 subnets, 250 hosts per subnet). By waiting 3 seconds for each IPv4 address, a worst case discovery time of 75,000 seconds would occur, which is about 21 hours. Each night the discovery runs for 4 hours, which means I can just about discover everything in about a week. Here is the same Web Jetadmin administrator in an IPv6 only environment. I am a Web Jetadmin administrator responsible for a network of 100 subnets. Anytime someone installs a printer or MFP on the network, I want to find this device in a reasonable amount of time and put the necessary configurations on it for our network. Every night from 10pm to 2am, except Saturday and Sunday, I configure a network discovery using IP ranges. Each range has 20 subnets and there are 18,446,744,073,709,551,616 usable IPv6 addresses per subnet (/64). I configure 5 ranges total and schedule the discovery, which iteratively goes through each usable IPv6 address with a unicast packet, waits three seconds for a response, then goes to the next IPv6 address. A total of 1,844,674,407,370,955,161,600 IPv6 addresses must be checked (100 subnets, 18,446,744,073,709,551,616 hosts per subnet). By waiting 3 seconds for each IPv6 address, a worst case discovery time of 166,020,696,663,385,964,544 seconds would occur, which is about 52644817562 centuries. Each night the discovery runs for 4 hours, which means I can just about discover everything in ...... Obviously, directed IPv6 discovery over a randomized 64 bit Identifier is not going to work. Even when using algorithms that allow certain fields in the 64 bit Identifier to be well known and hence discarded, we still don't have a workable unicast discovery solution. The next step is to see if we can utilize IPv6 Multicast along with a discovery protocol. Discovery: Multicast Assuming we are using a discovery protocol on top of IPv6 multicast, IPv6 multicast has different IPv6 multicast addresses for different multicast scopes. The two scopes which will concern us here are the Link Local Scope and the Site Local Scope. Link-Local scopes for multicast addresses are for the local subnet only - they don't traverse routers. As a result, unless a separate software program is running on each of the 100 subnets we are attempting to discover devices on, we aren't going to find every device on these subnets. Moving to Site Local multicast addresses, we have an address that could reach every subnet in what is loosely termed "site". Which subnets are reached depends on the value associated with the hop limit, which can be from 1 to 255. What would be the difference between sending out a Site Local Multicast discovery using a hop limit of 16 versus 32? Well, it is "site" specific - depending on configuration. What this means is that a hop limit of 16 may reach 100 subnets on the "site" and a hop limit of 17 may reach 1000 subnets. There is no way to really control it using Site Local multicasts. What happens to network bandwidth when 1000 subnets need to respond to a Site Local Multicast? Well, it depends on the protocol and the implementation in the end nodes. A good implementation randomizes responses over a lengthy period, but not all implementations are good ones. As a network administrator for an enterprise IPv6 deployment, do you really want a lot of Site Local multicast packets floating around your network? Do you want to rely on end nodes to implement multicast responders correctly? Do you want anyone who can get a SLAAC address to be able to send out Site Local multicast traffic? Discovery: DNS RFC 5006 allows a DNS server address to be returned via an IPv6 router advertisement. Here, a SLAAC device now doesn't need DHCPv6 to get the IPv6 address of a DNS server. Assuming that Dynamic DNS updates can be done without security, the node can now update DNS with its name. The name by itself isn't of very much use, so DNS Service Discovery (DNS-SD) could be used to update DNS with service records for the device. Unfortunately, this device doesn't know what domain name to use, so it is in trouble here too. Not to mention, allowing unsecured DNS updates is 29