Provided by: manpages-pt_20040726-4_all 
NOME
ip - Implementação do protocolo IPv4 em Linux
SINOPSE
#include <sys/socket.h>
#include <net/netinet.h>
tcp_socket = socket(PF_INET, SOCK_STREAM, 0);
raw_socket = socket(PF_INET, SOCK_RAW, protocol);
udp_socket = socket(PF_INET, SOCK_DGRAM, protocol);
DESCRIÇÃO
Linux implementa o Protocolo Internet (IP), versão 4, descrito nas RFC791 e RFC1122. ip
contém uma implementação de multicasting de nível 2, conforme a RFC1112. Ele também
contém um roteador IP que inclui um filtro de pacotes.
A interface do programador é compatível com sockets BSD. Para maiores informações sobre
sockets, veja socket(7).
Um socket IP é criado ao se chamar a função socket(2) no formato socket(PF_INET,
socket_type, protocol). Tipos válidos de sockets são SOCK_STREAM para abrir um socket
tcp(7) , SOCK_DGRAM para abrir um socket udp(7) , ou SOCK_RAW para abrir um socket raw(7)
para acessar o protocolo IP protocol diretamente. protocol é o protocolo IP no header IP
a ser recebido ou enviado. Os únicos valores válidos para protocol são 0 e IPPROTO_TCP
para sockets TCP, e 0 e IPPROTO_UDP para sockets UDP. Para SOCK_RAW Você deve especificar
um protocolo IP IANA válido, definido nos números atribuídos na RFC1700.
Quando um processo quer receber novos pacotes ou conexões de entrada, ele deveria ligar um
socket a um endereço local de interface, usando bind(2). Somente um socket IP pode ser
ligado a qualquer par (endereço, porta) local dado. Quando INADDR_ANY é especificado na
chamada 'bind' , o socket será ligado a todas as interfaces locais. Quando listen(2) ou
connect(2) são chamados sobre um socket não ligado, o socket é automaticalmente ligado a
uma porta livre aleatória, com o endereço local setado em INADDR_ANY.
Um endereço de socket TCP local que tenha sido ligado é indisponível por algum tempo
depois do fechamento, a menos que o flag SO_REUSEADDR tenha sido setado. Deve-se tomar
cuidado quando se usa este flag, pois ele torna o TCP menos reliable.
FORMATO DE ENDEREÇO
Um endereço de socket IP é definido como uma combinação de um endereço de interface IP e
um número de porta. O protocolo IP básico não suporta número de portas, elas são
implementadas por protocolos de nível mais alto, como udp(7) e tcp(7). Em sockets
diretos, sin_port é setado para o protocolo IP.
struct sockaddr_in {
sa_family_t sin_family; /* família de endereço: AF_INET */
u_int16_t sin_port; /* porta na ordem de byte da rede */
struct in_addr sin_addr; /* endereço internet */
};
/* Endereço internet. */
struct in_addr {
u_int32_t s_addr; /* endereço na ordem de byte da rede */
};
sin_family é sempre selecionado para AF_INET. Este é requerido; em Linux 2.2, muitas
funções de rede retornam EINVAL quando esta configuração está faltando. sin_port contém a
porta em ordem de byte da rede. Os números de porta abaixo de 1024 são chamados de portas
reservadas. Somente processos com id efetivo de usuário 0 ou a capabilidade
CAP_NET_BIND_SERVICE podem fazer o bind(2) nesses sockets. Note que o protocolo IPv4
direto, como tal, não possui nenhum conceito de porta, elas somente são implementadas por
protocolos superiores, como o tcp(7) e o udp(7).
sin_addr é o endereço IP do host. O membro addr de struct in_addr contém o endereço de
interface do host na ordem de rede. in_addr só deveria ser acessada usando-se as funções
de biblioteca inet_aton(3), inet_addr(3), inet_makeaddr(3) , ou diretamente com o
resolvedor de nomes (veja gethostbyname(3)). Os endereços IPv4 são divididos em unicast,
broadcast e multicast. Endereços de unicast especificam uma interface única de um host,
endereços de broadcast especificam todos os hosts de uma rede, e endereços de multicast
endereçam todos os hosts em um grupo de multicast. Datagramas dirigidos a endereços de
broadcast só podem ser enviados ou recebidos quando um sinalizador de socket SO_BROADCAST
está selecionado. Na implementação corrente, sockets orientados a conexão somente têm
permissão para usar endereços de unicast.
Note que o endereço e a porta são sempre armazenados na ordem da rede. Em particular,
isto significa que você precisa chamar htons(3) sobre o número que é atribuído a uma
porta. Todas as funções de manipulação de endereço/porta na biblioteca padrão funcionam na
ordem da rede.
Há vários endereços especiais: INADDR_LOOPBACK (127.0.0.1) sempre se refere ao host local
via dispositivo de loopback; INADDR_ANY (0.0.0.0) significa qualquer endereço para
conexão; INADDR_BROADCAST (255.255.255.255) significa qualquer host e tem o mesmo efeito,
em uma conexão, que o INADDR_ANY por razões históricas.
OPÇÕES DE SOCKETS
O IP suporta algumas opções de socket específicos de protocolo, que podem ser selecionado
com setsockopt(2) e lidas com getsockopt(2). O nível de opção de socket para IP é SOL_IP.
Um sinalizador inteiro para booleano é zero quando é falso, e em caso contrário é
verdadeiro.
IP_OPTIONS
Seta ou obtém as opções de IP a serem enviadas com cada pacote deste socket. Os
argumentos são um ponteiro para um buffer de memória que contém as opções, e o
comprimento da opção. A chamada setsockopt(2) seta as opções de IP associadas com
o socket. O máximo tamanho de opção para IPv4 é 40 bytes. Consulte RFC791 para ver
as opções permitidas. Quando o pacote inicial de requisição de conexão para um
socket SOCK_STREAM contém opções de IP, as opções de IP serão setadas
automaticamente para as opções do pacote inicial, com os headers de roteamento
revertido. Pacotes entrantes não têm permissão de mudar opções depois que a
conexão é estabelecida. O processamento de todas as opções entrantes de roteamento
da fonte é desabilitada por default, e pode ser habilitada pelo uso do sysctl
accept_source_route Para sockets de datagramas, as opções de IP só podem ser
setadas pelo usuário local. Chamando-se getsockopt(2) com IP_OPTIONS põe-se as
opções de IP correntes, usadas para envio, no buffer fornecido.
IP_PKTINFO
Passa uma mensagem ancilar IP_PKTINFO que contém uma estrutura pktinfo , que
fornece algumas informações sobre o pacote entrante. Isto só funciona para sockets
orientados a datagramas.
struct in_pktinfo
{
unsigned int ipi_ifindex; /* índice da interface */
struct in_addr ipi_spec_dst; /* endereço de destino do roteamento */
struct in_addr ipi_addr; /* endereço do Destino do Header */
};
ipi_ifindex é o único índice da interface onde o pacote foi recebido. ipi_spec_dst
é o endereço de destino da entrada da tabela de roteamento e ipi_addr é o endereço
de destino no cabeçalho do pacote. Se IP_PKTINFO é passado para sendmsg(2) então o
pacote de saída será enviado sobre a interface especificada em ipi_ifindex , com o
endereço de destino setado em ipi_spec_dst.
IP_RECVTOS
Se habilitado, a mensagem ancilar IP_TOS é passada com pacotes entrantes. Ele
contém um byte que especifica o campo "Tipo de Serviço/Precedência" do cabeçalho do
pacote. Espera um flag booleano inteiro.
IP_RECVTTL
Quando este flag é setado, passa uma mensagem de controle IP_RECVTTL com o campo
"time to live" do pacote recebido como um byte. Não é suportado para sockets
SOCK_STREAM
IP_RECVOPTS
Passa todas as opções de IP entrantes para o usuário em uma mensagem de controle
IP_OPTIONS. O header de roteamento e outras opções já são preenchidas para o host
local. Não é suportado para sockets SOCK_STREAM
IP_RETOPTS
Idêntico a IP_RECVOPTS , mas retorna opções diretas não processadas, com opções de
timestamp e registro de rota não preenchidos para este hop.
IP_TOS Seleciona ou recebe o campo Tipo-de-Serviço (Tipo-Of-Service - TOS), que é enviado
com todos os pacotes IP originados deste socket. Ele é usado para priorizar pacotes
na rede. TOS é um byte. Há alguns padrões de flags TOS definidos: IPTOS_LOWDELAY
para minimizar delays para tráfego interativo, IPTOS_THROUGHPUT para otimizar o
fluxo, IPTOS_RELIABILITY para otimizar a reliability, IPTOS_MINCOST deveria ser
usado como "dado preenchedor" onde transmissões lentas não causam problemas. No
máximo um desses valores de TOS podem ser especificados. Outros bits são inválidos
e serão zerados. Linux envia datagramas IPTOS_LOWDELAY primeiro por default, mas o
comportamento exato depende da disciplina de fila configurada. Alguns níveis de
alta prioridade podem requerer um id efetivo de usuário 0 ou a capabilidade
CAP_NET_ADMIN. A prioridade também pode ser setada de maneira independente de
protocolo, pela opção de socket ( SOL_SOCKET, SO_PRIORITY ) (veja socket(7) ).
IP_TTL Seta ou recupera o campo "time to live" corrente, que é enviado em todos os pacotes
originados neste socket.
IP_HDRINCL
Se habilitado, o usuário fornece um header ip na frente dos dados. Somente válido
para sockets SOCK_RAW. Veja raw(7) para mais informação. Quando este flag é
habilitado, os valores setados por IP_OPTIONS, IP_TTL e IP_TOS são ignorados.
IP_RECVERR
Habilita a passagem estendida e confiável de mensagens de erro. Quando habilitado
sobre um socket de datagrama, todos os erros gerados serão enfileirados em uma fila
de erros por-socket. Quando o usuário recebe um erro de uma operação de socket, os
erros podem ser recebidos chamando-se recvmsg(2) com o sinalizador MSG_ERRQUEUE
selecionado. A estrutura sock_extended_err descrevendo o erro será analisada em uma
mensagem ancilar, com o tipo IP_RECVERR e o nível SOL_IP. Isto é útil para
manipulação confiável de erros ou sockets desconectados. A parte dos dados
recebidos a partir da fila de erros contém o pacote de erro.
IP usa a estrutura sock_extended_err como segue: ee_origin é setado em
SO_EE_ORIGIN_ICMP para erros recebidos como um pacote ICMP, ou SO_EE_ORIGIN_LOCAL
para erros gerados localmente. ee_type e ee_code são setados para os campos "tipo"
e "código" do header ICMP. ee_info contém o MTU descoberto para EMSGSIZE erros.
ee_data não é usado atualmente. Quando o erro originou-se na rede, todas as opções
de IP (IP_OPTIONS, IP_TTL, etc.) habilitadas no socket e contidas no pacote de erro
são passadas como mensagens de controle. O "payload" do pacote que causou o erro é
retornado como dado normal.
Em sockets SOCK_STREAM , IP_RECVERR tem semânticas ligeiramente diferentes. Em vez
de gravar os erros para o próximo timeout, ele passa todos os erros entrantes
imediatamente para o usuário. Isto pode ser útil para conexões TCP muito curtas,
que precisam de uma manipulação de erros rápida. Use esta opção com cuidado: ela
torna o TCP não confiável, ao não permitir que ele se recupere propriamente de
deslocamento de roteamento, e outras condições e quebras normais da especificação
do protocolo. Note que TCP não tem fila de erro; MSG_ERRQUEUE é ilegal em sockets
SOCK_STREAM Portanto todos os erros são retornados pelo retorno de função do socket
ou SO_ERROR apenas.
Para sockets diretos, IP_RECVERR habilita a passagem para o aplicativo de todos os
erros ICMP recebidos, caso contrário os erros serão relatados apenas nos sockets
conectados.
Ele seta ou recupera um flag booleano inteiro. IP_RECVERR é desligado, por padrão.
IP_PMTU_DISCOVER
Seta ou recupera a configuração do Path MTU Discovery para um socket. Quando
habilitado, o Linux realiza o Path MTU Discovery neste socket como é definido na
RFC1191. O sinalizador de não fragmentação é selecionado em todos os datagramas de
saída. O padrão geral do sistema é controlado pelo sysctl ip_no_pmtu_disc para
sockets SOCK_STREAM , e desabilitado para todos os outros. Para sockets que não são
SOCK_STREAM , é responsabilidade do usuário empacotar os dados em blocos grandes,
de tamanho igual ao MTU e fazer a retransmissão, se necessário. O kernel rejeitará
pacotes que sejam maiores que o MTU da rota conhecida, se este flag é setada (com
EMSGSIZE ).
Flags do Path MTU Discovery Significado
IP_PMTUDISC_WANT Usa configurações por-rota.
IP_PMTUDISC_DONT Nunca executa Path MTU Discovery.
IP_PMTUDISC_DO Sempre executa Path MTU Discovery.
Quando o PMTU discovery está habilitado, o kernel automaticamente guarda as
informações do Path MTU por host de destino. Quando ele é conectado a um peer
específico com connect(2) , o PMTU conhecido atualmente pode ser recuperado
convenientemente usando-se a opção de socket IP_MTU (por exemplo, depois da
ocorrência de um erro EMSGSIZE ). Isso pode mudar com o tempo. Para sockets sem
conexão com muitos destinos, o novo also MTU para um dado destino também pode ser
acessado usando-se a fila de erros (veja IP_RECVERR). Um novo erro será
enfileirado em toda atualização de MTU de entrada.
Enquanto o MTU Discovery está em progresso, os pacotes iniciais de sockets de
datagramas podem ser perdidos. Aplicativos usando UDP devem ser alertados sobre
isso, e não levar isso em conta pera a estratégia de retransmissão de pacotes.
Para bootstrap o processo de path MTU discovery em sockets não conectados, é
possível iniciar com um tamanho de datagrama grande (de até 64K-headers bytes de
comprimento) e deixá-lo encolher pelas atualizações do MTU da rota.
Para conseguir uma estimativa inicial do PMTU, conecte um socket de datagrama a um
endereço de destino usando connect(2) e recupere o MTU chamando getsockopt(2) com a
opção IP_MTU
IP_MTU Recupera o PMTU atual do socket corrente. Somente válido quando o socket está
conectado. Retorna um inteiro. Somente válido como um getsockopt(2).
IP_ROUTER_ALERT
Passa todos os pacotes "a serem encaminhados" com a opção "Alerta de Roteador IP"
selecionada para este socket. Somente válido para sockets diretos. Isto é útil, por
enquanto, para daemons RSVP do espaço do usuário. Os pacotes mandados não são
encaminhados pelo kernel, é responsabilidade do usuário enviá-los novamente. A
ligação do socket é ignorada, tais pacotes são apenas filtrados pelo protocolo.
Espera um sinalizador inteiro.
IP_MULTICAST_TTL
Seta ou lê o valor de "time-to-live" de pacotes de multicast de saída para este
socket. É muito importante para pacotes multicast que seja setado o menor TTL
possível. O padrão é 1, o que significa que pacotes multicast não saem da rede
local a menos que o programa do usuário o requeira explicitamente. O argumento é um
inteiro.
IP_MULTICAST_LOOP
Seta ou lê um argumento booleano inteiro se pacotes de multicast enviados deveriam
ser retornados por meio de "loop back" para os sockets locais.
IP_ADD_MEMBERSHIP
Integra a um grupo de multicast. O argumento é uma estrutura struct ip_mreqn
struct ip_mreqn
{
struct in_addr imr_multiaddr; /* endereço IP de grupo de multicast */
struct in_addr imr_address; /* endereço IP da interface local */
int imr_ifindex; /* índice da interface */
};
imr_multiaddr contém o endereço do grupo de multicast com que a aplicação quer se
ligar ou deixar. Deve ser um endereço de multicast válido. imr_address é o
endereço da interface local com o qual o sistema deveria se unir ao grupo de
multicast; se for igual a INADDR_ANY , uma interface apropriada é escolhida pelo
sistema. imr_ifindex é um índice da interface que vai agregar/abandonar o grupo
imr_multiaddr , ou 0 para indicar qualquer interface.
Por questão de contabilidade, a antiga estrutura ip_mreq ainda é suportada. Ela
difere de ip_mreqn somente pela não inclusão do campo imr_ifindex. Somente válido
como um setsockopt(2).
IP_DROP_MEMBERSHIP
Abandona um grupo de multicast. O argumento é uma estrutura ip_mreqn ou ip_mreq ,
similar a IP_ADD_MEMBERSHIP.
IP_MULTICAST_IF
Seta o dispositivo local para um socket multicast. O argumento é uma estrutura
ip_mreqn ou ip_mreq , similar a IP_ADD_MEMBERSHIP.
Quando é passada uma opção inválida de socket, ENOPROTOOPT é retornado.
SYSCTLS
O protocolo IP suporta que a interface sysctl configure algumas opções globais. Os
sysctls podem ser acessados pela leitura ou escrita dos arquivos /proc/sys/net/ipv4/* , ou
usando a interface sysctl(2)
ip_default_ttl
Seta o valor default do "time-to-live" para pacotes de saída. Isso pode ser
alterado para cada socket, com a opção IP_TTL
ip_forward
Habilita "IP forwarding" com um flag booleano. "IP forwarding" também pode ser
configurado em uma base por interface.
ip_dynaddr
Habilita endereço dinâmico de socket e reescrita mascarada de entrada em mudança de
endereço de interface. Isto é útil para interface de dialup com endereços IP
variáveis. 0 significa sem reescrita, 1 ativa a reescrita, e 2 habilita o modo
verbose.
ip_autoconfig
Não documentado.
ip_local_port_range
Contém dois inteiros que definem a faixa padrão de portas locais alocados para
sockets. A alocação começa com o primeiro número e termina no segundo. Note que
eles não deveriam conflitar com as portas usadas pelo mascaramento (apesar de que o
caso é manipulado). Escolhas arbitrárias também podem causar problemas com alguns
filtros de pacotes de firewall que assumem informações sobre as portas locais em
uso. O primeiro número deve ser pelo menos maior que 1024, o melhor é que seja
maior que 4096 para evitar conflitos com portas mais conhecidas, e minimizar
problemas com o firewall.
ip_no_pmtu_disc
Se habilitado, não realiza Path MTU Discovery para sockets TCP, por padrão. Path
MTU discovery pode falhar se firewalls mal-configurados (que perdem todos os
pacotes TCP) ou interfaces mal-configuradas (por exemplo, um link ponto-a-ponto
onde ambos os extremos não concordam com o MTU) estão na rota. É melhor corrigir os
roteadores problemáticos na rota do que desligar o Path MTU Discovery globalmente,
porque a não execução deste último incorre em grandes custos para a rede.
ipfrag_high_thresh, ipfrag_low_thresh
Se a quantidade de fragmentos IP enfileirados atinge ipfrag_high_thresh , a fila é
"podada" para ipfrag_low_thresh . Contém um inteiro com o número de bytes.
ip_always_defrag
[Novo com Kernel 2.2.13; em versões anteriores do kernel, a feature era controlada
em tempo de compilação pela opção CONFIG_IP_ALWAYS_DEFRAG ]
Quando esse flag booleano é habilitado (diferente de 0) fragmentos de entrada
(partes de pacotes IP que surgiram quando algum host, entre a origem e o destino,
decidiram que os pacotes eram grandes demais e os cortaram em pedaços) serão
remontados (desfragmentados) antes de serem processados, mesmo se eles serão
encaminhados.
Somente habilite se estiver rodando um firewall que é o link exclusivo para sua
rede, ou um proxy transparente; nunca acione isso para um roteador normal ou um
host. Caso contrário, uma comunicação fragmentada pode ser perturbada quando os
fragmentos viajam sobre links diferentes. A desfragmentação também consome muita
memória e tempo da CPU.
Isto é "automagicamente" acionado quando o mascaramento ou o proxy transparente são
configurados.
neigh/*
Veja arp(7).
IOCTLS
Todos os ioctls descritos em socket(7) se aplicam a ip.
Os ioctls que configuram firewalling são documentados em ipfw(7) do pacote ipchains
Os ioctls que configuram parâmetros genéricos do dispositivo são descritos em
netdevice(7).
NOTAS
Tome cuidado com a opção SO_BROADCAST - ela não é privilegiada em Linux. É fácil
sobrecarregar a rede com broadcasts descuidados. Para novos protocolos de aplicativos, é
melhor usar um grupo de multicast em vez de broadcast. Broadcast é desencorajado.
Algumas outras implementações de sockets BSD provêm as opções de socket IP_RCVDSTADDR e
IP_RECVIF para conseguir o endereço de destino e a interface dos datagramas recebidos. O
Linux tem o IP_PKTINFO , mais geral para a mesma tarefa.
ERROS
ENOTCONN
A operação só é definida em sockets conectados socket, mas o socket não é
conectado.
EINVAL Um argumento inválido foi passado. Para operações de envio, isso pode ser causado
pelo envio a uma rota blackhole
EMSGSIZE
O datagrama é maior que um MTU na rota e não pode ser fragmentado.
EACCES O usuário tentou executar uma operação sem as permissões necessárias. Isso inclui:
Envio de pacote a um endereço de broadcast sem ter o sinalizador SO_BROADCAST
seleciona. Envio de um pacote através da rota prohibit Modificação de configuração
de firewall sem CAP_NET_ADMIN ou id de usuário efetivo 0. Ligação em uma porta
reservada sem CAP_NET_BIND_SERVICE ou id de usuário efetivo 0.
EADDRINUSE
Tentativa de ligar a um endereço já em uso.
ENOMEM and ENOBUFS
Não há memória disponível suficiente.
ENOPROTOOPT and EOPNOTSUPP
Uma opção de socket inválida foi passada.
EPERM Usuário não tem permissão para configurar alta prioridade, mudar configuração, ou
enviar sinais para o processo ou grupo requerido.
EADDRNOTAVAIL
Uma interface não existente foi requerida, ou o endereço de origem requerido não
era local.
EAGAIN A operação sobre um socket não-bloqueável teria sido bloqueada.
ESOCKTNOSUPPORT
O socket não está configurado, ou um tipo desconhecido de socket foi requerido.
EISCONN
connect(2) foi chamado em um socket já conectado.
EALREADY
Uma operação de conexão sobre um socket não-bloqueável já está em progresso.
ECONNABORTED
Uma conexão foi fechada durante um accept(2).
EPIPE A conexão foi inesperadamente fechada ou derrubada pelo outra extremidade.
ENOENT SIOCGSTAMP foi chamado em um socket onde nenhum pacote chegou.
EHOSTUNREACH
Nenhuma entrada válida da tabela de roteamento combina com o endereço de destino.
Este erro pode ser causado por uma mensagem ICMP de um roteador remoto para a
tabela de roteamento local.
ENODEV Dispositivo de rede não disponível ou não capaz de enviar IP.
ENOPKG Um subsistema do kernel não foi configurado.
ENOBUFS, ENOMEM
Não há memória livre suficiente. Isso frequentemente quer dizer que a alocação de
memória é limitada pelos limites do buffer de socket, e não pela memória do
sistema, mas isso não é 100% consistente.
Outros erros podem ser gerados pelos protocolos de overlay; veja tcp(7), raw(7), udp(7) e
socket(7).
VERSÕES
IP_PKTINFO, IP_MTU, IP_PMTU_DISCOVER, IP_PKTINFO, IP_RECVERR e IP_ROUTER_ALERT são novas
opções no Linux 2.2.
struct ip_mreqn é novo no Linux 2.2. Linux 2.0 somente suporta ip_mreq.
Os sysctls foram introduzidos com o Linux 2.2.
COMPATIBILIDADE
Por questões de compatibilidade com o Linux 2.0, a sintaxe obsoleta socket(PF_INET,
SOCK_RAW, protocol) ainda é suportada para abrir um socket packet(7) socket(PF_PACKET,
SOCK_RAW, protocol) nova estrutura de endereço sockaddr_ll para informação genérica da
camada de link, em vez do antigo sockaddr_pkt.
PROBLEMAS
Há muitos valores de erro inconsistentes.
Os ioctls que configuram opções de interface específicos do IP e tabelas ARP não estão
descritos.
AUTORES
Esta man page foi escrita por Andi Kleen.
VEJA TAMBÉM
sendmsg(2), recvmsg(2), socket(7), netlink(7), tcp(7), udp(7), raw(7), ipfw(7).
RFC791 para a especificação IP original.
RFC1122 para os requisitos do host IPv4.
RFC1812 para os requisitos do roteador IPv4.
TRADUZIDO POR LDP-BR em 21/08/2000.
Rubens de Jesus Nogueira <darkseid99@usa.net> (tradução) André L. Fassone Canova
<lonelywolf@blv.com.br> (revisão)