RFC 4607, "Source-Specific Multicast for IP", August 2006Source of RFC: ssm (rtg)
Errata ID: 905
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 18.104.22.168 through 22.214.171.124 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.]
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.