0

An IPv6 Multicast address is defined as

|   8    |  4 |  4 |              112 bits               |
+--------+----+----+-------------------------------------+
|11111111|flgs|scop|              group ID               |
+--------+----+----+-------------------------------------+

Being that we don't use dynamically assigned addresses, nor use rendevouz point or prefix based multicast, we could say we have this addresses according to scope:

FF01::/16 - Interface-Local scope
FF02::/16 - Link-Local scope
FF03::/16 - Realm-Local scope
FF04::/16 - Admin-Local scope
FF05::/16 - Site-Local scope
FF08::/16 - Organization-Local scope
FF0E::/16 - Global scope

Lets assume a mesh network with IP-over-IEEE802.15.4 like this:

  • Each Node has, at least, 2 processes requiring network capabilities
  • All nodes belong to the Group 1 visual helper

Using IPv6 multicast, we could have this situations:

1 - FF01::1 
   - process_1 send a message to FF01::1
   - process_2 receives message from process_1
   - process_3 receives message from process_1
2a - FF02::1
   - AAAA::4 send a message to FF02::1
   - AAAA::2 receives message from AAAA::4
   - AAAA::5 receives message from AAAA::4
2b - FF02::1
   - AAAA::3 send a message to FF02::1
   - AAAA::2 receives message from AAAA::3
   - BBBB::3 ignore message from AAAA::3 (different PAN_ID)
3 - FF03::1 (according to RFC7346, scope 3 in a ipv6-over-ieee802.15.4 include all nodes with the same PAN ID)
   - AAAA::2 send a message to FF03::1
   - AAAA::3 to AAAA::7 receives message from AAAA::2
   - BBBB::3 ignore message from AAAA::2 (different PAN_ID)
4 - FF05::1
   - AAAA::1 send a message to FF05::1
   - AAAA::2 to AAAA::7 receives message from AAAA::1
   - BBBB::1 to BBBB::7 receives message from AAAA::1
5 - FF08::1
   - AAAA::1 send a message to FF08::1
   - AAAA::2 to AAAA::7 receives message from AAAA::1
   - BBBB::1 to BBBB::7 receives message from AAAA::1
   - CCCC::1 to CCCC::7 receives message from AAAA::1
   - DDDD::1 to DDDD::7 receives message from AAAA::1

So here come the doubts (most come because of the non-wire-limited side of things):

0 - Are all the examples correct?

1 - What is the difference between sending something to FF01::1 and ::1? Can I direct a loopback message (::1) to a single process? Or does it use all the interfaces available while FF01::1 only uses one interface? Should this matter for internal processes that supposedly have access to all the interfaces?

2 - In a IEEE802.15.4 network can we assume a FF02::1 acts like a beacon message? All the nodes in the neighborhood can receive but won't repeat?

3 - I'd assume the equivalent of a wired-network FF03::1 would be everything connected under the same router? So every node would repeat the message for every interface available, while the router would act as a border patrol to keep the message on the right realm? so in this case, since the PAN_ID is defined by the borderRouter, we use the PAN_ID as the message filter in every node (every node can be in the network border, i.e. see nodes on different realms)

4 - Assuming we are the Organization, can we assume a city as a site? So a message sent to FF05::1 on a node belonging to city 1 would propagate through all the nodes in city 1? Since there's no wired connection, and it is possible for a node in one site to be seen by a node on another site, when receiving a message to FF05::1, the node must know what site it belongs to, and what site the message originated from. How is this different from having a group 2 for every node in city 1 and group 3 for city 2 and then sending a message to FF08::2 or FF08::3?

5 - The same as 5 for FF04::1. Is it right to assume a FF04::1 scope include a group of nodes that can belong to more than one PAN_ID? Ex. AAAA::2, AAAA::3 and BBBB::2. How is this different from using groups and using FF08::group for every case?

6(Last) - In a mesh network there's no notion of "nodes under a given gateway" since all nodes can see every node in the neigbourhood, so for FF01::1 to FF03::1, transmissions can be filtered by the device easily, by not repeating the message or by PAN_ID, but for addresses above FF04::1, should the device know what administration(s), site(s) and organization(s) he belongs to? Should we use FF08::/16 for every multicast message and use groups to define pseudo-administrations/sites/organizations?

Sorry for the long post, know this is a lot, but i've been searching for this and can't find anything that solve this mesh related doubts. Nor if this is the way to use IPv6 over a mesh network...

6
  • Why can't you just use unicast? Esssentially, using multicast will result in a very inefficient network as each frame is sent over every single link, which is especially bad for a wireless network with its limited bandwidth.
    – Zac67
    Jul 19, 2022 at 14:35
  • We've been using only unicast, however, we're getting to a point where one node needs to send a message to several nodes, and it's not possible to have all that information in the node. (We're using small devices) and having the message go all the way to the gateway and back will take too long Jul 21, 2022 at 10:59
  • I see - you're primarily using unicast and optionally multicast, as it's intended. From your question I had the impression you're trying to use multicast throughout to get around the forwarding decisions. All right!
    – Zac67
    Jul 21, 2022 at 11:45
  • Unless you plan to register your protocols with IANA, as per RFC 4291 you need to use the organization-local scope, ie. ff08::/8.
    – Zac67
    Jul 21, 2022 at 11:58
  • Very much depends on how your forwarding between different PANs and cities works which you haven't detailed. If forwarding is on L2, multicast distribution happens on the MAC layer of WPAN only and IPv6 specifics play a minor role. If forwarding is on L3 you need to implement PIM on the interconnecting nodes (preferably in sparse mode).
    – Zac67
    Jul 22, 2022 at 6:50

1 Answer 1

1

First, understand that multicast is not routed the same way unicast is routed. Multicast routing is very different than unicast routing (multicast uses MLS and a multicast routing protocol such as PIM). Unicast routing is deterministic because it has a single destination, and the routing sends the packet directly toward the destination. Multicast routing only sends packets toward hosts that have requested to join the multicast group; multicast routing is about not sending packets to places where hosts have not joined the multicast group.

Also, only Node-Local and Link-Local scopes use the ff0X::1 address as the All Nodes Address. The Realm-Local scope needs more definition in an RFC, and it will be defined by a larger scope, so it is not really useful right now.

0 - Are all the examples correct?

That is impossible to tell without a good network description or diagram for the examples, but most have an incorrect understanding of the All Nodes Address that is only valid for scopes 1 and 2 (see the IPv6 Multicast Address Space Registry and associated RFCs). The image you have provided does not match the examples.

1 - What is the difference between sending something to FF01::1 and ::1?

Obviously, ff01::1 is a multicast address (can only use UDP or other connectionless protocol), while ::1 is a unicast address (can use TCP, UDP, or any transport protocol). Only a process that has joined the multicast group on the transport protocol used (default is only IPv6, itself) would receive the multicast packet, and a process must use the ::1 unicast address, transport protocol (including any port if the transport protocol uses ports).

For your other questions, you incorrectly assume the ff0X::1 address is the All Nodes Address.

Following the 16-bit ffXX: multicast identifier, flags, and scopes, the next eight bits must currently be 0. Either the eight bits are Reserved, or four bits are flags that must be 0 and the next four bits are Reserved.

3
  • So by my understanding, IPv6 Multicast works somewhat like MQTT? Where the Source sends the packets to a determined router, and every node that needs to receive that group packets must then register to said router? But in a mesh network, every node can be a possible router as well as a host. There's no "downward path" from a source to a host... Jul 22, 2022 at 6:38
  • Also, edited the questions so the example nodes all have the correct address from the diagram. Jul 22, 2022 at 7:06
  • Layer-3 (IP) multicast is delivered in the same layer-3 network as it is sourced to the nodes which have joined the group. To forward multicast to a different network requires a multicast router.
    – Ron Maupin
    Jul 22, 2022 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.