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]