BOOTP - Bootstrap Protocol

• Trabalha na camada de aplicação, usando serviços de transporte UDP, logo não é dependente de implementações no sistema operacional.
• Oferece informações complementares e é expansível.
• Para simplificar a operação, todos os campos de dados no pacote possuem tamanho fixo.
• Em caso de erro, o cliente é responsável pela operação de retry.
  • Quando falta energia em uma rede, na ocasião de seu retorno todas as máquinas começam a rebootar automaticamente. Para evitar o excesso de erros por colisão de tentativas nesta situação, deve ser usado um algoritmo semelhante ao Exponential Backoff, usado na rede ethernet.
• Para evitar que processos servidores recebam desnecessariamente os pacotes de resposta de outros servidores, são usadas duas portas UDP diferentes entre o pedido e a resposta. O servidor recebe o pedido na porta 67 e responde na porta 68.
• O BOOTP não oferece o arquivo de Bootstrap, mas apenas a sua localização.
  • Para carregar este arquivo, deve ser utilizado um outro protocolo, de transferência de arquivos.
  • Em geral, se usa TFTP (RFCs 783 e 906), mas pode ser usado também o SFTP (RFC 913), ou mesmo o FTP (RFC 959 e outras).

Formato do pacote BOOTP

struct BOOTP {
    int8  Operation;
    int8  HardwareType;
    int8  HardwareLen;
    int8  Hops;
    int32 TransactionID;
    int16 Seconds;
    int16 Unused;       /*  Para alinhar os dados no pacote  */
    int32 ClientIpAddr;
    int32 YourIpAddr;
    int32 ServerIpAddr;
    int32 GatewayIpAddr;
    int8  ClientHardwareAddr[ 16 ];
    char  ServerHostName[ 64 ];
    char  BootFileName[ 128 ];
    int8  VendorSpecificArea[ 64 ];
} PacketData;

• Operation: Código da operação, Pedido ou Resposta. Poderia ser detectado pela porta UDP usada, mas um pouco de redundância de dados nunca faz mal, e neste caso, simplifica o processamento.
• Hardware Type: Identifica o tipo da rede física.
• Hardware Length: Informa o comprimento utilizado do campo de endereço físico.
• Hops: Inicializado com o valor 0, pode ser usado para limitar o número de retransmissões através de BOOTP redirects.
• Transaction ID: Identificador da transação. O servidor deve repetir em sua resposta este valor, gerado aleatoriamente pelo cliente. É uma forma de garantir que um cliente não vai receber a resposta de outro.
• Seconds: Número de segundos desde que o cliente começou o processo de pedidos BOOTP. Pode ser usado na implementação de servidores secundários, que só respondem depois de algum tempo, caso um servidor primário não tenha ainda respondido.
• Unused: Colocado apenas para garantir que os campos com endereços IP vão estar alinhados em endereços múltiplos de 4. Isso facilita a operação em máquinas de 32 bits.
• Client IP Addr: Endereço IP do Cliente, preenchido pelo próprio, caso seja conhecido de antemão. Facilita a operação do servidor e pode ser usado em chamadas secundárias ao serviço de BOOTP, para pegar mais parâmetros do campo Vendor Specific
• Your IP Addr: Endereço IP do cliente, preenchido pelo Servidor na operação de resposta.
• Server IP Addr: Endereço IP do servidor de Bootstrap. Poderia ser obtido via DNS, mas nem sempre isto é possível. Note-se que este endereço não é necessariamente o mesmo do servidor BOOTP
• Gateway IP Addr: Endereço do roteador a ser usado durante a operação de bootstrap. Evita que o cliente tenha que conhecer algoritmos de roteamento neste instante.
• Client Hardware Addr: Endereço físico do cliente. Campo de preenchimento obrigatório pelo cliente, usado como chave primária na maioria das buscas em tabela no servidor.
• Server Host Name: Nome do servidor. Campo opcionalmente preenchido pelo servidor. Pode também ser usado pelo cliente para sugerir uma opção ao servidor BOOTP, que poderá ou não aceitar a dica.
• Boot File Name: Nome do arquivo que deve ser carregado no bootpstrap. Preenchido pelo servidor, mas pode ser usado pelo cliente para sugerir um sistema operacional a ser utilizado. Em geral se usam nomes genéricos, como "unix", "router", "selftest", etc.
• Vendor Specific Area: Usado opcionalmente para se colocar dados de extensão do protocolo. Como em geral estes dados são definidos pelo fabricante de um produto, este campo ficou conhecido como campo de informação dependente do fabricante.

Informação dependente do fabricante

• Netmask
• Horário de GMT (Universal Time)
• Roteadores da SubRede
• Hostname do Cliente
• Tamanho do arquivo de Boot
• Endereços de servidores de:
  • Tempo (RDATE e/ou TIMED)
  • Domínio (DNS)
  • Log (SYSLOGD)
  • Impressão (LPD)

Comentários sobre o BOOTP

• Exemplo de sistemas que usam o BOOTP durante o Bootstrap:
  • NCSA Telnet. Quando configurado com bootp, é necessário menos informação inicial em seu arquivo de configuração. Isso simplifica muito a sua utilização em ambientes de rede cliente/servidor.
  • MS-Windows Sockets, várias implementações.
  • HP JetDirect Printer Server
• Por ser um protocolo mais completo, é o preferencial em novas aplicações. A comunidade de micros, apenas recentemente inserida no meio internet, usa muito este protocolo.
• Problemas: Oficialmente, não permite o uso de endereços temporários (dinâmicos), muito úteis em redes com muitos micros e poucos endereços IP livres.
• Recentemente surgiu o DHCP (RFCs 1533 e 1534), como um melhorador do BOOTP.
  • Permite o uso de endereços IP temporários.
  • Utilizado pelo MS-Windows NT e 95, em suas configurações default.