Configuration must not be carried by the routing protocol
PPS, University of Paris-Diderot
Case 7014
75205 Paris Cedex 13
France
jch@pps.univ-paris-diderot.fr
Where I argue that configuration information must be
carried by a protocol separate from the routing protocol.
The homenet group has given a fair amount to thought to the issue
of configuring routers automatically. There appears to be consensus
that snooping on the routing protocol is not sufficient, and that
explicit configuration information must be propagated to the routers.
There is currently no consensus on whether this extra information
should be carried by the routing protocol (e.g. within opaque LSAs in
OSPF, or the equivalent in IS-IS), or whether it should be carried by
a separate protocol.
In this document, I argue that configuration information should be
carried by a dedicated protocol separate from the routing protocol.
I have heard the following advantages claimed for conflating the
two functions:
it is not necessary to implement a new flooding protocol, which
saves space on resource-limited routers;
all routers already participate in the routing protocol, while
a new configuration protocol requires ensuring that all routers
forward the configuration information;
merging configuration with routing provides a form of fate sharing,
where the configuration and the routing information are either both
propagated or neither is; this might make fault detection and
isolation easier to perform.
Concerning the first point -- as I've shown with AHCP , a reasonably efficient, purely user-space, flooding
protocol can be implemented in a hundred lines of C code or so, and
takes just a few kB of flash and a few bytes of memory.
Concerning the second point, homenet is planning to mandate the
implementation of a new routing protocol on all home routers,
compatibility with "legacy" routers is alreeady broken. Requiring
a small daemon in order to participate in the flooding of
configuration information does not break compatibility any
further.
The fate sharing argument is without doubt the more compelling.
There are significant advantages to distributing configuration
information over a separate protocol:
the architecture is more robust -- issues with the routing protocol
do not prevent configuration information from being distributed;
distributing configuration information on a simple dedicated
protocol makes monitoring and trouble-shooting easier;
separate, well-defined protocols are more likely to be implemented
in a clean and efficient manner, especially by the Open Source/Free
Software community;
should new requirements arise, the architecture is easier to
evolve: it is possible to reuse most of the homenet architecture with
a new routing protocol;
should new requireent arise, the architecture can evolve
seamlessly: it is possible to reuse all of the homenet architecture
while running multiple routing protocols.
The first point is important -- experience with DHCPv4 and RA shows
how easy it is to run into issues with configuration protocols, and
how useful it is to be able to identify and decode configuration
packets without having a full understanding of a complex routing
protocol.
The second point is probably of secondary interest, since homenet
will likely use a routing protocol that has fully debugged
implementations and doesn't require much troubleshooting.
Additionally, IPv6 link-local addresses make recovering a router that
has lost its addresses somewhat easier than in the IPv4 world. Still,
making debugging and recovery easier remains a desirable property.
Concerning the third point, the experience of the last twenty years
or so shows that the Open Source/Free Software community is extremely
efficient at implementing small, self-contained pieces of software and
using them to build large yet flexible systems. A prime example of
that is OpenWRT, which is based on numerous independently developed
small daemons (udhcp, dnsmasq, uhttpd etc.) which, combined into
a consistent whole, form a complete, highly modular and flexible
router platform. The same community has found itself unable or
unwilling to implement large, monolitic architectures on the model of,
say, Microsoft Exchange.
The remaining two points are very important. Homenet should aim to
provide a sound basis for home routers for the next twenty years or
so; yet, it will not be the end-all of home router architecture. It
is absolutely essential that people be able to experiment with
different approaches even after homenet is finalised. Being able to
take an off-the-shelf homenet router and swap or augment its routing
protocol will allow people:
to experiment with the new link technologies that are bound to
emerge over the next twenty years, and that might not be well
supported by existing routing protocols;
to experiment with topologies different from the ones that are well
supported by existing routing protocols.
In short, homenet must be able to evolve without all of our work
being thrown out. I can envision a future "homenet II" stack
which uses a configuration protocol compatible with homenet, together
with a different routing protocol and perhaps a different service
discovery mechanism.
If the routing protocol is only in charge of routing, what protocol
should be used for distributing configuration information?
Router Advertisements (RAs) are ignored by
routers, and rightly so -- RAs have no loop avoidance mechanism, and
using RAs to configure routers leads to a number of problems that are
very difficult to solve. Extending the RA protocol to be suitable for
configuring routers is probably not worth the hassle, and will lead to
avoidable confusion.
The IETF has a number of standard configuration protocols. DHCPv6,
in particular, while originally intended to configure hosts, has been
coerced into configuring routers . It is my
hope that DHCPv6 can be extended to perform router configuration
within a homenet environment.
In the Babel experiment , I have designed
a new protocol, which I call AHCP . Since AHCP
is designed to run before routing is functional, it makes minimal
assumptions about the network -- it only requires each interface to
have a link-local IPv6 address and to be able to participate in
link-local multicast traffic. An AHCP client implements an increasing
diameter search in order to contact an AHCP server.
The full AHCP implementation (client+server+forwarder, with support
for both Linux and BSD Unix) consists of 3500 lines of C and 350
lines of Bourne shell code, and compiles to less than 40 kB. Subset
implementations are possible. We have found AHCP to be very robust
and reasonably fast even in the presence of massive packet loss. The
traffic generated is quite modest, even when simultaneously rebooting
the whole network.
As mentioned above, it is my hope that DHCPv6 can be coerced into
being useful as a router configuration protocol in the homenet
environment. However, I believe that the AHCP experiment can serve as
useful input for the homenet effort.
In this document, I have argued that configuration information
should not be carried by the homenet routing protocol. Homenet
routers should ideally be configured by a variant of DHCPv6; if that
is not possible, we should design a simple, self-contained protocol
for that purpose.
The Ad Hoc Configuration Protocol
The Babel Routing Protocol
IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6
Neighbor Discovery for IP version 6 (IPv6)