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