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]