Internet Draft O. Marce Document: draft-marce-zerouter-archi-00.txt D. Galand December 2002 Alcatel R&I, France Architecture for Zerouter 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 1 Abstract This document proposes an architecture for the self-configuration mechanisms to be used in an IP network. It identifies the entity and the relation between them. It also looks at the existing self-configuration solutions and proposals, with regards to the proposed architecture. 2 Introduction Various solutions are proposed to achieve self-configuration, at least for automatic address allocation [RefTBC]. They all address different aspects (IPv6 or IPv4, unmanaged network or delegation of management, etc.), and introduce different mechanisms, protocols or messages. The objective of this document is to give a reference architecture which can be used as a framework for the development of protocols, as well as for the comparison between proposals. 3 Functional Scopes of the self-configuration The objective of the self-configuration operation can be of different types. Among these, we distinguish the functional scopes, which define the network functions to be configured. The different functional scopes for the self-configuration which are considered for this reference architecture are the following. 3.1 IP address allocation. The issue is to allocate to the nodes an address which is unique at any given time. No assumption is made concerning the reusability of unused addresses, or the lifetime of an address. This can be done Marce, Galand [Page 1] Internet Draft Architecture for Zerouter December 2002 either for IPv4 or for IPv6. Both versions should be globally considered by the self-configuration mechanisms. This allows a consistent allocation between v4 and v6 addresses: that means that, for dual stacked nodes, it should exist a simple and unique mapping between Ipv6 prefixes and Ipv4 network address. Correct address allocation and management is needed to achieve basic reachability, so any proposed self-configuration mechanism must either address this scope or rely on an existing mechanism to achieve this allocation. In the context of IPv6 the address allocation is for prefix allocation only, the host part being considered out of scope. In the IPv4 context, this concerns to both the host and the network addresses. The issues of updating the DNS after address allocation is out of this scope and must be considered in the network service scope (see 3.3). 3.2 Routing protocols Routing protocols allow update of routing tables, in order to reflect changes in the routes (topology, capacity, cost, etc.) The issue is to initiate the correct routing protocol stack(s), with the correct initial configuration, depending of the context. The basic functionality is to deal with the initial start of routing protocol stacks. A more advanced task is to also handle the change in the network context and to stop, start or re-start routing protocol stacks in concordance. In such a case, the problem of transferring configuration from stopped stack to started one should be considered. This issue has to be addressed only for node which intend to provide dynamic routing functionality. This is typically not the case for hosts, and leaf routers which are the entry point into the routed network for the hosts. Self-configuration mechanism proposals should either explain why this issue is not related to the considered context, or how it achieve this functionality. 3.3 Network services In this document, network services refer to additional feature like, typically, support of DNS, RTP or SLP. These services are not forcedly needed for internetworking, but are of a so highly added value for end-users that they are considered as critical. The issues are depending of the considered service or protocols, but they mainly relate to the initial configuration, and to the transparent re-configuration. 3.4 Other scopes Depending on the implementation, other scopes can be also considered. In most of the cases, these are non functional scopes, typically to have a self-configuration operation restricted to an administrative domain, or to have a fully secured Marce, Galand [Page 2] Internet Draft Architecture for Zerouter December 2002 self-configuration. In this version of the document, those scopes are not highlighted. Once a basis architecture defined, these scopes would be considered, and refinements to the architecture will be defined if needed. Only some security aspects are mentioned. 4 Elements of the architecture 4.1 Entity The following entity have been identified in the reference architecture. - Self-Configurable Node (SCN): any node which supports protocol(s) related to this architecture. - Self-Configuration Authority (SCA): a SCN which is able to provide configuration to others SCN. - Self-Configuration Requestor (SCR): a SCN which requests for a configuration. Both the SCR and the SCA can have two different profiles, if it is on the same link than the other entity it communicates with, or not. 4.2 Relations The identified relations between the entities are the following. These give a high-level view of the communication between the entities. - Ra: relation between two SCAs. It allows to get info on the SCR which are known or configured by the others SCAs, and to exchange information to provide proxy to each others. This proxy relation between SCA allows delegation of authority, for example, in a hierarchical way. This relation must also provide ways to insure consistency or dependency between SCAs on the same link, and also between SCAs separated by one SCR only. - Rq: relation between an SCR and an SCA. This is the basic relation which must be provided. The SCR requests for a configuration which is returned, if authorized and allowed, by the SCA. - Rr: relation between two SCRs. A SCR can get info on available SCAs. In this case, the requesting SCRs can directly connect to the known SCAs. This relation also encompasses the relay of a SCR request to a SCA by one or more others SCRs. In addition to the three previous relations, the relation Ri is the relation between any SCN and the rest of the network of SCNs. This relation is mainly used during initial setup, in order for example, for a SCR to find a suitable SCA. All the defined relations are depicted on the following figure. Marce, Galand [Page 3] Internet Draft Architecture for Zerouter December 2002 +---------+ +---------+ Ri | | Ra | | <- - -+ SCA +<------------>+ SCA | | | | | +----+----+ +---------+ | |Rq | +----+----+ +---------+ Ri | | Rr | | <- - -+ SCR +<------------>+ SCR | | | | | +---------+ +---------+ Figure 1 Relations between entities 4.3 Functional description This section details the motivations of the relations and the exchanges which typically take place between the SCNs. The objective of this section is not to give any kind of specification for a self-configuration protocol, but it rather aims to give a description of the interactions requested for self-configuration. From a non-functional point of view, it is expected that the messages are all authenticated when the communication is multi-hop. 4.3.1 Relation Ri The objective of this relation is to make the SCNs to know their "SC environment". This means that, at least, the SCRs must be able to discover the available SCAs. The notion of the availability of SCA, from a given SCN point of view, is voluntarily let undefined at this stage. Any SCN can request for SCNs to present themselves on the network. This can be done using one of the usual known mechanisms: * Broadcast in IPv4, or reserved multicast address (e.g. all nodes link-local) in IPv6 * Anycast * Well-known address (either multicast or unicast) * SLP or similar protocol (which raises issues related to Network Service configuration) This relation encompasses different kinds of advertisements. The following are some examples of the expected features: * Every requesting nodes would present themselves in the request. * A SCA would reply to a SCR request only if it is able to provide configuration. * When the request comes from an authenticated SCAs, all the SCA would answer. * A SCN would be able to restrict the request to the link local scope only. Marce, Galand [Page 4] Internet Draft Architecture for Zerouter December 2002 * A SCN would be able to also request for other SCRs. The request would be link-local only, and all the SCRs would respond to the hello request. 4.3.2 Relation Rq This is the primary relation to be achieved, providing a client-server exchange between a SCR and a SCA. The SCR requests for configuration from a SCA. It is expected that the configuration have various scopes (see 3). The SCR would proposes the expected scope, and the SCA would give the scope of the returned configuration. Confirmation of configuration acceptance, as well as negotiation of configuration parameters are possible features which can be done in the frame of this relation. The SCA can also ask the SCR for the identity of the SCAs it received configuration, or for the id of the other known SCAs by the SCR. 4.3.3 Relation Ra The establishment of this relation means that the SCAs have a knowledge of each others. This can be done thanks to the relations Ri and with the help of relation Rq. The objective is to create a network of SCAs acting as a distributed SCA. A SCA can request to other SCAs to know the SCRs that each queried SCA have configured or have answered to. It can also request for the scope of configuration that each SCA can provide. A SCA can also ask to another SCA to act as a proxy. This request is expected to be done between SCAs which are not on the same link. The requesting SCA sends the scope of configuration that it wants to delegate. Once the second SCA accepted the delegation, the requesting SCA sends the configurations which will be served to the SCRs needing to be configured. This proxy approach allows to have a totally open hierarchy of SCA. An SCA can act as a proxy for more than one SCA, belonging to several hierarchies. 4.3.4 Relation Rr This relation is to allow the SCRs to know the SCAs available for their neighbor SCRs, with the objective either to find a backup SCA, in case of miss or shut down of the initial SCA, or to be able to check consistency between configuration between the area it connects together. A SCR can request to other SCRs to know the available SCAs. This should be issued only to destination of SCRs on the same link. In such case, the SCR receiving such request must give the list of known SCAs directly connected on the other links that those the request has been sent on. 5 Example of usage This section gives different scenarios and details how the architecture is used. Marce, Galand [Page 5] Internet Draft Architecture for Zerouter December 2002 5.1 Boot of a SCN When a SCN is booted, it first tries to establish a relation Ri on all its links. If one or more SCA answer, the SCN becomes a SCR and requests for a SCA which is able to provide the expected configuration. The SCR chooses in priority the SCA which are link-local, and which are authenticated. If no SCA answers, it should request for others SCR on the same link. In this case it establishes a relation Rr with all the answering SCR, and it issues requests to SCA that it received the addresses. Otherwise, the SCN chooses an arbitrary configuration in the expected scope. In this case, it starts a SCA, in order to provide consistency when other SCN which will be further connected. If the SCN has several interfaces, it can receive answers from several independent SCAs. It then uses the SCAs to configure the interfaces where the SCAs are connected. For other interfaces, where no SCA is available, it can request to one or more SCAs, applying different configuration (when not exclusive, i.e. addresses) to these interfaces. 5.2 Boot of a SCA When SCA is started, it tries to find other SCAs on the same link, thanks to the Ri relation. Then it does the same thing with SCRs. It then asks to the SCRs for the other known SCAs, in order to have a view as complete as possible of all the SCAs. The scope of this operation is strictly restricted to the same link and contiguous ones. Depending of its configuration (!) the SCA can request to serve as a proxy of one or several other SCAs, or can apply the SCR configurations that is stored. 5.3 Removing of a SCA A shutting down SCA should gracefully alert the other SCAs or request for a SCN to start another SCAs. In any case, a SCN which detects that the last SCA on a link stopped to work either alerts the other known SCAs or starts a SCA, taking it own configuration as a seed for computing configuration to distribute. 6 Existing initiatives for self-configuration This sections briefly describes the current solution and proposals for self-configuration, and details how they are suited with the reference architecture. 6.1 Ipv6 auto-configuration The basic IPv6 auto-configuration process is dedicated to hosts. It allows retrieval of 64 bits address prefix, the remaining 64 bits being determined from local information. This mechanism is based on the ICMP Router Advertisement message. Referring to the proposed architecture, the host acts here as a SCR, the router being the SCA. This mechanism only addresses IP address allocation, on link local. The only relation supported is the Rq Marce, Galand [Page 6] Internet Draft Architecture for Zerouter December 2002 relation, without scope information nor other SCAs querying. 6.2 Prefix delegation In [RefHaberman], ICMP v6 is augmented with prefix delegation messages. Its scope is address allocation only. The relation Ri and Rq are partially achieved. The SCR first issues a request to know the available SCAs. Then a request for prefix delegation is sent to the SCA. No information on the scope is allowed. The authenticated relations are allowed, and the decision is let on external policy. 6.3 DHCP Prefix delegation In [RefDHCPv6OptPrefix], a new option is added to DHCPV6. This option is intended for delegating prefixes from a delegating router to a requesting the router. In this concrete example, the SCA is the delegating router and the connected SCR is the requesting router. The relation Rq is achieved with the exchange of a list of prefixes from the SCA to the SCR. Afterwards each interface of the connected SCR is configured with list of prefixes to be distributed to the other SCRs (relation Rr). 6.4 ARC In [RefARCP], the relation Ri s established with the help of DHCP and BOOTP messages. It is expected to have one SCA per domain, which is the ARCP server. The relation Rq is almost completely achieved, the request for configuration containing place for scoping. The other relations Ra and Rr are not supported. 6.5 OPSFv3 for router autoconfiguration The [RefChelius] document proposes definition of new LSA useds to auto-configure IPv6 routers. The three LSAs allow to disseminate the chosen SLA and TLA by each routers. In case of conflict renumbering is done for the links having the smallest IDs. In [RefZOSPF], the proposed mechanisms deals with IPv6 and IPv4 address and prefix/subnet allocation. It details the different steps to allow a reliable allocation of prefix and addresses, dealing with collision detection and interoperability with global IPv6 prefix allocation. Both mainly corresponds to the Ra relation, allowing SCAs to find a consensus on the prefix and address to distribute, and relying on the OPSF drouter designation mechanisms. 6.6 Zerouter requirement document The [RefZerouterReq] document provides initial version for zerouter protocols. The IP address allocation and routing protocol scopes defined in this architecture are identified as requirements for zerouter (section 4.1 Problem Space). The impact of the type of media to the architecture is restricted to the relation Ri, which Marce, Galand [Page 7] Internet Draft Architecture for Zerouter December 2002 can also be implemented over non-broadcast media. The relations between two SCA (relation Ra) or between SCR (relation Rr) are intended to provide ability to deal gracefully with topological changes, as required in section 4.4. The proposed architecture is open to extensibility of configuration parameter distribution (section 4.6), providing only framework for entity and relations. The security aspects are mentioned into this definition of architecture, and must be considered in any implementation, with regards to the 4.10 section. 7 Conclusion This document proposes the definition of a reference architecture for the self-configuration. It identifies entities and relations, and propose a sort of comparison between existing proposals, based on the proposed frame. It is expected that this architecture would be used as a basis for discussion in self-configuration initiatives, especially in the Zerouter IETF working group, under preparation. 8 Acknowledgements Thanks to people from Zerouter mailing list, and special thanks to Kazuhiko Yamamoto for the helpful Emacs RFC mode. 9 References [RefHaberman] B. Haberman, J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", draft-haberman-ipngwg-auto-prefix-02.txt [RefDHCPv6OptPrefix] O. Troan, R. Droms, "IPv6 Prefix Options for DHCPv6", draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt [RefARCP] J. Linton, "Automatic Router Configuration Protocol", draft-linton-arcp-00.txt [RefZerouterReq] J. Linton, G. Chelius, "Zerouter Protocol Requirements", draft-linton-zerouter-requirements-00.txt [RefChelius] G. Chelius, E.Fleury, L. Toutain, "Using OSPFv3 for IPv6 router autoconfiguration", daft-chelius-router-autoconf-00.txt [RefZOSPF] A. Dimitrelis, A. Williams, "Autoconfiguration of routers using a link state routing protocol", draft-dimitri-zospf-00.txt 10 Authors' addresses Olivier Marce Alcatel R&I Route de Nozay F-91461 Marcoussis Cedex (France) Marce, Galand [Page 8] Internet Draft Architecture for Zerouter December 2002 Olivier.Marce@alcatel.fr Damien Galand Alcatel R&I Route de Nozay F-91461 Marcoussis Cedex (France) Damien.Galand@alcatel.fr Marce, Galand [Page 9]