Internet DRAFT - draft-chroboczek-configuration-separate
draft-chroboczek-configuration-separate
Network Working Group J. Chroboczek
Internet-Draft PPS, University of Paris-Diderot
Intended status: Experimental July 3, 2013
Expires: January 4, 2014
Configuration must not be carried by the routing protocol
draft-chroboczek-configuration-separate-00
Abstract
Where I argue that configuration information must be carried by a
protocol separate from the routing protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 4, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Chroboczek Expires January 4, 2014 [Page 1]
Internet-Draft Babel Extension Mechanism July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Advantages of carrying configuration information over the
routing protocol . . . . . . . . . . . . . . . . . . . . . . . 3
3. Advantages of separating configuration from routing . . . . . . 3
4. Possible configuration protocols . . . . . . . . . . . . . . . 5
4.1. Router Advertisements . . . . . . . . . . . . . . . . . . . 5
4.2. A standard configuration protocol . . . . . . . . . . . . . 5
4.3. A new protocol . . . . . . . . . . . . . . . . . . . . . . 5
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chroboczek Expires January 4, 2014 [Page 2]
Internet-Draft Babel Extension Mechanism July 2013
1. Introduction
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.
2. Advantages of carrying configuration information over the routing
protocol
I have heard the following advantages claimed for conflating the two
functions:
1. it is not necessary to implement a new flooding protocol, which
saves space on resource-limited routers;
2. all routers already participate in the routing protocol, while a
new configuration protocol requires ensuring that all routers
forward the configuration information;
3. 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 [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.
3. Advantages of separating configuration from routing
There are significant advantages to distributing configuration
Chroboczek Expires January 4, 2014 [Page 3]
Internet-Draft Babel Extension Mechanism July 2013
information over a separate protocol:
1. the architecture is more robust -- issues with the routing
protocol do not prevent configuration information from being
distributed;
2. distributing configuration information on a simple dedicated
protocol makes monitoring and trouble-shooting easier;
3. separate, well-defined protocols are more likely to be
implemented in a clean and efficient manner, especially by the
Open Source/Free Software community;
4. 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;
5. 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
Chroboczek Expires January 4, 2014 [Page 4]
Internet-Draft Babel Extension Mechanism July 2013
protocol will allow people:
o 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;
o 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.
4. Possible configuration protocols
If the routing protocol is only in charge of routing, what protocol
should be used for distributing configuration information?
4.1. Router Advertisements
Router Advertisements (RAs) [RFC4861] 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.
4.2. A standard configuration protocol
The IETF has a number of standard configuration protocols. DHCPv6,
in particular, while originally intended to configure hosts, has been
coerced into configuring routers [RFC3633]. It is my hope that
DHCPv6 can be extended to perform router configuration within a
homenet environment.
4.3. A new protocol
In the Babel experiment [BABEL], I have designed a new protocol,
which I call AHCP [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
Chroboczek Expires January 4, 2014 [Page 5]
Internet-Draft Babel Extension Mechanism July 2013
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.
5. Conclusions
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.
6. References
[AHCP] Chroboczek, J., "The Ad Hoc Configuration Protocol",
Internet Draft draft-chroboczek-ahcp-00, August 2010.
[BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
February 2011.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Chroboczek Expires January 4, 2014 [Page 6]
Internet-Draft Babel Extension Mechanism July 2013
Author's Address
Juliusz Chroboczek
PPS, University of Paris-Diderot
Case 7014
75205 Paris Cedex 13,
France
Email: jch@pps.univ-paris-diderot.fr
Chroboczek Expires January 4, 2014 [Page 7]
