Introdução: O IPV4 é o protocolod e Rede mais conhecido , pois tudo se iniciou quando os Russos colocaram no ar o satelite Sputinik em 1957, ganhando a corrida espacial dos Americanos, por isso o governo dos EUA: E em 1958 o Departamento de defesa dos EUA decidiu criar o Defense (DARPA) que tinha como missão garantir que os EUA estivessem sempre na dianteira tecnologica militar.
Surgiu assim a necessidade de criar um protocolo de comunicação por comutação de pacotes capas de interconectar computadores heterogeneos. Então foi lançado varios progetos e criados varios protocolos e fianlmente em 1981, foi criado o IPV4 sob o RFC 791. Em 1982 o TCP e o IP foram adotados como protocolos oficiais da ARPANET , porem sua popularisação veio quando da distribuição pelo Berkeley Software Distribution UNIX (BSB UNIX) versão 4.2c.
Estaremos estudando o IPV4. Chama-se de arquitetura TCP/IP o conjunto de protocolos que utilisam os TCP e o IP para estabelecer a comunicação entre redes
Fragment Offset (Deslocamento do Fragmento): 13 bits. Esse campo indica a posição desse fragmento em relação ao do datagrama original. O valor desse campo é expresso em unidades de 8 octetos (64 bits), portanto o tamanho mínimo do campo de dados de um fragmento é de 64 bits. O primeiro fragmento tem valor 0 nesse campo.
TTL (Time to Live – Tempo de Vida): 8 bits. Indica o tempo máximo que o datagrama pode permanecer na rede. Se o valor nesse campo for 0, o datagrama deve ser destruído. A intenção desse campo é não permitir que datagramas cujo destino seja inalcançável fiquem eternamente circulando pela rede. Inicialmente, a unidade do TTL era segundos, mas como cada unidade processadora de datagramas (roteadores, switches de camada 3, etc.) deve diminuir o TTL de uma unidade e o tempo de processamento de pacotes é muito inferior a 1 s, o TTL passa a ser somente um limite superior da existência de cada datagrama.
Protocol (Protocolo): 8 bits. Indica o protocolo da camada superior que está utilizando os serviços da camada IP. Esses valores estão definidos no RFC 790 – Assigned
Network Numbers (Números de Redes Designados) de 1981. Esse RFC foi substituído pelo RFC 1700 – Assigned Numbers. O número do TCP, por exemplo, é 6. Quando o IP estiver encapsulado em outra camada IP, como em uma Virtual Private Network, por exemplo, o valor desse campo é 4.
Header Checksum (Verificação da Soma do Cabeçalho): 16 bits. Esse checksum é calculado somente sobre o cabeçalho IP. Como alguns campos mudam freqüentemente, como o TTL, esse valor tem que ser recalculado. Para se calcular esse checksum, faz-se o complemento de um de cada palavra de 16 bits do cabeçalho, soma-se elas e faz-se o complemento de um da soma total (para efeitos de cálculo, o campo Header Checksum vale 0). Embora esse algoritmo seja simples, ele é suficiente e seguro para a maioria das situações. Pode ser que ele seja substituído por um algoritmo do tipo CRC.
Source Address (Endereço de Origem): 32 bits. Informa o endereço de origem.
Destination Address (Endereço de Destino): 32 bits. Informa o endereço de destino. Essa informação é utilizada pelos roteadores para o encaminhamento (roteamento) do datagrama. Alguns equipamentos podem utilizar os campos IP de origem, de destino e até mesmo informações de protocolos de níveis superiores e o tipo de dado sendo transmitido para realizar o roteamento de pacotes e juntamente realizar algum tipo de priorização ou QoS.
Options (Opções): Tamanho variável, entre 0 e 320 bits (40 octetos). O que é opcional é a transmissão ou não desse campo, não a implementação. Todo os roteadores e gateways devem implementar meios de codificação/decodificação desse campo. Pode haver mais de uma opção nesse campo. As opções servem, entre outras coisas, informar se o próprio campo Option deve ou não ser copiado para os fragmentos, caso o pacote venha a ser fragmentado, para embutir um timestamp da rede, adicionar informações relativas ao nível de segurança do pacote (confidencialidade) ou para especificar uma rota para um determinado destino. Mais informações sobre esse campo podem ser encontradas no RFC 791.5
Padding (Enchimento): Tamanho variável, entre 0 e 31 bits. O campo Padding serve apenas para que o cabeçalho IP tenha um tamanho múltiplo de 32 bits.
Só se faz o enchimento (obrigatoriamente com 0), se o tamanho do campo Option não for múltiplo de 32 bits.
O endereçamento no IPv4
Os 32 bits de endereçamento do IPv4 estão separados em duas partes, sendo que a primeira informa o endereço de rede e a segunda, o endereço de host. A representação do endereço IPv4 é feita através da chamada notação decimal pontuada. Nela, cada um dos quatro bytes do endereço IPv4 é representado pelo seu valor decimal, separados por um “.”. Originalmente, foram definidas 3 classes de endereço, identificadas pelo valor dos primeiros bits do endereço de rede, para atender às necessidades de redes de diferentes tamanhos. A figura abaixo mostra essa divisão.
Classe A: 0.0.0.0 a 127.255.255.255
Aplicação: Para as poucas organizações que possuem redes com número muito grande de hosts.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Endereço de rede Endereço de host
Classe B: 128.0.0.0 a 191.255.255.255
Aplicação: Para organizações de tamanho médio, com número relativamente grande de hosts.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
1 0 Endereço de rede Endereço de host
Classe C: 192.0.0.255 a 223.255.255.255
Aplicação: Para organizações pequenas, com número pequeno de hosts.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
1 1 0 Endereço de rede Endereço de host
Modo de endereçamento extendido: 224.0.0.0 a 255.255.255.255
Aplicação: Uso experimental.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
1 1 1 Endereço extendido
Figura 2.1.2.1 – Formato original dos endereços, suas classes e as faixas de endereços.
Existem ainda mais Duas Classes de endereços:
Classe D: 224.0.0.0 a 239.255.255.255
Aplicação: Transmissão de tráfego multicast.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
1 1 1 0 Endereço multicast
Classe E: 240.0.0.0 a 255.255.255.255
Aplicação: Uso experimental.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Endereços experimentais
Classes de endereço adicionais.
A tabela abaixo mostra os endereços IPv4 reservados e as faixas de endereços utilizáveis.
Classe Faixa de endereços Utilização
A 0.0.0.0 a 0.255.255.255 Não utilizável.
A 10.0.0.0 a 10.255.255.255 Rede reservado para uso em redes privadas.
A 127.0.0.0 a 127.255.255.255 Não utilizável. Loopback para teste de interfaces.
A Demais faixas de endereços Utilizáveis comercialmente.
B 172.16.0.0 a 172.16.255.255 Rede reservado para uso em redes privadas.
B Demais faixas de endereços Utilizáveis comercialmente.
C 192.168.0.0 a 192.168.255.255 Endereço de rede reservado para uso em redes privadas.
C Demais faixas de endereços Utilizáveis comercialmente.
O IP versão 6 (IPv6) é a nova versão do Internet Protocol, projetado para ser o sucessor do IPv4. O IPv6 foi desenvolvido para atender as necessidades atuais e as de um futuro próximo. Foram considerados os desejos das empresas por redes com arquiteturas mais escaláveis, maior segurança e integridade dos dados, extensões ao QoS, autoconfiguração, maior agregação no nível do backbone global e outras necessidades.
Alguns mais interessados podem se perguntar “Por que não existe IPv5 ?”. O IPv5 foi uma pequena modificação experimental no IPv4 para trafegar voz e vídeo sobre multicast. Sua especificação pode ser encontrada sob o RFC 1819 – Internet Streaming Protocol Version 2 (ST2).
Apesar de haver vários backbones com IPv6 em caráter experimental, como o 6Bone, que é o backbone IPv6 do projeto IPng (Internet Protocol Next Generation – Próxima Geração do Internet Protocol) da IETF (Internet Engineering Task Force – Força Tarefa de Engenharia da Internet), a previsão para o início de operação comercial do IPv6 é 2010. Por uns 5 anos, os equipamentos deverão oferecer compatibilidade entre IPv6 e IPv4, seja por encapsulamento, tunelamento, algum protocolo de roteamento capaz de lidar com ambas as versões ou alguma outra técnica. Porém, a migração não será algo simples. Há um grupo de trabalho do IETF, o IPng Transition (ou simplesmente ngtrans”), exclusivamente ocupado para levantar os problemas e soluções para essa migração.
As principais mudanças com relação ao IPv4 são:
Capacidade de endereçamento expandida: No IPv6, cada endereço é determinado por 128 bits.
Foi previsto que os 32 bits de endereçamento do IPv4 não seriam suficientes para atender a demanda até o final da primeira década do ano 2000. O número de hosts possíveis no IPv6 é 2128 = 3,4028 x 1038, um número extremamente grande. Para se ter uma noção da grandeza desse valor , assumindo-se a área do planeta Terra como sendo 510.065.500 x 1012 mm2, poderíamos ter 6,6713 x 1017 IP/mm2. Porém, o endereçamento do IPv6 não é completamente plano, isto é, não é possível utilizar todas as combinações possíveis. Se supusermos que sejam efetivamente utilizados 64 bits desses 128 bits, ainda assim teríamos mais de 36.000 IP/m2, um número suficientemente grande para suprir a demanda por várias décadas. Embora tecnologias como a NAT tenham prolongado a sobrevivência do IPv4 (no caso da NAT, com relação ao número de endereços possíveis), elas não 13 são suficientes para resolver todos os problemas do IP com relação às necessidades futuras, porque a mesma NAT, por exemplo, inviabiliza ou dificulta alguns tipos de aplicações, como segurança fim-a-fim e VPN (Virtual Private Networks – Redes Privadas Virtuais).
Simplificação do formato do cabeçalho: Alguns campos do cabeçalho do IPv4 foram descartados ou tornados opcionais, para simplificar o processamento dos pacotes mais comuns e diminuir o overhead do IPv6, que possui um cabeçalho maior.
Maior suporte para campos opcionais e extensões: Os campos opcionais possuem agora menos restrições quanto ao seu tamanho, há maior flexibilidade para a introdução de novas extensões no futuro, o encaminhamento de pacotes fica mais simplificado e pode ser diferenciado a cada hop.
Capacidade para identificação de fluxo: O originador dos pacotes tem como identificar um fluxo de pacotes para um determinado destino (unicast ou multicast) e pedir tratamento especial desse fluxo por parte do roteador, como QoS diferenciado e serviço de tempo real. No IPv4, esse tipo de funcionalidade é implementado pelos roteadores e switches de camadas 3 ou 4, sobrecarregando seu processamento. O custo desse processamento foi passado para o originador do pacote e os equipamentos podem utilizar o processamento economizado para outras funções.
A especificação do IPv6:
A figura abaixo foi tirada da especificação do IPv6, documentada sob o RFC 2460.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Version Traffic Class Flow Label
Payload Length Next Header Hop Limit
Source Address (128 bits = 4 x 32 bits)
Destination Address (128 bits = 4 x 32 bits)
(Extension Header)
Data
Especificação do IPv6 (RFC 2460).
Version (Versão): 4 bits. Para essa versão, o valor é 6.
Traffic Class (Classe de Tráfego): 8 bits. Esse campo ainda é experimental e pode vir a ser modificado. Na primeira especificação do IPv6, RFC 1883, esse campo não existia. Em seu lugar havia um campo de 4 bits chamado Priority (Prioridade). A função desse campo é permitir diferenciação de tráfego (classes de tráfego) e mecanismos de prioridade, para que os roteadores possam prover tratamento apropriado em cada caso. Algumas idéias do TOS e dos bits Precedence do IPv4 foram aproveitadas. Ainda há muita discussão sobre a divisão mais útil e eficiente dos vários tipos de tráfego em classes. Cabe à camada superior informar a camada IPv6 qual a classe de tráfego a ser utilizada. Um roteador pode alterar os bits do campo Traffic Class da forma que desejar. Por esse motivo, uma estação não deve assumir que um determinado tipo de tráfego que ela associou a uma certa classe, será recebido com o campo Traffic Class com o mesmo valor com o qual ela transmitiria.
Flow Label (Identificação do Fluxo): 20 bits. Um flow é uma seqüência de pacotes enviados a partir de uma determinada origem, para um determinado destino (unicast ou multicast), requerendo um tratamento especial pelos roteadores, como QoS ou reserva de banda (RSVP – Resource Reservation Protocol), por exemplo. O campo Flow Label ainda é experimental e pode vir a ser modificado, como já ocorreu desde a primeira especificação do IPv6, onde ele possuía 24 bits. As mudanças dependem da identificação das características que forem surgindo do tráfego na Internet.
A intenção do Flow Label é permitir que a origem possa atribuir uma identificação (padronizada) aos pacotes, para que eles recebam tratamento especial por um roteador (fazer QoS, tráfego de tempo real, etc.). Roteadores e hosts que não são capazes de identificar o Flow Label de um pacote devem deixar o campo com valor igual a 0, quando originá-lo, deixá-lo inalterado, quando retransmiti-lo, ou ignorá-lo, quando recebê-lo.
Payload Length (Comprimento da Carga): 16 bits. Informa o comprimento dos dados, em octetos, encapsulados pela camada de rede, isto é quantos bytes vêm depois do cabeçalho IPv6 (os campos de extensão são contabilizados). Caso esse campo seja 0, indica que o comprimento do payload é superior a 65.535 octetos e é informado em um Extension Header.
Next Header (Próximo Cabeçalho): 8 bits. Informa qual o protocolo da camada superior que está utilizando os serviços da camada IP. A numeração também segue o RFC 1700. O UDP, por exemplo, é número 17. No IPv6, pode haver um campo opcional após o cabeçalho. Nesse caso, o valor de Next Header informa qual o tipo de extensão que vem após o cabeçalho IPv6.
Hop Limit (Limite de Hop): 8 bits. Semelhante ao TTL do IPv4, cada unidade processadora de pacotes (nó) decrementa esse valor de 1 unidade e quando esse valor chegar a 0, o pacote é descartado.
Source Address (Endereço de Origem): 128 bits. Informa o endereço de origem do pacote.
Destination Address (Endereço de Destino): 128 bits. Informa o endereço de destino. O endereço de destino pode não ser o endereço do host final, porque pode ser um cabeçalho de roteamento.
Extension Header (Cabeçalho de Extensão): Tamanho variável, mas sempre múltiplo de 8 octetos (64 bits). Pode haver mais de um campo de extensão. A presença de um campo de extensão pode ser determinada pelo valor do campo Next Header. Cada Extension Header tem um campo Next Header informando o próximo protocolo, como pode ser observado na figura abaixo. Normalmente, somente o nó de destino irá processar os Extension Headers. Os Extension Headers precisam ser processados exatamente na ordem em que eles aparecem. Uma implementação completa do IPv6 tem ser capaz de reconhecer e processar os seguintes tipos de Extension Headers: (Hop-by-Hop Options (Opções Hop-a-Hop), Routing – Type 0 (Roteamento – Tipo 0), Fragment (Fragmento), Destination Options (Opções de Destino), Authentication (Autenticação) e Encapsulating Security Payload (Encapsulando Carga de Segurança). Os quatro primeiros tipos de Extension Header podem ser encontrados no RFC 2460 (o da especificação do IPv6), e os dois últimos, nos RFCs 2402 e 2406, respectivamente. O Routing Header pode especificar quais são os próximos destinos depois do destino especificado pelo campo Destination Address. Quando houver mais de um Extension Header presente, recomenda-se que eles estejam na seguinte ordem: cabeçalho IPv6, Hop-by-Hop Options, Destination Options (para o primeiro destino, especificado pelo Destination Address, e pelos próximos destinos, especificados no Routing Header), Routing, Fragment, Authentication, Encapsulating Security Payload, outro Destination Options (para ser processado somente pelo último destino) e depois os cabeçalho do protocolo da camada superior.
IPv6 Header
Next Header = TCP
TCP
Header + Data
IPv6 Header
Next Header = Routing
Routing Header
Next Header = TCP
TCP
Header + Data
IPv6 Header
Next Header = Routing
Routing Header
Next Header = Fragment
Fragment Header
Next Header = TCP
Fragment of TCP
Header + Data
Exemplo de Extension Headers do IPv6.
Quando ocorrer a migração para o IPv6, os protocolos da camada superior que incluem o tamanho do campo IP em seus mecanismos de detecção de erro deverão ser alterados. No IPv6, há também um “pseudo-cabeçalho”, após os Extension Header, mostrado na figura abaixo.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Upper-Layer Packet Length Next Header Pseudo-cabeçalho que antecede o cabeçalho da camada superior no IPv6.
Upper-Layer Packet Length (Comprimento do Pacote da Camada Superior): 32 bits. Corresponde ao comprimento em bytes da camada superior, incluindo o cabeçalho e os dados (PDU e SDU). Para protocolos de camada superior que carregam seu comprimento no próprio cabeçalho, como o UDP, o valor desse campo é o mesmo do presente na camada superior.
Next Header (Próximo Cabeçalho): O Next Header do pseudo-cabeçalho será diferente do Next Header do cabeçalho IPv6, somente no caso em que houver Extension Headers após o IPv6. Nesse caso, o Next Header do IPv6 informa o valor do Extension Header.
O MTU mínimo do IPv6 é de 1.280 bytes (no IPv4 era 576 bytes), mas o recomendado é que ele seja maior que 1.500 bytes, para que possa ser feita alguma forma de encapsulamento sem que a camada de rede precise fragmentar os dados. Ao contrário do IPv4, quando o protocolo da camada superior for o UDP, o checksum não é opcional. Ele é calculado e é levado em consideração o tamanho do pseudo-cabeçalho. Se o valor do checksum der 0x0000, ele deve ser passado para 0xFFFF. Assim, quando um nó IPv6 receber um pacote transportando UDP, se o checksum do UDP for 0x0000, o pacote será descartado. Não será discutido aqui o ICMP do IPv6 (ICMPv6), mas obviamente ele possui algumas modificações. Uma delas é que seu cabeçalho equivale aos 32 primeiros bits somente do IPv4. Sua especificação encontra-se no RFC 2463 – Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
O endereçamento no IPv6
Ainda não há uma especificação oficial para a alocação e formação de endereços do IPv6, mas no RFC 2471 – IPv6 Testing Address Alocation (Teste de Alocação de Endereço do IPv6), há uma proposta, mostrada na figura abaixo. Embora seja experimental e esteja servindo para testes de implementações do IPv6, ela segue as recomendações definidas para a arquitetura IPv6 e o seu formato é consistente com o Aggregatable Global Unicast Address Allocation (Alocação Global Agregavel de Endereço Unicast) e com o Top-Level Aggregation and Next-Level Aggregation Assignment Rules (Regras de Designação de Agregação Top-Level e Agregação Next-Level). O endereço IPv6 pode ser definido manualmente, por IPv6 Auto Address Allocation (Alocação Automática de Endereço IPv6) ou por DHCPv6 (Dynamic Host Configuration Protocol – Protocolo Dinâmico de Configuração de Host).
Conclusão: O IPV6 é um padrão que promete resolver vários problemas da internet , porem são necessárias algumas adaptações nos sistemas operacionais atuais aumentando com isso o tempo da migração . Para muitos ele trará complexidades que no momento não existiam para os administradores de Rede, porem as melhorias em configurações e segurança irá facilitar em muito a montagem de uma Rede. Ainda há os que acham que o aumento da tabela resultante do aumento de Roteamento pode ser demasiado para os hards existentes hoje no mercado, por isso esperamos o surgimento de hards com mais memória e a um custo menor para um desempenho mais favorável ao IPV6.
Nenhum comentário:
Postar um comentário