network rc-scripts

Hi,

I'm the Zynot-IPv6 founder and I've plan in the roadmap a review of the
network rc-scripts. I've updated our main wiki page [
http://wiki.zynot.org/zynot/moin.cgi/ZynotIpv6 ] and written a draft about
this review [ http://www.e-glop.net/zynot/network-rcscripts.xhtml ]. You
would be able to modify or comment this document going on this wiki's page
[ http://wiki.zynot.org/zynot/moin.cgi/NetworkRcscriptsDraft ].

I add this here to be able to recieve comments also through this media :

- -- ---

A draft for network rc-scripts

Baptiste SIMON (aka BeTa)

   e-glop.net
   version 1.0

   Copyright © 2003 Baptiste SIMON

   July 2003, the 4th

   This document's goal is to prepare and document the network
   rc-scripts' development. Let's see what would happen.
     _________________________________________________________

   Table of Contents
   1. Introducing the ideas
   2. The needs

        2.1. Basic level
        2.2. IPv4 level
        2.3. IPv6 level
        2.4. More...

   3. The concrete things

        3.1. rc-scripts
        3.2. Configuration file

   4. Conclusion
   5. The author
   6. Annexes

        6.1. This document other formats
        6.2. Publication License

1. Introducing the ideas

   Today, network rc-scripts are made to provide great IPv4
   improvments. Tomorrow (but quite oftenly today) IPv6 would
   come. And we have to provide great modular tools which can
   support all those technologies at the same level.

   The current rc-scripts are not modular at all. We have to hack
   them to make an IPv6-only box's network running well. So The
   goal of this document will be to explain where I'd like to see
   the network rc-scripts go.
     _________________________________________________________

2. The needs

   The needs for network rc-scripts are, as said before, to
   provide a modular approach of the matter.
     _________________________________________________________

2.1. Basic level

   At this level we only have to set up the needed interfaces. No
   more necessities.
     _________________________________________________________

2.2. IPv4 level

   IPv4 needs are :

     * Assigning an "evoluated" IPv4 (with the possibility to set
       our own broadcast, network, etc... parameters) to an
       interface
     * Possibility to use DHCP
     * Making "aliases" possible (eg. eth0:1)
     * Setting whether the box would be a router or not
     * Providing IP spoofing protections
     _________________________________________________________

2.3. IPv6 level

   IPv6 needs are :

     * Assigning a "hard" stateless IPv6 address
     * Possibility to use a stateful (DHCPv6) auto-configuration
     * Setup the IPv6 native stateless auto-configuration
     * Setting whether or not an interface can route datagrams or
       not
     _________________________________________________________

2.4. More...

   We have not to reproduce the past errors by providing an
   extended non-modular pool of tools. We don't know how would
   tomorrow will evoluate...
     _________________________________________________________

3. The concrete things

3.1. rc-scripts

   We have to have a modular approach. I was first thinking about
   :

     * /etc/init.d/net.[interface] --> upping interfaces
     * /etc/init.d/net.[protocol] --> setting up generalities on
       protocol
     * /etc/init.d/net.[interface].[protocol] --> enabling
       [protocol] on [interface]. Depends on net.[interface] and
       on net.[protocol]
     * /etc/init.d/net --> set up or down all the network. It
       depends on all the net.[interface].[protocol] rc-scripts.
       I still don't know how we would be able implement it, but
       maybe it would be set for eth0 by default (most case) and
       editable to add things in its dependances (not for
       novices). If you have a better idea for that, do not
       hesitate to contact us or to mail [email protected].
     _________________________________________________________

3.2. Configuration file

   One big configuration seems to be ideal. Its syntax has to be
   adaptable. It would contain this kind of parameters :

     * IPv4 protocol
          + inet4_[interface] : IPv4 parameters (<address>
            [broadcast <broadcast>] [netmask <netmask>])
          + inet4_[interface]_alias[<number>] : same as
            "inet4_[interface]" but for aliases. The <number>
            must be logically increasing from "1".
          + inet4_forwarding : list of IPv4 interfaces on which
            enable forwarding
          + inet4_nospoof : list of IPv4 interfaces on which one
            we would prevent IPv4 spoofing
          + inet4_gateway : the IPv4 gateway parameter
            (<dev>|<address>)
     * IPv6 protocol
          + inet6_[interface] : IPv6 stateful "hard" parameters
            (<address>/<mask>)
          + inet6_autoconf : list of IPv6 interfaces on which one
            we would enable stateless auto-configuration
          + inet6_forwarding : list of IPv6 interfaces on which
            enable forwarding
          + inet6_gateway : the IPv6 gateway parameter
            (<dev>|<address>/<mask>)

   The idea is :

     * Everything which can be treated globally is treated as so
       (if we would treat every interface independently, it would
       be more tweakable but also really more difficult to deploy
       well).
     * Everything which HAVE TO be treated interface by interface
       is treated as so (no other possibility ;c).
     _________________________________________________________

4. Conclusion

   Writing this doc before coding has made clear to me that there
   would be many points of comments here. So you might see that
   paper as a request for comments. So please, feel free to
   comment out this doc on [ http://www.zynot.org/ ] or by mail
     _________________________________________________________

5. The author

   Baptiste SIMON <[email protected]>

   Administrateur système GNU/Linux

   Zynot-IPv6 team funder

   Looking for an employment
     _________________________________________________________

6. Annexes

6.1. This document other formats

   This document has been writen in RST with KWrite and then
   converted into DN-XML and Docbook with dn2dbk.xsl.

   The XHTML, HTML and XSL-FO versions have been created with the
   official DocBook XSLT stylesheet [1]. The PDF, Postscript, RTF
   and plain text versions have been create with Jade.

   Find all those formats here :

     * XHTML
     * HTML
     * PDF
     * postcript
     * Texte brut
     * RTF
     * reStructuredText
     * DocBook - XML
     * DN-XML
     * XSL-FO
     _________________________________________________________

6.2. Publication License

   This document from www.e-glop.net or www.ipv6.e-glop.net is
   published under the Open Publication License. Permission is
   granted to copy, distribute and/or modify this document under
   the terms of the Open Publication License version 1.0.

  Notes

   [1] The app-text/docbook-xsl-stylesheets package on Gentoo-Linux

- -- ---

nb: the power of DocBook used easily ;c)

I'm not supposed to be really skilled in that kind of stuff but I want to
do it. So please, feel free to comment or modify this doc (under the terms
of the license of course ;cb).

Best regards,

-- 
Baptiste SIMON
   aka BeTa
Administrateur Système GNU/Linux & Unix
3, av. de la Calypso
44000 Nantes
06 75 79 28 48