Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

IPv6 multicast addresses: Is the Group ID field effectively 112 bits or 32 bits?

Tags:

ipv6

multicast

I'm trying to understand the rules for choosing an IPv6 multicast address Group ID, and the RFC seems somewhat inconsistent. For example, in RFC 2373 section 2.7 this diagram is shown:

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

... but then in section 2.7.2 it shows this:

|   8    |  4 |  4 |          80 bits          |     32 bits     |
+------ -+----+----+---------------------------+-----------------+
|11111111|flgs|scop|   reserved must be zero   |    group ID     |
+--------+----+----+---------------------------+-----------------+

So my question is, are the upper 80 bits of the Group ID field usable or not? If they are usable, is it only under certain circumstances (e.g. when using non-Ethernet networking technology?) What problems should I expect to experience if I set these bits when multicasting over an Ethernet LAN?

like image 598
Jeremy Friesner Avatar asked Nov 06 '22 18:11

Jeremy Friesner


1 Answers

According to Stevens UNP, Volume 1, Third edition, there are two formats defined for IPv6 multicast addresses, the flags field differentiates between them (flags=00PT):

  • if P = 0 then it's normal multicast address. 80 bits are all zero, the T flag tells between well-known and transient addresses,
  • if P = 1 then this is a unicast-based address, 80 bits contain length and value of the unicast prefix.

The book mentions RFC 3306 for the latter.

RFC 3307 [Haberman 2002] describes the allocation mechanism for the low-order 32 bits of an IPv6 group address (the group ID), independent of the setting of the P flag.
like image 136
Nikolai Fetissov Avatar answered Nov 30 '22 02:11

Nikolai Fetissov