Ticket #174 (reopened defect)

Opened 1 year ago

Last modified 3 weeks ago

ipv6 link-local address are not complete

Reported by: Tobu Assigned to: Tobu
Priority: major Milestone:
Component: nss-mdns Version:
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

10/06/07 16:44:19 changed 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?

10/06/07 17:19:41 changed 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.

10/06/07 18:38:35 changed 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.

10/06/07 22:12:37 changed 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 .

10/09/07 20:59:49 changed by lennart

  • status changed from closed to reopened.
  • resolution 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

10/10/07 23:39:34 changed 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.

10/12/07 00:56:39 changed by lennart

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

sorry for the confusion.

10/07/08 12:52:38 changed 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