Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Nov 2004 00:15:10 +0200 (EET)

On Sat, 30 Oct 2004, The IESG wrote:
> The IESG has received a request from the IP Version 6 Working Group WG to
> consider the following document:
>
> - 'Link Scoped IPv6 Multicast Addresses '
>   <draft-ietf-ipv6-link-scoped-mcast-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2004-11-13.

The document is in an awful shape.  It clearly hasn't seen sufficient 
review.  I think thew applicability is very questionable as well, but 
it seems some think this is sufficiently useful...

semi-substantial
----------------

==> this doc should probably say "This memo updates RFC 3306." at the end,
because you're modifying the format specified there (an old MUST no longer
applies).

     flgs MUST be "0011".  (The first two bits have been yet undefined,
      sent as zero and ignored on receipt) flgs MUST use the same flag
      defined in section 4 of [RFC 3306].

==> the sentence no longer holds true, due to embedded-RP.  I'd suggest just
removing the sentence, because it doesn't seeem to be relevant to the 
main thrust of the document.

      scop MUST be <= 2. It is preferred to use this method for the
      link-local scope rather than unicast-prefix-based IPv6 multicast
      addresses [RFC 3306].

==> The sentence here is redundant.  The users can use whichever they wish
and deem appropriate.

      LSM (Link Scoped Multicast) field MUST be "1111 1111" which maps to
      the plen field in [RFC 3306], whereas the plen field in [RFC 3306]
      MUST NOT be greater than 64.

      That is, flgs, scop, and LSM fields are used to identify whether an
      address is a multicast address as specified in this document.

==> this seems an inappropriately complex and confusing way to specify this,
renaming plen field to "LSM" and giving it static value of 255.  Just
specify that plen = 255, you don't even have to have the extra diagram 
and you're done!

      The lifetime of link scoped multicast addresses has no dependency
      on the Valid Lifetime field in the Prefix Information option,
      corresponding to the unicast address being used, contained in the
      Router Advertisement message [RFC 2461].

==> does this need to be said?  This is rather obvious.  If you want to say
something, I'd rather say that there is no lifetime because link-local
addresses have no lifetime!

5. Considerations

      Since multicast addresses are created from the unique IID, their
      useful lifetime is linked to the period during which the IID is
      known to be unique.  Thus, it is possible to conflict between IIDs,
      due to a new node joining the network that uses the same IID.  The
      document does not consider this case at this phase.  It is another
      challenging issue and out of scope of this document.

==> this is a bit inaccurate, "due to a new node joining the network 
that uses the same IID" -- this node would fail DAD and be unable to 
use the link-local address to generate the link-scoped address!  On 
the other hand, the cases where DAD fails, this also fails -- like the 
node with same MAC address as with someone on the link powered on and 
only after that plugged on the link.

      The link scoped multicast address format supports source-specific
      multicast addresses by the same method, as defined by [RFC 3306].

==> this is tehnically conflicting with the spec because plen is 255, and
not 0 as required by SSM.  Just remove this.

==> The title should be renamed in any case to something better than
"Considerations".

6. Security Considerations

      [RFC 3041] describes the privacy extension to IPv6 stateless
      address autoconfiguration for an IID.  The secure IID, generated by
      [RFC 3041], can be used for consisting of a link scoped multicast
      address since the uniqueness is verified by the DAD procedure as
      part of the secure auto-configuration process.

==> Here Be Dragons!  This is technically wrong: RFC3041 addresses are
generated based on the received prefix information options, so there will
never be link-local scope RFC3041 addresses to generate the multicast
addresses from -- and even if there were, you'd have to consider their
lifetime here.

==> Now that this bogus text is removed, Security Considerations section is
empty.  I guess something needs to be written there.  I guess you could say
that the uniqueness of the multicast addresses is guaranteed by the DAD
process.

editorial
---------

      of a node, an IID is uniquely determined.  After then, each node

==> "After then" should be replaced with something like "After that" or just
simply "Then".  Fix in multiple places.

     conflicts.  Basically, it is preferred to use this method for the
      link-local scope rather than unicast-prefix-based IPv6 multicast
      addresses [RFC 3306].

==> no references in the abstract, just remove '[RFC 3306]'.

Also, nodes which are
      supplied multicast services, easily consist of multicast addresses
      of multicast servers using NDP (address resolution) and well-known
      group IDs.

==> "supplied" -> "supplying" ?  Further, I'm having trouble understanding
what this sentence tries to mean..

     Group ID is generated to indicate multicast application and is used
      to guarantee its uniqueness only in the host.  It may also be set
      on the basis of the guidelines outlined in [RFC 3307].

==> remove "also".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------