lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #13106] Add IPv6 scopes


From: David van Moolenbroek
Subject: [lwip-devel] [task #13106] Add IPv6 scopes
Date: Wed, 18 Jan 2017 23:42:56 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

Follow-up Comment #14, task #13106 (project lwip):

Comment #13:

Sounds good! Whatever I would come up with (as always, I can never promise
anything) will be limited to the core layers, so any help with the
higher-layer stuff would be very welcome.

> scope ID (which is the same as interface index?)

The short answer: practically yes. The long answer is definitely worth
discussing here as well though. The theory on scope IDs ("zone indices") is
fairly elaborate - see RFC 4007 Sec. 6. In effect, for each scope (0..15), a
zone maps to a set of zero or more interfaces, mostly as specified through
user configuration. I think that for a lightweight IPv6 implementation, it is
acceptable to follow the default model presented there, which is that each
interface is assigned its own interface and link zone. The result is that the
zone index for interface-local and link-local scopes can effectively be
considered the same as the interface index, and that is then also the scope
ID. For unicast, this is enough to cover link-local, ULA, and global addresses
(site-local addresses have been deprecated for a while now). Multicast is a
bit more involved, in that there are also larger-scoped multicast targets (eg
admin-local) that would require an associated zone to make sense. However, the
default model would simply disregard the scope ID there, and send packets to
whatever is the default interface. Interface-local and link-local multicast,
which is what's actually used internally already, will still work as expected,
though.

Of course it would be nice to use the default model and then provide hooks to
implement more elaborate schemes, but I'm afraid that things would get
complicated rather quickly that way, and it is not really clear to me whether
that kind of flexibility really buys much in practice. For example, I'm pretty
sure that having multiple interfaces on the same link has other, bigger
issues..

(BTW, thanks for all the input so far everyone!)

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?13106>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]