Subject: IPv6 link-scoped multicast

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 00:24:18 +0300 (EEST)

Hi,

(This will be discussed in IPv6 WG session, but to bring it up in 
MBONED as well as appropriate..)

draft-ietf-ipv6-link-scoped-mcast-04.txt specifies link-local -scoped
IPv6 multicast addressing format, which uses a format which would
conflict with SSM address range FF3x::/32 (but not FF3x::/96).  
Basically it just embeds the EUI64 identifier ("MAC-address") on the
multicast address plus leaves 32 bits for group-id.

I think there are two big problems I see with this:

  1) this conflicts with the (reserved) SSM address range, causing 
     problems with all the implementations which do SSM.

  2) the problem this draft is solving is not sufficiently well
     understood or articulated.

The first is IMHO a sufficient reason to design this in some other 
way.  But IMHO the second is a larger problem, which affects the way 
such a re-design should be made.  We should not go forward until we 
can write down a precise problem statement..

It has been stated that this form of multicast addressing is needed in 
a zero-conf link-local environment.  But this is really vague and 
doesn't answer the real questions: 

  a) how do you perform source discovery / rendezvous in such a 
     zeroconf environment?

  b) do you need to support scenario where sources would be frequently 
     moving from one zero-conf link-local environment to another?

  c) why can't you use transient link-local multicast addresses?  
     There's potentially 112 bits for link-specific group-id's -- that 
     should be enough to randomize an address and not have conflict.

  d) even if you used RFC3306-based addressing with prefix fe80::/64, 
     there would be 32 bits of group-id to pick from.  Isn't this 
     enough?  (If I'd have to choose a redesign, I'd probably pick 
     this.)

  e) if a random group-id is not acceptable, why the group-id must be 
     static, or somehow determinable?

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

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 03 Aug 2004 02:45:00 +0900

As for the #1,
first of all, the authors of this draft tried to figure out SSM address
ranges,
(which one is correct - FF32::/96 or FF32::/32 ?)

 o FF3x::/32 appears once in RFC 3306, sec 6.
 o FF3x::/96 is more frequently mentioned in several specs
      - RFC 3569 - sec 2, sec6,
      - draft-ietf-ssm-arch-04.txt - sec 1
      - RFC 3307 - sec 3, and RFC 3306 - sec 7, etc.,

We thought SSM implementations should check for FF32::/96, rather than
FF32::/32
since is a better/safer way to check for FF3x::/96 - it could avoid wacky
addresses.
E.g.,  FF32:0:0:1::1 could be checked.

So, we asked Brian Haberman who is a co-authors of RFC3306.

His answer is :
The other documents refer to the /96 since RFC 3306 specifies the first 96
bits of the SSM address.  However, RFC 3306 reserves the larger /32 in
order to allow for expansion of the SSM range in the future.  Any future
work though would require a new RFC to be written.
Given that, Brian would suggest that /32 be used as the guideline for any
changes in our draft.  By doing so, our spec would not be affected by
future expansion in the SSM space.
---

So, we got 2 choices at this time.

First choice is to
    let it remain as it is - with SSM implementation considerations.
    sec 5 of current spec reflects that  : In order to avoid this
conflict,
    we recommend SSM implementations must check for FF3x::/96

    However, this recommendation/restriction of this draft is not good,
    because this definition or interpretation MUST be taken
    by SSM/Mboned WG first.

Second chice is to
    change the address format a little bit to distinguish SSM and
    Link scoped multicast addresses

    One of candidates is Update plen field in [RFC 3306] as LSM

|   8    | 4  | 4  |  8  |  8  |       64       |       32      |
+--------+----+----+-----+-----+----------------+---------------+
|11111111|00PT|scop| rsvd| LSM |   Interface ID |    group ID   |
+--------+----+----+-----+-----+----------------+---------------+

    LSM (plen of RFC 3306) field MUST be 1111 1111,
    while plen of RFC 3306 MUST NOT be greater than 64.
    E.g, Link scoped mcast addresses = FF32:00ff:a12:34ff:fe56:7890::/96.
    It can be distinguished from SSM - FF32::/32

Or, we can consider use of reserved field in [RFC 3306].

We'll discuss about this issue at upcoming IPv6 session (Wed.)
Before meeting, we'd like to listen mboned WG's(or IPv6 WG) opinion first.

Regarding applicability issue,
this draft is an extension to the multicast portion of IPv6 addressing
architecture [RFC 3513] and Unicast-Prefix based Addresses [RFC 3306]
for *Link Scoped*.

We and many people from IPv6 WG think that
this spec has benefits over RFC3306 for scop <=2.

Each node can generate its unique multicast addresses - /96 automatically
without multicast allocation servers (without collision fear).

We have a real/well-implemented zero-conf. multicast application in ad-hoc
env.
I believe other co-authors will explain its scenarios/operation soon.

Thanks,
Myung-Ki,

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 05 Aug 2004 06:00:53 +0900

As for the issue #2,
our main goal is to *generate* unique multicast addresses - /96
automatically (like RFC 3306) without any fear of conflicts.

It goes well with multicast sources supplying link scoped
multicast services in a zeroconf/serverless environment
(especially, multi-link subnet, etc.).

I think source discovery, etc. are another challenging
problems and (actually) out of scope in this draft.
Also, it could be very application (implementation)-dependent, you know.

But, we can show application scenarios.
This is very simple one of examples.

o Multicast source side
   1. Link-local address
     - FE80::a12:34ff:fe56:7890
   2. Predefined/static group id
     - Channel 1 -> 1
   3. Source can get unique multicast addresses - /96
     - FF32:00ff:a12:34ff:fe56:7890::/96
   4. Session creation
     - FF32:00ff:a12:34ff:fe56:7890::1
o Multicast receiver side
   1. Predefined/static group id
     - Channel 1 -> 1
   2. *Source discovery*
     - LLMNR + predefined group id
   3. Join
     - FF32:00ff:a12:34ff:fe56:7890::1

Thanks,
Myung-Ki,

---

From: Pekka Savola <[email-masked]>
Date: Thu, 5 Aug 2004 02:57:37 +0300 (EEST)

> automatically (like RFC 3306) without any fear of conflicts.

"Any fear" is subjective.  It is completely possible that a node 
might start to send an SSM stream to that particular multicast 
address.

>      - FF32:00ff:a12:34ff:fe56:7890::1

So, the group ID appears to be communicated out of band.

What is the name of the session?  Why cannot the source check from
LLMNR whether such a session, or such an address under that session
does not already exist? (This is why I was stating that this kind of 
problems appear to be trivially solved as part of source discovery.)

Apart from that..

Can you provide a bit of details what you're actually obtaining from 
LLMNR?  Does the source register the address 
FF32:00ff:a12:34ff:fe56:7890::1 there, and just join to what you 
receive?

If so, there is really no requirement for embedding EUI64 on the
address, it's just something that's assumed to be reasonably unique.

A constructive suggestion: reword this spec to use the upper bits of 
FF02::/16, even embedding the EUI64 if you wish, and publish it as an 
Informational RFC if you think an RFC is really needed.

---

From: Jerome Durand <[email-masked]>
Date: Thu, 05 Aug 2004 19:32:52 +0200

> might start to send an SSM stream to that particular multicast 

And remember you can take 1,000,000,000 addresses on the link keeping a 
probability below 1 over 1,000,000 that there is a collision. Therefore 
I think you should justify your proposal with something else (simplicity 
for example, or calculation method to avoid randomization...)

My concern is that we can always derive a multicast address from 
something. You seem to need these addresses and I would really like to 
see examples of applications.

> Informational RFC if you think an RFC is really needed.

I'd say FF12::/16 as FF0X::/16 are must be reserved by IANA right?

Thanks !

Jerome