Practical IPv6 Deployment for Printing and Imaging Devices

yummypineappleΛογισμικό & κατασκευή λογ/κού

30 Ιουν 2012 (πριν από 4 χρόνια και 11 μήνες)

450 εμφανίσεις


Practical IPv6 Deployment for Printing and Imaging Devices

May 2008

Table of Contents:


IPv6 – Truths, Myths, and Practical Considerations...............................................................................2

The Importance of Names and Name Resolution.................................................................................4

The Isolated Dual-Stack.....................................................................................................................5

LLMNR Support in HP Jetdirect...........................................................................................................9

IPv6 Link Local Islands....................................................................................................................11

What IPv6 Address Range Should We Use?.....................................................................................15

IPv6 Stateless Automatic Address Configuration (SLAAC)....................................................................20

Preparing the Intranet for IPv6.........................................................................................................24

DNS Zone Options for the Intranet...................................................................................................27

The IPv6 Only Subnets....................................................................................................................27

IPv6 Discovery, Attacks, and Mitigations...........................................................................................28

HP Jetdirect Security Options with IPv6.............................................................................................31


Appendix A: Changing Vista’s Preferences.......................................................................................34

Appendix B: IPv6 Service Discovery.................................................................................................37


The change from IPv4 to IPv6 is coming. There will be deployment difficulties, security concerns, and
potentially a whole new peer-to-peer connectivity model ushered in by the transition to IPv6. The
benefits could be tremendous, but they could also be risky due to lack of IPv6 experience. Although
the transition to IPv6 has been slow, there are many signs it is increasing. The recent resolution of the
American Registry for Internet Numbers (ARIN) has tried to encouraged IPv6 adoption due to IPv4
address space being depleted (
) and prompted additional
interest in IPv6. Lockheed Martin has also announced an IPv6 pilot as they plan on moving towards
an IPv6 infrastructure. Microsoft shipped Vista in 2007 and included IPv4, IPv6, and IPsec as fully
supported connectivity solutions for applications that run on Vista. Windows Server 2008 follows in
Vista’s footsteps with a server platform and fully supported IPv4, IPv6, and IPsec solutions.



This whitepaper takes an application approach to the IPv4 to IPv6 transition. The reality is that IPv4
and IPv6 will be running together for many years as networking protocols. Microsoft Vista, Windows
Server 2008, Mac OS X, and many Linux versions can be deployed with IPv4 and IPv6 running at the
same time. The position expounded here is that upgrading the networking infrastructure for the
Intranet to support IPv4 and IPv6 allows a customer to develop IPv6 expertise, qualify their
applications for both IPv4 and IPv6, develop a DNS strategy, and avoid complex tunneling
mechanisms for the Intranet. In other words, the focus is on the dual-stack transition mechanism and
IP neutral application deployment. This focus is based upon HP’s printing and imaging experience
with IPv4, IPv6, and IPsec. HP has been working on IPv6 for quite a while and shipping products that
support IPv6. For example:

• HP introduced the HP Jetdirect 635n EIO print server which supports IPv4, IPv6, and IPsec in
October of 2005 and is as of September 2007, the 635n is the only print server that has
been certified as IPv6-Capable by United States Department of Defense (DoD) and is on the
DoD’s approved products list:
. Because it can be
added to almost all HP LaserJet and Color LaserJets that have an EIO slot, upgrading existing
printers and MFPs to a 635n card is very easy.
• The 635n also has IPv6 Forum’s IPv6-Ready Phase-2 logo, the highest for any print server:
• In the Fall of 2006, HP began shipping thousands of printers and MFPs with built in
Embedded Jetdirect technology that supports IPv6 and these devices will also have the IPv6-
Ready Phase-2 logo.
• In the Spring of 2007, the advanced HP CM8000 Color MFP Series shipped with Embedded
Jetdirect technology supporting both IPv6 and IPsec.
• In June 2008, the HP Jetdirect 690n 802.11bg EIO print server was introduced allowing
these protocols to run over a wireless printing and imaging infrastructure.

As customers deploy Microsoft Vista, Window Server 2008, and HP’s latest printing and imaging
products, IPv6 will be enabled and active on the network by default. Naturally, this deployment will
bring up many questions: What impact will IPv6 have on existing IPv4 networks? How will IPv6 affect
my imaging and printing infrastructure? How can IPv6 be used to improve a printing and imaging
infrastructure? To answer these questions, we need to examine some popular myths and truths about

IPv6 – Truths, Myths, and Practical Considerations

As the push to IPv6 continues, some vendors will be coming in late with products and experience. In
an attempt to gather momentum and overcome these deficiencies, there is a good opportunity for
Fear, Uncertainty, and Doubt (FUD) about IPv6 to spread. In addition, some vendors may be
promoting their IPv6 products too strongly and ignoring some of the relevant issues regarding its
deployment. HP can help our customers understand these issues because HP has the experience
regarding IPv6 technology and has proven that experience by providing products which meet the
highest certifications currently possible for IPv6. With this experience in mind, let’s examine some of
the myths about IPv6 and develop some practical considerations about IPv6.

Statement: Through the use of Network Address Translation (NAT), IPv4 addresses will never run
out and as a result the transition to IPv6 will never happen.
Status: Myth
Practical Consideration: Over 70% of enterprise corporations employ NAT in some way. NAT
has been extremely useful in allowing IPv4 addresses to be used at a slower pace. However, NAT
works by translating private IP addresses into public ones. Private IP addresses are not allowed on
the Internet. Therefore, all public servers and public routing on the Internet must use public IP


address. These public IP addresses will eventually not be available due to IP address exhaustion as
more and more public IP addresses are handed out. The time when these IP address will no longer
be available is the subject to much debate and most often hinges on how existing IP addresses can be
“taken back” and used more efficiently – however, the day will eventually arrive. For more
information, please refer to the Frequently Asked Questions section for the recent ARIN resolution on
IPv4 address depletion and moving to IPv6:

Statement: With Microsoft’s Vista and Server 2008 having IPv6 enabled by default, simply running
an IPv4 application on these platforms will allow it to become IPv6 enabled and participate in IPv6
Status: Myth
Practical Consideration: Widespread Vista and Server 2008 deployment primarily means a
Dual-Stack transition mechanism for network applications. Dual-Stack refers to an application having
both IPv6 and IPv4 communication available to the application. However, these software
applications will need to be modified (source code changed, recompiled, etc…) to support what is
called an “IP Neutral” Application Programming Interface (API). An IP Neutral application can
communicate over IPv4 or IPv6 transparently to the user. An IPv4 application not modified to be IP
Neutral will remain an IPv4 only
application when executing on a Dual-Stack machine such as Vista
because the application uses an API which only understands IPv4. Also, software solutions that are
comprised of multiple dependent applications must have all their dependent applications modified to
be IP Neutral for the software solution to be IP Neutral.

Statement: Moving to IPv6 will make my network more secure because IPsec is required.
Status: Myth
Practical Consideration: IPv6 will be delivered to customers with IPsec support and without IPsec
support. In addition, should IPsec be delivered with IPv6, it still must be configured to be utilized and
an IPsec configuration can be a complex and time consuming process to get right for a medium to
large sized network. In another sense, deploying IPv6 to an existing IPv4 network can also be seen
to weaken the security of the network. It is very important to explore this point further. There is a vast
amount of expertise in the network security world with IPv4. Intrusion detection and prevention
devices, firewalls, demarcation routers, etc… all understand IPv4 pretty well. This IPv4 expertise
doesn’t necessarily translate into IPv6 expertise. Introducing IPv6 into a stable IPv4 environment
allows for more attack vectors against popular TCP/IP protocols and a proper evaluation of IPv6
deployment is required. As an example, an IPv4 router which has many TCP/IP access control lists
that restrict the type of applications that can be used for IPv4 is upgraded to support both IPv4 and
IPv6 routing. Unless these access control lists are duplicated for IPv6, applications using IPv6 can
circumvent the access lists that were in place for IPv4. Before deploying IPv6 to parts of the network
that have a high amount of security configurations or security devices, be sure to understand how the
configuration of these devices will need to change to accommodate IPv6 and understand whether
these devices have an IPv6 upgrade and support plan. As an example, the latest HP printing and
imaging products with Jetdirect technology allow for IPv4 and IPv6 to be treated equally in regards to
security configurations, such as the negotiation of IPsec or the configuration of packet filtering rules.

Statement: IPv6 is plug-n-play. By simply turning on IPv6 routing, my IPv6 devices will auto
configure and IPv6 can be used just like IPv4 with DHCP.
Status: Myth
Practical Consideration: IPv6 Stateless Automatic Address Configuration (SLAAC) does make it
easy for an IPv6 device to obtain a routable IPv6 address. Unfortunately, this ability comes at a high
price of not being able to securely update DNS with name to IPv6 address mappings (Note –
Integration into Microsoft’s Active Directory can overcome this limitation). Given the length of IPv6
addresses and the goal of IP Neutrality for applications, names are much preferred over explicit IP
addresses. It will be tempting for many customers to allow for unsecured Dynamic DNS updates to
overcome this limitation in SLAAC. Customers should be aware that the large device space (64 bit
identifier in the IPv6 address) with IPv6 means that discovery of IPv6 devices will be difficult to brute
force in a short time and many attackers will logically move towards DNS as a way of finding and


exploiting IPv6 devices. Attackers will love the network environment which allows for unsecured
Dynamic DNS updates.

Statement: Given the practical considerations presented thus far, customers should really develop
solid migration plans to IPv6.
Status: TRUE!
Practical Consideration: Given the recent ARIN resolution and the emerging markets for IPv6,
many products that a customer will buy will be Dual-Stack out of the box. Essentially, by the end of
2007, IPv6 will be enabled and operational on new workstations with Vista, servers with Windows
Server 2008, and newly deployed printers and MFPs as well as many other network devices
targeting the IPv6 market. Customers will be deploying these devices in predominately IPv4
environments. Is your network ready for it? If you don’t answer this question with an enthusiastic
“YES!”, then the answer is “NO!”

IPv6 is a really big event in the networking world and there are bound to be some hiccups in the
deployment of IPv6 in your network. By having a quality migration plan, many of these issues can be
solved before support calls come in or at the very least can be handled with minimal impact to
productivity. One of the goals of such a plan is to make the user completely unaware what protocol
they are using – IPv4 or IPv6. This means that the user application must be IP Neutral. An IP Neutral
application means avoiding the user typing in or using IP addresses. What can we use instead? The
name of a network device provides a level of indirection that hides the IP address of the device. The
importance of names and the process of turning a name into an IP address (or IP addresses!) are
discussed next.

The Importance of Names and Name Resolution
IPv6 addresses are 128 bits in length and to write them out fully requires about 36 characters, as an
example 2001:0DB8:0000:0000:789A:BCDE:FDCB:A987. There are shortcut methods to reduce
the number of characters to help people remember IPv6 addresses. By using those shortcuts the
previous IPv6 address can be reduced to 2001:DB8::789A:BCDE:FDCB:A987, but as you can see
an explicit IPv6 address will never be as easy to remember as an IPv4 address. For instance, HP
printers can be configured to show the IPv4 address on the control panel of the printer. If a user
wants to print to the printer, they often can remember the IPv4 address or quickly write it down on a
small piece of paper or even on their hand. As an example, could be the printer’s
IP address, which isn’t too bad to remember. What if the printer’s IP address on the control panel
showed 2001:DB8::789A:BCDE:FDCB:A987? A user may need to take a picture of the control
panel with their cell phone to remember it!

What is the alternative to displaying explicit IP addresses? The alternative is to use a network name
that describes the device. Almost all networked devices have a name as well as an IP address. For
instance, let’s assume that a printer displayed on the control panel “BLD3P6” which is short for
“Building 3, Pole 6”. This name is much easier to remember than IP addresses. The user would then
take this name and return to their workstation and enter it into an application. Now, the workstation’s
application and Operating System work together to resolve the name into an IP address or multiple IP
addresses. In most cases, a name will resolve to either:

• An IPv4 Address
• An IPv4 Address and an IPv6 Address
• An IPv6 Address

The second case allows for an application to choose either IPv4 or IPv6 or try each address until one
works. The application being able to choose which IP address to use is extremely powerful and will
make name resolution more important than ever.


For our discussion, the Operating System will be Microsoft’s Vista, although Windows Server 2008
would work fine for our examples as well. Depending on the networking configuration, Vista will
resolve names to IP addresses using a variety of algorithms. As IPv6 is introduced through Vista and
HP devices, how the name resolution is handled becomes an integral part of both IPv4 and IPv6
application operation and any long term migrations to IPv6. Let’s start by examining some commonly
used networking topologies and see how name resolution operates in those environments.

The Isolated Dual-Stack

As a review, when an operating system has an IPv4 stack and an IPv6 stack loaded at the same time,
the system is said to be Dual-Stack. An application that can run transparently over IPv4 or IPv6 is
called an IP Neutral application. Let’s assume that an impromptu meeting is setup in a conference
room. A couple of laptops with Microsoft Vista and the latest HP Multi-Function Printer (MFP) are
installed on a switch and everything is powered on.

Both the HP MFP and Microsoft Vista will attempt to find an IPv4 address. They will do this through
different algorithms, but will most likely end up being on the 169.254 /16 subnet. This subnet range
is referred to by a couple of different names – IPv4 Link Local, Automatic Private IP Addressing
(APIPA), IPv4 Zero Configuration, IPv4 Serverless Configuration to name a few. This whitepaper will
refer to the 169.254 /16 address range as IPv4 Link-Local (IPv4LL). IPv4LL has a couple of

• It cannot be routed by routers
• End Nodes randomly select an address in the 169.254 /16 range then defend it

IPv4LL solves the “I don’t have an IP address” problem without administrator intervention or the need
for an IP address issuing server (e.g., DHCP). It allows for local communication only. It works well
for impromptu setups and ad-hoc type of networks. It works less well as a fail-over address. Its
downfall is that it works as the primary address rather than a supplemental address. It is not
supported by all vendors and was a late addition to the IPv4 specification (for details, see RFC

With IPv6, Link Local addressing was an essential part of the specification. Also, unlike IPv4, IPv6
was designed to support multiple IP addresses from its inception. Therefore, IPv6 automatically gets
an IPv6 Link Local (IPv6LL) address as part of the standard IPv6 initialization process and will always
have this IP address even if it is configured with an additional non Link Local address. The IPv6LL
range is FE80::/10. Refer to Figure 1 – Link Local



Figure 1 - Link Local

Let’s assume the following values for each network device after boot up:

• MFP1:, FE80::1, hostname “mfp1”
• Vista1:, FE80::2, hostname “vista1”
• Vista2:, FE80::3, hostname “vista2”

A user on Vista1 types in the following at a Command Prompt: “ping mfp1”. What happens?

The “ping” application on Vista1 will attempt to do name resolution of the name “mfp1” in order to
find the IP address associated with that name by calling a function called getaddrinfo(). This function
is implemented by the Vista operating system and is part of the standard for implementing an IPv6
API. There are no servers (e.g., DNS, WINS) configured in this link local environment, so Vista1 will
attempt to use the Link Local Multicast Name Resolution (LLMNR) protocol. This protocol works over
IPv4 and IPv6 and Vista1 will try IPv6 first. An HP MFP with an Embedded Jetdirect version of
V.37.XX and lower does not support LLMNR and the LLMNR packets go unanswered (Note: We will
discuss Jetdirect’s LLMNR implementation, available in a later firmware release, in another section).
Next, Vista1 will use NetBIOS over IPv4 which the MFP will respond to and the MFP tells Vista1 its
IPv4 address. This basic description is really what is seen on the network from a packet perspective.
However, a lot more is happening behind the scenes. Let’s cover this a little more in depth. Refer to
Figure 2 – The Vista Resolver:



Figure 2 – The Vista Resolver

Microsoft’s Vista resolver is doing a lot of work trying to find out the IP address or IP addresses for the
name “mfp1”. First, the name “mfp1” is a single label name. In contrast, “” would
be a multi-label name. The resolver must perform the most work with single label names because
single label names can fit a variety of name resolution protocols and Vista1 may need to try all of
them. If the name was a multi-label name, then only DNS would be used (Numbers 1 and 2 in Figure
2) because the other name resolution protocols only support single label names. Second, because the
network is an ad-hoc network or Link Local network, there is no DNS configuration, no WINS
configuration, and the lookup up LAN Manager hosts (LMHOSTS) is disabled by default. Essentially,
this is Vista1’s default configuration. Third, if any of the steps one through seven in Figure 2 are


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 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 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 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 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 to 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.


Figure 3 - Two Link Local Networks

The first thing that should be pointed out is that routing is not possible with these Link Local
environments. A router is shown, but this router will not forward any link local traffic from one
network to the other. In addition, the router will not forward destination IP addresses in the IPv4 Link
Local Multicast range (224.0.0/24), any limited broadcast packets (, or any
subnet broadcasts ( Therefore, a user on Vista1 executes the following
command: “ping mfp2”. The name resolution will fail because MFP2 will never receive any link local
name resolution traffic. In short, Link Local Network 1 does not know Link Local Network 2 exists and
vice versa.

LLMNR Support in HP Jetdirect

Just to shake things up a bit, HP Jetdirect introduced LLMNR support based on RFC 4795 in firmware
versions V.38.XX and later, which was just introduced in 2008. As time goes on, LLMNR support in
HP devices will gradually increase of course, but since it is not widely available, this whitepaper will
cover LLMNR in separate sections. Let’s look at a new diagram, Figure 4 – LLMNR.

Figure 4 - LLMNR


The following descriptions are color coded so that they can be referenced in Figure 5 – Network

(1) Vista1 executes the command “ping mfp0”. Note: mfp0 does not exist
. We are using a non-
existent name to show the algorithm being used.

• Step 0: The ping application, which on Vista is IP Neutral, internally calls getaddrinfo() with
the name “mfp0”
• Step 1: The resolver checks the DNS cache. “mfp0” not found.
• Step 2: Not done. There is no DNS configuration.
• Step 3: The resolver checks the LLMNR cache. “mfp0” 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 There is no
• Step 5: Vista1 checks the NetBIOS name cache. “MFP0” 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 There is no response.
• Step 8: not performed because LMHOSTS lookup is disabled by default.

(2) Vista1 executes the command “ping mfp1”, mfp1 supports LLMNR

• 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 Jetdirect
responds to both requests. Vista1 prefers IPv6 over IPv4.
• The ICMP Echo Request/Reply over IPv6 is sent.

(3) Vista1 executes the command “ping mfp2”, mfp2 does not support LLMNR.

• Step 0: The ping application, which on Vista is IP Neutral, internally calls getaddrinfo() with
the name “mfp2”
• Step 1: The resolver checks the DNS cache. “mfp2” not found.
• Step 2: Not done. There is no DNS configuration.
• Step 3: The resolver checks the LLMNR cache. “mfp2” 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 There is no
• Step 5: Vista1 checks the NetBIOS name cache. “MFP2” not found.
• Step 6: Not Done. There is no WINS configuration.
• Step 7: Vista1 sends a NetBIOS Name Query for “MFP2” over IPv4 to the subnet broadcast
address of There is response.
• The ICMP Echo Request/Reply over IPv4 is sent


Figure 5 – Network Trace

HP Jetdirect ships with LLMNR enabled by default. If for any reason, the administrator does not want
LLMNR to be used, it can be disabled on HP Jetdirect. When LLMNR is supported but disabled,
NetBIOS name resolution will result in IPv4 being used.

IPv6 Link Local Islands

When Microsoft began rolling out Windows NT, DHCP was used to automatically assign IPv4
addresses and the Windows Internet Naming Service (WINS) provided a server based name
resolution. This setup is still used today in many environments. Refer to Figure 6 – IPv6 Link Local

Figure 6 - IPv6 Link Local Islands

As we can see in Figure 6, IPv4 addresses are being assigned to the various network devices via
DHCPv4. We’ll assume that the IPv4 Router is acting as a DHCPv4 Relay agent. The DHCPv4 server
is also providing options to clients and one of those options is the NetBIOS name server or WINS
server option, which provides the IPv4 address of the WINS server. DHCPv4 clients that support
WINS will use this option to register their names with WINS as well as lookup names to IPv4 address
mappings. WINS only supports IPv4.


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 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
• 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, the entry may look something like this: 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

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.


Figure 7 - ADI DNS

Here we are formally introducing Active Directory. We’ll assume the domain name is
“example.internal” and that all Microsoft servers and workstations are part of the domain. Active
Directory Integrated DNS (ADI-DNS) is where the DNS database is stored in Active Directory. For
devices that are integrated into the Active Directory, ADI-DNS allows for a secure update to DNS
using a kerberized DNS update mechanism. Devices that are not integrated into the Active Directory
either use WINS or ask the DHCPv4 server to update DNS on their behalf.

A typical network setup would be that the DHCPv4 supplies the DNS server address, the domain
name, and the router IP addresses to the two subnets shown in Figure 7. Upon receiving this
information from the DHCPv4 server, the Vista systems can update DNS. The HP MFPs ask the
DHCPv4 server to update DNS on their behalf and if a WINS server is provided in the DHCPv4
configuration, the HP devices will register their names with the WINS server too.

In the DNS database for the zone “example.internal”, something like the following would probably
be seen:

• vista1 A // added to DNS by Vista1
• vista2 A // added to DNS by Vista2
• mfp1 A // added to DNS by the DHCPv4 Server
• mfp2 A // added to DNS by the DHCPv4 Server

Essentially, vista1.example.internal will map to, vista2.example.internal will map to, and so on. These mappings are stored in what is called an “A” record. DNS can
also hold name to IPv6 address mappings through an AAAA record. The same name, such as
“vista1”, can have multiple A records and multiple AAAA records associated with it. Notice the no
IPv6 records are present – this is because the only IPv6 addresses available are Link Local addresses.
Vista will not register Link Local addresses in DNS and neither should you because Link Local
addresses are only valid for their subnet and a name to address mapping could be returned to a
device on another subnet. This would result in communication errors and timeouts. In addition,
Microsoft also recommends not adding Link Local addresses to the hosts file either.

Once we have introduced DNS into our infrastructure, we now have two commonly used names that
can be used to identify devices. One is to use the hostname and the other is to use a Fully Qualified
Domain Name or FQDN (Note: technically an FQDN ends in a period – such as
“mfp2.example.internal.”, but the term FQDN is commonly used in the way described here). Here
are the examples:


• “ping mfp2”
• “ping mfp2.example.internal”

Depending on the name typed in, two very different name resolutions are carried out by Vista. We
talked earlier about single label names and multi-label names. The “ping mfp2” command is where
we will start, assuming it is execute on Vista1. In order to illustrate the difference in name resolution
between the two commands, let’s assume that the user makes a mistake and types in “mfp3” instead
of “mfp2” for both commands

Let’s look at what happens for “ping mfp3” (Refer back to Figure 2):

• Step 0: The ping application, which on Vista is IP Neutral, internally calls getaddrinfo() with
the name “mfp3”
• Step 1: The resolver checks the DNS cache. “mfp3” not found.
• Step 2: The resolver sees that there is a DNS configuration. Taking the name “mfp3”, it
concatenates “.example.internal.” as the primary DNS suffix and asks the DNS server for
name resolution information for the A record or IPv4 record. This process will continue as
long as there are DNS suffixes available in the configuration. The name
“mfp3.example.internal” will return a result code indicating that condition.
• Step 3: The resolver checks the LLMNR cache. “mfp3” 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 There is no
response since the HP MFP doesn’t support LLMNR.
• Step 5: Vista1 checks the NetBIOS name cache. “MFP3” is not found.
• Step 6: Vista1 checks the WINS server. “MFP3” is not found.
• Step 7: Vista1 sends out a NetBIOS broadcast over IPv4. “MFP3” is not found.
• Step 8: Not Performed

Compare this process to this command executed on the same machine “ping mfp3.example.internal”

• Step 0: The ping application, which on Vista is IP Neutral, internally calls getaddrinfo() with
the name “mfp3.example.internal”
• Step 1: The resolver checks the DNS cache. “mfp3.example.internal” not found.
• Step 2: The resolver sees that there is a DNS configuration. The resolver asks the DNS server
to resolve the name “mfp3.example.internal” to an IPv4 address (an DNS A record). Since
this name doesn’t exist, it will return a result code indicating that condition.
• Step 3: Not Performed
• Step 4: Not Performed
• Step 5: Not Performed
• Step 6: Not Performed
• Step 7: Not Performed
• Step 8: Not Performed

In the second command, because the user has specified an FQDN, only the DNS server is queried.
Vista1 will not try to get the AAAA record because Vista1 only has a Link Local IPv6 address. Since
other Link Local IPv6 addresses should not be in DNS and Link Local IPv6 addresses cannot be routed,
to ask for an AAAA record would be to simply waste DNS server bandwidth.

What if the user had typed “mfp2” correctly? Well, both name resolutions would have gone to Step
2 and succeeded. What if the record wasn’t in DNS? Well, the command “ping mfp2” would have
been successful because the WINS server would have been tried. However, the command “ping
mfp2.example.internal” would have failed because only the DNS server is tried because the user
entered an FQDN. This is an important point: “ping mfp2” would have worked but “ping


mfp2.example.internal” would have failed because “ping mfp2.example.internal” effectively says:
“only check the DNS server”.

Effectively in these last few configurations, although all the Vista machines and HP MFPs have an IPv6
address, communication only goes over IPv4. Can we force IPv6 to be used in these environments?
Sure, but we are forced to use the IPv6 Link Local address explicitly, which really provides no benefit,
is extremely error-prone, and can only be used for communication on the local subnet. As we can
see, IPv6 for HP’s printing and imaging devices results in “IPv6 Link Local Islands” because IPv6 is not
used due to how name resolution operates.

What IPv6 Address Range Should We Use?

We’ve covered IPv6 being turned on by default and being deployed in IPv4 environments. What
happens if we actually want to deploy IPv6 but do not want to have an Internet IPv6 presence?
Rather than discuss a way of getting an IPv6 address range from an Internet Service Provider (ISP),
this whitepaper will discuss the IPv6 Unique-Local range which can be setup for a given environment
or “site”. This process will not allow IPv6 address to be used to access the Internet directly, but will
allow the deployment of routable IPv6 addresses in the intranet. We can use Unique-Local internally
to a “site” and populate the internal DNS servers with this information (e.g. “example.internal” and
not “”). The Unique-Local Range is formatted as follows (from RFC 4193):

Prefix: 7 bits
Local Bit: a single bit set to a one.

Effectively, the above shows the prefix for Unique-Local will be FD in hexadecimal

Global ID: 40 bits or 5 octets
Subnet ID: 16 bits or 2 octets
Interface ID: 64 bits or 8 octets

For our purposes, the 40 bits for the Global ID is the most important. What we want to do is come
up a random way of generating the 40 bits. We only have to do this once for an entire site (Note:
“site” is a loose term. A company may have several physical sites, but in this discussion all of those
sites will have only one global ID and the different physical sites will be differentiated through the
subnet field).

We can simply borrow some dice from a family game at home or buy some from the store for a small
amount of money. We will create a table of 40 rows. Each row represents a throw of a die. The
value of the die throw will be converted to a binary value. This conversion is done as follows: If the
die value is odd, the binary value is one; if the die value is even, the binary value is zero. An
example table and values is shown in Figure 8:


Figure 8 - Die Roll to Binary Conversion


Once we have this table, we can bring up the Windows calculator to do the rest of the work for us.

Figure 9 - Standard View Calculator

Change to the Scientific View.

Figure 10 - Change to Scientific View


Figure 11 - Scientific View

Select Binary.

Figure 12 - Select Binary

Enter the Binary values from your dice rolls.


Figure 53 - Enter Binary Value

Select Hex, which will automatically conver the Binary value to Hexadecimal, to get the Global ID.

Figure 64 - Convert to Hexadecimal

The format of the unique-local address would be as follows:

FD [insert random string here] [subnet]::/64

Assuming a subnet of zero and using the random value in Figure 14, we have:



To maintain and promote our general sanity, we will match our subnet values for IPv6 with the subnet
values for IPv4 as shown:

Figure 15 - Unique Local Network Configuration

This unique-local IPv6 range was done only for example purposes so please do not use it in actual
deployments. In addition, the IPv6 link local address is still available to be used, just not shown. The
rest of this whitepaper will use the non link local IPv6 range assigned for use in documentation,

IPv6 Stateless Automatic Address Configuration (SLAAC)

Assuming the network administrator decides to upgrade the IPv4 router to support IPv4 and IPv6 or
adds a separate router to support IPv6 routing, suddenly the network behavior could change quite
drastically because IPv6 supports automatic IPv6 address configuration. In order to configure an IPv6
router, non link local IPv6 addresses associated with the links need to be configured. In most cases,
once a non link local IPv6 address has been configured on the router, the router will provide IPv6
Automatic Address Configuration to the link segment.

A standard part of the IPv6 initialization process for end nodes (like HP printers and MFPs) is to look
for IPv6 routers so that they may provide IPv6 automatic address configuration information.
Suddenly, every IPv6 enabled device now has at least two IPv6 addresses: A link local IPv6 address
and a non link local IPv6 address. Refer to Figure 16 – IPv4/IPv6 Network


Figure 76 - IPv4/IPv6 Network

Let’s break down the IP addresses on this network (NOTE: this is not a listing in DNS, only the IP
addresses assigned to the nodes in Figure 16):

• vista1, 2001:db8:1::21, fe80::21
• vista2, 2001:db8:1::22, fe80::22
• mfp1, 2001:db8:1::23, fe80::23
• mfp2, 2001:db8:2::100, fe80::100
• WINS, (no IPv6)
• DNS, (no IPv6)
• DHCPv4 (no IPv6)

With the addition of these IPv6 addresses, the name resolution algorithm used by Vista will change
slightly. The change happens in DNS. Let’s look at the command “ping mfp2.example.internal”

• Vista1 asks the DNS server for the A record of the name “mfp2.example.internal”.
Depending on the result code returned, Vista1 may also ask for the AAAA record of

The important thing about this algorithm change is that Vista1 asks for an A record first. There are
two scenarios that are important: 1) The DNS server has no A record and no AAAA record for
mfp2.example.internal and 2) the DNS server has no A record for mfp2.example.internal but does
have an AAAA record for mfp2.example.internal. The DNS server result code in the response will be
different depending on what records are in its database and Vista1 will know whether to try LLMNR
or query the DNS server for the AAAA record. If both records exist, Vista1 will get both the IPv4
address and the IPv6 address. By default, Vista’s resolver will list the IPv6 addresses before the IPv4
addresses when presenting the name resolution results to the client application (NOTE: this behavior
can be changed – refer to Appendix A).

In our example, the DNS server only has an IPv4 address which Vista1 will use to ask the DNS
server name resolution questions. Therefore, Vista1 is asking for IPv6 information over the IPv4
protocol. This network behavior is perfectly valid. DNS resolvers and servers are not supposed to
make any assumptions about record types and the underlying transport. A DNS resolver can ask for
A records over IPv6 or AAAA records over IPv4.


Continuing with this example, let’s look at their DNS name to IP address mappings:

• vista1 A
• vista1 AAAA 2001:db8:1::21
• vista2 A
• vista2 AAAA 2001:db8:1::22
• mfp1 A // Added to DNS by DHCPv4 Server
• mfp2 A // Added to DNS by DHCPv4 Server

Vista machines are able to update DNS securely because of their tight integration with Active
Directory. HP printers and MFPs have to rely on the DHCPv4 server to update DNS on their behalf.
However, because there is no DHCPv6 server operating on the network, it doesn’t appear as though
the same name registration can happen automatically with IPv6. Therefore, only the A record is
available for mfp1 and mfp2 in DNS.

In short, “ping mfp2.example.internal” will result in IPv4 being used based upon the DNS records
shown previously. To “force” IPv6 to be used, there are several options. The most common option is
to have the DNS administrator add AAAA records manually to DNS for the printers and MFPs. This
manual process is tedious, but is required for security reasons. It is possible to allow network devices
that support Dynamic DNS to update DNS insecurely, but that would be a mistake for any
environment. In order to update DNS securely, these devices would need to be integrated into the
Active Directory and support Microsoft’s kerberzied DNS update mechanism or supply DNS security
credentials in some secure manner and have the device securely update DNS on its own. To be
honest, the last approach is not a very good one as getting DNS security credentials distributed
securely is not an easy task and it would probably be easier to simply update DNS with the
appropriate IPv6 addresses since they are less likely to change than IPv4 addresses.

Let’s change our example slightly. We have a node called mfp3.remote.example.internal. Assuming
that an AAAA record is added for mfp3.remote.example.internal and because Vista prefers IPv6 or
IPv6, IPv6 would then be used for everything right? Well, not exactly. What Vista will do is gather
all the IP addresses for a given name. Let’s assume that the DNS entries for mfp3 are as follows:

• mfp3 A (Placed here by DHCPv4 Server)
• mfp3 AAAA 2001:DB8:128::21b:78FF:FE0A:5D9A (Placed here by the DNS

In order to properly explain what happens next, we are going to have to switch applications. Let’s
start using FTP instead of ping. From the command prompt:

“FTP mfp3.remote.example.internal”

Here Vista will get both the IPv6 and IPv4 addresses from DNS and put them in a list. The FTP client
on Vista will attempt to establish a TCP connection to port 21 on the IPv6 address
2001:DB8:128::21b:78FF:FE0A:5D9A. We can look at a network trace and verify this functionality

Here we can see the DNS query in the first four packets (communication over IPv4). First an IPv4
address is returned and then an IPv6 address is returned. The FTP client then chooses the IPv6


address and begins the FTP connection on it. What happens when a given protocol is supported
over IPv4 but not IPv6? What would the behavior be? Let’s look at a trace where we are trying to
open a telnet connection to mfp3.remote.example.internal. HP Jetdirect does not support telnet on

Here we can see that the DNS query behaves as before and the IPv6 address is selected as before.
However, when the connection is attempted over IPv6, the TCP connection is RESET (RST) indicating
that this port is not supported. The FTP client tries a couple more times (rather persistently). Rather
than quit altogether, the client changes to use IPv4 and a connection is then accepted.

This process of gathering all the IP addresses associated with a name and then trying each IP address
until a “good one” is found for a particular service is extremely important to understand. It is a
fundamental part of every application that claims to be IP Neutral. Unfortunately, each application
must implement these changes and some applications may not do it correctly. This could lead to
performance issues. Be sure to try more than one application when troubleshooting these types of
problems to try and eliminate network issues versus application issues. An example of a networking
issue would be where DNS contains an AAAA record that describes a host. However, IPv6 is not
network routable from all locations of the site network. When a Vista client resolves the name and
gets an IPv6 address and begins to try and contact it, the client is assuming that the IPv6 address can
be reached over the network. If it cannot, it must timeout before moving to another IP address. If all
applications are timing out because of IPv6 reachability issues, application performance could drop
to unacceptable levels. In the example above, the switch from IPv6 to IPv4 due to Telnet not being
supported over IPv6 happens in about one second, because the Telnet server is able to return a TCP
RST and inform the client immediately. Let’s look at a case where we have a DNS records indicating
IPv4 and IPv6 addresses, but only connectivity over IPv4. The host is on the IPv4 network
192.168.0/24 and the IPv6 network of 2001:db8::/64 and is trying to reach

Here we can see that there is a 21 second delay (as opposed to one second) when IPv6 reachability
is an issue. You can also see in this trace how the DNS query goes over IPv6 but asks for both IPv4
and IPv6 records.

Keep in mind that once a non link local IPv6 address is configured on Vista clients and Vista clients
are part of an Active Directory Integrated DNS environment, IPv6 addresses will automatically appear


in DNS records for those Vista clients. Also keep in mind that a non link local IPv6 addresses can
appear on your Vista clients by simply adding an IPv6 router to your network – which may not be
what the IT Administrator wanted!

Assuming there are not any IPv6 network reachability issues, let’s make sure we understand the
difference between these two commands:

• “FTP 2001:DB8:128::21b:78FF:FE0A:5D9A”
• “FTP mfp3.remote.example.internal”

The first command fails and the second command passes because, unbeknownst to the user, the
second command switches to use IPv4 after the IPv6 connection fails. This leads us to a second
important point about IP Neutral services – there should be no difference in the service capability
when accessed over IPv6 as compared to IPv4. Why? In most cases, users will be using name
resolution rather than explicit IP addresses (mainly because after typing in one IPv6 address explicitly,
you’ll never want to type in another one). Therefore, the user will be typing in a name because it is
much easier. As we have seen throughout this whitepaper, the name resolution algorithms are
dependent on many variables and these variables control whether IPv6 or IPv4 is selected without the
user’s knowledge. Imagine a web server that served up different content for a user depending on
whether IPv4 was used or IPv6 was used when the user has no idea what IPv4 or IPv6 even refers to!
For example, a web browser on one client machine could display different content from a web
browser on another machine, even though the name in the URL was exactly the same – one machine’s
name resolution chose IPv4 and another machine’s name resolution chose IPv6. Clearly, this
behavior would not be desired.

What have we learned in this section? Well, if the network administrator decides to configure the
company’s routers with IPv6, suddenly IPv6 SLAAC takes over and all IPv6 enabled devices get a non
link local IPv6 address in addition to the link local IPv6 address they have. Basically, all these
devices now have 3 IP addresses – an IPv4 address, a link local IPv6 address, and a non link local
IPv6 address. If an IPv6 enabled device is integrated into the Active Directory and supports the
kerberized DNS update mechanism, then most likely the IPv6 addresses are in DNS, which could
lead to reachability issues.

Preparing the Intranet for IPv6

Using Unique-Local IPv6 addresses provides for a lot of flexibility for the Intranet. The great benefit of
the Unique-Local addressing is that it allows a customer to develop the following:

• IPv6 Expertise
• IP Neutral Application Testing and Deployment
• IPv6 Security Evaluations Within the Intranet

As a customer’s experience grows, they may be able to begin to convert some subnets over to IPv6
only and relinquish IPv4. When the day comes to connect to the IPv6 Internet, a customer can do so
with the knowledge and experience. When the IPv6 Internet is brought in, a customer will need to
begin what could be a painful renumbering process (moving from a Unique-Local IPv6 prefix to a
Global IPv6 address prefix). Until that day, we can get by just fine by using Unique Local IPv6
addressing. (NOTE: Network Address Translation (NAT) may also be a solution to get from a Unique
Local IPv6 address to a Global IPv6 Address. However, NAT is frowned upon by most if not all IPv6

This whitepaper will not discuss intranet tunneling methods such as ISATAP. The primary reason is
that Vista and Longhorn will be shipping with IPv6 enabled and operational along with IPv4 and most
environments have not migrated to IPv6 at all. This means that the initial transition mechanism will be


Dual-Stack. By controlling how AAAA records get into DNS, this Dual-Stack transition mechanism will
allow us time to add IPv6 capability to internal routers. When IPv6 is fully routable across the
intranet, we reach a point where we can add AAAA records to our existing hostnames that are
capable of Dual-Stack, starting with our domain controllers, proxy servers, DNS servers, and other
fundamental servers. Once our Dual-Stack methodology is proven, we then can start to experiment
with IPv6-only subnets.

In what follows, a sample network will be shown along with typical connections to the Internet for
small to medium size companies. This sample network is not intended to be a recommended
deployment, but simply for illustration and educational purposes.

Refer to Figure 17 – Intranet and Internet

Figure 17 - Intranet and Internet

Here we have a simple network where we’ve separated out our Public Servers from our Internal
Servers. The public servers remain IPv4 and the components that provide security to our network from
the Internet remain IPv4 (e.g., Firewall. Other components may include Host Intrusion Detection
Systems, Network Intrusion Detection Systems, etc...). DNS Zones are also different from the internal
network (example.internal) from the external network ( The internal zone will have
both A and AAAA records while the external zone will only have A records.

The internal servers have been placed in their own subnet and are Dual-Stack. Using SLAAC, we are
able to give out our Unique Local range. However, unless our devices are integrated into the Active
Directory, we will not be able to securely update DNS. With the sheer amount of network
appliances, not just printers and MFPs, there are a multitude of devices that may not need or desire
integration with Active Directory. Consequently, getting these addresses securely in DNS becomes a
tedious task.


This whitepaper makes the case for disabling SLAAC and moving to DHCPv6 for stateful IPv6 address
management. The paramount objection to moving to DHCPv6 for stateful IPv6 address management
is that SLAAC can use DHCPv6 to provide “Other” parameters and therefore there is no need for
DHCPv6 to provide anything but those “Other” parameters, such as IPv6 addresses for DNS servers.
What DHCPv6 and stateful IPv6 address management does provide is the following:

• Centralized IPv6 Address Management
• DNS Update via the FQDN option

First and foremost, if one has to setup the DHCPv6 server for the “Other” parameters, one might as
well use its IPv6 address management capability and get the DNS Update functionality. This extra
benefit seems to provide quite a bit without involving a lot of extra work. The only other requirement
is that DHCPv6 Relay Agents are used so that DHCPv6 messages can be sent and received across
routers for unconfigured clients.

Refer to Figure 18 – DHCPv6

Figure 18 - DHCPv6

Here we have shown our DHCPv6 server and our DHCPv6 Relay Agents. Devices that are not
integrated into the Active Directory can utilize the DHCPv6 server to enter their IPv6 addresses and
corresponding names into DNS.


DNS Zone Options for the Intranet

Now that we have a setup where DHCPv4 updates the A records in DNS and DHCPv6 updates the
AAAA records in DNS for our non Active Directory integrated devices, we can also consider other
options for DNS Zones.

One of the issues with IPv6 migration is the concern that the initial migration will impact the IPv4
production network. As we can see, the implementations of iterating through various IP addresses are
left up to the application. This process is application dependent. One option to alleviate these types
of concerns is to create a unique zone in the Intranet for IPv6 addresses and use client configured
DNS Suffix to point to the IPv6 zone. As an example:

DNS Forward Lookup Zone: example.internal
All records except AAAA records
Updated by DHCPv4 for devices not integrated in the Active Directory

DNS Forward Lookup Zone: ipv6.example.internal
All records except A records
Updated by DHCPv6 for devices not integrated in the Active Directory

Client Configuration
Primary DNS domain name: example.internal
DNS Suffix: ipv6.example.internal

Thus, typing “ping mfp2” from the command prompt of Vista1 would result in the following:

• Vista1 would look for mfp2.example.internal
• Vista1 would look for mfp2.ipv6.example.internal
• Vista1 would try other hostname resolution options

In short, IPv4 would be tried first. Only if an IPv4 address was not available would the IPv6 suffix be
tried. Also, to force IPv6 to be used, the application could utilize “mfp2.ipv6.example.internal” and
not have to type in an IPv6 address.

Although this initially sounds like a good idea, the main problem is that a device may only be able to
handle one domain name for both IPv4 and IPv6. HP Jedirect handle separate domain names if
desired for IPv4 and IPv6, but that may not be true of all devices. For example, if the DHCPv6 server
provides a domain name for IPv6 and the DHCPv4 server provides a domain name for IPv4, which
one does the client use? Another possible option is to stay with a single domain name and configure
Vista clients to prefer IPv4 to IPv6 and then gradually change the preference one subnet at a time,
stopping when there are any issues. Appendix A describes this configuration.

The IPv6 Only Subnets

Obviously, as we integrate IPv6 in our environment, our goal is to eventually be using IPv6 exclusively
and IPv4 is not available for use. This environment is called an IPv6-Only environment. The most
natural place to begin implementing the IPv6 only environment is in the subnet.

It is important to mention that an IP Neutral environment and an IPv6-Only environment are not the
same things. For a given solution, many applications and services may be used. Some of these
applications may be IP Neutral and some may not be. Therefore, moving to an IPv6-Only
environment could cause problems for some solutions that have not moved all the components of that
solution to be IP Neutral.


It is also important to recognize there may be key services on the network that must
be dual stack (or
IPv6 only) when moving a subnet over to IPv6 only. As an example, domain controllers, http proxies,
recursive DNS servers, etc… all have to be accessible over IPv6.

Refer to Figure 19 – IPv6 Only Subnet

Figure 19 - IPv6 Only Subnet

Here we have created an IPv6 only subnet. Notice that the server subnet all needs to be dual stack
and be accessible over IPv6 for this process to be successful. At this point, various applications can
be deployed in the IPv6 only subnet (as well as communicate with the IPv6 only subnet remotely) to
see how they react.

IPv6 Discovery, Attacks, and Mitigations

So now we have IPv6 only subnets. What are some of the things we should worry about?

Discovery: Unicast

One of the ways to highlight some concerns over IPv6-only network deployments is to first talk about
an IPv4 only network. Here is a scenario Web Jetadmin administrator working on an IPv4 only

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 250 usable IPv4 addresses per subnet (/24). I configure 5 ranges total and schedule
the discovery, which iteratively goes through each usable IPv4 address with a unicast packet, waits


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


not a good security practice. So, to update DNS, we’ll need to use DHCPv6 and get a domain name.
We would have to manually configure a cryptographic key to allow for secure D-DNS updates. How
does this device get the DNS key? Well, this is a problem because it must be done securely and
DHCPv6 isn’t implemented with DNS key cryptographic distribution capability, which means it must
be done manually, which means we have to find the devices to do it, which means we are back to
square one. Even assuming we did get a D-DNS cryptographic key and we did implement a DNS-SD
mechanism, one has to wonder that if DNS begins to resemble Active Directory in terms of logical
configuration and mapping of services, and Active Directory is in use in most environments, why we
aren’t using Active Directory?

Discovery: Active Directory

With Active Directory Integrated DNS (ADI-DNS), we know that computers that are integrated into the
AD can update their DNS records securely. However, there is no need to do service discovery via
DNS. Computer objects within the directory have attributes that can be modified to enable nodes to
discover objects using a search of the directory. That is all wonderful so far, but how many devices
are integrated into the AD? How many mobile nodes and other various devices for which IPv6
development was a driver for have built in AD support? Doesn’t AD support require administrative
intervention to first create the object in AD to begin with? How does that administration happen with
headless and mobile IPv6 devices?


If you place yourself in an attacker’s shoes and you need to find IPv6 devices because you have an
IPv6 exploit, what would you do? Well, you could try the following:

• Use IPv4 to find devices. Networks that are IPv4/IPv6 and haven’t shut down IPv4
completely can utilize IPv4 to cut down on time to find Dual-Stack devices (via unicast or
• Use Site-Local Multicasts to find IPv6 devices. Some devices incorrectly report ICMPv6 errors
to multicast packets. By sending a Site-Local Multicast to a non-well-known UDP port you may
be able to find those devices quickly. You can also use Link Local multicast packets to scan
through UDP ports to find UDP ports that are open and responsive over a given protocol and
then attempt to use Site-Local multicasts for the same protocol. As an example, attempt
Service Location Protocol (SLP), LLMNR, and multicast DNS (mDNS) over site local multicast
addresses to see if there are any implementations out there responding to them.
• Search the DNS server for service records or attempt to get a Zone transfer to find all the
devices. If you are able to find some valid domain names, guessing at hostnames is much
easier than searching the IPv6 Identifier address space.
• If you can find an LDAP server, see if you can search the directory for devices anonymously.

What if you don’t want to find devices but just want cause a lot of IPv6 disruption (or network

• Blasting out site-local multicast addresses to randomized UDP ports with randomized hop
limits is a good start.

What if you want to compromise devices that you have found without relying on software exploits?

• Use SNMP over IPv6 to try and find network agents that you can write MIBs on. Sometimes
Access Control Lists have been specified to prevent this for IPv4, but were the ACLs updated
for IPv6 when IPv6 was deployed? This is true of any management protocol, not just SNMP.
• Check if the DNS servers support unsecured DNS updates. If so, modify entries or populate
new service records.
• Check for IPv6 web servers – they may not have the same security as the IPv4 web servers.


In short, any management protocol that has IPv4 specific restrictions can potentially be used without
those restrictions via IPv6.


You seem worried about IPv6 only networks. You should be. There are a set of problems that
currently do not have adequate solutions because IPv6 only enterprise environments don’t really exist.
We can speculate on some of the things that would be necessary

• Smart desktop switches – intelligence is required at the network edge for IPv6 constraints
• The ability to designate ports on a switch that are connected to IPv6 routers. Traffic is filtered
• The ability to enforce disabling IPv6 automatic address configuration – we don’t want to use
it and a “bad” node that still attempts to use it can be detected by the switch and disabled
• The ability to require DHCPv6 on a switch port to be successful before allowing any traffic
from a non-link local address. The switch maps DHCPv6 addresses to ports for valid IPv6
addresses and discards anything that is non-link-local and not assigned via DHCPv6.
• The ability of a DHCPv6 to setup a “signature” in the randomization of the last 64 bits of the
DHCPv6 address. For instance, for all DHCPv6 address assignments, the interface ID must
have octet 0 bit 5 set to zero, octet 1 bit 4 set to one, etc… This “signature” can be used by
other layer three devices to distinguish valid unicast IPv6 addresses (e.g., assigned by my
authorized DHCPv6 server) from invalid ones in Access Control Lists.
• The ability to designate ports on the switch as being for a DHCPv6 server or DHCPv6 relay.
• The ability to filter all IPv4/IPv6 tunneling/transition protocols at the switch (e.g., 6to4,
ISATAP, Teredo).
• Only authorized multicast servers can send multicast packets with greater than link local
• Any switch that receives a multicast packet from a non-authorized node with greater than link
local scope must wrap that packet in a transport and send it to the authorized multicast server
for a decision.

Some fun work needs to be done!

HP Jetdirect Security Options with IPv6

In terms of IPv4, IPv6 and IPsec, there are three types of HP Jetdirect products:

• IPv4 Support, no IPv6 support, no IPsec support
• IPv4 Support, IPv6 Support, no IPsec support
• IPv4 Support, IPv6 Support, IPsec support over IPv4 and IPv6

For the products that support IPv6, HP Jetdirect provides several options to help with the security of the

First, some customers may not want to have IPv6 enabled by default. HP Jetdirect provides the
capability to disable IPv6 if so desired. Refer to Figure 20, which is a snapshot of the Embedded
Web Server. By simply unchecking the Enable checkbox and clicking Apply, the IPv6 protocol can
be disabled.


Figure 20 - IPv6 Enable/Disable

For those customers that would like to have IPv6 capability for certain services and have other
services disabled, HP Jetdirect provides a Firewall configuration which can be used to control access
to the printer/MFP (NOTE: Please follow normal security precautions by setting passwords and
controlling access to the Networking tab. See the whitepaper “HP Jetdirect Security Guidelines”). In
the following example, because we are concerned with our security infrastructure not being as ready
for IPv6 attacks as IPv4 attacks, we are going to disable IPv6 for management protocols, but enable
IPv4 and IPv6 for everything else. Refer to Figure 21:


Figure 21 - Firewall Policy

Rules are processed in order. The first rule will drop any management protocol, such as SNMP, that
is being carried by IPv6. IPv4 is not affected by this rule. The next two rules allow IPv4 and IPv6 for
any remaining traffic that was not handled by Rule 1. In this way, we can force management access
to only work over IPv4. For products that support IPsec, the Firewall can be used to force IPsec to be
used for certain services, like management services. All an all, the Firewall provided by HP Jetdirect
allows for a variety of configurations and a lot of flexibility for the administrator.

Microsoft’s Vista, Windows Server 2008, and the new HP Printing and Imaging devices will have
IPv6 enabled by default. As these devices are deployed in our existing IPv4 environments, we can
see how name resolution plays a fundamental process in the Dual-Stack transition methods. Using
the name resolution algorithm in Vista, we went through various network environments and studied
how the introduction of routable IPv6 addresses will affect network applications. Through the same
name resolution mentality, we also discussed DHCPv6, SLAAC, the impact to DNS, and made
some recommendations. Hopefully all of the issues discussed in this whitepaper will prompt its
readers to create their own IPv6 transition plan!


Appendix A: Changing Vista’s Preferences
We can experiment with Vista preferences without having a device that supports IPv6. In the hosts
file located in SystemRoot\System32\Drivers\Etc, there are two entries by default: localhost
::1 localhost

These entries refer to the loopback address which is used to “loop back” networking traffic through
the stack and back to an application without going on the actual network itself. Because there are
two records for the name “localhost”, one IPv4 and IPv6 address, and Microsoft’s Vista will prefer
IPv6 addresses in the default configuration, IPv6 should be used when the command “ping localhost”
is executed. Refer to Figure 20.

Figure 8 - Hosts

Now we can execute the ping command – Refer to Figure 21.


Figure 9 - Ping

It is not possible for the request to be sent out to and for a reply to be received from ::1.
Therefore, you know that the ping command used the IPv6 loopback address of ::1 based upon the
text “Reply from ::1”. Since there are two localhost entries, we know that IPv6 must be preferred.

We can change Vista’s preferences by modifying the Registry. Before making modifications to the
Registry, a backup copy should be made. The Registry key we want to modify has to first be
created. Refer to Figure 22:

Figure 10 - Disabled Components

We can see that the key resides here:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
The key needs to be called DisabledComponents and should be a DWORD set to zero.

Now we need to modify the value of Disabled Components to have Vista prefer IPv4 over IPv6.
We can do this by setting the value to 0x20. Refer to Figure 23.


Figure 11 – Value

Now we will need to restart Vista for the changes to take effect. Once the restart has completed, we
can execute the “ping localhost” command again. Refer to Figure 24.

Figure 12 – Ping

Now the reply is coming from, the IPv4 loopback address. Therefore, we have made
Vista prefer IPv4 over IPv6.

To disable all tunneling technologies, but not IPv6, use 0x01 for this key. This setting would be
recommended for those customers committed to the Dual-Stack transition method.


Appendix B: IPv6 Service Discovery
Apple has led the way in creating Zero Configuration IP networks. This leadership has resulted in the
IPv4 Link Local configuration algorithm, multicast DNS, and DNS service discovery, all of which when
implemented by Apple is collectively called “Bonjour”. HP printers and MFPs were among the first to
have Bonjour support with IPv4. Now, HP printers and MFPs that have IPv6 support also support
Bonjour over IPv4 and IPv6 with firmware V.34.XX or later. Using Bonjour, IPv6 could automatically
be selected to be used as a communication protocol transparently to the user. Bonjour is available
for several different operating systems, not only MacOS.

Bonjour works equally well for discovering services when the IP address range has been
administratively configured. These services are local to the subnet that the computer running Bonjour
is attached. In most cases, this limitation is fine. To expand service discovery to a larger network
topology requires additional work that is beyond the Zero Configuration standard. In any case,
whenever a DNS server is involved, the security of the server and the validity of its records become
paramount in importance.

Many confuse Bonjour with LLMNR. LLMNR is a way to establish and resolve link local names to IP
addresses using IP multicast technology but doesn’t involve service discovery. As an example of this
difference, HP’s Universal Print Driver uses the service discovery technology of Bonjour as one of its
methods to find printers and MFPs. An alternative way of discovery services on the network is called
Web Services Discovery or WS-Discovery. HP printer’s and MFPs that support IPv6 support WS-
Discovery over IPv6 using V.34.XX or later, support WS-Discovery over IPv4 and IPv6 with firmware
V.36.XX or later, and support LLMNR with V.38.XX or later. Microsoft’s Vista and HP Software will
be using WS-Discovery extensively.