Que serviço de rede atribui automaticamente endereços IP aos dispositivos na rede?

O protocolo de configuração dinâmica de hosts ( 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 a dispositivos conectados à rede usando uma arquitetura cliente-servidor . [1]

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 protocolo em cada computador ou dispositivo. Quando conectado à rede, e periodicamente depois disso, um cliente solicita um conjunto de parâmetros do servidor DHCP usando o protocolo DHCP.

O DHCP pode ser implementado em redes que variam em tamanho de redes residenciais a grandes redes de campus e redes ISP regionais. [2] Muitos roteadores e gateways residenciais têm capacidade de servidor DHCP. A maioria dos roteadores de rede residencial recebe um endereço IP exclusivo na rede ISP. Em 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 da Internet versão 4 (IPv4), bem como a versão 6 ( IPv6 ). A versão IPv6 do protocolo DHCP é comumente chamada de DHCPv6 .

Em 1984, o Reverse Address Resolution Protocol (RARP), definido no RFC 903, foi introduzido para permitir que dispositivos simples, como estações de trabalho sem disco, obtenham dinamicamente um endereço IP adequado. No entanto, como atuava na camada de enlace de dados , tornava a implementação difícil em muitas plataformas de servidor e também exigia que um servidor estivesse presente em cada link de rede individual. O RARP foi substituído pelo protocolo Bootstrap ( BOOTP ) definido no 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. [3]

O DHCP é baseado no 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. [4] O DHCP foi definido pela primeira vez na 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 [5] e outras pequenas mudanças foram adicionadas pela RFC 2131; que a partir de 2014 continua sendo o padrão para redes IPv4.

O DHCPv6 foi inicialmente descrito pelo RFC 3315 em 2003, mas foi atualizado por muitos RFCs subsequentes. [6] RFC 3633 adicionou um mecanismo DHCPv6 para delegação de prefixo , e autoconfiguração de endereço sem estado foi adicionado por RFC 3736.

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

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 pool 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 nomes e servidores de horário . Ao receber uma solicitação de 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 quaisquer outras informações válidas para toda a rede e pelo período de tempo para o qual a alocação ( aluguel ) é válido. Um cliente DHCP geralmente 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 a 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 sub-redes diferentes.

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

Os serviços DHCP são usados ​​para o protocolo da 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. [7] Para a operação IPv6, os dispositivos podem, alternativamente, usar a autoconfiguração de endereços sem estado . Os hosts IPv6 também podem usar o endereçamento local de link para realizar operações restritas ao link de rede local.

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 para o protocolo de bootstrap ( BOOTP ). A porta UDP número 67 é a porta de destino de um servidor e a porta UDP número 68 é usada pelo cliente.

As operações DHCP se dividem em quatro fases: descoberta do servidor, oferta de aluguel de IP, solicitação de aluguel de IP e confirmação de aluguel de IP. Esses estágios são freqüentemente abreviados como DORA para descoberta, oferta, solicitação e confirmação.

A operação DHCP começa com os clientes transmitindo uma solicitação. Se o cliente e o servidor estiverem em sub-redes diferentes, um DHCP Helper ou DHCP Relay Agent pode ser usado. Os clientes que solicitam a renovação de um aluguel 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, definidos como 0) que o cliente pode usar para indicar de que forma (broadcast ou unicast) ele pode receber o DHCPOFFER: 0x8000 para transmissão, 0x0000 para unicast. [8] Normalmente, o DHCPOFFER é enviado por unicast. Para aqueles hosts que não podem aceitar pacotes unicast antes que os endereços IP sejam configurados, este 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 da sub-rede específica (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á atender à solicitaçã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 autorizado simplesmente ignora a solicitação, levando a um tempo limite dependente da implementação para que o cliente expire a solicitação e solicite 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 é definido como o endereço MAC usado pelo cliente. Algumas opções também estão definidas.

Oferecer

Quando um servidor DHCP recebe uma mensagem DHCPDISCOVER de um cliente, que é uma solicitação de aluguel de endereço IP, o servidor DHCP reserva um endereço IP para o cliente e faz uma oferta de aluguel enviando uma mensagem DHCPOFFER ao cliente. Essa mensagem contém a 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 está fazendo a oferta. O servidor DHCP também pode tomar conhecimento do 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). Aqui, o servidor, 192.168.1.1, especifica o endereço IP do cliente no campo YIADDR (seu endereço IP).

Solicitação

Em resposta à oferta DHCP, o cliente responde com uma mensagem DHCPREQUEST, transmitida ao servidor, [a] solicitando o endereço oferecido. Um cliente pode receber ofertas DHCP de vários servidores, mas aceitará apenas uma oferta DHCP. O cliente produzirá um ARP gratuito para descobrir se há algum outro host presente na rede com o mesmo endereço IP. Se não houver resposta de outro host, significa que não há nenhum host com a mesma configuração de IP na rede e a mensagem é transmitida ao servidor mostrando a aceitação do endereço IP. Com base na opção de identificação do servidor necessária na solicitação e transmissão de mensagens, os servidores são informados cuja oferta o cliente aceitou. [10] : Seção 3.1, Item 3 Quando outros servidores DHCP recebem esta mensagem, eles retiram todas as ofertas que fizeram ao cliente e retornam o endereço IP oferecido ao pool de endereços disponíveis.

Reconhecimento

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 do aluguel e quaisquer outras informações 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 sondar o endereço recém-recebido [11] (por exemplo, com o protocolo de resolução de endereço ARP ) para evitar conflitos de endereço causados ​​pela sobreposição de pools de endereços de servidores DHCP.

Em formação

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 determinado aplicativo. Por exemplo, os navegadores usam o DHCP Inform para obter as configurações do proxy da web via WPAD .

Liberando

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 obriga o envio de Liberação de DHCP .

Um servidor DHCP pode fornecer parâmetros de configuração opcionais ao cliente. O RFC 2132 descreve as opções de DHCP disponíveis definidas pela Internet Assigned Numbers Authority (IANA) - DHCP e BOOTP PARAMETERS. [12]

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

As opções são sequências de octetos de comprimento variável. O primeiro octeto é o código de opção, o segundo octeto é o número de octetos seguintes e os octetos restantes são dependentes 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 seguinte e 0x02 é o valor de "oferta".

As tabelas a seguir listam as opções DHCP disponíveis, conforme listado no RFC 2132 [13] e no registro IANA. [12]

Tipos de mensagens DHCP

Esta tabela lista os tipos de mensagem DHCP, documentados em RFC 2132, RFC 3203, [14] RFC 4388, [15] RFC 6926 [16] e RFC 7724. [17] Esses códigos são o valor na extensão DHCP 53, mostrado em a 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 sequência de caracteres ou octetos de comprimento variável 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 certo tipo de hardware ou firmware é definir um valor em suas solicitações DHCP, chamado de Identificador de Classe do Fornecedor (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 de maneira apropriada. Alguns tipos de decodificadores também definem o VCI (opção 60) para informar ao servidor DHCP sobre o tipo de hardware e a funcionalidade do dispositivo. O valor para o qual essa opção é definida fornece ao servidor DHCP uma dica sobre qualquer informação extra necessária que este cliente precise 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 às solicitações DHCP transmitidas entre uma retransmissão DHCP e um servidor DHCP. [18]

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 o servidor DHCP usando o roteamento IP, porque não possui um endereço IP roteável, não conhece o endereço da camada de link de um roteador e não sabe o endereço IP do servidor DHCP.

Para permitir que clientes DHCP em sub-redes não servidas diretamente por servidores DHCP se comuniquem com servidores DHCP, os agentes de retransmissão DHCP podem ser instalados nessas sub-redes. O cliente DHCP transmite no link local; o agente de retransmissão recebe a transmissão e a transmite para um ou mais servidores DHCP usando unicast . O agente de retransmissão armazena seu próprio endereço IP no campo GIADDR do pacote DHCP. O servidor DHCP usa o valor GIADDR para determinar a sub-rede na qual o agente de retransmissão recebeu a transmissão e aloca um endereço IP nessa sub-rede. Quando o servidor DHCP responde ao cliente, ele envia a resposta ao endereço GIADDR, novamente usando unicast. O agente de retransmissão então retransmite a resposta na rede local.

Nessa situação, a comunicação entre o agente de retransmissão e o servidor DHCP normalmente usa uma porta UDP de origem e de destino de 67.

Conforme descrito na RFC 2131, [10] : Seção 4.4, um cliente DHCP pode receber essas mensagens de um servidor:

• DHCPOFFER
• DHCPACK
• DHCPNAK

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

O DHCP garante confiabilidade de várias maneiras: renovação periódica, religação, [10] : Seção 4.4.5 e failover. Os clientes DHCP são concessões alocadas que duram algum tempo. Os clientes começam a tentar renovar seus aluguéis depois que a metade do intervalo de aluguel expira. [10] : Seção 4.4.5 Parágrafo 3 Eles fazem isso enviando uma mensagem DHCPREQUEST unicast ao 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 vez em quando, [10] : Seção 4.4.5 Parágrafo 8 [b] então se o servidor DHCP voltar a funcionar ou se tornar acessível novamente, o cliente DHCP terá sucesso em contatá-lo e renovar o contrato.

Se o servidor DHCP estiver inacessível por um longo período de tempo, [10] : Seção 4.4.5 Parágrafo 5 o cliente DHCP tentará se religar, transmitindo seu DHCPREQUEST ao invés de unicast. Por ser transmitido , 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 êxito um servidor DHCP de backup, esse servidor deve ter informações precisas sobre a ligação do cliente. Manter informações de ligação precisas entre dois servidores é um problema complicado; se ambos os servidores puderem atualizar o mesmo banco de dados de aluguel, deve haver um mecanismo para evitar conflitos entre as atualizações nos servidores independentes. Uma proposta para a implementação de servidores DHCP tolerantes a falhas foi enviada à Internet Engineering Task Force, mas nunca foi formalizada. [26] [c]

Se a religação falhar, o aluguel acabará por expirar. Quando o aluguel expira, o cliente deve parar de usar o endereço IP concedido a ele em seu aluguel. [10] : Seção 4.4.5 Parágrafo 9 Nesse momento, ele reiniciará o processo DHCP desde o início, transmitindo uma DHCPDISCOVERmensagem. 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á usar a rede novamente. No entanto, como seu endereço IP foi alterado, todas as conexões em andamento serão interrompidas.

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

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

• Servidores DHCP não autorizados que fornecem informações falsas aos clientes. [29]
• Clientes não autorizados com acesso aos recursos. [29]
• Ataques de exaustão de recursos de clientes DHCP maliciosos. [29]

Porque o cliente não tem como validar a identidade de um servidor DHCP, os servidores DHCP não autorizados (comumente chamados de " DHCP desonestos ") podem ser operados em redes, fornecendo informações incorretas para os clientes DHCP. [30] Isso pode servir tanto como um ataque de negação de serviço, impedindo o cliente de obter acesso à conectividade de rede, [31] ou como um ataque man-in-the-middle . [32] Porque o servidor DHCP fornece ao cliente DHCP endereços IP do servidor, como o endereço IP de um ou mais servidores DNS, [29] um invasor pode convencer um cliente DHCP a fazer suas pesquisas DNS através de seu próprio servidor DNS, e pode, portanto, fornecer suas próprias respostas às consultas DNS do cliente. [33] [34] Isso, por sua vez, permite que o invasor redirecione o tráfego da rede através de si mesmo, permitindo-lhe espionar as conexões entre o cliente e os servidores de rede que contata, ou simplesmente substituir esses servidores de rede pelos seus próprios. [33]

Como o servidor DHCP não tem 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. [30] Isso também permite que os clientes DHCP esgotem o armazenamento de endereços IP do servidor DHCP - ao apresentar novas credenciais cada vez que pede um endereço, o cliente pode consumir todos os endereços IP disponíveis em um link de rede específico, evitando que outros clientes DHCP recebendo serviço. [30]

O DHCP fornece alguns mecanismos para atenuar esses problemas. A extensão do protocolo Relay Agent Information Option (RFC 3046, normalmente referido na indústria por seu número real como Opção 82 [35] [36] ) permite que os operadores de rede anexem tags às mensagens DHCP conforme essas mensagens chegam na rede confiável do operador de rede . Essa tag é então 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. [28]

Outra extensão, Autenticação para Mensagens DHCP ( RFC 3118 ), fornece um mecanismo para autenticar mensagens DHCP. Em 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. [37] Um livro de 2007 sobre tecnologias DSL observou que:

várias vulnerabilidades de segurança foram identificadas contra as medidas de segurança propostas pelo RFC 3118. Esse fato, combinado com a introdução do 802.1x , tornou mais lenta a implantação e a taxa de execução do DHCP autenticado e nunca foi amplamente implantado. [38]

Um livro de 2010 observa que:

[t] aqui houve muito poucas implementações de autenticação DHCP. Os desafios de gerenciamento de chaves e atrasos de processamento devido à computação de hash foram considerados um preço muito alto a pagar pelos benefícios percebidos. [39]

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

• RFC 2131, protocolo de configuração dinâmica de host
• RFC 2132, opções de DHCP e extensões de fornecedores BOOTP
• RFC 3046, opção de informações do agente de retransmissão DHCP
• RFC 3397, opção de pesquisa de domínio do protocolo de configuração dinâmica de hosts (DHCP)
• RFC 3942, Opções de Reclassificação do Protocolo de Configuração de Host Dinâmico Versão Quatro (DHCPv4)
• RFC 4242, opção de tempo de atualização de informações para protocolo de configuração dinâmica de hosts para IPv6
• RFC 4361, identificadores de cliente específicos de nó para protocolo de configuração dinâmica de hosts, versão quatro (DHCPv4)
• RFC 4436, Detecção de conexão de rede em IPv4 (DNAv4)
• RFC 3442, Opção Classless Static Route para Dynamic Host Configuration Protocol (DHCP) versão 4
• RFC 3203, extensão de reconfiguração de DHCP
• RFC 4388, Leasequery do protocolo de configuração dinâmica de hosts (DHCP)
• RFC 6926, DHCPv4 Bulk Leasequery
• RFC 7724, Consulta de concessão DHCPv4 ativa

• Mídia relacionada ao protocolo de configuração dinâmica de hosts (DHCP) no Wikimedia Commons