| Network Working Group | J. Chroboczek |
| Internet-Draft | PPS, University of Paris-Diderot |
| Intended status: Experimental | July 02, 2013 |
| Expires: January 03, 2014 |
Configuration must not be carried by the routing protocol
draft-chroboczek-homenet-configuration-separate-00
Where I argue that configuration information must be carried by a protocol separate from the routing protocol.
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 03, 2014.
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.
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:
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.
There are significant advantages to distributing configuration information over a separate protocol:
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:
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) [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.
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.
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 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.
| [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. |