> 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.
Yes, but for unicast there is a clear possibility of using a hostname instead
of a literal IP address in such a case. In fact I suspect most unicast
usage of this nature uses a hostname.
Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on
web pages, in SDP, etc and have the hosts do a DNS lookup to join the
session?)
Does the malloc architecture take into account using the DNS in
such a way?
Erik
> 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]
--------------------------------------------------------------------
