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 17:41:53 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

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

For correctness of multi-interface IPv6 nodes this is a rather important task,
because there may be overlap between link-local addresses used on separate
links, and the current IPv6 code is in no way ready to deal with that.

The way I see it, before any work can be done on this task, a crucial decision
has to be taken first. Each netif will have to be extended with an interface
index field that will serve as the scope ID of the interface; this is the easy
part. IPv6 addresses (struct ip6_addr) will similarly have to be extended with
a scope ID however, and this is where things are less clear. There appear to
be two options:

1. Extend "struct ip6_addr" with a separate field to store the scope ID. The
field itself needs to be only a u8_t, but due to structure alignment rules,
this will still increase the size of the IPv6 address structure from 16 to 20
bytes (and dual-stack ip_addr_t from 20 to 24 bytes).

2. Embed the scope ID into "unused" bits of link-local addresses. In this
case, the lower 8 bits of the first 32-bit word of link-local addresses would
contain the scope ID. For example, the internal representation of fe80::1 on
interface lo0 would be fe80:2::1, with 2 being the interface index of lo0.
This type of embedding is what the IPv6 implementation of the BSDs (WIDE/KAME)
does as well.

Compared to #1, the approach of #2 costs no extra memory, but it makes the
implementation somewhat more error-prone, as the scope ID has to be removed
whenever anything is put on the wire, and it is relatively easy to forget that
and and leak the scope ID.

With appropriate macro abstractions, it should be fairly easy to make support
for scope IDs a compile-time option, which may be part of the consideration
here. This would be mainly for single-netif configurations though, since for
RFC compliance, support for proper scoping is absolutely required.

What do people is the better of the two approaches? Does either option sound
unacceptable, even? Or did I forget something? All input appreciated!

    _______________________________________________________

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]