One document matched: draft-ietf-zeroconf-reqts-07.txt
Differences from draft-ietf-zeroconf-reqts-06.txt
Zeroconf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires Sept 2001 March 2, 2001
Zeroconf Requirements
draft-ietf-zeroconf-reqts-07.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 [RFC 2131], DNS [RFC
1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be
configured and maintained by an administrative staff. This is
unacceptable for emerging networks such as home networks,
automobile networks, airplane networks, or adhoc 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 (zeroconf)
protocols.
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
Before embarking on defining zeroconf protocols, protocol
requirements are needed. This document states the zeroconf
protocol requirements for four protocol areas; this document does
not define specific protocols. The four areas are: IP interface
configuration, translation between host name and IP address, IP
multicast address allocation, and service discovery. The
requirements for these four areas result from examining everyday
use or scenarios of these protocols.
Table of Contents
1 Introduction................................................2
1.1 Key words.................................................3
1.2 Reading This Document.....................................3
1.3 Zeroconf Coexistence......................................3
1.4 Scalability...............................................3
1.5 Routable Protocol Requirement.............................3
1.6 Conflicts and State Changes Requirement...................4
2 Scenarios & Requirements....................................4
2.1 IP Interface Configuration................................4
2.2 Translation between Host name and IP Address Scenarios....6
2.3 IP Multicast Address Allocation Scenarios.................7
2.4 Service Discovery Scenarios...............................9
3 Security Considerations....................................10
3.1 IP interface configuration...............................11
3.2 Name to Address Resolution...............................12
3.3 Service Discovery........................................13
3.4 Multicast Address Allocation.............................13
4 IANA Considerations........................................14
5 Full Copyright Statement...................................14
6 Acknowledgements...........................................14
7 References.................................................15
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 [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.
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:
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
- IP interface configuration
- Translation between host name and IP address
- IP multicast address allocation
- 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 [RFC
2119].
1.2 Reading This Document
Introduction, Scenarios & Requirements, and Security
Considerations are the major sections of this document.
The Scenarios & Requirements section walks 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 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 might 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.
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.
1.5 Routable Protocol Requirement
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
If a protocol is intended to span multiple IP subnets it SHOULD
NOT use broadcasts or link-local addressing.
Requirement:
- Protocols intended to span multiple IP subnets SHOULD NOT use
broadcasts or link-local addressing.
1.6 Conflicts and State Changes Requirement
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.
Requirement:
- MUST respond to state changes and resolve conflicts in a timely
manner.
2 Scenarios & Requirements
This section contains a subsection for each of the four protocol
areas. Within each subsection, terms and assumptions are followed
by specific representative scenarios that lead to zeroconf
protocol requirements in that area. Each subsection ends with an
IPv6 considerations section.
2.1 IP Interface Configuration
In this document, configuration of an IP interface on a host is IP
interface configuration. IP interface configuration always
includes the configuration of an IP address and netmask; it may
include some routing information (e.g. 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 - context sensitive term that may apply to one or more
of the terms: link layer network, IP subnet, or internet.
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
bridge - a networking device that connects two link layer
networks by using only link-layer protocols (e.g. Ethernet).
IP interface configuration scenarios are two IP packet-sending
scenarios and a bridge install scenario.
2.1.1 IP Packet-Sending
These scenarios consist of sending an IP packet from one host to
another. These scenarios apply to any IP packets with a unicast
destination IP address. There are two sub-scenarios. In the first,
both the sender of the IP packet and the receiver of the IP packet
are on the same IP subnet. In the second, the two senders are on
different IP subnets within an internet.
Requirements:
- MUST determine the netmask for an IP subnet.
- MUST have unique IP addresses within an IP subnet.
- MUST have some routing information (for the internet scenario).
- MUST have unique IP subnets within an internet (only for the
internet scenario).
2.1.2 Bridge Installed
This scenario starts with two completely operational link-layer
networks with two distinct IP networks in which IP interface
configuration was completed with a zeroconf protocol on each
network. These two link-layer networks logically become a single
link-layer network after a newly installed bridge connects them.
Somehow the hosts operating on the two IP networks must now
configure themselves to operate as a single IP network. Since the
bridge connects the networks at the link-layer, there is no change
in link status from off to on, which is the usual signal used in
Ethernet networks for IP hosts to configure.
Topology changes from the installation of a bridge or a router may
create the following problems: inconsistent netmasks that cause IP
hosts to be on different IP subnets when they should be on a
single IP subnet, 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
internet.
Requirement:
- MUST resolve conflicts and state changes in a timely manner.
2.1.3 IPv6 Considerations
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
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.
2.2 Translation between Host name and IP Address Scenarios
Host names allow users to refer to hosts by name instead of IP
addresses. This is among the most fundamental, thus most
important, usage paradigms in TCP/IP networking.
Terms:
host name - A textual name that allows a user to refer to a host
by name rather than IP address.
domain name - Zero or more textual labels, separated by dots,
that identify a DNS domain [RFC 1034] [RFC 1035].
resolver - The host needing a name to IP address translation.
The scenarios for translation between host name and IP address are
Web browsing and host name lookup by a game. In addition, host
name selection is discussed.
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.
The name of a Web server may be within the same domain along with
the name of the resolver or may be part of some other domain.
Requirement:
- MUST translate a name to an IP address.
- MUST translate an IP address to a name.
2.2.2 Host Name Selection
How the host gets its name (or Domain Name [RFC 1034]) is part of
some other configuration protocol or user configuration, and is
not part of this zeroconf scenario. This scenario deals with hosts
on a network selecting and operating with unique names. A protocol
must allow a host to determine if its name is unique. If the name
is not unique, the protocol must notify the user or some IP
interface configuration software to select another name then
repeat the process of verifying the uniqueness of the name.
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
Requirement:
- MUST allow a host to determine if its name is unique. Then if
not unique, notify the user or configuration software so that
another name may be chosen and similarly verified.
2.2.3 IPv6 Considerations
Protocols to perform translation between host name and IP address
have no zeroconf related differences for IPv4 and IPv6.
2.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) .
IP multicast addresses range from 224.0.0.0 to 239.255.255.255.
[RFC 2365] defined multicast scopes are:
node-local (unspecified)
link-local (224.0.0.0/24)
local (239.255.0.0/16)
site-local (unspecified)_
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 [SSM] addresses are 232.0.0.0 to
232.255.255.255.
Assumptions:
- The node-local and SSM addresses require no protocol or
interaction between multiple hosts, thus are not mentioned
further in this document.
- Global and organizational scoped addresses are meant for
networks of a greater scale than zeroconf protocols, thus are
not mentioned further in this document.
- Only local, link-local and site-local scopes are considered
further in this document.
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
- 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
[RFC 2365].
Scenarios are scope enumeration, address allocation, and multiple
sources.
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.
2.3.2 Address Allocation
IP multicast address allocation (local, link-local and site-local
scopes only) requires a host to specify a given scope, the number
of addresses, and a time before the allocation expires.
Coordination among hosts must occur to avoid allocating the same
address more than once. This coordination must span the entire
scope respective to the address. Upon deallocation or expiration
of an address, the address MUST become available to use again.
Requirements:
- MUST select a multicast address with a given scope and lease
time.
- MUST ensure address is not allocated more than once within the
scope of the address.
- MUST allow the multicast address to become available for use
again after the address expires or becomes deallocated.
2.3.3 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.
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.
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
Also, with a claim and defend protocol, usually the allocating
host is responsible for defending an address; however, the host
may not be available to defend. Despite the unavailability of the
allocating host, the multicast address must still be deallocated
when it is no longer needed and must still be defended from
incorrect use while other hosts are using it.
In other words, if the a host allocates a multicast address, then
leaves the multicast group, some other host must be designated to
defend and deallocate the address.
Requirements:
- A host other than the allocating host MUST be able to deallocate
and defend a multicast address.
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.
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.
Terms:
service - an instance of an implementation of a particular
logical function that may be accessed through some 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 a clients to discover a servers (or peers to find other
peers) of a particular service. A service discovery protocol is
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
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.
2.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:
- MUST allow a service to be discovered.
- MUST discover via service identifier and/or service type.
- MUST discover services without use of a service specific
protocol.
- SHOULD discover via service characteristics.
- MUST complete in a timely (10s of seconds) manner.
2.4.2 IPv6 Considerations
Service discovery protocols have no zeroconf related differences
for IPv4 and IPv6.
3 Security Considerations
The principal goal of Zero Configuration protocols is to provide
network configuration where existing configuration and
configuration services are unavailable. This is at odds with
secure operation since security mechanisms generally require some
pre-configuration (such as keys, certificates, etc.).
Generally speaking, security mechanisms in IETF protocols are
mandatory to implement. However, a particular implementation
might permit a network administrator to turn off a particular
security mechanism operationally. However, implementations should
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
strive to 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.
This section explicitly describes what this requires of each
protocol area.
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, ESP, AH) appropriate to the threat.
3.1 IP interface configuration
Specific risks arise due to not securing IP interface
configuration. An active attacker could completely or selectively
prevent hosts from being properly configured. If an attacker
'hoards' all IP addresses, inappropriately claiming to be
configured with them, this would prevent other hosts from
effectively participating in IP interface configuration.
An active attacker could be more selective and instead of claiming
it has all IP addresses, it could claim this only in response to
requests from a specific host (or hosts) to deny them service. It
might also be possible that an active attacker could partially
misconfigure one or more victims to cause these nodes to have
partial (but not full) use of the network service.
IP communication relies on lower level address resolution
protocols (ARP [RFC 826] or IPv6 Neighbor Discovery [RFC 2461]).
In the case of ARP and its cousins (e.g. inverse ARP, reverse ARP,
proxy ARP), there is no standard security mechanism. Neither the
integrity of the message nor the endpoint authentication is
checked. This makes it possible for an active attack to subvert
both of these protocols. Since the scope of these protocols is
limited to a single broadcast network, the potential range of the
risk due to this attack is limited. The effect of the attack,
however, is to potentially disrupt all communication on the local
link.
It is appropriate to not require IP interface configuration
protocols to implement security mechanisms when these hosts (and
others) will then proceed to perform subsequent communication
using insecure mechanisms such as ARP. Thus hosts using insecure
IP interface configuration are ultimately no more vulnerable to
attack than other hosts on the network configured using some other
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
more secure mechanism. The security requirements demand that
zeroconf protocols MUST NOT compromise security if security is
deployed. In the case of IPv4, it is acceptable (though not
desirable) that interface configuration is insecure since the
existing IPv4 address resolution mechanism is already insecure.
For that reason the IPv4 interface configuration protocol MAY
include no security mechanisms.
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).
In the case of IPv6 Neighbor Discovery, this protocol can be
secured as it uses ICMPv6 messages, which run over IP. IPv6
Neighbor Discovery messages can thus be protected for integrity
and endpoint authentication using IP Security. [RFC 2401, 2402,
2403, 2404]
3.2 Name to Address Resolution
The security implications of this zeroconf protocol must be
compared against the DNS protocol.
DNS is a client-server protocol. The zeroconf name to address
translation protocol will likely use multicast so that any host
may respond to queries. This broadens the possibility that host
authentication in the form of hostname-IP address mappings may be
compromised, since all hosts effectively may behave as DNS
servers.
Currently it is possible to subvert DNS in various ways, unless
DNSsec [RFC 2535, 2931] is used. For example:
- A client may be configured with the address of an attacker's DNS
server. For example, an active attacker on the same subnet as
the client may respond to DHCP DHCPDISCOVER messages and
deliberately configure the client to use a compromised DNS
server.
- An active attack against a DNS client is possible - where an
attacker unicasts a DNS reply to a client request that arrives
at the client before the legitimate server's response.
DNSsec protects against such attacks as the client can verify that
the data it retrieves using the DNS has been signed from a source
that the client has been configured to accept.
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
A zeroconf name to address resolution protocol MUST be compatible
with the use of DNSsec. Therefore it MUST be possible for a host
running a zeroconf protocol to use DNS and DNSsec for
authenticated name resolution if that host (or its
administrator) chooses to do so. [RFC 2541]
3.3 Service Discovery
The zeroconf service discovery protocol MUST NOT be less secure
than the IETF standard service discovery protocol: The Service
Location Protocol, Version 2 [RFC 2608] (SLPv2).
The threat posed by using an insecure service discovery protocol
is that unauthorized entities may participate. A client may be
misled to communicate with a host that has been compromised or
that offers an antagonistic server that the client did not intend
to use. This might be easy to detect (e.g. after attempting to
use a printer that doesn't exist, no printed upon paper appears.)
This may also be difficult to detect (e.g. an illegitimate server
copies all data for an attacker's subsequent perusal and the user
has no way of knowing).
A client could still detect that it is communicating with an
unauthorized server, but that would require authentication and
authorization mechanisms at a higher level (the client-server
protocol).
SLPv2 protects against the threat of discovery of unauthorized
services. SLPv2 messages that contain an answer may include an
associated authorization block. This allows a client receiving a
message to verify the answer, using digital signatures and a
certificate-based system as the basis for authorization. Other
mechanisms are possible.
A zeroconf service discovery protocol MUST allow a client to
verify that a service advertisement sent by a server was created
by an authorized source.
3.4 Multicast Address Allocation
The zeroconf multicast address allocation protocol MUST NOT be
less secure than MADCAP [RFC 2730] and AAP [AAP]. These are the
IETF standards track protocols for Multicast Address Allocation.
The threat of using an insecure Multicast Address Allocation
protocol is that an active attacker could 'hoard' all multicast
addresses - inappropriately claiming to have allocated them. This
would prevent other hosts from effectively participating in the
Multicast Addresss Allocation protocol. This could be done to
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
stop all participation or selectively, to prevent particular hosts
from allocating addresses.
Both AAP and MADCAP do not include mechanisms for protecting
message integrity or end-point authentication. These protocols
suggest the use of IPsec for this purpose, as AAP and MADCAP are
compatible with the IP Authentication Header. A zeroconf
multicast address allocation protocol MUST either be compatible
with IP AH or provide another mechanism for optional-to-use (but
mandatory to implement) authentication.
4 IANA Considerations
No known IANA considerations arise from this document.
5 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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."
6 Acknowledgements
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.
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
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.
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.
Editor:
Myron Hattig
Intel Corporation
3585 SW 198th Avenue
Aloha, OR 97007
myron.hattig@intel.com
7 References
[RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol",
RFC 826, November 1982.
[RFC 1034] P. Mockapetris, Host names - Concepts and Facilities,
RFC 1034, November 1987
[RFC 1035] P. Mockapetris, Host names - Implementations and
Specifications, RFC 1034, November 1987
[RFC 1487] Yeong, W., Howes, T., and S. Kille, Lightweight
Directory Access Protocol, RFC 1487, July 1993.
[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.
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-07.txt March 2001
[RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC
2131, March 1997.
[RFC 2365] D. Meyer Administratively Scoped Multicast Address
RFC 2365,July 1998.
[RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401 November 1998
[RFC 2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC
2402 November 1998
[RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998
[RFC 2535] D. Eastlake, "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2541] D. Eastlake, "DNS Security Operational
Considerations", RFC 2541, March 1999
[RFC 2608] E. Guttman, et all, "Service Location Protocol,
Version 2", RFC 2608, June 1999
[RFC 2730] S. Hanna, B. Patel, M. Shah, Multicast Address
Dynamic Client Allocation Protocol (MADCAP), RFC
2730, Dec 1999.
[RFC 2931] D. Eastlake, "DNS Request and Transaction Signatures (
SIG(0)s )", RFC 2931, September 2000
[SSM] H. Holbrook, "Source-Specific Multicast for IP",
draft-holbrook-ssm-00.txt, March 2000. A work in
progress.
[AAP] Handley, M., Hanna, S., " Multicast Address Allocation
Protocol (AAP)", draft-ietf-malloc-aap-04.txt, June
2000. A work in progress.
Hattig [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 08:31:42 |