Subject: RE: uni-based-mcast and malloc-ipv6-guide

From: "Dave Thaler" <[email-masked]>
Date: Mon, 17 Sep 2001 14:38:15 -0700

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> 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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Sep 2001 09:40:25 +0200 (CEST)

> 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

---

From: Bill Manning <[email-masked]>
Date: Tue, 18 Sep 2001 09:38:46 -0700 (PDT)

once they are documented in RFC's they can be added.  

--bill (zone admin for mcast.net)

% 
% 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-masked]
% > --------------------------------------------------------------------
% 

-- 
--bill

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 10:23:44 -0400

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

---

From: George Mitchell <[email-masked]>
Date: Mon, 17 Sep 2001 15:20:42 -0700 (PDT)

> Here's the unicast equivalent:

Unless I'm missing something really obvious, shouldn't you both simply
be advertising a domain name?  Put the address into DNS when the time
comes and everybody will be happy.                    -- George Mitchell