Subject: Re: Review for draft-smith-6man-link-locals-off-link-00.txt

From: Dan Lüdtke <[email-masked]>
Date: Sat, 12 Dec 2015 17:39:40 +0100

Hi Mark,

I just wanted to point out that the section 5.1. sin6_scope_id may not behave as expected on all major operating systems. I had quite some trouble getting the interface id (read: the scope) on BSD systems.

The kernel handles the scope internally by embedding it into the link-local address instead of appending it or having a dedicated data structure for that. Unfortunately, the kernel leaks that data _unmodified_ towards the API. You expect to find the scope id in scope_id, but actually it looks something like this:

addr = fe80:3::1
scope_id = 0

In this case, 3 is the scope_id has has to be copied to scope_id manually and then removed from the address part. To me, this is ridiculous, but I gave up on fixing this, for political reasons. The last time I tried was with bitrig, as BSD fork.

--> https://marc.info/?l=bitrig-tech&m=144522332620846&w=2

I just think that it is very improtant to mention in your draft that some major operating systems may not fully comply with the API. It does help developers a lot. Imagine how surprised I was when I ported a software from Linux to BSD and wasted *hours* figuring out what was going on there.

Thanks!

Dan

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Dec 2015 06:04:18 +1100

Hi Dan,

Thanks for the comments. I presume you mean them for my other draft on
using LLs (How to use IPv6 Link-Local Addresses in Applications).

I plan to do some work on it over the upcoming holidays.

> I just think that it is very improtant to mention in your draft that some major operating systems may not fully comply with the API. It does help developers a lot. Imagine how surprised I was when…

Yes, that sounds like it was very frustrating. I'll mention that some
OSes are known not to be compliant, or perhaps mention this specific
one and how it encodes the scope information.

While not compliant with the sockets API, I think it also specifically
means that BSD or that fork is not compliant with RFC4007, "IPv6
Scoped Address Architecture".

Thanks very much for you comments.

Best regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Dec 2015 19:27:23 -0800

At Sat, 12 Dec 2015 17:39:40 +0100,
Dan Lüdtke <[email-masked]> wrote:

> The kernel handles the scope internally by embedding it into the
> link-local address instead of appending it or having a dedicated
> data structure for that. Unfortunately, the kernel leaks that data
> _unmodified_ towards the API.

That's certainly ugly, but I think it's not unfair to clarify that in
most APIs the BSD implementation tries to hide the ugliness from
applications.  As commented in the code referenced in this link...

> --> https://marc.info/?l=bitrig-tech&m=144522332620846&w=2

             * BSD variants embed scope zone IDs in the 128bit
             * address as a kernel internal form.  Unfortunately,
             * the embedded IDs are not hidden from applications
             * when getting access to them by sysctl or ioctl.

...in some very low level, system-specific interfaces it's revealed.
For other APIs that most ordinary applications use, such as
sendto/recvfrom/connect/accept/getsockname/getpeername this ugly trick
is hidden.

--
JINMEI, Tatuya