Dynamic Host Configuration Protocol
| Pilha de protocolos TCP/IP |
|---|
| Camada de aplicação |
| Camada de transporte |
| Camada de rede |
| Camada de enlace de dados |
O DHCP, Dynamic Host Configuration Protocol (protocolo de configuração dinâmica de host), é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host, máscara de sub-rede, default gateway (gateway padrão), número IP de um ou mais servidores DNS, sufixos de pesquisa do DNS e número IP de um ou mais servidores WINS. Este protocolo é o sucessor do BOOTP que, embora mais simples, tornou-se limitado para as exigências atuais. O DHCP surgiu como um padrão em outubro de 1993. O RFC 2131 (1997) contém as especificações mais atuais. O último standard para a especificação do DHCP sobre IPv6 (DHCPv6) foi publicado como RFC 3315 (2003).
Funcionamento Básico[editar | editar código-fonte]
O DHCP usa um modelo cliente-servidor.
Resumidamente, o DHCP opera da seguinte forma:
- Quando um computador (ou outro dispositivo) se conecta a uma rede, o host/cliente DHCP envia um pacote UDP em broadcast (destinado a todas as máquinas) com uma requisição DHCP (para a porta 67);
- Qualquer servidor DHCP na rede pode responder a requisição. O servidor DHCP mantém o gerenciamento centralizado dos endereços IP usados na rede e informações sobre os parâmetros de configuração dos clientes como gateway padrão, nome do domínio, servidor de nomes e servidor de horário. Os servidores DHCP que capturarem este pacote responderão (se o cliente se enquadrar numa série de critérios — ver abaixo) para a porta 68 do host solicitante com um pacote com configurações onde constará, pelo menos, um endereço IP e uma máscara de rede, além de dados opcionais, como o gateway, servidores de DNS, etc.
Termos Utilizados no DHCP[editar | editar código-fonte]
Servidor DHCP: É um servidor onde foi instalado e configurado o serviço DHCP. Em Microsoft Windows, após a instalação de um servidor DHCP ele precisa ser autorizado no Active Directory, antes que possa efetivamente atender pedidos de clientes. O procedimento de autorização no Active Directory é uma medida de segurança, para evitar que servidores DHCP sejam introduzidos na rede sem o conhecimento do administrador da rede. Além do Windows Server, o serviço de DHCP também pode ser instalado nas distribuições Linux, como o serviço DHCP3 Server, pacote já presente na maioria das distribuições servidoras de Linux. O servidor DHCP não está disponível para Windows 2000 Professional, Windows XP Professional ou Windows Vista.
Cliente DHCP: É qualquer dispositivo de rede capaz de obter as configurações do TCP/IP a partir de um servidor DHCP. Por exemplo, uma estação de trabalho com o Microsoft Windows 10, uma estação com qualquer distribuição Linux, uma impressora com placa de rede habilitada ao DHCP, etc.
Escopo: Um escopo é o intervalo consecutivo completo dos endereços IP possíveis para uma rede (por exemplo, a faixa de 10.10.10.100 a 10.10.10.150, na rede 10.10.10.0/255.255.255.0). Em geral, os escopos definem uma única sub-rede física, na rede na qual serão oferecidos serviços DHCP. Os escopos também fornecem o método principal para que o servidor gerencie a distribuição e atribuição de endereços IP e outros parâmetros de configuração para clientes na rede, tais como o default gateway, servidor DNS e assim por diante.
Superescopo: Um superescopo é um agrupamento administrativo de escopos que pode ser usado para oferecer suporte a várias sub-redes IP lógicas na mesma sub-rede física. Os superescopos contêm somente uma lista de escopos associados ou escopos filhos que podem ser ativados em conjunto. Os superescopos não são usados para configurar outros detalhes sobre o uso de escopo. Para configurar a maioria das propriedades usadas em um superescopo, é necessário configurar propriedades de cada escopo associado, individualmente. Por exemplo, se todos os computadores devem receber o mesmo número IP de default gateway, este número tem que ser configurado em cada escopo, individualmente. Não tem como fazer esta configuração no superescopo e todos os escopos (que compõem o superescopo), herdarem estas configurações.
Intervalo de exclusão: Um intervalo de exclusão é uma sequência limitada de endereços IP dentro de um escopo, excluído dos endereços que são fornecidos pelo DHCP. Os intervalos de exclusão asseguram que quaisquer endereços nesses intervalos não são oferecidos pelo servidor para clientes DHCP na sua rede. Por exemplo, dentro da faixa 10.10.10.100 a 10.10.10.150, na rede 10.10.10.0/255.255.255.0 de um determinado escopo, pode-se criar uma faixa de exclusão de 10.10.10.120 a 10.10.10.130. Os endereços da faixa de exclusão não serão utilizados pelo servidor DHCP para configurar os clientes DHCP.
Pool de endereços: Após definir um escopo DHCP e aplicar intervalos de exclusão, os endereços remanescentes formam o pool de endereços disponíveis dentro do escopo. Endereços em pool são qualificados para atribuição dinâmica pelo servidor para clientes DHCP na sua rede. No nosso exemplo, onde temos o escopo com a faixa 10.10.10.100 a 10.10.10.150, com uma faixa de exclusão de 10.10.10.120 a 10.10.10.130, o nosso pool de endereços é formado pelos endereços de 10.10.10.100 a 10.10.10.119, mais os endereços de 10.10.10.131 a 10.10.10.150.
Concessão: Uma concessão é um período de tempo especificado por um servidor DHCP durante o qual um computador cliente pode usar um endereço IP que ele recebeu do servidor DHCP (diz-se atribuído pelo servidor DHCP). Uma concessão está ativa quando ela está sendo utilizada pelo cliente. Geralmente, o cliente precisa renovar sua atribuição de concessão de endereço com o servidor antes que ela expire. Uma concessão torna-se inativa quando ela expira ou é excluída no servidor. A duração de uma concessão determina quando ela expirará e com que frequência o cliente precisa renová-la no servidor.
Reserva: Usa-se uma reserva para criar uma concessão de endereço permanente pelo servidor DHCP. As reservas asseguram que um dispositivo de hardware especificado na sub-rede sempre pode usar o mesmo endereço IP. A reserva é criada associada ao endereço de hardware da placa de rede, conhecido como endereço MAC (ou MAC address). No servidor DHCP cria-se uma reserva, associando um endereço IP com um endereço MAC. Quando o computador (com o endereço MAC para o qual existe uma reserva) é inicializado, ele entre em contato com o servidor DHCP. O servidor DHCP verifica que existe uma reserva para aquele MAC address e configura o computador com o endereço IP associado ao MAC address. Caso haja algum problema na placa de rede do computador e a placa tenha que ser substituída, mudará o MAC address e a reserva anterior terá que ser excluída e uma nova reserva terá que ser criada, utilizando, agora, o novo MAC address.
Tipos de opção: Tipos de opção são outros parâmetros de configuração do cliente que um servidor DHCP pode atribuir aos clientes. Por exemplo, algumas opções usadas com frequência incluem endereços IP para gateways padrão (roteadores), servidores WINS (Windows Internet Name System) e servidores DNS (Domain Name System). Geralmente, esses tipos de opção são ativados e configurados para cada escopo. O console de Administração do serviço DHCP também permite configurar tipos de opção padrão que são usados por todos os escopos adicionados e configurados no servidor. A maioria das opções é predefinida através da RFC 2132, mas pode-se usar o console DHCP para definir e adicionar tipos de opção personalizados, se necessário.
Critérios de atribuição de IPs[editar | editar código-fonte]
O DHCP, dependendo da implementação, pode oferecer três tipos de alocação de endereços IP:
- Atribuição manual - Onde existe uma tabela de associação entre o endereço MAC do cliente (que será comparado através do pacote broadcast recebido) e o endereço IP (e dados restantes) a fornecer. Esta associação é feita manualmente pelo administrador de rede; por conseguinte, apenas os clientes cujo MAC consta nesta lista poderão receber configurações desse servidor;
- Atribuição automática - Onde o cliente obtém um endereço de um espaço de endereços possíveis, especificado pelo administrador. Geralmente não existe vínculo entre os vários MAC habilitados a esse espaço de endereços;
- Atribuição dinâmica - O único método que dispõe a reutilização dinâmica dos endereços. O administrador disponibiliza um espaço de endereços possíveis, e cada cliente terá o software TCP/IP da sua interface de rede configurados para requisitar um endereço por DHCP assim que a máquina for ligada na rede. A alocação utiliza um mecanismo de aluguel do endereço, caracterizado por um tempo de vida. Zerado/expirado esse tempo de vida naturalmente, da próxima vez que o cliente se conectar, o endereço provavelmente será outro.
Algumas implementações do software servidor de DHCP permitem ainda a atualização dinâmica dos servidores de DNS para que cada cliente disponha também de um DNS. Este mecanismo utiliza o protocolo de atualização do DNS especificado no RFC 2136.
Detalhes técnicos[editar | editar código-fonte]
O DHCP (Dynamic Host Configuration Protocol) utiliza o modelo cliente-servidor, no qual o cliente solicita o endereço e obtém a concessão de um IP, envolvendo quatro passos, que seguem a seguinte ordem (conforme figura ao lado):
- discovery (descoberta)
- offer (oferta)
- request (pedido)
- acknowledge (confirmação)
DHCPDISCOVERY (descoberta)[editar | editar código-fonte]
O cliente transmite mensagens na sub-rede física para descobrir os servidores DHCP disponíveis. Os administradores de rede podem configurar um roteador local para encaminhar pacotes DHCP a um servidor DHCP de uma sub-rede diferente. Este cliente cria um pacote UDP (User Datagram Protocol), com o destino de difusão 255.255.255.255 ou o endereço de broadcast de sub-rede específica. Um cliente DHCP também pode solicitar o seu último endereço IP conhecido (no exemplo abaixo, 192.168.1.100). Se o cliente permanece conectado a uma rede IP para o qual este é válido, o servidor pode satisfazer o pedido. Caso contrário, ele depende se o servidor está configurado no modo autoritário ou não. Um servidor no modo autoritário negará o pedido, fazendo o cliente pedir um novo endereço IP imediatamente. Um servidor no modo não autoritário simplesmente ignora o pedido, levando a um limite de tempo, dependente da implementação, para o cliente desistir do pedido e pedir um novo endereço IP.
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0x00000000 | ||||
| SIADDR (Server IP Address) | ||||
| 0x00000000 | ||||
| GIADDR (Gateway IP Address switched by relay) | ||||
| 0x00000000 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000
| ||||
| 0x00000000 | ||||
| 192 octets of 0s. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| 53: DHCP Discover | ||||
| 1: subnet mask | ||||
| 3: router | ||||
| 54: DHCP server | ||||
| 6: DNS servers | ||||
DHCPOFFER (oferta)[editar | editar código-fonte]
Quando um servidor DHCP recebe um pedido de concessão de IP de um cliente, ele reserva um endereço IP para o cliente (essa reserva é opcional, segundo a RFC 2131 - 3.1.2) e estende uma oferta de concessão IP através do envio de uma mensagem DHCPOFFER para o cliente. Esta mensagem contém o endereço MAC do cliente, o endereço IP que o servidor está oferecendo, a máscara de sub-rede, a duração da concessão, bem como o endereço IP do servidor de DHCP que faz a oferta. O servidor determina a configuração com base no endereço de hardware do cliente como especificado no campo CHADDR (endereço de hardware do cliente). Aqui o servidor, 192.168.1.1, especifica o endereço IP no campo YIADDR (seu endereço IP).
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0xC0A80164 (192.168.1.100) | ||||
| SIADDR (Server IP Address) | ||||
| 0xC0A80101 (192.168.1.1) | ||||
| GIADDR (Gateway IP Address) | ||||
| 0x00000000 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0s. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| 53: DHCP Offer | ||||
| 1: 255.255.255.0 subnet mask | ||||
| 3: 192.168.1.1 router | ||||
| 51: 86400s (1 day) IP lease time | ||||
| 54: 192.168.1.1 DHCP server | ||||
6: DNS servers:
| ||||
DHCPREQUEST (pedido)[editar | editar código-fonte]
Em resposta aos pedidos de oferta do servidor, o cliente responde com um DHCPREQUEST, ainda em broadcast (para ser visível por todos os DHCP servers), solicitando o endereço oferecido. Um cliente pode receber ofertas de vários servidores DHCP, mas vai aceitar apenas uma oferta DHCP. Com base no campo ID da transação no pedido, os servidores são informados da oferta que o cliente aceitou. Quando outros servidores DHCP receberem esta mensagem, eles retiram quaisquer ofertas que eles poderiam ter feito para o cliente e retornam o endereço oferecido ao pool de endereços disponíveis. Em alguns casos, DHCPMESSAGE é transmitido em broadcast, em vez de ser unicast para um servidor DHCP particular, porque o cliente DHCP ainda não recebeu um endereço IP. Além disso, esta mensagem de uma forma pode deixar todos os outros servidores DHCP saberem que outro servidor fornecerá o endereço IP sem perder qualquer um dos servidores com uma série de mensagens unicast. A mensagem DHCPREQUEST também é utilizada pelo cliente DHCP para renovar o período de concessão do endereço de rede de tempo em tempo (dependente do período de concessão configurado no servidor DHCP e de implementação do cliente).
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x01 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0x00000000 | ||||
| SIADDR (Server IP Address) | ||||
| 0xC0A80101 (192.168.1.1) | ||||
| GIADDR (Gateway IP Address) | ||||
| 0x000000080 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C03 | ||||
| 0x8D590002 | ||||
| 0x00000001 | ||||
| 0x00000009 | ||||
| 192 octets of 0s. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| 53: DHCP Request | ||||
| 50: 192.168.1.100 requested | ||||
| 54: 192.168.1.1 DHCP server | ||||
DHCPACK (confirmação)[editar | editar código-fonte]
Quando o servidor DHCP recebe a mensagem DHCPREQUEST do cliente, o processo de configuração entra em sua fase final. A fase de reconhecimento envolve o envio de um pacote DHCPACK para o cliente. Este pacote inclui a duração da concessão e quaisquer outras informações de configuração que o cliente pode ter solicitado. Neste ponto, o processo de configuração de IP é concluído. O protocolo prevê que o cliente DHCP configurará sua interface de rede com os parâmetros negociados.
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0xC0A80164 (192.168.1.100) | ||||
| SIADDR (Server IP Address) | ||||
| 0xC0A80101 (192.168.1.1) | ||||
| GIADDR (Gateway IP Address switched by relay) | ||||
| 0x00000000 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000
| ||||
| 0x00000000 | ||||
| 192 octets of 0s. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| 53: DHCP ACK | ||||
| 1: 255.255.255.0 subnet mask | ||||
| 3: 192.168.1.1 router | ||||
| 51: 86400s (1 day) IP lease time | ||||
| 54: 192.168.1.1 DHCP server | ||||
6: DNS servers:
| ||||
Informações DHCP[editar | editar código-fonte]
Um cliente DHCP pode solicitar mais informações do que o servidor enviou com o DHCPOFFER original. O cliente também pode solicitar dados repetidos para uma determinada aplicação. Por exemplo, os navegadores usam DHCPINFORM para obter as configurações de proxy web via WPAD. Estas consultas com o servidor DHCP não servem para atualizar o tempo de concessão do IP em seu banco de dados (para isso é enviada a mensagem DHCPREQUEST).
Liberando DHCP[editar | editar código-fonte]
O cliente envia uma solicitação (DHCPRELEASE) ao servidor DHCP para liberar a configuração de rede e o cliente DHCP desativa seu endereço IP. Como os dispositivos de lado do cliente geralmente não sabem quando os usuários podem desligá-los da rede, o protocolo não obriga o envio de DHCPRELEASE.
Parâmetros de configuração de cliente no DHCP[editar | editar código-fonte]
Um servidor DHCP pode fornecer parâmetros de configuração opcionais para o cliente. RFC 2132 descreve as opções disponíveis DHCP definidas pelo Internet Assigned Numbers Authority (IANA) - DHCP e PARÂMETROS BOOTP. Um cliente DHCP pode selecionar, manipular e substituir os parâmetros fornecidos por um servidor DHCP.
Opções do DHCP[editar | editar código-fonte]
Existe uma opção para identificar o fornecedor e funcionalidade de um cliente DHCP. A informação é uma sequência de comprimento variável de caracteres ou octetos que tem um significado especificado pelo fornecedor do cliente DHCP. Um método que um cliente DHCP pode utilizar para se comunicar com o servidor que está usando um certo tipo de hardware ou de firmware é definir um valor em seus pedidos de DHCP chamado de classe de fornecedor Identifier (VCI) (Opção 60). Este método permite a um servidor DHCP para diferenciar entre os dois tipos de máquinas de cliente e processar os pedidos provenientes dos dois tipos de modems de forma adequada. Alguns tipos de set-top boxes também definir a VCI (Opção 60) para informar o servidor DHCP sobre o tipo de hardware e funcionalidade do dispositivo. O valor que essa opção é definida para dar ao servidor DHCP uma dica sobre as informações necessárias extra que este cliente precisa de uma resposta do DHCP.[1]
| Code | Name | Length | Notes |
|---|---|---|---|
| 0 | Pad[2] | 1 octet | Can be used to pad other options so that they are aligned to the word boundary |
| 1 | Subnet Mask[3] | 4 octets | Must be sent after the router option (option 3) if both are included |
| 2 | Time Offset[4] | 4 octets | |
| 3 | Router | multiples of 4 octets | Available routers, should be listed in order of preference |
| 4 | Time Server | multiples of 4 octets | Available time servers to synchronise with, should be listed in order of preference |
| 5 | Name Server | multiples of 4 octets | Available IEN116 name servers, should be listed in order of preference |
| 6 | Domain Name Server | multiples of 4 octets | Available DNS servers, should be listed in order of preference |
| 7 | Log Server | multiples of 4 octets | Available log servers, should be listed in order of preference. |
| 8 | Cookie Server | multiples of 4 octets | |
| 9 | LPR Server | multiples of 4 octets | |
| 10 | Impress Server | multiples of 4 octets | |
| 11 | Resource Location Server | multiples of 4 octets | |
| 12 | Host Name | minimum of 1 octet | |
| 13 | Boot File Size | 2 octets | Length of the boot image in 4KiB blocks |
| 14 | Merit Dump File | minimum of 1 octet | Path where crash dumps should be stored |
| 15 | Domain Name | minimum of 1 octet | |
| 16 | Swap Server | 4 octets | |
| 17 | Root Path | minimum of 1 octet | |
| 18 | Extensions Path | minimum of 1 octet | |
| 255 | End | 0 octets | Used to mark the end of the vendor option field |
| Code | Name | Length | Notes |
|---|---|---|---|
| 19 | IP Forwarding Enable/Disable | 1 octet | |
| 20 | Non-Local Source Routing Enable/Disable | 1 octet | |
| 21 | Policy Filter | multiples of 8 octets | |
| 22 | Maximum Datagram Reassembly Size | 2 octets | |
| 23 | Default IP Time-to-live | 1 octet | |
| 24 | Path MTU Aging Timeout | 4 octets | |
| 25 | Path MTU Plateau Table | multiples of 2 octets |
| Code | Name | Length | Notes |
|---|---|---|---|
| 26 | Interface MTU | 2 octets | |
| 27 | All Subnets are Local | 1 octet | |
| 28 | Broadcast Address | 4 octets | |
| 29 | Perform Mask Discovery | 1 octet | |
| 30 | Mask Supplier | 1 octet | |
| 31 | Perform Router Discovery | 1 octet | |
| 32 | Router Solicitation Address | 4 octets | |
| 33 | Static Route | multiples of 8 octets | A list of destination/router pairs |
| Code | Name | Length | Notes |
|---|---|---|---|
| 34 | Trailer Encapsulation Option | 1 octet | |
| 35 | ARP Cache Timeout | 4 octets | |
| 36 | Ethernet Encapsulation | 1 octet |
| Code | Name | Length | Notes |
|---|---|---|---|
| 37 | TCP Default TTL | 1 octet | |
| 38 | TCP Keepalive Interval | 4 octets | |
| 39 | TCP Keepalive Garbage | 1 octet |
| Code | Name | Length | Notes |
|---|---|---|---|
| 40 | Network Information Service Domain | minimum of 1 octet | |
| 41 | Network Information Servers | multiples of 4 octets | |
| 42 | Network Time Protocol Servers | multiples of 4 octets | |
| 43 | Vendor Specific Information | minimum of 1 octets | |
| 44 | NetBIOS over TCP/IP Name Server | multiples of 4 octets | |
| 45 | NetBIOS over TCP/IP Datagram Distribution Server | multiples of 4 octets | |
| 46 | NetBIOS over TCP/IP Node Type | 1 octet | |
| 47 | NetBIOS over TCP/IP Scope | minimum of 1 octet | |
| 48 | X Window System Font Server | multiples of 4 octets | |
| 49 | X Window System Display Manager | multiples of 4 octets | |
| 64 | Network Information Service+ Domain | minimum of 1 octet | |
| 65 | Network Information Service+ Servers | multiples of 4 octets | |
| 68 | Mobile IP Home Agent | multiples of 4 octets | |
| 69 | Simple Mail Transport Protocol (SMTP) Server | multiples of 4 octets | |
| 70 | Post Office Protocol (POP3) Server | multiples of 4 octets | |
| 71 | Network News Transport Protocol (NNTP) Server | multiples of 4 octets | |
| 72 | Default World Wide Web (WWW) Server) | multiples of 4 octets | |
| 73 | Default Finger Server | multiples of 4 octets | |
| 74 | Default Internet Relay Chat (IRC) Server | multiples of 4 octets | |
| 75 | StreetTalk Server | multiples of 4 octets | |
| 76 | StreetTalk Directory Assistance (STDA) Server | multiples of 4 octets |
| Code | Name | Length | Notes |
|---|---|---|---|
| 50 | Requested IP Address | 4 octets | |
| 51 | IP Address Lease Time | 4 octets | |
| 52 | Option Overload | 1 octet | |
| 53 | DHCP Message Type | 1 octet | |
| 54 | Server Identifier | 4 octets | |
| 55 | Parameter Request List | minimum of 1 octet | |
| 56 | Message | minimum of 1 octet | |
| 57 | Maximum DHCP Message Size | 2 octets | |
| 58 | Renewal (T1) Time Value | 4 octets | |
| 59 | Rebinding (T2) Time Value | 4 octets | |
| 60 | Vendor class identifier | minimum of 1 octet | |
| 61 | Client-identifier | minimum of 2 octets | |
| 66 | TFTP server name | minimum of 1 octet | |
| 67 | Bootfile name | minimum of 1 octet |
Retransmissão DHCP[editar | editar código-fonte]
Em redes pequenas, onde apenas uma sub-rede IP está a ser gerido, os clientes DHCP se comunicar diretamente com os servidores DHCP. No entanto, os servidores DHCP também pode fornecer endereços IP para várias sub-redes. Neste caso, um cliente DHCP que ainda não adquiriu um endereço IP não podem se comunicar diretamente com o servidor DHCP usando o roteamento IP, porque não tem um endereço de IP, nem ele sabe o endereço IP de um roteador. A fim de permitir que os clientes DHCP em sub-redes não diretamente servidos por servidores DHCP para se comunicar com servidores DHCP, os agentes de retransmissão DHCP pode ser instalado nesses sub-redes. As transmissões do cliente DHCP no link local, o agente de retransmissão recebe a transmissão e 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 GIADDR para determinar a sub-rede na qual o agente de retransmissão recebeu a transmissão, e atribui um endereço IP na sub-rede. Quando as respostas do servidor DHCP para o 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.
Confiabilidade[editar | editar código-fonte]
O protocolo DHCP fornece confiabilidade de várias maneiras: renovação periódica, religação e failover. Clientes DHCP são atribuídos locações que duram por algum período de tempo. Os clientes começam a tentar renovar suas concessões uma vez metade do intervalo o arrendamento expirou. Eles fazem isso através do envio de uma mensagem DHCPREQUEST unicast para o servidor DHCP que concedeu o contrato original. Se esse servidor for inativo ou inacessível, ele vai deixar de responder ao DHCPREQUEST. No entanto, o DHCPREQUEST será repetido pelo cliente ao longo do tempo, [especificar], para quando o servidor DHCP volta-se ou torna-se acessível novamente, o cliente DHCP vai conseguir entrar em contato com ela, e renovar o seu contrato. Se o servidor DHCP está inacessível por um período prolongado de tempo, [especificar] o cliente DHCP tentará religar, transmitindo sua DHCPREQUEST vez de unicasting-lo. Porque ele é transmitido, a mensagem vai chegar DHCPREQUEST todos os servidores DHCP disponíveis. Se algum outro servidor DHCP é capaz de renovar a concessão, ele vai fazê-lo neste momento.
A fim de religação para o trabalho, quando o cliente contatar com êxito um servidor DHCP de backup, o servidor deve ter informações precisas sobre a ligação do cliente. Manter informações vinculativas precisa entre dois servidores é um problema complicado, se os dois servidores são capazes de atualizar o banco de dados mesma locação, deve haver um mecanismo para evitar conflitos entre as atualizações nos servidores independentes. Um padrão para implementação de servidores tolerantes a falhas DHCP foi desenvolvido na Internet Engineering Task Force.
Se religação falhar, o arrendamento acabará por expirar. Quando a concessão expira, o cliente deve parar de usar o endereço IP concedido a ele em seu contrato. Na época, ele irá reiniciar o processo de DHCP desde o início, transmitindo uma mensagem DHCPDISCOVER. Desde o seu contrato de arrendamento expirou, ele vai aceitar qualquer endereço IP que lhe é oferecido. Uma vez que tem um novo endereço IP, provavelmente a partir de um servidor DHCP diferente, vai mais uma vez ser capaz de usar a rede. No entanto, como seu endereço IP mudou, as conexões em curso será quebrado.
Segurança[editar | editar código-fonte]
A base de protocolo DHCP não inclui nenhum mecanismo de autenticação. Por isso, é vulnerável a uma variedade de ataques. Estes ataques se dividem em três categorias principais:
- Fornecimento de informações falsas a clientes por servidores DHCP não autorizados.
- Acesso aos recursos da rede por clientes não autorizados.
- Ataques exaustivos aos recursos da rede advindos de clientes DHCP mal-intencionados.
Porque o cliente não tem como validar a identidade de um servidor DHCP, servidores DHCP não autorizados podem ser operados em redes, prestação de informações incorretas aos clientes DHCP. Isso pode servir tanto como um ataque de negação de serviço, impedindo o cliente de ter acesso à conectividade de rede. Porque o servidor DHCP fornece o cliente DHCP com endereços IP do servidor, como o endereço IP de um ou mais servidores DNS, um atacante pode convencer um cliente DHCP para fazer pesquisas através de seu DNS seu próprio servidor DNS, e pode, portanto, fornecer suas próprias respostas a consultas DNS do cliente. Por sua vez, permite que o atacante para redirecionar o tráfego de rede através de si, permitindo-lhe escutar as conexões entre os servidores de rede do cliente e ele entra em contato, ou simplesmente para substituir os servidores de rede com o seu próprio. Porque o servidor DHCP não tem nenhum mecanismo seguro para autenticar o cliente, os clientes podem obter acesso não autorizado aos endereços IP de apresentação de credenciais, tais como identificadores do cliente, que pertencem a outros clientes DHCP. Isso também permite que os clientes DHCP para esgotar o DHCP armazenamento de servidor de endereços IP, apresentando novas credenciais cada vez que ele pede um endereço, o cliente pode consumir todos os endereços IP disponíveis em um link de rede particular, impedindo outros clientes DHCP da obtenção de serviços. DHCP fornece alguns mecanismos para mitigar esses problemas.
O Relé de Agente de Informações extensão protocolo Option (RFC 3046) permite que os operadores de rede para conectar marcas a mensagens DHCP uma vez que estas mensagens chegam na rede de confiança do operador de rede. Esta tag é então usado como um token de autorização para controlar o acesso do cliente aos recursos da rede. Porque o cliente não tem acesso à rede a montante do agente de retransmissão, a falta de autenticação não impede que o operador do servidor DHCP de confiar no token de autorização.
Outro ramal, autenticação para DHCP mensagens (RFC 3118), fornece um mecanismo para autenticação de mensagens DHCP. Infelizmente RFC 3118 não viu a adoção generalizada por causa dos problemas de gerenciamento de chaves para um grande número de clientes DHCP.
Rede sem DHCP - APIPA[editar | editar código-fonte]
APIPA é a abreviatura de Automatic Private IP Addressing. Esta é uma nova funcionalidade que foi introduzida no Microsoft Windows 98, está presente no Windows 2000, Windows XP, Windows Vista, Windows 7, Longhorn Server e no Windows Server 2003. Imagine um cliente com o protocolo TCP/IP instalado e configurado para obter as configurações do protocolo TCP/IP a partir de um servidor DHCP. O cliente é inicializado, porém não consegue se comunicar com um servidor DHCP. Nesta situação, o Windows, usa o recurso APIPA, e automaticamente atribui um endereço IP da rede 169.254.0.0/255.255.0.0. Este é um dos endereços especiais, reservados para uso em redes internas, ou seja, este não seria um endereço de rede, válido na Internet. A seguir descrevo mais detalhes sobre a funcionalidade APIPA.
ATENÇÃO: O número de rede usado pelo recurso APIPA é o seguinte: 169.254.0.0/255.255.0.0
Nota: O recurso APIPA é especialmente útil para o caso de uma pequena rede, com 4 ou 5 computadores, onde não existe um servidor disponível. Neste caso pode-se configurar todos os computadores para usarem o DHCP. Ao inicializar, os clientes não conseguirão localizar um servidor DHCP (já que não existe nenhum servidor DHCP nesta rede do nosso exemplo). Neste caso o recurso APIPA atribuirá endereços da rede 169.254.0.0/255.255.0.0 para todos os computadores da rede. O resultado final é que todos ficam configurados com endereços IP da mesma rede e poderão se comunicar, compartilhando recursos entre si. É uma boa solução para uma rede doméstica ou de pequeno escritório.
Ver também[editar | editar código-fonte]
Referências
- ↑ a b Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 3: RFC 1497 vendor extensions. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 3.1: Pad Option. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 3.3: Subnet Mask. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 3.4: Time Offset. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 4: IP Layer Parameters per Host. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 5: IP Layer Parameters per Interface. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 6: Link Layer Parameters per Interface. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 7: TCP Parameters. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 8: Application and Service Parameters. Consultado em 26 de julho de 2012
- ↑ Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor Extensions». IETF. Section 9: DHCP Extensions. Consultado em 26 de julho de 2012