Subject: Re: ipv6 link-local multicast problems
To: None <M.Drochner@fz-juelich.de>
From: Jun-ichiro itojun Hagino <itojun@itojun.org>
List: tech-net
Date: 11/08/2003 06:48:10
> > i would suggest specifying interface
> > 	explicitly, always, even with IPV6_JOIN_GROUP. 
> 
> Thanks -- yes, it is easy because the id is needed for the bind()
> anyway. The ntp-4.2 code just doesn't care about scope_ids at all --
> do other IPv6 implementations not need it to be specified?
> 
> Can one assume that every IPv6 stack worth using supports
> the sin6_scope_id member (so it wouldn't need #ifdefs)?

	Linux IPv6 implementation is ancient and uses RFC2133 API, which lacks
	sin6_scope_id.  USAGI effort is trying to update it to more recent
	one with sin6_scope_id.  when i write software i do not support
	implementation with RFC2133 API, since without sin6_scope_id link-local
	and other addresses are ambiguous and we cannot make application run
	in a robust way.

> Another problem I ran into with ntp-4.2 is that it picked up
> KAME-mangled link-local IPv6 addresses when it enumerated its
> interfaces. (ie, with the scope id in byte 3)

	how does it get the list of interface addresses?  getifaddrs?
	SIOCGIFCONF?  anyways, we need to translate KAME-mangled address into
	normal one (with sin6_scope_id filled) on getifaddrs/SIOCGIFCONF.

> While bind()ing to such an address works (the non-zero bytes are
> silently ignored), this breaks crypto authentication because
> the sending IPv6 address is used to calculate a session key.
> Imho, these mangled addresses shouldn't occur outside the
> kernel (except for kvm readers, where it can hardly be avoided).
> Both the sysctl() and the SIOCGIFCONF method however pass the
> internal representation of the addresses to users.
> Well, user code can fix it (as some NetBSD utilities as eg route(8)
> do), but this seems unnecessary because in both cases a complete
> sockaddr structure is passed, so the scope_id can be put into
> its designated field.

	SIOCGIFCONF/sysctl exposes kernel internal address structure so special
	handling is needed in the apps.  getifaddrs is a wrapper to SIOCGIFCONF
	so it passes anything passed from SIOCGIFCONF directly to the apps.

	yes, we could change SIOCGIFCONF to do the dirty work in the kernel,
	however, (1) we would have INET6-specific code in sys/net/route.c
	and/or rtsock.c which is ugly, (2) i'm not sure if such API change
	will be safe after long-time deployment of the mangled API.
	so i'm afraid of making the change.

itojun