> -----Original Message-----
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 1:52 PM
> 
> > How so?  One can renew multicast addresses.  (Conceivably an
> > implementation could support the ability to automatically renew
> > multicast addresses as long as the unicast address stays valid.)
> 
> Suppose I want to get a multicast address so I can advertise a session
> (e.g., on a web page). I do this two weeks in advance of the event. I
> want the address to last one day only. The key point is that I will
> want to use the address staring two weeks from now.
> 
> However, because unicast lifetimes are only a week, that's too far
> into the future to actually get the address (yet), so the address
> can't be obtained yet. This would seem like it might be a problem.  Is
> it? (I don't know how this scenario fits with the way multicast is
> actually used in IPv4, so this really is a question.)

This is a good question, and in fact it's not multicast specific.
Here's the unicast equivalent:

You're advertising a unicast streaming session on a web page that
will start in two weeks (and last one day).  You use a URL with
a literal unicast address in it.  However, you don't know from 
your RA that your address will definitely be the same by then.
Again, this would seem like it might be a problem.

I think the same dangers and possible solutions exist for both
unicast and multicast.  Some solutions, with varying degrees of
"goodness", might include:
1) Change the web page if the address changes, and hope people
   don't use an out-of-date web page.
2) Don't use address literals in the URL, and hope that people
   don't resolve the name to an address until close to the
   session starts.
3) Make the admin have knowledge somehow that the address
   will indeed be valid throughout the life of the session
   advertised.

The point is that pretty much any solution you use 
for unicast can be used for multicast as well.

-Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to