Dibbler - a portable DHCPv6  1.0.2RC1
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
  1. Architecture

General architecture is common between server, client and (to some extent) relay. In all cases, classes are divided into several major groups:

  • IfaceMgr – Interface Manager. It represents all network interfaces present in the system. They're represented by TIfaceIface objects and stored in IfaceLst. Each interface has list of open sockets, represented with TIfaceSocket objects. There are also a number of auxiliary functions for getting proper interface. IfaceIface objects also provide methods to add, update and remove addresses.
  • AddrMgr – Address Manager. It is an address database, which stores all informations about clients, IAs and associated addresses.
  • CfgMgr – Config Manager. It is being used to read configuration information from config file and provide those informations while runtime. Common mechanisms shared between server and client are scarce, so this base class is almost empty.
  • TransMgr – Transmission Manager, sometimes called Transaction Manager. It is responsible for network interaction and core DHCPv6 logic. It sends various messages when such need arise, matches received responses with sent messages, retransmits messages etc. It contains list of messages currently being trasmitted.
  • Messages – There is one parent class of all messages. It contains several basic functionalites common to all messages.
  • Options – There are multiple option classes. Note that some classes are designed to represent one specific option (e.g. OptIAAddress) and other are not (e.g. OptAddrLst can contain address list, so it can be used as DNS Resolvers, SIP servers o NIS servers option).
  • Misc – This cathegory (or rather directory) contains various miscellanous classes and functions.

None of those classes is used directly. Client, server and relay uses derived classes.

They are all created within DHCPClient or DHCPServer objects in client or server, respectively. DHCPRelay object will perform similar function for relays.

6.1 Client Architecture

Client is represented by a DHCPClient object. It contains 4 large managers, each with its own functions. Also messages and options are defined:

  • TClntIfaceMgr – contains client version of the IfaceMgr. Major difference is a TClntIfaceIface class, an enhanced version of the IfaceIface. It provides methods to set up various options on the physical interface. Those methods are used by Options representing options.
  • TClntAddrMgr – Client version supports additional, client related functions, e.g. tentative timeout used in DAD procedure. It also simplifies database handling as there will always be only one client in the database.
  • TClntCfgMgr – Client related parser. TClntCfgMgr and related objects are designed to provide easy access to parameters specified in the configuration file. ClntCfgIface is a very important class as most of the parameters is interface-specific.
  • TClntTransMgr – Core logic of the Client. It uses all other managers to decide what actions should be taken at occuring circumstances, e.g. send REQUEST when there are less addresses assigned than specified in the configuration file.
  • TClntMsg – All messages have client specific classes. Those objects are created as new messages are being sent. After server message reception, object is also created and passed to the original message. For example, client sends SOLICIT message and server send ADVERTISE message. Reply will be passed by invoking answer(msgAdvertise) method on the Solicit object.
  • TClntOpt – There are client specific options defined. Each of those options has doDuties() method which is called if this option was received in a proper reply message from the server. It calls appropriate methods in TClntIfagrMgr which set specific options in the system.

6.2 Server Architecture

Server is represented by a DHCPServer object. It contains 4 large managers, each with its own functions. Also SrvMessages and SrvOptions are defined:

  • TSrvIfaceMgr – contains server version of the IfaceMgr. There are almost no modificiation compared to common version.
  • TSrvAddrMgr – Client version supports additional, client related functions, e.g. tentative timeout used in DAD procedure. It also simplifies database handling as there will always be only one client in the database.
  • TSrvCfgMgr – Client related parser. TSrvCfgMgr and related objects are designed to provide easy access to parameters specified in the configuration file. SrvCfgIface is a very important class as most of the parameters is interface-specific.
  • TSrvTransMgr – Core logic of the client. It uses all other managers to decide what actions should be taken at occuring circumstances, e.g. send REQUEST when there are less addresses assigned than specified in the configuration file.
  • TSrvMsg – Server version of the messages. Each time server receives a message, TSrvMsg is created. Depending of its type, TSrvAdvertise of TSrvReply message is created. As parameter to its contructor original message is passed. After creating message, it is sent back to the client and stored for possible retransmission purposes.
  • TSrvOpt – Server version of the Option representing objects. They are just used to store data, so they are considerably simpler than client versions.

6.3 Relay Architecture

Preliminary relay version was available in the 0.4.0 release. It consists of serveral simple blocks:

  • TRelIfaceMgr – contains relayr version of the IfaceMgr. There are almost no modificiation compared to common version, execept decodeMsg() and decodeRelayRepl() methods.
  • TRelCfgMgr – Relay related parser. TRelCfgMgr and related objects are designed to provide easy access to parameters specified in the configuration file. RelCfgIface is a very important class as most of the parameters is interface-specific.
  • TRelTransMgr – It's plain simple manager. It's only function is to relay received message on all interfaces.
  • TRelMsg] – From the relay's point of view, all messages fall to one of 3 categories: Generic (i.e. not encapsulated) messages, RelayForw (already forwarded by some other relay) and RelayRepl (replies from server). Most of the messages is threated as generic message.
  • TRelOpt – Similar approach is used to handle options. Expect RELAY_MSG option (which contains relayed message) and interface-id option (which contains identifier of the interface), all options are threated as generic options, which are handled transparently.

6.4 Requestor Architecture

Todo:

6.5 Naming Convention

Todo:

6.6 Algorithms

6.6.1 Lease assignment policy

  1. Client classification is performed (a class is assigned to a client) (see NodeClientSpecific::analyseMessage(msg) in void TSrvTransMgr::relayMsg(SPtr<TSrvMsg> msg))
  1. black-list, white-list (TSrvCfgMgr::isClntSupported() called from TSrvTransMgr::relayMsg() )
  2. Check if there is existing lease for this client/ia. If there is, assign it. (TSrvOptIA_NA::renew() called from TSrvOptIA_NA::TSrvOptIA_NA() )
  3. Check if there is reserved address/prefix defined for this client. If it is, assign it (fixed-lease or "exception") (TSrvOptIA_NA::assignFixedLease() called from TSrvOptIA_NA::TSrvOptIA_NA() )
  4. Check if client didn't exceed max-client-leases (see code in TSrvOptIA_NA::TSrvOptIA_NA())
  5. See if there is a lease that was assigned previously (cache) (TSrvOptIA_NA::assignCachedAddr() called from TSrvOptIA_NA::TSrvOptIA_NA())
  6. See if client sent a hint and try to assign it, if possible. If requested address is not available, try to assign similar address (i.e. from the pool that hint belongs to). (TSrvOptIA_NA::assignRequestedAddr() called from TSrvOptIA_NA::TSrvOptIA_NA())
  7. randomly assign a new lease (TSrvOptIA_NA::assignRandomAddr() called from TSrvOptIA_NA::TSrvOptIA_NA())

6.6.2 Fixed lease management

  1. Old database is read when server starts.
  2. Existing leases are confirmed against current configuration. Invalid leases are removed.

The following steps are somewhat not feasible as there may be reservations for remote-id or subscriber-id (or mac address)

  1. List of fixed leases is created, based on configuration.
  2. An attempt to add each fixed lease to DB is tried. If lease is already in DB, addition is skipped. Leases are marked as fixed.

6.7 Authentication

see TClntMsg::appendAuthenticationOption() bool TClntMsg::checkReceivedAuthOption() void TSrvMsg::appendAuthenticationOption(SPtr<TDUID> duid) bool TSrvMsg::validateReplayDetection()

missing:

  • validation on server side