Subject: AD Review comments on draft-ietf-ipv6-link-scoped-mcast-05.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 10 Oct 2004 13:40:31 -0400

Hi All,

Just FYI --

I sent the attached AD review comments to the WG chairs and the 
authors of draft-ietf-ipv6-link-scoped-mcast-05.txt on October 3rd. 
I usually try to copy the WG on substantive AD review comments, and I 
am not sure why I failed to do so in this case.  Anyway, you can read 
my comments below.

This document has been placed in "AD Review -- Revised ID Needed 
State" and I am waiting for these issues to be resolved before 
sending the document to IETF Last Call.

Your comments are welcome!

Margaret

---

I have completed my AD review of draft-ietf-ipv6-link-scoped-mcast-05.txt,
and I have several comments on this draft.  As some of these comments
are substantive, I would like the draft to be updated to address these
concerns before we send it to IETF Last Call.

Let me start with a couple of general comments:

(1) There are several places in this document where it says that these
link-scoped multicast addresses will be assigned "at the same time" as
link-local addresses are auto-configured.  I don't see any reason for
this restriction, and I believe that these addresses could safely be
configured at any time after DAD is completed.

(2) The document says:

     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].

This makes sense to me, but I think it misses the point...  Since
these addresses are created from the unique IID, their useful lifetime
is linked to the period during which the IID is known to be unique.
Right?  So, the document needs to discuss what happens to these
addresses if there is a later IID conflict, due to a new node joining
the network that uses the same IID.

I also have some specific comments on the text (marked with '>>'):

Abstract

     This document specifies an extension to the multicast addressing
     architecture of the IPv6 protocol. The extension allows for the use
     of interface-IDs to allocate multicast addresses.  When a link-

>>  I would refer to Interface Idenfitiers (IIDs) the first time and
   later use the IID acronym for consistency with other IPv6
   documents.

     Consequently, this technique MUST be used for link scoped multicast

>>  MUST only be used for link scoped multicast?  (s/MUST/MUST only) ??

     addresses.  If you want to use multicast addresses greater than
     link-local scope, you need other methods such as [RFC 3306].

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

>>  What type of further processing is done on these addresses?  I
   wouldn't think that, after they are generated, these addresses
   would be handled any differently than other link scoped multicast
   addresses...

     Interface ID field is used to distinguish each node from others.
     And this value is obtained from the IEEE EUI-64 based interface
     identifier of the link-local unicast IPv6 address.  Given the use
     of this method for link-local scope, the interface ID embedded in
     the multicast address SHOULD come from the interface ID of the
     link-local unicast address on the interface after DAD has
     completed.  That is, the creation of the multicast address MUST
     occur after DAD has completed as part of the auto-config process.

>>  This paragraph conflicts with itself.  It is not clear whether the
   link scoped address SHOULD only be configured after DAD has
   completed or MUST only be configured after DAD has completed.  I
   think you mean MUST...

6. Security Considerations

     [RFC 3041] describes the privacy extension to IPv6 stateless
     address autoconfiguration for an interface ID.  The interface ID,
     generated by [RFC 3041], is also used in this method since the
     uniqueness is verified by DAD procedure as part of the secure auto-
     config process.

>>  You should probably indicate whether link scoped multicast
   addresses can be configured using IIDs generated for privacy
   addresses or not.

       Informative

       [RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor
                   Discovery for  IP Version 6 (IPv6)," RFC 2461,
                   December 1998.

>>  I think that you need a normative reference to this and to IPv6
   Auto Configuration.

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