Internet DRAFT - draft-guttman-nits-reqts
draft-guttman-nits-reqts
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:13:22 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 23 Jun 1999 14:35:00 GMT
ETag: "2e9a90-9c2c-3770f094"
Accept-Ranges: bytes
Content-Length: 39980
Connection: close
Content-Type: text/plain
Internet Engineering Task Force E. Guttman
INTERNET DRAFT Editor
Sun Microsystems
23 June 1999
NITS Requirements
draft-guttman-nits-reqts-00.txt
Status of This Memo
This document is a submission by the NITS Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the nits@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 RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Networks in the Small (NITS) are a particular class of networks.
These networks may be established in the home, in small offices or
even on an impromptu basis. NITS networks typically do not have and
should not be expected to have network infrastructure such as DHCP
servers, DNS and the like. These networks may have only occasional
connectivity to larger networks where these services exist.
Typical users of NITS networks do not have the skills nor desire to
install, configure, administer or maintain networking software. To
enable IP networking in the NITS environment, protocols for automatic
configuration of hosts and discovery of services are needed which
Guttman, Editor Expires 23 January 2000 [Page i]
Internet Draft Requirements for Networks In The Small 23 June 1999
require as little memory and processor resources on hosts which
employ them as possible.
This document presents requirements for host configuration and
service discovery on NITS networks. This document also addresses how
hosts which implement NITS protocols must behave when they discover
that they are on non-NITS networks. This will ensure that NITS
protocols do not disrupt normal network operations.
1. Contributing Authors
The following authors (in alphabetical order) have contributed
to this document: Erik Guttman (Sun Microsystems), Myron Hattig
(Intel), Brent Miller, Thomas Narten, Marcia Peters (IBM Corp.), Bob
Quinn (Stardust Technologies) and John Tavs (IBM Corp.).
Guttman, Editor Expires 23 January 2000 [Page ii]
Internet Draft Requirements for Networks In The Small 23 June 1999
2. Introduction
This document will define and state the requirements for hosts
operating in Networks in the Small (NITS). These are a particular
class of networks which may be established in the home, in small
offices or even on an impromptu basis. NITS networks typically do
not have and should not be expected to have network infrastructure
such as DHCP servers, DNS and the like. These networks may only
have occasional connectivity to larger networks where these services
exist.
Typical users of NITS networks do not have the skills nor desire to
install, configure, administer or maintain networking software. For
this reason, it is imperative that NITS networks not require any
manual configuration for host parameters and that services may be
discovered easily and with the minimum of required user interaction.
Hosts present on NITS networks may have very reduced capabilities.
For this reason, the protocols used in that setting must require as
little memory and processor resources on hosts which employ them as
possible.
This document begins with a presentation of the terminology used
later on. The general goals of this document are briefly summarized
in Section 4.
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 [18].
3. Terminology
Address Assignment
Hosts require addresses in order to operate on IP networks.
When hosts lack a fixed address, they must acquire their
address via network protocols which assign it.
Announcement
This is a broadcast or multicast message which informs all
(or some subset) of hosts on a network of something. These
messages are useful for passive automatic configuration.
Client
A client is a process which communicates with a server
process running on the network. The client may initiate this
Guttman, Editor Expires 23 January 2000 [Page 1]
Internet Draft Requirements for Networks In The Small 23 June 1999
communication by sending messages over IP. Some client software
obtains service without initiating it. For example NTP clients
may simply join a multicast group and listen for messages.
Dynamic Configuration
These are parameters which are obtained on demand through the
use of network protocols such as DHCP [8] and MADCAP [21].
Host
An IP enabled device connected to a network which conforms
to host requirements [15]. This need not be a 'computer,'
the definition applies to any other device capable of network
communication.
Host Configuration
These are parameters that a host needs in order to function
on an IP network. Specifically, a host needs to know its IP
address, the subnet mask, the addresses of one or more gateway
routers and the addresses of one or more DNS servers. There
may be no gateway router or DNS server present, but this is
itself critical host configuration information.
Interface
A host's attachment point to a link. It is possible (though
unusual) for a host to have more than one interface to the
same link. Interfaces are uniquely identified by IP unicast
addresses; a single interface may have more than one such
address.
Larger Network
A larger network is in contrast to NITS. Larger networks deploy
DHCP servers or hosts with static host configuration. Larger
networks deploy routers, DNS servers and require network
administration.
Link
A communication facility or medium over which hosts can
communicate at the link layer, i.e., the protocol layer
immediately below IP.
Neighboring
Having an IP address belonging to the same subnet.
Guttman, Editor Expires 23 January 2000 [Page 2]
Internet Draft Requirements for Networks In The Small 23 June 1999
Multicast interface
An interface to a multicast link, that is, an interface to
a link over which IP multicast or IP broadcast service is
supported.
Multicast link
A link over which IP multicast or IP broadcast service is
supported.
Name Resolution
The mapping of a device identifier to a (user-friendly)
name, such as is done in DNS [1] (and can be done in other
protocols).
Router
A host that forwards IP datagrams, as specified.
Service
A service is a process running on a host which receives and
responds to messages transmitted over IP, using a particular
transport protocol and port number. It is possible that a
service is not request/reply oriented. For example if a
service spontaneously multicasts to a particular group.
Service Advertisement
A service which employs a service discovery protocol to
make itself known 'advertises' its services. The service
advertisement may be passive (in response to solicitations
for service) or active (where the service announces itself)
depending on the particulars of the service discovery
protocol. The service advertisement may or may not include the
characteristics (attributes) of a service, depending on which
protocol is used for service discovery.
Service Characteristics
Service characteristics may include server capabilities, status
and operational information (such as contact information for
repairs). These characteristics may be defined so as to be
humanly readable or to enable software only service discovery.
If a client may use service characteristics as part of Service
Discovery, the client may find a server which matches its
Guttman, Editor Expires 23 January 2000 [Page 3]
Internet Draft Requirements for Networks In The Small 23 June 1999
capabilities or requirements. If Service Discovery does not
characteristics
Service Discovery
A client requires the location and other parameters of the
service in order to contact it. A client employs a service
discovery protocol to acquire these parameters.
Smaller Network
A smaller network is 'autonomous.' The network is not a
logical part of a greater, centrally administered network.
Implication: One cannot assume the presence of services,
planning of network address space, or any administrative
configuration. Also, the network may or may not have a gateway
router. A smaller network is also 'Limited in Scale.' The
network does not serve more than a certain size community, such
as one would find in a home or small office. There may be many
services on the network, but few active clients. Implication:
NITS mechanisms may not work well if one attempts to use them
on a campus or in a large office. If these assumptions are not
true, eventually scalability considerations will emerge and a
Larger Network will be required.
Solicitation
This is a broadcast or multicast message which elicits replies
from all hosts which recognize the request applies to them.
Solicitations are useful for active automatic configuration.
Static Configuration
These are parameters which are entered manually or recorded in
persistent storage.
Subnet
Either a single subnet of a subnetted IP network or a single
non-subnetted IP network, i.e., the entity identified by an IP
address logically ANDed with its assigned subnet mask. More
than one subnet may exist on the same link.
User
A person who interacts with client software. Software
processes with no human interface may also be a 'user' of
client software.
Guttman, Editor Expires 23 January 2000 [Page 4]
Internet Draft Requirements for Networks In The Small 23 June 1999
4. General Goals
- Create no new protocols unless they're needed.
- Don't break existing networks.
- Make IP networking easier to the point where newly added devices
'just work.'
5. Scenarios and Applicability
This section describes the applicability of the requirements defined
in this document.
5.1. The home networking scenario
To illustrate the problem statement that leads to requirements, a
home networking scenario is presented. Generically, this scenario
considers the introduction of a new device into a home network.
The specific scenario presented here is that of a new computer being
introduced to an existing home network (other scenarios could also
be developed). The newly introduced computer, to be fully utilized,
needs to become a participant in the "home area network". It needs
to make itself known to the other network participants, including
services that it can offer to them (perhaps it is capable of router
functions, or has specific software services that other devices
can use). The computer also needs to become aware of the other
network participants, including services that they offer that may
be of interest (perhaps another computer in the home network offers
printing services or image capture services; the newly introduced
computer also needs to find the network access point to the larger
network).
In a home environment, these functions need to be self-configuring
(accomplished with minimal user setup and configuration). This
process should "just work", not requiring extensive user knowledge of
the network nor onerous configuration or administration processes.
This scenario assumes a home environment, although as noted above,
the problem statement and requirements that arise from this scenario
are likely to apply to other similar environments. For this
scenario, we assume that:
1. The home network is connected to a larger network (like the
Internet), but only intermittently. The home network needs
to be fully usable whether or not it is connected to the
Guttman, Editor Expires 23 January 2000 [Page 5]
Internet Draft Requirements for Networks In The Small 23 June 1999
larger network.
2. The devices in the home network use IETF protocols, having
at least IP support. The devices share a physical layer
connection.
5.2. Scalability
In this scenario, there are not the same scalability requirements
that would apply in larger networks. It is possible to use multicast
based discovery protocols that floods the entire network, for
example, where in a corporate network that would not be acceptable.
Still, there is a limit to the amount of bandwidth any operational
protocol on NITS networks should claim.
Small networks may have limited bandwidth available due to the
performance of the underlying physical layer.
There may also be many hosts on a home network. It may be the case
that a home network has hundreds or thousands embedded servers. What
distinguishes a small network from a large one is:
1. There are a limited number of users (that is people making use
of client applications). Though there may potentially be many
services, few will be in use at any given time.
2. Small networks will lack network administration and
infrastructure which provides scalable networking. For
examples, bridges and routers may not be deployed.
6. Automatic Configuration
Automatic Configuration provides hosts with the ability to operate
in the absence of static configuration and other services found in a
larger network.
6.1. Host Configuration
The fundamental configuration that a host needs to operate in a
small network is host configuration. Dynamic host configuration is
obtained using DHCP [8]. It MUST also be possible to obtain host
configuration in the absense of DHCP servers.
Guttman, Editor Expires 23 January 2000 [Page 6]
Internet Draft Requirements for Networks In The Small 23 June 1999
6.2. Service Discovery
Clients on a NITS network MUST be able to obtain service
configuration information (principally the location of services)
through the use of a service discovery protocol. This service
discovery must be both interoperable with different services from
different vendors and afford some security: It MUST be possible to
distinguish between a 'legitimate' service advertisement and one
which is not.
In larger networks, a 'centralized repository' or 'registry' for
service information provides scalability for service discovery
protocols. The service discovery protocol SHOULD enable hosts to
discover a registry automatically (if one exists), so that subsequent
service lookup and advertising operations can be done in a scalable
manner.
In the past service discovery protocols which did not address these
considerations caused scalability problems in larger networks (viz.
SAP [6], NBP [7], SMB [5]).
6.3. Service Advertising
Devices with services must be able to advertise themselves on the
network. This service advertisement must be both interoperable with
different clients from different vendors and afford some security.
The service advertisement MUST be made in such a way that the client
can determine whether the service advertisement is legitimate or not.
6.4. Client interaction with Services
The protocols which clients use to contact and communicate with
services are out of scope of this specification. NITS protocol
requirements ensure that essential configuration is obtainable from
the network. Application layer protocols SHOULD then function
equally well whether they are in a smaller or larger network.
6.5. Name resolution
DNS name resolution is a fundamental service on IP networks.
Although it is possible to perform some application layer operations
using only IP addresses, hosts SHOULD be able to perform DNS name
resolution even in the absense of DNS servers.
If a DNS server is available it MUST be used in preference to a NITS
DNS resolution mechanism.
Guttman, Editor Expires 23 January 2000 [Page 7]
Internet Draft Requirements for Networks In The Small 23 June 1999
7. Behavior when connected to a larger network
Hosts in a NITS network which is connected or reconnected with a
larger network MUST be reconfigured subsequently.
This reconfiguration has at least two results: Host configuration
will change (as hosts become aware of a gateway router, etc.)
Second, protocols which are host requirements on smaller networks
but are not applicable on larger networks MUST NOT be used. NITS
protocols which are not appropriate for larger networks MUST include
an applicability statement.
Where possible, the same protocols SHOULD be requirements for use in
smaller and larger networks as this will simplify the implementation
and operation of networking software.
7.1. Scalability Considerations
Note that in order to enable service discovery, device discovery
using protocol layers 1-4 is required. Before service discovery can
be accomplished, it is probably necessary to learn a layer-2 address
such as a MAC address or virtual circuit identifier, and/or a layer-3
address like an IP address. In considering the device discovery
process, it is important to understand the scope of the message --
how far it can travel and what blocks it.
(Consider a layer-2 service such as Ethernet broadcast, a layer
3 service such as IP multicast, and layer 4 services like a UDP
datagram to a NDS or a NetBIOS Name Server or a WINS server. Based
upon the network topology, configuration and policies, broadcast or
multicast messages might be locally confined, or they might traverse
multiple routers, perhaps being limited by filters or hop counts).
Scoping is important in discovering that a target device exists
without unnecessarily broadcasting outside the required scope and
potentially "flooding" larger and larger networks. Furthermore,
there may be multiple target devices of interest (and even invalid
duplicate devices) that appear within different scopes. Scoping is
also important in the area of security. In developing the device
and service discovery requirements and potential solutions for home
or similar environments, where "the network" may not resemble the
Internet model, scoping is an important consideration.
7.2. Use of Multicast
Global multicast addresses SHOULD NOT be used in NITS protocols
since it is possible that messages intended only for the local
unadministered network might escape and be routed to larger networks.
Guttman, Editor Expires 23 January 2000 [Page 8]
Internet Draft Requirements for Networks In The Small 23 June 1999
Administrative scoped multicast addresses [22] are intended to
localize multicast traffic and SHOULD be used in NITS protocols.
Although NITS protocols are intended to be run on small networks
they MUST not make use of multicast which would present scalability
problems if they were connected to a larger network. This could mean
that NITS protocols always behave in a way that would be appropriate
on a larger network or that hosts discover they are no longer on a
smaller network and change their behavior.
8. Enumerated Requirements for NITS hosts
The following list summarizes the requirements presented in previous
sections.
1. Hosts MUST be capable of dynamic configuration of host
configuration, whether DHCP servers or relays are present or not.
2. Hosts MUST be capable of being configured by DHCP so that they
can be reconfigured if a NITS network is (re)attached to a larger
network.
3. Clients MUST be capable of obtaining service configuration
information (principally the location of services) through the
use of a service discovery protocol.
4. Services MUST be discoverable by means of a service discovery
protocol.
5. Hosts SHOULD be able to resolve domain names even in the absense
of a DNS server.
6. Protocols specified for use in NITS networks which include an
applicability statement which states they are not appropriate
for use in larger networks MUST NOT be used in larger networks.
There MUST be a way for hosts to detect when it is inappropriate
for the protocol to be used.
7. Global multicast addresses SHOULD NOT be used in NITS protocols.
Administratively scoped multicast addresses SHOULD be used in
NITS protocols.
9. Protocols which fulfill NITS requirements
This document defines the requirements for NITS networking. It does
not enumerate the protocols which fulfill those requirements.
Guttman, Editor Expires 23 January 2000 [Page 9]
Internet Draft Requirements for Networks In The Small 23 June 1999
It is worth noting, however, that for host configuration there
are well understood protocols which will likely be part of a NITS
networking host requirement document. These include stateless
address configuration for IPv4 [10] and IPv6 [12].
10. Open Issues
10.1. Is DNS resolution in NITS a requirement?
Is DNS resolution on a NITS network really necessary? If services
can be discovered by means of a service discovery protocols, and
locations transmitted in numerical IP addresses - why are names
required? There is no name space management in a NITS network.
There is no hierarchy of domains to consider. Assuming DNS
resolution is possible on NITS in a decentralized fashion [3], how is
the name space going to be kept unique? What happens when two hosts
claim the same name?
What should we say about static configuration of DNS (if someone
manually enters host to IP address tables)?
10.2. Multicast, Administrative Multicast and MADCAP
Should multicast support be a requirement for hosts in NITS networks?
Multicast seems to be required to support service discovery and other
services like Multicast DNS [3] which are under discussion.
Should MADCAP [21] be used so that hosts can allocate and use
administrative scoped multicast addresses [22] from the smallest
enclosing scope by default? This would go a long way toward making
NITS protocols more scalable and protecting larger networks from
getting spill-over. Note that a minimal MADCAP client is really
quite small.
It may also be worthwhile discussing how MASC-like [4] claim and
defend for multicast addresses could be used in NITS when MADCAP
servers are not present.
10.3. Behavior upon receiving router advertisements
What should hosts do when they have employed stateless address
configuration and see router advertisements [14]? The hosts should
have non-routable addresses. Still, should they behave differently
when they detect a transition (when a router appears or disappears?)
Guttman, Editor Expires 23 January 2000 [Page 10]
Internet Draft Requirements for Networks In The Small 23 June 1999
10.4. IP address autoconfiguration and Ad Hoc networking
Stateless address configuration for IPv4 [10] and IPv6 [12] both
involve claim and defend mechanisms. These mechanisms will work
poorly in Ad Hoc networks [23]. MANET protocols assume all hosts
have unique addresses in order to establish routing. Ad Hoc networks
could benefit from NITS protocols in other respects as they by
definition lack infrastructure and infrastructure and may be quite
small. If stateless address configuration is a requirement for hosts
on NITS networks, a consequence may be that NITS may not apply to Ad
Hoc networks.
10.5. NITS, NAT, VPN, Securing a small network
Should NITS networking requirements include a specific list of VPN
and NAT protocol and operational requirements?
Should this document describe address sharing (a topic related to
NAT)?
What should be done about securing NITS services from abuse or
illegitimate use from clients in larger networks to which the smaller
network is connected? What are the security requirements for clients
and services on a NITS network? These cannot be very sophisticated
since a primary goal is ease of use and unskilled operators.
A possible list of requirements was proposed:
1. Allow communication from host to a corporate LAN via VPN.
2. Allow communication from host to another home-network via VPN.
3. Allow hosts in the home to simultaneously access the Internet
using 1 or 2 globally unique IP addrs.
4. Allow access from the Internet to a home-network server (e.g.
household WEB server).
5. Allow access from the Internet to multiple home servers of a
single service (e.g. personal WEB servers).
6. Protect devices, resources, and communication in the home-network
from Internet attacks.
7. Protect communication when traversing the Internet to access
corporate LAN or another home-network.
Guttman, Editor Expires 23 January 2000 [Page 11]
Internet Draft Requirements for Networks In The Small 23 June 1999
10.6. How big is small?
The approximate scale of a NITS network has been discussed on the
NITS mailing list. The very rough consensus is that it is around
10 users, 100s of hosts and 1000s of services, or smaller. If the
network has more than these numbers of entities it is not small. Of
course in small networks today we have fewer hosts and services, but
we have to consider what will happen *if we are successful.* What if
there are lots of devices enabled with the NITS protocols fulfilling
the requirements in this document?
Is it appropriate to include this discussion in the body of the
requirements document? It has been suggested that we focus on
functionality and not debate quantities in preparing this document.
10.7. Networks in the Simple?
Should we focus on 'Simple' instead of 'Small?' The difference is
instead of considering scaling issues, we are encouraged to look
at a different kind of host and a different kind of network. For
instance, we could specifically define this as Home Networks so we
could talk about Home Appliance requirements. Should we focus on
usability issues perhaps instead of how larger networks are to be
protected from poorly scalable NITS mechanisms?
Focusing on Small instead of Simple puts the focus on operation
without infrastructure and with reduce number of active client hosts.
10.8. Do we need a 'Scenarios' or 'Applications' Section?
There has been discussion of specific scenarios and applications of
NITS protocols. Would it help the clarity and motivation for the
reader of this document to include this after the introduction?
10.9. Gateway requirements and small networks
Should there be requirements on a gateway such that it automatically
(a) provides either DHCP or DHCP relay service at the least, (b)
ensures that hosts on the NITS network are configured so as to be
able to reach hosts off of the smaller network. Should this document
define gateway requirements or only host requirements?
Guttman, Editor Expires 23 January 2000 [Page 12]
Internet Draft Requirements for Networks In The Small 23 June 1999
10.10. Is service discovery conclusive?
When service discovery is successful, should the client be able to
use the service, or do we assume that it may not be able to. In the
former case service discovery finds only those services which match
the client's capabilities and requirements. In the latter case the
client may have to perform feature negociation with the service -
the result of which may be that the client is not able to use the
service.
10.11. Device identification and discovery
Should the following terms be in the terminology section? They are
problematic to define and have confused most readers.
Device Discovery
This is the protocol allowing the resolution of an identifier
to obtain the location of a device. For example, a host with
the destination IP address of another host may require its MAC
address in order to send a datagram. Protocols which enable
device discovery in this sense include ARP [24] for IPv4 and
Neighbor Discovery [13] for IPv6.
Device Identification
This is any unique identifier belonging to a host attached to
a network. An example of such an identifier is an IP address
or a MAC layer address. It is possible that other identifiers
may be used in NITS protocols (ie. a device supports a SNMP
agent).
It has been suggested that this section is an absolute must:
If devices are not self descriptive then you need an external
directory in which to look up an ID number (which will need to
be relatively unique). Having a common language for describing
capabilities is the only way you can get interoperability of
autonomous devices.
10.12. Browsing and human friendly identifiers
Should this requirement document specify how human readable
identifiers should be created to enable interoperability of browsers?
This amounts to requirements for human interfaces to the service
discovery protocol. Some issues here are:
Guttman, Editor Expires 23 January 2000 [Page 13]
Internet Draft Requirements for Networks In The Small 23 June 1999
Service type names:
To browse all the speakers in my house the service
advertisement of each speaker has to be consistent with some
standards. Only then can a service browser produce a listing
of speakers from different vendors, interoperably.
Internationalization:
Any strings which are available from NITS protocols which are
intended for human readability (ie. in a browser) MUST be
internationalizable. What does that mean, though? Are IDs
passed around for which there are standardized translations?
Should the protocols be able to support strings with different
languages?
Attributes:
Browsers which offer directory (or directory-like) functions
may provide attributes for viewing in a browser. This is in
contrast to providing only the name and descriptive text.
Attributes also make sophisticated server selection possible
as part of the human interface of the browser. The problem
is: If attributes are part of service advertisements, they
have to be standardized for interoperability. Should the NITS
requirements document describe how this is to be done?
11. IANA Considerations
There are no known IANA considerations arising from NITS protocol
requirements.
12. Internationalization Considerations
This document describes interoperability requirements for hosts on
NITS networks. These include protocols which exchange human readable
strings. Requirements which involve human readable strings include
considerations for internationalizing those strings.
13. Security Considerations
NITS protocols will enable a great deal of automatic configuration.
These present numerous opportunities for malicious masquerading as
legitimate services. NITS protocols must consider how to balance
some protection from attackers who seek to misconfigure hosts and the
zero-configuration ideal.
Guttman, Editor Expires 23 January 2000 [Page 14]
Internet Draft Requirements for Networks In The Small 23 June 1999
Some of the requirements defined by this document provide some
security properties to protect client hosts in NITS networks. These
include the requirement that the service discovery protocol enable
a client to determine if a service advertisement is 'legitimate' or
not.
It is clear that this document needs to define the class of threats
which are present when NITS protocols are employed. Do these threats
arise from adversaries *on* the NITS network? Do we have to consider
threats which arise from adversaries in a larger network which is
impermanently connected to the smaller network?
Guttman, Editor Expires 23 January 2000 [Page 15]
Internet Draft Requirements for Networks In The Small 23 June 1999
14. 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 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."
References
[1] P. Mockapetris Domain Names - Concepts and Facilities RFC 1034,
November 1987
[2] A. Gulbrandsen, P. Vixie A DNS RR for specifying the location of
services (DNS SRV) RFC 2052, October 1996.
[3] B. Woodcock, B. Manning Multicast Discovery of DNS Services
draft-manning-multicast-dns-01.txt December, 1998. A work in
progress.
[4] D. Estrin, et. al. The Multicast Address-Set Claim (MASC)
Protocol draft-ietf-malloc-masc-01.txt February, 1999. A work
in progress.
[5] Microsoft Networks SMB File Sharing Protocol Extensions 3.0
Document Version 1.09, November 1989
Guttman, Editor Expires 23 January 2000 [Page 16]
Internet Draft Requirements for Networks In The Small 23 June 1999
[6] Novell, Inc. IPX RIP and SAP Router Specification Part Number
107-000029-001, Version 1.30, May 1996
[7] S. Gursharan, R. Andrews, and A. Oppenheimer Inside AppleTalk
Addison-Wesley, 1990.
[8] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997.
[9] S. Alexander, R. Droms DHCP Options and BOOTP Vendor Extension
RFC 2132, March 1997.
[10] 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.
[11] R. Troll DHCP Option to Disable Stateless Auto-Configuration
in IPv4 Clients draft-ietf-autoconfig-04.txt February, 1999. A
work in progress.
[12] S. Thomson, T. Narten IPv6 Address Autoconfiguration RFC 2462,
December 1998.
[13] T. Narten, E. Nordmark, W. Simpson Neighbor Discovery for IP
Version 6 (IPv6) RFC 2461, December 1998.
[14] S. Deering ICMP Router Discovery Messages RFC 1256, September
1991.
[15] R. Braden Requirements for Internet Hosts -- Communication
Layers RFC 1122, October 1989
[16] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol version 2. RFC 2608, June 1999.
[17] E. Guttman, C. Perkins, J. Kempf Service Templates and service:
Schemes RFC 2609, June 1999.
[18] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[19] H. Alvestrand Language Tags RFC 1776, July 1994.
[20] F. Yergeau. UTF-8, a transformation format of unicode and ISO
10646. RFC 2279, October 1998.
[21] iS. Hanna, B. Patel, M. Shah Multicast Address Dynamic Client
Allocation Protocol (MADCAP) draft-ietf-malloc-madcap-05.txt
May 1999. A work in progress.
Guttman, Editor Expires 23 January 2000 [Page 17]
Internet Draft Requirements for Networks In The Small 23 June 1999
[22] D. Meyer Administratively Scoped Multicast Address RFC 2365,
July 1998.
[23] IETF MANET WG MANET WG Charter http://www.ietf.org/
[24] D. Plummer An Ethernet Address Resolution Protocol RFC 826,
November 1982
Guttman, Editor Expires 23 January 2000 [Page 18]
Internet Draft Requirements for Networks In The Small 23 June 1999
Editor's Address
Questions about this memo can be directed to:
Editor:
Erik Guttman
Sun Labs - Networking and Security - Advanced Development
Sun Microsystems, Inc.
Bahnstr. 2
74915 Waibstadt
Germany
phone: +49 7263 911 701
or: +1 650 786 5992
email: Erik.Guttman@Sun.Com
Guttman, Editor Expires 23 January 2000 [Page 19]
