Subject: AD comments on draft-ietf-zeroconf-reqts-11.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Sep 2002 15:58:37 -0400

I've re-reviewed this document, as the WG has indicated it wants the
IESG to approve publication. Some of these issues are farily minor,
but I think another rev is needed (hopefully quickly!), before I can
put it before the IESG for consideration.

>                     Zeroconf IP Host Requirements

A better title would be nice. One that communicates to the
(non-familiar) reader what the document is about. How about something
like:

    Requirements for Automatic Configuration of IP Hosts

>    Some questions for further discussion:
> 
>    o  Anything else to add here?
> 
>    o  What might be appropriate MUST/SHOULD requirements?
> 
>    o  Do we wish to restrict the operation of specific zeroconf
>       protocols in particular cases (e.g.  the mDNS case, were it is
>       disabled if and DNS configuration information is present)
> 
>    o  Do we wish to imply that zeroconf protocols may only be used to
>       configure IP addresses in specific restricted ranges?  (e.g.
>       private addresses, 169.254/16)
> 
>    o  What about "configured protocols" that may delegate an address or
>       name space to a zeroconf protocol for allocation?

Hmm. Is this section finished?

> 1.5 Routable Protocol Requirement
> 
>    Zeroconf protocols are not inherently limited to a single IP subnet.
>    If a protocol is intended to span multiple IP subnets it MUST NOT use
>    broadcasts or link-local addressing.
> 
>    Requirement:
> 
>    o  Protocols intended to span multiple IP subnets MUST NOT use
>       broadcasts or link-local addressing.

but doesn't the current MDNS document actually restrict usage to
link-local?

> 3.1.1 IPv6 Considerations
> 
>    IPv6 allows a host to select an appropriate IP address and netmask
>    using Stateless Autoconfiguration[RFC2462].  Thus a zeroconf IP
>    interface configuration solution already exists for hosts using IPv6.

not sure I agree. for a single link, yes. But if there are multiple
links/subnets, someone has to configure the routers with
prefixes. This isn't zeroconf-ish. If the above wording is intended to
be limited to link-local, I agree (but then the words should be more
narrowly scoped).

>    o  A zeroconf name resolution protocol MUST support resolution of
>       names that could not previously be resolved.  In particular,
>       probing a desired host name (which does not exist) when joining a
>       network must not prevent the desired hostname from being resolved.

Don't understand what that means.

>    o  A zeroconf name resolution protocol MUST support resolution of
>       names on multiple IP subnets connected by a router.

Not supported today by mdns. And doesn't this imply something about
the link-local addresses not having sufficient utility? I guess I'm
partly confused about whether zeroconf needs to work beyond
link-local or not.

>    o  Hosts using zeroconf name resolution protocols MUST ensure that
>       the use of a desired name will not cause a conflict when moving to
>       a new network or powering up.

wording problem? one can't ensure (in advance) that a name won't cause
a conflict on the next place you move to. Are you trying to say that
you can't claim a name before verifying that the name is not in use?
Can this be folded into the previous requirement:

>    o  A zeroconf name resolution protocol MUST support mechanisms to
>       probe whether a host name is currently in use.

====

>    o  Host names SHOULD be chosen in a way that minimises the
>       probability that two hosts will use the same resource.  Note that
>       this is out of scope of the name resolution protocol itself.

Is wording right above? does "same resource" really mean "same host
name"?

>    Using a zeroconf name resolution protocol to query a DNS name is NOT
>    equivalent to using the DNS protocols to query the same name.  A host
>    using DNS and zeroconf name resolution protocols at the same time
>    MUST NOT allow zeroconf names to mask DNS names.
	
more words? Seems like this is a somewhat cryptic way of saying that
DNS and zeroconf need to coexist in a coherent fashion. Is this
wording also trying to sidestep the detailed discussion about what the
coexistance should look like? Seems like this is an important part of
the problem to understand.

>   source-specific multicast addresses for IPv6, in [SS6].

SS6 is not in the references...

Also, the IPv6 mcast references may need updating anyway to take care
of some relatively new documents: RFC 3306/3307.

> 3.3.2 Address Allocation
> 
>    IP multicast address allocation (local, link-local and site-local
>    scopes only) requires an application to be able to request the use of
>    a suitable multicast address.  Coordination among applications must
>    occur to avoid conflicting allocations of the same address.  This
>    coordination must span the entire scope respective to the address.
>    When an allocated address is no longer required, that address MUST
>    become available for use again.
> 
>    o  MUST select a multicast address.
>

Missing "requirements:" before first bullet? (there is a transition
missing)

> 3.3.4 IPv6 Considerations
> 
>    To date, no range has been reserved for source-specific addresses in
>    IPv6.  See [SS6].  Hence, until such a range is reserved, dynamic
>    allocation of source-specific addresses applies only to IPv4.

Is this true in light of  RFC 3306?

nits:

It would be good to separate references into normative and
non-normative sections.

>   are updated to reflect these changes, and is responsible for ensuring

no comma

>    2, and will be applied to derive requirements for each zeroconf

no comma

Thomas

---

From: Erik Guttman <[email-masked]>
Date: Wed, 11 Sep 2002 22:24:19 +0200 (CEST)

> Hmm. Is this section finished?

This sentence was not supposed to be in the released draft.  Agh!
 
> but doesn't the current MDNS document actually restrict usage to

The current mdns doc is not "intended to span multiple IP subnets."
SLP does span multiple IP subnets and it does not use broadcast
or link-local addressing (though it can be configured to use
broadcast).
 
> be limited to link-local, I agree (but then the words should be more

We don't discuss configuring routers in this document.
 
> Don't understand what that means.

If at first you don't succeed, try and try again.  The first failure
mustn't prevent you from subsequent success.

> the link-local addresses not having sufficient utility? 

I think this is wrong.  I regret I didn't catch this before forwarding
the doc to the IESG.

> I guess I'm

Link local operation is needed.  It is not meant to be a limit.
SLP for example is not limited to link-local.  llmnr in the future
might not be limited to link-local. 
 
> >       probe whether a host name is currently in use.

The requirement is too strictly stated.  What it means is that
if it causes a conflict, the conflict will be resolved in due time.
 
> Is wording right above? does "same resource" really mean "same host

It should be 'the same name,' since we are discussing name
resolution protocol requirements.

Erik

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Sep 2002 16:51:06 -0400

> This sentence was not supposed to be in the released draft.  Agh!

OK

> or link-local addressing (though it can be configured to use

OK.

> We don't discuss configuring routers in this document.

yes, but if the routers must be configured in order for stateless
addrconf to work (which it does for anything other than LL) then
saying IPv6 has a zeroconf address configuration solution seems a bit
misleading.

More precise wording would be something like:

    IPv6 provides a mechanism that allows a host to generate a
    link-local IP address Autoconfiguration[RFC2462].  Thus a zeroconf
    IP interface configuration solution for generating link-local
    addresses already exists for hosts using IPv6.

The point is that obtaining subnet masks and other scopes of addresses
is not exactly a zeroconf operation in practice.

> mustn't prevent you from subsequent success.

Whoa. I don't get that at all from the words in the draft. And I'm
confused about probing failing vs. resolving the name. I'd suggest a
rewrite. I'm still confused about what the problem is the MUST is
trying to fix (so I can't suggest words, yet).

> I think this is wrong.  I regret I didn't catch this before forwarding

Are you saying just remove the  text?

> > I guess I'm partly confused about whether zeroconf needs to work
> > beyond link-local or not.

> might not be limited to link-local.

OK. I think  I understand this point now.

> if it causes a conflict, the conflict will be resolved in due time.

Ok. We need proposed text then.

> resolution protocol requirements.

OK, and thanks for the speedy response!

Thomas

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Sep 2002 18:32:43 -0400

> mustn't prevent you from subsequent success.

It sounds like what you are saying is that hosts/resources/services
can appear at any time, and their names should be usable soon after
they appear.  This would imply for instance not caching the 
results of failed queries.

> if it causes a conflict, the conflict will be resolved in due time.

actually it is entirely possible to ensure  (as a matter of protocol
compliance) that LLMNR won't cause a naming conflict for DNS-style
names, at least to approximately the same extent that DNS ensures this.  
it can be done simply by forbidding a host from answering any LLMNR 
queries from any zone for which that host has not been delegated the 
authority to maintain that zone by the administrator of the DNS
parent zone.    in other words, the host has to have been delegated 
its own zone; then it can modify the zone and act as a server for
that zone.  that won't prevent two hosts from answering to the
same DNS name any more than arp prevents two hosts from answering
to the same IP address, but it would mean that a conflict is a 
violation of the protocol.

OTOH, the idea that 'the network' can 'resolve' a conflict about
resources that don't belong to 'the network' is something that I 
find totally infeasible.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Sep 2002 10:06:26 +1000

> put it before the IESG for consideration.

I can do that pretty quickly, hopefully today.

>     Requirements for Automatic Configuration of IP Hosts.

OK by me.
ACTION: change doc name to the above.

>>   Some questions for further discussion:
[ ... ]
> Hmm. Is this section finished?

Mea culpa -- I removed other similar sections, but missed
this one.

ACTION: remove this section.

> but doesn't the current MDNS document actually restrict usage to

Yes, for now.  Also this document isn't the mDNS document.
The zeroconf charter currently says one router.

I think it would be short-sighted if we did not at least
consider the possibilty of zeroconf name resolution
protocols that would operate in a small routed network.

ACTION: no change.

> be limited to link-local, I agree (but then the words should be more

I see your point.

ACTION: add the word "link-local" as in:

    IPv6 allows a host to select an appropriate link-local IP address
    and netmask using Stateless Autoconfiguration[RFC2462].

> Don't understand what that means.

I'll try to clarify the text.  The idea is supposed to be that
conflict detection probing shouldn't be cached, resulting in
the name being un-resolvable for a while.

> partly confused about whether zeroconf needs to work beyond

Not supported today, but mentioned as a possibility in the draft.

I don't see why zeroconf name can't resolve to something that isn't
a link-local address (e.g. RFC1918, global IPv4 at the IETF, etc).

Again, I think it would be short-sighted if we did not at
least consider the possibilty of zeroconf name resolution
protocols that would operate in a small routed network.

ACTION: change the MUST to a SHOULD

> Can this be folded into the previous requirement:

ACTION: wording change:

    o  A host moving to a new network or powering up MUST ensure that
       all names it will respond to do not conflict with names already
       in use.

> Is wording right above? does "same resource" really mean "same host

Yes.

ACTION: wording change:

     .. that two hosts will use the same host name.

> the problem to understand.

My understanding is that zeroconf name resolution and the
DNS are not the same thing, and are orthogonal.
I have posted to the dnsext mailing list to try and
clarify that, and got one response confirming that point
of view:
   http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01538.html

Keith and others have read this document (in conjunction
with the mDNS/LLMNR document) and have come to different
conclusions.  I shall re-read what is in the requirements
document and clarify it.

> of some relatively new documents: RFC 3306/3307.

ACTION: shall fix

> Missing "requirements:" before first bullet? (there is a transition

ACTION: shall fix

> Is this true in light of  RFC 3306?

Not sure, shall check it out.
Any comments Dave?

OK.

>>   2, and will be applied to derive requirements for each zeroconf

ACTION: press the delete key in the right place.. ;)

-- 

regards
	aidan
____
:wq!

Sydney Network Research Lab             [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://marc.labs.mot.com/snrl/

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Sep 2002 12:22:34 +1000

> the name being un-resolvable for a while.

This is now two seperate requirements:

    	    <t>A zeroconf name resolution protocol MUST support
	    resolution of names that could not previously be
	    resolved.</t>

and slightly later

	    <t>Conflict detection procedures (such as probing for the
	    existence of a a desired host name) MUST NOT prevent the
	    hostname from being resolved.</t>

which I think captures the intent.

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Sep 2002 12:31:12 +1000

>> Is this true in light of  RFC 3306?

RFC3306 specifies the IPv6 SSM address range, so the paragraph
isn't accurate anymore.

draft-ietf-ssm-arch-00.txt says:
(talking about non-IANA allocated SSM addresses)

     The policy for allocating the rest of the SSM addresses to sending
     applications is strictly locally determined by the sending host.

Given that an earlier assumption bullet says:

    o  The node-local and SSM addresses require no protocol or
       interaction between multiple hosts, thus are not mentioned further
       in this document.

I think the text is redundant.

ACTION: remove paragraph

- aidan

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Sep 2002 22:48:50 -0400

> which I think captures the intent.

well, I don't know if I agree.  if multiple hosts are advertising conflicting
information about the same name, this is an error.  in the absence of some 
external information there is no way to "resolve" this conflict, thus the
"host name" resolution should fail rather than lying to the host or application.

at least that's true for a globally-scoped name.  it might be appropriate
for local names to behave differently.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Sep 2002 14:57:51 +1000

> "host name" resolution should fail rather than lying to the host or application.

These haven't changed:

    o  A host moving to a new network or powering up MUST ensure that all
       names it will respond to do not conflict with names already in
       use.

    o  Zeroconf name resolution protocols MUST resolve host name
       conflicts in a timely manner and on an ongoing basis.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 09:11:56 -0400

>        conflicts in a timely manner and on an ongoing basis.

again, if these are global names that are (or could be) used in DNS,
and there's a conflict between the names, something is wrong.  it's 
certainly reasonable to detect such conflicts at the earliest 
opportunity, but "resolving" such conflicts seems infeasible.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 Sep 2002 11:00:22 -0400

> opportunity, but "resolving" such conflicts seems infeasible.

My reading of the intent with these words is that  when two networks
merge, there now may be two (or more) nodes each thinking they own a
particular name. This needs to be detected and resolved, so that only
one node continues to use the name.

This is not the same thing as implying a global name space.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 Sep 2002 11:05:09 -0400

> 	    resolution of names that could not previously be

Still not entirely clear. I think what is meant is that you don't want
to  do negative caching (or at least not for long), as a failure to
resolve in the past, does not mean failure will happen again in the
future. If that is the intent, how about:

     	    <t>Because hosts can connect and disconnect from a network
 	    at any time, name resolution that fails at one point in
 	    time MUST NOT result in a permanent inability to resolve
 	    that name in the future.

Not sure the wording here is quite right, but seems more clear about
the intent (to me)

Thomas

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 12 Sep 2002 10:17:40 -0500

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Aidan Williams" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; <[email-masked]>; "Thomas Narten" <[email-masked]>
Sent: Thursday, September 12, 2002 8:11 AM
Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) 

> opportunity, but "resolving" such conflicts seems infeasible.

..."resolving" such conflicts seems infeasible...

Many things seem infeasible, if code is not being written, and there is no
interest in resolving what some portray as "conflicts".

As one example, look at the emerging managers for 17.IN-ADDR.ARPA.
All 9 can have an opinion, software can take a vote and that particular zone
in the DNS can be tracked...."on an ongoing basis"...

http://www.iana.org/assignments/ipv4-address-space
017/8           Apple Computer Inc.                     Jul 92
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:136     PICTURES
0:137     BBS
0:138     PLACE
0:139     KIDS
0:140     SPACE
0:141     APPRAISERS
0:142     CHANGE
0:143     CREATED
==========================================

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 12 Sep 2002 10:55:05 -0500

----- Original Message ----- 
From: "Jim Fleming" <[email-masked]>
> interest in resolving what some portray as "conflicts".

http://www.sdnbd.org/sdnp/news/cctldtraining_sdnp.htm
http://www.wwtld.org/nameserver/cctld_names_server_training.html
Vietnam : 11 September 2002
Contact person: Vu Xuan Bach  <[email-masked]>
==================

Another example would be how the new 128-bit DNS software is able to look
for key names and remove allocations if they are no longer in use.

IN-ADDR.VN ?

http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=in-addr.vn&Type=255&submit=Lookup

That type of tracking can happen on an "on-going basis". If people are told to
remove zones such as IN-ADDR.VN, then they lose their allocation. That opens
up more space for other people.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 12:02:41 -0400

> This is not the same thing as implying a global name space.

if there's no intent to support use of DNS names or DNS-like names,
and the group is willing to NOT overload existing name lookup APIs, 
I'd like that to be stated explicitly and up-front.  it simplifies 
a number of problems, but it also makes zeroconf incompatible with
existing programs - so I have my doubts that this is the intent.

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 12:05:37 -0400

"permanent" is too long.  how about

	...the failure to resolve a name at some time MUST NOT 
	be taken as an indication that the name will remain invalid
	for any length of time.

if we need to specify a max amount of time, I suggest one minute.

---

From: [email-masked]
Date: Fri, 13 Sep 2002 18:27:27 +0900

>existing programs - so I have my doubts that this is the intent.

	(i know i'm talking about different draft)
	then why "local.arpa" was removed from mDNS/LLMNR document?  indicators
	like "local.arpa" or "local" (used by Apple Rendezvous) is a good
	indication.

itojun

---

From: Aidan Williams <[email-masked]>
Date: Tue, 17 Sep 2002 22:06:32 +1000

Thanks for the text.
I ended up with:

	    <t>Because hosts can connect and disconnect from a network
	    at any time, the failure to resolve a name at some time
	    MUST NOT be taken as an indication that the name will
	    remain invalid for any length of time.</t>

-- 

regards
	aidan
____
:wq!

---

From: Aidan Williams <[email-masked]>
Date: Mon, 23 Sep 2002 16:34:21 +1000

Hi all,

I have written some expanded text on the subject of requirements
for DNS and zeroconf name resolution protocol coexistance.

We have not reached agreement on this.  My intent was to write
up the basic approaches and issues that have been suggested and
call it quits.  If you have objections to what I have written,
can I ask that you provide specific text.  Otherwise I'll end
up trying to read your mind and I'm not very good at that.. ;)

This is the last change arising from list email that I think I
need to do to draft-ietf-zeroconf-reqts-12.txt before submitting
a new rev of the draft.

- aidan

3.2.2 Relationship to the DNS

     Zeroconf name resolution protocols cannot be directly equated with
     the DNS even though they may have a number of similarities.  For
     example, the DNS protocols as deployed today rely on a server
     infrastructure that may not be present in a zeroconf environment.
     Host names used in zeroconf networks are inherently locally scoped
     whereas DNS names are global and unique by design.

     At the time of writing, consensus on how zeroconf name resolution
     protocols should interact with the DNS has not been reached.  The
     next sections will attempt to capture the flavour of the different
     approaches that have been proposed.

3.2.2.1 Close coupling

     In this approach an application may look up a DNS name (e.g.
     "www.someco.com") using an existing API and receive and answer from a
     zeroconf name resolution protocol.  The zeroconf name resolution
     protocol makes use of existing on-the-wire DNS formats, resource
     record definitions, and namespace.  Some names may have a DNS suffix
     that identifies them as being local in scope.

     Issues yet to be resolved with this approach relate to security and
     consistency.  If the zeroconf name resolution involves multicasting
     the request on a local network then the risk of spoofed responses to
     global DNS names like "www.someco.com" is increased.  If the
     namespace is the same, then doing a zeroconf name lookup should
     return results consistent with DNS lookup for the same name.  What is
     meant by this consistency is not agreed.  Should the zeroconf lookup
     only be used when the DNS lookup has failed?  Should that lookup
     reflect what would have been returned by the DNS?  How should the
     probing for uniqueness of a zeroconf name relate to updating of a DNS
     record?

3.2.2.2 Completely orthogonal

     Another approach is to ensure that the zeroconf namespace and the DNS
     namespace are completely orthogonal.  There is therefore no
     possibility of any application using the DNS via existing APIs
     behaving differently after a zeroconf name resolution protocol is
     deployed.  Applications would need to explicitly use a zeroconf name
     lookup API in order to resolve names using a zeroconf lookup
     protocol.  Conversely, existing applications will derive no benefit
     from zeroconf protocols unless they are re-written.  Deployment of a
     zeroconf name resolution protocol would necessitate application
     upgrade.

3.2.2.3 API compatible

     In this approach the zeroconf namespace is distinct from the DNS
     namespace however zeroconf names may be resolved using an existing
     API.  A number of operating systems use generalised name service
     interfaces that transparently allow a variety of name lookup
     protocols to be used to resolve hostnames for applications.  A
     zeroconf name resolution protocol could be incorporated into such a
     system in a straightforward manner as just one more namespace and
     lookup protocol.

     Again, there is increased risk of spoofed responses if the multicast
     zeroconf name resolution protocol is used to resolve
     "www.someco.com".  One possible way of minimising the security risk
     is to ensure that locally scoped names are distinguishable from DNS
     names, perhaps via a known reserved DNS suffix or by virtue of not
     containing a dot.  A multicast zeroconf resolution protocol could
     then avoid making requests for names which look like global DNS
     names.  Alternatively, we could require that zeroconf name lookups
     only be performed when the equivalent DNS lookup has failed.

 > conclusions.  I shall re-read what is in the requirements

Zero Configuration Networking                                A. Williams
Internet-Draft                                                  Motorola
Expires: March 19, 2003                               September 18, 2002

          Requirements for Automatic Configuration of IP Hosts
                    draft-ietf-zeroconf-reqts-12.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 19, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   Many common TCP/IP protocols such as DHCP [RFC2131], DNS
   [RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must be
   configured and maintained by an administrative staff.  This is
   unacceptable for emerging networks such as home networks, automobile
   networks, airplane networks, or ad hoc networks at conferences,
   emergency relief stations, and many others.  Such networks may be
   nothing more than two isolated laptop PCs connected via a wireless
   LAN.  For all these networks, an administrative staff will not exist
   and the users of these networks neither have the time nor inclination
   to learn network administration skills.  Instead, these networks need
   protocols that require zero user configuration and administration.
   This document is part of an effort to define such zero configuration

Williams                 Expires March 19, 2003                 [Page 1]

Internet-Draft            Zeroconf Requirements           September 2002

   (zeroconf) protocols.

   Before embarking on defining zeroconf protocols, protocol
   requirements are needed.  This document states the zeroconf protocol
   requirements for four protocol areas; they are: IP interface
   configuration, translation between host name and IP address, IP
   multicast address allocation, and service discovery.  This document
   does not define specific protocols, just requirements.   The
   requirements for these four areas result from examining everyday use
   or scenarios of these protocols.

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1     Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2     Reading This Document  . . . . . . . . . . . . . . . . . .  4
   1.3     Zeroconf Coexistence . . . . . . . . . . . . . . . . . . .  5
   1.4     Scalability  . . . . . . . . . . . . . . . . . . . . . . .  5
   1.5     Routable Protocol Requirement  . . . . . . . . . . . . . .  5
   1.6     Maintaining Consistent Network State . . . . . . . . . . .  6
   2.      Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1     Addition and Removal of Devices  . . . . . . . . . . . . .  6
   2.2     Network Coalescing and Partitioning  . . . . . . . . . . .  7
   3.      Requirements . . . . . . . . . . . . . . . . . . . . . . .  8
   3.1     IP Interface Configuration . . . . . . . . . . . . . . . .  8
   3.1.1   IPv6 Considerations  . . . . . . . . . . . . . . . . . . . 10
   3.2     Translation between Host name and IP Address . . . . . . . 10
   3.2.1   IPv6 Considerations  . . . . . . . . . . . . . . . . . . . 11
   3.2.2   Relationship to the DNS  . . . . . . . . . . . . . . . . . 11
   3.2.2.1 Close coupling . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.2.2 Completely orthogonal  . . . . . . . . . . . . . . . . . . 12
   3.2.2.3 API compatible . . . . . . . . . . . . . . . . . . . . . . 12
   3.3     IP Multicast Address Allocation Scenarios  . . . . . . . . 13
   3.3.1   Scope Enumeration  . . . . . . . . . . . . . . . . . . . . 14
   3.3.2   Address Allocation . . . . . . . . . . . . . . . . . . . . 14
   3.3.3   Multiple Sources . . . . . . . . . . . . . . . . . . . . . 15
   3.3.4   IPv6 Considerations  . . . . . . . . . . . . . . . . . . . 15
   3.4     Service Discovery Scenarios  . . . . . . . . . . . . . . . 15
   3.4.1   Printer Service  . . . . . . . . . . . . . . . . . . . . . 16
   3.4.2   IPv6 Considerations  . . . . . . . . . . . . . . . . . . . 16
   4.      Security Considerations  . . . . . . . . . . . . . . . . . 16
   4.1     The Basic in/out Security Policy . . . . . . . . . . . . . 17
   4.2     Security Scenarios . . . . . . . . . . . . . . . . . . . . 18
   4.2.1   Use on an isolated, secure network link  . . . . . . . . . 18
   4.2.2   Use on a shared (insecure) link  . . . . . . . . . . . . . 18
   4.2.3   Use in conjunction with configured protocols . . . . . . . 18
   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 19

Williams                 Expires March 19, 2003                 [Page 2]

Internet-Draft            Zeroconf Requirements           September 2002

           Normative References . . . . . . . . . . . . . . . . . . . 19
           Informative References . . . . . . . . . . . . . . . . . . 19
           Author's Address . . . . . . . . . . . . . . . . . . . . . 21
           Full Copyright Statement . . . . . . . . . . . . . . . . . 22

Williams                 Expires March 19, 2003                 [Page 3]

Internet-Draft            Zeroconf Requirements           September 2002

1. Introduction

   A zeroconf protocol is able to operate correctly in the absence of
   configured information from either a user or infrastructure services
   such as conventional DHCP [RFC2131] or DNS [RFC1034][RFC1035]
   servers.  Zeroconf protocols may use configured information, when it
   is available, but do not rely on it being present.  For example, the
   use of MAC addresses (i.e.  layer two addresses) as parameters in
   zeroconf protocols is generally acceptable because they are globally
   unique and readily available on most devices of interest.

   The benefits of zeroconf protocols over existing configured protocols
   are an increase in the ease-of-use for end-users and a simplification
   of the infrastructure necessary to operate protocols.

   This document discusses requirements for zeroconf protocols in four
   areas:

   o  IP interface configuration

   o  Translation between host name and IP address

   o  IP multicast address allocation

   o  Service discovery

   Security considerations are also discussed.

1.1 Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2 Reading This Document

   Introduction, Scenarios, Requirements, and Security Considerations
   are the major sections of this document.

   The Scenarios & Requirements sections walk through protocol scenarios
   and then lists the requirements of the protocol needed to accomplish
   the scenario.

   The Security Consideration section lists security issues with
   zeroconf protocols.

   Requirements dispersed throughout this document begin with the text
   "Requirements:" or "Requirement:" on a single line, which is followed

Williams                 Expires March 19, 2003                 [Page 4]

Internet-Draft            Zeroconf Requirements           September 2002

   by a bulleted list of requirements.

1.3 Zeroconf Coexistence

   It is not necessary to simultaneously use zeroconf protocols in all
   four areas (i.e.  IP interface configuration, translation between
   host name and IP address, IP multicast address allocation, service
   discovery).  For example, it may make sense on some networks to
   provide a DHCP server for configured IP interface configuration, but
   perform translation between host name and IP address using a zeroconf
   protocol.

   Given that zeroconf protocols may be deployed on existing configured
   networks, care must be taken in their design to ensure minimum
   disruption to existing networks and applications.  Particular
   consideration should be given to the security implications of
   deploying zeroconf protocols in conjunction with standard configured
   network protocols.

   Requirements:

   o  Zeroconf protocols SHOULD minimise their impact on existing
      networks

   o  Zeroconf protocols SHOULD minimise impact on existing
      applications.

   o  Zeroconf protocols MUST NOT be any less secure than related
      current IETF-Standard protocols.

1.4 Scalability

   The primary reasons to deploy Zeroconf protocols are simplicity and
   ease-of-use.  Scalability is important but it is a secondary goal.
   Thus, scalability should not detract from the primary goals of
   simplicity and ease-of-use.

   Requirement:

Williams                 Expires March 19, 2003                 [Page 5]

Internet-Draft            Zeroconf Requirements           September 2002

1.6 Maintaining Consistent Network State

   Many networks undergo change during their lifetime.  For example,
   hosts may be added and removed, network segments may be re-arranged,
   and devices may change names or run different services.  In a
   configured network an administrator ensures that protocol parameters
   are updated to reflect these changes and is responsible for ensuring
   network consistency.

   In contrast, zeroconf protocols must adapt to changing network
   conditions.  Zeroconf protocols must be able to resolve conflicts and
   return the network to a consistent state after changes in network
   topology or other events.

   Requirement:

   o  Zeroconf protocols MUST restore the network to a consistent state
      in a timely fashion when changes in network topology or other
      events occur.

   This is a general requirement applicable to all zeroconf protocols.
   It should be kept in mind when considering the scenarios in Section 2
   and will be applied to derive requirements for each zeroconf protocol
   area considered in Section 3.

2. Scenarios

   The scenarios described in the next few sections highlight the
   general characteristics of the zeroconf protocol environment.  Each
   zeroconf protocol needs to deal with the following aspects of the
   zeroconf environment.

2.1 Addition and Removal of Devices

   Zeroconf protocols are expected to be useful in networks where hosts
   come and go.  Hosts using zeroconf protocols must not assume that
   network resources assigned to them (e.g.  address assignments, names,
   etc) will be appropriate for networks they subsequently join.  In
   addition, network resources allocated to a host should be reclaimed
   once it leaves the network.

   Requirements:

   o  Zeroconf protocols MUST support mechanisms to probe whether a
      network resource is currently in use.

   o  Hosts using zeroconf protocols MUST validate allocated network
      resources when moving to a new network or powering up.

Williams                 Expires March 19, 2003                 [Page 6]

Internet-Draft            Zeroconf Requirements           September 2002

   o  Zeroconf protocols MUST support timely reclamation of any network
      resources they allocate.

   Implication:

   o  The information needed to allocate network resources must arrive
      in the network along with the host.

2.2 Network Coalescing and Partitioning

   Inevitably, two or more operational networks using zeroconf protocols
   will be connected together, creating a single merged network.  Prior
   to the merge, each zeroconf network has independently allocated
   resources (e.g.  addresses, names, etc).  After merging, two hosts in
   the merged network may end up using the same network resource, thus
   potentially creating conflicts.

   In general a network merge "event" cannot be detected.  For example,
   the installation of a layer-2 bridge between two zeroconf networks
   does not result in network interfaces going up and down on the hosts,
   which would be an indication that they should re-validate or
   reconfigure the network resources they are using.

   Implication:

   o  It is not sufficient to rely on hosts detecting conflicts during
      power on or movement from network to network.  Rather, detection
      and resolution of network conflicts is an ongoing part of zeroconf
      protocol operation.

   Requirement:

   o  Zeroconf protocols MUST resolve network resource conflicts in a
      timely manner and on an ongoing basis.

   Zeroconf protocols that detect and resolve network resource conflicts
   on an ongoing basis will benefit from increased robustness in the
   face of poor implementation, and varying network conditions.

   A zeroconf network may also be split into two or more smaller
   independent networks.  The requirement from Section 2.1 that network
   resources be reclaimed in a timely fashion also applies in this case.
   Since network merging increases the potential for network conflicts,
   it may be prudent to ensure that network resources associated with
   hosts are not immediately re-claimed for re-use.  Any network which
   periodically joins and partitions with another zeroconf network will
   benefit from this behaviour.  An example is an IP network in a car

Williams                 Expires March 19, 2003                 [Page 7]

Internet-Draft            Zeroconf Requirements           September 2002

   joining with the home network whilst the car is parked in the garage
   and partitioning when it is driven away.

   Requirement:

   o  Zeroconf protocols SHOULD NOT immediately reuse network resources
      as soon as they become available.

   o  Network resources SHOULD be allocated in a way that minimises the
      probability that two hosts will be allocated the same resource.

   o  Network resources SHOULD be allocated in a way that increases the
      chances of a particular host being allocated the same resource
      should it leave and rejoin the network.

3. Requirements

   This section contains a subsection for each of the four protocol
   areas.  Within each subsection, terms and assumptions are followed by
   specific zeroconf protocol requirements in that area.  Each
   subsection ends with IPv6 considerations.

3.1 IP Interface Configuration

   In this document, IP interface configuration always includes the
   configuration of an IP address and netmask; it may include some
   routing information (such as default route).  IP interface
   configuration is needed before almost any IP communication can take
   place.

   Terms:

   IP subnet: A single logical IP network that may span multiple link
      layer networks.  All IP hosts on the IP subnet communicate without
      any layer 3 forwarding device (e.g.  router).

   internetwork: Multiple IP subnets connected by routers.

   network: a context sensitive term that may apply to one or more of
      the terms: a link layer network, an IP subnet, or an internetwork.

   bridge: a networking device that connects two link layer networks by
      using only link-layer protocols (e.g.  Ethernet).

   IP interface configuration must take place before an IP packet can be
   sent from one host to another.  This section requires that sufficient
   information be provided by a zeroconf interface configuration

Williams                 Expires March 19, 2003                 [Page 8]

Internet-Draft            Zeroconf Requirements           September 2002

   protocol to allow IP packets to be sent to a unicast destination IP
   address on the same subnet as the sender, and on a different subnet
   to the sender.

   Requirements: A zeroconf IP interface configuration protocol

   o  MUST configure an appropriate netmask.

   o  MUST allocate unique IP addresses within an IP subnet.

   o  MUST allow configuration of zero or more gateways (for the
      internetwork scenario).

   o  MUST have unique IP subnets within an internetwork (This is only
      for the case when there is one or more router attached in the
      network where autoconfigured hosts.  How routers obtain their
      configuration is beyond of the scope of this document.)

   The following requirements are derived from applying Section 2.1 and
   Section 2.2 to IP interface configuration.

   Requirements: A zeroconf IP interface configuration protocol

   o  MUST be capable of discovering whether an IP address is currently
      in use.

   o  Hosts using a zeroconf interface configuration protocol MUST
      validate allocated IP addresses when moving to a new network or
      powering up.

   o  MUST support timely reclamation of allocated IP addresses.

   o  MUST resolve IP address conflicts in a timely manner and on an
      ongoing basis.

   o  SHOULD NOT immediately reuse IP addresses as soon as they become
      available.

   o  IP addresses SHOULD be allocated in a way that minimises the
      probability that two hosts will be allocated the same address.

   o  IP addresses SHOULD be allocated in a way that increases the
      chances of a particular host being allocated the same address
      should it leave and rejoin the network.

Williams                 Expires March 19, 2003                 [Page 9]

Internet-Draft            Zeroconf Requirements           September 2002

   IPv6 provides a mechanism that allows a host to generate a link-local
   IP address Autoconfiguration[RFC2462].  Thus a zeroconf IP interface
   configuration solution for generating link-local addresses already
   exists for hosts using IPv6.

3.2 Translation between Host name and IP Address

   A zeroconf name resolution protocol allows users to refer to their
   devices by name rather than IP address.  Host names are more user
   friendly than IP addresses and host names have a greater chance of
   remaining unchanged over time.  A zeroconf device connected to
   different networks is quite likely to use different IP addresses,
   however a host name may stay the same.  For applications like web
   browsers which store bookmarks and histories, use of names rather
   than IP addresses is beneficial.

   In a zeroconf network, the information required to construct a host
   name must enter the network with the device.  It is expected that
   users will configure names into devices, or that devices will come
   with a pre-configured name.  Devices may also construct a name from a
   MAC address or serial number.  How this is to be achieved is outside
   the scope of this document.

   Terms:

   host name: A textual name that allows a user to refer to a host by
      name rather than IP address.

   Requirements:

   o  A zeroconf name resolution protocol MUST allow host names to be
      mapped into IP addresses.

   o  A zeroconf name resolution protocol SHOULD allow IP addresses to
      be mapped back to names.

   o  Because hosts can connect and disconnect from a network at any
      time, the failure to resolve a name at some time MUST NOT be taken
      as an indication that the name will remain invalid for any length
      of time.

   o  A zeroconf name resolution protocol SHOULD support resolution of
      names on multiple IP subnets connected by a router.

   The following requirements are derived from applying Section 2.1 and
   Section 2.2 to zeroconf name resolution.

Williams                 Expires March 19, 2003                [Page 10]

Internet-Draft            Zeroconf Requirements           September 2002

   Requirements:

   o  Zeroconf name resolution protocols MUST allow timely re-use of
      hostnames.

   o  Conflict detection procedures (such as probing for the existence
      of a desired host name) MUST NOT prevent valid hostnames from
      being resolved.

   o  Zeroconf name resolution protocols SHOULD NOT immediately reuse
      host names as soon as they become available.

   o  Host names SHOULD be chosen in a way that minimises the
      probability that two hosts will use the same name.  Note that this
      is out of scope of the name resolution protocol itself.

3.2.1 IPv6 Considerations

   Protocols to perform translation between host name and IP address
   have no known zeroconf-related differences for IPv4 and IPv6.

3.2.2 Relationship to the DNS

   Zeroconf name resolution protocols cannot be directly equated with
   the DNS even though they may have a number of similarities.  For
   example, the DNS protocols as deployed today rely on a server
   infrastructure that may not be present in a zeroconf environment.
   Host names used in zeroconf networks are inherently locally scoped
   whereas DNS names are global and unique by design.

   At the time of writing, consensus on how zeroconf name resolution
   protocols should interact with the DNS has not been reached.  The
   next sections will attempt to capture the flavour of the different
   approaches that have proposed.

Williams                 Expires March 19, 2003                [Page 11]

Internet-Draft            Zeroconf Requirements           September 2002

3.2.2.1 Close coupling

   In this approach an application may look up a DNS name (e.g.
   "www.someco.com") using an existing API and receive and answer from a
   zeroconf name resolution protocol.  The zeroconf name resolution
   protocol makes use of existing on-the-wire DNS formats, resource
   record definitions, and namespace.  Some names may have a DNS suffix
   that identifies them as being local in scope.

   Issues yet to be resolved with this approach relate to security and
   consistency.  If the zeroconf name resolution involves multicasting
   the request on a local network then the risk of spoofed responses to
   global DNS names like "www.someco.com" is increased.  If the
   namespace is the same, then doing a zeroconf name lookup should
   return results consistent with DNS lookup for the same name.  What is
   meant by this consistency is not agreed.  Should the zeroconf lookup
   only be used when the DNS lookup has failed?  Should that lookup
   reflect what would have been returned by the DNS?  How should the
   probing for uniqueness of a zeroconf name relate to updating of a DNS
   record?

3.2.2.2 Completely orthogonal

   Another approach is to ensure that the zeroconf namespace and the DNS
   namespace are completely orthogonal.  There is therefore no
   possibility of any application using the DNS via existing APIs
   behaving differently after a zeroconf name resolution protocol is
   deployed.  Applications would need to explicitly use a zeroconf name
   lookup API in order to resolve names using a zeroconf lookup
   protocol.  Conversely, existing applications will derive no benefit
   from zeroconf protocols unless they are re-written.  Deployment of a
   zeroconf name resolution protocol would necessitate application
   upgrade.

3.2.2.3 API compatible

   In this approach the zeroconf namespace is distinct from the DNS
   namespace however zeroconf names may be resolved using an existing
   API.  A number of operating systems use generalised name service
   interfaces that transparently allow a variety of name lookup
   protocols to be used to resolve hostnames for applications.  A
   zeroconf name resolution protocol could be incorporated into such a
   system in a straightforward manner as just one more namespace and
   lookup protocol.

   Again, there is increased risk of spoofed responses if the multicast
   zeroconf name resolution protocol is used to resolve
   "www.someco.com".  One possible way of minimising the security risk

Williams                 Expires March 19, 2003                [Page 12]

Internet-Draft            Zeroconf Requirements           September 2002

   is to ensure that locally scoped names are distinguishable from DNS
   names, perhaps via a known reserved DNS suffix or by virtue of not
   containing a dot.  A multicast zeroconf resolution protocol could
   then avoid making requests for names which look like global DNS
   names.  Alternatively, we could require that zeroconf name lookups
   only be performed when the equivalent DNS lookup has failed.

3.3 IP Multicast Address Allocation Scenarios

   IP Multicast is used to conserve bandwidth for multi-receiver bulk-
   delivery applications, such as audio, video, or news.

   IP Multicast is also used to perform a logical addressing function.
   For example, when a host needs to communicate with local routers, it
   can send packets to the all-routers multicast address without having
   to know in advance the IP address(es) of the router(s).

   IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255.

   [RFC2365] defined multicast scopes are:

        node-local           (unspecified for IPv4)
        link-local           (224.0.0.0/24)
        local                (239.255.0.0/16)
        site-local           (unspecified for IPv4)
        organizational-local (239.192.0.0/14)
        global               (224.0.1.0-238.255.255.255)

   A relative assignment is an integer offset from the highest address
   in the scope and represents a 32-bit address.  For example, within
   the local scope, 239.255.255.0/24 is reserved for relative
   allocations.

   Source-Specific Multicast addresses are 232.0.0.0 to 232.255.255.255
   [I-D.ietf-ssm-arch].

   Unicast-prefix-based IPv6 multicast addresses are defined, as well as
   source-specific multicast addresses for IPv6[RFC3306].

   Assumptions:

   o  Global and organizational scoped addresses are meant for networks
      of a greater scale than zeroconf protocols, thus are not mentioned
      further in this document.

Williams                 Expires March 19, 2003                [Page 13]

Internet-Draft            Zeroconf Requirements           September 2002

   o  Only local, link-local and site-local scopes are considered
      further in this document.

   o  If it is desirable to restrict multicast packets from entering and
      leaving a multicast scope boundary, it is assumed that the router
      at the boundary is a "boundary router" as described in [RFC2365].

   Scenarios are scope enumeration, address allocation, and multiple
   sources.

3.3.1 Scope Enumeration

   Applications that leave the choice of scope up to the user require
   the ability to enumerate what scopes the host is operating within.
   In addition, services that are assigned relative addresses require
   the ability to enumerate what scopes the host is within; only then
   will a host be able to apply the relative address to a scope.

   Requirements: Application support software used to autoconfigure
   multicast addresses

   o  MUST list which of the scopes (local, link-local, or site-local)
      are available for hosts.

   o  MUST list per-scope address ranges that may be allocated.

3.3.2 Address Allocation

   Requirements: A zeroconf multicast address allocation protocol

   o  MUST prevent conflicting allocations of the same address.

   o  MUST allow the multicast address to become available after the
      address is no longer in use.

Williams                 Expires March 19, 2003                [Page 14]

Internet-Draft            Zeroconf Requirements           September 2002

3.3.3 Multiple Sources

   An intercom system inside a home is an example of a multiple source
   IP multicast application.  In this type of application, several
   sources may be sending packets destined to the same IP multicast
   address.

   This multiple source example illustrates the problem that a
   particular address may continue to be valid, even after the host that
   initially allocated the address is no longer present; the zeroconf
   multicast address allocation must correctly support this type of
   operation.  In other words, if a host allocates a multicast address,
   then leaves the multicast group, some other host must defend the
   address.

   Requirements:

   o  A host other than the allocating host MUST be able to defend or
      otherwise maintain the allocation of a multicast address.

   To date, no range has been reserved for dynamic allocation of Link-
   scoped addresses in IPv4.  Hence, unless such a range is reserved,
   dynamic allocation of link-scoped addresses applies only to IPv6.

3.4 Service Discovery Scenarios

   Service discovery protocols allow users or software to discover and
   select among available services.  This removes the requirement that
   the user or client software know a server's location in advance in
   order for the client to communicate with the server.

   Terms:

   service: a particular logical function that may be invoked via some
      network protocol, such as printing, storing a file on a remote
      disk, or even perhaps requesting delivery of a pizza.

   service characteristics: Characteristics provide a finer granularity
      of description to differentiate services beyond just the service
      type.  For example if the service type is printer, the
      characteristics may be color, pages printed per second, location,
      etc.

   service discovery protocol: A service discovery protocol enables
      clients to discover servers (or peers to find other peers) of a

Williams                 Expires March 19, 2003                [Page 15]

Internet-Draft            Zeroconf Requirements           September 2002

      particular service.  A service discovery protocol is an
      application layer protocol that relies on network and transport
      protocol layers.

   service protocol: A service protocol is used between the client and
      the server after service discovery is complete.

   The scenarios are the discovery of a simple printer service.

3.4.1 Printer Service

   Network-enabled printers allow various network clients to submit
   print jobs.  A service discovery protocol MUST allow a printer
   service to be discovered by devices needing to print.  This requires
   a service type as well as a service identifier to distinguish
   instances of a single service type.  Service discovery MUST be
   independent from any particular printing protocol such as lpd, raw-
   tcp, ipp.

   Printers vary in their characteristics such as location, status, dots
   per inch, etc.  Discovering a service based on these characteristics
   SHOULD be part of the service discovery protocol.

   Service discovery MUST complete in a timely (10s of seconds) manner.

   Requirements:

   o  MUST allow a service to be discovered.

   o  MUST discover via service identifier and/or service type.

   o  MUST discover services without use of a service-specific protocol.

   o  SHOULD discover via service characteristics.

   o  MUST complete in a timely (10s of seconds) manner.

3.4.2 IPv6 Considerations

   Service discovery protocols have no zeroconf related differences for
   IPv4 and IPv6.

4. Security Considerations

   Zeroconf protocols are intended to operate in a local scope, in
   networks containing one or more IP subnets, and potentially in
   parallel with standard configured network protocols.

Williams                 Expires March 19, 2003                [Page 16]

Internet-Draft            Zeroconf Requirements           September 2002

   Application protocols running on networks employing zeroconf
   protocols will be subject to the same sets of security issues
   identified for standard configured networks.  Examples are: denial of
   service due to the unauthenticated nature of IPv4 ARP and lack of
   confidentiality unless IPSec-ESP, TLS, or similar is used.  However,
   networks employing zeroconf protocols do have different security
   characteristics and the subsequent sections attempt to draw out some
   of the implications.

   Security schemes usually rely on some sort of configuration.
   Security mechanisms for zeroconf network protocols should be designed
   in keeping with the spirit of zeroconf, thus making it easy for the
   user to exchange keys, set policy, etc.  It is preferable that a
   single security mechanism be employed that will allow simple
   configuration of all the various security parameters that may be
   required.

   Generally speaking, security mechanisms in IETF protocols are
   mandatory to implement.  A particular implementation might permit a
   network administrator to turn off a particular security mechanism
   operationally.  However, implementations should be "secure out of the
   box" and have a safe default configuration.

   Zeroconf protocols MUST NOT be any less secure than related current
   IETF-Standard protocols.  This consideration overrides the goal of
   allowing systems to obtain configuration automatically.  Security
   threats to be considered include both active attacks (e.g.  denial of
   service) and passive attacks (e.g.  eavesdropping).  Protocols that
   require confidentiality and/or integrity should include integrated
   confidentiality and/or integrity mechanisms or should specify the use
   of existing standards-track security mechanisms (e.g.  TLS [RFC2246],
   ESP [RFC1827], AH [RFC2402]) appropriate to the threat.

4.1 The Basic in/out Security Policy

   The claim/collide approach to resource allocation is attractive in
   the zeroconf environment.  To operate securely, hosts allocating
   resources need to ensure that messages indicating that a network
   resource is in use are authenticated.  Hosts soliciting for a name or
   service must also be able to authenticate the responses they receive.
   A message is considered "authenticated" if it can be proved to have
   been sent by a member of a group of devices running zeroconf
   protocols.  Note that in general, devices running zeroconf protocols
   must trust the other devices in the group because any device may
   claim to be using an address or name, or advertising a service.
   Zeroconf security mechanisms must at a minimum be able to distinguish
   between messages originating from a device "inside" the group or a
   device "outside" the group.

Williams                 Expires March 19, 2003                [Page 17]

Internet-Draft            Zeroconf Requirements           September 2002

   Requirement:

   o  Security schemes for zeroconf protocols MUST be able to implement
      a basic "inside/outside" security policy.

   Access control mechanisms within a zeroconf network are beyond the
   scope of this document.

4.2 Security Scenarios

   In the next few sections, several scenarios are examined to highlight
   the security implications of employing zeroconf protocols in various
   environments.

4.2.1 Use on an isolated, secure network link

   In this scenario all the devices in the network are connected to a
   secure link (e.g.  a control network in a car, or a private network
   between two devices used for configuration).  The link might be a
   separate physical wire or shared media with layer-2 security enabled
   (e.g.  wireless or power-line networks).  Any host that has access to
   the link is trusted and any packet received from the secure link is
   considered to be authenticated.  In this case, the inside/outside
   policy is implemented by controlling access to the link itself.

4.2.2 Use on a shared (insecure) link

   In this scenario, a group of devices use zeroconf protocols on
   link(s) they share with other devices who are NOT part of the group.
   Various pieces of network configuration MUST be consistent across all
   hosts sharing the link (e.g.  addresses, netmask, routing
   information) in order for communication to occur at all.
   Consequently, hosts inside the group are potentially at risk from
   hosts outside their group when they try to configure such information
   (e.g.  via ARP insecurity).  Host names and service identifiers MUST
   be unique within a group, but with authentication may not need to be
   unique across the link.  Assuming that requests and responses can be
   associated with a group and authenticated, solicitations and
   responses for host names and services that are not located inside the
   group can be ignored.

4.2.3 Use in conjunction with configured protocols

   Zeroconf protocols are likely to be used in conjunction with
   configured network protocols.  In general, zeroconf protocols must
   not allocate resources from the same address or name spaces used by
   configured network protocols.  Locally allocated zeroconf network
   resources must not mask global assigned resources.

Williams                 Expires March 19, 2003                [Page 18]

Internet-Draft            Zeroconf Requirements           September 2002

5. IANA Considerations

   No known IANA considerations arise from this document.

6. Acknowledgments

   Thanks to Peter Ford and Stuart Cheshire for hosting the NITS
   (Networking In The Small) BOF that was the catalyst to forming the
   Zeroconf Working Group.

   Thanks to Erik Guttman and Stuart Cheshire for forming and chairing
   the Zeroconf Working Group, which is responsible for this document.

   Thanks to Erik Guttman for providing key input to the service
   discovery and the security sections.

   Thanks to Dave Thaler for providing key input to the IP multicast
   address allocation sections.

   Thanks to Stuart Cheshire for providing key input to the introduction
   and IP interface configuration sections.

   Thanks to Myron Hattig for acting as editor for previous versions of
   this document.

   Additional recognition goes the following people for their
   influential contributions to this document and its predecessors:
   Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn,
   John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach,
   Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard
   Aboba, Ran Atkinson.

Normative References

Informative References

   [I-D.ietf-ssm-arch]  Cain, B. and H. Holbrook, "Source-Specific
                        Multicast for IP", draft-ietf-ssm-arch-00 (work
                        in progress), February 2002.

   [RFC0826]            Plummer, D., "Ethernet Address Resolution
                        Protocol: Or converting network protocol
                        addresses to 48.bit Ethernet address for
                        transmission on Ethernet hardware", STD 37, RFC
                        826, November 1982.

   [RFC1034]            Mockapetris, P., "Domain names - concepts and
                        facilities", STD 13, RFC 1034, November 1987.

Williams                 Expires March 19, 2003                [Page 19]

Internet-Draft            Zeroconf Requirements           September 2002

   [RFC1035]            Mockapetris, P., "Domain names - implementation
                        and specification", STD 13, RFC 1035, November
                        1987.

   [RFC1123]            Braden, R., "Requirements for Internet Hosts -
                        Application and Support", STD 3, RFC 1123,
                        October 1989.

   [RFC1827]            Atkinson, R., "IP Encapsulating Security Payload
                        (ESP)", RFC 1827, August 1995.

   [RFC2026]            Bradner, S., "The Internet Standards Process --
                        Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC2119]            Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14, RFC 2119,
                        March 1997.

   [RFC2131]            Droms, R., "Dynamic Host Configuration
                        Protocol", RFC 2131, March 1997.

   [RFC2246]            Dierks, T., Allen, C., Treese, W., Karlton, P.,
                        Freier, A. and P. Kocher, "The TLS Protocol
                        Version 1.0", RFC 2246, January 1999.

   [RFC2251]            Wahl, M., Howes, T. and S. Kille, "Lightweight
                        Directory Access Protocol (v3)", RFC 2251,
                        December 1997.

   [RFC2365]            Meyer, D., "Administratively Scoped IP
                        Multicast", BCP 23, RFC 2365, July 1998.

   [RFC2401]            Kent, S. and R. Atkinson, "Security Architecture
                        for the Internet Protocol", RFC 2401, November
                        1998.

   [RFC2402]            Kent, S. and R. Atkinson, "IP Authentication
                        Header", RFC 2402, November 1998.

   [RFC2461]            Narten, T., Nordmark, E. and W. Simpson,
                        "Neighbor Discovery for IP Version 6 (IPv6)",
                        RFC 2461, December 1998.

   [RFC2462]            Thomson, S. and T. Narten, "IPv6 Stateless
                        Address Autoconfiguration", RFC 2462, December
                        1998.

   [RFC2535]            Eastlake, D., "Domain Name System Security

Williams                 Expires March 19, 2003                [Page 20]

Internet-Draft            Zeroconf Requirements           September 2002

                        Extensions", RFC 2535, March 1999.

   [RFC2541]            Eastlake, D., "DNS Security Operational
                        Considerations", RFC 2541, March 1999.

   [RFC2608]            Guttman, E., Perkins, C., Veizades, J. and M.
                        Day, "Service Location Protocol, Version 2", RFC
                        2608, June 1999.

   [RFC2730]            Hanna, S., Patel, B. and M. Shah, "Multicast
                        Address Dynamic Client Allocation Protocol
                        (MADCAP)", RFC 2730, December 1999.

   [RFC2931]            Eastlake, D., "DNS Request and Transaction
                        Signatures ( SIG(0)s)", RFC 2931, September
                        2000.

   [RFC3306]            Haberman, B. and D. Thaler, "Unicast-Prefix-
                        based IPv6 Multicast Addresses", RFC 3306,
                        August 2002.

Author's Address

   Aidan Williams
   Motorola Australian Research Centre
   Locked Bag 5028
   Botany, NSW  1455
   Australia

   Phone: +61 2 9666 0500
   EMail: [email-masked]
   URI:   http://www.motorola.com.au/marc/

Williams                 Expires March 19, 2003                [Page 21]

Internet-Draft            Zeroconf Requirements           September 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Williams                 Expires March 19, 2003                [Page 22]

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Sep 2002 14:33:53 -0400

a couple of comments on DNS/zeroconf name resolution scenarios

1. having scenarios is fine but I don't think we should publish a 
requirements document without having consensus on requirements
for each of those scenarios.  if recent discussion has revealed that 
we don't have that consensus, maybe we need to do more work.

2. while it's certainly appropriate to mention the security aspect,
spoofing of responses is not the only potential source of inconsistency 
between DNS and a zeroconf service - the scenario where DNS-connected 
hosts see a different set of RRs than those which are using zeroconf 
will arise entirely out of normal operation, with no malice or ill 
intent on anyone's part.

Keith