Subject: more on reclaiming 225/8

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2001 09:34:04 -0700

Regarding what I saw at OSU (225.1.2.3):

corvallis-hub>sh ip mroute | inc 225.1.2.3
(*, 225.1.2.3), 4w1d/00:02:59, RP 207.98.64.240, flags: SP
[...]
(128.193.22.165, 225.1.2.3), 07:41:37/00:03:11, flags: T
(128.193.25.37, 225.1.2.3), 05:45:54/00:03:11, flags: T
(128.193.190.19, 225.1.2.3), 1w0d/00:03:11, flags: T
(128.193.190.93, 225.1.2.3), 5d06h/00:03:11, flags: T
[...]

There are a ton of these (> 110) in use. Why? It would appear
that there is a software/OS replication package named Altiris
distributed by/with Compaq. The default OS installation on the
Compaqs includes Altiris (whatever it is) and it is configured to
use 225.1.2.3 as its default group. However, I can't tell this is
a Compaq setting or an Altiris default. 

This is yet another reason why we need a document like
draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt.

Dave

-----

>>   225/8 was allocated for experimentation with the MASC protocol.
>>   In particular, it was to be used to statically assign the top
>>   level of the MASC infrastructure (statically) so we didn't have
>>   to deploy a BRIB capable routing system before experimenting
>>   with the MALLOC architecture. The assignment is (from 
>>   http://www.iana.org/assignments/multicast-addresses):
>> 
>>   225.0.0.0-225.255.255.255  MALLOC (temp - renew 1/01) [Handley]
>> 
>>   Since we are not using 225/8 for this purpose (or at all, for
>>   that matter), I want to reclaim it. Mark Handley suggested that
>>   I mention this to the list. If you have comments, please
>>   respond directly to me (copying the list). 
>> 
>>   Thanks,
>> 
>>   Dave

---

From: John Meylor <[email-masked]>
Date: Thu, 05 Jul 2001 12:37:28 -0700

David Meyer wrote:
> 
> >> May be this needs to specifically include product developers and vendors :
> >>
> >> 15. Use of IANA Reserved Addresses
> >>
> >>    Applications MUST NOT use addressing in the IANA reserved blocks.
> 
> My sense is that's a different document. I'd like to keep this
> one focused on the IANA.

right, again, perhaps something like <draft-ietf-mboned-mcast-apps-02.txt>.

 john

---

From: John Meylor <[email-masked]>
Date: Thu, 05 Jul 2001 12:36:36 -0700

Hugh LaMaster wrote:
> 
> We seem to need some kind of educational effort to get
> the word out to these companies regarding sensible use.

indeed

> Certainly, some uses are obviously not sensible, but,
> I don't see anything in
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt
> 
> that specifically prescribes the correct thing to do
> to a consumer product developer.

perhaps this could be incorporated into something like Bob, Kevins:
<draft-ietf-mboned-mcast-apps-02.txt> in section on address management.

 John

---

From: Brad Hefta-Gaub <[email-masked]>
Date: Thu, 05 Jul 2001 13:14:42 -0700

Hugh LaMaster wrote:

> Should sdr-like code be required in such products?  I don't know what the companies have
> in mind if multiple users on a LAN happen to be using the same product.  Have any people
> on these mailing lists had any discussions with the folks
> at these companies regarding what they are going with such products?

These are some great questions, and I'm glad to see the discussion group turning its
attention to this topic. As a developer of server software that transmits multicast we
seriously considered this question and came to the following implementation.

1) We allow users to dynamically configure the address ranges used by each RealSystem
Server instance. In our documentation we attempt to educate the users to the standards and
issue involved in the selection of an address range.

2) We have also implemented optional support for SAP/SDR. In our implementation, the server
can be asked to send out SAP announcements, as well as listen for SAP announcements. When
our product is configured to listen for SAP announcements it will remove any addresses that
are announced as in use from it's range of selectable addresses. When it is configured to
announce, it obviously announces the addresses it is using.

For intranet uses, we recommend that network administrators configure their servers to
announce and listen for SAP, and provide each of there servers with the same reasonably
sized range of addresses. In this configurations, multiple RealSystem Servers will happily
coexist without stepping on each others address spaces. Assuming the user is using other
multicast applications on their network, they can either configure the RealSystem Server to
avoid address ranges they've applied to those other applications, or if that application
also uses SAP/SDR, then the RealSystem Server will automatically detect its announcements
and avoid those addresses that are in use.

Now, to be clear, this is what we've implemented to date. We recognize that SAP never
really reached standards track, but we implemented this support before alternate solutions
were available. We are aware that today MADCAP is a standards track solution for address
allocation, and we are reviewing the feasibility of implementing support for this, as well,
in our products. At this point, we don't hear demand for this from our customers. I am
curious if the group has insight into the general availability and use of MADCAP servers in
the field. (Which vendors have shipping MADCAP server implementations, etc.) I would
envision us taking the approach in the future of allowing the use of MADCAP as an option to
the user configured address range.

I would welcome any feedback that the group might have on the approach we've taken.

-Brad

Brad Hefta-Gaub
General Manager of Product Development
Media Systems Division
RealNetworks, Inc.

---

From: zaid <[email-masked]>
Date: Thu, 5 Jul 2001 15:39:02 -0400 (EDT)

I can see where this can blow up once we start including vendor/apps
specific points.

Zaid

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2001 12:45:29 -0700

>> <draft-ietf-mboned-mcast-apps-02.txt> in section on address management.

Good idea (as I said, it belongs somewhere, just not in the IANA
guidelines). 

Dave

---

From: Beau Williamson <[email-masked]>
Date: Thu, 05 Jul 2001 16:12:52 -0500

Hugh,

Wouldn't this be better handled by having all applications use MADCAP to obtain the group address? After all, this is what that protocol was designed to do.  (If I remember correctly.)

Of course there is a problem if the application is a legacy application that doesn't support MADCAP and doesn't bother to request an group address.  How would you enforce certain policies concerning group address usage?

I have several customers that are wrestling with these sorts of issues (admission control, rate-limiting, address-allocation, etc.) and it doesn't appear that there are any standard ways to deal with these problems.

Beau
At 03:22 PM 7/5/2001, Hugh LaMaster wrote:

>Sounds good to me also.  In fact, I see that the section on 
>address management actually does have this started:
>
>
>   In almost all cases, application designers should assume that
>   multicast addresses are to be dynamic.  Very little of the multicast
>   address space is available for static assignment by IANA [MADDR].
>   Also, given the host-specific addressing available with SSM, Internet-
>   wide, static address assignment is expected to be very rare.
>   
>   
>I think with a little more directness, e.g., drop a few qualifiers:
>
>   Application designers should assume that multicast addresses are 
>   to be dynamic.
>
>But, from this point on, I'm not sure what should be written.  
>Most of this document is written from the perspective of 
>streaming media servers/clients or the similar videoconferencing,
>but, the applications that are causing the most trouble with MSDP 
>&etc. are things that don't fit that model - e.g. DriveImage.
>
>How *should* a non-interactive non-A/V mostly-local application
>get its address (presumably in 239.255.x.y) and (port)?
>Although sdr does work on the 239.x.y.z spaces by using
>the appropriate multicast address, e.g., for 239.255.x.y,
>239.255.255.255 for the SAP announcements, it isn't obvious
>to me that a batch/CLI type application that might be run
>automatically at a particular time fits the sdr/SAP model.
>
>I'm speculating that a query mechanism could be used, e.g., IGMPv3
>general query, that would instantaneously return groups
>to be avoided, and that the application could then randomly
>select address and port, and then advertise via SAP
>the selected group in 239.255/16.  Is that a bad idea (probably)?
>
>
>--
> Hugh LaMaster, M/S 233-21,    Email: [email-masked]
> NASA Ames Research Center     Or:    [email-masked]
> Moffett Field, CA 94035-1000  Or:    [email-masked]
> Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 5 Jul 2001 13:22:54 -0700 (PDT)

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 5 Jul 2001 11:41:36 -0700 (PDT)

I think static assignments in, e.g., 224.[0,1].x.y are almost always
a bad idea, but, I'm not sure how a product, intended for use by
folks who know little or nothing about multicast, should
[automatically] go about assigning such an address dynamically.  
Something in 239.255/16 is definitely local, but, how should the 
address/port be assigned?  Should sdr-like code be required in such 
products?  I don't know what the companies have in mind if multiple 
users on a LAN happen to be using the same product.  Have any 
people on these mailing lists had any discussions with the folks 
at these companies regarding what they are going with such products?

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2001 11:47:27 -0700

>> to a consumer product developer.

That's because it's not targetted at developers. Its built to
guide the IANA.

>> at these companies regarding what they are going with such products?

I have not.

Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2001 12:21:26 -0700

Dave

---

From: zaid <[email-masked]>
Date: Thu, 5 Jul 2001 15:05:42 -0400 (EDT)

Hi Hugh,

All addresses that are not currently used or assigned by IANA are
considered reserved.

I think we also need for networks to update their scope/filter policies
to stop forwarding reserved groups. 

Thanks
Zaid