Subject: mboned: take 2 on multicast address discovery

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Feb 2005 21:49:59 +0200 (EET)

Hi,

It seems there hasn't been all that much convergence on multicast 
address discovery.

To focus the discussion, and prepare a basis on which to have 
discussions in Minneapolis, I tried to capture all the four different 
problem statements in an I-D.

It has been posted already, but is available at:
   http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-address-discovery-problems-00.txt

I highlight DaveM's feeling that AFAICS, only by solving the 
inter-site address discovery we can really get to the point where 
there is no need to do static IANA assignment.  The rest seem to be 
interesting ways to deploy new protocols, but in the end probably not 
much more useful than specifying MADCAP was.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Kristoff <[email-masked]>
Date: Fri, 25 Feb 2005 10:11:39 -0600

Catching up...

On Sat, 12 Feb 2005 21:49:59 +0200 (EET)

>    http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-address-discovery-problems-00.txt

In the Abstract, "Typically applications developers have requested static
IANA assignments for the applications ..."

Many of the more recent "problems" have been applications that do not
request IANA assignments.  They often just seem to pick an address or
worse a large netblock out of thin air and use that.

Same comment applies to the Introduction section.

Perhaps also detail the DNS option that Marshall was hinting at a
few times.  On the surface, this seems nice, but I suspect opens
up a can of worms with other sorts of issues (ambiguity of what an
A RR points to between DNS domains for example).

John

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 25 Feb 2005 12:31:13 -0500

On Fri, 25 Feb 2005 10:11:39 -0600
> Perhaps also detail the DNS option that Marshall was hinting at a

I was trying to do more than hint :)

> A RR points to between DNS domains for example).

One of my concerns was to use existing mechanisms as much as possible,
in much the same way as inverse DNS lookup was instituted.

> John

Marshall

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Feb 2005 19:49:25 +0200 (EET)

> Same comment applies to the Introduction section.

Sure.  The text can be tuned, but the same conclusions apply AFAIK.

> A RR points to between DNS domains for example).

This is a solution to a problem, and doesn't belong here (but may 
belong to the follow-up discussion).

Under which problem(s) are you proposing this as a solution?

Could you or Marshall describe the details?  (Please, under a 
different thread.) FWIW, I've gone through some exercises of trying to 
figure out how DNS could be used, but got across some problems 
relating to authorization of DNS dynamic updates, discovery of the 
right zone (by all the parties) and the difficulty for expanding ring 
search.

---

From: John Kristoff <[email-masked]>
Date: Fri, 25 Feb 2005 13:59:30 -0600

On Fri, 25 Feb 2005 19:49:25 +0200 (EET)

> Sure.  The text can be tuned, but the same conclusions apply AFAIK.

Except that quite possibly no solution seems to address that problem,
which is a big one I think, short of deprecating the traditional ASM
model entirely.

> belong to the follow-up discussion).

Hmm... seems to me DNS is the classic address discovery solution.
Perhaps because it is such a divergent approach that it doesn't
belong other than to say "DNS migitation techniques are not explored
in this document".

John

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Feb 2005 08:01:05 +0200 (EET)

> Hmm... seems to me DNS is the classic address discovery solution.

It is classic, yes, but does not solve the multicast address discovery 
problems unless the client and server ends _know_ what they want to 
discover.

For example, how would "dogfight" use DNS?

You might be interested to look at 
draft-palet-v6ops-tun-auto-disc-03.txt, especially section 3.2 for 
DNS, which lists some automatic discovery techniques for a slightly 
different (unicast) purpose.

Would it try to look up:
  - dogfight.somevendor.com? (obviously not)
  - use link-local multicast name resolution
    * works only inside a link, insufficient.
  - dogfight.<DNS search path>, e.g.. dogfight.northwestern.edu ?
    * assumes the clients know the search patch
    * assumes the dogfight administrator can manually add such record,
      or that the server can do it automatically with a DNS update
    * assumes that the DNS folks don't reject such an approach
    * does not work automatically across administrative boundaries
      (problem 4) because the others won't know which domain it is
  - dogfight.4.3.2.1.in-addr.arpa. (or similar in the reverse DNS)
    * see above for inserting the record
    * how would the other nodes know that it's under IP
      address "1.2.3.4" or in general, where to look?
  - something else?

The problem with ASM multicast address discovery is that the client 
and server end don't really know what they're looking for before they 
find it ;-)

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sat, 26 Feb 2005 08:42:09 -0500

Hello;

Just to be clear, I proposed this for the case of multicast "push" services, where
the sender and receiver both know something about each other. I do not necessarily see
this as a solution for the general source discovery case.

I modeled it explicitly on the CDN's, which use DNS for a similar purpose.

I will try to make what I had in mind clear.

Suppose I started a very popular program update service using multicast called, say, Marshall's
Goblin. Now, if I picked and hardcoded an address for this to use, this could be bad.

Instead, we set up a new top-level domain, called multicast, and goblin would be associated with
goblin.multicast or maybe goblin.marshall.multicast.

(Obviously there are a lot of details here, such as should there be a new TLD, how 
is registration done, etc., but they do not change the core of the idea.)

So, a box with the goblin daemon on it binds to goblin.marshall.multicast.
If it finds a class D address behind that domain name, well and good, it uses it to send or 
receive or both, depending on the goblin application. If not, it (should) do nothing.

Now, goblin.marshall.multicast can be (and should be) globally distributed using DNS, by the
application developer (me, in this example). 
However, if the default address that is globally linked to is not convenient to a domain
administrator (for whatever reason) they could replace the global DNS with a local DNS, and
make goblin use whatever (Class D) address they want. Yes, this is something they have to do
manually, but only once. This seems appropriate to me, as the one 
with the problem is the one doing the work. Lots of enterprises have internal and external
DNS already anyway (giving, for example, their web server a NAT'ed address internally).

Of Pekka's problem's, listed below, not one seems to apply, at least to the
problem I was trying to solve. For example, 
"does not work automatically across administrative boundaries",
is not really true - the default will pass domain boundaries. The domain specific DNS should not.

This is NOT intended to solve the general source discovery problem. However, if we develop servers
for multicast SD (using SIP or otherwise), then I could see a use for it, in that there
could be a convention that server.marshall.multicast is the server for the SD for my content. 

Regards
Marshall

On Sat, 26 Feb 2005 08:01:05 +0200 (EET)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Feb 2005 20:21:14 +0200 (EET)

> this as a solution for the general source discovery case.

Ack.

> goblin.multicast or maybe goblin.marshall.multicast.

Sure, though this does not improve the situation much -- IANA would 
still assign a global address because otherwise the DNS name would 
point nowhere by default?

> receive or both, depending on the goblin application. If not, it (should) do nothing.

OK.  A key problem here is, well, a key problem.  Does IANA configure 
the DNS for goblin.marshall.multicast, or do you expect some 
delegation service for marshall.multicast?  Or if not, how do you do 
DNS updates to the root-- securely (keying material?)?

Taking this up a notch, I don't quickly see what benefit there would 
be in goblin.marshall.multicast to begin with (instead of requiring 
one to use goblin.marshall.com or .name).  Or would this just be a 
convenience for IANA so they would have a zone to administer (for 
free) or that multicast app developers wouldn't have to pay 20USD/yr 
to register their own domain name?

> DNS already anyway (giving, for example, their web server a NAT'ed address internally).

Ok, so they could do something like local DNS name hijacking by 
setting the name up as authorative.

> could be a convention that server.marshall.multicast is the server for the SD for my content.

Yes, DNS would not hurt.  The thing I'm having trouble figuring out is 
what benefits do you see in the special xxx.multicast domain, instead 
of apps just using something like name.goblin.com. ?

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 11:19:54 +0100

>DNS updates to the root-- securely (keying material?)?

No, the . (root) returns NXDOMAIN, as the service would not be
available. If the ISP supports it, then the ISP has a 

Though IANA could run .service and preconfigure some default addresses
of course, the ones that are not configured, return a NXDOMAIN or
similar.

>setting the name up as authorative.

Indeed, /me agains offers the .service domain which can be announce by
an ISP, also see the upcoming mail to the v6tc WG.

eg:
goblin.multicast.service.      A    224.3.2.1
dogfight.multicast.service.    A    224.1.2.3
tsp.ipv6.transition.service.   A    192.0.2.6
http.ports.service.            TXT "Hyper Text Transfer Protocol: www"

Very easy to configure with standard tools etc... and if we also define
a IPv4 and IPv6 wellknown DNS server address, that should always have
this, we can easily have OS's configure 2001:db8::53 (whatever IANA
assigns) as the DNS server, which will be authoritive for .service and
will also act a recursive nameserver....

But I already mentioned the above a couple times already of course, but
there seems to be no interest in something quite logical and simple as
the above.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 14:16:41 +0200 (EET)

> http.ports.service.            TXT "Hyper Text Transfer Protocol: www"

This would be in conflict with Beau's original goal, that is, that the 
application must not depend on any servers or configuration of servers 
(e.g., set up of a local .xxx.service. zones).

If IANA would prepopulate these names and manage what they point to 
(by default) the problem would be that you'd be burdening IANA with a 
new task, managing the service DNS entries.

> there seems to be no interest in something quite logical and simple as

This is probably something that should be written up separately from 
the other proposals, and proposed at DNSOP WG, or as a BoF of its own. 
The approach has so many implications that I doubt just one WG (not 
chartered to deal with this kind of generic system) could be able to 
deal with this.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 28 Feb 2005 08:33:36 -0500

Maybe I missed some important message in this thread, but there
already is a high-level DNS anchor for multicast addresses:

tigers:~ brian$ dig ntp.mcast.net

; <<>> DiG 9.2.2 <<>> ntp.mcast.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13682
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3

;; QUESTION SECTION:
;ntp.mcast.net.                 IN      A

;; ANSWER SECTION:
ntp.mcast.net.          604800  IN      A       224.0.1.1

;; AUTHORITY SECTION:
mcast.net.              199127  IN      NS      Strul.stupi.se.
mcast.net.              199127  IN      NS      NS.ISI.EDU.
mcast.net.              199127  IN      NS      NIC.NEAR.net.
mcast.net.              199127  IN      NS      flag.ep.net.

;; ADDITIONAL SECTION:
NIC.NEAR.net.           142212  IN      A       192.52.71.4
Strul.stupi.se.         35430   IN      A       192.108.200.1
Strul.stupi.se.         35430   IN      A       192.36.143.3

The downside I see to this is that it does not play well with the
IPv6 model of having IANA allocate 32-bit group ID's rather than
full addresses (RFC 3306 and 3307).

SSM can be handled by adding Resource Records to the entries
that contain the source address info.

Regards,
Brian

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 14:43:12 +0100

>tigers:~ brian$ dig ntp.mcast.net

   Domain Name: MCAST.NET
   Registrar: INTERNET ASSIGNED NUMBERS AUTHORITY (2)
   Whois Server: whois.iana.org

And it is even run by IANA. Now I am really starting wonder what the
argument against having a well known .service domain is ;)

>> chartered to deal with this kind of generic system) could be able to 

I would support the creation of such a BoF/WG to get the above rolling
as it will solve a lot of bootstrap and configuration problems and would
solve one of the important aspects of IPv6: Plug & Play without Pray.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 16:14:40 +0200 (EET)

On Mon, 28 Feb 2005, Jeroen Massar wrote:
> And it is even run by IANA.

Uh oh.  Not quite.

[whois.iana.org]
Domain mcast.net not found.  Please note that this whois server only provides
information for a very few domains

SOA records seem to indicate it's run by ep.net, courtesy of Bill 
Manning.

I don't know the relationship between IANA and EP.NET, but if I was a 
vendor, I might not be comfortable using xxx.mcast.net for forward 
lookups.

> solve one of the important aspects of IPv6: Plug & Play without Pray.

Sure.  The problem just is, these BoF/WGs never just "come up".  They 
require a lot of hard work, and a lot of people interested in working 
on a subject (writing a problem statement, describing the 
requirements, maybe outlining a solution etc.)

---

From: David Meyer <[email-masked]>
Date: Mon, 28 Feb 2005 06:51:06 -0800

>> information for a very few domains

	FWIW, I've been working with the IANA to clean up
	mcast.net (there are a few dead NS there, etc).

	Dave

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Feb 2005 16:07:03 +0100

> 	mcast.net (there are a few dead NS there, etc).

BTW, is there any chance of getting IPv6 address registered for
sap.mcast.net? I.e.

sap.mcast.net	AAAA	ff0e::2:7ffe

and reverse as well if possible...

Probably some other v6 addresses as well..

Stig

---

From: David Meyer <[email-masked]>
Date: Mon, 28 Feb 2005 07:12:36 -0800

>> Probably some other v6 addresses as well..

	I'll raise it when I meet with the IANA folks in Minn.

	Dave