A Method for Generating Link-Scoped IPv6 Multicast Addresses
draft-ietf-ipv6-link-scoped-mcast-09

[Ballot discuss]
I'd like to see a change in title; as someone knowledable about IPv6 and multicast in general but not having seen this document, I thought from the title that it was about link scoped multicast - I would like to see the title be something like "A Method for Generating Link Scoped IPv6 Multicast Addresses", or "IID-based Link Scoped IPv6 Multicast Addresses".

[Ballot comment]
>      Basically, it is preferred to use this method for the link-local
>      scope rather than unicast-prefix-based IPv6 multicast addresses
>      [RFC 3306].  This document restricts the usage of defined fields
>      such as scop, plen and network prefix fields of [RFC 3306].
>      Therefore, this document specifies encoded information for link-
>      local scope in multicast addresses.

It would be good to add  a sentence explaing _why_ this mechanism is
preferred over the one in 3306.

[Ballot discuss]
does IID have to be an IEEE EUI-64  identifier? The document
is unclear. I assume it does not need to be, but it says:

>      The IID field (replacing the 64-bit prefix field from [RFC 3306])
>      is used to distinguish each node from others.  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

IEEE EUI-64 is a very specific thing and is not an IID.

Follow-up message sent to Pekka:

Date: Sun, 5 Dec 2004 10:35:25 -0500
To: Pekka Savola <pekkas@netcore.fi>, iesg@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Cc: ipv6@ietf.org
Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed
Standard
X-BeenThere: ipv6@ietf.org
List-Id: "IP Version 6 Working Group (ipv6)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
<mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
<mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
X-Spam: [F=0.0004985666; B=0.500(0); HS=0.500(-26400); S=0.010; MH=0.830(2004120501); R=0.010(s301/n44012)]


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

IETF LC Comments:

From: Pekka Savola <pekkas@netcore.fi>
To: iesg@ietf.org
Cc: ipv6@ietf.org
Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed
Standard

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:
>
...snip...
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org 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".

I have completed my 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 I 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.

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes



2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?



The document has been reviewed by several members of the IPv6 WG.

Additionally, several multicast experts have reviewed the proposal.

The chairs have no concerns about the reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?



No.



4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.



No concerns.



5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?



This document has strong concurrence within a small set of the WG.



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.



No.



7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?



Yes



- Technical Summary



    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-

    local unicast address is configured at each interface of a node, an

    interface ID is uniquely determined.  By delegating multicast

    addresses at the same time as the interface ID, each node can

    generate their unique multicast addresses automatically without

    conflicts.  Basically, it is preferred to use this method for the

    link-local scope rather than unicast-prefix-based IPv6 multicast

    addresses [RFC 3306].



- Working Group Summary



The IPv6 working group has done reviews of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the ipv6@ietf.org

mailing list and by the working group chairs.





Regards,

Brian & Bob

IPv6 WG co-chairs