[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12                        
Zeroconf WG                                              M. Hattig
Internet Engineering Task Force                             Editor
INTERNET DRAFT                                         Intel Corp.
Expires  September 2000                             March 10, 2000


                         Zeroconf Requirements
                    draft-ietf-zeroconf-reqts-03.txt

Status of This Memo

   This document is a submission by the Zeroconf Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be
   submitted to the zeroconf@merit.edu mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC 2026].  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.

Abstract

   Many common TCP/IP protocols such as DHCP, DNS, MADCAP, and LDAP
   must be configured and maintained by an administrative staff. This
   is unacceptable for emerging networks such as home networks, small
   office networks, automobile networks, airplane networks, or adhoc
   networks at conferences, emergency relief stations, and many
   others. For 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 (zeroconf) protocols.

   Before embarking on defining zeroconf protocols, protocol
   requirements are needed. This document presents requirements for
   zeroconf protocols in four areas: IP host configuration, domain



   Hattig                                                  [Page 1]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   name to IP address resolution, IP multicast address allocation,
   and service discovery. The requirements for these four areas
   result from examining everyday use or scenarios of these
   protocols.

   An additional part of the overall zeroconf protocol effort
   includes a separate profiles document that is a companion to this
   requirements document. The profile document matches existing
   protocols with the requirements. If existing protocols do not meet
   the requirements then new zeroconf protocols must be created.

                           Table of Contents

   1 Introduction................................................2
   1.1 Reading This Document.....................................3
   1.2 Background Information....................................3
   1.3 Zeroconf Protocols........................................4
   2 Scenarios & Requirements....................................9
   2.1 IP Host Configuration.....................................9
   2.2 Domain Name to IP Address Resolution Scenarios...........12
   2.3 IP Multicast Address Allocation Scenarios................15
   2.4 Service Discovery Scenarios..............................18
   3 Security Considerations & Requirements.....................20
   3.1 IP Host Configuration....................................21
   3.2 Domain Name to IP Address Resolution.....................21
   3.3 IP Multicast Address Allocation..........................22
   3.4 Service Discovery........................................22
   3.5 IPv6 Considerations......................................22
   4 IANA Considerations........................................22
   5 Full Copyright Statement...................................22
   6 Acknowledgements...........................................23
   7 References.................................................24

1  Introduction

   This document presents requirements for zeroconf protocols in four
   areas: IP host configuration, domain name to IP address
   resolution, IP multicast address allocation, and service
   discovery. Security issues and the transitions between a zeroconf
   protocol and a non-zeroconf protocol are also discussed within
   each protocol area.

   The major sections to this requirements document are the
   Introduction, Scenarios & Requirements, and Security
   Considerations & Requirements. The introduction provides the
   background information, terms, and assumptions so the scenarios
   can be understood. The Scenarios & Requirements section lists
   requirements that result from examining everyday usage scenarios
   of protocols. The security section lists threats and security
   requirements for all four protocol areas.



   Hattig                                                  [Page 2]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000



   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 [RFC
   2119].

1.1 Reading This Document

   Because this document deals with four distinct protocol areas,
   many sections are divided into these areas. These areas are:
   - IP host configuration
   - Domain name to IP address resolution
   - IP multicast address allocation
   - Service discovery

   With the exception of the introduction, a reader only interested
   in particular areas only needs to read about those areas. However,
   all readers should read the introduction to understand the flow of
   the document and various global assumptions.

   Specifically, the introduction provides the necessary background
   information to support the scenarios and requirements sections.
   This introduction includes reference information, restrictions,
   assumptions, and terms.

   The Scenarios & Requirements section is divided into protocol
   areas. Within each area is a representative set of everyday usage
   scenarios that generate unique requirements. A summary of all
   requirements finishes each protocol area subsection.

   The Security Considerations & Requirements section lists threats
   and security requirements for each protocol area.

1.2 Background Information

   The below references are divided by protocol area with additional
   references for security and general knowledge. Note that some IETF
   working groups are listed because they specify protocols that
   impact zeroconf protocols. All readers should be familiar with the
   general knowledge references.

   IP host configuration:
   - [AutoNet] Ipv4 Auto-Configuration I-D
   - [MiniDHCP] Auto-Addressing in Multi-segment Networks I-D
   - [RFC 1918] RFC 1918 Private Addresses
   - [RFC 2131] RFC 2131 DHCP
   - [RFC 2132] RFC 2132 DHCP Options
   - [RFC 2462] IPv6 Auto-Configuration
   - [RFC 2461] IPv6 Neighbor Discovery
   - [IPv6 WG] Next Generation (Ipv6) WG



   Hattig                                                  [Page 3]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   - [DHC WG] Dynamic Host Configuration WG

   Domain name to IP address resolution:
   - [Mcast DNS] Multicast DNS I-D
   - [RFC 1001] NETBIOS: CONCEPTS AND METHODS
   - [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS
   - [RFC 1034] RFC 1034 DNS
   - [DNSEXT WG] DNS Extension WG

   Multicast address allocation:
   - [AutoMcast] Multicast Address Allocation in Auto-Configured
     Networks I-D
   - [RFC 2730] RFC 2730 MADCAP
   - [RFC 2365] RFC 2365 Administratively Scoped Multicast Address
   - [MALLOC WG] Multicast Address Allocation WG

   Service discovery:
   - [SSDP] Simple Service Discovery Protocol I-D
   - [RFC 2608] RFC 2608 Service Location Protocol v2
   - [RFC 2609] RFC 2609 SLP Schemes

   Security:
   - [RFC 2316] RFC 2316, IAB Security Architecture Workshop
   - [RFC 2401] RFC 2401, Security Architecture for IP
   - [RFC 2411] RFC 2411, IP Security Document Roadmap
   - [RFC 2504] RFC 2504, User's Security Handbook

   General knowledge:
   - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers
   - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers
   - [RFC 1458] RFC 1458 Requirements for Multicast Protocols
   - [RFC 1812] RFC 1812 Requirements for Internet Gateways

1.3 Zeroconf Protocols

   Below are strict definitions of zeroconf protocol and a non-
   zeroconf protocol. Also discussed are how a host transitions
   between a zeroconf protocol and non-Zeroconf protocol within a
   single area as well as coexistence of protocols in different
   areas. Then, additional subsections state the assumptions and
   restrictions for each protocol area.

1.3.1  Definitions

   A zeroconf protocol requires no user configuration and does not
   rely on information received from a centralized server.

   A non-zeroconf protocol requires user configuration or relies on
   information received from a centralized server.




   Hattig                                                  [Page 4]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


1.3.2  Transitions

   Below is a discussion of three possible transitions that a host
   SHOULD consider when using a zeroconf protocol. Basically, the
   host must be able to determine when to change from using the
   zeroconf protocol to the non-zeroconf protocol, or vice-versa. In
   addition, if the host moves from one network to another network
   and both networks are using a zeroconf protocol, the host must
   know to re-initialize or restart the zeroconf protocol.

   The first transition is a zeroconf to non-zeroconf transition.
   This type of transition may occur either if a host moves to a new
   network that does not use a zeroconf protocol when the old network
   used a zeroconf protocol. Or if the host stays on the same network
   but a non-zeroconf server comes online within that network. For
   example, if a DHCP server comes online after hosts are configured
   with a zeroconf IP host configuration protocol then hosts MUST re-
   configure with DHCP.

   The second transition is the opposite of the first; it is a non-
   zeroconf to zeroconf transition. This may occur if a host moves to
   a different network or when a non-zeroconf server goes offline
   within a network.

   The third transition occurs if a host moves from one network to
   another network when both networks use a zeroconf protocol. For
   example, if a person is using a laptop in her home network with a
   zeroconf protocol, then she takes that laptop to her neighbor's
   home network that uses the same zeroconf protocol, then the laptop
   must automatically adapt to the zeroconf protocol operating in the
   new network.

   Another subtle example of this third of transition is if the
   network topology changes significantly as when a bridge gets
   installed between two existing networks. In this case, if the
   networks are utilizing a zeroconf IP host configuration protocol,
   the protocol MUST allow the hosts to detect addressing conflicts
   and possibly reconfigure.

1.3.3  Coexistence

   A zeroconf protocol in one area MUST be able to coexist with a
   non-zeroconf protocol in another area.

   To illustrate this point, suppose there are standard zeroconf and
   non-zeroconf protocols for IP host configuration and domain name
   to IP address resolution.






   Hattig                                                  [Page 5]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   For IP host configuration, the zeroconf protocol is "protocol-A."
   The non-zeroconf protocol is "protocol-B", supported by a fully
   conformant "protocol-B" server.

   For domain name to IP address resolution, the zeroconf protocol is
   "protocol-C".  The non-zeroconf protocol is "protocol-D" supported
   by a fully conformant "protocol-D" server.

   Within a single network, the IP host configuration zeroconf
   protocol-A MUST be able to coexist with the domain name to IP
   address resolution non-zeroconf protocol-D.

   In contrast, zeroconf and non-zeroconf protocols from a single
   area MUST NOT be able to coexist during normal operation. They MAY
   coexist during a transition, but the coexistence period MUST be
   minimal.

1.3.4  IP Host Configuration

   In this document, IP host configuration really is the
   configuration of an interface on an IP host. That is, IP host
   configuration is complete when a host is able to use an IP
   address, netmask, and default route on an interface. IP host
   configuration is required before almost any IP communication can
   take place through a single interface on a host.

   DHCP is the common IP host configuration solution deployed today.
   DHCP consists of servers and clients. The client discovers the
   server, and then the server offers configuration parameters to
   clients. It is assumed that all zeroconf IP host configuration
   schemes will coexistence with DHCP. DHCP is the non-zeroconf
   solution for IP host configuration.

   The definitions needed for the IP host configuration scenarios
   are:

   IP subnet û a single logic IP network that may span multiple layer
   2 networks. All hosts on a single logical IP network have the
   identical result when performing the following operations
   (HostIPAddr & netmask). In addition, all hosts on the single
   logical subnet have a unique result when performing the following
   operation (HostIPAddr & ~netmask) (inverse netmask).

   internet - multiple IP subnets connected by routers. This may be
   the global Internet or a private internet.

   Network - general term that may apply to IP subnet, internet,
   Internet, or a layer 2 network. The context in which this term is
   used defines its meaning.




   Hattig                                                  [Page 6]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


1.3.5  Domain name to IP address resolution

   Web browsing to an URL utilizes domain name to IP address
   resolution. When a user enters a host name to download a file with
   FTP, the entered name is resolved to an IP address. Domain name to
   IP address resolution allows applications and users to remain
   blissfully unaware of IP addresses.

   DNS is the common way to resolve names. DNS consists of servers
   that maintain resource records; a record maps a domain name to an
   IP address. In addition, resolvers (i.e. clients) on hosts query
   the DNS servers for the information in resource records. Name
   servers have authority for particular zones. A zone covers a
   complete set or a subset of a domain. If a server cannot directly
   resolve a name, it passes the request onto another DNS server or
   returns the IP address of another DNS server back to the resolver
   so the resovler can query the DNS server it just learned about.
   DNS is the non-zeroconf solution for domain name to IP address
   resolution.

   It is assumed that sub-domain delegation is not done within the
   zone that a zeroconf domain name to IP address resolution protocol
   is performed. In other words, a zone includes all of the names in
   its domain.

   In addition, it is assumed a zeroconf domain name to IP address
   resolution protocol will only be used if a DNS server is not
   present or a host is not configured with a DNS server. It is also
   assumed that TCP/IP networking connectivity to other zones MAY
   exist and those other zones have DNS servers. Furthermore, this
   also assumes that a special router exists at the edge of these two
   zones and is able to convert between the zeroconf and non-zeroconf
   domain name to IP address resolution protocols.

   A default domain is the domain considered ôlocalö to a host.

1.3.6  IP Multicast Address Allocation

   Examples of emerging multicast applications include audio/video
   (e.g. TV), bulk news, and intra-home intercom system. These
   applications require an IP multicast address prior to sending IP
   multicast packets. In most cases, the IP multicast address is
   unique per application source. The scope of the multicast address
   determines if a multicast packet gets transmitted beyond certain
   administrative domains, which are separated by a boundary router
   as defined in RFC 2365.

   MADCAP is the non-Zeroconf IP multicast address allocation
   solution. MADCAP is a client/server protocol that operates much
   like DHCP. In addition, the client may define a range from which



   Hattig                                                  [Page 7]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   the IP multicast address is allocated by passing a scope along
   with the clientÆs allocation request.

   Zeroconf solutions are only concerned with IP multicast addresses
   scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and
   any scope of single-source IP multicast addresses. It is assumed
   that an RFC 2365 defined boundary router appropriately controls
   multicast packets from physically entering and leaving scope
   boundaries.

1.3.7  Service Discovery

   Service discovery protocols have proven to be critical to the
   usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are
   good real-world examples of this. Services from printing to gaming
   are easily found on these networks.

   Unlike the other protocol areas in this document, service
   discovery will not likely have separate zeroconf and non-zeroconf
   protocols; one protocol will serve both.

   Also unlike the other protocol areas, no service discovery
   protocol has been as widely deployed as DNS or DHCP. Service
   Location Protocol version 2 (SLPv2) is defined in Standards Track
   RFC 2608. An Internet-Draft defines Simple Service Discovery
   Protocols (SSDP), which is another service discovery protocol.

   Service discovery definitions are:

   Process - A process is an implementation of an algorithm in
   software, hardware, or a combination of software and hardware.

   Registry - A process that acts as an intermediary between a client
   and a server.  Servers 'register' service advertisements and other
   pertinent information (e.g. authentication info, announcement
   criteria) with registries, then the service may be discovered from
   the registry instead of from a server.

   Registry update - A message that contains updated registry
   information. It may cause one or more registry entries to be
   deleted, added, or modified.

   Server - A process that offers services to clients.  A server can
   make its service(s) known to clients by means of a service
   discovery protocol.

   Service - A service is set of processes that utilize a particular
   protocol. Services range from printing to transferring a file to
   providing on-line pizza order and delivery.




   Hattig                                                  [Page 8]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   Service Advertisement Packet - An unsolicited packet issued by a
   server or registry. The advertisement provides the service
   identifier, service type, and possibly service characteristics.

   Service Characteristics û Characteristics provide a finer
   granularity of description by which 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
   a client (or clients) to discover a server (or servers) of a
   particular service. A service discovery protocol is an application
   layer protocol that relies on network and transport protocol
   layers.

   Service Identifier - A service identifier allows clients, servers,
   advertisers, discoverers, and registries to uniquely identify an
   instance of a service type.

   Service Protocol - A service protocol is used between the client
   and the server after service discovery is complete.

   Service Solicitation - A request packet made by a client to obtain
   a response packet that indicates a service is present. The
   response may come from a service or a registry.

   Service Type û A service type allows clients, servers,
   advertisers, discoverers, and registries to uniquely identify a
   type of service such as a printer service.

2  Scenarios & Requirements

   This section lists everyday usage scenarios that lead to
   requirements for zeroconf protocols. There is a subsection for
   each of the four protocol areas. Within each protocol area
   representative scenarios are discussed and requirements are
   identified. Also, within each area is a summary of the
   requirements and an IPv6 considerations section.

2.1 IP Host Configuration

   IP Host configuration determines the appropriate values for an IP
   interface's IP address, netmask, and default route. Then the host
   must operate with those values. The scenarios in this section are
   ping, bridge install, and transitions between zeroconf IP host
   configuration and DHCP.

2.1.1  Ping




   Hattig                                                  [Page 9]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   Ping consists of one host sending an ICMP echo request to another
   host, then the other host replying with an ICMP echo reply. Ping
   has two sub-scenarios: ping to a host on local IP subnet and ping
   to a host off the local IP subnet.

   When sending a ping, a host performs the AND operation on the
   netmask and the destination IP address then compares that result
   with the result of an AND operation on the host's IP address and
   netmask. Here is representative C code:

   ((HostIPAddr & netmask) == (DestIPAddr & netmask))

   If the result of this compare is FALSE, then the host forwards the
   packet to the default router because the destination address is
   off the local IP subnet. If the result is TRUE, then the host
   sends an ARP request to resolve the destination IP address to a
   hardware address within the local IP subnet.

   These steps are important to show that a ping to a host on a local
   IP subnet presents different requirements than a ping to a host on
   a non-local IP subnet. The zeroconf IP host configuration MUST
   allow ping to succeed in either case if it is possible within the
   TCP/IP connectivity provided by a given network. The specific
   protocol requirements follow:

   Netmask requirements:
   - All hosts on an IP subnet MUST have a common netmask.

   IP address requirements:
   - The result of (HostIPAddr & netmask) must be the same value for
     all hosts on an IP subnet
   - The result of (HostIPAddr & ~netmask) (inverse netmask) must be
     unique for all hosts on an IP subnet

   Default route requirements:
   - A default route is not required for communication within the
     local subnet.
   - A default route is required for communication off the local
     subnet.

   Note that by definition, IP subnet numbers must be unique within
   an internet, thus no address duplication between hosts on
   different subnets can exist. Managing IP subnet numbers is not the
   function of an IP host configuration protocol; it is the function
   of a router or another entity aware of an entire internet.
   Zeroconf IP Host configuration does not include configuration of
   routers; however, zeroconf IP host configuration MAY utilize a
   configured router to retrieve the default route or the netmask.
   Hosts could subsequently determine the IP subnet number with the
   netmask.



   Hattig                                                  [Page 10]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000



   Note that a ping from a host using a private address (as defined
   in RFC 1918) to a globally unique IP address on the Internet does
   not add additional requirements to the zeroconf IP host
   configuration protocol. Instead, it places additional requirements
   on the specialized router that sits between the internet using the
   private address space and the global Internet. The requirements of
   this specialized router are outside the scope of this document.

2.1.2  Bridge Installed

   This scenario starts with two completely operational standalone
   networks. After initial IP host configuration with zeroconf
   protocols, these two networks become one when a bridge gets
   installed between them.

   Two problems arise. The first is that hosts now may have duplicate
   IP addresses. Note, that this is not considered a major problem
   because the occurrence of duplicate addresses can be made
   statically improbably if the netmask is the same for all networks
   and allows for a large number of hosts (e.g. netmask of
   255.255.0.0).

   Another problem is that the hosts on the two networks are not
   using the same netmask or that all hosts do not have the same
   result of (HostIPAddr & netmask) operation as was shown to be a
   requirement for ping. Note this assumes that a network with
   multiple IP subnets operating over a single layer-2 network is not
   desirable.

   These problems create unique requirements for the bridge install
   scenario. Specifically, the zeroconf IP host configuration
   protocol MUST provide hosts with the ability to detect duplicate
   IP addresses even after initial configuration. Once detected, one
   of the hosts must choose a new IP address and ensure that the new
   IP address is unique. In addition, the protocol MUST consolidate
   two IP subnets into a single IP subnet.

2.1.3  Zeroconf and non-Zeroconf Transitions

   DHCP is the non-zeroconf IP host configuration protocol. Hosts
   MUST be able to transition between DHCP and the zeroconf IP host
   configuration protocol by detecting the presences or absence of a
   DHCP server. Barring any new DHCP option, the most likely
   mechanism is a DHCP discovery message.

   If DHCP is detected while using zeroconf IP host configuration,
   the host must start utilizing DHCP. If DHCP is no longer detected
   while using DHCP, the host must start utilizing the zeroconf IP
   host configuration protocol.



   Hattig                                                  [Page 11]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000



2.1.4  Requirements Summary

   Zeroconf IP host configuration protocol requirements are:
   - The protocol MUST allow all hosts on an IP subnet to have a
     common netmask.
   - The protocol MUST allow all hosts on an IP subnet to choose an
     IP address such that the result of the (HostIPAddr & netmask)
     operation is the same value for all hosts on an IP subnet.
   - The protocol MUST allow all hosts on an IP subnet to choose an
     IP address such that the result of the (HostIPAddr & ~netmask)
     operation (inverse netmask) is unique among all hosts on an IP
     subnet.
   - The protocol MUST allow hosts to operate without choosing a
     default route to communicate with other hosts on their local
     subnet.
   - The protocol MUST allow hosts to choose a default route if it is
     available.
   - The protocol MUST allow the host to defend the address it
     chooses.
   - The protocol MUST provide hosts the ability to detect duplicate
     IP addresses after initial configuration.
   - The protocol MUST be able to consolidate two IP subnets into a
     single IP subnet.
   - The protocol MUST allow a host to detect that DHCP is and is not
     in use.
   - The protocol MUST allow a host to transition from the zeroconf
     protocol to DHCP if DHCP is detected while using zeroconf IP
     host configuration.
   - The protocol MUST allow a host to transition from DHCP to the
     zeroconf protocol if while using DHCP the DHCP server is no
     longer detected.

2.1.5  IPv6 Considerations

   IPv6 allows a host to select an appropriate IP address, netmask,
   and find a default route, thus if a network is using IPv6, there
   already exists a zeroconf IP host configuration solution.

2.2 Domain Name to IP Address Resolution Scenarios

   Domain name to IP address resolution consists of a host making a
   query that contains a host name, and then the response to the
   query contains the IP address to complete the resolution.

   The zeroconf problem with DNS is that the host must be configured
   with the IP address of a DNS server. This allows the host to send
   a unicast DNS request to a DNS server, then its simplest form, the
   DNS server responds with the IP address.




   Hattig                                                  [Page 12]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   The zeroconf goal for domain name to IP address resolution is to
   remove the need for the host to configure the IP address of a DNS
   server.

   The first scenarios are to resolve a name of a host that resides
   within the zeroconf domain and then to resolve a name that resides
   outside the zeroconf domain.

   Another scenario below is a host determining its name and default
   domain. Once a name is selected, the host must ensure the name is
   unique within its default domain. This is an ancillary issue for
   domain name to IP address resolution that will most likely result
   in a protocol that is independent from protocols that resolve
   domain names to IP addresses.

   The final scenarios are transitions between using DNS and the
   zeroconf domain name to IP address resolution protocol.

2.2.1  Name Resolution

   The zeroconf domain name to IP address resolution protocol MUST
   resolve a name to an IP address without a host being configured
   with the IP address of a DNS server. This includes names within
   the same domain as the host that is using the zeroconf protocol as
   well as names within other domains.

2.2.2  Name and default domain selection

   A name selection protocol is necessary so that all host within a
   domain have unique names. Once a host chooses a name, it MUST then
   determine if the name is in use. If the host requires a unique
   name, the host selects a different name and again determines if
   the name is unique. This process continues until the host has a
   name that is unique within a domain.

   A host MUST determine its default domain and the default domain
   MUST be the same for all hosts within the domain.

   The zeroconf name resolution protocol must become active
   periodically to check the validity of name. One example of when
   this is necessary is when previously disconnected yet operational
   networks now become connected by the installation of a router or a
   bridge.

2.2.3  Zeroconf and non-Zeroconf Transitions

   DNS is the non-zeroconf domain name to IP address resolution
   protocol. There are four transitional cases to consider.





   Hattig                                                  [Page 13]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   The first is a zeroconf to non-zeroconf transition that occurs
   when the host is first configured with the IP address of the DNS
   server and the host can actually reach the DNS server (i.e. the
   DNS server responds to requests).

   The second is a non-zeroconf to zeroconf transition that occurs
   when for some reason the DNS server can no longer be reached. One
   such reason may be that the host is moved to a network without
   connectivity to the DNS server. In this case the zeroconf domain
   name to IP address resolution protocol MUST be invoked.

   The third transition is from zeroconf back to non-zeroconf. This
   occurs when the DNS server becomes reachable again. Following the
   above example, the host is moved back to the original network with
   connectivity to the DNS server.

   The final transition is a non-zeroconf to zeroconf transition that
   occurs when the IP address of the DNS server is removed from the
   host.

   These transitions generate the following requirements:
   - The zeroconf protocol MUST operate when a host is not configured
     to use a DNS server.
   - If configured to use DNS the host MUST be able to detect the
     presence and the absence of a DNS server.
   - If the DNS server becomes absent after configuration, the host
     MUST use the zeroconf protocol.
   - If the DNS server becomes present after being absent, the host
     MUST use DNS.

2.2.4  Requirements Summary

   Zeroconf Domain name to IP address protocol requirements are:
   - The protocol MUST resolve a name to an IP address without a host
     being configured with the IP address of a DNS server. This
     includes names within the same domain as the host that is using
     the zeroconf protocol as well as names within other domains.
   - The protocol MUST allow the host to defend the name it chooses.
   - The protocol MUST operate when a host is not configured to use a
     DNS server.
   - If configured to use DNS the host MUST be able to detect the
     presence and the absence of a DNS server.
   - If the DNS server becomes absent after configuration, the host
     MUST use the zeroconf protocol.
   - If the DNS server becomes present after being absent, the host
     MUST use DNS.

   Zeroconf name selection protocol requirements are:





   Hattig                                                  [Page 14]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   - Processing within a host is responsible for choosing a host
     name. This includes selecting the initial name as well as
     selecting subsequent names if a name proves to be a duplicate.
   - The protocol MUST allow the host to determine if the name is in
     use by another host within the default domain. At various times
     a host MUST actively determine if another host is using its
     name.
   - The protocol MUST remain within the domain of the hosts using
     the protocol.
   - The protocol MUST allow hosts to create or determine the
     existence of a default domain.
   - The protocol MUST ensure all hosts operating within a domain use
     the same default domain.

2.2.5  IPv6 Considerations

   Domain name to IP address resolution protocols as well as name and
   default domain selection have no zeroconf related differences for
   IPv4 and IPv6.

2.3 IP Multicast Address Allocation Scenarios

   IP multicast is used to conserve bandwidth and reduce complexity
   in the source. Bandwidth is conserved because a sender only sends
   a single packet, then a large number of receivers receive that
   packet. The unicast alternative requires the source to send
   individual packets to each destination; this consumes more
   bandwidth. In addition, unicasting increases the complexity of the
   source because the source must maintain a list of the individual
   destinations.

   All IP multicast addresses allocated are from the scopes of Local
   (i.e. 239.255.0.0/16), link-local, node-local, and Single-source
   IP multicast addresses of any scope. Descriptions of ôScope
   Enumerationö and ôAllocate Node-scoped or Single-Source Global IP
   multicast addressö do not result in requirement but do provide
   important information about IP multicast operations. The scenarios
   of ôAllocate Link-scoped or Local-Scope IP multicastö, ôAllocate
   IP Multicast Address Used by Multiple Sourcesö, then the
   transitions between zeroconf and MADCAP generate protocol
   requirements.

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 within [RFC
   2771].

   In addition, services that are assigned relative addresses [RFC
   2365] also require the ability to enumerate what scopes the host



   Hattig                                                  [Page 15]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   is within, then a host is able to apply the relative address to a
   scope.

   When enumerating scopes, the following scopes may be assumed to
   exist in all cases (assuming well-known ranges have been reserved
   by IANA).
   - Node-Local
   - Link-Local
   - Local (i.e., the Zeroconf area)
   - Single-source global

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - A host MUST be able to obtain the set of scope names, for all
     scopes it is within.
   - A host MUST be able to obtain the set of address ranges for all
     scopes it is within.

2.3.2  Allocate Node-scoped or Single-Source Global IP multicast
       address

   Each host is always responsible for allocating its own Node-scoped
   and Single-source Global multicast addresses, regardless of
   whether it is use of zeroconf protocols since there is no
   coordination between devices for such allocation, no protocol is
   involved, and there are no protocol requirements.

   Allocating (global) single-source addresses is only possible if
   the host has already acquired a global unicast IP address.

   To date, no range has been reserved for dynamic allocation of
   Single-source addresses in IPv6.  Hence, until such a range is
   reserved, dynamic allocation of Single-source addresses applies
   only to IPv4.

2.3.3  Allocate Link-scoped or Local-Scope IP multicast address

   Address allocation at the Link and larger scopes requires
   coordination to avoid address collisions.  To allocate an address,
   the host specifies a given scope, the number of addresses it
   desires, and the lifetime for which it desires.

   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.

   Collision detection must span the entire Link for Link-scope
   allocations, and must span the entire locally scoped internet for
   Local-scope allocations. The protocol should include the ability



   Hattig                                                  [Page 16]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   for a host to choose addresses, determine if they are in use, and
   choose different addresses if so.

   The collision detection protocol must become active at various
   times such as when previously disconnected yet operational
   networks now become connected by the installation of a router or
   bridge.

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - A host that wishes to allocate a multicast address with a given
     scope and lifetime MUST select an address.
   - A host MUST determine if the address has been allocated by
     another host.
   - A host MUST participate to defend the addresses it allocates.
   - At various times a host MUST actively determine if another host
     has allocated an address it has allocated.
   - Routers MUST route this protocol to ensure it spans the entire
     local scope.

2.3.4  Multiple Source

   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.

   Here, the first source that needs the IP address MUST allocate the
   address, yet it may not be the host that deallocates the multicast
   address. This is because the first source may leave the multicast
   group before all the other sources stop sending packets to that IP
   multicast address. This requires, the last source using the IP
   multicast address to deallocate the IP multicast address after it
   is done sending.

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - When more than one source uses an IP multicast address, the last
     host acting as a source for the IP multicast address MUST
     deallocate the IP multicast address.


2.3.5  Zeroconf and non-Zeroconf Transitions

   MADCAP is the non-zeroconf IP multicast address allocation
   protocol. Hosts MUST be able to transition between MADCAP and the
   zeroconf IP multicast address allocation protocol by detecting (or
   not detecting) the presences of a MADCAP server.





   Hattig                                                  [Page 17]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   If MADCAP is detected while using zeroconf IP multicast address
   allocation, the host must start utilizing MADCAP. If MADCAP is no
   longer detected while using MADCAP, the host must start utilizing
   the zeroconf IP multicast address allocation protocol.

2.3.6  Requirements Summary

   Zeroconf IP multicast address allocation protocol requirements
   are:
   - A host that wishes to allocate a multicast address with a given
     scope and lifetime MUST select an address.
   - A host MUST determine if the address has been allocated by
     another host.
   - A host MUST participate to defend the addresses it allocates.
   - At various times a host MUST actively determine if another host
     has allocated an address it has allocated.
   - Routers MUST route this protocol to ensure it spans the entire
     locally scoped internet.
   - The protocol MUST allow the last source that uses a multicast
     address to deallocate the multicast address regardless of which
     node allocated the address.
   - If MADCAP is detected while using zeroconf IP multicast address
     allocation, the host must start utilizing MADCAP.
   - If MADCAP is no longer detected while using MADCAP, the host
     must start utilizing the zeroconf IP multicast address
     allocation protocol.

2.3.7  IPv6 Considerations

   To date, no range has been reserved for dynamic allocation of
   Single-source addresses in IPv6.  Hence, until such a range is
   reserved, dynamic allocation of Single-source 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.

2.4 Service Discovery Scenarios

   [MODIFY MODIFY MODIFY ] As stated earlier, there is not really a
   non-zeroconf service discovery protocol; instead, the service
   discovery protocol must scale to larger networks. For this reason
   there are no transitional scenarios related to service discovery.
   The scenarios are the discovery of a simple printer service and
   the discovery of a printer manager that consolidates many printer
   services.





   Hattig                                                  [Page 18]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


2.4.1  Printer Service

   Networked enabled printers allow various networked clients to
   submit print jobs.  A service discovery protocol MUST allow a
   printing client to discover the printer service. This requires a
   service type as well as a service identifier to distinguish
   instances of a single service type.

   Discovery MUST be possible by either the client actively
   soliciting the server or by the server advertising then the client
   passively listening for the advertisements. Once a client finds
   the printer, it can utilize different printing protocols such as
   raw tcp, lpd, and ipp.

   Printers vary in their characteristics such as location, status,
   dots per inch, drivers, etc. Discovering these characteristics
   MUST be part of the service discovery protocol. Some service
   specific protocols allow the client and server to negotiate the
   use of these characteristics after the service is found; thus,
   alleviating the need for the service discovery protocol to
   discover by characteristic. However, characteristic discovery MUST
   be part of the service discovery protocol for those services
   without capability negotiation.

   Within a short number of seconds after activating a print server,
   a user who is actively browsing for a printer MUST be able to see
   the device appear in a browser window, or a user application such
   as a spreadsheet MUST be able to begin using the print service.
   This requires the service discovery to be timely.

   In the case of a printer service, a printer may be temporarily
   taken off-line for repair or everyday maintenance. This requires
   clients to be able to rediscover a service.

   A discovery protocol itself MUST NOT require configuration. Note
   that configuration of the service discovery protocol is not to be
   confused with the configuration of the client or server protocol
   which places no requirements on the service discover protocol.

2.4.2  Printer Manager

   A printer manager acts as a proxy to various printers. A printer
   manager improves scalability by providing a single location from
   which clients can find all printers.

   In addition, a printer manager provides an evolutionary path for
   service discovery deployment. For example, if an existing printer
   does not support the zeroconf service discovery protocol, the
   printer manager can use a legacy printer specific protocol to
   learn the existence and characteristics of a printer then expose



   Hattig                                                  [Page 19]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   that printer and its characteristics through the zeroconf service
   discovery protocol. This allows new printer clients that support
   the service discovery protocol to discover legacy printers that do
   not support the zeroconf service discovery protocol.

   A print manager requires a registry to cache information about
   services and characteristics of services. Clients MUST be able to
   extract data from the registry without knowledge that they are
   talking to a registry. In other words, the client and server sides
   of the service discovery protocol MUST NOT be any different
   whether a registry is involved or not. Registry updates that
   maintain the registry are required of the service discovery
   protocol but are optionally implemented for a particular service;
   this allows legacy protocols or the zeroconf service discovery
   protocol to update and maintain the registry.

2.4.3  Requirements Summary

   Zeroconf service discovery protocol requirements are:
   - The protocol MUST allow a client to discover the service by a
     service type, service identifier, and service characteristics.
   - The protocol MUST support solicitations and advertisements.
   - The protocol MUST be independent from any particular service.
   - The protocol MUST allow timely discovery of a service.
   - The protocol MUST allow clients to rediscover a service.
   - The protocol MUST NOT require user configuration.
   - The protocol MUST allow for registry.
   - The protocol MUST allow the client and server sides of the
     protocol to interact identically with and without a registry.
   - The protocol MUST include optional mechanisms to update a
     registry.

2.4.4  IPv6 Considerations

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

3  Security Considerations & Requirements

   By definition security requires configuration. Security examples
   include a configured key for payload encryption, user entered
   passwords for conditional access, and an administrator configures
   port mappings to enable a protocol to traverse a firewall. The
   configuration required by security is in direct conflict with the
   design goals of zeroconf protocols; however, security requirements
   take precedence over zeroconf protocol design goals.

   Given this reality, this section focuses on the minimal
   configuration necessary to make zeroconf protocols secure. In




   Hattig                                                  [Page 20]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   addition, this section describes four types of general threats and
   how those general threats apply to each protocol area.

   The general threats are:

   Hoarding: Hosts claim all available resources, whether they plan
   to use them or not.  This is a form of denial of service attack.

   Masquerading: Hosts can respond to requests that they should not
   so they can masquerade as another host.

   Antagonistic Server: A server could offer support for a critical
   service but intentionally misconfigure hosts on the network.

3.1 IP Host Configuration

   Threats include:
   - A host could hoard IP addresses.

   If secure zeroconf IP host configuration is required, all hosts
   MUST be certifiable as valid participants. In addition, a host
   MUST be configured with some security information. Furthermore,
   some security information must be part of every zeroconf IP host
   configuration packet.

   Here is an example to illustrate: All hosts are registered as
   valid security participants by the manufactures before the product
   ships. In addition the product is shipped with a private key.
   Before the secure device communicates with another secure device
   it gets the other deviceÆs registered info, then submits that
   registered info to the registration authority to get the devices
   public key. Of course this request is encrypted. From that point
   on all packets are encrypted using a public key and a private key.

3.2 Domain Name to IP Address Resolution

   Potential threats include:
   - A host could masquerade by responding to names requests
     illegitimately.
   - A host could hoard names by responding to all 'claim' requests.

   Hosts MUST be able to be configured to use a zeroconf protocol for
   domain name to IP address resolution securely.  For example, a
   'reply' from the resolution protocol could be accompanied by
   a 'signature' which could be verified before being accepted.
   The security configuration would have to provide the server
   portion of the protocol with the data needed to produce a
   'signature' which could only be produced if in possession of the
   configuration data.




   Hattig                                                  [Page 21]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


3.3 IP Multicast Address Allocation

   Potential threats include:
   - A host could hoard multicast addresses by denying others the
     ability to obtain them.
   - A host could snoop to learn all used IP multicast addresses in
     use then reconfigure the border router to allow IP multicast
     data to go beyond the desired boundary.

   Hosts MUST be able to be configured to use a zeroconf protocol for
   multicast address allocation securely.  For example, a claim and
   defend protocol used for multicast address allocation would have
   to include security data with all messages.  A host in the
   zeroconf network could verify that another host's claim was
   legitimate or not.

3.4 Service Discovery

   Potential threats include:
   - Servers could masquerade by responding to service discovery
     requests that they shouldn't respond to.
   - A host could pose as an antagonistic service discovery
     'infrastructure element.' Some service discovery protocols
     offer a 'registry', 'directory', 'proxy' or other
     infrastructure element for scalability.

   The service discovery protocol MUST provide mechanisms that allow
   a client to determine if both the service it discovers and the
   service discovery protocol infrastructure it uses to discover
   services are 'legitimate.'

   The service discovery protocol MUST provide mechanisms that allow
   a client to determine if both the service it discovers and the
   service discovery protocol infrastructure it uses to discover
   services are 'legitimate.'

3.5 IPv6 Considerations

   [TBD]

4  IANA Considerations

   There are no known IANA considerations arising from this document.

5  Full Copyright Statement

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

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise



   Hattig                                                  [Page 22]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   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."

6  Acknowledgements


   Thanks to Peter Ford for hosting the first 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.

   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.

   Editor:

   Myron Hattig
   Intel Corporation



   Hattig                                                  [Page 23]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   2111 NE 25th Ave.  JF3 206
   Hillsboro, OR 97124
   myron.hattig@intel.com


7  References

   [STD 3]      R. Braden  Requirements for Internet Hosts --
                Communication Layers  RFC 1122, STD 3, October 1989

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

   [RFC 1001]   PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
                TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987

   [RFC 1002]   PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
                TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March
                1987

   [RFC 1034]   P. Mockapetris, Domain Names - Concepts and
                Facilities, RFC 1034, November 1987

   [RFC 1458]   R. Braudes, Requirements for Multicast Protocols, RFC
                1458, May 1993

   [RFC 1918]   D. Karrenberg, et al, Address Allocation for Private
                Internets, RFC 1918, Feb 1996

   [RFC 2026]   S. Bradner, The Internet Standards Process --
                Revision 3, RFC 2026 Oct 1996

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

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

   [RFC 2132]   S. Alexander, R. Droms  DHCP Options and BOOTP Vendor
                Extension RFC 2132, March 1997.

   [RFC 2316]   S. Bellovin, Report of the IAB Security Architecture
                Workshop, RFC 2316, April 1998

   [RFC 2365]   D. Meyer  Administratively Scoped Multicast Address
                RFC 2365,July 1998.

   [RFC 2401]   S. Kent, Security Architecture for the Internet
                Protocol, RFC 2401, Nov 1998




   Hattig                                                  [Page 24]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   [RFC 2411]   R. Thayer, IP Security Document Roadmap, RFC 2411,
                Nov 1998

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

   [RFC 2462]   S. Thomson, T. Narten  IPv6 Address Autoconfiguration
                RFC 2462, December 1998.

   [RFC 2504]   E. Guttman, Users' Security Handbook, RFC 2504, Feb.
                1999

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

   [RFC 2609]   E. Guttman, C. Perkins, J. Kempf  Service Templates
                and service: Schemes,  RFC 2609, June 1999.


   [RFC 2730]   iS. Hanna, B. Patel, M. Shah,  Multicast Address
                Dynamic Client Allocation Protocol (MADCAP)  draft-
                ietf-malloc-madcap-05.txt Dec 1999.

   [AutoMcast]  D. Thaler, B. Adoba, Multicast Address Allocation in
                Auto-Configured Networks, draft-thaler-zeroconf-
                multicast-00.txt, Oct 1999. A work in progress

   [AutoNet]    R. Troll  Automatically Choosing an IP Address in an
                Ad-Hoc IPv4 Network  draft-ietf-dhc-ipv4-autoconfig-
                04.txt  April, 1999. A work in progress.

   [MCAST DNS]  B. Woodcock, B. Manning  Multicast Discovery of DNS
                Services draft-manning-multicast-dns-01.txt
                December, 1998. A work in progress.

   [MiniDHCP]   Bernard Aboba, Auto-Addressing in Multi-segment
                Networks, draft-aboba-zeroconf-multi-00.txt, Oct
                1999. A work in progress.
   [SSDP]       Y. Goland et al, Simple Service Discovery Protocol,
                draft-cai-ssdp-v1-02.txt, June 1999,  A work in
                progress.

   [IPv6 WG]    IP Next Generation WG,
                www.ietf.org/html.charters/ipngwg-charter.html.

   [DHC WG]     Dynamic Host Configuration WG,
                www.ietf.org/html.charters/dhc-charter.html.




   Hattig                                                  [Page 25]


   Internet Draft      draft-ietf-zeroconf-reqts-03.txt     Mar 2000


   [NAT WG]     Network Address Translation WG,
                www.ietf.org/html.charters/nat-charter.html.

   [DNSEXT WG]  DNS Extension WG,
                http://www.ietf.org/html.charters/dnsext-charter.html

   [MALLOC WG]  Multicast Allocation WG Charter,
                www.ietf.org/html.charters/malloc-charter.html.













































   Hattig                                                  [Page 26]