Subject: Re: fe80::/16 on specific link layers

From: Sander Steffann <[email-masked]>
Date: Tue, 1 Aug 2017 12:53:15 +0200

Hi,

> Op 31 jul. 2017, om 19:09 heeft 神明達哉 <[email-masked]> het volgende geschreven:
> 
> At Mon, 31 Jul 2017 12:37:35 +1000,
> Mark Smith <[email-masked]> wrote:
> 
>>> It would break BSD-variant implementations, which internally use the
>>> 2nd 16-bit field of link-local addresses to identify the corresponding
>>> link, e.g., fe80:1::abcd means fe80::abcd in link "#1".  (It's an
>>> internal form and doesn't appear on wire).
>>> 
>>> Yes, that's an ugly implementation-specific hack and you could blame
>>> the designer of the idea.  But I'm afraid we can't simply ignore the
>>> deployment base as a matter of practice.
>> 
>> I'm curious what the consequences would be of making BSD-variants
>> compliant? Are any user space applications relying on it? Does BSD
>> support the Sockets API and therefore applications should be using the
>> scope_id field for zone (ifindex) information rather than using this
>> link ID in the reserved LL address field?
> 
> [...]
> 
> Some special purpose applications still deal with the hack themselves,
> though.  They include network statistics apps (that read the kernel
> memory directly) and routing protocol apps (these tend to use
> non-standard APIs to get access to the kernel's routing table, where
> the raw in-memory representation is exchanged between the kernel and
> apps).

I also remember Gert Döring running into this when implementing some OpenVPN IPv6 stuff as well, but then I guess OpenVPN does some funny routing table manipulations and falls under that category :-)

Cheers,
Sander

---

From: Gert Doering <[email-masked]>
Date: Tue, 1 Aug 2017 11:27:24 +0200

Hi,

On Tue, Aug 01, 2017 at 12:53:15PM +0200, Sander Steffann wrote:
> I also remember Gert Döring running into this when implementing
> some OpenVPN IPv6 stuff as well, but then I guess OpenVPN does some
> funny routing table manipulations and falls under that category :-)

I ran into it when writing the code to figure out where a given IPv6
address is currently routed to (to be able to install a /128 host 
route for the VPN Server via "outside interface" when all IPv6 is 
routed "inside" the VPN).  Since gateways happen to be RA-installed,
I saw fe80:<ifindex>::<hostid> route next-hops...

The code currently uses what FreeBSD route.c used to do:

        struct sockaddr_in6 *s6 = (struct sockaddr_in6 *)gate;
        struct in6_addr gw = s6->sin6_addr;

        if (gate->sa_len == sizeof(struct sockaddr_in6)
            && IN6_IS_ADDR_LINKLOCAL(&gw) )
        {
            gw.s6_addr[2] = gw.s6_addr[3] = 0;
        }

... just zero'ing the fields on receive-from-kernel, as we're not 
using the scope ID directly (we use the interface name, which is
delivered as RTA_IFP in the routing socket response).  I said "used to
do", as FreeBSD changed their interface already, delivering scope_id
and not using s6_addr[2] and [3] any longer (if I remember correctly).

But that's indeed a special case application, talking routing sockets
directly - for us, it would not be a problem if these two fields were
always zero.  Other software talking to the routing socket is likely
aware of the operating system variants and does whatever is needed -
especially since there's differences in the data structures used 
already today.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email-masked]
fax: +49-89-35655025                        [email-masked]