Ticket #174 (reopened defect)

Opened 6 years ago

Last modified 4 years ago

ipv6 link-local address are not complete

Reported by: Tobu Owned by: Tobu
Milestone: Component: nss-mdns
Keywords: Cc:

Description

When using avahi to get ipv6 addresses, the addresses in the fe80::/64 range should be suffixed with something like %eth0 to be usable. These "link-local" (in the ipv6 sense) addresses are specific to the interface where they are published.

Otherwise, tools like ssh won't be able to use these addresses; ssh justnexttome.local won't work.

Look for "scoped addresses" in this document:  http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/#CHAPTER-SECTION-USING-API

Change History

Changed 6 years ago by lathiat

The Avahi API already provides this information which can be used in a bind()

If you want the format is as %(interface) this would be an application specific thing?

Changed 6 years ago by Tobu

Looking at "getent hosts callisto.local" just gave me the ipv6 part without the scope part, so I assumed something was wrong with avahi.

But if the avahi api does give the scope part, there is still a chance that it is lost or ignored by libnss-mdns, libnss3, and the two programs I have tested, ping6 and ssh.

I'll have a look at what libnss-mdns does.

Changed 6 years ago by Tobu

  • owner changed from lennart to Tobu
  • status changed from new to assigned
  • component changed from avahi-core to nss-mdns

The scope info gets lost in libnss-mdns's implementation of gethostbyname & friends.

It should be added back only for the fe80::/64 range, and for symmetry it would have to be added to gethostbyaddr too, so that we have this behaviour:

//callisto has a link-local address, useless without scope
gethostbyname("callisto.local") => "fe80::42...%eth0"
//router has a global address and needs no scope
gethostbyname("router.local") => "fe02::86..."
//accept scoped addresses
gethostbyaddr("fe80::42...%eth0") => "callisto.local"

It seems the fix should be in nss-mdns's avahi.c's avahi_resolve_name and avahi_resolve_address; I'll write a patch.

Changed 6 years ago by Tobu

  • status changed from assigned to closed
  • resolution set to wontfix

This is impossible to fix, because the NSS SPI requires the use of struct hostent, which is a bunch of struct in6_addr, which are just 128 bits and no zone/scope information. NSS would have to use a sockaddr_in6 to solve the problem.

For info, some of the details on link-local addresses are in RFC 4007.

The NSS SPI is just:  http://www.gnu.org/software/libc/manual/html_node/Host-Names.html#Host-Names .

Changed 6 years ago by lennart

  • status changed from closed to reopened
  • resolution wontfix deleted

Hmm, actually I believe this might indeed be fixable. According to Ulrich Drepper NSS modules may now implement the full getipnodexxx() APIs which support passing iface indexes. It's just not documented.

Reopening, since this needs to be investigate a bit more

Changed 6 years ago by Tobu

Good news; I have a git checkout of glibc, but I really hope I don't have to build it.

The getipnode... stuff seems deprecated, I think the recommended API is getaddrinfo and getnameinfo (possibly some of the support for NSS getipnode... has been removed by the looks of the changelog). The NSS stuff uses some macros, so I'm not really sure of what can be done.

Best would be to ask what commit introduced that support.

Changed 6 years ago by lennart

Sorry, of course I ment getaddrinfo ("gai") when I said getipnodexxx()

sorry for the confusion.

Changed 5 years ago by JeremyVisser

Just for the record, Mac OS X manages to do this fine.

e.g. ssh myserver.local will correctly connect to fe80::42...%en0

Note: See TracTickets for help on using tickets.