Subject: rfc4007 implementation question

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Dec 2017 11:38:17 +0100

Figure 1 of RFC4007 shows an example where a single link2 is
attached to two interfaces - interface2, interface3. This is
the one case we interface zones are different from link zones.

Are there any implementations that suport this model directly ?
Aka: Where a zone_id for the link scope would have no 1:1 equivalent
interface id (or name) ? 

The implementations i have seen to support this case  are all based on the 
creation of some virtual interface, then map the two underlying (physical)
interfaces into it, and then the interface id of that virtual interface
would map 1:1 to the link scope zone_id. And in result it seems
interface IDs are used interchangeably with link scope zone_ids...

Thanks
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Dec 2017 07:42:15 +1300

Apart from anything else, there seems to be no way to represent
the "link index" described in RFC4007 in the socket API, which
explicitly supports interface indexes. So even if a stack
internally separates the two concepts as described in RFC4007,
there seems to be no way to communicate this outside the stack.

Regards
   Brian

On 17/12/2017 23:38, Toerless Eckert wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 18 Dec 2017 11:24:43 -0800

At Mon, 18 Dec 2017 07:42:15 +1300,

> explicitly supports interface indexes. So even if a stack

What do you mean by this?  sockaddr_in6::sin6_scope_id has a generic
name, and, *in theory* we should be able to set it to an appropriate
zone ID for the address as defined in RFC4007.  Whether there's an
implementation that can do it is a totally different question, of
course.

> > Aka: Where a zone_id for the link scope would have no 1:1 equivalent

BSD variants try to implement the model quite hard.  For example, you
should be able to use a generalized utility to configure scope zone
IDs: https://github.com/kame/kame/blob/master/kame/kame/scope6config/scope6config.c
on FreeBSD (it's not part of the standard OS distribution so you'll
need to compile it manually.  I've just confirmed it built on a
FreeBSD 10.3R box).  You should be able to specify the same link ID
for two different interfaces.  That said, the kernel stack still
relies on a one-to-one mapping between links and interfaces, so I'm
afraid you'll have troubles if you actually configure it that way.

I suspect other implementations assume the one-to-one mapping more
broadly and naively.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Dec 2017 08:44:42 +1300

> implementation that can do it is a totally different question, of

Exactly. "The mapping of sin6_scope_id to an interface or
set of interfaces is left to implementation and future specifications
on the subject of scoped addresses." In contrast, ipi6_ifindex
is well defined as "send/recv interface index".

> for two different interfaces.

In the context of autonomic networking, where Toerless is working,
there is no "you" to configure this; it needs to be automatic. I
guess I could write some heuristic code to detect such a configuration.

> That said, the kernel stack still

I think that's correct. I hooked my Windows box up this way yesterday
and it promptly got two global IPv6 addresses and two link-locals,
assigned of course to two different interface indexes. And of course
received its own multicasts.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 19 Dec 2017 11:52:13 -0800

At Tue, 19 Dec 2017 08:44:42 +1300,

> there is no "you" to configure this; it needs to be automatic. I

Okay.  I actually wondered whether some automatic detection was

>>> Aka: Where a zone_id for the link scope would have no 1:1 equivalent

so I gave a reference to an implementation that at least supports the
model with manual configuration.

--
JINMEI, Tatuya