UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Platform: 8530.93.0 stable-channel daisy

Steps to reproduce the problem:
1. It appears that Chromebook is designed to not work with link-local IPv6 addresses, whereas, the Chrome browser installation on Windows seems to not think of this as an issue. 
2. Chrome browser in either setup overwrites it's copy of the printers IPv6 address with each AAAA record the printer advertises.

Based on #1, I will mark this CR as Not a Defect.

With regard to #2, we performed the following testing.
1. DHCPv6 was turned ON on the test router
2. An Iceman unit (Linux 1.0) was connected to the network along with Palermo Fast (Linux 3.0)
3. When advertising its AAAA address, the Iceman orders the link-local IPv6 address ahead of the DHCPv6 address.
4. Palermo/Limo orders the DHCPv6 address ahead of the link-local IPv6 address.
    This ordering is based on how the addresses are returned to mDNS by NCA/NC.
5. In the case of Iceman, Chromebook overwrites the LL IPv6 address with the following DHCPv6 address.
    In the case of Palermo, Chromebook overwrites the DHCPv6 address with the following LL IPv6 address.
6. In the case of Iceman, Chromebook issues a POST on the privet registration URL over the DHCPv6 address.
    In the case of Palermo, Chromebook determines the address is not routable and does not POST to the privet reg URL.
7. The confirmation screen pops up on Iceman but not on Palermo.

After hacking mDNS to advertise only the DHCPv6 AAAA record, the confirmation screen popped up when attempting to register the printer via the Chromebook.

After this observation, I upgraded Chromebook and the Chrome browser on Windows to see if either of their behaviours changed. But they continued as before i.e. Chrome browser on Windows has no problem with LL IPv6 address; Chromebook has a problem with LL IPv6 and also overwrites it's copy of the printer IP address with each AAAA record it receives from the printer.

It is reasonable for Chromebook to take issue with LL IPv6 but overwriting its copy of the printer address record with each AAAA record it receives is incorrect Bonjour behaviour. The least it could do is not perform the overwrite if it finds the printer address copy is already DHCPv6 address. But this is still wrong behaviour. Chromebook will still end up overwriting manual and DHCPv6 addresses and this will potentially create problems at the time of registration.
Can you help raise a bug with Google about this? Chromebook should maintain as many records of the printer address as mDNS advertises.

Here are the upgrade details.
Chromebook:
Google Chrome: 53.0.2785.144 (32 bit)
Revision: 0
Platform: 8530.93.0 stable-channel daisy
Blink: 537.36 (@0)

Chrome browser on Windows: 53.0.2785.143

What is the expected behavior?
Printer should show confirmation screen when trying to perform GCP registration via chrome://devices while set to "Enable IPv6 only"

R&D Development Engineer wanted me to raise an issue with Google in regards to "Printer confirmation screen not coming up if registering via chrome://devices while set to "Enable IPv6 only."

This issue only occurs if using Chromebook device but not if using Windows device - Chrome browser.

What went wrong?
mDNS has moved to libnc for Linux 3.0 (new HP products HP is working on currently) whereas it was using NCA in Linux 1.0 and classic prior HP products Google has qualified. The way the IPv6 addresses are returned by both interfaces is different. Earlier, we would get an array of IPv6 addresses and now, mDNS traverses a linked list of IPv6 addresses from the tail node, building the AAAA records along the way. mDNS can traverse the address list from the head node. But this still is not a guaranteed fix for Chromebook. 

Here is snapshot of the AAAA records returned by Naples:

Chromebook notes the printers IP address when it sees the first AAAA record, which is a link-local(LL) IPv6 address.
When it sees the second AAAA record, it overwrites the printer’s address with this new value which happens to be a routable address. 
When the user tries to register the printer, Chromebook finds that the printers address it has stored is routable and can perform a POST on that address.

Here is a snapshot of WeberPDL running Linux 3.0:

Chromebook notes the printers IP address when it sees the first AAAA record, which is a routable DHCPv6 address.
When it sees the second AAAA record, it overwrites the printer’s address with this new value which happens to be a LL address. 
When the user tries to register the printer, Chromebook finds that the printers address it has stored is not routable and won’t perform a POST.
Chromebook should have maintained both copies of AAAA records or not overwritten the routable address with the LL address.

When DHCPv6 is turned off on the router, both the Naples unit and the WeberPDL unit hold only LL IPv6 addresses. In this case, Chromebook won’t talk to either printer. The registration confirmation screen won’t pop up on either printer. So this scenario is not new to Linux 3.0.

Do you know what Google’s typical turnaround on defects is? If the overwrite issue will take too long to resolve at their end, we can change the AAAA advertisement ordering in mDNS. But again, this will handle only this specific DHCPv6 scenario. Once manual addresses enter the picture, Chromebook can get cranky again. 

Did this work before? N/A 

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: 53.0.2785.144 (32 bit)
Flash Version: Shockwave Flash 23.0 r0