[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposal: Network configuration file format

Here is my proposal for a network configuration file format. It is one
config file containing all data needed for the network configuration.
This includes the interface configuration and routing and firewall
setup. The parsing of the config file will be done by a "smart"
activation agent written in C (there is no code yet, but I will be
working on it ASAP). This agent should figure out reasonable defaults
when some values are not given in the configuration file.
I am writing this proposal as my first try to get Debian a network
configuration that can be easily changed by configuration tools as well
as manually. I am also in contact with Jacques Gelinas (the Linuxconf
developer) with whom I am planning to write a Linuxconf configuration
module and Michael Johnson (from RedHat) who ist interested in using the
firewall configuration part for the RedHat distribution. I would like to
have more cooperation between RedHat and Debian and the firewall setup
could be a start.
This proposal is subject to heavy changes and I encourage everybody to
write comments and critics about the proposal. I want something that is
easy to set up for the beginner but is powerful enough to control neary
every aspect of a Linux network configuration. The main point where I am
not sure is about splitting the information. The data could be in one
big file (as it is now in the proposal) or it could be split into
multiple file, each for its specific purpose.
The file format is taken from BIND 8.x as I find it easy to read and

I am open to any suggestions, this is only the first try. But I want a
network configuration soon, because I am building a Debian based
firewall distribution that needs some configuration tools !

PS: I am not a Debian developer yet, my application is pending for a few
months now...

Proposed config file format for the Linuxconf advanced network module:

Main Sections (from 1 to 4)
1. Global: All definitions that are valid for the whole host.
   Any ideas what entries should belong here ?

2. Networks: One network equals one (physical) interface.
   [It is named Network because of it seems more natural for new users,
   advanced users will know that a network needs an (physical) interface
   the other way around.]
   This section constists of several entries, one per network (aka per
   interface). An entry has the format:
      network "internal" {
        interface "eth0" {
          addressv6     .................;
        interface "eth0:0" {

   and the following options (mainly all options taken by "ifconfig") :
     - interface: The used interface (e.g.: eth0, isdn0, ppp0, sl0, lo,
     - addressv4: The IPv4 address of the interface, can be either a
       address, "bootp" or "dhcp" or "dynamical" for dialup-connections.
     - addressv6: The IPv6 address of the interface.
     There can be zero or more interface entries. There can be two
     per interface, one IPv4 and one IPv6 address (see ifconfig man
     add), or if kernel 2.2.x is used, any number of addresses can
     be used per interface (see "ip" command documentation).
     All interfaces in one network entry share the same netmask and
     and network address as they are on the same physical network.      
     This feature will be useful for virtual servers.      
     If there is no interface definition, it is only a named network
     at least the netmask and network address have to be given. Named
     networks are used for defining routing and firewall targets.      
     - netmaskv4 / netmaskv6: The network netmasks.      
     - broadcastv4 / broadcastv6: The broadcast addresses.      
     - networkv4 / networkv6: The network addresses.
     The must be at least either a IPv4 or a IPv6 definition for the
     interface. The use of both address formats is possible and
encouraged for
     the next years until the transition to IPv6 is completed.
     - ptpaddressv4: When the interface is a point-to-point interface,
       address of the other end.
     - ptpaddressv6: The IPv6 address of the other end.

     Optional parameters:
     - enabled: Can be set to true or false, default is true. This can
be used
       to temporarily disable an interface if set to false.
     - arp: true or false (see ifconfig man page)
     - allmulti: true or false (see ifconfig man page)
     - metric: see ifconfig man page
     - mtu: see ifconfig man page
     - tunneldest: Has to be after an IPv6 address line and specifies
       destination of the (optional) IPv6-in-IPv4 tunnel.
     - irq: The dynamically changeable IRQ if supported by the device.
     - io_addr: The I/O address if supported by the device.
     - mem_addr: The memory address if supported by the device.
     - media: The used media (e.g. 10baseT or 10base2).
     - bandwidth: The maximum bandwith for a interface (see iproute2+tc
     - setdefaultroute: Sets the default route to point to the
       This can be used for very easy setups, such as ppp-only connected
       Can be True, False or onconnect.
     maybe in future enhancements:
     - ipx address
     - appletalk address
     - PPP / ISDN options (I would prefer this one to be implemented
     - .......

3. Routing: Routing table entries. All routing entries for the specified
   interfaces are done automatically and should not be given here.
   Routing classes are:
     - default:
       route default {
         metric        1;
       route default {
         metric        2;
       A gateway address can be followed by a metric that is used for
       route. Add one entry per default route.
     - routes to named networks:
       route "external" {
         metric       1;
       route "external" {
         metric       2;
     - routes to hosts:
       route "" {
     - bridges between networks:
       bridge "virtualnetwork" {
         from         "internal";
         to           "external";
       I never used Linux bridging, so I have no knowledge about the

     Options for routing entries (this should cover all new 2.2.x
     - I will go through the "ip" command documentation and try to build
       list of current kernel 2.2.x features. This will take me a few
       but I think the general routing concept stays they same, there
will just
       be more options similiar to firewalling.

4. Firewalling:
   This section contains firewalling rules (see ipchains manual page for
      rule {
        from "internal";
        to "external";
    could be written in the form
       rule { from "internal" to "external" masquerade }

    Possible parameters for a firewalling rule are:
    - from: Zero or more can be given. If there are more than one from
      more than one rules will be added to the kernel filter
    - to: see from
    If no from parameter is given, all source hosts match the rule. The
    goes for to parameters. Values of these parameters can either be
    networks or hosts (given by IP address or FWDN).
    - forward: Directly forward packages between all "from" and "to"
hosts /
    - masquerade: Masquerade the connections.
    - deny <direction>: Skip packets matching the other parameters.
    - reject <direction>: Reject (send ICMP reply to sender) matching
    - accept <direction>: Accept matching packets.
    Where <direction> is either incoming or outgoing.
    - log: Log all packets matching the rule into the syslog.
    - monitor: Copy all matching packets to the netlink device. This
      monitoring of active connections with a separate package (I will
write a 
      little daemon that listens for TCP connection start and end
packets and
      provides a list of active TCP connections on request.).
    - protocol: Can be either "tcp", "udp" or "icmp".
    - firstpacket: Matches only the first packet of a TCP connection
(with the
      SYN bit set).
    - fragment: Matches a fragment of a TCP packet that is NOT the first
      fragment (and therefore that is not containing the IP header
    - redirect: Use port forwarding to a specific host.
    - transproxy: Redirect to a local port (transparent proxying).
    - bidirectional: Create a second rule with exchanged "from" and "to"
    - options for setting the TOS field and marking the packets on the
    All options can be preceeded by "not", inversing the parameter

    A spoof protection is set up automatically for all interfaces.

5. Examples

5.1 An example as I would use it for my home network:

# The local network.
network "internal" {
  # The main connection to the internal network.
  interface "eth0" { addressv4 }
  # This is for testing apache's virtual server capabilities
  interface "eth0:0" { addressv4 dhcp }

# a direct connection to a other local network that provides some
network "untrusted" {
  interface "eth1" { addressv4 }

# For using Vmware's network capabilities.
network "vmnet" {
  interface "vmnet0" { addressv4 }

# The ISDN connection to the outside
network "isdn" {
  interface "isdn0" { 
  arp false;
  # A shell script sets this to true if I want automatic connections to
be made
  enabled false;
  # Maybe we should put in the ISDN settings here too (telephone number,
  # protocol, ...)

# PPP dialins
network "dialin" {
  interface "ppp0" { 
    # I do not want dialins to saturate my ISDN connection.
    bandwidth 14400;
  interface "ppp1" { 
    bandwidth 14400;
  arp false;

# A named network for the firewalling rules
network "internet" {

# The default route to the internet
route default {

# Now some firewalling rules
# masquerade the internal network to the internet, but do www access
over a
# (transparent) proxy on the local host
rule { from "internal" to "internet"/www 
  protocol tcp; 
  transproxy 8080 
rule { from "internal" to "internet" masquerade }
# port forwarding to the internal ftp server
# everywhere/ftp means port 21
rule { from "internet" to everywhere/ftp 
  protocol tcp;
rule { from "dialin" to "internet" masquerade }
# Only provide internet access but do not allow local network access
rule { from "dialin" to "internal" reject incoming }
# allow connections to the untrusted network but not the other direction
rule { from "internal" to "untrusted" forward }
rule { from "untrusted" to "internal";
  deny incoming;

5.2 A simple masquerading-only example would look like this:

network "internal" {
  interface "eth0" { addressv4 }
  # network and broadcast adresses are determined by interface address
  # netmask, but could be overridden here

network "dialout" {
  interface "ppp0" { 
    addressv4 dynamical;
    ptpaddressv4 dynamical;
  # all other values are figured out by the "smart" activation agent
  setdefaultroute onconnect;

rule { from "internal" masquerade }

Reply to: