Re: Reserved addresses in the SSM range

[jhall@UU.NET (Jeremy Hall)]

I can say beyond a shadow of a doubt that we will not wish to implement a
feature where one packet can generate many responses.  The Internet as a
whole is still trying to rid of the problems with DOS attacks and directed 
broadcast.

_J

In the new year, Doron Rajwan wrote:
> 
> Hugh LaMaster might be right that the addition of the reserved addresses
> mechanism might not worth it. Still, I think that we have (almost) nothing
> to loose by reserving addresses. We might gain from being able to tell if a
> multicast source is alive, using the "ping" address I suggested.
> 
> I do not have a strong opinion on this issue.
> 
> Doron.
> 
> 
> 
> -----Original Message-----
> From: Hugh LaMaster [mailto:lamaster@nren.nasa.gov]
> Sent: Tuesday, August 08, 2000 1:12 AM
> To: SSM List
> Subject: Re: Reserved addresses in the SSM range
> 
> 
> 
> On Mon, 7 Aug 2000, Jeremy Hall wrote:
> 
> > I am finding it difficult to know why one would wish to reserve addresses.
> 
> I agree completely.  I see no reason to reserve *any* SSM groups.
> 
> > > First, we have nothing to loose.
> 
> Not true.  We have excess documentation.  Look at all the current
> IANA multicast address assignments that were made, sit there taking 
> up space in the documents, people have to read at various times, 
> and 99% of which are never used.
> 
> > > Second, we all know that UDP and TCP reserved ports is proven to be
> > > helpful.
> 
> And harmful.  Look at all the unnecessary port assignments in the
> IANA documents.  380K worth of port assignments, almost all of 
> which could easily have been assigned dynamically.
> 
> > > can think of the following services, each given in a different,
> > > predefined,
> > > multicast address:
> 
> IMHO, static address and port assignments should only be used
> for unavoidable bootstrap mechanisms or where a well-known port
> is used to support a universal service (e.g. NTP).  All other 
> addresses and ports should be dynamically assigned.  If this 
> policy were followed, about 99% of these assignments could 
> go away.
> 
> > > 
> > > 1. Time service. The server's local time and time zone every second.
> > >    Support packet-loss rate detection.
> > >    Support "ping" for multicast.
> > >    I suggest address 232.0.0.1 for this one.
> 
> OK, I changed my mind.  This is one that should be "reserved"
> so that no one will ever use it.
> 
> 
> --
>  Hugh LaMaster, M/S 233-21,    Email: lamaster@nren.nasa.gov
>  NASA Ames Research Center     Or:    lamaster@nas.nasa.gov
>  Moffett Field, CA 94035-1000  Or:    lamaster@george.arc.nasa.gov
>  Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.
> 
>