> itojun@itojun.org said:
> > 	Linux IPv6 implementation is ancient and uses RFC2133 API, which
> > lacks sin6_scope_id.
> 
> Hmm - the sin6_scope_id member is present in unpatched 2.4 kernels, it was
> missing in 2.2. This doesn't mean of course that it is actually supported,
> but software just referencing it should compile, and the resulting code
> shound't work worse than before, right?
> The ntp4.2 release notes state:
> > If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected,
> > support for the IPv6 address family is generated
> and since scope_id is part of rfc2553, ntp should not try to compile in
> IPv6 support if scope_id is not present.
> As you see, I'm trying to avoid to introduce unnecessary #ifdefs...
> Do you think this argument is good enough, so I can suggest my present
> patches to the ntp people?

	i feel no need to support RFC2133 API (i.e. linux 2.2).  assuming
	RFC2553 is fine.

> > 	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
> agreed, such stuff should be in protocol specific functions, but having
> it in many userland applications is not much better...
> A clean userland interface would be good to have.
> > i'm not sure if such API change
> > 	will be safe after long-time deployment of the mangled API
> I see that there is no short-term solution, but a viable plan could be to
> introduce a macro for address exporting, something like
> #define __KAME_EXPORT_IP6_ADDRESS(a) do {\
> 	if (IN6_IS_ADDR_{,MC_}LINKLOCAL(a) &&\
> 	    (a->sin6_addr[{2,3}] != 0)) {\
> 		a->sin6_scope_id = ...;\
> 		a->sin6_addr[{2,3}] = 0;\
> 	}\
> } while(0);
> and get it into all affected code.
> Then the kernel could be changed later and the code would still work.
> Just an idea...

	we (KAME) have been wondering what is the right way to go.
	for instance, if we are to stop using kame-mangled address format,
	netmask for routing table lookup will become non-continuous; non-radix
	routing table lookup speedup techniques (like ART algorithm in KAME
	tree) cannot be used.  we're still wondering.

itojun