Deploy360 29 May 2014

Case Study: Printing and Scanning Over IPv6 Only?

By Jan ŽoržFormer Operational Engagement Programme Manager

As happens to all of us from time to time, my old printer broke down and it was time to get a new one. However, for me, as co-author of RIPE-554, which defines the IPv6 requirements for ICT equipment, I couldn’t just go and buy any printer. It had to have IPv6 support. After a bit of searching, I finally found one that fit all my needs, including IPv6 support: A Brother DCP-7065DN.

After unboxing the device and connecting it to the network – the truth reveals: It has IPv6 support!

Printer Setup

Setting up the IPv6 address is not a problem; the menu is  under “Network configuration” -> “Configure TCP” (where IPv4 settings are) -> “Configure IPv6”.


So far so good! After initial setup I could ping6 the device with no problems whatsoever.

One important note: Router Advertisements (RAs) are enabled on this link, so the printer can setup its default route using SLAAC. For printing and scanning purposes I’m using a statically configured IPv6 address on the printer’s network interface.


The next step was to get my MacBook to work with the new printer. For printing there was no issues whatsoever. I chose “add a new printer,” put in the IPv6 address and the system immediately gathered the correct model and settings over IPv6 and selected the correct driver for it:


After setup, the printer was ready for the test and printing now works with no glitches over IPv6, even when I’m far away from home (and connected to an IPv6 network, of course).

A quick examination with Wireshark reveals that the packets carrying the print job are actually using IPv6 as a transport:


Too cool!

With printing working perfectly over IPv6, my next challenge was scanning over IPv6…


There is a Brother software called ControlCenter2 that is supposed to enable scanning over the network. While I did not test it with IPv4, it certainly has some issues using IPv6.

When I began the setup, my MacBook was on a different network segment than my new Brother printer. Printing over IPv6 worked like a charm – but not scanning. I tried to add the printer to my MacBook’s settings, but all I received back was an unidentified error. It seemed that the scanner software on the printer did not understand where to send packets, or where its gateway was.

Editors note: This is very likely due to either improperly scoped multicast discovery packets, or a home router blocking those multicast discovery packets. See work on service discovery in the IETF Homenet working group for more.

Of course, the next thing I did was to connect my MacBook to the network segment where the new printer is. From that point on everything went extremely well! The scanner was immediately recognized and then I could happily scan remotely, well, sort of “remotely.” I need to be on the same network segment to be able to scan over IPv6. Hopefully someone from Brother is reading this and can fix this small inconvenience for me (please, send me the patched version of drivers) 🙂


So, it looks like at least some printer vendors are implementing IPv6 today, and Brother is one of them.

A use-case for ULA?

The other issue that I encountered while using the printer over IPv6 is the dynamic nature of the local network that we are setting up. My laptop is set up to do SLAAC, so if my CPE goes down or loses its IPv6 connectivity settings then my printer is not reachable anymore, even from my local network. Since my CPE gets the prefix delegation over DHCPv6 from my ISP if that is gone (due to a link failure for example) then the IPv6 routing in my house is gone too. Well, not entirely in my house as my network gets reconfigured fairly quickly, but for a “normal” user who is not a network engineer this could be a serious problem. This is where ULA kicks in and I must admit, I put the ULA in the network segment where my printer resides – just for a test – and it worked. So there is one possible use-case for ULA addresses: For printers, home devices and all other gadgets that we want to connect to even if our ISP’s IPv6 connectivity is down or broken. In my case I removed the ULA from my network after the test, but for the less hands-on home network administrator it might be handy to have it configured just in case.

Final conclusion: We’ve come a long way, baby!

Good work, Brother. They still have some minor fixes to do, but generally IPv6 seems to just work, at least on this printer.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...