A maior rede de estudos do Brasil

Grátis
314 pág.
IPv6 apostila completa

Pré-visualização | Página 3 de 47

um grande poder de processamento do dispositivo tradutor. O uso da NAT também 
impossibilita rastrear o caminho de pacote, através de ferramentas como traceroute, por exemplo, 
e dificulta a utilização de algumas técnicas de segurança como IPSec. Além disso, seu uso passa 
uma falsa sensação de segurança, pois, apesar de não permitir a entrada de pacotes não 
autorizados, a NAT não realiza nenhum tipo de filtragem ou verificação nos pacotes que passa 
por ela.
 13
●
 NAT
● Vantagens:
● Reduz a necessidade de endereços públicos;
● Facilita a numeração interna das redes;
● Oculta a topologia das redes;
● Só permite a entrada de pacotes gerado em resposta a um pedido 
da rede.
● Desvantagens:
● Quebra o modelo fim-a-fim da Internet;
● Dificulta o funcionamento de uma série de aplicações;
● Não é escalável;
● Aumento do processamento no dispositivo tradutor;
● Falsa sensação de segurança;
● Impossibilidade de se rastrear o caminho do pacote;
● Impossibilita a utilização de algumas técnicas de segurança como 
IPSec.
Soluções
10.0.0.0 a 10.255.255.255 /8 (16.777.216 
hosts)
172.16.0.0 a 172.31.255.255 /12 (1.048.576 hosts)
192.168.0.0 a 192.168.255.255 /16 (65.536 hosts)
Embora estas soluções tenham diminuído a demanda por IPs, elas não foram suficientes 
para resolver os problemas decorrentes do crescimento da Internet. A adoção dessas técnicas 
reduziu em apenas 14% a quantidade de blocos de endereços solicitados à IANA e a curva de 
crescimento da Internet continuava apresentando um aumento exponencial.
Essas medidas, na verdade, serviram para que houvesse mais tempo para se desenvolver 
uma nova versão do IP, que fosse baseada nos princípios que fizeram o sucesso do IPv4, porém, 
que fosse capaz de suprir as falhas apresentadas por ele.
Mais informações:
• RFC 1380 - IESG Deliberations on Routing and Addressing
• RFC 1918 - Address Allocation for Private Internets
• RFC 2131 - Dynamic Host Configuration Protocol
• RFC 2775 - Internet Transparency
• RFC 2993 - Architectural Implications of NAT
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) 
• RFC 3027 - Protocol Complications with the IP Network Address Translator
• RFC 4632 - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and 
Aggregation Plan.
 14
Soluções paliativas: Queda de apenas 14%
Soluções
Deste modo, em dezembro de 1993 a IETF formalizou, através da RFC 1550, as pesquisas 
a respeito da nova versão do protocolo IP, solicitando o envio de projetos e propostas para o novo 
protocolo. Esta foi umas das primeiras ações do grupo de trabalho da IETF denominado Internet 
Protocol next generation (IPng). As principais questões que deveriam ser abordadas na elaboração 
da próxima versão do protocolo IP foram:
� Escalabilidade;
� Segurança;
� Configuração e administração de rede;
� Suporte a QoS;
� Mobilidade;
� Políticas de roteamento;
� Transição.
 15
Estas medidas geraram mais tempo para desenvolver uma nova 
versão do IP.
●
 1992 - IETF cria o grupo IPng (IP Next Generation)
● Principais questões:
● Escalabilidade;
● Segurança;
● Configuração e administração de rede;
● Suporte a QoS;
● Mobilidade;
● Políticas de roteamento;
● Transição.
Soluções
Diversos projetos começaram a estudar os efeitos do crescimento da Internet, sendo os 
principais o CNAT, o IP Encaps, o Nimrod e o Simple CLNP. Destas propostas surgiram o TCP 
and UDP with Bigger Addresses (TUBA), que foi uma evolução do Simple CLNP, e o IP Address 
Encapsulation (IPAE), uma evolução do IP Encaps. Alguns meses depois foram apresentados os 
projetos Paul’s Internet Protocol (PIP), o Simple Internet Protocol (SIP) e o TP/IX. Uma nova 
versão do SIP, que englobava algumas funcionalidades do IPAE, foi apresentada pouco antes de 
agregar-se ao PIP, resultando no Simple Internet Protocol Plus (SIPP). No mesmo período, o 
TP/IX mudou seu nome para Common Architecture for the Internet (CATNIP).
Em janeiro de 1995, na RFC 1752 o IPng apresentou um resumo das avaliações das três 
principais propostas:
– CANTIP - foi concebido como um protocolo de convergência, para permitir a 
qualquer protocolo da camada de transporte ser executado sobre qualquer protocolo de 
camada de rede, criando um ambiente comum entre os protocolos da Internet, OSI e 
Novell;
– TUBA - sua proposta era de aumentar o espaço para endereçamento do IPv4 e torná-lo 
mais hierárquico, buscando evitar a necessidade de se alterar os protocolos da camada 
de transporte e aplicação. Pretendia uma migração simples e em longo prazo, baseada 
na atualização dos host e servidores DNS, entretanto, sem a necessidade de 
encapsulamento ou tradução de pacotes, ou mapeamento de endereços;
– SIPP - concebido para ser uma etapa evolutiva do IPv4, sem mudanças radicais e 
mantendo a interoperabilidade com a versão 4 do protocolo IP, fornecia uma 
plataforma para novas funcionalidades da Internet, aumentava o espaço para 
endereçamento de 32 bits para 64 bits, apresentava um nível maior de hierarquia e era 
composto por um mecanismo que permitia “alargar o endereço” chamado cluster 
addresses. Já possuía cabeçalhos de extensão e um campo flow para identificar o tipo 
de fluxo de cada pacote.
 16
Solução definitiva:
Soluções
Entretanto, conforme relatado também na RFC 1752, todas as três propostas apresentavam 
problemas significativos. Deste modo, a recomendação final para o novo Protocolo Internet 
baseou-se em uma versão revisada do SIPP, que passou a incorporar endereços de 128 bits, 
juntamente com os elementos de transição e autoconfiguração do TUBA, o endereçamento 
baseado no CIDR e os cabeçalhos de extensão. O CATNIP, por ser considerado muito 
incompleto, foi descartado.
Após esta definição, a nova versão do Protocolo Internet passou a ser chamado 
oficialmente de IPv6.
Mais informações:
• RFC 1550 - IP: Next Generation (IPng) White Paper Solicitation
• RFC 1752 - The Recommendation for the IP Next Generation Protocol
As especificações da IPv6 foram apresentadas inicialmente na RFC 1883 de dezembro de 
1995, no entanto, em em dezembro de 1998, está RFC foi substituída pela RFC 2460. Como 
principais mudanças em relação ao IPv4 destacam-se:
� Maior capacidade para endereçamento: no IPv6 o espaço para endereçamento aumentou 
de 32 bits para 128 bits, permitindo: níveis mais específicos de agregação de endereços; 
identificar uma quantidade muito maior de dispositivos na rede; e implementar mecanismos 
de autoconfiguração. A escalabilidade do roteamento multicast também foi melhorada 
através da adição do campo "escopo" no endereço multicast. E um novo tipo de endereço, o 
anycast, foi definido;
� Simplificação do formato do cabeçalho: alguns campos do cabeçalho IPv4 foram 
removidos ou tornaram-se opcionais, com o intuito de reduzir o custo do processamento dos 
pacotes nos roteadores;
� Suporte a cabeçalhos de extensão: as opções não fazem mais parte do cabeçalho base, 
permitindo um roteamento mais eficaz, limites menos rigorosos em relação ao tamanho e a 
quantidade de opções, e uma maior flexibilidade para a introdução de novas opções no 
futuro;
� Capacidade de identificar fluxos de dados: foi adicionado um novo recurso que permite 
identificar de pacotes que pertençam a determinados tráfegos de fluxos, para os quais 
podem ser requeridos tratamentos especiais;
� Suporte a autenticação e privacidade: foram especificados cabeçalhos de extensão 
capazes de fornecer mecanismos de autenticação e garantir a integridade e a 
confidencialidade dos dados transmitidos.
 18
●
 1998 - Definido pela RFC 2460
● 128 bits para endereçamento.
● Cabeçalho base simplificado.
● Cabeçalhos de extensão.
● Identificação de fluxo de dados (QoS).
● Mecanismos de IPSec incorporados ao protocolo.
● Realiza