INTERNET-DRAFT J. Linton Date: December 2002 EarthLink Expires: June 2003 G. Chelius draft-linton-zerouter-requirements-00.txt INRIA Zerouter Protocol Requirements Status of this Memo 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 This document provides requirements for protocols addressing Zero-configuration routing, known as "Zerouter" protocols. It identifies requirements applicable to any of various approaches that may be proposed to this problem space, and is provided with the aim of ensuring complete and secure protocol definition. Scope is defined to ensure operation compatible with existing protocols while minimizing overlap with other ongoing work. Linton/Chelius [Page 1] INTERNET-DRAFT Expires: June 2003 December 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Key Words. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Problem Space . . . . . . . . . . . . . . . . . . . . . 3 4.2. Media Type Support and Layer-2 Default Parameters . . . 3 4.3. Topology Considerations . . . . . . . . . . . . . . . . 4 4.4. Adaptive Operation. . . . . . . . . . . . . . . . . . . 4 4.5. Coexistence with Manual Configuration . . . . . . . . . 4 4.6. Extensibility of Configuration Parameter Distribution . 5 4.7. Host Addressing . . . . . . . . . . . . . . . . . . . . 5 4.8. Prefix Delegation and Configuration . . . . . . . . . . 5 4.9. Management. . . . . . . . . . . . . . . . . . . . . . . 5 4.10. Security. . . . . . . . . . . . . . . . . . . . . . . . 6 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Recent months have seen the widespread introduction of Home Gateway, NAT and other commodity router products which greatly increase the level of networking capability available in homes and small offices without the need for sophisticated knowledge of network engineering. Home and Professional operating systems have likewise undergone increases in capability with a minimal need for manual configuration. In the same vein, a new movement toward zero-configuration routing is being addressed under the title "Zerouter", which aims to define protocols which enable standards-based IP routing over an arbitrary network topology without user intervention. This document describes this problem space, and captures the commonly understood requirements which such protocols must meet in order to be implemented in a practical, secure, and interoperable fashion. 2. 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 [KEYWORDS]. Linton/Chelius [Page 2] INTERNET-DRAFT Expires: June 2003 December 2002 3. Terminology - zerouter interface : a router interface configured by a zerouter protocol. - zerouter link : a link with one or more zerouter interface attached to. - prefix configuration : attribution of one or several valid IP prefixes to an autoconfigured link. - prefix delegation : delegation of a prefix from a non zerouter host or router to a zerouter. 4. Requirements 4.1. Problem Space The aim of a zerouter protocol is to automatically - with no manual intervention - configure all router parameters required to enable networking in a given topology. Zerouter protocols must be able to operate over complex topologies including multiple interconnected links, possible loops and with potentially multiple media types including wireless ones. Routing is out of the scope of zerouter. However, the configuration of parameters required for the bootstrap of routing protocols must be performed by zerouter protocols. This automatic configuration must include the prefix configuration of all zerouter links. Links must be attributed a prefix for all ISP delegated prefix spaces. The prefix configuration mechanism must be efficient, in the sense that it must converge if the prefix space size is greater or equal to the number of zerouter links. This convergence must be achieved in a reasonnable amount of time. 4.2. Media Type Support and Layer-2 Default Parameters Zerouter solutions must function on broadcast media such as IEEE 802.3/Ethernet, 802.11/WiFi and point-to-point links. Support for non-broadcast media types is not required but may be included. Solutions capable of operating on diverse media types are considered desirable. Zerouter protocols are not required to configure any link specific or layer-2 parameter. Standardization of default layer-2 parameters necessary for interoperable implementation is not specifically excluded from the scope of work, but no such specification should be Linton/Chelius [Page 3] INTERNET-DRAFT Expires: June 2003 December 2002 included in Zerouter protocol standards documents. To the extent that such specification is needed, if any, it will be addressed in separate documents. 4.3. Topology Considerations Zerouter protocols are expected to operate in contiguous zones of zerouter interfaces. Operation across discontiguous topologies such as non-zerouter interfaces is out of scope, though solutions addressing these areas may be considered valuable. Zerouter protocols must operate correctly in Internet connected networks, and must correctly support multi-homed networks without allowing transit routing between Internet links. Zerouter solutions must operate correctly on networks of small and medium size, i.e. 1 to 20 routers. Scalability to larger networks is not required but is desirable. 4.4. Adaptive Operation Solutions are expected to deal gracefully with topological changes in the network. This includes, for example, the addition or removal of routers and bridges between auto-configured LANs or the attachment of the network to a new ISP. Zerouter protocols should address the possibility of distributing and reclaiming prefix space delegated into or reclaimed from the zerouter zone by an ISP connection or other external source. Such mechanisms should be compatible with existing defined prefix delegation mechanisms; definition of new prefix delegation mechan- isms is out of scope and should be avoided. Topology changes may lead to collisions between auto-configured prefixes. A zerouter protocol must detect collisions and reconfigure the network to reenter a valid state. Collision detection and network reconfiguration should be performed in as little time as practical. 4.5. Coexistence with Manual Configuration Solutions are expected to coexist gracefully with configured networks and must not interrupt their function. Solutions must operate regardless of whether they are connected to the Internet or not. It is expected that in some cases users will construct a network using zeroconf and then perform some level of manual configuration afterward; automatically configured routers must Linton/Chelius [Page 4] INTERNET-DRAFT Expires: June 2003 December 2002 continue to interoperate correctly with manually configured ones in this situation. It should be possible to manually configure zerouter interfaces. Manual configuration should not disrupt zerouter auto-configuration mechanisms on the changed interface and must not disrupt zerouter operation on other interfaces. Zerouter protocols must support the ability to disable zerouter behaviour on an interface and make it manually configured. When a zerouter interface is also manually configured, the collision detection mechanism of the zerouter protocol should also apply to any manually configured prefixes. In other words, collisions should be resolved between auto-configured prefixes and manually configured prefixes of zerouter interfaces. A zerouter protocol is not required to probe for collisions between auto-configured prefixes and prefixes advertised by non-zerouter interfaces (manually-only configured interfaces). 4.6. Extensibility of Configuration Parameter Distribution Zerouter solutions must include a mechanism for the distribution of most-basic configuration parameters to autoconfigured routers. This mechanism should be specified using an extensible format in order to address future requirements, but initially may specify no more detail than is necessary for proper (and secure) operation in the accepted use cases. 4.7. Host Addressing Definition of a host addressing method is out of scope. Zerouter protocols should be compatible with predefined host addressing mechanisms. A zerouter protocol must configure all parameters required to allow classical host addressing methods to work correctly (e.g. DHCP or IPv6 stateless autoconfiguration). 4.8. Prefix Delegation and Configuration Definition of a Prefix Delegation method is out of scope. Zerouter protocols should be compatible with predefined Prefix Delegation mechanisms. Definition of Prefix Configuration mechanisms, however, is in scope and must be addressed. 4.9. Management Management of zerouter operation should be addressed. Management Linton/Chelius [Page 5] INTERNET-DRAFT Expires: June 2003 December 2002 operation may be an exception to the zero-configuration guideline in that management is performed by a human operator. However management may be necessary, particularly for error diagnostic and recovery. Definition of new management mechanisms is out of scope; Zerouters should be compatible with existing management mechanisms. 4.10. Security Secure Zerouter operation must be addressed. For ease of implementation, Zerouter protocols should make use of existing security methods such as TLS, IPSec, and Layer-2 mechanisms wherever possible. Secure operation may be an exception to the zero-configuration guideline in that some minimal amount of administration may be necessary. The goal here should be to minimize it or eliminate it entirely if possible. 5. Change Log Version 00 - Initial Draft Acknowledgements We would like to thank Andrew White, Aidan Williams, Laurent Toutain, Marcus Brunner, Alexandru Petrescu, Eric Fleury, Olivier Marce, and all the participants in the Zerouter Mailing List for their individual contributions which have guided the writing of this document. References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Linton/Chelius [Page 6] INTERNET-DRAFT Expires: June 2003 December 2002 Authors' Addresses Jeb R. Linton 8235 Depot Place Manassas, VA 20112 USA email: jrlinton@ieee.org Guillaume Chelius Citi Insa-Lyon, Ares Inria Batiment Leonard de Vinci 21 avenue Jean Capelle 69621 Villeurbanne Cedex France email: gchelius@telecom.insa-lyon.fr Linton/Chelius [Page 7]