Subject: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses"

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Oct 2003 16:25:53 -0700

This is a IPv6 working group last call for comments on advancing the 
following document as an Proposed Standard:

	Title		: Link Scoped IPv6 Multicast Addresses
	Author(s)	: J. Park, et al.
	Filename	: draft-ietf-ipv6-link-scoped-mcast-03.txt
	Pages		: 5
	Date		: 2003-7-2

Please send substantive comments to the ipv6 mailing list, and minor 
editorial comments to the authors.  This last call period will end on 4 
November 2003.

Bob Hinden / Brian Haberman

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 11:09:57 +0200 (CEST)

The document says:
  scop <= 2.  The value of this multicast address is necessary to 
  distinguish between an Interface ID-based multicast address and a 
  unicast-prefix-based multicast address.  If scop <= 2, the former MUST 
  be used.  That is, this document updates the [RFC 3306], which 
  describes the latter. 

I'm trying to understand why the RFC 3306 are so broken for scope <=2
that they can not be used.
While using the new address format for scope <= 2 would presumably be
preferred I don't see why prohibiting (as the "MUST" above does)
the use of RFC 3306 for those scopes.

If prohibiting them is the right thing I think the document should state why.

The example says:
  This is an example of an interface ID-based multicast address with 
  link-local scope.  For example in an Ethernet environment, if the 
  link-local unicast address is FE80::12:34:56:78:90:AB, the multicast 
  prefix of the host is FF32:0:1234:56FF:FE78:90AB::/96.  For SSM, 
  multicast address will be FF32::/96. 
Typo (I think): FE80::12:34:56:78:90:AB should be FE80::1234:5678:90AB

and a better example would have a 64 bit iid (the above one has 16 leading
zeros). Such as
	FE80::a12:34ff:fe56:7890
resulting in
	FF32:0:a12:34ff:fe56:7890::/96

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 14:26:24 +0200 (CEST)

> In my memory,
> IPv6 guys also agreed on our view during the 54th IETF meeting.
> 
> I think ..
> RFC3306 needs allocation server of 32bit goup ID
> in order to support the uniqueness in the site.
> This site is identified by network prefix.
> 
> But, 
> Group ID Autoconfiguration in link-scope will be valuable 
> without help of allocation server.
> Each node in our draft  allocates group ID independently.

I understand that link-scope has benefits over unicast-prefix for scope <=2.
So saying "it is preferred to use ..." or "recommended" would seem ok.
But saying "MUST" - meaning a prohibitation of using unicast-prefix -
seems much to strong unless there are arguments that unicast-prefix
is "broken" (not just "suboptimal") for those scopes.

  Erik

---

From: "jspark" <[email-masked]>
Date: Wed, 22 Oct 2003 20:23:58 +0900

Hi Erik

Thanks for your comments.

>preferred I don't see why prohibiting 
> (as the "MUST" above does) the use of RFC 3306 for those scopes.

> If prohibiting them is the right thing I think the document should state
why.

Technically, RFC3306 can be used  for scope <=2.

RFC3306 author's  consent to the following sentence :
our draft updates the "Unicast-Prefix- based IPv6 Multicast 
Addresses" for the link-local scope. 

In my memory,

I think ..

But, 

zeros). Such as
> 	FF32:0:a12:34ff:fe56:7890::/96

Good comment. 
We will publish new draft with a reflex of reality soon.

Jungsoo

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Oct 2003 17:19:23 +0300 (EEST)

Hi,

> 	Filename	: draft-ietf-ipv6-link-scoped-mcast-03.txt
[...]

There are a large number of things to be said, but I'll just stick to two
main points.  I've never seen much use for this specification, and I do
not believe this specification is useful as is.

It should be replaced by Informational guidance how to use "vanilla"
RFC3306 to generate the addresses the nodes want, or by the a
specification of link-scoped multicast DAD.

Further, as currently written, the addresses generated are from Source
Specific Multicast range, rendering them practically useless for the
purposes of the memo.

 1) I've never seen a justified reason why this is useful.  Apparently, 
the document aims to allow a node to generate unique link-scoped multicast 
addresses autonomously, without any user input, without a fear of 
collision or any additional mechanisms.

First, there is no guarantee of uniqueness in the first place, as DAD on
the IPv6 link-local unicast address was performed on the address, not the
Interface-ID.  In practice, the collisions should be very rare, though.

Second, considering that there is no guaranteed uniqueness, what harm is 
there to generate the addresses as currently specified in RFC3306, like:

 - take the prefix of a link-local address (e.g. fe80::/64, or fe80::/10)
 - put it in RFC3306 address, like FF32:40:fe80:<stuff>:<group-id> or
   FF32:A:fe80:<stuff>:<group-id>.
   this would leave 64 bits space to generate an address, assuming the 
   group-id is 32.
 - the 64 bits (<stuff>) could be the interface ID of the link-local 
   address, or something else completely, like a random number.

Ergo, there seems to be zero need to specify an update for RFC3306, it can
already provide for a mechanism to allocate the link-local multicast
addresses.

Third, if we want to go down this particular path, a better solution would
probably be to create a generic "multicast DAD" mechanism to verify the
uniqueness of a group either on a link, or within a multicast scope.  If
the applicability would be on the link, even unicast DAD mechanisms could
be reused.

2) the current spec uses the reserved field in such a fashion that plen=0 
and the other nodes not implementing this spec will interpret the 
link-local multicast addresses generated using this spec as SSM addresses.  

The problem with this is that the SSM implementations need to have new
special code for the treatment of scope=2 and plen != 60.  This will
result in inconsistent behaviour, and is counter-productive.

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Oct 2003 17:35:47 +0300 (EEST)

>    address, or something else completely, like a random number.

oops.. a miscalculation; this would leave (about) 48 bits for "stuff"  
rather than 64.. assuming the group-id would be 32, which it wouldn't need
to be.

regardless of that, the point seems valid: there seem to be little need 
for this spec.

of course, the simplest way would be use the about 48 bits or 80 bits to
randomly generate an address.  The collision probability is insignificant.

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 23 Oct 2003 11:06:07 +0900

> is "broken" (not just "suboptimal") for those scopes.

   ok, I think it is a good clarification.

   Thanks,
   Myung-Ki.

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 23 Oct 2003 11:08:46 +0900

Hi, Pekka.

> not believe this specification is useful as is.

   As Erik said, I think that this draft has benefits over unicast-prefix for
   scope <=2.
   Each node can allocate group ID (32 bits) independently (without any user
   input,  without a fear of collision or any additional mechanisms).

> Interface-ID.  In practice, the collisions should be very rare, though.

   I don't think so.
   DAD on the IPv6 link-local unicast address also guarantees the uniqueness
   of  Interface-ID in the link-local unicast address.
   I beleive that there was a consensus on that (when the draft was
   published).

>    address, or something else completely, like a random number.

   As you said, this is wrong calculation :)

> the applicability would be on the link, even unicast DAD mechanisms could

   I think "multicast DAD" is an another mechanism.
   I (and many folks) don't want to make a new mechanism for this goal
  (link-scoped).
   Link scoped multicast address is more simple and convenient.

> link-local multicast addresses generated using this spec as SSM addresses.

   In unicast-prefix,
   to accomplish SSM, a node MUST: [RFC 3306]

         o  Set P = 1.
         o  Set plen = 0.
         o  Set network prefix = 0.

   Thus, the "network prefix" should be mentioned to distinguished the
  conflict.
   In this draft, "Interface ID" of link-scoped mcast address != 0.
   I think this clarification should be added in current document.

  Thanks,
  Myung-Ki.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2003 09:12:46 +0300 (EEST)

On Thu, 23 Oct 2003, Myung-Ki Shin wrote:
[...]
>    input,  without a fear of collision or any additional mechanisms).

There is 32 bits worth of group ID to distinguish between the groups the 
different nodes use.  There is about 48 bits to distinguish between the 
nodes on the same link.  Don't you think this is already enough?

There is no need to define precise external semantics (like embedding the
interface ID) to what the addresses should include (i.e., the neighbor
node doesn't need to know which address the other node would use for
multicasting group-id X).  It's just enough that they're reasonably
unique.  This can be done using a number of techniques, none of which
warrant a Protocol Action from the IETF.

>    I beleive that there was a consensus on that (when the draft was

No, I think it was specifically some form of consensus that DAD is not
DIID.  This is true in particular with unicast prefixes.  This happens
with link-local prefixes as well, if you use e.g. fe81::1 and fe80::1 on
the same physical link but pointing to different nodes.  (Btw, does the 
spec say the interface-ID must be taken from the link-local address? If 
not, it will have problems with manually configured global addresses..)

>    As you said, this is wrong calculation :)

.. but this doesn't nullify the usefulness of the algorithm.  Just insert 
something probably unique (a random number, MAC-address, etc.) in the 48 
bits and you're done.

>    I (and many folks) don't want to make a new mechanism for this goal

Agreed.

>    Link scoped multicast address is more simple and convenient.

Inventing an address without additional specification would be even 
simpler.

>    I think this clarification should be added in current document.

If an SSM implementation checks for FF3x::/32 (as described in RFC 3306
section 6), and not for FF3x::/96 (as described in RFC 3306 section 7),
but will not implement this specification, there will be lots of trouble.

---

From: "jspark" <[email-masked]>
Date: Fri, 24 Oct 2003 10:36:00 +0900

Hi, Pekka.

>>>Pekka Savola wrote:
>> > First, there is no guarantee of uniqueness in the first place, as 
>> > DAD on the IPv6 link-local unicast address was performed on the 
>> > address, not the Interface-ID.  In practice, the collisions should be
very rare, though.

>>Myung-Ki Shin wrote:

>No, I think it was specifically some form of consensus that DAD is not
DIID.  
>This is true in particular with unicast prefixes.  This happens with
link-local prefixes as well, 
>if you use e.g. fe81::1 and fe80::1 on the same physical link but pointing
to >different nodes.  
>(Btw, does the spec say the interface-ID must be taken from the link-local
address? 
>If not, it will have problems with manually configured global addresses..)

I understand what you mean.
So, I'd like to clarify this. 

Section 3 of our spec says:
-----------
  "Interface ID field is used to distinguish each host from others.  And 
   this value is obtained from the IEEE EUI-64 based interface 
   identifier of the link-local unicast IPv6 address."
-----------

Our method uses only  the EUI-64 based Interface ID, 
derived from Link-local unicast address. 
So, there is guarantee of uniqueness in our method. 

>> > Pekka Savola wrote:
>> > 2) the current spec uses the reserved field in such a fashion that 
>> > plen=0 and the other nodes not implementing this spec will interpret 
>> > the link-local multicast addresses generated using this spec as SSM
addresses.

>>Myung-Ki Shin wrote: 

>If an SSM implementation checks for FF3x::/32 (as described in RFC 3306
section 6), 
>and not for FF3x::/96 (as described in RFC 3306 section 7), but will not
implement this specification, 
>there will be lots of trouble.

Of course, 
I think a SSM implementation "MUST" check for FF3x::/96.

Thanks

JungSoo

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 24 Oct 2003 11:17:43 +0900

> >> > address, not the Interface-ID.  In practice, the 

My understanding is that there will be no problem, because the spec 
says the interface-ID must be taken from the link-local address
(IEEE-64 based interface ID) 

> >there will be lots of trouble.

I think all SSM multicast addresses must have the format FF3x::/96,
according to ["network prefix = 0" of RFC 3306] hence there will be no
trouble. 

Daniel

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2003 09:46:09 +0300 (EEST)

> Section 3 of our spec says:

First, there is typically just one link-local address.  Either it uses 
EUI-64 based IID or not.  If it doesn't, you can't generate addresses like 
this.

Second, the EUI-64 does not guarantee the uniqueness of the method.  
Otherwise we would not be needing DAD with addresses that are generated 
with EUI-64.  But it is mandated by the specs.  So these addresses are 
*not* truly, completely, totally, unique.

> I think a SSM implementation "MUST" check for FF3x::/96.

This is certainly one interpretation.  I'm not sure everybody has made the 
same.  This should be brought to the attention of e.g. MBONED WG to see 
what kind of interpretations they have.