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

From: Margaret Wasserman <[email-masked]>
Date: Sun, 5 Dec 2004 10:35:25 -0500

Hi Pekka,

There is a new version of this document available at:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt

Could you check if it addresses your substantial concerns?

Margaret

At 12:15 AM +0200 11/13/04, Pekka Savola wrote:
>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
--------------------------------------------------------------------