RFC 4607, "Source-Specific Multicast for IP", August 2006

Errata ID: 905
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Rejected by: Adrian Farrel
Date Rejected: 2013-09-18

problems with IPv6 SSM address range, and with related text

The 4th paragraph of Section 1, on page 3, RFC 4607 says:

   Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
   reserved in [IPv6-MALLOC] for allocation by IANA.  Addresses in the
   range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic
   allocation by a host, as described in [IPv6-MALLOC].  Addresses in
   the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6
   SSM addresses.  ([IPv6-MALLOC] indicates that FF3x::0000:0001 to
   FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM]
   mandates that  P=1 and T=1, hence their designation as invalid.)  ...

I see a lot of problems in that reasoning.

a) The most obvious issue first:
As far as I can see, RFC 3307 [IPv6-MALLOC] only requires for
"Permanent IPv6 Multicast Addresses":

   Multicast addresses assigned by IANA MUST have the T bit set to 0 and
   the P bit set to 0.

(RFC 3307, Section 4, top of page 4)

This restriction is not mentioned for other cases.

Since the '3' nibbles in "FF3x::0000:0000 through FF3x::3FFF:FFFF"
just mean P=1 and T=1 (cf. RFC 3306 [IPv6-UBM], Section 4, pp. 2/3),
IMHO the phrase from the above quotation,
                  [IPv6-MALLOC] indicates that FF3x::0000:0001 to
   FF3x::3FFF:FFFF must set P=0 and T=0,
is neither logical nor conclusive.  Hence the final conclusion,
                   "hence their designation as invalid."
does not hold.

Perhaps it would have been much more simple and clear to just
declare the range FF3x::0000:0000 through FF3x::3FFF:FFFF as
reserved or invalid -- without giving any reason.

b) Delving into further details of RFC 3307, one can find that
Section 4.2 reserves the range 0x40000000 to 0x7FFFFFFF for
"Permanent IPv6 Multicast Group Identifiers" with the intent that
assignments in that range hold
   "regardless of the upper 96 bits of the multicast address".

On the other hand, the current IPv6 Addressing Architecture document
clearly states that
   T=0 means  "well known" / "permanently-assiged" / IANA allocated,
while
   T=1 means  "transient" / "dynamically allocated".
Under this rule, the above "regardless" in RFC 3307 is partially
invalid, because upper 96 bits containing T=1 are not allowed for
IANA allocated MC addresses.

[Note: Perhaps, this statement is also inappropriate, because
 RFC 3307 initially states (in Section 4, at the bottom of page 3):
   ....  The following guidelines assume that the prefix of the
   multicast address has been initialized according to [ADDRARCH] or
   [UNIMCAST].
 and both specifications quoted restrict or fix the values of some
 of these upper 96 bits ...]

Hence, there is a subtle conflict between RFC 3307 and RFC 4291 !

c) Taking the ADDRARCH and RFC 3307 rules together, it is clear
that the first sentence of the RFC 4607 quotation above,
   Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
   reserved in [IPv6-MALLOC] for allocation by IANA.
does not hold, as T=1 in these addresses !

Later on, in Section 9 (IANA Cosiderations, page 15), RFC 4607 says:

   IANA allocates IPv4 addresses in the range 232.0.0.1 through
   232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to
   FF3x::7FFF:FFFF.  [...]

The latter clearly contradicts RFC 4291 for this reason (T=1).

Therefore, this range might better have been reserved/forbidden,
or excluded from the IPv6 SSM address range.


Taking all together:
There are serious conflicts between RFC 4291, RFC 3307, and RFC 4607.

Sadly enough, it seems that it was not a good idea to assign
FF3x::/32 for IPv6 SSM.

I'm sure that RFC 4291 should NOT be called in question.

Perhaps, it would have been better to restrict the IPv6 SSM range to
FF3x::8000:0000/31, and *not* provide for any subrange available
for specific IANA assignments.
Then, should there really arise the serious need for IANA allocated,
specific IPv6 SSM addresses, another (small) range (with T=0 and P=0)
could be assigned additionally for this purpose.

[Note 1: Thus, this address range would indeed fall under the regime
 of Section 4.1 of RFC 3307, "Permanent IPv6 Multicast Addresses".
 Note 2: T=0 + P=1 would necessitate a formal update to RFC 3306 that
 does not allow this combination, and maybe to RFC 3956 as well.]

Notes:

from pending
--VERIFIER NOTES--
This Errata Report is rejected because it constitutes a significant technical change to the specification. This rejection makes no judgement about whether the issues raised are right or wrong.

In considering the issues raised in this Errata Report readers are also invited to consider draft-ietf-6man-multicast-addr-arch-update that may be related work.

Report New Errata