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

[David van Moolenbroek]

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

Alright, here is my patch for implementing support for IPv6 scopes. It is
fairly big, but I hope that the commit message and code comments explain well
enough what's going on. As such I'd like to ask you to look at the patch for a
detailed description, so that I can limit this post to the design decisions I
took based on the discussion here (and a bit about testing).

Regarding comment #1 and others: as it turns out, adding a separate zone field
is an incredible lot easier and cleaner, so as long as the added bit of memory
is not an issue, this is *by far* the better option. Therefore, that is what
this patch does. The most significant advantage is that there are essentially
no issues with backward compatibility this way, as long as applications either
use standard lwIP functionality or otherwise at least zero out the ip6_addr_t
structures they generate. Overall, as far as I can tell, embedding would have
required a lot more, quite a bit more complex, and as such harder to maintain,
code in many places.

Regarding comment #4: for simplicity's sake I have had to make the decision
that locally assigned scoped addresses do always have a zone ID. I still agree
that with the embedding case this would have been bad, but I'd argue that with
an explicit zone field, it is now a good thing: it allows an application to
get one of the available addresses from a netif, and use that in (eg) a bind()
call directly, as such preserving zone information. Applications that are not
scope-aware will only look at the address part, which is as it was before, and
ignore the zone part.

Regarding comments #8, #9: the current patch does make the whole scopes
support optional with a LWIP_IPV6_SCOPES configuration option, at least for
now. My reasoning for this is as follows: 1) given that this whole thing is in
effect an addition to the code, it is not so difficult to isolate the new
parts; there are very few places where there is code only for the
LWIP_IPV6_SCOPES==0 case, the rest is just stubbing away of new macros (see
the new ip6_zones.h); 2) for now, it gives people the ability to go back to
the old situation if this change breaks something, which is particularly
relevant because I have not been able to test more than the core API so far;
the configuration option can always be phased out later when all other code
(within lwIP and outside) is "ready"; 3) alternatively, for single-netif
configurations, one could argue that it's still beneficial to remove
everything at compile time that is not needed for that case, in which case
LWIP_IPV6_SCOPES could be defined to (!LWIP_SINGLE_NETIF) later or so.

Regarding comment #14: in contrast to what I expected, as it turns out, it is
incredibly easy, and in fact "natural", to capture the entire IPv6 scoping
policy in just three macros, and so that is what this patch does. It provides
the ability for the application to disable those three macros' definitions
(with IPV6_CUSTOM_SCOPES) and instead supply its own. There is only one
exception in the code based on whether such custom scopes are set or not, and
that is merely a performance optimization for the default policy. I still
don't know if this support will be useful to anyone in practice, and the
support can be easily removed again as well, but given that it was this simple
(and thus also easy to maintain as an option), I felt there was no reason to
leave it out.

So does the resulting system work? As backstory, before I started on this, my
lwIP-based sockets implementation already supported IPv6 address scopes, using
workarounds such as explicit PCB binding and source/interface preselection.
Due to the lack of scope support in lwIP itself, this would work correctly
only if all link-local addresses were globally unique, but it was still
functional, and I had already written a few tests for this form of scopes
support.

With this patch, but with the zone field always set to zero when generating
addresses, my implementation continued to pass all its tests, including those
related to address scopes (which is good, but not yet very telling). After
that, I removed all the workarounds but kept zone IDs set to zero; everything
still passed except tests related to address scopes (as expected, but still
showing that e.g. no bad-scope assertions were triggered). Finally, I have
changed my implementation to properly set zone IDs and fully work with the new
implementation here, and now all my tests pass again. In summary, the core API
part of this change has seen at least reasonable testing so far.

Moreover, I have done a few specific tests; let me describe the most extreme
one. On my lwIP-based system I can now assign the same link-local address
(fe80::1) to two different interfaces, and then have two additional nodes
(running NetBSD as it happens), each on a separate link attached to one of
those two interfaces, with both those nodes assigned the same, second
link-local address (fe80::2). With this setup, from the lwIP-based system I
can ping (RAW) and make full (TCP) connections to each of the other two nodes,
picking one or the other based entirely by providing a zone ID from userland.
In addition, I have confirmed that IPv6 reassembly of (UDP) packets with
link-local addresses works as expected in this setup, including reassembly
timeouts going to the right link. Obviously none of this would have worked
before.

There are still several things left to test, though. I have added very basic
sin6_scope_id support to the lwIP sockets API in this patch, but I have not
even been able to test compilation of that change. In theory however, that
should be all that is needed to support address scopes in the sockets layer!
As for 6lowpan, I have been able to compile but not test my changes there, and
so those could use some scrutiny in particular. Overall, in terms of the lwIP
code repository that should be all I think, but the contrib stuff may be
another story of course..

The 0002 patch here is a separate TCP-specific mini-optimization that is now
easy to make after changes needed for the scopes support anyway.

As an aside, I have a separate patch that extends the ip6addr_aton/ntoa
routines to accept and produce "%if0" type suffixes. Technically this is not
what such functions do, which is why I did not include that extension here. It
may still be convenient for many platforms, though? I would be happy to add
this patch as well, possibly making its functionality optional - please let me
know.

(file #39572, file #39573)
    _______________________________________________________

Additional Item Attachment:

File name: 0001-Add-support-for-IPv6-address-scopes.patch Size:96 KB
File name: 0002-tcp-eliminate-some-redundant-route-lookups.patch Size:3 KB


    _______________________________________________________

Reply to this item at:

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

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