Hello Devs,

I'd like to discuss some different approaches to a simple setup for BLE and iwpan 802.15.4 nodes connected to a gateway via 6lowpan (in a star pattern).  No mesh involved.

On the gateway side, I'm running a NAT64 container which picks up traffic destined for the 64:ff9b::/96 network and translates it to IPv4 before sending it out.  On the return path it gets re-translated back from IPv4 to the 64:ff9b::/96 IP and sent back to the original node that sent the data.   Paired with that I'm also running a DNS64 container on the gateway which accepts DNS queries from the connected nodes (BLE and 802.15.4 6lowpan) and if an IPv4 address would normally be returned it translates it to the 64:ff9b::/96 prefix (DNS64).

Using this setup, each node *should* have basic access to the internet even on home networks where there is no IPv6 available.

On each Zephyr node,  we currently only have a link-local address configured.

Enter the complications:

If I ask Zephyr to send a packet to a 64:ff9b::/96-based address (via the gateway IP) it gets denied because link-local addresses are not "proper" according to RFCs and the function here:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/ip/net_if.c#L1689

Here are some of my proposed changes to solve this:

1. First solution was to setup RADVD on the gateway to present a "proper" IPv6 network to the connected nodes.  Here we encounter initial connection failures due to the RA packets not being received prior to the application choosing to communicate via the network.  Looks like @jukkar's L4 notifications would come in handy here if we can craft the right requirements for the "UP" and "DOWN" notifications.  Also, I think that RADVD is overkill in this scenario.  We are talking about a hand full of nodes on 1 subnet w/ 1 statically configured router IP.  It will never change and if the gateway goes down, the nodes would never be connected in the first place.

2. Second solution was to add a Kconfig option to subsys/net/ip/net_if.c which would change the behavior of is_proper_ipv6_address().  In effect saying "go ahead and use the link-local address" we know what we're doing.  I'm not sure how the networking maintainers feel about that as it does contradict RFC.  Seems like a one-off fix.

3. A third solution was to add Kconfig options to subsys/net/lib/config for NET_APP_MY_IPV6_ROUTER, NET_APP_MY_IPV6_PREFIX and NET_APP_MY_IPV6_PREFIX_LEN.  These would effectively configure the nodes at boot-time as if the related RA packets had been received (no lifetime expiration). These changes might allow us to modify all of our IPv6 samples so that multiple nodes can be running at the same time.

Question to @jukkar or other network maintainers: What's the preferred setup?  I know there is movement on this front but I'm not sure of the specifics.

- Mike

Hi Michael,

On Fri, 2018-08-17 at 12:15 -0700, Michael Scott wrote:

Hello Devs,

I'd like to discuss some different approaches to a simple setup for
BLE
and iwpan 802.15.4 nodes connected to a gateway via 6lowpan (in a
star
pattern). No mesh involved.

On the gateway side, I'm running a NAT64 container which picks up
traffic destined for the 64:ff9b::/96 network and translates it to
IPv4
before sending it out. On the return path it gets re-translated
back
from IPv4 to the 64:ff9b::/96 IP and sent back to the original node
that
sent the data. Paired with that I'm also running a DNS64 container
on
the gateway which accepts DNS queries from the connected nodes (BLE
and
802.15.4 6lowpan) and if an IPv4 address would normally be returned
it
translates it to the 64:ff9b::/96 prefix (DNS64).

Using this setup, each node *should* have basic access to the
internet
even on home networks where there is no IPv6 available.

On each Zephyr node, we currently only have a link-local address
configured.

Enter the complications:

If I ask Zephyr to send a packet to a 64:ff9b::/96-based address
(via
the gateway IP) it gets denied because link-local addresses are not
"proper" according to RFCs and the function here:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/i
p/net_if.c#L1689

Here are some of my proposed changes to solve this:

1. First solution was to setup RADVD on the gateway to present a
"proper" IPv6 network to the connected nodes. Here we encounter
initial
connection failures due to the RA packets not being received prior
to
the application choosing to communicate via the network. Looks like
@jukkar's L4 notifications would come in handy here if we can craft
the
right requirements for the "UP" and "DOWN" notifications. Also, I
think
that RADVD is overkill in this scenario. We are talking about a
hand
full of nodes on 1 subnet w/ 1 statically configured router IP. It
will
never change and if the gateway goes down, the nodes would never be
connected in the first place.

This would be most standard configuration but as you said, if the
network is very tiny it is kind of overkill to use radvd. But if you
are moving the device around, then this is definitely the best option
as then the prefix is set properly in different subnets automatically.

2. Second solution was to add a Kconfig option to
subsys/net/ip/net_if.c
which would change the behavior of is_proper_ipv6_address(). In
effect
saying "go ahead and use the link-local address" we know what we're
doing. I'm not sure how the networking maintainers feel about that
as
it does contradict RFC. Seems like a one-off fix.

This is a bit too hackish imho.

3. A third solution was to add Kconfig options to
subsys/net/lib/config
for NET_APP_MY_IPV6_ROUTER, NET_APP_MY_IPV6_PREFIX and
NET_APP_MY_IPV6_PREFIX_LEN. These would effectively configure the
nodes
at boot-time as if the related RA packets had been received (no
lifetime
expiration). These changes might allow us to modify all of our IPv6
samples so that multiple nodes can be running at the same time.

We have a lot of static configuration already so probably it would not
harm too much to add these too. IPv6 is suppose to be auto configured
so setting these at compile time would contradict this idea. Currently
the static IPv6 address configuration in Zephyr is meant for testing
purposes and setting also prefix and router statically would help
testing effort in this front. IMHO it does not make much sense to use
statically set IPv6 addresses in real networks.

In real life scenarios and devices, I would definitely prefer the
option 1. as then everything would work just fine in every network
setup and there would be no need re-compile if you want to use
different IPv6 configuration and subnet. This is how IPv6 is suppose to
work anyway.


So a summary of these imho would be:
* Option 1. is the best bet for real life devices
* Option 2. is no-go
* Option 3. we could add the static prefix and router info. This should
only be used for testing purposes with a big disclaimer about loosing
dynamic configuration of the device if done this way.

Question to @jukkar or other network maintainers: What's the
preferred
setup? I know there is movement on this front but I'm not sure of
the
specifics.

- Mike

Cheers,
Jukka