Protocolo de Configuração de Host Dinâmico

O Dynamic Host Configuration Protocol (DHCP) é um protocolo de gerenciamento de rede usado em redes de Protocolo de Internet (IP) para atribuir automaticamente endereços IP e outros parâmetros de comunicação aos dispositivos conectados à rede usando uma arquitetura cliente-servidor.

A tecnologia elimina a necessidade de configurar individualmente os dispositivos de rede manualmente e consiste em dois componentes de rede, um servidor DHCP de rede instalado centralmente e instâncias de cliente da pilha de protocolos em cada computador ou dispositivo. Quando conectado à rede, e periodicamente a partir de então, um cliente solicita um conjunto de parâmetros do servidor usando DHCP.

O DHCP pode ser implementado em redes que variam em tamanho, desde redes residenciais até grandes redes de campus e redes ISP regionais. Muitos roteadores e gateways residenciais possuem capacidade de servidor DHCP. A maioria dos roteadores de rede residencial recebe um endereço IP exclusivo dentro da rede ISP. Dentro de uma rede local, um servidor DHCP atribui um endereço IP local a cada dispositivo.

Os serviços DHCP existem para redes que executam o Protocolo de Internet versão 4 (IPv4), bem como a versão 6 (IPv6). A versão IPv6 do protocolo DHCP é comumente chamada de DHCPv6.

História

O Reverse Address Resolution Protocol (RARP) foi definido no RFC 903 em 1984 para a configuração de dispositivos simples, como estações de trabalho sem disco, com um endereço IP adequado. Atuando na camada de enlace de dados dificultou a implementação em diversas plataformas de servidores. Exigia que um servidor estivesse presente em cada link de rede individual. O RARP foi substituído pelo Protocolo Bootstrap (BOOTP) definido na RFC 951 em setembro de 1985. Isso introduziu o conceito de um agente de retransmissão, que permitia o encaminhamento de pacotes BOOTP pelas redes, permitindo que um servidor BOOTP central atendesse hosts em muitas sub-redes IP.

O DHCP é baseado em BOOTP, mas pode alocar dinamicamente endereços IP de um pool e recuperá-los quando não estiverem mais em uso. Ele também pode ser usado para fornecer uma ampla gama de parâmetros de configuração extras para clientes IP, incluindo parâmetros específicos da plataforma. O DHCP foi definido pela primeira vez no RFC 1531 em outubro de 1993, mas devido a erros no processo editorial foi quase imediatamente reeditado como RFC 1541.

Quatro anos depois, o tipo de mensagem DHCPINFORM e outras pequenas alterações foram adicionadas pela RFC 2131, que a partir de 2021 continua sendo o núcleo do padrão para redes IPv4, com atualizações em RFC 3396, RFC 4361, RFC 5494 e RFC 6842.

O DHCPv6 foi inicialmente descrito pelo RFC 3315 em 2003. Após atualizações por muitos RFCs subsequentes, ele foi substituído pelo RFC 8415, que se fundiu na delegação de prefixo e na configuração automática de endereço sem estado.

Visão geral

Internet Protocol (IP) define como os dispositivos se comunicam dentro e através de redes locais na Internet. Um servidor DHCP pode gerenciar configurações de IP para dispositivos em sua rede local, por exemplo, atribuindo endereços IP a esses dispositivos automática e dinamicamente.

O DHCP opera com base no modelo cliente-servidor. Quando um computador ou outro dispositivo se conecta a uma rede, o software cliente DHCP envia uma consulta de transmissão DHCP solicitando as informações necessárias. Qualquer servidor DHCP na rede pode atender à solicitação. O servidor DHCP gerencia um conjunto de endereços IP e informações sobre os parâmetros de configuração do cliente, como gateway padrão, nome de domínio, servidores de nome e servidores de horário. Ao receber uma solicitação DHCP, o servidor DHCP pode responder com informações específicas para cada cliente, conforme previamente configurado por um administrador, ou com um endereço específico e qualquer outra informação válida para toda a rede e para o período de tempo para o qual a alocação (arrendamento) é válido. Um cliente DHCP normalmente consulta essas informações imediatamente após a inicialização e, posteriormente, periodicamente antes da expiração das informações. Quando um cliente DHCP atualiza uma atribuição, ele inicialmente solicita os mesmos valores de parâmetro, mas o servidor DHCP pode atribuir um novo endereço com base nas políticas de atribuição definidas pelos administradores.

Em grandes redes que consistem em vários links, um único servidor DHCP pode atender toda a rede quando auxiliado por agentes de retransmissão DHCP localizados nos roteadores de interconexão. Esses agentes retransmitem mensagens entre clientes DHCP e servidores DHCP localizados em diferentes sub-redes.

Dependendo da implementação, o servidor DHCP pode ter três métodos de alocação de endereços IP:

Atribuição dinâmica

Um administrador de rede reserva uma gama de endereços IP para DHCP, e cada cliente DHCP na LAN está configurado para solicitar um endereço IP do servidor DHCP durante a inicialização da rede. O processo de solicitação e concessão usa um conceito de arrendamento com um período de tempo controlável, permitindo que o servidor DHCP recupere e, em seguida, realoque endereços IP que não são renovados.

Atribuição automática

O servidor DHCP atribui permanentemente um endereço IP a um cliente solicitante de um intervalo definido por um administrador. Isso é como alocação dinâmica, mas o servidor DHCP mantém uma tabela de atribuições de endereços IP anteriores, de modo que ele possa preferencialmente atribuir a um cliente o mesmo endereço IP que o cliente tinha anteriormente.

Atribuição manual

Este método também é várias vezes chamado alocação de DHCP estática, atribuição de endereço fixo, reservae Ligação de endereço MAC/IP. Um administrador mapeia um identificador único (a cliente id ou endereço MAC) para cada cliente para um endereço IP, que é oferecido ao cliente solicitante. Os servidores DHCP podem ser configurados para voltar a outros métodos se isso falhar.

Os serviços DHCP são usados para Protocolo de Internet versão 4 (IPv4) e IPv6. Os detalhes do protocolo para IPv4 e IPv6 diferem o suficiente para que possam ser considerados protocolos separados. Para a operação IPv6, os dispositivos podem, alternativamente, usar autoconfiguração de endereço sem estado. Os hosts IPv6 também podem usar o endereçamento local de link para obter operações restritas ao link de rede local.

Operação

Uma ilustração de uma sessão DHCP não renovada típica; cada mensagem pode ser uma transmissão ou um unicast, dependendo das capacidades do cliente DHCP.

O DHCP emprega um modelo de serviço sem conexão, usando o User Datagram Protocol (UDP). Ele é implementado com dois números de porta UDP para suas operações, que são os mesmos do protocolo bootstrap (BOOTP). O servidor escuta na porta UDP número 67 e o cliente escuta na porta UDP número 68.

As operações DHCP dividem-se em quatro fases: descoberta de servidor, oferta de concessão de IP, solicitação de concessão de IP e confirmação de concessão de IP. Esses estágios são frequentemente abreviados como DORA para descoberta, oferta, solicitação e reconhecimento.

A operação DHCP começa com os clientes transmitindo uma solicitação. Se o cliente e o servidor estiverem em domínios de difusão diferentes, pode ser usado um auxiliar DHCP ou um agente de retransmissão DHCP. Os clientes que solicitam a renovação de uma concessão existente podem se comunicar diretamente via unicast UDP, desde que o cliente já tenha um endereço IP estabelecido naquele ponto. Além disso, há um sinalizador BROADCAST (1 bit no campo de sinalizadores de 2 bytes, onde todos os outros bits são reservados e, portanto, são definidos como 0) que o cliente pode usar para indicar de que maneira (transmissão ou unicast) ele pode receber o DHCPOFFER: 0x8000 para transmissão, 0x0000 para unicast. Normalmente, o DHCPOFFER é enviado por unicast. Para os hosts que não podem aceitar pacotes unicast antes que os endereços IP sejam configurados, esse sinalizador pode ser usado para contornar esse problema.

Descoberta

O cliente DHCP transmite uma mensagem DHCPDISCOVER na sub-rede da rede usando o endereço de destino 255.255.255.255 (transmissão limitada) ou o endereço de transmissão de sub-rede específico (transmissão direcionada). Um cliente DHCP também pode solicitar seu último endereço IP conhecido. Se o cliente permanecer conectado à mesma rede, o servidor poderá conceder a requisição. Caso contrário, depende se o servidor está configurado como autoritativo ou não. Um servidor autoritativo nega a solicitação, fazendo com que o cliente emita uma nova solicitação. Um servidor não autoritativo simplesmente ignora a solicitação, levando a um tempo limite dependente da implementação para o cliente expirar a solicitação e solicitar um novo endereço IP.

Por exemplo, se HTYPE for definido como 1, para especificar que o meio usado é Ethernet, HLEN é definido como 6 porque um endereço Ethernet (endereço MAC) tem 6 octetos de comprimento. O CHADDR é configurado para o endereço MAC usado pelo cliente. Algumas opções também são definidas.

Oferta

Quando um servidor DHCP recebe uma mensagem DHCPDISCOVER de um cliente, que é uma solicitação de concessão de endereço IP, o servidor DHCP reserva um endereço IP para o cliente e faz uma oferta de concessão enviando uma mensagem DHCPOFFER ao cliente. Esta mensagem contém o ID do cliente do cliente (tradicionalmente um endereço MAC), o endereço IP que o servidor está oferecendo, a máscara de sub-rede, a duração da concessão e o endereço IP do servidor DHCP que faz a oferta. O servidor DHCP também pode observar o endereço MAC de nível de hardware na camada de transporte subjacente: de acordo com as RFCs atuais, o endereço MAC da camada de transporte pode ser usado se nenhum ID de cliente for fornecido no pacote DHCP.

O servidor DHCP determina a configuração com base no endereço de hardware do cliente conforme especificado no campo CHADDR (endereço de hardware do cliente). No exemplo a seguir, o servidor (192.168.1.1) especifica o cliente& #39;s endereço IP no campo YIADDR (seu endereço IP).

Pedido

Em resposta à oferta DHCP, o cliente responde com uma mensagem DHCPREQUEST, transmitida ao servidor, solicitando o endereço oferecido. Um cliente pode receber ofertas DHCP de vários servidores, mas aceitará apenas uma oferta DHCP. Antes de reivindicar um endereço IP, o cliente transmitirá uma solicitação ARP, a fim de descobrir se existe outro host presente na rede com o endereço IP proposto. Se não houver resposta, este endereço não entra em conflito com o de outro host, portanto é livre para ser usado.

O cliente deve enviar a opção identificação do servidor na mensagem DHCPREQUEST, indicando o servidor cuja oferta o cliente selecionou. Quando outros servidores DHCP recebem essa mensagem, eles retiram todas as ofertas feitas ao cliente e retornam o endereço IP oferecido ao pool de endereços disponíveis.

Agradecimento

Quando o servidor DHCP recebe a mensagem DHCPREQUEST do cliente, o processo de configuração entra em sua fase final. A fase de confirmação envolve o envio de um pacote DHCPACK ao cliente. Este pacote inclui a duração da concessão e qualquer outra informação de configuração que o cliente possa ter solicitado. Neste ponto, o processo de configuração de IP está concluído.

O protocolo espera que o cliente DHCP configure sua interface de rede com os parâmetros negociados.

Depois que o cliente obtém um endereço IP, ele deve investigar o endereço recém-recebido (por exemplo, com o protocolo de resolução de endereço ARP) para evitar conflitos de endereço causados por pools de endereços sobrepostos de servidores DHCP. Se esta sonda encontrar outro computador usando esse endereço, o computador deverá enviar DHCPDECLINE, broadcast, para o servidor.

Informações

Um cliente DHCP pode solicitar mais informações do que o servidor enviado com o DHCPOFFER original. O cliente também pode solicitar dados repetidos para um aplicativo específico. Por exemplo, navegadores usam DHCP Inform para obter configurações de proxy da web via WPAD.

Liberação

O cliente envia uma solicitação ao servidor DHCP para liberar as informações do DHCP e o cliente desativa seu endereço IP. Como os dispositivos clientes geralmente não sabem quando os usuários podem desconectá-los da rede, o protocolo não exige o envio de DHCP Release.

Parâmetros de configuração do cliente

Um servidor DHCP pode fornecer parâmetros de configuração opcionais para o cliente. A RFC 2132 descreve as opções disponíveis de DHCP definidas pela Internet Assigned Numbers Authority (IANA) - PARÂMETROS DHCP e BOOTP.

Um cliente DHCP pode selecionar, manipular e substituir parâmetros fornecidos por um servidor DHCP. Em sistemas do tipo Unix, esse refinamento no nível do cliente geralmente ocorre de acordo com os valores no arquivo de configuração /etc/dhclient.conf.

Opções

As opções são cadeias de octetos de comprimento variável. Isso é chamado de codificação Tipo-comprimento-valor. O primeiro octeto é o código de opção, o segundo octeto é o número de octetos seguintes e os octetos restantes dependem do código. Por exemplo, a opção de tipo de mensagem DHCP para uma oferta apareceria como 0x35, 0x01, 0x02, onde 0x35 é o código 53 para "tipo de mensagem DHCP", 0x01 significa um octeto a seguir e 0x02 é o valor de & #34;oferta".

As tabelas a seguir listam as opções de DHCP disponíveis, conforme listado na RFC 2132 e no registro da IANA.

Tipos de mensagem DHCP

Esta tabela lista os tipos de mensagem DHCP, documentados em RFC 2132, RFC 3203, RFC 4388, RFC 6926 e RFC 7724. Esses códigos são o valor na extensão DHCP 53, mostrado na tabela acima.

Identificação do fornecedor do cliente

Existe uma opção para identificar o fornecedor e a funcionalidade de um cliente DHCP. A informação é uma string de comprimento variável de caracteres ou octetos que tem um significado especificado pelo fornecedor do cliente DHCP. Um método pelo qual um cliente DHCP pode se comunicar com o servidor que está usando um determinado tipo de hardware ou firmware é definir um valor em suas solicitações DHCP chamado Vendor Class Identifier (VCI) (Opção 60). Este método permite que um servidor DHCP diferencie entre os dois tipos de máquinas clientes e processe as solicitações dos dois tipos de modems apropriadamente. Alguns tipos de set-top boxes também definem o VCI (opção 60) para informar o servidor DHCP sobre o tipo de hardware e a funcionalidade do dispositivo. O valor para o qual esta opção é definida dá ao servidor DHCP uma dica sobre qualquer informação extra necessária que este cliente precisa em uma resposta DHCP.

Outras extensões

Subopções de informações do agente de retransmissão

A opção de informações do agente de retransmissão (opção 82) especifica o contêiner para anexar subopções a solicitações DHCP transmitidas entre uma retransmissão DHCP e um servidor DHCP.

Retransmissão

Em redes pequenas, onde apenas uma sub-rede IP está sendo gerenciada, os clientes DHCP se comunicam diretamente com os servidores DHCP. No entanto, os servidores DHCP também podem fornecer endereços IP para várias sub-redes. Nesse caso, um cliente DHCP que ainda não adquiriu um endereço IP não pode se comunicar diretamente com um servidor DHCP que não esteja na mesma sub-rede, pois a transmissão do cliente só pode ser recebida em sua própria sub-rede.

Para permitir que clientes DHCP em sub-redes não atendidas diretamente por servidores DHCP se comuniquem com servidores DHCP, agentes de retransmissão DHCP podem ser instalados nessas sub-redes. Um agente de retransmissão DHCP é executado em um dispositivo de rede, capaz de rotear entre a sub-rede do cliente e a sub-rede do servidor DHCP. O cliente DHCP transmite no link local; o agente de retransmissão recebe o broadcast e o transmite para um ou mais servidores DHCP usando unicast. Os endereços IP dos servidores DHCP são configurados manualmente no agente de retransmissão. O agente de retransmissão armazena seu próprio endereço IP, da interface na qual recebeu o broadcast do cliente, no campo GIADDR do pacote DHCP. O servidor DHCP usa o valor GIADDR para determinar a sub-rede e, subsequentemente, o pool de endereços correspondente, a partir do qual alocar um endereço IP. Quando o servidor DHCP responde ao cliente, ele envia a resposta para o endereço GIADDR, novamente usando unicast. O agente de retransmissão então retransmite a resposta na rede local, usando unicast (na maioria dos casos) para o endereço IP recém-reservado, em um quadro Ethernet direcionado ao endereço MAC do cliente. O cliente deve aceitar o pacote como seu, mesmo que esse endereço IP ainda não esteja definido na interface. Diretamente após o processamento do pacote, o cliente define o endereço IP em sua interface e está pronto para a comunicação regular do IP imediatamente a seguir.

Se a implementação do cliente da pilha IP não aceitar pacotes unicast quando ainda não tiver um endereço IP, o cliente poderá definir o bit broadcast no campo FLAGS ao enviar um DHCPDISCOVER pacote. O agente de retransmissão usará o endereço IP de transmissão 255.255.255.255 (e o endereço MAC do cliente) para informar o cliente sobre o DHCPOFFER do servidor.

A comunicação entre o agente de retransmissão e o servidor DHCP geralmente usa uma porta UDP de origem e destino de 67.

Estados do cliente

Um diagrama simplificado de transição do estado do cliente DHCP baseado na figura 5 do RFC 2131.

Conforme descrito no RFC 2131, um cliente DHCP pode receber estas mensagens de um servidor:

• DHCPOFFER
• DHCPACK
• DHCPNAK

O cliente se move pelos estados DHCP dependendo de como o servidor responde às mensagens que o cliente envia.

Confiabilidade

O DHCP garante a confiabilidade de várias maneiras: renovação periódica, religação e failover. Os clientes DHCP recebem concessões que duram algum período de tempo. Os clientes começam a tentar renovar seus aluguéis uma vez que metade do intervalo de arrendamento tenha expirado. Eles fazem isso enviando uma mensagem unicast DHCPREQUEST para o servidor DHCP que concedeu a concessão original. Se esse servidor estiver inativo ou inacessível, ele não responderá ao DHCPREQUEST. No entanto, nesse caso, o cliente repete o DHCPREQUEST de tempos em tempos, portanto, se o servidor DHCP voltar a funcionar ou ficar acessível novamente, o cliente DHCP conseguirá contatá-lo e renovar a concessão.

Se o servidor DHCP estiver inacessível por um longo período de tempo, o cliente DHCP tentará religar, transmitindo seu DHCPREQUEST em vez de unicast. Por ser broadcast, a mensagem DHCPREQUEST alcançará todos os servidores DHCP disponíveis. Se algum outro servidor DHCP puder renovar a concessão, ele o fará neste momento.

Para que a religação funcione, quando o cliente contata com sucesso um servidor DHCP de backup, esse servidor deve ter informações precisas sobre a ligação do cliente. A manutenção de informações de ligação precisas entre dois servidores é um problema complicado; se ambos os servidores puderem atualizar o mesmo banco de dados de concessão, deve haver um mecanismo para evitar conflitos entre atualizações nos servidores independentes. Uma proposta para implementar servidores DHCP tolerantes a falhas foi submetida à Força-Tarefa de Engenharia da Internet, mas nunca foi formalizada.

Se a religação falhar, a concessão acabará por expirar. Quando a concessão expirar, o cliente deve parar de usar o endereço IP concedido a ele em sua concessão. Nesse momento, ele reiniciará o processo DHCP desde o início, transmitindo uma mensagem DHCPDISCOVER. Como seu aluguel expirou, ele aceitará qualquer endereço IP oferecido a ele. Assim que tiver um novo endereço IP (presumivelmente de um servidor DHCP diferente), ele poderá novamente usar a rede. No entanto, como seu endereço IP foi alterado, todas as conexões em andamento serão interrompidas.

Redes IPv6

A metodologia básica do DHCP foi desenvolvida para redes baseadas no Internet Protocol versão 4 (IPv4). Desde o desenvolvimento e implantação de redes IPv6, o DHCP também tem sido usado para atribuir parâmetros nessas redes, apesar dos recursos inerentes do IPv6 para autoconfiguração de endereço sem estado. A versão IPv6 do protocolo é designada como DHCPv6.

Segurança

O DHCP base não inclui nenhum mecanismo de autenticação. Por causa disso, é vulnerável a uma variedade de ataques. Esses ataques se enquadram em três categorias principais:

• Servidores DHCP não autorizados fornecendo informações falsas aos clientes.
• Clientes não autorizados ganham acesso a recursos.
• Ataques de exaustão de recursos de clientes DHCP maliciosos.

Como o cliente não tem como validar a identidade de um servidor DHCP, servidores DHCP não autorizados (comumente chamados de "rogue DHCP") podem ser operados em redes, fornecendo informações incorretas aos clientes DHCP. Isso pode servir como um ataque de negação de serviço, impedindo que o cliente obtenha acesso à conectividade de rede, ou como um ataque man-in-the-middle. Como o servidor DHCP fornece ao cliente DHCP endereços IP do servidor, como o endereço IP de um ou mais servidores DNS, um invasor pode convencer um cliente DHCP a fazer suas pesquisas de DNS por meio de seu próprio servidor DNS e, portanto, fornecer suas próprias respostas às consultas de DNS do cliente. Isso, por sua vez, permite que o invasor redirecione o tráfego de rede por si mesmo, permitindo que ele espie as conexões entre o cliente e os servidores de rede com os quais contata ou simplesmente substitua esses servidores de rede pelos seus.

Como o servidor DHCP não possui um mecanismo seguro para autenticar o cliente, os clientes podem obter acesso não autorizado a endereços IP apresentando credenciais, como identificadores de cliente, que pertencem a outros clientes DHCP. Isso também permite que os clientes DHCP esgotem o armazenamento de endereços IP do servidor DHCP - apresentando novas credenciais cada vez que solicita um endereço, o cliente pode consumir todos os endereços IP disponíveis em um link de rede específico, impedindo que outros clientes DHCP de obter serviço.

O DHCP fornece alguns mecanismos para mitigar esses problemas. A extensão do protocolo Relay Agent Information Option (RFC 3046, geralmente referido na indústria por seu número real como Opção 82) permite que as operadoras de rede anexem tags a mensagens DHCP à medida que essas mensagens chegam à operadora de rede&# 39;s rede confiável. Essa tag é usada como um token de autorização para controlar o acesso do cliente aos recursos da rede. Como o cliente não tem acesso à rede upstream do agente de retransmissão, a falta de autenticação não impede que o operador do servidor DHCP confie no token de autorização.

Outra extensão, Autenticação para Mensagens DHCP (RFC 3118), fornece um mecanismo para autenticação de mensagens DHCP. A partir de 2002, o RFC 3118 não tinha sido amplamente adotado devido aos problemas de gerenciamento de chaves para um grande número de clientes DHCP. Um livro de 2007 sobre tecnologias DSL observou que:

foram identificadas numerosas vulnerabilidades de segurança contra as medidas de segurança propostas pelo RFC 3118. Este fato, combinado com a introdução de 802.1x, abrandou a implantação e a taxa de aceitação do DHCP autenticado, e nunca foi amplamente implantado.

Um livro de 2010 observa que:

[t] aqui foram poucas implementações de Autenticação DHCP. Os desafios dos atrasos principais de gestão e processamento devido à computação hash foram considerados um preço muito pesado para pagar pelos benefícios percebidos.

As propostas arquitetônicas de 2008 envolvem a autenticação de solicitações DHCP usando 802.1x ou PANA (ambos transportam EAP). Foi feita uma proposta da IETF para incluir o EAP no próprio DHCP, o chamado EAPoDHCP; isso não parece ter progredido além do nível de rascunho da IETF, o último dos quais data de 2010.

Documentos de padrões IETF

• RFC 2131, Protocolo de Configuração de Anfitrião Dinâmico
• RFC 2132, Opções DHCP e Extensões de Fornecedor BOOTP
• RFC 3046, DHCP Relay Agent Opção de informação
• RFC 3397, Opção de pesquisa de domínio do protocolo de configuração dinâmica do host (DHCP)
• RFC 3942, Reclassificando o Protocolo de Configuração de Anfitrião Dinâmico Versão Quatro (DHCPv4) Opções
• RFC 4242, Opção de tempo de atualização de informações para protocolo de configuração dinâmica do host para IPv6
• RFC 4361, Identificadores de Clientes específicos de nó para Protocolo de Configuração de Anfitrião Dinâmico Versão Quatro (DHCPv4)
• RFC 4436, Detectando anexo de rede em IPv4 (DNAv4)
• RFC 3442, Opção de rota estática sem classes para protocolo de configuração dinâmica do host (DHCP) versão 4
• RFC 3203, extensão de reconfiguração DHCP
• RFC 4388, Leasequery do protocolo de configuração de host dinâmico (DHCP)
• RFC 6926, lâmpada DHCPv4 Leaseque
• RFC 7724, Active DHCPv4 Lease Query