IPv6-over-IEEE802.15.4 Multicast scope

Question

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

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...

Answer 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.