Rede Grupo de Trabalho HDCP - 1997

Protocolo de configuração dinâmica de hosts
Status deste memorando
Este documento especifica um protocolo de rastreamento de padrões

da Internet para
Comunidade da Internet e solicita discussão e sugestões para
melhorias. Por favor, consulte a edição atual da "Internet
Padrões Oficiais do Protocolo "(STD 1) para o estado de
padronização
e status deste protocolo. A distribuição deste memorando é
ilimitado.
Abstrato
O protocolo DHCP (Dynamic Host Configuration Protocol) fornece uma

estrutura
para passar informações de configuração para hosts em uma rede
TCPIP.
O DHCP é baseado no Bootstrap Protocol (BOOTP) [7], adicionando o
capacidade de alocação automática de endereços de rede
reutilizáveis e
opções adicionais de configuração [19]. O DHCP captura o
comportamento de
Os agentes de retransmissão BOOTP [7, 21] e os participantes DHCP
podem interoperar
com os participantes do BOOTP [9].
Índice
1. Introdução. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Alterações no RFC1541. . . . . . . . . . . . . . . . . . . . .
. 3
1.2 Trabalho Relacionado. . . . . . . . . . . . . . . . . . . . . .
. . . 4
1.3 Definição e problemas do problema. . . . . . . . . . . . . . .
. 4
1.4 Requisitos. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminologia. . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Metas de design. . . . . . . . . . . . . . . . . . . . . . . .
. 6
2. Resumo do Protocolo. . . . . . . . . . . . . . . . . . . . . . .
8
2.1 Repositório de parâmetros de configuração. . . . . . . . . . .
. . 11
2.2 Alocação dinâmica de endereços de rede. . . . . . . . . . . 12
3. O protocolo cliente-servidor. . . . . . . . . . . . . . . . . .
13
3.1 Interação cliente-servidor - alocando um endereço de rede. . .
13
3.2 Interação cliente-servidor - reutilizando um anteriormente
alocado
Endereço de rede . . . . . . . . . . . . . . . . . . . . . . .
17
3.3 Interpretação e representação de valores temporais. . . . . . .
20
3.4 Obtenção de parâmetros com rede configurada externamente
endereço . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.5 Parâmetros do cliente no DHCP. . . . . . . . . . . . . . . . .
. 21
3.6 Uso de DHCP em clientes com múltiplas interfaces. . . . . . .
22
3.7 Quando os clientes devem usar o DHCP. . . . . . . . . . . . . .
. . . 22
4. Especificação do protocolo cliente-servidor DHCP. . . . . . . 22
Droms Standards Track [Página 1]
Protocolo de configuração de host dinâmico RFC 2131, março de 1997
4.1 Construindo e enviando mensagens DHCP. . . . . . . . . . . . 22

4.2 Controles administrativos do servidor DHCP. . . . . . . . . . .
. . 25
4.3 Comportamento do servidor DHCP. . . . . . . . . . . . . . . . .
. . . . 26
4.4 Comportamento do cliente DHCP. . . . . . . . . . . . . . . . .
. . . . 34
5. Agradecimentos . . . . . . . . . . . . . . . . . . . . . . .42
6. Referências . . . . . . . . . . . . . . . . . . . . . . . . .42
7. Considerações de segurança. . . . . . . . . . . . . . . . . . .
.43
8. Endereço do autor. . . . . . . . . . . . . . . . . . . . . . 44
A. Parâmetros de Configuração do Host. . . . . . . . . . . . . . .
45
Lista de Figuras
1. Formato de uma mensagem DHCP. . . . . . . . . . . . . . . . . .
. 9
2. Formato do campo 'flags'. . . . . . . . . . . . . . . . . . 11
3. Diagrama da linha do tempo das mensagens trocadas entre o
cliente DHCP e
servidores ao alocar um novo endereço de rede. . . . . . . . .
15
4. Diagrama da linha do tempo das mensagens trocadas entre o
cliente DHCP e
servidores ao reutilizar um endereço de rede anteriormente
alocado. . 18
5. Diagrama de transição de estado para clientes DHCP. . . . . . .
. . . . 34
Lista de mesas
1. Descrição dos campos em uma mensagem DHCP. . . . . . . . . . . .
10
2. Mensagens DHCP. . . . . . . . . . . . . . . . . . . . . . . . .
14
3. Campos e opções usados pelos servidores DHCP. . . . . . . . . .
. . 28
4. Mensagens do cliente de vários estados. . . . . . . . . . . . .
. 33
5. Campos e opções usadas pelos clientes DHCP. . . . . . . . . . .
. 37
1. Introdução
O protocolo DHCP (Dynamic Host Configuration Protocol) fornece

configuração
parâmetros para hosts da Internet. O DHCP consiste em dois
componentes:
protocolo para entregar parâmetros de configuração específicos do
host de um
Servidor DHCP para um host e um mecanismo para alocação de rede
endereços para hosts.
O DHCP é construído em um modelo cliente-servidor, onde o servidor

DHCP designado
hosts alocam endereços de rede e fornecem parâmetros de
configuração
para hosts configurados dinamicamente. Ao longo do restante deste
documento, o termo "servidor" refere-se a um host que fornece
inicialização
parâmetros através do DHCP, e o termo "cliente" refere-se a um host
solicitando parâmetros de inicialização de um servidor DHCP.
Um host não deve agir como um servidor DHCP, a menos que seja
explicitamente configurado
para fazê-lo por um administrador do sistema. A diversidade de
hardware e
implementações de protocolos na Internet impossibilitariam
operação se hosts aleatórios pudessem responder a solicitações
DHCP.
Por exemplo, o IP requer a configuração de muitos parâmetros dentro
do
software de implementação de protocolos. Porque o IP pode ser usado
em muitos
tipos diferentes de hardware de rede, valores para esses parâmetros
não pode ser adivinhado ou assumido como tendo os padrões corretos.
Além disso,
os esquemas de atribuição de endereços distribuídos dependem de uma
votação / defesa
mecanismo para a descoberta de endereços que já estão em uso. IP

hosts nem sempre podem defender seus endereços de rede, portanto,
que tal esquema de alocação distribuída de endereços não pode ser
garantido evitar a atribuição de endereços de rede duplicados.
O DHCP suporta três mecanismos para alocação de endereços IP. Em

"alocação automática", o DHCP atribui um endereço IP permanente a
um
cliente. Em "alocação dinâmica", o DHCP atribui um endereço IP a um
cliente por um período limitado de tempo (ou até que o cliente
explicitamente
abandona o endereço). Na "alocação manual", o IP de um cliente
o endereço é atribuído pelo administrador da rede e o DHCP é usado
simplesmente para transmitir o endereço atribuído ao cliente. Um
particular
A rede utilizará um ou mais desses mecanismos, dependendo da
políticas do administrador da rede.
A alocação dinâmica é o único dos três mecanismos que

permite a reutilização automática de um endereço que não é mais
necessário pelo
cliente para o qual foi atribuído. Assim, a alocação dinâmica é
particularmente útil para atribuir um endereço a um cliente que
será
conectado à rede apenas temporariamente ou por compartilhar
pool de endereços IP entre um grupo de clientes que não precisam
endereços IP permanentes. A alocação dinâmica também pode ser uma
boa escolha
para atribuir um endereço IP a um novo cliente permanentemente
conectado a uma rede onde os endereços IP são suficientemente
escassos
É importante recuperá-los quando clientes antigos são aposentados.
A alocação manual permite que o DHCP seja usado para eliminar a
propensão a erros
processo de configuração manual de hosts com endereços IP em
ambientes onde (por qualquer motivo) é desejável gerenciar
Atribuição de endereços IP fora dos mecanismos DHCP.
O formato das mensagens DHCP é baseado no formato das mensagens

BOOTP,
capturar o comportamento do agente de retransmissão BOOTP descrito
como parte do
Especificação BOOTP [7, 21] e permitir a interoperabilidade dos
Clientes BOOTP com servidores DHCP. A utilização de agentes de
transmissão BOOTP elimina
a necessidade de ter um servidor DHCP em cada rede física
segmento.
1.1 Mudanças na RFC 1541
Este documento atualiza a especificação do protocolo DHCP que

aparece em
RFC1541 Um novo tipo de mensagem DHCP, DHCPINFORM, foi adicionado;
Vejo
seção 3.4, 4.3 e 4.4 para detalhes. O mecanismo de classificação
para
a identificação de clientes DHCP em servidores DHCP foi estendida
para incluir
classes "vendor", conforme definido nas seções 4.2 e 4.3. O mínimo
restrição de tempo de locação foi removida. Finalmente, muitos
editorial
mudanças foram feitas para esclarecer o texto como resultado da
experiência
ganhou em testes de interoperabilidade DHCP.
1.2 Trabalho Relacionado
Existem vários protocolos da Internet e mecanismos relacionados que

abordar algumas partes do problema de configuração dinâmica do
host. o
Protocolo de Resolução de Endereços Inversos (RARP) [10] (através
do
extensões definidas no RARP Dinâmico (DRARP) [5]) explicitamente
aborda o problema da descoberta de endereços de rede e inclui um
mecanismo de atribuição de endereço IP automático. A transferência
de arquivos triviais
Protocolo (TFTP) [20] fornece o transporte de uma imagem de
inicialização de um
servidor de inicialização. O Protocolo de Mensagens de Controle da
Internet (ICMP) [16]
fornece para informar hosts de roteadores adicionais via "ICMP
redirecionar "mensagens. ICMP também pode fornecer informações de
máscara de sub-rede
através da mensagem "ICMP mask request" e outras informações
através
a mensagem ("obsoleta") de solicitação de informações ICMP. Hosts
podem localizar
roteadores através do mecanismo de descoberta de roteadores ICMP
[8].
O BOOTP é um mecanismo de transporte para uma coleção de

configurações
em formação. O BOOTP também é extensível e extensões oficiais [17]
foram definidos para vários parâmetros de configuração. Morgan tem
extensões propostas para o BOOTP para atribuição dinâmica de
endereços IP [15].
O Network Information Protocol (NIP), utilizado pelo projeto Athena
em
MIT, é um mecanismo distribuído para atribuição dinâmica de
endereços IP
[19] O Protocolo de Localização de Recursos RLP [1] fornece a
localização
serviços de nível superior. As estações de trabalho sem disco da
Sun Microsystems usam
um procedimento de inicialização que emprega RARP, TFTP e um
mecanismo RPC chamado
"bootparams" para fornecer informações de configuração e operação
código do sistema para hosts sem disco. (Sun Microsystems, estação
de trabalho Sun
e SunOS são marcas registradas da Sun Microsystems, Inc.)
redes também usam DRARP e um mecanismo de auto-instalação para
automatizar a configuração de novos hosts em uma rede existente.
Em outro trabalho relacionado, a unidade de transmissão mínima

(MTU) do caminho
algoritmo de descoberta pode determinar o MTU de uma Internet
arbitrária
caminho [14]. O Protocolo de Resolução de Endereços (ARP) foi
proposto
como protocolo de transporte para localização e seleção de recursos
[6].
Finalmente, as RFCs de Requisitos do Host [3, 4] mencionam
requisitos para a reconfiguração do host e sugerir um cenário para
configuração inicial de hosts sem disco.
1.3 Definição e problemas do problema
DHCP é projetado para fornecer clientes DHCP com a configuração

parâmetros definidos nas RFCs de Requisitos do Host. Depois de
obter
parâmetros via DHCP, um cliente DHCP deve poder trocar pacotes
com qualquer outro host na Internet. Os parâmetros da pilha TCP /
IP
fornecidos pelo DHCP estão listados no Apêndice A.
Nem todos esses parâmetros são necessários para uma inicialização

recém-inicializada.
cliente. Um cliente e um servidor podem negociar a transmissão de
apenas os parâmetros exigidos pelo cliente ou específicos de um
sub-rede particular.
DHCP permite, mas não requer a configuração do cliente

parâmetros não diretamente relacionados ao protocolo IP. O DHCP
também faz
não aborda o registro de clientes recém-configurados com o domínio
Sistema de nomes (DNS) [12, 13].
O DHCP não se destina a uso na configuração de roteadores.
1.4 Requisitos
Ao longo deste documento, as palavras usadas para definir o

a importância de requisitos particulares é capitalizada. Essas
palavras
está:
o "DEVE"
Esta palavra ou o adjetivo "REQUERIDO" significa que o

item é um requisito absoluto desta especificação.
o "NÃO DEVE"
Esta frase significa que o item é uma proibição absoluta

desta especificação.
o "deveria"
Esta palavra ou o adjetivo "RECOMENDADO" significa que há

pode existir razões válidas em circunstâncias específicas para
ignorar
este item, mas todas as implicações devem ser entendidas e
o caso cuidadosamente pesado antes de escolher um curso
diferente.
o "NÃO DEVE"
Esta frase significa que podem existir razões válidas em

circunstâncias particulares quando o comportamento listado é
aceitável
ou até mesmo útil, mas todas as implicações devem ser
entendidas
e o caso cuidadosamente ponderado antes de implementar
qualquer comportamento
descrito com este rótulo.
o "MAIO"
Esta palavra ou o adjetivo "OPCIONAL" significa que este item

é
verdadeiramente opcional. Um fornecedor pode optar por incluir
o item
porque um determinado mercado exige ou porque
melhora o produto, por exemplo; outro fornecedor pode omitir o
mesmo item.
1.5 Terminologia
Este documento usa os seguintes termos:
o "cliente DHCP"
Um cliente DHCP é um host da Internet que usa DHCP para obter

parâmetros de configuração, como um endereço de rede.
o "servidor DHCP"
Um servidor DHCP é um host da Internet que retorna a

configuração
parâmetros para clientes DHCP.
o "agente de retransmissão BOOTP"
Um agente de retransmissão BOOTP ou agente de retransmissão é um

host ou roteador da Internet
que passa mensagens DHCP entre clientes DHCP e servidores DHCP.
O DHCP foi projetado para usar o mesmo comportamento do agente
de retransmissão especificado
na especificação do protocolo BOOTP.
o "ligação"
Uma ligação é uma coleção de parâmetros de configuração,

incluindo
pelo menos um endereço IP, associado ou "ligado a" um DHCP
cliente. As ligações são gerenciadas por servidores DHCP.
1.6 Objetivos do design
A lista a seguir fornece metas gerais de design para o DHCP.
O DHCP deve ser um mecanismo e não uma política. DHCP deve

permitir que administradores de sistemas locais controlem a
configuração
parâmetros onde desejado; por exemplo, administradores do
sistema local
deve ser capaz de aplicar políticas locais em relação à
alocação
e acesso a recursos locais, quando desejado.
o Os clientes não devem exigir configuração manual. Cada cliente

deve ser capaz de descobrir a configuração local apropriada
parâmetros sem intervenção do usuário e incorporar aqueles
parâmetros em sua própria configuração.
o Redes não devem requerer configuração manual para

clientes. Em circunstâncias normais, o gerente de rede
não deve ter que inserir nenhuma configuração por cliente
parâmetros.
o DHCP não deve exigir um servidor em cada sub-rede. Para

permitir
escala e economia, o DHCP deve funcionar através de roteadores
ou
intervenção de agentes de retransmissão BOOTP.
o Um cliente DHCP deve estar preparado para receber várias

respostas
a uma solicitação de parâmetros de configuração. Algumas
instalações
pode incluir vários servidores DHCP sobrepostos para aprimorar
confiabilidade e aumentar o desempenho.
o DHCP deve coexistir com dados estaticamente configurados, não

participantes
hosts e com implementações de protocolo de rede existentes.
o DHCP deve interoperar com o comportamento do agente de

retransmissão BOOTP
descrito pela RFC 951 e pela RFC 1542 [21].
o DHCP deve fornecer serviço para clientes BOOTP existentes.
A lista a seguir apresenta metas de design específicas para a

transmissão de
os parâmetros da camada de rede. O DHCP deve:
o Garantir que qualquer endereço de rede específico não esteja

em
usar por mais de um cliente DHCP de cada vez,
o Reter a configuração do cliente DHCP na reinicialização do

cliente DHCP. UMA
Cliente DHCP deve, sempre que possível, ser atribuído da mesma
parâmetros de configuração (por exemplo, endereço de rede) em
resposta
a cada pedido,
o Reter a configuração do cliente DHCP nas reinicializações do

servidor e,
sempre que possível, um cliente DHCP deve receber a mesma
parâmetros de configuração, apesar das reinicializações do
mecanismo DHCP,
o Permitir atribuição automática de parâmetros de configuração

para novos
clientes para evitar a configuração manual de novos clientes,
o Suporte a alocação fixa ou permanente de configuração

parâmetros para clientes específicos.
2. Resumo do Protocolo
Do ponto de vista do cliente, o DHCP é uma extensão do BOOTP

mecanismo. Esse comportamento permite que clientes BOOTP existentes
interoperar com servidores DHCP sem exigir qualquer alteração no
software de inicialização dos clientes. RFC 1542 [2] detalha a
interações entre clientes e servidores BOOTP e DHCP [9]. Lá
são algumas transações novas e opcionais que otimizam a interação
entre clientes e servidores DHCP descritos nas seções 3 e
4
A Figura 1 apresenta o formato de uma mensagem DHCP e a tabela 1

descreve
cada um dos campos na mensagem DHCP. Os números entre parênteses
indica o tamanho de cada campo em octetos. Os nomes dos campos
dado na figura será usado ao longo deste documento para se referir
a
os campos nas mensagens DHCP.
Existem duas diferenças principais entre o DHCP e o BOOTP.

Primeiro,
O DHCP define mecanismos pelos quais os clientes podem receber um
endereço de rede para um contrato de arrendamento finito,
permitindo a reatribuição em série
de endereços de rede para diferentes clientes. Em segundo lugar, o
DHCP fornece o
mecanismo para um cliente adquirir toda a configuração IP
parâmetros de que necessita para operar.
O DHCP introduz uma pequena mudança na terminologia destinada a

esclarecer
significado de um dos campos. Qual foi o campo "extensões de
fornecedor"
no BOOTP foi renomeado o campo "opções" no DHCP. Similarmente,
os itens de dados marcados que foram usados dentro do "fornecedor"
do BOOTP
extensões ", que foram anteriormente referidas como" fornecedor
extensões, "agora são denominadas simplesmente" opções ".
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| op (1) | htipo (1) | hlen (1) | lúpulo (1) |
+ --------------- + --------------- + --------------- + - ---------
----- +
| xid (4) |
+ ------------------------------- + ----------------- -------------
- +
| segundos (2) | bandeiras (2) |
+ ------------------------------- + ----------------- -------------
- +
| ciaddr (4) |
+ ------------------------------------------------- --------------
+
| yiaddr (4) |
+ ------------------------------------------------- --------------
+
| siaddr (4) |
+ ------------------------------------------------- --------------
+
| giaddr (4) |
+ ------------------------------------------------- --------------
+
| |
| chaddr (16) |
| |
| |
+ ------------------------------------------------- --------------
+
| |
| sname (64) |
+ ------------------------------------------------- --------------
+
| |
| arquivo (128) |
+ ------------------------------------------------- --------------
+
| |
| opções (variável) |
+ ------------------------------------------------- --------------
+
Figura 1: Formato de uma mensagem DHCP
O DHCP define uma nova opção de 'identificador de cliente' que é

usada para passar
identificador de cliente explícito para um servidor DHCP. Essa
mudança elimina
a sobrecarga do campo 'chaddr' nas mensagens BOOTP, onde
'chaddr' é usado tanto como um endereço de hardware para
transmissão de BOOTP
responder mensagens e como um identificador de cliente. O
'identificador do cliente'
é uma chave opaca, que não deve ser interpretada pelo servidor; por
exemplo,
o 'identificador do cliente' pode conter um endereço de hardware,
idêntico ao
o conteúdo do campo 'chaddr', ou pode conter outro tipo de
identificador, como um nome DNS. O 'identificador do cliente'
escolhido por um
Cliente DHCP deve ser exclusivo para esse cliente dentro da sub-
rede para o qual
o cliente está conectado. Se o cliente usar um 'identificador de
cliente' no
uma mensagem, DEVE usar esse mesmo identificador em todas as
mensagens, para garantir que todos os servidores identifiquem
corretamente o cliente.
O DHCP esclarece a interpretação do campo 'siaddr' como o

endereço do servidor para usar na próxima etapa do cliente
processo de bootstrap. Um servidor DHCP pode retornar seu próprio
endereço no
'siaddr', se o servidor estiver preparado para fornecer o próximo
serviço de bootstrap (por exemplo, entrega de um executável do
sistema operacional
imagem). Um servidor DHCP sempre retorna seu próprio endereço no
servidor
opção de identificador.
DESCRIÇÃO DOS OCTETOS DE CAMPO

----- ------ -----------
op 1 Mensagem do código de operação / tipo de mensagem.

1 = BOOTREQUEST, 2 = BOOTREPLY
htipo 1 Tipo de endereço de hardware, consulte a seção ARP em
"Atribuído
Números "RFC; por exemplo, '1' = ethernet 10mb.
hlen 1 Comprimento do endereço de hardware (por exemplo, '6' para
10mb
ethernet).
hops 1 Client define como zero, opcionalmente usado por agentes de
retransmissão
ao inicializar através de um agente de
retransmissão.
xid 4 Transaction ID, um número aleatório escolhido pelo
cliente, usado pelo cliente e servidor para
associar
mensagens e respostas entre um cliente e um
servidor.
Segs 2 Preenchido pelo cliente, segundos decorridos desde o cliente
começou a aquisição de endereços ou processo de
renovação.
flags 2 Flags (veja a figura 2).
ciaddr 4 Endereço IP do cliente; preenchido apenas se o cliente
estiver em
BOUND, RENOVAR ou REABINDING estado e pode
responder
para solicitações ARP.
yiaddr 4 'seu' (cliente) endereço IP.
siaddr 4 endereço IP do próximo servidor a ser usado no bootstrap;
retornado em DHCPOFFER, DHCPACK pelo servidor.
giaddr 4 Endereço IP do agente de retransmissão, usado na
inicialização por meio de um
agente de retransmissão.
chaddr 16 Endereço de hardware do cliente.
sname 64 Nome do host do servidor opcional, cadeia terminada com
nulo.
arquivo 128 Nome do arquivo de inicialização, seqüência terminada
nula; "genérico"
nome ou nulo em DHCPDISCOVER, totalmente
qualificado
nome do caminho do diretório no DHCPOFFER.
opções var Campo de parâmetros opcionais. Veja as opções
documentos para uma lista de opções definidas.
Tabela 1: Descrição dos campos em uma mensagem DHCP
O campo 'opções' agora tem tamanho variável. Um cliente DHCP deve

ser
preparado para receber mensagens DHCP com um campo de 'opções'
comprimento 312 octetos. Este requisito implica que um cliente DHCP
deve
estar preparado para receber uma mensagem de até 576 octetos, o IP
mínimo
tamanho do datagrama um host IP deve estar preparado para aceitar

[3]. DHCP
clientes podem negociar o uso de mensagens DHCP maiores através do
opção 'tamanho máximo da mensagem DHCP'. O campo de opções pode ser
mais
estendido para os campos 'file' e 'sname'.
No caso de um cliente usando DHCP para configuração inicial (antes

o software TCP / IP do cliente foi completamente configurado), DHCP
requer uso criativo do software TCP / IP do cliente e do liberal
interpretação do RFC 1122. O software TCP / IP DEVE aceitar e
encaminhar para a camada IP quaisquer pacotes IP entregues ao
cliente
endereço de hardware antes de o endereço IP ser configurado;
Servidores DHCP
e agentes de retransmissão BOOTP podem não ser capazes de entregar
mensagens DHCP para
clientes que não podem aceitar datagramas unicast de hardware antes
do
O software TCP / IP está configurado.
Para contornar alguns clientes que não podem aceitar datagramas IP

unicast
antes que o software TCP / IP seja configurado conforme discutido
no
parágrafo, o DHCP usa o campo 'flags' [21]. O bit mais à esquerda é
definido como o sinalizador BROADCAST (B). A semântica deste flag é
discutido na seção 4.1 deste documento. Os bits restantes do
O campo flags está reservado para uso futuro. Eles devem ser
definidos para zero por
clientes e ignorados por servidores e agentes de retransmissão. A
figura 2 dá a
formato do campo 'flags'.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - +
| B | MBZ |
+ - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - +
B: Bandeira da BROADCAST
MBZ: DEVE SER ZERO (reservado para uso futuro)
Figura 2: Formato do campo 'flags'
2.1 Repositório de parâmetros de configuração
O primeiro serviço fornecido pelo DHCP é fornecer armazenamento

persistente
de parâmetros de rede para clientes de rede. O modelo do DHCP
armazenamento persistente é que o serviço DHCP armazena uma entrada
de valor-chave
para cada cliente, onde a chave é um identificador único (por
exemplo, um número de sub-rede IP e um identificador único dentro
do
sub-rede) eo valor contém os parâmetros de configuração para o
cliente.
Por exemplo, a chave pode ser o par (IP-subnet-number, hardware-

endereço) (note que o "endereço de hardware" deve ser digitado pelo
tipo de hardware para acomodar possíveis duplicações de hardware

endereços resultantes de problemas de ordem de bits em uma mídia
mista,
rede em ponte) permitindo a reutilização em série ou simultânea de
endereço de hardware em diferentes sub-redes e para endereços de
hardware
isso pode não ser globalmente único. Alternativamente, a chave pode
ser o
par (IP-subnet-number, hostname), permitindo que o servidor atribua
parâmetros de forma inteligente para um cliente DHCP que foi movido
para um
sub-rede diferente ou mudou endereços de hardware (talvez porque
a interface de rede falhou e foi substituída). O protocolo define
que a chave será (número de sub-rede IP, endereço de hardware) a
menos que
cliente fornece explicitamente um identificador usando o 'cliente
opção de identificador. Um cliente pode consultar o serviço DHCP
para
recuperar seus parâmetros de configuração. A interface do cliente
para o
repositório de parâmetros de configuração consiste em mensagens de
protocolo para
solicitar parâmetros de configuração e respostas do servidor
carregando os parâmetros de configuração.
2.2 Alocação dinâmica de endereços de rede
O segundo serviço fornecido pelo DHCP é a alocação temporária ou

endereços de rede permanente (IP) para os clientes. O mecanismo
básico para
a alocação dinâmica de endereços de rede é simples: um cliente
solicita o uso de um endereço por algum período de tempo. o
mecanismo de alocação (a coleção de servidores DHCP) garante não
para realocar esse endereço dentro do tempo solicitado e tenta
retornar o mesmo endereço de rede sempre que o cliente solicitar
endereço. Neste documento, o período durante o qual um endereço de
rede
é alocado para um cliente é referido como uma "concessão" [11]. o
o cliente pode estender seu contrato com solicitações subsequentes.
O cliente pode
emitir uma mensagem para liberar o endereço de volta para o
servidor quando o
o cliente não precisa mais do endereço. O cliente pode pedir um
atribuição permanente, pedindo um contrato de arrendamento
infinito. Mesmo quando
atribuir endereços "permanentes", um servidor pode optar por
distribuir
arrendamentos longos mas não infinitos para permitir a detecção do
fato de que
o cliente foi aposentado.
Em alguns ambientes, será necessário reatribuir a rede

endereços devido ao esgotamento dos endereços disponíveis. Em tais
ambientes, o mecanismo de alocação reutilizará endereços cujos
lease expirou. O servidor deve usar qualquer informação que seja
disponível no repositório de informações de configuração para
escolher
endereço para reutilização. Por exemplo, o servidor pode escolher o
mínimo
endereço recentemente atribuído. Como verificação de consistência,
a alocação
servidor deve investigar o endereço reutilizado antes de atribuir o
endereço,
por exemplo, com um pedido de eco ICMP, e o cliente DEVE sondar o
endereço recém-recebido, por exemplo, com ARP.
3. O Protocolo Cliente-Servidor
DHCP usa o formato de mensagem BOOTP definido no RFC 951 e

fornecido em
tabela 1 e figura 1. O campo 'op' de cada mensagem DHCP enviada de
um cliente para um servidor contém BOOTREQUEST. BOOTREPLY é usado
no
campo 'op' de cada mensagem DHCP enviada de um servidor para um
cliente.
Os primeiros quatro octetos do campo 'opções' da mensagem DHCP

contém os valores (decimal) 99, 130, 83 e 99, respectivamente (este
é o mesmo cookie mágico definido no RFC 1497 [17]). o
restante do campo 'opções' consiste em uma lista de tags
parâmetros que são chamados de "opções". Todas as "extensões de
fornecedor"
listados na RFC 1497 também são opções de DHCP. RFC 1533 dá a
conjunto completo de opções definidas para uso com o DHCP.
Várias opções foram definidas até agora. Uma opção em particular -

a opção "tipo de mensagem DHCP" - deve ser incluída em todos os
DHCP
mensagem. Esta opção define o "tipo" da mensagem DHCP.
Opções adicionais podem ser permitidas, exigidas ou não permitidas
dependendo do tipo de mensagem DHCP.
Em todo este documento, mensagens DHCP que incluem uma 'mensagem

DHCP
type 'option será referenciado pelo tipo de mensagem; por exemplo,
um
Mensagem DHCP com tipo de mensagem 'Tipo de mensagem DHCP' 1 será
encaminhada
como uma mensagem "DHCPDISCOVER".
3.1 Interação cliente-servidor - alocando um endereço de rede
O resumo a seguir das trocas de protocolo entre clientes e

servidores refere-se às mensagens DHCP descritas na tabela 2. O
diagrama da linha do tempo na figura 3 mostra as relações de tempo
em um
interação cliente-servidor típica. Se o cliente já conhece sua
endereço, algumas etapas podem ser omitidas; esta interação
abreviada é
descrito na secção 3.2.
1. O cliente transmite uma mensagem DHCPDISCOVER no seu local

físico
sub-rede. A mensagem DHCPDISCOVER PODE incluir opções que
sugerem
valores para o endereço de rede e a duração da concessão. Relé
BOOTP
agentes podem passar a mensagem para servidores DHCP não no
mesmo
sub-rede física.
2. Cada servidor pode responder com uma mensagem DHCPOFFER que

inclua uma
endereço de rede disponível no campo 'yiaddr' (e outros
parâmetros de configuração nas opções DHCP). Servidores não
precisam
reservar o endereço de rede oferecido, embora o protocolo
trabalhar de forma mais eficiente se o servidor evitar alocar a
oferta oferecida
endereço de rede para outro cliente. Ao alocar um novo endereço,
servidores devem verificar se o endereço de rede oferecido não é
em uso; por exemplo, o servidor pode sondar o endereço oferecido

com uma solicitação de eco ICMP. Servidores devem ser
implementados para que
administradores de rede podem optar por desativar sondas de
endereços alocados. O servidor transmite a mensagem DHCPOFFER
para o cliente, usando o agente de retransmissão BOOTP, se
necessário.
Message Use
------- ---
DHCPDISCOVER - Transmissão do cliente para localizar os servidores

disponíveis.
DHCPOFFER - Servidor para cliente em resposta ao DHCPDISCOVER com

oferta de parâmetros de configuração.
DHCPREQUEST - Mensagem do cliente para servidores (a) solicitando

parâmetros oferecidos de um servidor e
implicitamente
ofertas em declínio de todos os outros, (b)
confirmando
correção do endereço previamente atribuído após,
por exemplo, reinicialização do sistema ou (c)
estender a concessão em um
endereço de rede específico.
DHCPACK - Servidor para cliente com parâmetros de configuração,

incluindo endereço de rede comprometido.
DHCPNAK - Servidor para cliente indicando a noção de rede do

cliente
endereço está incorreto (por exemplo, o cliente
mudou para novo
sub-rede) ou a concessão do cliente como expirada
DHCPDECLINE - Cliente para servidor indicando endereço de rede já

está
em uso.
DHCPRELEASE - Cliente para servidor, abandonando o endereço de rede

e
cancelando o aluguel restante.
DHCPINFORM - Cliente para servidor, solicitando apenas a

configuração local
parâmetros; o cliente já configurou externamente
Endereço de rede.
Tabela 2: Mensagens DHCP
Servidor cliente servidor

(não selecionado) (selecionado)
vvv
| | |
| Inicia a inicialização |
| | |
| _____________ / | \ ____________ |
| / DHCPDISCOVER | DHCPDISCOVER \ |
| | |
Determina | Determina
configuração | configuração
| | |
| \ | ____________ / |
| \ ________ | / DHCPOFFER |
| DHCPOFFER \ | / |
| \ | |
| Recolhe respostas |
| \ | |
| Seleciona a configuração |
| | |
| _____________ / | \ ____________ |
| / DHCPREQUEST | DHCPREQUEST \ |
| | |
| | Confirma configuração
| | |
| | _____________ / |
| | / DHCPACK |
| | |
| Inicialização concluída |
| | |
. . .
. . .
| | |
| Desligamento gracioso |
| | |
| | \ ____________ |
| | DHCPRELEASE \ |
| | |
| | Descarta o aluguel
| | |
vvv
Figura 3: Diagrama da linha de tempo das mensagens trocadas entre
o DHCP
cliente e servidores ao alocar um novo endereço de rede
3. O cliente recebe uma ou mais mensagens DHCPOFFER de um ou mais

servidores. O cliente pode optar por esperar por várias
respostas.
O cliente escolhe um servidor do qual solicitar configuração
parâmetros, com base nos parâmetros de configuração oferecidos no
Mensagens DHCPOFFER. O cliente transmite uma mensagem DHCPREQUEST
que deve incluir a opção 'servidor identificador' para indicar
qual
servidor selecionado, e que PODE incluir outras opções
especificando valores de configuração desejados. O IP solicitado
endereço 'opção deve ser definida para o valor de' yiaddr 'no
Mensagem DHCPOFFER do servidor. Esta mensagem DHCPREQUEST é
transmissão e retransmitida através de agentes de retransmissão
DHCP / BOOTP. Ajudar
Certifique-se de que quaisquer agentes de retransmissão BOOTP
encaminham a mensagem DHCPREQUEST
para o mesmo conjunto de servidores DHCP que recebeu o original
Mensagem DHCPDISCOVER, a mensagem DHCPREQUEST DEVE usar o mesmo
valor no campo 'segs' do cabeçalho da mensagem DHCP e ser enviado
para o
mesmo endereço de broadcast IP que a mensagem DHCPDISCOVER
original.
O cliente expira e retransmite a mensagem DHCPDISCOVER se
o cliente não recebe mensagens DHCPOFFER.
4. Os servidores recebem a transmissão DHCPREQUEST do cliente.

Esses servidores não selecionados pela mensagem DHCPREQUEST usam
o
mensagem como notificação de que o cliente recusou esse servidor
oferta. O servidor selecionado na mensagem DHCPREQUEST confirma o
ligação para o cliente para armazenamento persistente e responde
com um
Mensagem DHCPACK contendo os parâmetros de configuração para o
solicitando cliente. A combinação de 'identificador de cliente'
ou
'chaddr' e endereço de rede atribuído constituem um
identificador para a concessão do cliente e são usados pelo
cliente
e servidor para identificar uma concessão mencionada em qualquer
mensagem DHCP.
Qualquer parâmetro de configuração na mensagem DHCPACK NÃO DEVE
conflito com aqueles na mensagem anterior DHCPOFFER para o qual o
cliente está respondendo. O servidor não deve verificar o
oferecido
endereço de rede neste momento. O campo 'yiaddr' no DHCPACK
as mensagens são preenchidas com o endereço de rede selecionado.
Se o servidor selecionado não puder satisfazer a mensagem

DHCPREQUEST
(por exemplo, o endereço de rede solicitado foi alocado), o
servidor deve responder com uma mensagem DHCPNAK.
Um servidor pode optar por marcar os endereços oferecidos aos

clientes em
Mensagens DHCPOFFER indisponíveis. O servidor DEVE marcar um
endereço oferecido a um cliente em uma mensagem DHCPOFFER como
disponível se
o servidor não recebe nenhuma mensagem DHCPREQUEST desse cliente.
5. O cliente recebe a mensagem DHCPACK com configuração

parâmetros. O cliente deve executar uma verificação final no
parâmetros (por exemplo, ARP para o endereço de rede alocado) e
observa
duração da concessão especificada na mensagem DHCPACK. Neste
ponto, o cliente está configurado. Se o cliente detectar que o

endereço já está em uso (por exemplo, através do uso de ARP), o
cliente deve enviar uma mensagem DHCPDECLINE para o servidor e
reinicia
o processo de configuração. O cliente deve esperar um mínimo de
dez
segundos antes de reiniciar o processo de configuração para
evitar
tráfego de rede excessivo em caso de loop.
Se o cliente receber uma mensagem DHCPNAK, o cliente reinicia

processo de configuração.
O cliente expira e retransmite a mensagem DHCPREQUEST se o

cliente recebe nem uma mensagem DHCPACK ou DHCPNAK. O cliente
retransmite o DHCPREQUEST de acordo com a retransmissão
algoritmo na seção 4.1. O cliente deve optar por retransmitir
o DHCPREQUEST vezes suficientes para dar probabilidade adequada
de
entrar em contato com o servidor sem causar o cliente (eo usuário
de
esse cliente) esperar muito antes de desistir; por exemplo, um
cliente
retransmitir como descrito na seção 4.1 pode retransmitir o
Mensagem DHCPREQUEST quatro vezes, para um atraso total de 60
segundos,
antes de reiniciar o procedimento de inicialização. Se o cliente
não recebe uma mensagem DHCPACK ou DHCPNAK depois de empregar o
algoritmo de retransmissão, o cliente reverte para o estado INIT
e
reinicia o processo de inicialização. O cliente DEVE notificar o
usuário que o processo de inicialização falhou e está sendo
reiniciado.
6. O cliente pode optar por renunciar a sua concessão em um endereço

de rede
enviando uma mensagem DHCPRELEASE para o servidor. O cliente
identifica a locação a ser liberada com seu 'identificador de
cliente',
ou 'chaddr' e endereço de rede na mensagem DHCPRELEASE. Se o
cliente usou um 'identificador de cliente' quando obteve a
concessão,
DEVE usar o mesmo 'identificador de cliente' na mensagem
DHCPRELEASE.
3.2 Interação cliente-servidor - reutilizando uma rede anteriormente

alocada
endereço
Se um cliente se lembra e deseja reutilizar um sistema previamente

alocado
endereço de rede, um cliente pode optar por omitir algumas das
etapas
descrito na seção anterior. O diagrama da linha do tempo na figura
4
mostra os relacionamentos de tempo em uma interação cliente-
servidor típica
para um cliente reutilizando um endereço de rede anteriormente
alocado.

1. O cliente transmite uma mensagem DHCPREQUEST em sua sub-rede
local.
A mensagem inclui o endereço de rede do cliente no
opção "endereço IP solicitado". Como o cliente não recebeu sua
endereço de rede, NÃO DEVE preencher o campo 'ciaddr'. BOOTP
agentes de retransmissão passar a mensagem para servidores DHCP
não no mesmo
sub-rede. Se o cliente usou um 'identificador de cliente' para
obter
endereço, o cliente DEVE usar o mesmo 'identificador de cliente'
no
Mensagem DHCPREQUEST.
2. Servidores com conhecimento dos parâmetros de configuração do

cliente
responder com uma mensagem DHCPACK ao cliente. Servidores NÃO
DEVEM
verifique se o endereço de rede do cliente já está em uso; a
O cliente pode responder a mensagens de solicitação de eco ICMP
neste momento.
Servidor cliente servidor
vvv
| | |
| Começa |
| inicialização |
| | |
| / | \ |
| _________ __ / | \ __________ |
| / DHCPREQU EST | DHCPREQUEST \ |
| / | \ |
| | |
Localiza | Localiza
configuração | configuração
| | |
| \ | / |
| \ | ___________ / |
| \ | / DHCPACK |
| \ _______ | / |
| DHCPACK \ | |
| Inicialização |
| complete |
| \ | |
| | |
| (Subsequente |
| DHCPACKS |
| ignorado) |
| | |
| | |
vvv
Figura 4: Diagrama da linha de tempo das mensagens trocadas entre

o DHCP
cliente e servidores ao reutilizar um arquivo alocado
Endereço de rede

Se a solicitação do cliente for inválida (por exemplo, o cliente

mudou
para uma nova sub-rede), os servidores DEVEM responder com uma
mensagem DHCPNAK para
o cliente. Servidores NÃO DEVEM responder se suas informações
não forem
garantido para ser exato. Por exemplo, um servidor que
identifica um
pedido para uma ligação expirada pertencente a outro servidor
DEVE
NÃO responder com um DHCPNAK a menos que os servidores estejam
usando um
mecanismo para manter a coerência entre os servidores.
Se 'giaddr' for 0x0 na mensagem DHCPREQUEST, o cliente está

ligado
a mesma sub-rede que o servidor. O servidor DEVE
Transmitir a mensagem DHCPNAK para o endereço de difusão
0xffffffff
porque o cliente pode não ter um endereço de rede ou sub-rede
corretos
máscara, e o cliente pode não estar respondendo a solicitações
ARP.
Caso contrário, o servidor DEVE enviar a mensagem DHCPNAK para o
IP
endereço do agente de transmissão BOOTP, conforme registrado em
'giaddr'. o
O agente de retransmissão, por sua vez, encaminhará a mensagem
diretamente para o
endereço de hardware do cliente, para que o DHCPNAK possa ser
entregue
se o cliente mudou para uma nova rede.
3. O cliente recebe a mensagem DHCPACK com configuração

parâmetros. O cliente executa uma verificação final nos
parâmetros
(como na seção 3.1), e observa a duração da locação especificada
na mensagem DHCPACK. A locação específica é implicitamente
identificada
pelo 'identificador de cliente' ou 'chaddr' e pelo endereço de
rede. No
Neste ponto, o cliente está configurado.
Se o cliente detectar que o endereço IP na mensagem DHCPACK

já está em uso, o cliente DEVE enviar uma mensagem DHCPDECLINE
para o
servidor e reinicia o processo de configuração solicitando uma
novo endereço de rede. Esta ação corresponde ao cliente
movendo-se para o estado INIT no diagrama de estado DHCP, que é
Se o cliente receber uma mensagem DHCPNAK, ela não poderá

reutilizar
lembrou o endereço de rede. Em vez disso, deve solicitar um novo
endereço reiniciando o processo de configuração, desta vez
usando o procedimento (não abreviado) descrito na seção
3.1. Essa ação também corresponde ao cliente se mudar para
o estado INIT no diagrama de estado do DHCP.
O cliente expira e retransmite a mensagem DHCPREQUEST se
o cliente não recebe nem uma mensagem DHCPACK nem uma mensagem
DHCPNAK. o
cliente retransmite o DHCPREQUEST de acordo com a retransmissão
algoritmo na seção 4.1. O cliente deve optar por retransmitir
o DHCPREQUEST vezes suficientes para dar probabilidade adequada
de
entrar em contato com o servidor sem causar o cliente (eo
usuário de
esse cliente) esperar muito antes de desistir; por exemplo, um
cliente
retransmitir como descrito na seção 4.1 pode retransmitir o
Mensagem DHCPREQUEST quatro vezes, para um atraso total de 60

segundos,
antes de reiniciar o procedimento de inicialização. Se o cliente
recebe uma mensagem DHCPACK ou DHCPNAK após o uso
o algoritmo de retransmissão, o cliente pode optar por usar o
Endereço de rede e parâmetros de configuração alocados
anteriormente
para o restante do contrato não expirado. Isso corresponde a
movendo para o estado BOUND no diagrama de transição do estado
do cliente mostrado
na figura 5.
4. O cliente pode optar por renunciar a sua concessão em uma rede

endereço enviando uma mensagem DHCPRELEASE para o servidor. o
cliente identifica a locação a ser liberada com sua
'identificador de cliente', ou 'chaddr' e endereço de rede no
Mensagem DHCPRELEASE.
Observe que, nesse caso, onde o cliente mantém sua rede

endereço localmente, o cliente normalmente não abrirá mão de
locação durante um desligamento gracioso. Apenas no caso em que
o
cliente explicitamente precisa renunciar ao seu arrendamento,
por exemplo, o cliente
está prestes a ser movido para uma sub-rede diferente, o cliente
enviará
uma mensagem DHCPRELEASE.
3.3 Interpretação e representação de valores temporais
Um cliente adquire uma concessão para um endereço de rede por um

período fixo de
tempo (que pode ser infinito). Ao longo do protocolo, os horários
são para
ser representado em unidades de segundos. O valor de tempo de
0xffffffff é
reservado para representar "infinito".
Como clientes e servidores podem não ter relógios sincronizados, os

horários são
representados nas mensagens DHCP como tempos relativos, para serem
interpretados
em relação ao relógio local do cliente. Representando relativo
vezes em unidades de segundos em uma palavra de 32 bits sem sinal
dá uma gama de
tempos relativos de 0 a aproximadamente 100 anos, o que é
suficiente
para os tempos relativos a serem medidos usando o DHCP.
O algoritmo para interpretação da duração do aluguel dado no

O parágrafo assume que os relógios cliente e servidor são estáveis
uns aos outros. Se houver desvio entre os dois relógios, o servidor
pode considerar que a concessão expirou antes do cliente. Para
compensar, o servidor pode retornar uma duração mais curta de
cliente que o servidor se compromete com o banco de dados local do
cliente
em formação.
3.4 Obtenção de parâmetros com endereço de rede configurado

externamente
Se um cliente obteve um endereço de rede através de outros meios

(por exemplo, configuração manual), ele pode usar uma mensagem de
solicitação DHCPINFORM
para obter outros parâmetros de configuração locais. Servidores

recebendo um
Mensagem DHCPINFORM construir uma mensagem DHCPACK com qualquer
local
parâmetros de configuração apropriados para o cliente sem:
alocação de um novo endereço, verificação de uma ligação existente,
preenchimento
em 'yiaddr' ou incluindo parâmetros de tempo de concessão. Os
servidores DEVERIAM
unicast a resposta do DHCPACK ao endereço dado no campo 'ciaddr'
da mensagem DHCPINFORM.
O servidor deve verificar o endereço de rede em uma mensagem

DHCPINFORM
para consistência, mas NÃO DEVE verificar se há uma concessão
existente. o
servidor forma uma mensagem DHCPACK contendo a configuração
parâmetros para o cliente solicitante e envia a mensagem DHCPACK
diretamente para o cliente.
3.5 Parâmetros do cliente no DHCP
Nem todos os clientes exigem a inicialização de todos os parâmetros

listados em
Apêndice A. Duas técnicas são usadas para reduzir o número de
parâmetros transmitidos do servidor para o cliente. Primeiro, a
maioria
os parâmetros têm padrões definidos nas RFCs de Requisitos do Host;
se o cliente não receber nenhum parâmetro do servidor que
sobrescreve
os padrões, um cliente usa esses valores padrão. Em segundo lugar,
na sua
mensagem inicial DHCPDISCOVER ou DHCPREQUEST, um cliente pode
fornecer o
servidor com uma lista de parâmetros específicos que o cliente está
interessado
Se o cliente incluir uma lista de parâmetros em um DHCPDISCOVER
mensagem, deve incluir essa lista em qualquer subseqüente
DHCPREQUEST
mensagens.
O cliente deve incluir a opção 'tamanho máximo da mensagem DHCP'

para
deixe o servidor saber quão grande o servidor pode fazer suas
mensagens DHCP.
Os parâmetros retornados para um cliente ainda podem exceder o
espaço
alocado para opções em uma mensagem DHCP. Neste caso, dois
opções flags (que devem aparecer no campo 'options' do
mensagem) indicam que os campos 'file' e 'sname' devem ser usados
para opções.
O cliente pode informar ao servidor quais parâmetros de

configuração
o cliente está interessado em incluir a 'lista de solicitação de
parâmetro'
opção. A parte de dados desta opção lista explicitamente as opções
solicitado pelo número da tag.
Além disso, o cliente pode sugerir valores para o endereço de rede

e tempo de concessão na mensagem DHCPDISCOVER. O cliente pode
incluir
a opção "endereço IP solicitado" para sugerir que um determinado IP
endereço pode ser atribuído, e pode incluir o 'tempo de concessão
do endereço IP'
opção para sugerir o tempo de locação que gostaria. Outras opções
representando "dicas" nos parâmetros de configuração são permitidas
em um
Mensagem DHCPDISCOVER ou DHCPREQUEST. No entanto, opções adicionais
podem
ser ignorado pelos servidores, e vários servidores podem, portanto,

não
retornar valores idênticos para algumas opções. O 'endereço IP
solicitado'
opção deve ser preenchida apenas em uma mensagem DHCPREQUEST quando
o
O cliente está verificando os parâmetros de rede obtidos
anteriormente. o
cliente preenche o campo 'ciaddr' somente quando configurado
corretamente
com um endereço IP no estado BOUND, RENEWING ou REBINDING.
Se um servidor receber uma mensagem DHCPREQUEST com um pedido
inválido
Endereço IP ', o servidor deve responder ao cliente com um DHCPNAK
mensagem e pode optar por relatar o problema ao sistema
administrador. O servidor pode incluir uma mensagem de erro no
opção 'mensagem'.
3.6 Uso de DHCP em clientes com múltiplas interfaces
Um cliente com várias interfaces de rede deve usar o DHCP através

de cada
interface independentemente para obter informações de configuração
parâmetros para essas interfaces separadas.
3.7 Quando os clientes devem usar o DHCP
Um cliente deve usar o DHCP para readquirir ou verificar seu

endereço IP e
parâmetros de rede sempre que os parâmetros da rede local possam
ter
mudou; por exemplo, no momento da inicialização do sistema ou após
uma desconexão do
rede local, pois a configuração da rede local pode mudar sem
conhecimento do cliente ou do usuário.
Se um cliente tiver conhecimento de um endereço de rede anterior e

não puder
para contatar um servidor DHCP local, o cliente pode continuar a
usar o
endereço de rede anterior até que a concessão desse endereço
expire.
Se a concessão expirar antes que o cliente possa contatar um
servidor DHCP, o
cliente deve interromper imediatamente o uso da rede anterior
endereço e pode informar os usuários locais sobre o problema.
4. Especificação do protocolo cliente-servidor DHCP
Nesta seção, assumimos que um servidor DHCP tem um bloco de rede

endereços dos quais pode satisfazer pedidos de novos endereços.
Cada
servidor também mantém um banco de dados de endereços alocados e
arrendamentos em
armazenamento permanente local.
4.1 Construindo e enviando mensagens DHCP
Clientes e servidores DHCP constroem mensagens DHCP preenchendo

campos na seção de formato fixo da mensagem e anexando
itens de dados marcados na área de opção de comprimento variável.
As opções
área inclui primeiro um "cookie mágico" de quatro octetos (que foi
descrito
na seção 3), seguido pelas opções. A última opção deve sempre

seja a opção 'end'.
O DHCP usa o UDP como seu protocolo de transporte. Mensagens DHCP

de um cliente
para um servidor são enviados para a porta 'servidor DHCP' (67), e
DHCP
mensagens de um servidor para um cliente são enviadas para a porta
'cliente DHCP'
(68). Um servidor com múltiplos endereços de rede (por exemplo, um
multi-homed
host) PODE usar qualquer um dos seus endereços de rede em mensagens
DHCP de saída.
O campo 'identificador do servidor' é usado para identificar um

servidor DHCP
em uma mensagem DHCP e como um endereço de destino de clientes para
servidores. Um servidor com vários endereços de rede DEVE estar
preparado
para aceitar qualquer um dos seus endereços de rede como
identificar esse servidor
em uma mensagem DHCP. Para acomodar uma rede potencialmente
incompleta
conectividade, um servidor deve escolher um endereço como um
'servidor
identificador 'que, para o melhor do conhecimento do servidor, é
alcançável
do cliente. Por exemplo, se o servidor DHCP e o cliente DHCP
estão conectados à mesma sub-rede (ou seja, o campo 'giaddr' no
mensagem do cliente é zero), o servidor deve selecionar o IP
endereço que o servidor está usando para comunicação nessa sub-rede
como o
'identificador do servidor'. Se o servidor estiver usando vários
endereços IP em
essa sub-rede, qualquer endereço desse tipo pode ser usado. Se o
servidor tiver
recebeu uma mensagem através de um agente de retransmissão DHCP, o
servidor DEVE
escolha um endereço na interface em que a mensagem foi
recebido como o 'identificador do servidor' (a menos que o servidor
tenha outro,
melhor informação sobre a qual fazer a sua escolha). Clientes DHCP
use o endereço IP fornecido na opção 'servidor identificador' para
qualquer
solicitações unicast para o servidor DHCP.
Mensagens DHCP transmitidas por um cliente antes de o cliente obter

seu endereço IP deve ter o campo de endereço de origem no cabeçalho
IP
definido como 0.
Se o campo 'giaddr' em uma mensagem DHCP de um cliente for

diferente de zero,
o servidor envia qualquer mensagem de retorno para a porta
'servidor DHCP' no
Agente de retransmissão BOOTP cujo endereço aparece em 'giaddr'. Se
o 'giaddr'
campo é zero e o campo 'ciaddr' é diferente de zero, então o
servidor
unicasts mensagens DHCPOFFER e DHCPACK para o endereço em 'ciaddr'.
Se 'giaddr' for zero e 'ciaddr' for zero, o bit de broadcast será
definido, o servidor transmite as mensagens DHCPOFFER e DHCPACK
para
0xffffffff. Se o bit de transmissão não estiver definido e 'giaddr'
for zero e
'ciaddr' é zero, então o servidor unicasts DHCPOFFER e DHCPACK
mensagens para o endereço de hardware do cliente e o endereço
'yiaddr'. Em
Em todos os casos, quando 'giaddr' é zero, o servidor transmite
qualquer DHCPNAK
mensagens para 0xffffffff.
Se as opções em uma mensagem DHCP se estenderem para o 'sname' e

'file'
campos, a opção 'sobrecarga de opção' DEVE aparecer nas 'opções'
campo, com valor 1, 2 ou 3, conforme especificado na RFC 1533. Se o
opção de 'sobrecarga de opção' está presente no campo 'opções', o

opções no campo 'opções' DEVEM ser finalizadas por uma opção
'final',
e pode conter uma ou mais opções 'pad' para preencher o campo de
opções.
As opções nos campos 'sname' e 'file' (se em uso como indicado)
pela opção 'options overload') DEVE começar com o primeiro octeto
de
campo, DEVE ser terminado por uma opção 'final' e DEVE ser
seguido por opções de "pad" para preencher o restante do campo.
Qualquer
opção individual nos campos 'options', 'sname' e 'file'
inteiramente contido nesse campo. As opções no campo 'opções'
DEVE ser interpretado primeiro, de modo que qualquer opção de
'sobrecarga de opção'
ser interpretado. O campo 'arquivo' DEVE ser interpretado a seguir
(se o
A opção 'option overload' indica que o campo 'file' contém
DHCP), seguido pelo campo 'sname'.
Os valores a serem passados em uma tag 'option' podem ser muito

longos para caber
os 255 octetos disponíveis para uma única opção (por exemplo, uma
lista de roteadores
em uma opção 'roteador' [21]). As opções podem aparecer apenas uma
vez, a menos que
especificado de outra forma no documento de opções. O cliente
concatena
os valores de múltiplas instâncias da mesma opção em um único
lista de parâmetros para configuração.
Os clientes DHCP são responsáveis por toda a retransmissão de

mensagens. o
O cliente DEVE adotar uma estratégia de retransmissão que incorpore
algoritmo de backoff exponencial aleatório para determinar o atraso
entre retransmissões. O atraso entre as retransmissões DEVE ser
escolhido para permitir tempo suficiente para que as respostas do
servidor sejam
entregue com base nas características da internetwork entre
o cliente e o servidor. Por exemplo, em uma Ethernet de 10Mb / s
internetwork, o atraso antes da primeira retransmissão DEVE ser 4
segundos randomizados pelo valor de um número aleatório uniforme
escolhido
do intervalo -1 a +1. Clientes com relógios que fornecem resolução
granularidade de menos de um segundo pode escolher um não inteiro
valor de randomização. O atraso antes da próxima retransmissão DEVE
ser 8 segundos randomizados pelo valor de um número uniforme
escolhido a partir de
o intervalo -1 a +1. O atraso na retransmissão DEVE ser duplicado
com
retransmissões subsequentes até um máximo de 64 segundos. O cliente
PODE fornecer uma indicação de tentativas de retransmissão para o
usuário como
uma indicação do progresso do processo de configuração.
O campo 'xid' é usado pelo cliente para corresponder mensagens DHCP

recebidas
com solicitações pendentes. Um cliente DHCP deve escolher 'xid's em
tal
de maneira a minimizar a chance de usar um 'xid' idêntico ao usado
por outro cliente. Por exemplo, um cliente pode escolher um
diferente,
inicial aleatório 'xid' cada vez que o cliente é reinicializado e
subseqüentemente use xid's seqüenciais até a próxima
reinicialização. Selecionando
um novo 'xid' para cada retransmissão é uma decisão de
implementação. UMA
O cliente pode optar por reutilizar o mesmo 'xid' ou selecionar um
novo 'xid' para
cada mensagem retransmitida.
Normalmente, os servidores DHCP e os agentes de retransmissão BOOTP

tentam fornecer
Mensagens DHCPOFFER, DHCPACK e DHCPNAK diretamente para o cliente
usando
entrega de uicast. O endereço de destino IP (no cabeçalho IP) é
definido para o endereço 'yiaddr' do DHCP e o destino da camada de
links
endereço é definido para o endereço 'chaddr' do DHCP. Infelizmente,
alguns
as implementações do cliente não conseguem receber esse IP unicast
datagramas até que a implementação tenha sido configurada com um
Endereço IP (levando a um impasse no qual o endereço IP do cliente
não pode ser entregue até que o cliente tenha sido configurado com
um IP
endereço).
Um cliente que não pode receber datagramas IP unicast até o seu

protocolo
software foi configurado com um endereço IP DEVERÁ DEFINIR
BROADCAST bit no campo 'flags' para 1 em qualquer DHCPDISCOVER ou
DHCPREQUEST mensagens que o cliente envia. O bit BROADCAST
fornecer uma sugestão para o servidor DHCP e o agente de
retransmissão BOOTP para transmitir
quaisquer mensagens para o cliente na sub-rede do cliente. Um
cliente que pode
receber datagramas IP unicast antes de seu software de protocolo
ter sido
configurado deve limpar o bit BROADCAST para 0. O BOOTP
documento de esclarecimentos discute as ramificações do uso do
BROADCAST bit [21].
Um servidor ou agente de retransmissão que envia ou retransmite

diretamente uma mensagem DHCP
para um cliente DHCP (ou seja, não para um agente de retransmissão
especificado no
campo "giaddr") deve examinar o bit BROADCAST nas "bandeiras"
campo. Se este bit estiver definido como 1, a mensagem DHCP DEVE
ser enviada como
uma transmissão IP usando um endereço de transmissão IP
(preferencialmente 0xffffffff)
como o endereço de destino IP e o endereço de difusão da camada de
enlace como
o endereço de destino da camada de link. Se o bit BROADCAST estiver
limpo
para 0, a mensagem deve ser enviada como um unicast IP para o
endereço IP
especificado no campo 'yiaddr' e o endereço da camada de enlace
especificado
no campo 'chaddr'. Se o unicast não for possível, a mensagem
PODE ser enviado como uma transmissão IP usando um endereço de
broadcast IP
(preferencialmente 0xffffffff) como endereço IP de destino e l
tinta-
encaminhe o endereço de broadcast como o endereço de destino da
camada de enlace.
4.2 Controles administrativos do servidor DHCP
Os servidores DHCP não precisam responder a todos os DHCPDISCOVER e

Mensagem DHCPREQUEST que recebem. Por exemplo, uma rede
administrador, para manter o controle rigoroso sobre os clientes
conectados
para a rede, pode escolher configurar servidores DHCP para
responder apenas
para clientes que tenham sido previamente registrados por meio de
mecanismo. A especificação DHCP descreve apenas as interações
entre clientes e servidores quando os clientes e servidores
escolhem
interagir; está além do escopo da especificação DHCP
descrever todos os controles administrativos que o sistema
administradores podem querer usar. Servidor DHCP específico

implementações podem incorporar quaisquer controles ou políticas
desejados por um
administrador de rede.
Em alguns ambientes, um servidor DHCP terá que considerar os

valores
das opções de classe de fornecedor incluídas em DHCPDISCOVER ou
DHCPREQUEST
mensagens ao determinar os parâmetros corretos para um determinado
cliente.
Um servidor DHCP precisa usar algum identificador exclusivo para

associar
cliente com o seu contrato. O cliente pode optar por fornecer
explicitamente
o identificador através da opção 'identificador do cliente'. Se o
cliente
fornece um 'identificador de cliente', o cliente DEVE usar o mesmo
'cliente'
identificador 'em todas as mensagens subsequentes, eo servidor DEVE
usar esse
identificador para identificar o cliente. Se o cliente não fornecer
um
opção 'client identifier', o servidor DEVE usar o conteúdo do
campo 'chaddr' para identificar o cliente. É crucial para um DHCP
cliente para usar um identificador exclusivo dentro da sub-rede
para a qual o
cliente está anexado na opção 'identificador do cliente'. Uso de
'chaddr' como identificador exclusivo do cliente pode causar
inesperado
resultados, pois esse identificador pode estar associado a um
hardware
interface que poderia ser movida para um novo cliente. Alguns sites
podem escolher
para usar o número de série do fabricante como o 'identificador de
cliente', para
evitar mudanças inesperadas em um endereço de rede do cliente
devido à transferência
de interfaces de hardware entre computadores. Os sites também podem
optar por usar
um nome DNS como o 'identificador de cliente', fazendo com que as
concessões de endereço sejam
associado ao nome DNS em vez de uma caixa de hardware específica.
Clientes DHCP estão livres para usar qualquer estratégia na seleção

de um servidor DHCP
entre aqueles dos quais o cliente recebe uma mensagem DHCPOFFER. o
cliente implementação de DHCP deve fornecer um mecanismo para o
usuário
para selecionar diretamente os valores do 'identificador de classe
do fornecedor'.
4.3 Comportamento do servidor DHCP
Um servidor DHCP processa as mensagens DHCP recebidas de um cliente

com base
o estado atual da ligação para esse cliente. Um servidor DHCP pode
recebe as seguintes mensagens de um cliente:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
A Tabela 3 fornece o uso dos campos e opções em uma mensagem DHCP

um servidor. O restante desta seção descreve a ação do
Servidor DHCP para cada mensagem recebida possível.
4.3.1 Mensagem DHCPDISCOVER
Quando um servidor recebe uma mensagem DHCPDISCOVER de um cliente,

o
servidor escolhe um endereço de rede para o cliente solicitante. Se
não
endereço está disponível, o servidor pode escolher relatar o
problema para
o administrador do sistema. Se um endereço estiver disponível, o
novo endereço
DEVE ser escolhido da seguinte forma:
o O endereço atual do cliente, conforme registrado no registro

atual do cliente;
ligação, ELSE
o Endereço anterior do cliente, conforme registrado no cliente

(agora
expirado ou liberado), se esse endereço estiver no servidor
pool de endereços disponíveis e não já alocados, ELSE
o O endereço solicitado na opção "Endereço IP Solicitado", se

endereço é válido e não está alocado,
o Um novo endereço alocado a partir do pool de servidores

disponível
endereços; o endereço é selecionado com base na sub-rede a
partir da qual
a mensagem foi recebida (se 'giaddr' for 0) ou no endereço de
o agente de retransmissão que encaminhou a mensagem ('giaddr'
quando não 0).
Conforme descrito na seção 4.2, um servidor MAIO, para

administração
razões, atribuir um endereço diferente do solicitado ou
recusar-se a atribuir um endereço a um determinado cliente, embora
endereços estão disponíveis.
Observe que, em algumas arquiteturas de rede (por exemplo,

internets com mais
de uma sub-rede IP atribuída a um segmento de rede física), pode
ser
o caso em que o cliente DHCP deve ser atribuído um endereço de um
sub-rede diferente do endereço registrado em 'giaddr'. Assim, o
DHCP
não exige que o cliente seja atribuído como endereço do
sub-rede em 'giaddr'. Um servidor é livre para escolher alguma
outra sub-rede,
e está além do escopo da especificação DHCP descrever formas
em que o endereço IP atribuído pode ser escolhido.
Embora não seja necessário para a operação correta do DHCP, o

servidor DEVE
NÃO reutilize o endereço de rede selecionado antes que o cliente
responda
a mensagem DHCPOFFER do servidor. O servidor pode optar por gravar
endereço como oferecido ao cliente.
O servidor também deve escolher um prazo de expiração para a

concessão, como
segue:
o Se o cliente não solicitou uma locação específica no

Mensagem DHCPDISCOVER e o cliente já tem uma rede atribuída
endereço, o servidor retorna o tempo de expiração da concessão
anteriormente
atribuído a esse endereço (note que o cliente deve explicitamente
solicitar uma locação específica para estender o prazo de
expiração em um
endereço previamente atribuído), ELSE
o Se o cliente não solicitou uma locação específica no

Mensagem DHCPDISCOVER e o cliente não tem um atribuído
endereço de rede, o servidor atribui um padrão configurado
localmente
tempo de locação, ELSE
o Se o cliente solicitou uma concessão específica no DHCPDISCOVER

mensagem (independentemente de o cliente ter uma rede atribuída
endereço), o servidor pode optar por retornar o número solicitado
locação (se a concessão for aceitável para a política local) ou
selecione
outro contrato.
Campo DHCPOFFER DHCPACK DHCPNAK

----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY DE BOTREPLIA
'htype' (do RFC "números atribuídos")
'hlen' (comprimento do endereço de hardware em octetos)
'lúpulo' 0 0 0
'xid' 'xid' do cliente 'xid' do cliente 'xid' do cliente
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
mensagem mensagem mensagem
'seg' 0 0 0
'ciaddr' 0 'ciaddr' de 0
DHCPREQUEST ou 0
'yiaddr' endereço IP oferecido endereço IP 0
para cliente atribuído ao cliente
'siaddr' endereço IP do próximo endereço IP do próximo 0
servidor bootstrap do servidor de inicialização
'flags' 'flags' de 'flags' de 'flags' de
cliente DHCPDISCOVER cliente DHCPREQUEST cliente
DHCPREQUEST
'giaddr' 'giaddr' de 'giaddr' de 'giaddr' de
DHCPREQUEST
'chaddr' 'chaddr' de 'chaddr' de 'chaddr' de
DHCPREQUEST
'sname' Nome do host do servidor Nome do host do servidor (não
utilizado)
ou opções ou opções
'arquivo' Arquivo de inicialização do cliente Arquivo de inicialização
do cliente (não utilizado)
nome ou opções nome ou opções
opções de opções 'opções'
Opção DHCPOFFER DHCPACK DHCPNAK

------ --------- ------- -------
O endereço IP solicitado NÃO DEVE NÃO DEVE NÃO
Tempo de concessão de endereço IP deve deve (DHCPREQUEST) não deve
NÃO DEVE (DHCPINFORM)
Use campos 'file' / 'sname' MAIO PODE NÃO DEVE
Tipo de mensagem DHCP DHCPOFFER DHCPACK DHCPNAK
Lista de solicitação de parâmetro NÃO DEVE NÃO DEVE NÃO
Mensagem DEVERIA DEVERIA
O identificador do cliente NÃO DEVE NÃO PODE
Identificador de classe de fornecedor PODE MAIO
Identificador do servidor DEVE SER PRECISO
O tamanho máximo da mensagem NÃO DEVE NÃO DEVE NÃO
Todos os outros podem maio não deve
Tabela 3: Campos e opções usadas pelos servidores DHCP
Depois que o endereço e a concessão da rede forem determinados, o

servidor
constrói uma mensagem DHCPOFFER com a configuração oferecida
parâmetros. É importante que todos os servidores DHCP retornem o
mesmo
parâmetros (com a possível exceção de uma rede recentemente alocada
endereço) para garantir o comportamento previsível do cliente,
independentemente de qual
servidor que o cliente seleciona. Os parâmetros de configuração
devem ser
selecionado aplicando as seguintes regras na ordem abaixo.
O administrador da rede é responsável por configurar múltiplos
Servidores DHCP para garantir respostas uniformes desses
servidores. o
servidor deve retornar ao cliente:
o O endereço de rede do cliente, conforme determinado pelas regras

dadas
anteriormente nesta seção,
o O prazo de expiração do contrato de locação do cliente, conforme

determinado pelo
regras dadas anteriormente nesta seção,
o Parâmetros solicitados pelo cliente, de acordo com o seguinte

regras:
- Se o servidor foi explicitamente configurado com um padrão

valor para o parâmetro, o servidor deve incluir esse valor
em uma opção apropriada no campo 'opção',
- SE o servidor reconhece o parâmetro como um parâmetro

definido no Documento de Requisitos do Host, o servidor
DEVE
incluir o valor padrão para esse parâmetro, conforme
Documento de Requisitos do Host em uma opção apropriada no
campo 'opção', ELSE
- O servidor não deve retornar um valor para esse parâmetro,
O servidor DEVE fornecer tantos parâmetros solicitados quanto

possível e deve omitir quaisquer parâmetros que não possa
fornecer. o
servidor DEVE incluir cada parâmetro solicitado apenas uma vez, a
menos que
explicitamente permitido nas opções DHCP e no fornecedor BOOTP
Documento de extensões.
o Quaisquer parâmetros da ligação existente que diferem do host

Padrões do Documento de Requisitos,
o Quaisquer parâmetros específicos para este cliente (conforme

identificado
o conteúdo de 'chaddr' ou 'client identifier' no DHCPDISCOVER
ou mensagem DHCPREQUEST), por exemplo, conforme configurado pela
rede
administrador,
o Quaisquer parâmetros específicos da classe deste cliente

(conforme identificado
pelo conteúdo do 'identificador de classe de fornecedor'
opção na mensagem DHCPDISCOVER ou DHCPREQUEST),
por exemplo, conforme configurado pelo administrador da rede; os
parametros
DEVE ser identificado por uma correspondência exata entre o
fornecedor do cliente
identificadores de classe e as classes do cliente identificadas
no
servidor,
o Parâmetros com valores não padrão na sub-rede do cliente.
O servidor pode escolher retornar o 'identificador de classe de

fornecedor' usado para
determinar os parâmetros na mensagem DHCPOFFER para auxiliar o
cliente na seleção de qual DHCPOFFER para aceitar. O servidor
insere
o campo 'xid' da mensagem DHCPDISCOVER no campo 'xid' do
a mensagem DHCPOFFER e envia a mensagem DHCPOFFER para o
solicitando cliente.
4.3.2 Mensagem DHCPREQUEST
Uma mensagem DHCPREQUEST pode vir de um cliente respondendo a um

Mensagem DHCPOFFER de um servidor, de um cliente verificando um
endereço IP alocado ou de um cliente que estende a concessão em um
Endereço de rede. Se a mensagem DHCPREQUEST contiver um 'servidor
identificador ', a mensagem é em resposta a um DHCPOFFER
mensagem. Caso contrário, a mensagem é uma solicitação para
verificar ou estender
arrendamento existente. Se o cliente usa um 'identificador de
cliente' em um
Mensagem DHCPREQUEST, deve usar esse mesmo "identificador de
cliente" em todos
mensagens subseqüentes. Se o cliente incluiu uma lista de pedidos
parâmetros em uma mensagem DHCPDISCOVER, DEVE incluir essa lista em
todas as mensagens subsequentes.
Qualquer parâmetro de configuração na mensagem DHCPACK NÃO DEVE

conflito com aqueles na mensagem anterior DHCPOFFER para o qual o
cliente está respondendo. O cliente deve usar os parâmetros no
Mensagem DHCPACK para configuração.
Os clientes enviam mensagens DHCPREQUEST da seguinte maneira:
o DHCPREQUEST gerado durante o estado SELECTING:
Cliente insere o endereço do servidor selecionado no 'servidor

identificador ',' ciaddr 'DEVE ser zero,' endereço IP solicitado
'DEVE ser
preenchido com o valor yiaddr do DHCPOFFER escolhido.
Note que o cliente pode optar por coletar vários DHCPOFFER

mensagens e selecione a "melhor" oferta. O cliente indica sua
seleção identificando o servidor de oferta no DHCPREQUEST
mensagem. Se o cliente não receber ofertas aceitáveis, o cliente
pode optar por tentar outra mensagem DHCPDISCOVER. Portanto, o
servidores podem não receber um DHCPREQUEST específico do qual
eles podem
decidir se o cliente aceitou ou não a oferta. Porque
os servidores não confirmaram quaisquer atribuições de endereços
de rede
a base de um DHCPOFFER, os servidores estão livres para
reutilizar oferecidos
endereços de rede em resposta a pedidos subsequentes. Como um
detalhes de implementação, os servidores não devem reutilizar
endereços oferecidos
e pode usar um mecanismo de tempo limite específico da
implementação para decidir
quando reutilizar um endereço oferecido.
o DHCPREQUEST gerado durante o estado INIT-REBOOT:
'identificador do servidor' NÃO DEVE ser preenchido, 'endereço

IP solicitado'
opção deve ser preenchida com a noção do cliente de sua
anteriormente
endereço atribuído. 'ciaddr' deve ser zero. O cliente está
procurando
verificar uma configuração armazenada em cache anteriormente
alocada. Servidor DEVERIA
enviar uma mensagem DHCPNAK para o cliente se o "endereço IP
solicitado"
está incorreto ou está na rede errada.
Determinar se um cliente no estado INIT-REBOOT está no

A rede correta é feita examinando-se o conteúdo de 'giaddr', o
opção "endereço IP solicitado" e uma consulta ao banco de dados.
Se o DHCP
servidor detecta que o cliente está na rede incorreta (ou seja,
resultado da aplicação da máscara de sub-rede local ou da
máscara de sub-rede remota (se
'giaddr' não é zero) para o valor da opção 'endereço IP
solicitado'
não corresponde a realidade), então o servidor deve enviar um
DHCPNAK
mensagem para o cliente.
Se a rede estiver correta, o servidor DHCP deve verificar se

a noção do cliente de seu endereço IP está correta. Se não,
então o
servidor deve enviar uma mensagem DHCPNAK para o cliente. Se o
DHCP
servidor não tem registro deste cliente, então ele deve
permanecer em silêncio,
e pode enviar um aviso para o administrador da rede. este
comportamento é necessário para a coexistência pacífica de
comunicando servidores DHCP no mesmo fio.
Se 'giaddr' for 0x0 na mensagem DHCPREQUEST, o cliente está

ligado
a mesma sub-rede que o servidor. O servidor DEVE transmitir o
Mensagem DHCPNAK para o endereço de difusão 0xffffffff porque o
o cliente pode não ter um endereço de rede ou uma máscara de
sub-rede corretos e
o cliente pode não estar respondendo a solicitações ARP.
Se 'giaddr' estiver definido na mensagem DHCPREQUEST, o cliente

está em um
sub-rede diferente. O servidor DEVE definir o bit de transmissão
no
DHCPNAK, para que o agente de retransmissão transmitirá o
DHCPNAK para o
cliente, porque o cliente pode não ter um endereço de rede
correto
ou máscara de sub-rede, e o cliente pode não estar respondendo a
solicitações ARP.
o DHCPREQUEST gerado durante o estado de RENOVAÇÃO:

IP solicitado'
A opção NÃO DEVE ser preenchida, o 'ciaddr' DEVE ser preenchido
com
endereço IP do cliente. Nesta situação, o cliente está
completamente
configurado e está tentando estender sua concessão. Esta
mensagem será
ser unicast, então nenhum agente de revezamento estará envolvido
em sua
transmissão. Porque 'giaddr' não é, portanto, preenchido, o
O servidor DHCP irá confiar no valor em 'ciaddr', e usá-lo
quando
respondendo ao cliente.
Um cliente pode optar por renovar ou estender seu contrato antes

de T1. o
servidor pode optar por não prolongar a concessão (como uma
decisão de
o administrador da rede), mas deve retornar uma mensagem DHCPACK
independentemente.
o DHCPREQUEST gerado durante o estado REBINDING:

IP solicitado'
A opção NÃO DEVE ser preenchida, o 'ciaddr' DEVE ser preenchido
com
endereço IP do cliente. Nesta situação, o cliente está
completamente
configurado e está tentando estender sua concessão. Esta
mensagem DEVE
ser transmitido para o endereço de broadcast IP 0xffffffff. O
DHCP
servidor deve verificar 'ciaddr' para correção antes de
responder a
o DHCPREQUEST.
O DHCPREQUEST de um cliente REBINDING é destinado a acomodar

sites que têm vários servidores DHCP e um mecanismo para
manter a consistência entre concessões gerenciadas por vários
servidores.
Um servidor DHCP PODERÁ estender a concessão de um cliente
somente se ele tiver
autoridade administrativa para o fazer.
4.3.3 Mensagem DHCPDECLINE
Se o servidor receber uma mensagem DHCPDECLINE, o cliente

descoberto através de outros meios que a rede sugerida
endereço já está em uso. O servidor deve marcar o endereço de rede
como não disponível e deve notificar o administrador do sistema
local de
um possível problema de configuração.
4.3.4 Mensagem DHCPRELEASE
Após o recebimento de uma mensagem DHCPRELEASE, o servidor marca a

rede
endereço como não atribuído. O servidor deve manter um registro do
parâmetros de inicialização do cliente para possível reutilização
em resposta a
solicitações subseqüentes do cliente.
4.3.5 Mensagem DHCPINFORM
O servidor responde a uma mensagem DHCPINFORM enviando um DHCPACK

mensagem diretamente para o endereço indicado no campo 'ciaddr' do
Mensagem DHCPINFORM. O servidor NÃO DEVE enviar um prazo de
expiração da concessão
para o cliente e não deve preencher 'yiaddr'. O servidor inclui
outros parâmetros na mensagem DHCPACK, conforme definido na seção
4.3.1.
4.3.6 Mensagens do cliente
A Tabela 4 detalha as diferenças entre mensagens de clientes em

vários estados.
-------------------------------------------------- ----------------
---
| | INIT-REBOOT | SELECIONANDO | RENOVAÇÃO | REABINDING |
-------------------------------------------------- ----------------
---
| broad / unicast | broadcast | transmissão | unicast | broadcast |
| server-ip | NÃO DEVE | DEVE | NÃO DEVE | NÃO DEVE |
| solicitado-ip | DEVE | DEVE | NÃO DEVE | NÃO DEVE |
| ciaddr | zero | zero | endereço IP | endereço IP |
-------------------------------------------------- ----------------
---
Tabela 4: Mensagens do cliente de diferentes estados
4.4 comportamento do cliente DHCP
A Figura 5 fornece um diagrama de transição de estado para um

cliente DHCP. UMA
cliente pode receber as seguintes mensagens de um servidor:
o DHCPOFFER
o DHCPACK
o DHCPNAK
A mensagem DHCPINFORM não é mostrada na figura 5. Um cliente

simplesmente
envia o DHCPINFORM e aguarda por mensagens DHCPACK. Uma vez o
cliente
selecionou seus parâmetros, concluiu a configuração
processo.
A Tabela 5 fornece o uso dos campos e opções em uma mensagem DHCP

um cliente. O restante desta seção descreve a ação do
Cliente DHCP para cada mensagem recebida possível. A descrição em
a seção a seguir corresponde ao procedimento de configuração
completo
anteriormente descrito na seção 3.1, eo texto no subseqüente
seção corresponde ao procedimento de configuração abreviado
-------- -------
| | + --------------------------> | | <------------------- +
| INIT- | | + --------------------> | INIT | |
| REINICIAR | DHCPNAK / + ----------> | | <--- + |
| | Restart | | ------- | |
-------- | DHCPNAK / | | |
| Rejeitar oferta | - / Enviar DHCPDISCOVER |
- / Enviar DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (não aceita) / ----------- | |
| | | Enviar DHCPDECLINE | | |
| REINICIALIZANDO | | | | SELECIONANDO | <---- + |
| | | / | | | DHCPOFFER / |
----------- | / ----------- | Recolha |
| | / | | | respostas |
DHCPACK / | / + ---------------- + + ------- + |
Contrato de locação, set | | v Selecione oferta / |
temporizadores T1, T2 ------------ enviar DHCPREQUEST | |
| + -----> | | DHCPNAK, Lease expirou / |
| | | SOLICITANDO | Parar rede |
DHCPOFFER / | | | |
Descartar ------------ | |
| | | | ----------- |
| + -------- + DHCPACK / | | |
| Contrato de locação, set ----- | REBINDO | |
| temporizadores T1, T2 / | | |
| | DHCPACK / ----------- |
| v Concessão de registro, conjunto ^ |
+ ----------------> ------- / timers T1, T2 | |
+ -----> | | <--- + | |
| | BOUND | <--- + | |
DHCPOFFER, DHCPACK, | | | T2 expira / DHCPNAK /
DHCPNAK / Descartar ------- | Rede de difusão de parada
| | | | DHCPREQUEST |
+ ------- + | DHCPACK / | |
T1 expira / registro de locação, set | |
Enviar temporizadores DHCPREQUEST T1, T2 | |
para servidor de leasing | | |
| ---------- | |
| | | ------------ + |
+ -> | RENOVAÇÃO | |
| | ---------------------------- +
----------
Figura 5: Diagrama de transição de estado para clientes DHCP
4.4.1 Inicialização e alocação do endereço de rede
O cliente começa no estado INIT e forma uma mensagem DHCPDISCOVER.

O cliente deve esperar um tempo aleatório entre um e dez segundos
para
dessincronizar o uso de DHCP na inicialização. O cliente define
'ciaddr'
para 0x00000000. O cliente pode solicitar parâmetros específicos
por
incluindo a opção 'lista de pedidos de parâmetros'. O cliente pode
sugerir um endereço de rede e / ou tempo de concessão, incluindo
opções de 'endereço IP solicitado' e 'tempo de concessão de
endereço IP'. o
cliente deve incluir seu endereço de hardware no campo 'chaddr', se
necessário para a entrega de mensagens de resposta DHCP. O cliente
pode
incluir um identificador exclusivo diferente no "identificador do
cliente"
opção, como discutido na seção 4.2. Se o cliente incluiu uma lista
de parâmetros solicitados em uma mensagem DHCPDISCOVER, deve
incluir
essa lista em todas as mensagens subsequentes.
O cliente gera e registra um identificador de transação aleatória e

insere esse identificador no campo 'xid'. O cliente registra sua
própria hora local para uso posterior no cálculo da expiração da
concessão. o
cliente, em seguida, transmite o DHCPDISCOVER no hardware local
endereço de broadcast para o endereço de broadcast IP 0xffffffff e
'DHCP
porta UDP do servidor.
Se o 'xid' de uma mensagem DHCPOFFER de chegada não corresponder ao

'xid' da mensagem DHCPDISCOVER mais recente, a mensagem DHCPOFFER
deve ser descartado silenciosamente. Todas as mensagens DHCPACK que
chegam devem ser
silenciosamente descartado.
O cliente coleta mensagens DHCPOFFER durante um período de tempo,

seleciona
uma mensagem DHCPOFFER do (possivelmente muitos) DHCPOFFER de
entrada
mensagens (por exemplo, a primeira mensagem DHCPOFFER ou a mensagem
DHCPOFFER
do servidor usado anteriormente) e extrai o endereço do servidor de
a opção 'servidor identificador' na mensagem DHCPOFFER. A Hora
sobre o qual o cliente recolhe mensagens e o mecanismo usado para
selecione um DHCPOFFER dependente da implementação.
Campo DHCPDISCOVER DHCPREQUEST DHCPDECLINE,

DHCPREFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (do RFC "números atribuídos")
'hlen' (comprimento do endereço de hardware em octetos)
'lúpulo' 0 0 0
'xid' selecionado pelo cliente 'xid' do servidor selecionado por
Cliente de mensagem DHCPOFFER
's' 0 ou segundos desde 0 ou segundos desde 0
Processo DHCP iniciado processo DHCP iniciado
'flags' Definir 'BROADCAST' Definir 'BROADCAST' 0
sinalizador se o sinalizador do cliente se o cliente
requer transmissão requer transmissão
responder resposta
'ciaddr' 0 (DHCPDISCOVER) 0 ou 0 do cliente (DHCPDECLINE)
rede do cliente de endereço de rede do cliente
endereço de rede (limite / RENOVAR / REINICIAR) endereço
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
hardware do cliente de hardware do cliente de hardware 'chaddr'
endereço address address
opções 'sname', se opções, if (não utilizadas)
indicado em indicado em
'sname / file' 'sname / file'
opção; caso contrário, opção; de outra forma
sem uso não utilizado
Opções de 'arquivo', se opções, se (não utilizado)
indicado em indicado em
'sname / file' 'sname / file'
opção; caso contrário, opção; de outra forma
sem uso não utilizado
opções de opções 'opções' (não utilizadas)
Opção DHCPDISCOVER DHCPREQUEST DHCPDECLINE,

------ ------------ ----------- -----------
Endereço IP solicitado pode ser obrigatório
(DESCOBRIR) SELECIONANDO ou (DHCPDECLINE),
NÃO DEVE REINICIALIZAR O INÍCIO) NÃO DEVE
(INFORMAR) NÃO DEVE (em (DHCPRELEASE)
BOUND ou
RENOVAÇÃO)
Tempo de locação de endereço IP pode maio não deve
(DESCOBRIR)
NÃO DEVE
(INFORMAR)
Use campos 'file' / 'sname' MAIO PODE MAIO
Tipo de mensagem DHCP DHCPDISCOVER / DHCPREQUEST DHCPDECLINE /
Identificador do cliente MAIO PODE MAIO
Identificador de classe de fornecedor PODE pode não
Identificador do servidor não deve deve (depois deve
SELECIONANDO)
NÃO DEVE (depois
INIT-REBOOT,
BOND, RENOVAÇÃO
ou REABINDING)
Lista de solicitação de parâmetro pode maio não deve
Tamanho máximo da mensagem PODE PODER NÃO DEVE
A mensagem NÃO DEVE NÃO SER
Site-específico pode maio não deve
Todos os outros podem maio não deve
Tabela 5: Campos e opções usados pelos clientes DHCP
Se os parâmetros forem aceitáveis, o cliente registrará o endereço

de
o servidor que forneceu os parâmetros do 'identificador do
servidor'
campo e envia esse endereço no campo 'identificador do servidor' de
um
Mensagem de difusão DHCPREQUEST. Uma vez que a mensagem DHCPACK do
servidor chega, o cliente é inicializado e se move para o estado
BOUND.
A mensagem DHCPREQUEST contém o mesmo 'xid' que o DHCPOFFER
mensagem. O cliente registra o vencimento da concessão como a soma
de
a hora em que o pedido original foi enviado e a duração do
a concessão da mensagem DHCPACK. O cliente DEVE executar um
verifique o endereço sugerido para garantir que o endereço não é
em uso. Por exemplo, se o cliente estiver em uma rede que
suporta o ARP, o cliente pode emitir uma solicitação ARP para o
pedido. Ao transmitir uma solicitação ARP para o endereço sugerido,
o cliente deve preencher seu próprio endereço de hardware como o
remetente
endereço de hardware, e 0 como o endereço IP do remetente, para
evitar
confundindo caches ARP em outros hosts na mesma sub-rede. Se o
endereço de rede parece estar em uso, o cliente DEVE enviar um

Mensagem DHCPDECLINE para o servidor. O cliente deve transmitir um
ARP
responder para anunciar o novo endereço IP do cliente e limpar
qualquer desatualizado
Entradas de cache ARP em hosts na sub-rede do cliente.
4.4.2 Inicialização com endereço de rede conhecido
O cliente começa no estado INIT-REBOOT e envia um DHCPREQUEST

mensagem. O cliente DEVE inserir seu endereço de rede conhecido
como
opção "endereço IP solicitado" na mensagem DHCPREQUEST. O cliente
pode solicitar parâmetros de configuração específicos, incluindo
opção 'lista de pedidos de parâmetros'. O cliente gera e registra
um
identificador de transação aleatória e insere esse identificador no
campo 'xid'. O cliente registra sua própria hora local para uso
posterior em
calcular a expiração da concessão. O cliente NÃO DEVE incluir um
'identificador do servidor' na mensagem DHCPREQUEST. O cliente
então
transmite o DHCPREQUEST no endereço de transmissão de hardware
local para
a porta UDP do 'servidor DHCP'.
Uma vez uma mensagem DHCPACK com um campo 'xid' correspondendo ao

campo
mensagem DHCPREQUEST do cliente chega de qualquer servidor, o
cliente é
inicializado e se move para o estado BOUND. O cliente registra a
concessão
tempo de expiração como a soma do tempo em que o DHCPREQUEST
mensagem foi enviada e a duração da concessão do DHCPACK
mensagem.
4.4.3 Inicialização com um endereço de rede atribuído externamente
O cliente envia uma mensagem DHCPINFORM. O cliente pode solicitar

parâmetros de configuração específicos incluindo a solicitação de
parâmetro
lista 'opção. O cliente gera e registra uma transação aleatória
identificador e insere esse identificador no campo 'xid'. o
O cliente coloca seu próprio endereço de rede no campo 'ciaddr'. o
O cliente NÃO DEVE solicitar parâmetros de tempo de concessão.
O cliente então unicasta o DHCPINFORM para o servidor DHCP se ele

sabe o endereço do servidor, caso contrário ele transmite a
mensagem para
o endereço de broadcast limitado (todos 1s). Mensagens DHCPINFORM
DEVEM ser
direcionado para a porta UDP do 'servidor DHCP'.
Uma vez uma mensagem DHCPACK com um campo 'xid' correspondendo ao

campo
mensagem DHCPINFORM do cliente chega de qualquer servidor, o
cliente é
inicializado.
Se o cliente não receber um DHCPACK dentro de um período razoável

de tempo (60 segundos ou 4 tentativas se usar o tempo limite
sugerido na seção
4.1), então deve mostrar uma mensagem informando ao usuário do
problema, e então deve começar o processamento de rede usando
adequado
padrões de acordo com o Apêndice A.
4.4.4 Uso de broadcast e unicast
O cliente DHCP transmite DHCPDISCOVER, DHCPREQUEST e DHCPINFORM

mensagens, a menos que o cliente saiba o endereço de um servidor
DHCP. o
cliente unicasts DHCPRELEASE mensagens para o servidor. Porque o
o cliente está recusando o uso do endereço IP fornecido pelo
servidor,
o cliente transmite mensagens DHCPDECLINE.
Quando o cliente DHCP conhece o endereço de um servidor DHCP, em

INIT ou REBOOTING, o cliente pode usar esse endereço no
DHCPDISCOVER ou DHCPREQUEST em vez do endereço de transmissão IP.
O cliente também pode usar unicast para enviar mensagens DHCPINFORM
para um
servidor DHCP conhecido. Se o cliente não receber resposta ao DHCP
mensagens enviadas para o endereço IP de um servidor DHCP
conhecido, o DHCP
cliente reverte para usar o endereço de transmissão IP.
4.4.5 Reaquisição e expiração
O cliente mantém duas vezes, T1 e T2, que especificam os horários

em
que o cliente tenta estender sua concessão em seu endereço de rede.
T1 é a hora em que o cliente entra no estado RENOVAÇÃO e
tenta entrar em contato com o servidor que originalmente emitiu o
cliente
Endereço de rede. T2 é a hora em que o cliente entra no
REABINDING estado e tenta entrar em contato com qualquer servidor.
T1 DEVE ser
antes de T2, que, por sua vez, DEVE ser mais cedo que a hora
qual a concessão do cliente expirará.
Para evitar a necessidade de relógios sincronizados, T1 e T2 são

expressos em
opções como tempos relativos [2].
No momento T1, o cliente se move para o estado RENOVANDO e envia

(via unicast)
uma mensagem DHCPREQUEST para o servidor estender sua concessão. O
cliente
define o campo 'ciaddr' no DHCPREQUEST para sua rede atual
endereço. O cliente registra a hora local em que o DHCPREQUEST
mensagem é enviada para cálculo do tempo de expiração da concessão.
o
O cliente NÃO DEVE incluir um 'identificador de servidor' no
DHCPREQUEST
mensagem.
Qualquer mensagem DHCPACK que chegue com um 'xid' que não

corresponda
o 'xid' da mensagem DHCPREQUEST do cliente é descartado
silenciosamente.
Quando o cliente recebe um DHCPACK do servidor, o cliente
calcula o tempo de expiração da concessão como a soma do tempo em
que
o cliente enviou a mensagem DHCPREQUEST e a duração da concessão
na mensagem DHCPACK. O cliente readquiriu com sucesso seu
endereço de rede, retorna ao estado BOUND e pode continuar
em processamento.
Se nenhum DHCPACK chegar antes do horário T2, o cliente passará

para REABINDING
estado e envia (via transmissão) uma mensagem DHCPREQUEST para
estender sua
de concessão. O cliente define o campo 'ciaddr' no DHCPREQUEST para
o seu
endereço de rede atual. O cliente NÃO DEVE incluir um 'servidor
identificador 'na mensagem DHCPREQUEST.
Times T1 e T2 são configuráveis pelo servidor através de opções. T1

O padrão é (0.5 * duration_of_lease). O padrão do T2 é (0.875 *
duration_of_lease). Tempos T1 e T2 devem ser escolhidos com alguma
aleatório "fuzz" em torno de um valor fixo, para evitar a
sincronização de
reaquisição de clientes.
Um cliente pode optar por renovar ou estender seu contrato antes de

T1. o
servidor pode optar por estender a concessão do cliente de acordo
com a política
definido pelo administrador da rede. O servidor deve retornar T1 e
T2, e seus valores DEVEM ser ajustados de seus valores originais
para
ter em conta o tempo restante no contrato.
Nos estados RENEWING e REBINDING, se o cliente não receber

resposta à sua mensagem DHCPREQUEST, o cliente DEVE esperar metade
do tempo restante até T2 (no estado RENOVAÇÃO) e metade do tempo
o tempo de locação restante (no estado REBINDING), até um mínimo de
60 segundos, antes de retransmitir a mensagem DHCPREQUEST.
Se a concessão expirar antes do cliente receber um DHCPACK, o

cliente
move-se para o estado INIT, DEVE parar imediatamente qualquer outra
rede
processamento e solicita parâmetros de inicialização de rede como
se o
cliente não foram inicializados. Se o cliente receber um DHCPACK
alocando a esse cliente seu endereço de rede anterior, o cliente
DEVE continuar o processamento de rede. Se o cliente receber uma
nova
endereço de rede, NÃO DEVE continuar a utilizar a rede anterior
endereço e deve notificar os usuários locais do problema.
4.4.6 DHCPRELEASE
Se o cliente não precisar mais usar seu endereço de rede atribuído

(por exemplo, o cliente é encerrado normalmente), o cliente envia
um
DHCPRELEASE mensagem para o servidor. Observe que a operação
correta
de DHCP não depende da transmissão de mensagens DHCPRELEASE.
5. Agradecimentos
O autor agradece aos muitos (e numerosos demais para mencionar!)

o DHC WG por seus incansáveis e contínuos esforços no
desenvolvimento
de DHCP e este documento.
Os esforços de J Allard, Mike Carney, Dave Lapp, Fred Lien e John

Mendonca na organização de sessões de teste de interoperabilidade
DHCP são
gratamente reconhecido.
O desenvolvimento deste documento foi apoiado em parte por doações
de
a Corporação para Iniciativas Nacionais de Pesquisa (CNRI),
Bucknell
Universidade e Sun Microsystems.
6. Referências
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU,

dezembro
1983.
[2] Alexander, S. e R. Droms, "Opções DHCP e o Fornecedor BOOTP

Extensões ", RFC 1533, Lachman Technology, Inc., Bucknell
University, outubro de 1993.
[3] Braden, R., Editor, "Requisitos para Hosts da Internet -

Camadas de Comunicação ", STD 3, RFC 1122, USC / Ciências da
Informação
Instituto, outubro de 1989.
[4] Braden, R., Editor, "Requisitos para Hosts da Internet -

Aplicação e Suporte, STD 3, RFC 1123, USC / Information
Instituto de Ciências, outubro de 1989.
[5] Brownell, D, "Protocolo de Resolução de Endereço Reverso

Dinâmico
(DRARP) ", trabalho em andamento.
[6] Comer, D. e R. Droms, "Acesso Uniforme ao Diretório da Internet

Serviços ", Proc. De ACM SIGCOMM '90 (edição especial da
Computer
Communications Review), 20 (4): 50--59, 1990.
[7] Croft, B. e J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,

Stanford e SUN Microsystems, setembro de 1985.
[8] Deering, S., "Mensagens de Descoberta do Roteador ICMP", RFC

1256, Xerox
PARC, setembro de 1991.
[9] Droms, D., "Interoperação entre DHCP e BOOTP", RFC 1534,

Bucknell University, outubro de 1993.
[10] Finlayson, R., Mann, T., Mogul, J. e M. Theimer, "A Reverse

Protocolo de Resolução de Endereços ", RFC 903, Stanford,
junho de 1984.
[11] Gray C. e D. Cheriton, "Locações: um eficiente tolerante a

falhas
Mecanismo de consistência do cache de arquivos distribuídos ",
em Proc.
o Décimo Segundo Simpósio ACM sobre Design de Sistemas
Operacionais, 1989.
[12] Mockapetris, P., "Nomes de domínio - conceitos e instalações",

STD
13, RFC 1034, USC / Information Sciences Institute, novembro
de 1987.
[13] Mockapetris, P., "Nomes de Domínio - Implementação e

Especificação ", STD 13, RFC 1035, USC / Ciências da
Informação
Instituto, novembro de 1987.
[14] Mogul J. e S. Deering, "Path MTU Discovery", RFC 1191,

Novembro de 1990.
[15] Morgan, R., "Atribuição de endereço IP dinâmico para Ethernet

anexada
Hosts ", trabalho em andamento.
[16] Postel, J., "Protocolo de Mensagens de Controle da Internet",

STD 5, RFC 792,
USC / Information Sciences Institute, setembro de 1981.
[17] Reynolds, J., "Extensões de informação do fornecedor BOOTP",

RFC 1497,
USC / Information Sciences Institute, agosto de 1993.
[18] Reynolds, J. e J. Postel, "Assigned Numbers", STD 2, RFC 1700,

USC / Information Sciences Institute, outubro de 1994.
[19] Jeffrey Schiller e Mark Rosenstein. Um protocolo para o

dinâmico
Atribuição de endereços IP para uso em uma Ethernet.
(Acessível
do Projeto Athena, MIT), 1989.
[20] Sollins, K., "Protocolo TFTP (Revisão 2)", RFC 783, NIC,
Junho de 1981.
[21] Wimer, W., "Esclarecimentos e Extensões para o Bootstrap

Protocolo ", RFC 1542, Carnegie Mellon University, outubro de
1993.
7. Considerações de segurança
O DHCP é construído diretamente em UDP e IP, que ainda são

inerentemente
inseguro. Além disso, o DHCP é geralmente destinado a
manutenção de hosts remotos e / ou sem disco. Enquanto talvez
impossível, configurar esses hosts com senhas ou chaves pode ser
difícil e inconveniente. Portanto, DHCP em sua forma atual é
bastante inseguro.

Servidores DHCP não autorizados podem ser facilmente configurados.
Esses servidores podem
em seguida, envie informações falsas e potencialmente perturbadoras
para os clientes
como endereços IP incorretos ou duplicados, roteamento incorreto
informações (incluindo roteadores falsificados, etc.), domínio
incorreto
endereços de servidores de nomes (como servidores de nomes
falsificados) e assim por diante.
Claramente, uma vez que esta informação de semente está no lugar,
um atacante pode
comprometer ainda mais os sistemas afetados.
Clientes DHCP maliciosos podem se mascarar como clientes legítimos

e
recuperar informações destinadas a esses clientes legítimos. Onde
alocação dinâmica de recursos é usada, um cliente mal-intencionado
reivindicar todos os recursos para si, negando recursos para
clientes legítimos.
8. Endereço do Autor
Ralph Droms
Departamento de Ciência da Computação
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Telefone: (717) 524-1145

EMail: droms@bucknell.edu

A. Parâmetros de Configuração do Host
IP-layer_parameters, _per_host: _
Seja um roteador ligado / desligado HRC 3.1

Roteamento de origem não local ligado / desligado HRC 3.3.5
Filtros de política para
roteamento de origem não local (lista) HRC 3.3.5
Tamanho máximo da remontagem inteiro HRC 3.3.2
Padrão TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
Tabela de planalto MTU (lista) MTU 7
IP-layer_parameters, _per_interface: _
Endereço IP (endereço) HRC 3.3.1.6
Máscara de sub-rede (máscara de endereço) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on / off HRC 3.3.3
Sabor do endereço de transmissão 0x00000000 / 0xffffffff HRC 3.3.6
Realizar a detecção de máscara on / off HRC 3.2.2.9
Seja um fornecedor de máscara ligado / desligado HRC 3.2.2.9
Executar a detecção do roteador on / off RD 5.1
Endereço de solicitação do roteador (endereço) RD 5.1
Roteadores padrão, lista de:
endereço do roteador (endereço) HRC 3.3.1.6
nível de preferência inteiro HRC 3.3.1.6
Rotas estáticas, lista de:
destino (host / sub-rede / rede) HRC 3.3.1.2
máscara de destino (máscara de endereço) HRC 3.3.1.2
número inteiro do tipo de serviço HRC 3.3.1.2
roteador de primeiro salto (endereço) HRC 3.3.1.2
ignorar redirecionamentos on / off HRC 3.3.1.2
MTT inteiro MTU 6.6
realizar detecção de PMTU on / off MTU 6.6
Link-layer_parameters, _per_interface: _
Trailers on / off HRC 2.3.1
Tempo limite do tempo limite do cache do ARP HRC 2.3.2.1
Encapsulamento Ethernet (RFC 894 / RFC 1042) HRC 2.3.3
TCP_parameters, _per_host: _
TTL inteiro HRC 4.2.2.19
Intervalo de keep-alive inteiro HRC 4.2.3.6
Tamanho de dados de vida útil 0/1 HRC 4.2.3.6
Chave:
MTU = Path MTU Discovery (RFC 1191, Proposta Padrão)

RD = Descoberta de Roteador (RFC 1256, Proposta Padrão)

Rede Grupo de Trabalho HDCP - 1997

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Rede Grupo de Trabalho HDCP - 1997

Caricato da

Copyright:

Formati disponibili

Protocolo de configuração dinâmica de hosts

Status deste memorando

Este documento especifica um protocolo de rastreamento de padrões

O protocolo DHCP (Dynamic Host Configuration Protocol) fornece uma

Droms Standards Track [Página 1]

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

4.1 Construindo e enviando mensagens DHCP. . . . . . . . . . . . 22

O protocolo DHCP (Dynamic Host Configuration Protocol) fornece

O DHCP é construído em um modelo cliente-servidor, onde o servidor

Droms Standards Track [Página 2]

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

mecanismo para a descoberta de endereços que já estão em uso. IP

O DHCP suporta três mecanismos para alocação de endereços IP. Em

A alocação dinâmica é o único dos três mecanismos que

O formato das mensagens DHCP é baseado no formato das mensagens

1.1 Mudanças na RFC 1541

Este documento atualiza a especificação do protocolo DHCP que

Droms Standards Track [Página 3]

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

1.2 Trabalho Relacionado

Existem vários protocolos da Internet e mecanismos relacionados que

O BOOTP é um mecanismo de transporte para uma coleção de

Em outro trabalho relacionado, a unidade de transmissão mínima

1.3 Definição e problemas do problema

DHCP é projetado para fornecer clientes DHCP com a configuração

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

Nem todos esses parâmetros são necessários para uma inicialização

DHCP permite, mas não requer a configuração do cliente

O DHCP não se destina a uso na configuração de roteadores.

Ao longo deste documento, as palavras usadas para definir o

Esta palavra ou o adjetivo "REQUERIDO" significa que o

Esta frase significa que o item é uma proibição absoluta

Esta palavra ou o adjetivo "RECOMENDADO" significa que há

Esta frase significa que podem existir razões válidas em

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

Esta palavra ou o adjetivo "OPCIONAL" significa que este item

Este documento usa os seguintes termos:

Um cliente DHCP é um host da Internet que usa DHCP para obter

Um servidor DHCP é um host da Internet que retorna a

o "agente de retransmissão BOOTP"

Um agente de retransmissão BOOTP ou agente de retransmissão é um

Uma ligação é uma coleção de parâmetros de configuração,

1.6 Objetivos do design

A lista a seguir fornece metas gerais de design para o DHCP.

O DHCP deve ser um mecanismo e não uma política. DHCP deve

Droms Standards Track [Página 6]

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

o Os clientes não devem exigir configuração manual. Cada cliente

o Redes não devem requerer configuração manual para

o DHCP não deve exigir um servidor em cada sub-rede. Para

o Um cliente DHCP deve estar preparado para receber várias

o DHCP deve coexistir com dados estaticamente configurados, não

o DHCP deve interoperar com o comportamento do agente de

o DHCP deve fornecer serviço para clientes BOOTP existentes.

A lista a seguir apresenta metas de design específicas para a

o Garantir que qualquer endereço de rede específico não esteja

o Reter a configuração do cliente DHCP na reinicialização do

o Reter a configuração do cliente DHCP nas reinicializações do

o Permitir atribuição automática de parâmetros de configuração

o Suporte a alocação fixa ou permanente de configuração

Droms Standards Track [Página 7]

Protocolo de configuração de host dinâmico RFC 2131, março de 1997

Do ponto de vista do cliente, o DHCP é uma extensão do BOOTP