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]