Description of problem:

If NetworkManager learns an name server with a link-local IPv6 address via DHCPv6 (the bug probably applies to RDNSS too, but I have not verified), it will write the address to /etc/resolv.conf without appending the interface ID. Since this address is ambiguous to glibc, it cannot be used.


Version-Release number of selected component (if applicable):

NetworkManager-0.8.9997-5.git20110702.fc15.x86_64


How reproducible:

100%


Steps to Reproduce:
1. Connect to a network that announces a link-local IPv6 nameserver using DHCPv6. In my case, this is done by the default behaviour of a ZyXEL P-2812HNU-F3 VDSL router, and is logged thusly by NetworkManager:

[...]
<info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) started...
<info>   address 2001:840:3033:10::d001
<info>   prefix 64
<info>   nameserver 'fe80::ca6c:87ff:feab:d027'
<info>   nameserver '2001:840:100::'
<info>   nameserver '2001:840:200::'
<info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
[...]


Actual results:

I end up with a resolv.conf containing the following:

> # Generated by NetworkManager
> search fud.no
> nameserver fe80::ca6c:87ff:feab:d027
> nameserver 2001:840:100::
> nameserver 2001:840:200::


Expected results:

Ending up with a resolv.conf that specified the interface ID for the link-local address, in my case like so:

> # Generated by NetworkManager
> search fud.no
> nameserver fe80::ca6c:87ff:feab:d027%eth0
> nameserver 2001:840:100::
> nameserver 2001:840:200::


Additional info:

In my case with the ZyXEL P-2812HNU-F3, this isn't a major problem as it also announces its upstream resolvers as the scondary and tertiary server. glibc will seamlessly and without delay fail over to those. However, the link-local address (which belongs to the ZyXEL itself) had been the only address that was being announced, any attempt to resolve anything would likely have failed.