[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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
 iesg@xxxxxxxx or ietf@xxxxxxxx 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
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------