Erik,
I would love to see more usage of DNS for multicast. There
are examples today of mcast addresses being registered in DNS.
Go to your favorite resolver and see what address you get back
when you query all-routers.mcast.net.
I would have to go and check, but I don't recall discussion
of the use of DNS within the MALLOC Architecture. However, it
would seem rather easy to use DDNS to add MAPCAP allocated addresses
to the DNS.
Brian
Erik Nordmark wrote:
>
> > 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
