Subject: draft-manning-multicast-dns-00.txt

From: Randy Bush <[email-masked]>
Date: Sat, 3 Apr 1999 18:34:35 -0800 (PST)

the iesg expects us to look at this.

randy

---

From: Bill Manning <[email-masked]>
Date: Sat, 3 Apr 1999 20:09:19 -0800 (PST)

> the iesg expects us to look at this.

again... 

-- 
--bill

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 4 Apr 99 20:49:09 JST

Randy;

> the iesg expects us to look at this.

But, the proposal is no good.

The basic problem is that almost all the multicast protocol
use broadcast within the multicast domain (FYI, the only
multicast protocol which does not use broadcast use DNS).

The amount of broadcast traffic is proportional to the number
of multicast groups or more.

So, there is no reason not to use administratively scoped
unicast addresses as the well known addresses of default
DNS servers, which also costs broadcast of the routing
information. But, unlike the multicast proposal, the
current software works as is with administratively scoped
unicast addresses.

The security consideration is broken, too. Configuration of
security is far more complex than the configuration of DNS
server addresses. If you need security, you need CONFIGURATION.
Don't bother to autoconfigure DNS.

						Masataka Ohta

PS

Attached is a very rough draft I'm working on about
administratively scoped unicast addresses.

Use of Administratively Scoped Unicast Addresses for DNS

It is possible to allocate administratively scoped
unicast addresses of a limited routing scope such as
a site, a provider.
The addresses can be used as
locally unique well known addresses of default DNS
servers.

.ti 0
1. Introduction

An administratively scoped unicast address can be assigned
to some kind of server uniquely within a certain routing
scope: a site, a provider or an AS. The server may also
have a globally unique unicast address,
which is useful for global communication between servers
with administratively scoped unicast addresses.

To reduce configuration efforts, vendors can configure
their product with the well-known addresses
of the administratively scoped unicast addresses.

Administrators of the scope of the server should control
routers at the boundary of the routing scope so that they
don't import routing informaiton of the administratively
scoped address from the outside of the scope.

If a routing scope does not contain a server with an
administratively scoped unicast address, the scope may
import routing information to the server from the outside
of the scope. If the routing information is imported from
multiple boudary routers, care should be taken that all
the imported routes point to the same server.

Unlike anycast addresses, and like private addresses,
administratively scoped unicast addresses
may be used as source addresses of packets. Bidirectional
communication like TCP works perfectly well between servers with
administratively scoped servers and their clients.

Unlike private addresses,
administratively scoped unicast addresses may have globally unique
well-known DNS names.

.ti 0
2. IANA Assigned Addresses and Names

Anyone who control already or newly assigned unicast
addresses can declare the addresses to be used as
administratively scoped unicast address.

However, for the stability of the assignement, assignements
directly controlled by IANA is desirable and some are listed
in this section.

The following IPv4 addresses are assigned: (XXX (192<=XXX<=223)
and YYY to be assigned by IANA. "asua.int." to be approved
by IANA)

.ti +3
IPv4 Address  Name             Description
------------------------------------------------------------------------
XXX.YYY.0.1   dns0.asua.int.   Default DNS resolver 0
XXX.YYY.1.1   dns1.asua.int.   Default DNS resolver 1
XXX.YYY.2.1   dns2.asua.int.   Default DNS resolver 2
.ti -3

Multiple addresses are assigned to the same service, when
redundant service is desired.

.ti 0
3. Multicast-based Appraoches

There is some approach to archieve the same effect based
on mulitcast addresses.

At first, it seems that such an approach, though a lot more
complex than the approach in this memo, needs less flooding and
is more robust against network failures.

However, so called intra domain multicast protocols are
all based on flooding proportional to (or more than,
in case of MOSPF)
the number of multicast groups. Worse, robustness of multicast
based approach, if any, is a protection at the host level.
End-to-end robustness, which is necessary if a daemon process
dies on a functioning host for example, can not be provided
through routing. Worse, robustness of multicast often means
a weak protection against the newly introduced single point
of failure, such as Core/RP or CBT/PIM-SM, and do not make
sense.

On the other hand, the approach in this memo works without
any modification to the existing protocols, needs minimum
amount of flooding of unicast routing and is robust against
network failures as long as end-to-end bi-directional
communication is possible between a client and one of servers.

.ti 0
4. Security Considerations

Administratively scoped unicast addresses are not protocols
and do not have their
own security issues.

If security is desired on some service using administratively
scoped unicast addresses, it should be
implemented as end-to-end security. However, such security
involves some configuration of security parameters which
renders the effectiveness of the administratively scoped
addresses to make things configurationless.

.ti 0
5. Author's Address

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 6 Apr 99 15:08:12 JST

Randy;

>> The amount of broadcast traffic is proportional to the number of multicast
>> groups or more.
> 
> in what i thought was the principal motivating application, it would be
> proportional to the number of clueless clients searching for a dns server.
> though the draft does get a bit carried away with many other wonderful uses,
> e.g. browsing, which might lead to the problem you suggest.

Most multicast protocols are designed a lot worse than you might
have expected.

Periodic domain wide broadcast is generated to maintain multicast
tree, regardless of whether there is data traffic or not.

With some multicast protocol, the amount of broadcast is proportional
to the number of receivers.

Still, it is not a problem, unless multicast is used extensively.

However, if you try to use multicast for everything including but not
limited to DNS resolution, the number of groups in a domain increases
and the amount of broadcast becomes the problem.

Note that people contaminated by mbone, where there essentially
are only 2 groups, can not recognize the problem, which resulted
in the bogus idea of the administratively scoped multicast.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Mon, 5 Apr 1999 16:24:37 -0700 (PDT)

> server addresses. If you need security, you need CONFIGURATION.

true.

> Don't bother to autoconfigure DNS.

indeed, this has been insufficiently motivated.  to compensate, the proposal
seems to throw the kitchen sink in to make it attractive (dopeler effect?),
service location, browsing, ...  these worry me.

and the expanded wildcard rules will require modification to servers,
despite the craftily worded 'no change to packet format'.  this seems to be
more for discovery and browsing than the basic, and seemingly simple after
all the expansion stuff, server discovery goal.

then there's all the stub DNS servers all over the place.

this all seems tricky and possibly quite messy.

randy