[RFC] ng_netif_hdr: add flags for multicast and broadcast by miri64 · Pull Request #2600 · RIOT-OS/RIOT

miri64 · 2015-03-14T13:21:36Z

~~A first idea in the direction of IPv6 multicast address resolution.~~

The problem I faced with the current IPv6 implementation is that Ethernet defines it's multicast addresses for IPv6 as follows: 33:33:xx:xx:xx:xx, where the xxs represent the last 4 byte of the IPv6 address (source: http://tools.ietf.org/html/rfc7042#section-2.3.1). This is an attempt to unify this with our current scheme of just assuming that the broadcast address will be ff:ff:….

Devices that don't support multicast (but have either EUI-48 or EUI-64 addressing) are requested to check the individual/group-bit (the 8th MSB in the address for either case), and transform it into there individual broadcast address if it is set to group.

~~As I've said: this is only a first idea and a starting point for discussion. I'm not that happy with this solution either.~~

[edit] I changed this PR completely in the wake of #2600 (comment):

I've got an idea: instead of assuming and stating how a general link-layer broadcast/multicast-address for link-layers should look like, we just let the link-layer decide this stuff completely:
We introduce a flag field to the general link-layer header ng_netif_hdr_t with a bit for either broadcast and multicast. If the network layer encounters any address format different then unicast, it sets the destination length for ng_netif_hdr_t to 0 and sets the flags accordingly. The driver then can decides itself how to handle that: IEEE 802.15.4 will just set it's preferred broadcast address on either broadcast or multicast == 1, and Ethernet can decide upon encountering these bits how to translate the address based on the next header.

I also adapted the already existing implementations for it.

People interested into discussing this might be @BytesGalore, @cgundogan, @emmanuelsearch, @haukepetersen, @Lotterleben, @PeterKietzmann, @phiros, and @OlegHahm.

miri64 · 2015-03-14T13:50:01Z

sys/net/network_layer/ng_ipv6/nc/ng_ipv6_nc.c

I could not find anything on EUI-64 translation, so I assumed it to be the same as the EUI-48 scheme with the ff:fe insertion.

miri64 · 2015-03-24T18:24:30Z

Any opinions on this? If not lets merge it ASAP!

miri64 · 2015-03-25T14:21:01Z

no... my question relates to the lines 210..215, where it is specified for mac-64?

nowhere really, it is based on a combination of https://standards.ieee.org/develop/regauth/tut/eui48.pdf and http://tools.ietf.org/html/rfc2464. That's where my own headaches with this PR start (though I'm also not sure if we can generalize for size == 6 this way also).

jfischer-no · 2015-03-26T09:08:41Z

@authmillenon It depends very much on phy + mac. I think "size=6" is ok, maybe you can add a comment that it applies only to ethernet (https://tools.ietf.org/html/rfc2464#section-7). I have nothing found for "size=8" (802.15.4 uses 16 bits for multicast), would be error output more appropriate for the case 8: (return -EINVAL; or rm L211..217)?

miri64 · 2015-03-26T09:37:28Z

It depends very much on phy + mac. I think "size=6" is ok, maybe you can add a comment that it applies only to ethernet (https://tools.ietf.org/html/rfc2464#section-7)

Yes and no: This is why I added the following to this PRs description:

Devices that don't support multicast (but have either EUI-48 or EUI-64 addressing) are requested to check the individual/group-bit (the 8th MSB in the address for either case), and transform it into there individual broadcast address if it is set to group.

This is also why I thought the translation for 8-byte addresses might be a good idea too.

I have nothing found for "size=8" (802.15.4 uses 16 bits for multicast), would be error output more appropriate for the case 8: (return -EINVAL; or rm L211..217)?

Then we wouldn't be able to send broadcast with IEEE 802.15.4 long addresses. I would rather set all bytes 0xff then

jfischer-no · 2015-03-26T10:13:01Z

I have nothing found for "size=8" (802.15.4 uses 16 bits for multicast), would be error output more appropriate for the case 8: (return -EINVAL; or rm L211..217)?

Then we wouldn't be able to send broadcast with IEEE 802.15.4 long addresses. I would rather set all bytes 0xff then

ok, make sense

haukepetersen · 2015-03-26T10:44:47Z

I am not a 100% convinced of the PR, (yet?). I don't like the idea on making assumptions on the underlying link layer based on the l2 address length. What happens, if I use a proprietary linke layer with 2 byte addresses that uses 0x0000 as broadcast address?

As I see it, there should be one fixed broadcast address registered for each interface. Then once an interface driver wants to send a package and detect it's broadcast address, it can either just use it (e.g. 802.15.4 -> 0xffff), or it can update re-fine it (e.g. Ethernet can parse some of the IP address and add that to 0xffff00000000).

I think this would be the more versatile approach.

miri64 · 2015-03-26T11:35:15Z

But e.g. Ethernet supports both multicast and broadcast (the later we need if we ever implement IPv4)… The Ethernet address you propose is not an Ethernet address purposeful for IPv6 multicast => they are defined as 0x333300000000.

miri64 · 2015-03-26T11:58:04Z

I've got an idea: instead of assuming and stating how a general link-layer broadcast/multicast-address for link-layers should look like, we just let the link-layer decide this stuff completely:
We introduce a flag field to the general link-layer header ng_netif_hdr_t with a bit for either broadcast and multicast. If the network layer encounters any address format different then unicast, it sets the destination length for ng_netif_hdr_t to 0 and sets the flags accordingly. The driver then can decides itself how to handle that: IEEE 802.15.4 will just set it's preferred broadcast address on either broadcast or multicast == 1, and Ethernet can decide upon encountering these bits how to translate the address based on the next header.

jfischer-no · 2015-03-26T12:17:35Z

I think this is a good idea

miri64 · 2015-03-27T21:39:51Z

Hijacked the PR for this ;-)

miri64 · 2015-03-29T17:02:09Z

Rebased to current master

miri64 · 2015-04-03T14:05:58Z

Rebased to current master

miri64 · 2015-04-13T23:02:49Z

Though we might discuss this a little more, can we merge it nevertheless soonish?

OlegHahm · 2015-04-14T07:30:52Z

ACK

[RFC] ng_netif_hdr: add flags for multicast and broadcast

haukepetersen · 2015-04-14T09:48:36Z

dammit, too late. The changes to the xbee driver are not completely fine... Broadcast needs another option and the position of the is_bcast function in the file is completely off... I guess I'll just open a new PR for this..

miri64 · 2015-04-22T19:46:42Z

@haukepetersen did you do that?

miri64 assigned haukepetersen Mar 14, 2015

miri64 added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR NSTF labels Mar 14, 2015

miri64 reviewed Mar 14, 2015
View reviewed changes

miri64 mentioned this pull request Mar 15, 2015

ng_ipv6: initial import #2454

Merged

OlegHahm assigned emmanuelsearch and unassigned haukepetersen Mar 18, 2015

miri64 changed the title ~~[RFC] ng_ipv6_nc: add multicast address translation~~ [RFC] ng_netif_hdr: add flags for multicast and broadcast Mar 27, 2015

miri64 force-pushed the ipv6_nc/feat/mc-translation branch from c790ee9 to ac5dd70 Compare March 27, 2015 21:38

miri64 force-pushed the ipv6_nc/feat/mc-translation branch from ac5dd70 to 760fb21 Compare March 29, 2015 17:02

miri64 mentioned this pull request Mar 29, 2015

ng_tapnet: initial import of a pure Ethernet device for native #2558

Closed

1 task

Lotterleben force-pushed the master branch from 1d9f189 to d4e068b Compare March 31, 2015 09:52

OlegHahm force-pushed the master branch 3 times, most recently from 9f184dd to 45554bf Compare March 31, 2015 13:01

miri64 added 2 commits April 3, 2015 16:05

netif_hdr: add flags for broadcast and multicast

d382fea

drivers.xbee: adapt driver for bc/mc flags

26e72b5

shell: adapt netif shell commands for bc flag

fa2ab8b

miri64 force-pushed the ipv6_nc/feat/mc-translation branch from 760fb21 to fa2ab8b Compare April 3, 2015 14:05

miri64 mentioned this pull request Apr 9, 2015

sys: net: add netdev device driver using dev_eth low-level ethernet driver API #2770

Closed

miri64 assigned OlegHahm and unassigned emmanuelsearch Apr 13, 2015

miri64 added a commit that referenced this pull request Apr 14, 2015

Merge pull request #2600 from authmillenon/ipv6_nc/feat/mc-translation

67602bb

[RFC] ng_netif_hdr: add flags for multicast and broadcast

miri64 merged commit 67602bb into RIOT-OS:master Apr 14, 2015

miri64 deleted the ipv6_nc/feat/mc-translation branch April 14, 2015 08:08

OlegHahm modified the milestone: Release 2015.06 Apr 29, 2015

Conversation

miri64 commented Mar 14, 2015

Uh oh!

miri64 Mar 14, 2015

Choose a reason for hiding this comment

Uh oh!

miri64 commented Mar 24, 2015

Uh oh!

miri64 commented Mar 25, 2015

Uh oh!

jfischer-no commented Mar 26, 2015

Uh oh!

miri64 commented Mar 26, 2015

Uh oh!

jfischer-no commented Mar 26, 2015

Uh oh!

haukepetersen commented Mar 26, 2015

Uh oh!

miri64 commented Mar 26, 2015

Uh oh!

miri64 commented Mar 26, 2015

Uh oh!

jfischer-no commented Mar 26, 2015

Uh oh!

miri64 commented Mar 27, 2015

Uh oh!

miri64 commented Mar 29, 2015

Uh oh!

miri64 commented Apr 3, 2015

Uh oh!

miri64 commented Apr 13, 2015

Uh oh!

OlegHahm commented Apr 14, 2015

Uh oh!

haukepetersen commented Apr 14, 2015

Uh oh!

miri64 commented Apr 22, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants