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