Tunnel DHCP ============= (c) Konrad Rosenbaum, 2009 (c) Patrick Brandao, 2015 protected under the GNU GPLv3 or at your option any newer (see COPYING for details) Website original (link quebrado): http://silmor.de/69 tDHCP - software ultra-pequeno para dar suporte a servidor dhcp6 e cliente dhcp6 orientada a tuneis (PPP, PPPoE, PPtP, EOIP, ...). Sem muita usabilidade para redes locais ethernet/broadcast. Compilando ---------- Software testado nos seguintes ambientes: - Slackware 14.1 64 bits (amd64): i3, i5, i7, xeon, fusion. Caso ocorrar algum erro durante a compilacao, certifique-se de que seu sistema tem as bibliotecas minimas para compilacao. Todos os testas foram executados em Slackware 14.x instalacao FULL Para compilar, execute: # make clean # make Serão criados os binarios: tdhcpc - cliente DHCPv6 tdhcpd - servidor DHCPv6 Copie-os para a pasta /usr/sbin/ ou qualquer pasta de sua preferencia. Comandos: # cp -fav tdhcpc /usr/sbin/ # cp -fav tdhcpd /usr/sbin/ Recursos do servidor - tdhcpd ---------------------------------- - Enviar prefixo para delegacao (dhcp-pd) - Enviar dominio DNS - Enviar endereco de DNS recursivo - Enviar nome do dominio DNS - Todos os parametros enviados via argumento (sem arquivo de config) - Emprestimos enviados como INFINITOS. Execute "tdhcpd --help" para detalhes de execucao. Recursos do cliente - tdhcpc ---------------------------------- - Solicita alocacao de IPv6 (endereco proprio) e Prefixo IPv6 (para redistribuir em rede local) - Executa script para ativar o IPv6 e o Prefixo. O script devera adicionar o ipv6 global da wan e dividir prefixo IPv6 em sub-prefixos de acordo com a quantidade de interfaces locais. Execute "tdhcpc --help" para detalhes de execucao. Por executar em links PPP, o cliente não obedece o tempo de emprestimo. Caso a conexao do tunel seja quebrada tudo devera ser apagado e esquecido. DUIDs ------ DUIDs are a bit of a touchy subject with DHCPv6. Normally fully blown DHCP agents are supposed to create DUIDs when installed using a predefined algorithm. This is not very practical for a configuration-less implementation that moreover works on interfaces that usually don't have the necessary IDs (MACs). Hence this implementation per default creates DUIDs from its own enterprise number plus the local host name. If no option is given both sides automatically calculate a unique code to use as DUID. Both sides use the PEN 0xffffffff plus 0x00 for server side or 0x01 for client side and the MD5 hash of the host name retrieved from the system or given with the --local-id option. If you want to use something else, you can specify your own DUID: Ethernet plus Time: --duid=0001-0001-TIME-MAC -> replace TIME by the current Unix time (print "%08x\n" `date +%s`) -> replace MAC with the MAC address of one of your ethernet cards Ethernet based: --duid=0003-0001-MAC -> replace MAC with the MAC address of one of your ethernet cards Enterprise based: --duid=0002-ENUM-ID -> replace ENUM by your 32bit enterprise number in hex (see http://www.iana.org/assignments/enterprise-numbers) please do not use the default enterprise number when you calculate your own DUID - you risk collision with automatically calculated DUIDs -> replace ID by an arbitrary hex string (with an even number of hex digits!) Known Bugs and Limitations --------------------------- TDHCP is configuration-less. This limits it in certain respects. It is also designed to be very simple - the bare minimum of what is necessary to configure a PPP link or IPv6 tunnel. * it does not keep track of leases * it ignores DUIDs (except for using the server supplied DUID from Advertise messages in its Request messages) * it ignores timers - it always assumes leases to be indefinite * it ignores many message and option types * the server is not able to handle relay agents * it can fail in very interesting ways if there is more than one server on the link it is attached to or if the server feels the need to send more than one reply to a request * it does not perform DAD (duplicate address detection) * it is not unicast enabled (global unicast senders are dropped; packets are only accepted from link-local addresses fe80::/10) * I probably made lots of mistakes about timeouts (some of them deliberate) * it does not support security features I do not plan to fix any of the above - except if someone can convince me that the problem affects PPP or tunnel links. If you find any bug that affects security (and is not caused by an inherent limitation of DHCP), please let me know: tdhcp (AT) silmor (DOT) de Patches to port to other Unixoid systems and for security problems are welcome. Patches that turn it into something resembling ISC DHCP or Dibbler will be dropped.