Subject: RFC 4607

From: Alfred Hönes <[email-masked]>
Date: Wed, 8 Nov 2006 23:53:31 +0100 (MEZ)

Hello,
after studying the recently published RFC 4607 (SSM for IP)
authored by you, I would like to submit a few comments,
pointing out a few issues I found with the RFC text -- the
second of which is considered serious.

(1)  erratum: outdated Reference

Unfortunately, Section 1 (first paragraph) and Section 11
of RFC 4607 refer to the previous IPv6 Address Architecture
document, RFC 3513, that has been superseded by RFC 4291,
published in February.
This is done using the Ref. tag, '[RFC3513]'.
It would have been much better if this would have been
updated to [RFC4291], and the appropriate rfc-ref entry
used in Section 16, near the bottom of page 16.

(2)  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.]

If I have not misunderstood something, or overlooked something
important, there really is a serious problem.
Please comment.

(3)  erratum: typo

Finally, there's a small typo in Section 7.5 of RFC 4607, on page 14.
In the second paragraph of the section,

                    ... applied to all source address ...
should say:
                    ... applied to all source addresses ...

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+