Subject: draft-ietf-zeroconf-reqts-08.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Jul 2001 14:04:47 -0400

The WG has reqested this document be published as an Informational
RFC. I have reviewed the document and have the following
questions/comments.

Thomas

How about a more descriptive title than "zeroconf requirements"

>    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 [RFC 2131] or DNS [RFC 1034,
>    RFC 1035] servers. Zeroconf protocols may use configured
>    information, when it is available, but do not rely on it being
>    present. One possible exception is the use of MAC addresses
>    (i.e. layer two addresses) as parameters in zeroconf protocols.

I do not consider a MAC address to be configured information. It is
built-in as far as the end user is concerned.

This may be a minor nit, but it may be worth pointing out that DHCP
*protocols* could be used in a zeroconf environment, so long as no
user configuration were needed. One can imagine a DHCP server figuring
out a lot of things on its own without being configured (and there has
been talk on the list about this).

> 1.5 Routable Protocol Requirement
> 
>    If a protocol is intended to span multiple IP subnets it SHOULD
>    NOT use broadcasts or link-local addressing.

define what link-local addressing is? i.e., self-configured addresses?

I.e., this term is clearly defined in IPv6, but I don't believe its
defined for IPv4 in any document (and IMO, it should be).

>    Requirement:
>    - Protocols intended to span multiple IP subnets SHOULD NOT use
>      broadcasts or link-local addressing.

Why not? just stating something should or should not be done without
context isn't always very convincing.

>    Topology changes or other events such as adding and removing hosts
>    may cause conflicts and state changes within a protocol. Zeroconf
>    protocols must be able to resolve conflicts and state changes caused
>    by topology changes or other events. The scenario in the 2.1.2 Bridge
>    Installed section is the only scenario that illustrates the need for
>    this requirement, thus the below requirement is duplicated in section
>    2.1.2. However, this requirement applies to all protocol areas.
 
Suggested rewording of the first part:

   Topology changes or other events such as adding and removing hosts
   may cause changes to the overall system state, invalidate
   assumptions made by some protocols, and lead to incorrect or
   undesirable operating states.  Zeroconf protocols must be able to
   detect and resolve conflicts and state changes caused by topology
   changes or other events in some cases. The scenario in the 2.1.2
   Bridge Installed section is the only scenario that illustrates the
   need for this requirement, thus the below requirement is duplicated
   in section 2.1.2. However, this requirement applies to all protocol
   areas.

>    Requirement:
>    - MUST respond to state changes and resolve conflicts in a timely
>      manner.

Note that his is really open ended, so I don't really know what "MUST"
means specifically. What conflicts need to be resolved? Indeed, what
is a "conflict"? My suspicion is that having a MUST here in a generic
sense is not appropriate. What you want is a MUST in specific
sitations that it is felt should or should not happen.

>    Requirements:
>    - MUST configure an appropriate netmask.
>    - MUST have unique IP addresses within an IP subnet.
>    - MUST have some routing information
>      (for the internetwork scenario).

On the last point, would it be more correct to say, needs the address
of one or more default routers? Or is there more to this?

>    - MUST have unique IP subnets within an internetwork
>      (only for the internetwork scenario).

Do you need to scope this more? I.e., can't an "internetwork" consist
of the entire Internet (per the earlier definition?)

>    Topology changes from the installation of a bridge or a router may
>    create the following problems: multiple default routes that cause
>    dial out lines to be used instead of broadband connections,
>    duplicate IP addresses within an IP subnet, or duplicate IP
>    subnets within an internetwork.

I don't understand the comment (or implication) about multiple default
routes leading to dial-out lines being used.

>    Requirement:
>    - MUST resolve conflicts and state changes in a timely manner.

Can the document be more specific and say just what conflicts need to
be resolved? Or is the assumption that the previously discussed issues
is what needs to be addressed?

> 2.1.3  IPv6 Considerations
> 
>    IPv6 allows a host to select an appropriate IP address, netmask,
>    and routing information, thus if a host is using IPv6, a zeroconf
>    IP interface configuration solution already exists.

Is this fully correct? Do routers automatically (without  user
configuration) advertise themselves as default routers?

Indeed, I'm a bit confused about whether this document assumes
multiple subnets are present. It seems to, but I thought the WG
decided that a single router was assumed. It would be good to state up
front what the assumptions are for the enivironment zeroconf is
operating in. Will there be just one router? Or multiple routers? Or
no routers?

> 2.2.1  Web Browsing
> 
>    An URL typically contains the name of a Web server. When a user
>    enters an URL into a Web browser, the name must be translated to
>    an IP address before any actual Web browsing occurs. Web servers
>    often record log files of accesses, and wish to map the client's
>    IP address back to a human-readable name for recording in the log
>    file. Thus, a mechanism to translate the IP address to a name is
>    required.
> 
>    Requirement:
>    - MUST translate a name to an IP address.
>    - MUST translate an IP address to a name.

This text curiously doesn't mention the DNS. But, for the web server,
isn't the DNS reverse lookup specifically what is assumed/required?
Seems like the reqirement is much more specific than just "translate
name to address" and vice versa, and involves integration with the
DNS.

> 2.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:
>    - MUST list which of the scopes (local, link-local, or site-local)
>      are available for hosts.
>    - MUST list per-scope address ranges that may be allocated.

I'm not clear what the requirement above is. That is, *who* is
responsbile for the MUST? The application? How is the application
supposed to determine this? Is the point that this information must
somehow be determinable? (General comment: This may all be an artifact
from the fact that the Requirements bullets are not using full
sentences.)

> 2.3.4  IPv6 Considerations
> 
>    To date, no range has been reserved for source-specific addresses
>    in IPv6.  Hence, until such a range is reserved, dynamic allocation
>    of source-specific addresses applies only to IPv4.
> 
>    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.

Is there reason to think that the mechanisms in IPv4 and IPv6 might be
different?

> 2.4 Service Discovery Scenarios
> 
>    Service discovery protocols allow users to select services and/or
>    hosts by a name that is discovered dynamically, rather than requiring
>    that the user know the name in advance and type it in correctly.

Can't an application find and select services without the user being
queried? E.g., isn't DNS a service? Should the user choose the DNS
server?

Should the user always be prompted, or is there room for the user not
having to select at all, if there is only one choice?

>    The IPv4 interface configuration protocol MAY omit security
>    mechanisms if and only if that protocol is not used for IPv6 and
>    cannot be extended to support IPv6.  It is strongly recommended that
>    it include security mechanisms, because many protocols are extended
>    later in ways not anticipated by the original developer(s).

Explain

>   use a printer that doesn't exist, no printed upon paper appears.)

parsing

On the security considerations. I'd like to run this by the Security
ADs before commenting specifically. So there may be some specific
comments on this point coming later.

---

From: Daniel Senie <[email-masked]>
Date: Mon, 09 Jul 2001 15:11:57 -0400

I've interspersed some comments below.

>been talk on the list about this).

There was a lot of debate about this. As I recall, the concern is that 
Zeroconf can't rely on there being a server. No server means no DHCP.

>define what link-local addressing is? i.e., self-configured addresses?

yes. See the link local draft...

>context isn't always very convincing.

Link local addressing can't be routed per definitions in the other draft.

>isn't the DNS reverse lookup specifically what is assumed/required?

Web servers as such are not dependent on DNS in any form. Implementations 
of web servers often have such dependencies, but reverse lookups are NOT 
required for proper operation of web servers.

>name to address" and vice versa, and involves integration with the

Zeroconf is an environment without servers. How are you going to do a DNS 
lookup without a server?

>queried? E.g., isn't DNS a service? Should the user choose the DNS

If there's no server serving DNS, it'll be hard to use it.

>comments on this point coming later.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Erik Guttman <[email-masked]>
Date: Wed, 11 Jul 2001 17:11:30 +0200 (MET DST)

> But the text in the document specifically says web servers do the reverse
> mapping, and that drives the requirement that a reverse mapping be
> doable. Existing web servers use the DNS for this. Are you saying that
> in a zeroconf environment, Web servers can and/or should use something
> other than DNS to do the reverse mapping?
> 
> The point I'm trying to amke is that it seems misleading at best to
> suggest that a generic address to name mapping is needed, if what is
> actually needed is one that applications can use just as they do today
> with DNS.

Yes.  What we want to say is that the upper layer support apps relying
on RFC 1123 DNS interfaces will continue to be supported.  We do not
have to, nor should we, say in the reqts doc how this support is achieved.

> The web server example above says they will need to do the reverse
> mapping. 

The web server example is motivate and support the listed reqts
for forward and reverse lookup.  What we should really do, perhaps,
is require support for RFC 1123, section 6.1.

> Yes. The text suggests that service discovery requires user choose
> from a menu of choices. Is that also true of services like the DNS?
> Does the above exclude services that are generic and where it doesn't
> matter who offers it?

What we really want to say is that services can be discovered and selected, 
by users or by a computer program.  That way the location of the server
does not need to be known in advance for client-server software to function.

We will quickly get into a rathole about DNS here.  One can use mDNS to
resolve DNS names when there is no DNS server.  You can query DNS SRV RRs
to request service instances by type.  That type is a name.  So, the
essential thing is not that one doesn't know the name of the service in
advance, but rather, one doesn't know the particular server instance yet.
One uses a service discovery protocol to obtain these concrete service
locations.

In summary, I suggest that this text be changed to:

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

Erik

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Jul 2001 09:27:52 -0400

> Zeroconf can't rely on there being a server. No server means no DHCP.

So I see. :-) I'm OK leaving the text as is then.

> yes. See the link local draft...

Ah, yes, that makes sense.

> Link local addressing can't be routed per definitions in the other draft.

My point was more on the "should not use broadcast". Per the
definition of link-local addressing, it *can't* be used -- routers
will drop the traffic, so this would seem to need to be stronger than
a "SHOULD NOT".

Thomas

---

From: Daniel Senie <[email-masked]>
Date: Wed, 11 Jul 2001 10:27:44 -0400

>other than DNS to do the reverse mapping?

I think pointing to web servers in this case is a bad idea, as it's a bad 
example. The example is based on common practice, not operational 
necessity. Many embedded devices have web servers within them which have no 
reliance on DNS. It's exactly this sort of embedded device (or "appliance" 
as some call them) which is likely to occur on a link-local network (e.g. 
for controlling devices in a house).

>Does the above exclude services that are generic and where it doesn't

I'll let others comment on this. From other messages, it sounds like others 
have better answers on this subject than I do.

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Jul 2001 09:30:40 +1000

> been talk on the list about this).

Personally, I prefer the notion of "zeroconf protocols", rather than
protocols being "zeroconf to the user".  A zeroconf protocol being
something that devices can engage in *without* the presence of some
other box or service on the network to assist it.

The "pre-configured" DHCP server along the lines of the mini-dhcp is
quite a common approach which to my mind does *not* fit the bill of a
"zeroconf protocol", but is "zeroconf to the user".  This is because
without the server, going through the motions of the protocol don't
get you anywhere.

I can imagine the co-existence of DHCP with IPv4LL: a DHCP server on
the same network segment could fake up "leases" for addresses which
are discovered to be in use via the receipt of ARP messages and dish
out addresses via DHCP to devices which do not support IPv4LL.
(Section 1.4 of the IPv4LL document frowns on this, and I am tempted
to agree).

I can also imagine co-existince of mDNS and "configured" DNS where
proxying could happen from mDNS to DNS and vice versa.  There could
also be a link to dynamic DNS, and possibly DHCP if the device wanted
to suggest a name for itself.

Similar things could probably be said about SLP and ZMAAP.

It is the nature of these protocols (that they are distributed, and
reasonably stateless) that allows them to interoperate with
non-zeroconf protocols.  I think this is a distinction worth keeping.

> defined for IPv4 in any document (and IMO, it should be).

The IPv4LL draft says (Section 1):

  "This document prescribes rules for how IPv4 link-local addresses
   MUST be treated by hosts and routers."

And goes on to say things like:

  - (Section 1)   addresses are allocated from
		  169.154.1.0 - 169.254.254.255
  - (Section 2.5) packets with source and/or destination address
		  in that range are never forwarded

This seems like a reasonable definition to me, and so I think the
document does define what link-local for IPv4 is.  However, the text
reads in a way that seems to assume the reader has an intuitive
understanding of what link-local is beforehand.  It could be clearer.

It also seems to me that the mechanism for acquiring such an address
doesn't have a great deal of relevance to the definition of
link-local, but that isn't obvious from the document.

[ I just noticed a typo too:
  Section 1.  "With respects to hosts, it discusses .." ]

Perhaps a positive statement could be made:

  "Zeroconf protocols operating across multiple IP subnets should use
   multicast and unicast address scopes other than link local."

This is well defined for IPv6, and is defined for IPv4 multicast.

Can we make a definition for IPv4 unicast address scopes?:

  a. "link local" as defined by IPv4LL
  b. "site scoped" defined as RFC1918 addressing
  c. "globally scoped" defined as everything else

Is this document an appropriate place for such a definition?

> context isn't always very convincing.

A comment to the effect that broadcast and link-local traffic is never
forwarded would justify the requirement for me.

> sitations that it is felt should or should not happen.

I agree.  IIRC, the discussion relating to this requirement really
focussed on unicast addressing and "routing" conflicts, where a MUST
is probably appropriate.  In general though a SHOULD ought to suffice,
and the specific protocols (e.g. IPv4LL) can specify the MUST
behaviour where it makes sense.

> of one or more default routers? Or is there more to this?

I think the wording takes care to avoid the term "default router".
Routing information may be a default route, but might not be.
There was even discussion of hosts ARPing for every address and
having the router do proxy ARP for destinations in different subnets.

> of the entire Internet (per the earlier definition?)

Perhaps "internetwork" should be a "zeroconf internetwork" in this
section, where a "zeroconf internetwork" is the bunch of subnets
connected to exactly one router.

Zeroconfiguration of a single subnet, and zeroconfiguration of a set
of subnets hanging off a single router should be allowed for (as per
the charter).  Communication with the global internet should not be
precluded, and seems to be largely a matter of obtaining a default
route, and a working DNS.

Unique subnets can be allocated easily enough by a single router from
a private(IPv4) or appropriately scoped(IPv6) address space but will
require additional mechanisms (IPv6 SA, DHCP, ICMP addrmask, router
discovery, etc) for this to be useful.

I'm still confused about the whole single-router idea.  It seems as if
we have gone sufficiently far away from it now that it could be easily
dropped entirely.  The case of a single router seems to be adequately
covered by the mini-dhcp draft and if you have a router, adding extra
configuration services probably isn't going to hurt (if the router
dies, you are probably stuffed anyway).

Eventually, it could well become important to automatically configure
multiple routers (and therefore subnets) in a zeroconf manner.
Currently, this is not a topic for the working group, and I can't see
how the single router topology moves us in that direction.

> routes leading to dial-out lines being used.

No idea.

> is what needs to be addressed?

I read this as referring to section 2.1.1, where there are a set of
uniqueness requirements, etc.  Maybe it could do so explicitly.
For me, this requirement adds an on-going consistency requirement for
everything in 2.1.1.

This is different to the similar statement earlier, which I take to be
more general.

> configuration) advertise themselves as default routers?

I don't quite follow your comment.  Yes, some boxes might advertise
themselves as default routers (some kind of IPv6 residential gateway
springs to mind), but I don't see why that should be required.

> operating in. Will there be just one router? Or multiple routers? Or

Quite.  I vote for no (zeroconf) routers at the moment.

> name to address" and vice versa, and involves integration with the

I see the DNS as just one implementation of name<->address mapping.
For example, NetBIOS naming under windows 2000 lets me ping netbios
names, web surf to netbios names, etc by trying the netbios name
lookup before going to the DNS.  If there is no DNS server around, the
netbios stuff still works.

A residential gateway could proxy name service requests to/from
netbios and DNS to get integration.  I think this could be what ends
up being required for mDNS too if it were to be integrated as a
zeroconf protocol into a non-zeroconf network (with a DNS server).

> from the fact that the Requirements bullets are not using full

Yes, I think the point is that there should be a way for the
application to find this information out.  Incidentally, this doesn't
seem to just be a zeroconf requirement, but is probably true of any
networking with non-trivial multicast applications.

> Is there reason to think that the mechanisms in IPv4 and IPv6 might be

Dunno.

> having to select at all, if there is only one choice?

Generally the user should only become involved when absolutely
necessary.

> comments on this point coming later.

regards
	aidan
____
:wq!

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Jul 2001 09:44:46 +1000

> for controlling devices in a house).

I can't off the top of my head think of a protocol which absolutely requires
reverse lookup of names (if we had one, we should use it as an example).
Slabs of the internet seem to function OK without reverse entries in the DNS.

Perhaps the requirement is that a zeroconf name service *protocol* must
support both forward and backward mapping.  That avoids the necessity of
specifying what a host/application needs to do in a given circumstance.
DNS as it stands supports forward and backward mapping, but there are
plenty of hosts for which the backward mapping fails.

regards
	aidan
____
:wq!

---

From: Daniel Senie <[email-masked]>
Date: Wed, 11 Jul 2001 22:53:08 -0400

>Slabs of the internet seem to function OK without reverse entries in the DNS.

I'm about to submit the latest update to 
draft-ietf-dnsop-inaddr-required-??.txt. This document does cover what 
works and what doesn't with regards to INADDR and implementations which 
require it. The new version in the works goes on to recommend against using 
INADDR for any sort of "security" check. Much of this discussion probably 
should flow over to there (and hopefully a few folks who wouldn't otherwise 
read that WG's documents will get interested and provide some more feedback).

>plenty of hosts for which the backward mapping fails.

I agree with this. Avoiding mention of specific examples or protocols is 
probably the best bet in this case.

Dan

---

From: Erik Guttman <[email-masked]>
Date: Thu, 12 Jul 2001 13:11:30 +0200 (MET DST)

> reverse lookup of names (if we had one, we should use it as an example).

I think we should insist on requiring continued support for DNS app level
interfaces, as described in RFC 1123, section 6.1.  

> plenty of hosts for which the backward mapping fails.

The fact that reverse lookups fail in the real world points to operational
problems, not a reason to give up on our attempt to correctly support
desirable functionality.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 13 Jul 2001 11:37:29 +0200 (MET DST)

Aidan,

>   c. "globally scoped" defined as everything else

This is an interesting starting point for an IPv4 scoped 
architecture.

> Is this document an appropriate place for such a definition?

No.  We are concluding work on this doc, not adding more
(very contentious) topics for consideration.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 13 Jul 2001 11:40:22 +0200 (MET DST)

> > draft-ietf-zeroconf-reqts-08.txt:

> "Thomas Narten" <[email-masked]> wrote: 

This is supposed to mean that if one indiscriminately dropped 
routers or bridges into a network, inappropriate topologies
may result leading to dumb forwarding paths.  How this could
happen, given that routers need to be configured, I don't know.
I think this paragraph should be dropped.

Erik