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,
Pekka Savola wrote:
> 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?
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
