DHCP

DHCP é o acrónimo de Dynamic Host Configuration Protocol ou, em Português, Protocolo Dinâmico de Configuração de Hospedeiros, ou ainda e em linguagem de gente é a forma de quem se liga à rede obter um endereço. Quando nos ligamos à rede não somos ninguém e então vem de lá um Sr. chamado DHCP que nos diz: Olha, eu acho que tens cara de bom rapaz e como queres falar com os outros passas a morar no 123.231.123.231 (estes numerozinhos como já vimos resumem País, Cidade, Rua, Prédio e Apartamento se fosse entre nós).

Vamos lá a ver como é que isto se processa.

Há uma entidade responsável a nível mundial pelo registo e atribuição de nomes e endereços, que é a ICANN ( Internet Corporation for Assigned Names and Numbers), que por sua vez delega na IANA (Internet Assigned Numbers Authority) a responsabilidade pela atribuição de endereços.

A IANA aloca blocos de endereços a 5 RIR (Regional Internet Registry):

• AfriNIC – África
• ARIN – USA e Canadá
• APNIC – Ásia Central e Sudeste, Austrália, Nova Zelândia, Indonésia, Filipinas e países vizinhos.
• LACNIC – Américas Central e do Sul e Caraíbas
• RIPE – Europa, Médio Oriente e Ásia Central e Norte.

Cada uma destas entidades regionais aloca por sua vez blocos de endereços a grandes clientes diretos e a ISP de maior nível hierárquico, que por sua vez os vão dividindo por níveis hierárquicos mais baixos até aos ISP de acesso, que provêm acesso à Internet a utilizadores finais.

Acontece por vezes que um mesmo ISP pode preencher várias camadas. Mas falaremos melhor deste caso quando abordarmos o roteamento. Vimos já com um exemplo elementar como é que podem ser atribuídos e divididos os vários blocos de endereço.

Então e o utilizador final, como é que obtém o endereço?

Normalmente o utilizador final obteria o endereço por alocação direta do administrador do ISP de acesso e ficaria com ele para sempre. Mas não pode ser assim. Os  endereços IPv4 estão a breves passos do esgotamento,  sendo portanto racionalizados os endereços atribuídos.

Atribuindo endereços só aos utilizadores que estiverem em cada momento ligados à rede, p.e. um provedor de um parque habitacional com 10.000 utilizadores conseguirá provavelmente resolver a situação com um bloco de 2.048 endereços. De cada vez que um equipamento terminal se liga a um ISP executa o DHCP, que é um protocolo da camada aplicacional que lhe permite obter um endereço IP.

Temos então um cliente DHCP, o tal equipamento que se liga a um ISP e, para lhe dar o que ele quer, teremos também um servidor DHCP. O servidor DHCP está no porto bem conhecido 67 e o cliente DHCP no porto bem conhecido 68.

Comecemos por ver na Figura 1 a mensagem tipo DHCP, bem mais complexa que as anteriores. Os diversos campos são definidos como segue:

• op – Código ou tipo de mensagem – 1 = BOOTREQUEST, 2 = BOOTREPLY;
• htype – Tipo de endereço de hardware – por exemplo: 1 = ethernet;
• hlen – Comprimento do endereço de hardware em bytes por exemplo:  6 para ethernet;
• hops –    Colocado a zero pelo cliente. Usado opcionalmente quando uma rede usa um servidor DHCP de outra rede, tendo que existir um relé de ligação DHCP que reendereça o broadcast;
• xid  – ID da Transação, escolhido aleatoriamente pelo cliente e usado por cliente e servidor para associarem as mensagens trocadas entre ambos;
• secs –  Preenchido pelo cliente e usado para determinar o tempo decorrido em segundos desde que o cliente iniciou o processo de aquisição ou renovação de endereço;
• flags – O bit de maior ordem é o que define o Broadcast (B bit). Os restantes 15 bits devem estar definidos a zero e destinam-se a futuras utilizações;
• ciaddr – Client IP address. Só é preenchido se o cliente está num estado de BOUND, RENEW ou REBINDING e pode responder a requisições ARP;
• yiaddr – ‘your’ (cliente) IP address;
• siaddr – Endereço do próximo servidor a usar em bootstrap; é enviado nas mensagens de DHCPOFFER e DHCPACK pelo servidor;
• giaddr – Endereço do agente de relé (referido em hops), caso exista um;
• chaddr – Endereço de hardware do cliente;
• sname – Opcional, é o nome do servidor hospedeiro, que deve terminar em null e preencher a totalidade de 64 Bytes. Herdado do BOOTP ou Bootstrap Protocol, deve ser preenchido a zeros se não usado;
• file – Nome do ficheiro de Boot. Deve ser genérico ou nulo em DHCPDISCOVER e deve ter a path completa em DHCPOFFER. Deve terminar em null de forma a preencher 128 Bytes. Herdado do BOOTP ou Bootstrap Protocol, deve ser preenchido a zeros se não usado;
• options – Conjunto variável de opções a serem utilizadas entre as disponíveis para DHCP.

Os campos que envolvam indicações de BOOT, ou BOOTP ou Bootstrap Protocol, são destinados a máquinas sem disco rígido, portanto sem memória permanente, para que possam descobrir um endereço IP, o endereço de um servidor hospedeiro na sua rede e o nome do ficheiro a ser carregado para a sua memória e a ser executado. Ficamos só por esta informação no que diz respeito a este tipo de campos.

ARP, também referido nos campos descritos, é um protocolo de pergunte e resposta da camada enlace (abaixo desta) destinado a traduzir endereços IP em endereços de hardware (MAC Address), de que falaremos quando chegarmos a esse camada.

É nas Opções que vai a descrição do que é pretendido em cada mensagem, por isso vamos descrever alguns códigos de extensão DHCP, conforme Figura 2:

Código 50 – Este código é usado pelo cliente na mensagem DHCPDISCOVER para pedir que um determinado código IP lhe seja atribuído. Comprimento 4 bytes.

Código 51 – Este código é usado pelo cliente para pedir que o endereço lhe seja atribuído por um determinado período de tempo e pelo servidor para comunicar qual é esse período de tempo. O tempo é especificado em segundos e num conjunto de 4 bytes, o comprimento desta opção.

Código 52 – Este código é usado para o servidor indicar ao cliente que está a usar o espaço do nome do servidor e/ou o espaço do path do ficheiro de Boot por o espaço destinado às opções não ser suficiente para as mesmas. (Overload). Tem 3 tipos possíveis:

1. O campo “file” está a ser utilizado para opções.
2. O campo “sname” a ser usado para opções.
3. Ambos os campos anteriores estão a ser usados para opções.

Código 53 – Este código é usado para identificar o tipo de mensagem em curso. Estes são os tipos que definem a mensagem:

1. DHCPDISCOVER – É um broadcast do cliente para localizar servidores disponíveis.
2. DHCPOFFER – O servidor responde ao cliente com a oferta de parâmetros de configuração.
3. DHCPREQUEST – Do cliente para os servidores:
   • Requisitando os parâmetros oferecidos por um dos servidores e rejeitando os dos outros, ou
   • Confirmando a correção do endereço previamente alocado, por exemplo após um reboot do sistema, ou
   • Estendendo o tempo de duração da atribuição de um determinado endereço.
4. DHCPDECLINE – Do cliente para o servidor indicando que o endereço já está em uso.
5. DHCPACK – Do servidor para o cliente a confirmar os parâmetros oferecidos e atribuídos.
6. DHCPNAK – Do servidor para o cliente a dar conhecimento de erro por escolha incorreta de rede ou porque o tempo de duração do endereço expirou.
7. DHCPRELEASE – Do cliente para o servidor a libertar o endereço antes da expiração do tempo de duração do mesmo.

Código 54 – É através deste código que o servidor indica o seu endereço ao cliente, em DHCPOFFER para ele o poder distinguir dos outros e é através desta opção que o cliente indica a oferta escolhida, em DHCPREQUEST. Também pode ser usada em DHCPACK e DHCPNAK. O comprimento desta opção é de 4 Bytes.

Código 55 – Este código é usado pelo cliente para pedir parâmetros específicos de configuração. A lista de parâmetros requisitados é especificada pelos códigos das respetivas opções, das quais indicamos a título de exemplo 4. O campo de comprimento refere-se ao número de parâmetros requisitados, 1 por byte. Os parâmetros são requisitados pelo seu código, que é o da lista que estamos a descrever.

Estamos assim em condições de simular a chegada de um cliente a uma rede e a sua solicitação de um endereço ao servidor DHCP. É o que vamos fazer de seguida para o nosso caso de estudo.

Caso de estudo – Pedido de endereço

Vamos ver o caso do endereço que nos tem acompanhado durante este Capítulo. Para já sabemos que ele se encontra na rede NBC 2.3. Nós sabemos mas ele não sabe. Quando um cliente se liga, ele não sabe o endereço da própria rede em que está inserido, muito menos o do servidor DHCP.

Então como resolver o problema?

A obtenção do endereço é executada em 4 passos, a que se dá o nome DORA (Discovery, Offer, Request, Acknowledgement – Descoberta, Oferta, Pedido, Reconhecimento), correspondentes a :

• IP Discovery (descoberta),
• IP Lease Offer (oferta por tempo determinado),
• IP Request (aceitação de uma oferta e pedido de confirmação) e
• IP Lease Acknowledgement (confirmação de empréstimo por tempo determinado).

O termo Lease significa o período de tempo por que o endereço é concedido.

A Figura 3 mostra um datagrama IP contendo um segmento UDP, que por sua vez contém uma mensagem DNS, constituindo o conjunto que é enviado pela camada  rede em conversações DHCP.

Passo 1 – IP Discovery

O cliente, quando se liga à rede, grita bem alto para os servidores de DNS da sua rede:

“Olá pessoal, alguém tem por aí um endereçozito de sobra para mim?”

Para isso, preenche a mensagem DHCP, coloca-a num segmento UDP e coloca o segmento num datagrama IP, preenchendo os campos que se indicam na Figura 4.

O campo de endereço de hardware está preenchido com  o único endereço que o cliente conhece para já, no segmento UDP os portos de origem e destino são os well known ports e no datagrama o endereço de origem é 0.0.0.0, pois não existe ainda e o endereço de destino é 255.255.255.255, um endereço de broadcast à rede, portanto a todos os servidores de DHCP na rede NBC 2.3.

Vejamos o campo de opções, onde o cliente faz as perguntas aos servidores, em pormenor:

53 – 1 – 1  <=> Isto é uma mensagem DHCPDISCOVER.
55 – 1 – 1  <=> Qual é a minha máscara de sub-rede?
55 – 1 – 3  <=> Quais são os endereços de primeiros router para mim, por ordem de preferência?
55 – 1 – 6  <=> Quais são os endereços dos servidores de DNS da minha rede?

Quaisquer outros campos que façam parte do envio normal de um pacote, já referenciados, não vão aqui mencionados por não serem relevantes para o que estamos a discutir.

Passo 2 – IP Lease Offer

Recolhida a mensagem por um ou mais servidores DHCP que se encontrem na rede, respondem-lhe os mesmos,  dizendo:

” Olha pá! Tenho por aqui este endereço de sobra que te mando, bem como as informações que pediste. Eu sou o João”.

com uma mensagem DHCP, como a da Figura 5 com os campos significativos preenchidos, que se lê como segue nas opções:

53 – 1 – 2  <=> Isto é uma mensagem DHCPOFFER.
54 – 4 – 188.72.202.50 <=> Endereço do servidor DHCP (p.e.), que faz esta oferta. Chama-se João.
51 – 4 – 41.200 <=> Tempo de atribuição em segundos. Igual a 12 horas. Comprimento 4 bytes.
1 – 4 – 255.255.255.0 <=> Resposta a pergunta 55 – 1 – 1, indicando a máscara da sub-rede.
3 – 20 – 5 endereços  <=> Resposta a pergunta 55 – 1 – 3, enviando 20 bytes com endereços de  5 routers.
6 – 16 – 4 endereços <=> Resposta a 55 – 1 – 6, enviando 16 bytes com endereços de 4 servidores de DNS.

Preenche ainda os campos:

yiaddr com o endereço proposto  188.72.202.158,

siaddr com o endereço do próximo servidor, irrelevante no nosso caso) e

chaddr  que é 34 2B 4E 65 30 2D.

Coloca a mensagem num segmento UDP com os well known ports de destino 68 e de origem 67, num pacote IP com o endereço de destino 255.255.255.255 e com o seu próprio endereço de origem. A mensagem é enviada em broadcast porque o cliente ainda não tem endereço.

Passo 3 – IP Request

O cliente recebe as mensagens de oferta de um ou mais servidores, escolhe uma e ecoa a oferta em broadcast, para que todos os servidores que fizeram ofertas fiquem a saber sobre quem incidiu a escolha:

“Obrigado a todos. Escolhi o endereço que o João me enviou e por isso peço ao João que mo confirme”.

com o campo de opções como segue:

53 – 1 – 3  <=> Isto é uma mensagem DHCPREQUEST.
54 – 4 – 188.72.202.50  <=> É o endereço do servidor DHCP que eu selecionei, o João portanto.
50 – 4 – 188.72.202.158  <=> É o código de requisição de um endereço específico, precisamente aquele que foi oferecido em yiaddr pelo DHCPOFFER.

Os campos siaddr e chaddr vão preenchidos tal como já estavam, mas o campo yiaddr vai em branco conforme com a Figura 6.

A mensagem é colocada num segmento UDP com os well known ports de destino 67 e de origem 68 e num datagrama IP com destino 255.255.255.255 e origem 0.0.0.0. O endereço de origem é nulo, pois o cliente ainda não tem endereço.

Passo 4 – IP Lease Acknowledgement

Recebida esta mensagem pelo servidor DHCP selecionado, o mesmo envia uma mensagem ao cliente confirmando aceitação da sua escolha, dizendo:

“Ok. Registo e confirmo a tua escolha. Volto a enviar-te o endereço atribuído, o tempo pelo qual to concedo e as informações que pediste”.

com os campos de opções significando:

53 – 1 – 5  <=> Isto é uma mensagem DHCPACK
54 – 4 – 188.72.202.50  <=> Confirma o seu endereço de servidor DHCP selecionado.
51 – 4 – 41.200 <=> Confirma o tempo de atribuição em segundos. Igual a 12 horas. Comprimento 4 bytes.
1 – 4 – 255.255.255.0 <=> Confirma resposta a pergunta  indicando a máscara da sub-rede.
3 – 20 – 5 endereços  <=> Confirma resposta com endereços de  5 routers (20/4=5).
6 – 16 – 4 endereços <=> Confirma resposta com endereços de 4 servidores de DNS (16/4=4).

com os campos yiaddr, siaddr e chaddr preenchidos, ainda como Broadcast, conforme a Figura 7.

Recebida pelo cliente esta mensagem, está concluído o processo de configuração do seu endereço IP, restando-lhe configurar a sua interface com os parâmetros acordados.

A interface do cliente e os routers ainda não estão configurados com este novo endereço, daí o envio ainda ser em broadcast. Só a partir desta mensagem é executado em todas as máquinas intervenientes no processo, a configuração para este endereço, nisto incluídos roteadores, servidores DNS, a própria máquina, etc.

Isto é, o mundo é informado da minha nova morada

Que agora está finalmente integrada na rede global.

NAT

NAT é o acrónimo de Network Address Translation ou, em Português, Tradução de Endereços de Rede.

Para além de ser uma forma de conseguir, com um simples endereço público, dar acesso à rede pública até um limite máximo de cerca de 60.000 utilizadores, a NAT permite que uma rede privada, de uma habitação, de um prédio, de um campus ou de uma empresa, p.e. possa estar escondida por detrás de um roteador, isto é, nenhum dos endereços internos dessa rede privada é visível do exterior, nem é possível chegar aos mesmos sem ser através do Roteador NAT.

Vamos lá tentar perceber porquê. Para isso acompanhemos com a Figura 8, onde considerámos uma rede privada usando endereços privados com 5 utilizadores e um roteador NAT. A rede é definida pelo endereço 192.168.1.0 e a interface interna do roteador tem o endereço 192.168.1.1

Embora vamos desenvolver este assunto mais para a frente convém já esclarecer que um roteador dispõe de uma interface por cada E/S que ligue com redes ou outros roteadores. No nosso caso terá uma interface virada para a rede pública com um IP adquirido por DHCP e que vamos admitir ser o 185.82.25.110 e outra interface virada para a rede privada com o endereço 192.168.1.1

A distribuição interna à rede pelos diversos utilizadores é feita por um switch, que pode estar fisicamente combinado com o roteador no mesmo equipamento.

Quando um utilizador interno da rede pretende, por exemplo requisitar a página que vimos usando

http://www.condominiopartners.pt/index.html

preenche os diversos cabeçalhos e inclui o seu porto de origem, p.e. 4375, o porto de destino 80, o seu endereço privado 192.168.1.5 e o endereço do destinatário 188.72.202.158.

O seu pacote não pode evidentemente ir para o exterior com um endereço do espectro privado, utilizável exclusivamente por uma rede privada e por cada uma separadamente entendido. A mensagem que sai do utilizador 4 vai diretamente ao roteador de acesso à rede pública (Gateway).

Quando o roteador NAT recebe a mensagem deste utilizador, faz a sua tradução para entendimento no exterior. Para isso abre o pacote, coloca no endereço de origem o seu endereço público 183.82.25.110 e cria um porto de origem seu, p.e. 6003, destinado a esta conexão, que coloca no local do porto de origem.

Depois de alterado (traduzido) o pacote, o roteador coloca numa tabela NAT que constrói, a relação entre o endereço de destino e o porto de origem desse pacote no seu sistema interno e o endereço de origem e porto de origem do utilizador na rede interna.

Só por esta descrição já se percebe que um roteador NAT tem que ter capacidade de chegar à camada de transporte.

A tabela NAT ilustrada na Figura 8 tem incluídos registos sobre todos os utilizadores que têm pedidos na rede.

Tal tabela vai-lhe posteriormente permitir redirecionar a resposta para o respetivo remetente, pois essa resposta trará como porto de destino aquele que criou para esta transação e o endereço de origem será aquele que registou na sua tabela.

Tendo o campo do porto 16 bits, o número de conexões simultâneas que um roteador NAT pode manter em relação à rede privada, poderá ser superior a 60.000.

Por detrás de um roteador NAT pode estar uma rede privada de grande dimensão, ela própria com roteadores e várias sub-redes. Não esquecer que um roteador tem um endereço por cada interface e que cada interface define uma sub-rede ou um roteamento para outra sub-rede. Veja-se por exemplo o caso de uma empresa que tem a concessão de exploração de uma extensa rede de autoestradas, onde tem sub-redes em todas as portagens, nos edifícios de escritório, em postos de exploração concessionados, um Centro de Dados, um Centro de regulação da rede viária, etc.

Todas estas sub-redes estão a enormes distâncias umas das outras e são reguladas pelo Centro de Dados. Teremos num caso destes várias LAN e WAN, podendo a comunicação ser feita por linhas dedicadas ou outras.

Todo este conjunto de sub-redes privadas da mesma empresa pode ligar ao exterior por um único roteador com NAT do Centro de Dados, com um único endereço público.

Vantagens? Muitas!

Do exterior ninguém consegue ver os endereços dos terminais da empresa, pois estes têm endereços privados. Só o endereço do roteador NAT é exposto publicamente.

A segurança da rede é muito mais eficiente pois todo o tráfego tem de passar pela mesma Firewall. Um só administrador num só local, pode controlar e impor todas as restrições que entender ao tráfego que circula para dentro e para fora da empresa.

Não é possível aceder do exterior a nenhum terminal interno, pois o seu endereço não é utilizável externamente. O acesso aos terminais internos depende do roteador NAT.

Bom, vamos parar por aqui com o endereçamento, para podermos agora falar do roteamento.