Subject: RE: uni-based-mcast and malloc-ipv6-guide

From: "Dave Thaler" <[email-masked]>
Date: Mon, 17 Sep 2001 09:17:10 -0700

Erik,

I'll let Brian respond to the editorial comments, but to
quickly answer a few of your questions:

> Will the unicast prefix based addresses ever need to use the
link-local
> prefix?

Need? No, since it could only ever be used for link-local multicast
groups,
and for that scope they don't buy you anything.

> If not it might make sense to explicitly ban that where it talks about
> scope
> in section 3.

Doesn't matter to me.  Technically it doesn't hurt anything to allow
them.
Whether it would be operationally clearer to allow or disallow them,
I don't know.

> The last paragraph in section 3 is about lifetimes.
> I don't understand what the intended effect is of the statement
> since I don't know what the lifetime is of a multicast address.

See RFC 2908.

> Is the intent that e.g. if the prefixes are advertised with a 1 day
valid
> lifetime, that an implementation MUST NOT use multicast addresses
derived
> from those prefixes in SDP advertisements that end beyond 1 day ahead?

Yes.

> If the intent is to really be that strict the document definitely
needs
> to be a lot more specific on this point. But I don't see a need to be
> that strict - all these multicast addresses are temporary - is there
> any real danger is for some applications "temporary" spans unicast
> prefix renumbering events?

Yes.
The operational danger is confusion and failure to diagnose problems
in a timely fashion.  (Same as would happen today in IPv4 if people
started using others' AS numbers in their multicast groups.)
The performance danger is possible collisions (specifically when
the group ID is IANA assigned or algorithmically generated)
between the old prefix owner and the new prefix owner.
 
-Dave

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Sep 2001 14:17:21 -0400

> See RFC 2908.

2908 seems to say mcast addresses have a start and end lifetime. That
makes sense. What I think is potentially significantly different with
the approach described in *this* document is that the lifetimes are
much shorter. I.e., it is conceivable that unicast addresses will be
advertised with prefixes of several days or a week in common
cases. That doesn't mean the addresses will expire then, just that
short unicast lifetimes are being advertised, just in case, it becomes
necessary to deprecate the address relatively quickly. However, if
multicast addresses derive their lifetimes from the same lifetime,
there may be a mismatch in expectations.
 
Seems to me that it might very well cause problems for multicast
applications that request an address with a start and end time that
don't match the advertised lifetimes of unicast addresses.

I wonder if this point should to be discussed in the document
explicitely. I.e., seems like this is a potential difference between
IPv4 multicast and IPv6 multicast. We should be making such
differences very clear to minimize confusion, if nothing else.

Will the tying of mcast adddresses to unicast lifetimes put additional
pressure on using longer unicast lifetimes?  Is this a good thing?

What are typical start and end times that folks use in IPv4  today? Do
they match expectations for unicast lifetimes in IPv6?

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Sep 2001 20:23:07 +0200 (CEST)

> See RFC 2908.

At least that reference is missing from the document.
But I see a mismatch between the draft and RFC 2908 since the latter
seems to say that an application can request multicast addresses with
a particular lifetime. With the uni-based addresses there can be no
way for the application to request a lifetime.
How can this be resolved?

> > from those prefixes in SDP advertisements that end beyond 1 day ahead?

If that is indeed the WG consensus then this should be made very clear
in the draft.

  Erik

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 10:04:44 -0400

Erik,

> How can this be resolved?

Well, the first thing is to actually reference 2908 in the doc. :)
I will make sure that 2908 is part of a section describing the
changes between v4 and v6 mcast allocation.

Brian