institiuto científico de ensino superior e pesquisa – icesp
Propaganda
INSTITUTO CIENTÍFICO DE ENSINO SUPERIOR E PESQUISA – ICESP CURSO DE TECNOLOGIA EM REDES DE COMPUTADORES ELISNALDO SANTIAGO PRAZER IPng Plano de migração da versão 4 do protocolo IP, para a versão 6 em grandes corporações BRASÍLIA 2006 2 ELISNALDO SANTIAGO PRAZER IPng Plano de migração da versão 4 para a versão 6 para grandes corporações Projeto apresentado ao Instituto Científico de Ensino Superior-UnICESP como requisito parcial, para a obtenção do título de tecnólogo em no curso de Tecnologia em Redes de Computadores. Orientador: Gustavo Fleury BRASILIA 2006 3 LISTA DE FIGURAS Figura Página Figura 7.1.1 – Modelo de referencia do TCP/IP baseado em 5 camadas ..................... 18 Figura 7.1.2 – Camadas conceituais dos serviços de internet (TCP/IP) ....................... 18 Figura 7.3.1.1 - Modelo do datagrama IP versão 4 ....................................................... 23 Figura 7.3.1.2 – Modelo do cabeçalho IP versão 4 ....................................................... 24 Figura 7.3.2.2.3 – Representação do funcionamento do protocolo ARP ....................... 30 Figura 7.3.3.1 – Esquema de interligação de redes com roteadores. ........................... 33 Figura 7.3.4.1 – processo de fragmentação do datagrama ........................................... 35 Figura 7.3.5.1 – Diagrama de encapsulamento conforme o Modelo OSI ...................... 36 Figura 7.3.6.1.1– Cabeçalho IP com endereço de destino no formato de multicast...... 38 Figura 7.3.7.1 – Encapsulamento de um datagrama IP criptografado em outro datagrama IP para comunicação VPN .......................................................................... 41 Figura 7.3.10.1 – Detalhamento do cabeçalho do IPsec ............................................... 43 Figura 7.3.6.5.2 – Detalhamento do cabeçalho do IPsec utilizando ESP ...................... 44 Figura 7.4.1.1 - Modelo do datagrama IP versão 6 ....................................................... 46 Figura 7.4.1.1.1 – Comparação entre os cabeçalhos IP versão 6 e 4 ........................... 51 Figura 7.4.1.1.2 – Composição de um datagrama IPv6 com os cabeçalhos de extensão ...................................................................................................................................... 52 Figura 7.4.2.1 – Composição do cabeçalho hop-by-hop ............................................... 53 Figura 7.4.2.2 – Formato do campo TYPE .................................................................... 53 Figura 7.4.4.1 – Formato do cabeçalho de roteamento ................................................. 55 Figura 7.4.4.2 – Mecanismo de funcionamento do cabeçalho de roteamento com S/L=1 ...................................................................................................................................... 57 Figura 7.4.5.1 – Formato do cabeçalho de fragmento ................................................... 58 Figura 7.4.5.2 – Processo de fragmentação de um datagrama..................................... 60 Figura 7.4.6.1 – Formato do cabeçalho de autenticação .............................................. 62 Figura 7.4.6.2 – Encapsulamento IP sobre IP ............................................................... 64 Figura 7.4.7.1 – Formato do cabeçalho criptografia ...................................................... 66 Figura 7.4.7.2 – ESP em modo TRANSPORTE ............................................................ 68 Figura 7.4.7.3 – ESP em modo TÚNEL ........................................................................ 69 Figura 7.4.7.4 – Funcionamento do ESP em modo TÚNEL .......................................... 69 Figura 7.4.8.1 – Endereço IPv6 representado em bits .................................................. 70 4 Figura 7.4.8.1.1 – Hierarquia de 3 níveis da Internet .................................................... 75 Figura 7.4.8.1.2 – Formato do endereço Unicast .......................................................... 75 Figura 7.4.8.2.1 – Formato do endereço Anycast ......................................................... 77 Figura 7.4.8.3.1 – Formato do endereço Multicast ........................................................ 77 Figura 7.4.10.1 – Formato do cabeçalho ICMPv6 ......................................................... 81 Figura 7.4.10.2 – Formato do pseudo cabeçalho ICMPv6 ............................................ 82 Figura 7.4.11.1 – Processo de reconhecimento do MTU dos links ............................... 86 Figura 7.4.11.2.1 – Processo de auto configuração de endereço “sem estado” ........... 87 Figura 7.4.11.3.1 – Processo fornecimento de endereço cliente/servidor ..................... 88 Figura 7.4.11.3.2 – Processo fornecimento de endereço com a utilização do DHCP Relay ............................................................................................................................. 90 Figura 7.4.11.3.3 – Processo fornecimento de endereço combinando DHCP e DNS ... 90 Figura 7.4.1.4 – Comparação entre os cabeçalhos IP versão 6 e 4 .............................. 93 5 LISTA DE TABELAS Tabela Página Tabela 7.2.1 – Tabela de evolução da Internet .....................................................................21 Tabela 7.3.2.1 -Formas de endereçamento do primeiro octeto do endereço IP ..............27 Tabela 7.3.2.2 – Classes do endereçamento IP....................................................................28 Tabela 7.3.3.1 – Exemplo de informações de uma tabela de roteamento ........................32 Tabela 7.3.6.1.1 – Tabela com algumas atribuições definidas para grupos de multicast .......................................................................................................................................................39 Tabela 7.4.1.1 – Tabela de classes de datagramas para tráfego controlado por congestionamento ......................................................................................................................50 Tabela 7.4.1.2 – Tabela de protocolos válida para o campo NEXT HEADER .................50 Tabela 7.4.2.1 – Valores de tipo de tratamento de datagramas pelos nós da rede ........53 Tabela 7.4.8.1 – Alocação de prefixos ....................................................................................72 Tabela 7.4.8.3.1 – Valores possíveis para o campo ESCOP ..............................................78 Tabela 7.4.8.3.2 – Valores Multicast reservados ..................................................................79 Tabela 7.4.8.3.3 – Valores Multicast para todos os nós (escopos 1 e 2) ..........................79 Tabela 7.4.8.3.4 – Valores Multicast para todos os nós (escopos 1, 2 ou 5) ...................79 Tabela 7.4.8.3.5 – Valores Multicast com outras funções ...................................................79 Tabela 7.4.10.1 – Valores e mensagens ICMPv6 .................................................................81 Tabela 7.5.1 – Processo fornecimento de endereço combinando DHCP e DNS ............92 6 LISTA DE SIGLAS Sigla Nomenclatura AH Authentication Header ARP Address Resolution Protocol ARPA Advanced Research Projects Agency ARPANET Rede de comunicação de dados desenvolvida pela agencia ARPA BGP Border Gateway Protocol BIT Dígito do sistema BINÁRIO de numeração BOOTP Bootstrap BSD Berkeley Software Distribution CBC Cipher Block Chaining CDMF Commercial Data Masking Facility CIDR Classes Inter-Domain Routing CSMA/CD Carrier Sense Multiple Access with Collision Detect DARPA Defense Advanced Research Projects Agency DCA Defense Communication Agency DHCP Dynamic Host Configuration Protocol DNS Domain Name Server EGP Exterior Gateway Protocol ESP Encap Security Payload Ethernet Tecnologia de rede local que utiliza a tecnologia CSMA/CD GGP Gateway-to-Gateway Protocol Hardware Partes físicas de um sistema computacional, eletrônicas ou não. 7 HMAC Hashed Message Authentication Code HOP Pontos de roteamento pelos quais um datagrama passa em uma transmissão IAB Internet Architecture Board IANA Internet Assigned Numbers Authority ICCB Internet Control and Configuration Board ICMP Internet Control Message Protocol IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IGRP Internet Gateway Routing Protocol Internet Rede pública Intranet Rede privada IP Internet Protocol IPng Internet Protocol next generation ou também conhecida como IPv6 IPv4 Versão 4 do protocolo IP IPv6 Versão 6 do protocolo IP MAC Media Access Control MAC Message Autentication Code Mainframe Computadores de grande porte MILNET Segmento da ARPANET fechado para o serviço militar Norte Americano MTU Maximum Transmission Unit NAT Network Address Translation ND Neighbor Discovery NIC Network Interface Card 8 Octetos Conjunto de oito bits OSPF Open Shortest Path First PAD Packet Assembler/Disassembler payload Parte de dados do cabeçalho IPv6 RFC Request for Comments RIP Routing Information Protocol S/L Strict/Loose Bit Map SA Security Association SHA Secure Hash Algorithm Socket Interface de software para acesso direto de programas aos protocolos Software Parte lógica de um sistema computacional SPI Security Parameters Index TCP Transmission Control Protocol TCP Transmission Control Protocol TLV Type-Length-Value TOS Type Of Service UDP User Datagram Protocol VPN Virtual Private Network www Word Wide Web 9 SUMÁRIO Capítulo Página 1. Introdução............................................................................................................. 11 2. Justificativa .......................................................................................................... 13 3. Objetivo Geral ....................................................................................................... 14 4. Objetivo Específico .............................................................................................. 15 5. Metodologia .......................................................................................................... 16 6. Escopo da pesquisa............................................................................................. 17 7. Referencial Teórico .............................................................................................. 18 7.1. Apresentação do protocolo TCP/IP ............................................................. 18 7.2. Breve Histórico.............................................................................................. 19 7.3. Internet Protocol versão 4 (IPv4) ................................................................. 23 7.3.1. Cabeçalho do DATAGRAMA IPV4 ........................................................ 23 7.3.2. Endereçamento IPv4 .............................................................................. 27 7.3.2.1. Subclasses do IPv4 ....................................................................... 28 7.3.2.2. Protocolo de Tradução de Endereços (ARP)............................... 29 7.3.3. Roteamento ............................................................................................ 31 7.3.4. Fragmentação ........................................................................................ 35 7.3.5. Encapsulamento .................................................................................... 36 7.3.6. Multicasting ............................................................................................ 37 7.3.6.1. Endereçamento multicast IP ......................................................... 38 7.3.6.1.1. Internet Group Management Protocol (IGMP) ........................ 39 7.3.7. Virtual Private Network (VPN) ............................................................... 40 7.3.8. Network Address Translation (NAT) .................................................... 41 7.3.9. Dynamic Host Configuration Protocol (DHCP).................................... 42 7.3.10. IP Security (IPsec) ............................................................................... 43 7.4. Internet Protocol versão 6 (IPv6) ................................................................. 46 7.4.1. Cabeçalho do DATAGRAMA IPv6 ......................................................... 46 7.4.1.1. Cabeçalhos Concatenados IPv6 ................................................... 51 7.4.2. Cabeçalho Hop by Hop options (salto a salto) .................................... 53 7.4.3. Cabeçalho Destination options ............................................................ 54 7.4.4. Cabeçalho Routing ................................................................................ 55 7.4.5. Cabeçalho Fragment ............................................................................. 57 10 7.4.6. Cabeçalho Authentication ..................................................................... 62 7.4.7. Cabeçalho Encapsulating Security Payload (ESP) ............................. 65 7.4.8. Endereçamento IPv6 .............................................................................. 70 7.4.8.1. Formato de Endereço Unicast Global .......................................... 74 7.4.8.2. Formato de Endereço Anycast ..................................................... 76 7.4.8.3. Formato de Endereço Multicast.................................................... 77 7.4.9. IEEE EUI-64............................................................................................. 80 7.4.10. Internet Control Message Protocol version (ICMPv6 6) ................... 80 7.4.11. Protocolo de Descoberta de Vizinhos (NDP – Neighbor Discovery Protocol) .............................................................................................. 83 7.4.11.1. Processo de descoberta dos MTUs dos caminhos (Path MTU Discovery Process)........................................................................ 85 7.4.11.2. Autoconfiguração de endereços .................................................. 86 7.4.11.3. DHCPv6 ........................................................................................... 87 7.5. Compatibilidade entre IPv4 e IPv6 .......................................................... 91 7.6. Comparando as versões do Protocolo ................................................... 93 7.7. Reflexões sobre alguns motivos para migração de IPv4 para IPv6 ..... 95 7.8. Conclusão do estudo ............................................................................... 97 Bibliografia 98 Outras fontes 99 11 1. Introdução Com a grande evolução da computação, o ser humano torna-se cada vez mais dependente dos recursos oferecidos pela tecnologia. Atualmente, a linha que separa os eletrônicos dos sistemas informatizados está cada vez mais tênue, e os grandes responsáveis por esta evolução são os recursos de comunicação de dados. Antes dos anos 90, cada aparelho possuía sua função específica, ou seja, aparelho de som para reprodução de músicas, telefone para conversação, máquina fotográfica para registro de imagens, computadores para edição de documentos, programação e execução de aplicativos e, comunicação de dados, atendia apenas a interesses de grandes corporações para interligação de seus mainframes. As redes de informação ganharam espaço nas coisas mais simples possibilitando uma interação entre tudo isso. Um grande exemplo é a telefonia celular que já é capaz de trafegar voz, dados e imagem utilizando-se de um aparelho telefônico através de redes integradas à Internet. Computadores exercem todas as atividades de eletrônicos como conversação, execução de jogos, captura e edição de imagens e vídeos e até mesmo execução de músicas. Tudo isso foi possível em função do protocolo TCP/IP que, de tão difundido, tornou-se necessária à criação de mecanismos de segmentação entre as redes privadas (Intranet) e a pública (Internet). Às redes privadas, principalmente nos ambientes corporativos, foi permitida a adoção de endereços TCP/IP de escolha própria cuja administração é realizada exclusivamente pela organização. Já a rede pública possui uma unidade controladora em cada país a fim de gerenciar a distribuição de IPs impedindo assim a duplicidade. 12 A integração destes dois ambientes, redes privadas e pública, se dá por dispositivos de tradução de endereços (NATs) que são implantados e administrados por cada organização a qual é atribuída a responsabilidade pelo seu funcionamento. Mesmo com vários recursos existentes para melhor aproveitamento dos endereços públicos, a quantidade de usuários e empresas que utilizam a Internet cresceu tanto que os 2 32 endereços de rede da Internet tendem a esgotar-se em poucos anos. Este foi o cenário que motivou grupos de pesquisa a trabalharem em um novo modelo de endereçamento TCP/IP a fim de atender a demanda mundial. Este modelo recebeu o nome de IPng e sua versão oficial é a IPV6 que entra para substituir a atual IPV4. 13 2. Justificativa Com o crescimento exponencial de utilização da Internet, os endereços públicos de acesso estão ficando escassos e os recursos de telecomunicações, saturados. Com a grande dependência destes recursos, um colapso no sistema acarretaria prejuízos imensuráveis para profissionais liberais e empresas que dependem desta estrutura para manter seus negócios. A fim de evitar este conflito, foi desenvolvida a versão 6 do protocolo IP. O IPv6 eleva substancialmente a quantidade de endereços para a Internet, bem como diminui o uso de banda de rede e reduz informações no cabeçalho de dados. Muito mais que a ampliação da faixa de endereçamento oficial, o IPv6 visa melhorar o desempenho das redes, principalmente nos pontos onde se exige maior processamento para passagem dos datagramas entre redes diferentes. Outra questão importante é o novo conceito de “cabeçalhos concatenados”. Isso permite um melhor gerenciamento de segurança do datagrama desde as atividades mais simples como um “echo replay” (comando ping) até as mais complexas como criptografia e VPN, por exemplo. Face ao exposto, todas as grandes corporações deveriam iniciar um plano de migração para esta nova tecnologia do protocolo IP. Esta mudança pode ser implementada a longo prazo, uma vez que existem serviços de tradução que tornam compatíveis, pelo menos por algum tempo, as duas versões do protocolo até porque, tal migração pode representar um alto custo em hardware e software caso a corporação ainda possua equipamentos que não suportem IPv6. 14 3. Objetivo Geral Nesta primeira etapa do Trabalho de Conclusão de Curso (TCC1), será realizado um estudo comparativo do protocolo IPv6 em relação ao IPv4, apresentando as melhorias do protocolo em sua evolução. Serão abordadas as funcionalidades mais utilizadas em ambientes de redes corporativos. Na segunda etapa (TCC2), deverá ser apresentado um plano de migração de tecnologia entre estes protocolos que poderá servir como base para planejamento de empresas de médio e grande porte, a fim de diminuir os impactos, principalmente com a substituição de hardware e ajustes de softwares ainda não compatíveis. 15 4. Objetivo Específico Apresentar as diferenças entre as versões, a compatibilidade e os protocolos afetados; Listar alguns equipamentos ativos mais utilizados que sejam compatíveis com a versão 6 do protocolo IP; Expor os sistemas de segurança de maior utilização pelo mercado que já são compatíveis com a nova versão; Apresentar algumas práticas de configuração de ambiente que sejam mais apropriadas para o funcionamento com o IPV6. 16 5. Metodologia Foi realizado um estudo sobre as características da estrutura do protocolo IPv6 baseada em comparação com o IPv4 para melhor compreensão. Uma rica bibliografia foi utilizada para estudo, bem como bons sites da Internet, a fim de se obter dados suficientes para um correto entendimento sobre o assunto. As propostas de adaptação apresentadas neste trabalho estão totalmente fundamentadas no material de estudo e, em alguns casos, em experiências vividas e compartilhadas na Internet. 17 6. Escopo da pesquisa Este trabalho de pesquisa apresenta os prós e os contras de cada versão do protocolo TCP/IP baseado em literaturas diversas com o intuito de orientar os administradores de grandes redes sobre a melhor forma de migrar seu ambiente para esta nova versão. Para a parte 2 do trabalho, será tomada uma empresa fictícia, baseada em características de uma empresa de grande porte real. 18 7. Referencial Teórico O objetivo aqui é realizar um estudo detalhado sobre a versão 6 o protocolo IP. Para isso, faremos uma breve revisão sobre o protocolo IPv4 para melhor entendimento das novas funcionalidades do IPv6. 7.1. Apresentação do protocolo TCP/IP O TCP/IP é um protocolo baseado em 5 camadas (Figura 7.1.1) e apresenta as melhores condições de roteamento e serviços de rede. Estes serviços estão divididos em três grupos dependentes entre si conforme Figura 7.1.2. Aplicação Transporte Internet Interface de Rede ou Enlace Física ou de hardware Sistemas e aplicativos Verificação de erros Serviços de endereçamento lógico e roteamento Endereçamento físico (MAC) Infra-estrutura de rede (cabos, conectores, etc.) Figura 7.1.1 – Modelo de referencia do TCP/IP baseado em 5 camadas SERVIÇO DE APLICAÇÃO SERVIÇO DE TRANSPORTE CONFIÁVEL SERVIÇO DE ENTREGA DE PACOTES SEM CONEXÃO Figura 7.1.2 – Camadas conceituais dos serviços de internet (TCP/IP) Esta divisão facilita o desenvolvimento das pesquisas no sentido poderem seguir suas linhas de trabalho simultaneamente. O IP é definido como um sistema de entrega de pacote não-confiável, sem conexão e com a filosofia do melhor esforço. Não-confiável, pois a entrega do pacote não é garantida pelo protocolo. Quem faz a garantia são os protocolos adjacentes. Sem conexão pois o pacote não estabelece um único caminho para uma seqüência de quadros, ou seja, um dado pode ser fragmentado e cada 19 fragmento pode ser enviado por caminhos diferentes, sendo reagrupados e reorganizados no destinatário. O melhor esforço é caracterizado pela procura do caminho de menor custo para entrega do datagrama. Esta procura é realizada utilizando-se como base de referência, tráfego, banda disponível, retardo do canal, perda de pacotes e integridade do link. Na versão 4, o protocolo é totalmente compatível com os hardwares e softwares disponíveis no mercado. Já na versão 6, como ainda está em fase de projeto, os primeiros sistemas e equipamentos compatíveis estão começando a aparecer, depois de quase 10 anos de homologação do serviço. 7.2. Breve Histórico O protocolo IP teve sua origem na década de 70 quando o Defense Advanced Research Projects Agency (DARPA), um dos maiores financiadores de pesquisa de redes de comutação de pacotes, iniciou os trabalhos para a criação de uma tecnologia para interconexão de redes. O DARPA desenvolveu sua primeira rede utilizando a tecnologia IP que foi batizada de ARPANET. Em 1979, o grupo de pesquisadores interessados no desenvolvimento da tecnologia IP estava tão grande, que foi necessário a criação do comitê Internet Control and Configuration Board (ICCB) para coordenar os trabalhos. Nos anos 80 a ARPANET começou a se expandir interligando os centros de pesquisa. Como tal expansão apontava para uma grande massa de usuários, a Agência de Defesa nas Comunicações (DCA), que já havia ingressado à ARPANET, determinou uma separação em uma rede militar (que passou a ser chamada de MILNET) e outra rede de pesquisas (que permaneceu com o mesmo nome). 20 Nesta mesma época, a versão Berkeley ou Berkeley Software Distribution (BSD) do UNIX, incorporou o TCP/IP em seu Sistema Operacional, permitindo que mais de noventa por cento dos departamentos de ciência de computação das universidades estivessem interligados podendo realizar transferência de arquivos entre elas. A Berkeley também desenvolveu o socket, uma interface para que sistemas aplicativos pudessem acessar diretamente protocolos de comunicação, não somente para o TCP/IP, mas outros que já existiam na época. No final da década de 80, o crescimento da Internet já atingia uma taxa de 15% ao mês, chegando em 2005 com aproximadamente trezentos milhões de computadores distribuídos em 209 países. O Internet Architecture Board (IAB) foi o primeiro órgão regulador para criação de padrões de evolução da Internet, definindo quais protocolos fariam parte obrigatória do conjunto TCP/IP e quais seriam as suas políticas oficiais. Em 1989, milhares de pessoas já tinha a Internet como fonte de negócios, o que dificultava as implementações experimentais de novas idéias. Em função disso, o IAB teve que ser reestruturado, criando um grupo com mais representantes da comunidade. Este grupo ficou conhecido como Internet Engineering Task Force (IETF) e tornou-se responsável pela padronização de protocolos e outros aspectos técnicos. Para se registrar os trabalhos de pesquisa com o TCP/IP, foram utilizadas as Request for Comments (RFC)s de forma seqüencial e cronológica. Os conceitos, padrões e propostas de protocolos devem ser aprovadas pelo Internet Engineering Steering Group (IESG), um departamento do IETF, para que se tornarem oficiais. Estas RFCs podem ser obtidas no site do IETF (http://www.ietf.org). 21 O maior fomentador de demandas tecnológicas, não vem do crescente aumento da quantidade de conexões, mas sim da necessidade de tráfego que as novas aplicações e serviços exigem para funcionarem bem na Internet. Quando a rede mundial de computadores foi implementada, utilizava-se linha de comando para as transações de dados. Com o surgimento dos sistemas operacionais gráficos, vieram as aplicações Word Wide Web(www), o que representou um drástico aumento na utilização do canal de comunicação. Como a Internet está sempre evoluindo, as demandas por protocolos e equipamentos mais ágeis não param de crescer. Para se ter uma idéia, temos atualmente telefonia e vídeo sendo transitados via IP com alta definição e utilizando a mesma tecnologia de trinta anos. Na tabela abaixo apresentamos a evolução da expansão do uso da internet, bem como a quantidade de gerencias nacionais que foram sendo espalhadas pelo mundo para uma melhor administração da evolução. Tabela 7.2.1 – Tabela de evolução da Internet Número Número de computadores Ano de redes na rede 1980 10 10 2 10 3 10 5 10 6 1990 2000 10 5 10 7 10 8 Número de usuários utilizando a rede Número de gerentes 10 2 10 6 10 8 10 9 10 0 101 10 2 10 3 2005 Fonte:COMER(2006) Interligação de rede com TCP/IP, 5ª ed.) Frente ao apresentado na tabela acima, pesquisadores chegaram a uma estimativa de que a disponibilidade de endereços de rede se prolongaria até 2028 se houvesse um bom reaproveitamento dos endereços não utilizados. De qualquer forma, é consenso que duas coisas ficaram evidentes com base na estatística de crescimento da Internet: Aplicações mais sofisticadas como telefonia e 22 videoconferência funcionam muito bem na versão 4 do IP e, os serviços de CIDR e NAT conseguiram estender os endereços oficiais à quantidade necessária à demanda atual Levando em consideração que a versão 4 do IP, totalmente inalterada, já está funcionando muito bem a mais de 30 anos, chegamos à conclusão de que o projeto é bastante flexível e poderoso, uma vez que neste período “o desempenho do processador aumentou por três ordens de grandeza, os tamanhos típicos de memória aumentaram por um fator maior que 400 e a largura de banda dos enlaces de maior velocidade na Internet aumentaram por um fator de cento e cinqüenta mil” (COMMER, Douglas E., Interligação de redes com TCP/IP. V1, 5 ed. p.370). Dado a tudo isso, é que os pesquisadores do IETF convidaram representantes de muitas comunidades para participarem do processo de criação de uma nova versão do TCP/IP. Deste novo grupo de trabalho foram elaboradas algumas propostas para base do novo protocolo e a melhor delas foi denominada SIP que teve sua versão estendida chamada de SIPP. Desta proposta nasceu o IPng que posteriormente foi nominado de IPV6, pois a versão 5 apresentou uma série de erros e mal entendidos. Segundo COMER(2006), com a nova proposta para o IPV6, será possível se 24 alocar 10 endereços IP por metro quadrado da superfície do planeta. 23 7.3. Internet Protocol versão 4 (IPv4) Como dito na apresentação do protocolo, o IP não garante a entrega do pacote nem a seqüência de entrega, mas fornece informações para que a camada TCP (que é um protocolo orientado a conexão) possa realizar a reorganização dos frames. Como não é o objetivo deste trabalho explorar a versão 4 do protocolo IP, esta parte tem o objetivo apenas de referenciar sobre o funcionamento desta versão para servir de base para as comparações e entendimentos da versão 6. 7.3.1. Cabeçalho do DATAGRAMA IPV4 A figura abaixo apresenta um diagrama pedagógico da estrutura do VERSÃO DO IP (VERSION) TAMANHO DO CABEÇALH O (HLEN) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 TIPO DE SERVIÇO (TOS) COMPRIMENTO TOTAL SINALIZADOR DE FRAGMENTO (FLAG) IDENTIFICAÇÃO TEMPO DE VIDA DO DATAGRAMA (TIME TO LIVE) 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 datagrama IP. IDENTIFICADOR DE INICIO DO DATAGRAMA FRAGMENTADO (OFFSET FRAGMENT) CHECAGEM DE ERRO DO CABEÇALHO (HEADER CHECKSUM) PROTOCOLO IP DE ORIGEM IP DE DESTINO PREENCHIMENTO OPÇÃO DO IP DADOS .......... Figura 7.3.1.1 - Modelo do datagrama IP versão 4 Fonte: COMMER(2006, p. 48) O datagrama IP é tratado em nível de software, não exercendo qualquer influência na estrutura de hardware da rede. Por este motivo, os campos devem ser bem definidos. Façamos um breve estudo de cada um dos campos acima: 24 VERS – Possui quatro bits que identificam a versão do protocolo IP utilizada para a construção do datagrama. Este é o primeiro campo a ser verificado pelo equipamento de roteamento a fim de não haver interpretação errada do conteúdo do datagrama. Caso não seja compatível, o datagrama é descartado. HLEN – Informa o tamanho, em palavras de 32 bits, do cabeçalho IP. Um cabeçalho padrão, ou seja, sem a utilização dos campos OPÇÕES IP e PREENCHIMENTO, possui um tamanho 5. Isso porque os doze campos iniciais possuem tamanho fixo. TIPO DE SERVIÇO (TOS) IDENTIFICAÇÃO FLAG TIME TO LIVE PROTOCOLO IP DE ORIGEM IP DE DESTINO VERS 5x32 HLEN COMPRIMENTO TOTAL OFFSET FRAGMENT HEADER CHECKSUM OPÇÃO DO IP PREENCHIMENTO DADOS .......... Figura 7.3.1.2 – Modelo do cabeçalho IP versão 4 TIPO DE SERVIÇO – Especifica como tratar o datagrama. Este campo está subdivido em duas partes: Uma com dois bits ainda não utilizada e outra com 6 bits que irão auxiliar o equipamento de roteamento a escolher qual o melhor canal de comunicação, baseado nas políticas locais e informações sobre os meios físicos a ele conectados. TAMANHO TOTAL – Indica o tamanho total do datagrama em quantidade de octetos. Este tamanho inclui o cabeçalho e a parte de dados. Por possuir um tamanho de 16 bits, permite um tamanho máximo de datagrama de 65.535 (sessenta e cinto mil, quinhentos e trinta e cinco) bits ou 8192 bytes. 25 IDENTIFICAÇÃO – O datagrama possui uma identificação única e, juntamente com os campos, FLAG, OFFSET e TAMANHO TOTAL, auxiliam na remontagem do pacote fragmentado. Ele é copiado para cada fragmento de modo que o destinatário possa identificar quais fragmentos pertencem a qual pacote original. FLAG – Este campo tem por objetivo informar aos roteadores quando um datagrama pode ou não ser fragmentado e também, se o fragmento recebido pertence ao meio ou ao fim do datagrama original. OFFSET FRAGMENT – Sua finalidade é mapear onde se inicia cada parte do datagrama original em um fragmento, ou seja, se um datagrama de identificação X possuía um tamanho de 4500 octetos, em uma rede Ethernet padrão, ele será fragmentado em 3 partes onde a identificação será igual nos três, a flag do primeiro e do segundo indicarão que há outros fragmentos relacionados à mesma identificação e o offset irá indicar valores múltiplos de 1500. Isso auxilia na remontagem do datagrama original. TIME TO LIVE (TTL) – Indica o tempo de vida de um datagrama quando lançado na rede. Este tempo é dado em saltos (hops). O campo possui 8 bits, o que permite um TTL máximo de 255 saltos. O objetivo deste campo é cuidar para que pacotes com destinos desconhecidos não fiquem circulando na rede eternamente. PROTOCOLO – Especifica informações sobre a parte de dados do datagrama, ou seja, em qual protocolo de alto nível, como o Transmission Control Protocol (TCP) e o User Datagram Protocol (UDP), o datagrama foi montado. 26 HEADER CHECKSUN – Tem como objetivo garantir a integridade do cabeçalho do datagrama. É calculado a partir da técnica de complemento de um ou inversão. É realizado apenas para o cabeçalho, permitindo assim, que os protocolos superiores realizem sua própria checagem de erros. IP DE ORIGEM – Neste campo é inscrito o endereço do host que originou o datagrama afim de que o destinatário saiba para quem responder se for o caso. IP DE DESTINO – Informa aos equipamentos de roteamento para qual destino estes devem direcionar os datagramas. OPÇÃO DO IP – Não é um campo obrigatório, porém sua maior utilização aplica-se na parte de gerenciamento da rede. É um campo de tamanho variável subdividido em três subcampos: cópia – que tem por objetivo informar se o campo opção deve ou não ser copiado para todos os fragmentos do datagrama; classe opção – informa a que classe pertence a opção. Ela pode ser datagrama, controle de rede ou depuração e medição; numero opção – especifica, dentro da classe, qual o objetivo do datagrama. PREENCHIMENTO – Como o campo opção do IP é variável, o campo preenchimento tem como objetivo completar com zeros o cabeçalho para que o mesmo possua um tamanho que seja múltiplo de 32 bits. (NAUGLE, Matthew. Guia ilustrado do TCP/IP. 2001 / COMMER, Douglas. Interligação de redes com TCP/IP) 27 7.3.2. Endereçamento IPv4 O endereçamento IP serve para identificar univocamente um host em uma rede. Ele é organizado em quatro octetos que podem representar, além do endereço do host, a rede a qual este pertence. O endereçamento IPv4 é distribuído em cinco classes distintas que visam organizar as faixas de endereçamento padrão para distribuição de redes e hosts como mostra a tabela abaixo: Tabela 7.3.2.1 -Formas de endereçamento do primeiro octeto do endereço IP Classe A B C D E Endereço inicial 0 128 192 224 240 Endereço final 127 191 223 239 255 Binário inicial 00000000 10000000 11000000 11100000 11110000 Binário final 01111111 10111111 11011111 11101111 11111111 A classe D é utilizada para endereçamentos multicasting como veremos no item 7.3.6. Já a classe E possui aplicações especiais e não é utilizada para endereçamento de redes e estações. As classes A, B e C se aplicam à identificação de hosts de um modo geral, porém com alguns endereços reservados, ficando o endereçamento da seguinte forma: Classe A – 1.0.0.0 a 126.0.0 Classe B – 128.0.0.0 a 192.255.0.0 Classe C – 193.0.0.0 a 223.255.255.0 28 O endereço 0.0.0.0 somente é utilizado quando um novo host ingressa na rede e não possui um endereço. Trata-se de um broadcast para um serviço de DHCP que objetiva distribuir endereços IP dinamicamente. O endereço 127.0.0.0 também é conhecido com endereço de loopback. Este endereço é utilizado pelo software de protocolo para realizar testes na interface e não circula na rede. As classes têm como objetivo definir a quantidade de redes e de hosts dentro um sistema de numeração. Veja na tabela abaixo como fica a distribuição: Tabela 7.3.2.2 – Classes do endereçamento IP Classe A B Qtd redes 126 (28 63) 2 (16126) Qtd hosts 224 2 (16777214) 216 2 (65536) C (216 31) 2 (2031616) 28 2 (253) A subtração de dois do total da quantidade de hosts, deve-se ao fato de que, quando todos os bits da parte host do endereço estão “setatos” em zero, temos o endereço da rede geral e quando estes estão em um, representam um endereço de broadcast. 7.3.2.1. Subclasses do IPv4 As subclasses foram criadas de modo a se permitir a segmentação das classes oficiais em pequenas sub-redes que pudessem ser roteadas. Ela é aplicada em um endereço específico de uma classe válida a fim de aproveitar alguns octetos da parte host para o endereço de rede. 29 As classes possuem máscaras de rede próprias que são: Classe A – 255.0.0.0 (11111111.00000000.00000000.00000000) Classe B – 255.0.0.0 (11111111.11111111.00000000.0000000) Classe C – 255.255.255.0 (11111111.11111111.11111111.00000000) Ao se observar a representação binária das máscaras, podemos concluir que os “uns” agrupados forçam o octeto a representar a parte rede do endereço. Assim, se forçarmos alguns bits da parte host em “um”, podemos fazer com que esta também seja rede. Veja o exemplo abaixo: Endereço - 130.64.80.25 Classe B Máscara padrão – 255.255.0.0 ou /16 Máscara de sub-rede – 255.255.192.0 ou /18 Novas redes: 130.64.0.0 130.64.64.0 130.64.128.0 130.64.192.0 Observemos que com o simples acréscimo de dois bits para a máscara classe B, pudemos dividir a rede em quatro novas sub-redes. 7.3.2.2. Protocolo de Tradução de Endereços (ARP) Para que os endereços de Internet funcionem em uma rede física, é necessário que estes endereços lógicos (IP) estejam associados a um endereço físico (NIC ou assemelhados). Para isso, foi criado o protocolo ARP que está mais relacionado com a parte de hardware do que com o software em si. No caso das redes ethernet, toda vez que uma nova interface de rede é inserida no ambiente, um novo relacionamento entre seu NIC e seu endereço IP 30 deve ser realizado em cada estação da rede em um determinado domínio de colisão. A questão é que isso não acontece dinamicamente. É necessário que algum host faça uma requisição de um endereço físico a partir da informação do endereço lógico, ou seja, quando algum outro host quiser se comunicar com o novo equipamento. Para que isso aconteça, um broadcast especial é lançado na rede local com o endereço lógico de destino. Todos os hosts irão ouvir a solicitação mas apenas o que possuir tal endereço irá responder. Como o host destino também necessita atualizar sua tabela ARP, ele aproveita o datagrama de solicitação, extrai os dados do par IP/NIC e atualiza sua tabela. Justamente porque os NIC não são configurados pelos administradores da rede, essa tabela deve estar constantemente sendo atualizada. Isso acontece a cada vez que um determinado host recebe qualquer tipo de solicitação (broadcast, unicast ou multicast), ou quando o tempo de validade dos dados de sua tabela ARP expira. Neste último caso, um broadcast ARP é lançado na rede com o endereço lógico para que o destino devolva a solicitação com o NIC atualizado. Veja abaixo um diagrama de funcionamento do ARP: Tabela ARP 10.70.8.3 - 3c.ab.55.23.c6.ff 10.70.8.5 - 3c.b5.8e.73.55.a9 10.70.8.254 - aa.cb.45.78.b8.fc 10.70.8.66 - a6.87.32.b7.ee.76 10.70.8.20 - d4.55.ff.a8.66.b1 10.70.8.3 3c.ab.55.23.c6.ff 10.70.8.5 3c.b5.8e.73.55.a9 Roteador 10.70.8.254 aa.cb.45.78.b8.fc Broadcast ARP 10.70.8.20 Ethernet Resposta d4.55.ff.a8.66.b1 10.70.8.66 a6.87.32.b7.ee.76 10.70.8.20 d4.55.ff.a8.66.b1 Tabela ARP 10.70.8.3 - 3c.ab.55.23.c6.ff 10.70.8.5 - 3c.b5.8e.73.55.a9 10.70.8.254 - aa.cb.45.78.b8.fc 10.70.8.66 - a6.87.32.b7.ee.76 10.70.8.20 - d4.55.ff.a8.66.b1 Figura 7.3.2.2.3 – Representação do funcionamento do protocolo ARP 31 7.3.3. Roteamento Roteamento é a capacidade que alguns equipamentos possuem de interligar domínios de broadcast diferentes (entenda-se por domínio de broadcast as redes que pertencem à mesma rede lógica, definida por uma máscara ou sub-máscara). Esta atividade é mais comumente realizada por equipamentos que possuem a capacidade para roteamento (roteadores). Segundo COMMER(2006), na última edição do seu livro “interligação de redes com TCP/IP 5ª edição 2006”, o termo atualmente utilizado é encaminhamento ao invés de roteamento, mas será utilizado este último por questão de familiaridade global. O roteamento ou encaminhamento de frames está subdividido em dois tipos básicos: Entrega direta e entrega indireta. Roteamento com entrega direta Duas máquinas pertencem a uma mesma rede se os prefixos IP referentes a parte rede forem idênticos. Caso esta afirmativa não se aplique, os hosts pertencem a redes diferentes. Para que haja uma entrega direta do pacote, ou seja, para que dois hosts possam trocar informações sem a intervenção de um roteador, é necessário que a afirmativa do primeiro parágrafo deste item seja verdadeira. Roteamento com entrega indireta Se dois hosts pretendem se falar mas seus prefixos são diferentes, eles pertencem a redes diferentes, logo não podem se comunicar sem a intervenção de um roteador. Neste caso, o pacote é encaminhado para este equipamento que, normalmente interliga duas ou mais redes, para que o mesmo possa dar um 32 novo destino ao pacote. Ou seja, o roteador “retira” o pacote de uma rede e o “insere” em outra a ele diretamente conectada. Para que o roteador saiba para onde enviar o pacote, é necessário que o mesmo possua uma “tabela de roteamento” ou “tabela de encaminhamento”. Nesta tabela são armazenados apenas os endereços de rede às quais ele conhece. Esta tabela pode ser alimentada manualmente (rotas estáticas) ou automaticamente (rotas dinâmicas). Normalmente as redes que são armazenadas nesta tabela foram aprendidas por um processo semelhante ao da tabela ARP. A diferença é que ela não contém endereço físico até porque a rede é uma entidade virtual. Mas vale lembrar que os roteadores possuem uma tabela ARP para cada interface. Assim é possível ao roteador direcionar o datagrama para o próximo roteador ou host. Uma tabela de roteamento eficiente possui as informações como segue: Tabela 7.3.3.1 – Exemplo de informações de uma tabela de roteamento Destino Distância Rota Rede A 0 Direta Rede B 0 Direta Rede C 1 Roteador B Rede D 2 Roteador B Podemos observar que a tabela pertence a um roteador que está entre as redes A e B e que esta última é o caminho para se atingir as redes C e D. Na seqüência é apresentada uma figura para exemplificar a situação acima: 33 Rede A Rede D Roteador A Roteador C Rede B Roteador B Rede C Figura 7.3.3.1 – Esquema de interligação de redes com roteadores. Como podemos observar, a tabela apresentada pertence ao roteador A que se encontra localizado entre as redes A e B. E assim, cada roteador teria uma tabela semelhante. Isso facilita ao roteador a identificação do caminho ao qual ele deve submeter o datagrama. Existem vários protocolos que foram desenvolvidos especialmente para a alimentação desta tabela. Entre eles, os mais utilizados são: Border Gateway Protocol (BGP) – Tem a função de auxiliar os sistemas autônomos na comunicação entre si permitindo que estes propagem informações sobre destinos diretamente conectados ou cujas conexões sejam realizadas através deles. Este protocolo utiliza o TCP como transporte a fim de garantir a integridade da entrega. A tabela é alimentada de uma única vez quando o roteador é ligado. As 34 atualizações são realizadas na medida em que os datagramas vão sendo roteados. Routing Information Protocol (RIP) – Trata-se de um protocolo de roteamento que divulga suas rotas através da utilização de um broadcast realizado a cada trinta segundos baseado em vetor de distância, ou seja, qual o menor caminho para se chegar ao destino. A divulgação é feita por apenas um roteador dentro de um sistema autônomo. Os demais apenas aprendem estas rotas quando são divulgadas. Caso este roteador falhe, ou seja, se em 180 segundos não houver nova divulgação de rota, os demais zeram o contador de tempo de validade dos dados da tabela e um novo roteador é eleito para realizar tal atividade. Em função deste tempo de propagação de rotas, ele se torna lento para convergência de informações. Open Shortest Path First (OSPF) – Trata-se de um protocolo baseado em estado do enlace, ou seja, avalia qual o melhor caminho em termos de tráfego, distancia, confiabilidade, retardo do sinal, etc. Este protocolo não alimenta tabelas de rotas em si, mas levanta o estado das conexões dos roteadores vizinhos a partir de um roteador de divulgação. Com ele podem-se definir prioridades por tipo de serviço, bem como promover balanceamento de carga através de vários caminhos para um único destino. 35 7.3.4. Fragmentação A fragmentação foi implementada a fim de atender aos diversos tipos de meios de transmissão. Cada meio possui um tamanho diferente e normalmente é dado em octetos. As redes ethernet por exemplo, possuem uma “Unidade de Transferência Máxima (MTU)” de 1500 octetos. Cada fragmento de um datagrama possui um cabeçalho semelhante ao original. Isto objetiva manter a integridade da informação. Em cada processo de fragmentação, um cabeçalho novo é inserido no fragmento e a parte de dados é novamente fragmentada. Neste cabeçalho, os campos offset e flags são modificados em relação ao original, pois eles são responsáveis pela seqüênciação do datagrama fragmentado tornando-o possível de ser remontado no destino. Ident. -cabeçalho offset - 0 flag - 000 tamanho - 3020 octetos end. Orig - host A end. Dest - host B cabeçalho Ident. -cabeçalho offset - 0 flag - 000 tamanho - 3020 octetos end. Orig - host A end. Dest - host B Dados HOST A cabeçalho HOST B Ethernet Ethernet MTU = 1500 Ident. -cabeçalho offset - 0 flag - 001 tamanho - 1500 octetos cabeçalho Ident. -cabeçalho offset - 1480 flag - 001 tamanho - 1500 octetos Ident. -cabeçalho offset - 2960 flag - 000 tamanho - 60 octetos MTU = 600 Dados Ident. -cabeçalho offset - 0 flag - 001 tamanho - 600 octetos cabeçalho Da dos cabeçalho Dados Ident. -cabeçalho offset - 580 flag - 001 tamanho - 600 octetos cabeçalho Da dos cabeçalho Dados Ident. -cabeçalho offset - 1160 flag - 001 tamanho - 600 octetos cabeçalho Da dos Ident. -cabeçalho offset - 1740 flag - 001 tamanho - 600 octetos cabeçalho Da dos Ident. -cabeçalho offset - 2320 flag - 001 tamanho - 600 octetos cabeçalho Da dos Ident. -cabeçalho offset - 2900 flag - 000 tamanho - 120 octetos cabeçalho Da dos Figura 7.3.4.1 – processo de fragmentação do datagrama Dados 36 7.3.5. Encapsulamento Encapsulamento é o processo de “empacotamento” de dados seguindo um modelo de camadas. O OSI afirma que cada camada de um host de origem se comunica apenas com a sua camada equivalente no host de destino. Isso se deve ao fato de que cada nível possui um cabeçalho próprio que, para os níveis inferiores, representam apenas dados. Os níveis mais abaixo, obedecendo à hierarquia da pilha, não se preocupam com o conteúdo vindo das camadas superiores. No IP é acrescido o cabeçalho do datagrama e enviado para a camada subjacente onde serão acrescentados novos cabeçalhos até o momento em que o quadro é lançado na rede física. No destinatário, o processo é inverso, ou seja, os últimos níveis primeiro retiram seus cabeçalhos e repassam os dados para os níveis superiores conforme a F E Aplicação dado Apresentação encapsulament o R dado desencapsulamento figura abaixo: Aplicação dado Apresentação dado S dado Sessão T S dado Transporte T S dado Rede S dado Enlace Enlace F Física Física E R T R T S dado Sessão dado S Transporte dado S T Rede dado S T R dado S T R E S T R F dado Meio físico Figura 7.3.5.1 – Diagrama de encapsulamento conforme o Modelo OSI E F 37 7.3.6. Multicasting Multicasting é um mecanismo utilizado pelos níveis inferiores do OSI para direcionar um quadro de dados para mais de um host simultaneamente. A diferença em relação ao broadcasting está na maneira de propagação da mensagem que se difunde apenas em um grupo determinado e não para todos os hosts da rede. No IP, o multicasting possui as seguintes características: Endereço de grupo – cada grupo possui uma identificação única classe D. Número de grupos – Cada IP pode participar de até 2 28 grupos de multicasting diferentes. Este valor se deve às limitações do tamanho da tabela de roteamento. Associação de grupo dinâmico – Cada host pode se associar ou desassociar de grupos. Uso do hardware – O IP pode se utilizar da capacidade do hardware que propaga multicasting para difundir pacote para seu grupo. Caso esta facilidade não seja suportada pela controladora, o IP se utiliza do broadcasting ou do unicasting para implementar a facilidade. Encaminhamento de internet – Permite que hosts se conectem a outros grupos de multicasting em redes diferentes. Para tal facilidade, os roteadores devem ser capazes de rotear pacotes de multicasting. Semântica de distribuição – Os pacotes multicasting também seguem a filosofia de “caminho de melhor esforço”, ou seja, os datagramas podem ser fragmentados, sofrer retardos entre outros problemas como qualquer outro pacote. 38 Associação e transmissão – Qualquer host pode enviar datagramas a qualquer grupo de multicasting. A associação é declarada apenas para limitar quem recebe pacotes multicasting. 7.3.6.1. Endereçamento multicast IP Os endereçamentos multicast podem ser permanentes (ou conhecidos), que podem ser utilizados por protocolos de roteamento multicast ou transitórios que são criados quando necessário e se desfazem quando todos os membros se desvinculam do grupo. Um datagrama é identificado como sendo de multicasting, quando os quatro primeiros bits do campo “endereço de destino” do cabeçalho IP se inicia com a VERS HLEN TIPO DE SERVIÇO (TOS) 31 30 29 28 27 26 25 24 23 22 COMPRIMENTO TOTAL IDENTIFICAÇÃO TIME TO LIVE 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 seqüência 1110, ou seja, valores entre 224 e 239. FLAG OFFSET FRAGMENT PROTOCOLO HEADER CHECKSUM IP DE ORIGEM 1 1 1 0 I P D E D E S T I N O OPÇÃO DO IP PREENCHIMENTO DADOS .......... Figura 7.3.6.1.1– Cabeçalho IP com endereço de destino no formato de multicast Alguns endereços de multicast representam, como já mencionado, grupos fixos como por exemplo 224.0.0.12 que é o endereço utilizado para o serviço de DHCP e o 224.0.0.10 que atende ao serviço de roteamento utilizando IGRP. A próxima figura apresenta uma tabela com os endereços reservados mais utilizados. 39 Tabela 7.3.6.1.1 – Tabela com algumas atribuições definidas para grupos de multicast Endereço 224.0.0.1 224.0.0.2 224.0.0.9 224.0.0.10 224.0.0.12 Função Todos os sistemas da sub-rede Todos os roteadores da sub-rede Roteadores RIP2 Roteadores IGRP Serviço DHCP Os limites de propagação dos datagramas multicast podem ser controlados, utilizando o campo “tempo de vida” (TTL) em hops do pacote (0 para propagação local ou 1 para interpretação por parte do roteador, 2 para propagação em um hop, e assim por diante) ou pela configuração dos roteadores, bloqueando a propagação de qualquer datagrama com endereço de multicast. Para que haja roteamento de pacotes multicasting entre redes distintas, e até mesmo para que haja um controle de cadastro e descadastro de novos hosts nos grupos de multicast é necessário o protocolo IGMP. 7.3.6.1.1. Internet Group Management Protocol (IGMP) IGMP é um protocolo padrão TCP/IP responsável pela administração das associações e roteamentos de pacotes multicasting. Sua atividade pode ser desmembrada em duas etapas: Primeira etapa: Para que um novo host ingresse em um grupo, este deve enviar um pacote IGMP para o endereço multicasting do grupo de endereços solicitando sua inclusão. Os roteadores multicasting, por sua vez, recebem o datagrama e o propaga entre os outros roteadores das redes participantes. Segunda etapa: Em função das associações serem dinâmicas, os roteadores multicasting realizam ciclos periódicos de verificação de 40 permanência dos membros dos grupos. Se nenhum host responder pelo mesmo, o roteador deixa de propagar datagramas para os roteadores das redes adjacentes. O IGMP foi projetado para evitar congestionamento da rede com difusão desnecessária de datagramas. Visto que os grupos multicasting são dinâmicos, cabe dizer que as tabelas de roteamento para este serviço mudam toda vez que um host entra ou sai do grupo. Se um host pertencente a um grupo X e este quiser enviar um datagrama Multicasting para seu próprio grupo, o frame se propagará apenas para as redes que possua hosts pertencentes ao grupo. Caso o host pertença a um grupo diferente e queira mandar uma mensagem para um grupo onde nenhum host da sua rede seja membro, o roteador multicasting terá que identificar as redes que possuem membros cadastrados no grupo solicitado e propagar o datagrama para todas de uma única vez. Isso poupa banda de rede. 7.3.7. Virtual Private Network (VPN) Uma rede virtual privada parte do princípio de que se é possível criar um túnel pela internet de maneira que duas redes privativas possam usar os vários links públicos para se comunicarem com completa segurança. A VPN utiliza os conceitos de tunelamento e criptografia para realizar tal interligação de redes. O tunelamento consiste em se inserir um datagrama completo na parte de dados de outro datagrama. Se o interno for criptografado, todos os seus dados, inclusive endereços de origem e destinos não poderão ser decodificados por 41 terceiros que não possuam as “chaves de criptografia” adequadas. A figura abaixo descreve melhor esta situação. Datagrama interno criptografado com cabeçalho Cabeçalho do datagrama IP Área de dados do datagrama externo Figura 7.3.7.1 – Encapsulamento de um datagrama IP criptografado em outro datagrama IP para comunicação VPN Desta maneira, se é possível encaminhar pacotes entre redes privadas utilizando o canal público. Mesmo assim, ainda encontramos problemas quando os hosts da rede interna necessitam acessar também a rede pública, pois normalmente as corporações não possuem um IP válido para cada host de sua rede local. Para solucionar tal problema, foi criada a tecnologia de NAT, ou tradução de endereços. 7.3.8. Network Address Translation (NAT) Essa tecnologia visa permitir que endereços não válidos possam se comunicar com endereços públicos sem gerar conflitos de endereços repetidos. O NAT pode atuar de duas maneira: um-para-um e um-para-muitos No modo um-para-um, apenas um endereço interno pode se comunicar com outro público, ou seja, se possuíssemos apenas um endereço válido, apenas uma estação por vez poderia se comunicar com o mundo externo. Já na configuração um-para-muitos, um único endereço válido permite que vários endereços internos se comuniquem com vários sites externos utilizando um mesmo endereço de saída. 42 O NAT é um serviço do nível de transporte baseado em TCP. Ele, associado aos protocolos de roteamento, permite as ações descritas acima. Quando o datagrama é roteado de uma rede privada para uma rede pública, o nível de transporte cria uma tabela de-para a fim de organizar as associações entre os endereços públicos e privados. 7.3.9. Dynamic Host Configuration Protocol (DHCP) Trata-se de um protocolo do tipo BOOTP que tem por objetivo proporcionar o serviço de distribuição de endereços IP válidos para uma intranet. Este serviço pode ser configurado de três maneiras diferentes: - Configuração manual: O gerente de rede define que determinado MACADDRES irá possuir sempre o mesmo endereço. - Configuração automática: O gerente de rede configura o servidor DHCP para distribuir um endereço permanente para cada host da rede local - Configuração Dinâmica: O serviço DHCP é configurado para “alocar”, por um intervalo de tempo pré-determinado, um endereço para cada host. Quando este tempo estiver vencendo, o host deverá renegociar a alocação deste endereço. Caso o endereço não seja renegociado com o servidor, ele é liberado e será utilizado por outro host. Por se tratar de um protocolo do nível de transporte baseado em UDP, seu pacote é encapsulado em um datagrama IP. Os servidores necessitam desencapsular o pacote ao nível de transporte para realizar a identificação do mesmo. 43 7.3.10. IP Security (IPsec) Trata-se de um conjunto de protocolos criados pelo IETF a fim de garantir comunicação de dados de forma segura pela internet utilizando-se de duas facilidades básicas: - Autenticação: onde as partes (hosts), ou apenas uma delas, realizam um processo de autenticação para garantir que um host não será “clonado” por outro mal intencionado. - Criptografia: tem por objetivo criptografar o datagrama utilizando o mesmo algoritmo em ambos os hosts que querem se comunicar. Uma representação básica para o datagrama seria a seguinte: Cabeçalho IPV4 Cabeçalho de autenticação Cabeçalho TCP Tamanho do payload Próximo cabeçalho Índice de Parâmetros de Segurança Número de seqüência Dados de Autenticação (variável) ... Dados TCP reservado Figura 7.3.10.1 – Detalhamento do cabeçalho do IPsec Para este protocolo, existe um cabeçalho próprio que é inserido entre o cabeçalho IP e a sua parte de dados e é identificado pelo roteador, analisando o campo PROTOCOLO que deve estar preenchido com o valor 51. - Próximo Cabeçalho – armazena o valor original do campo cabeçalho do cabeçalho IP. Com isso, é possível a multi e demultiplexação do datagrama para se tratar o conteúdo original. 44 - Tamanho do Payload – Especifica o tamanho do cabeçalho de autenticação - Índice de Parâmetros de Segurança – Especifica o esquema de segurança utilizado - Número de Seqüência – armazena o número de seqüência exclusivo para cada datagrama - Dados de Autenticação – contém os dados de segurança para o esquema selecionado. Para que o destinatário saiba que está recebendo uma seqüência de datagramas com criptografia Encap Security Payload (ESP), o campo PROTOCOLO do cabeçalho IP deve estar setado com o valor 50. Como este campo não possui um tamanho fixo, o subcampo PRÓXIMO CABEÇALHO marca que a informação não foi transmitida completamente no datagrama corrente. Cabeçalho IPV4 Cabeçalho ESP Autenticado Criptografado Cabeçalho TCP Dados TCP Término ESP Autenticação ESP Figura 7.3.6.5.2 – Detalhamento do cabeçalho do IPsec utilizando ESP Como podemos observar, a inserção dos campos em vermelho delimitam a área a ser criptografada e autenticada. Desta maneira, o cabeçalho de transporte bem como os dados são codificados dificultando a visualização do seu conteúdo por hosts não autorizados. Vale atentar que o IPsec não analisa os campos mutáveis em seus cálculos de integridade do datagrama (check sun). O TTL é utilizado pelos roteadores para a 45 checagem de erros. Isso é feito porque os campos “mutáveis” durante o percurso entre uma origem e um destino podem afetar nos cálculos da criptografia. 46 7.4. Internet Protocol versão 6 (IPv6) A versão 6 do protocolo IP, nada mais é do que uma melhoria da versão 4, uma vez que esta última, conforme dito no item 7.2 é um projeto muito flexível e estável. O principal argumento então seria a re-estruturação do formato de endereçamento de modo a atender a carência de alocações públicas. Tanto é verdade que, como será observado neste trabalho, poucas diferenças de funcionamento apareceram e a transparência de comunicação entre as versões foi preservada. As limitações estão mais presentes nos hardwares e firmwares que em alguns casos, poderá haver a necessidade de substituição. Esta parte do trabalho seguirá a mesma seqüência apresentada na versão 4 afim de facilitar a percepção das diferenças. 7.4.1. Cabeçalho do DATAGRAMA IPv6 VERSÃO DO IP (VERSION) CLASSE DE TRÁFEGO (CLASS) RÓTULO DE FLUXO (FLOW LABEL) TAMANHO DO PAYLOAD (PAYLOAD LABEL) PRÓXIMO CABEÇALHO (NEXT HEADER) LIMITE DE SALTOS (HOP LIMIT) .......... ENDEREÇO DE ORIGEM (SOURCE ADDRESS) ENDEÇO DE DESTINO (DESTINATION ADDRESS Figura 7.4.1.1 - Modelo do datagrama IP versão 6 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Vejamos como ficou o novo cabeçalho com o IPv6: 47 Como podemos observar, o novo cabeçalho foi simplificado em relação à versão 4 em termos de campos de controle, porém o seu tamanho passou de 20 bytes para 40 que é fixo para qualquer tipo e tamanho de datagrama. Isso se deve principalmente devido ao novo tamanho do endereço que passou de 4 para 16 octetos como veremos no item 7.4.2. Abaixo segue a função de cada campo: VERS – É praticamente o único campo que não foi modificado, ou seja, tem como função identificar a versão do cabeçalho do datagrama. No caso da versão 6, ele vem setado como 0110. Class – A classe de tráfego possui função semelhante ao campo Type of Service (TOS), ou seja, definir a prioridade do datagrama em um mecanismo de roteamento. Na versão 6, é possível ao roteador distinguir tipos de tráfego como: o “Controlado por congestionamento” (congetion- controlled) - pacotes são retirados da rede quando o índice de utilização do canal está muito alto. Possui 7 níveis de prioridade e seleção do que será descartado, seguindo a ordem da tabela 7.4.1.1, ou seja, datagramas de FTP possuem prioridade sobre os datagramas de e-mail, login remoto, sobre os de FTP e assim por diante. o “Não controlado por congestionamento” (noncongestioncontrolled) – Os datagramas de prioridade inferior são descartados para priorizar o tráfego de datagramas com prioridades mais altas. São sete níveis (8 a 15) mas não possuem atribuições especificadas. Esta classe de dados 48 normalmente é caracterizada por informações que exigem transmissão em tempo real. Exemplos de serviços que utilizam essa classe, seira a transmissão de áudio e vídeo de alta definição. Flow Label – Tem como função definir um controle de fluxo relacionado com o tipo de aplicação. Cada host, ao estabelecer uma comunicação com outro em uma rede distinta, informa um valor neste campo. O roteador memoriza-o a fim de criar uma espécie de reserva de banda para essa comunicação. Caso este host deixe de usar esse “canal” o roteador libera essa reserva para outras comunicações. Essa reserva dura aproximadamente seis segundos após o encerramento do ultimo datagrama trafegado. Isso acontece para evitar que um host tente utilizar o mesmo rótulo para comunicações distintas pelo mesmo roteador. Uma vez estipulado o rótulo de fluxo e respeitando o prazo de validade em um roteador, o serviço de roteamento não irá mais verificar dados do datagrama uma vez que no primeiro enviado, estas informações já foram armazenadas pelo roteador. A associação entre a CLASE DE TRÁFEGO, RÓTULO DE FLUXO e ENDEREÇO DE ORIGEM, geram uma identificação única na comunicação de dados. Tamanho do payload – Informa o tamanho do datagrama sem o cabeçalho. Se este for maior que 64KB (jumbogramas), um outro cabeçalho (cabeçalho de opção) entrará no datagrama informando o tamanho real. 49 Next header – Apresenta qual o tipo de cabeçalho virá imediatamente seguinte ao cabeçalho base (no IPv6 um datagrama pode conter vários cabeçalhos anexados). Equivale, de certo modo, ao campo PROTOCOLO do IPv4. Tanto que os protocolos do nível superior ainda continuam valendo como pode ser visto na tabela 7.4.1.2. Mas este campo vai além de informar apenas o protocolo. O IPv6 permite a criação de cabeçalhos de extensão (ou cabeçalhos concatenados) para definir qual o serviço do datagrama. Hop-Limit – É a duração do datagrama em uma rede definido em “saltos” de um roteador para outro. Ele é equivalente ao campo TTL do IPv4, com uma única diferença teórica. No TTL, a unidade de medida é o segundo, mas já foi comprovado que os roteadores atuais conseguem transmitir datagramas entre si, em intervalos de tempo bem inferiores a 1s. Como em cada roteador é decrementado um no valor deste campo, praticamente o tempo de vida é contado em saltos que duram menos que 1s. Source Address – Este campo de 128 bits, assim como no IPv4, indica qual o endereço de origem do datagrama. Destination Address – Informa o endereço de destino da informação. 50 Tabela 7.4.1.1 – Tabela de classes de datagramas para tráfego controlado por congestionamento Valor de prioridade 0 1 2 3 4 5 6 7 Especificação da prioridade Prioridade não especificada Tráfego em background Transferências não continuadas (ex. e-mail) Reservado para definições futuras Transferências continuadas de grandes volumes (ex. FTP) Reservado para definições futuras Tráfego interativo (ex. logins remotos) Controle de tráfego (ex.: protocolos de roteamento e gerencia de redes) Fonte: THOMAS(1996 p.98) Tabela 7.4.1.2 – Tabela de protocolos válida para o campo NEXT HEADER Código do protocolo 0 1 2 3 4 5 6 8 17 41 43 44 50 51 58 59 60 Descrição Reservado ICMP IGMP GGP IP (encapsulamento IP) Stream TCP EGP UDP IPv6 Roteamento Fragmentação ESP AH ICMPv6 Sem próximo cabeçalho Opções de destinação Fonte:MURHAMMER, Martin W. et all(2000 p.49),MILLER(1997, p.40) 51 7.4.1.1. Cabeçalhos Concatenados IPv6 Essa é uma das grandes inovações da versão 6 do IP que na versão 4, era utilizado apenas na criptografia ESP. Isso permite uma maior flexibilidade do datagrama que irá agilizar na comunicação dos dados entre os roteadores. Observe a figura 7.4.1.1.1: Version Class Version Class Flow label Payload lengh Version Class Flow label Payload lengh Version Class Flow label Payload lengh Version Class Flow label Payload lengh Flow label Payload lengh Next header Hop limit Source address Destination address Next reader TCP header Next reader Routing header Next reader Fragment header Next header Hop limit Source address Destination address Hop limit Source address Destination address Hop limit Source address Destination address Source address Destination address Data Data TCP header Routing header Next header TCP header Fragment header Next header Routing header Hop limit Data TCP header Routing header Next header TCP header Data TCP header Data Figura 7.4.1.1.1 – Conceito de cabeçalhos concatenados Fonte: Mark (1997,p.41 e 45) Como podemos ver, os cabeçalhos de extensão e serviços são anexados entre os dados e o endereço de destino. Todos eles possuem um campo PROXIMO CABEÇALHO de 8 bits como o apresentado no cabeçalho principal. Porém a quantidade de cabeçalhos que podem ser anexados é limitada e segue uma ordem numérica (apesar do destino não checar tal ordem, ela facilita nas atividades de roteamento) conforme apresentado na tabela 7.4.1.2. 52 Os cabeçalhos de extensão também possuem campos próprios referentes aos serviços a eles atribuídos. Na próxima figura temos uma visão mais detalhada VERSION=6 CLASS=6 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 de um datagrama com alguns cabeçalhos de extensão. FLOW LABEL=80 PAYLOAD LENGTH=64Bytes NEXT HEADER=0 HOP LIMIT=255 .......... ENDEREÇO DE ORIGEM (SOURCE ADDRESS) ENDEREÇO DE DESTINO (DESTINATION ADDRESS NEXT HEADER=43 HEADER LENGTH Hop by Hop options NEXT HEADER=44 HEADER LENGTH Routing Options NEXT HEADER=51 HEADER LENGTH Fragment Identification NEXT HEADER=6 HEADER LENGTH Authentication Data TCP header and Data Figura 7.4.1.1.2 – Composição de um datagrama IPv6 com os cabeçalhos de extensão Fonte: STEPHEN(1996, p.108), TCP/IP Tutorial e Técnico(2000, p. 352) e MARK(1997, p.45) Observe que cada campo PROXIMO CABEÇALHO aponta para o campo de informações do cabeçalho seguinte. Cada cabeçalho também possui um tamanho próprio dependendo do seu tipo e seu valor sempre será múltiplo de 8. Na seqüência do trabalho, veremos melhor alguns cabeçalhos. 53 7.4.2. Cabeçalho Hop by Hop options (salto a salto) Este cabeçalho tem por objetivo informar aos “nós” por onde ele passa, incluindo o próprio destinatário, sobre o tamanho do datagrama (se for do tipo JUMBO), características de criação do pacote e ações do roteador conforme sua interpretação do datagrama. Sua opção de extensão é variável no formato Type- HEADER LENGTH NEXT HEADER TYPE 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Length-Value (TLV) conforme podemos ver no esquema abaixo: LENGTH VALUE (de tamanho variável) Figura 7.4.2.1 – Composição do cabeçalho hop-by-hop Fonte: MARK(1997, p.46) XX Y 7 6 5 4 3 2 1 TYPE – Possui tamanho de 8 bits e segue a representação abaixo: 0 ZZZZZ Figura 7.4.2.2 – Formato do campo TYPE Fonte: TCP/IP Tutorial e Técnico (2000,p 353) o XX – Informa como um nó que não reconhece o tipo do datagrama deve processá-lo. Veja a tabela abaixo Tabela 7.4.2.1 – Valores de tipo de tratamento de datagramas pelos nós da rede Fonte: MARK(1997, p.48) e TCP/IP Tutorial e Técnico (2000,p. 353) Valor Descrição 00 Pula a opção e continua processando o cabeçalho 01 Descarta o pacote Descarta o pacote e envia uma mensagem ICMP ao remetente de que o pacote não foi 10 reconhecido Descarta o pacote e envia uma mensagem ICMP ao remetente (se o endereço de 11 destino não for um multicasting) de que o pacote não foi reconhecido 54 o Y – Informa se o valor do campo VALUE pode ser modificado ao passar pelos nós da rede. Se 0, não pode haver modificação. Se 1 pode haver modificação o ZZZZZ – Informa quantos bytes de preenchimentos serão utilizados para manter o campo VALUE com tamanho múltiplo de 8. Isso acontece pois os “limites naturais de palavras” nos processadores modernos são de 16 ou 64 bits. Quando este campo está setado para 0, indica que usaremos PAD1, ou seja, apenas um byte será preenchido. Qualquer outro valor entre 1 e 194 informa a quantidade de bytes de preenchimento foram utilizados. O valor 194 informa que o datagrama é do tipo JUMBO. LENGTH – Apresenta o tamanho do campo VALUE em bytes VALUE – Depende do tipo do cabeçalho. 7.4.3. Cabeçalho Destination options Igualmente ao cabeçalho hop by hop, este cabeçalho tem por objetivo informar sobre o tamanho do datagrama (se for do tipo JUMBO), características de criação do pacote e ações do roteador conforme sua interpretação. A única diferença é que as informações aqui contidas são de interesse único do destinatário. Tanto que a maioria das literaturas trata os dois cabeçalhos em um único item. Este cabeçalho é opcional e mais utilizado por sistemas de criptografia na comunicação. 55 7.4.4. Cabeçalho Routing O cabeçalho de roteamento tem como objetivo permitir que o host de origem possa definir o caminho pelo qual o datagrama deve passar. Isso é possível uma vez que a origem deve conhecer todos os MTUs pelos quais seu pacote deverá passar afim de retirar dos roteadores a tarefa de fragmentação. Uma vez conhecendo os MTUs, as informações de largura de banda e confiabilidade também podem ser recebidas. Com isso o host pode mandar pacotes que necessitem de mais segurança por um caminho específico e os demais por NEXT HEADER HEADER LENGTH ROUTING TYPE RESERVED 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 rotas livres. Vejamos abaixo o diagrama do cabeçalho de roteamento. SEGMENTS LEFT STRICT/LOOSE BIT MAP ADDRESS (1) ADDRESS (2) .................. ADDRESS (N) Figura 7.4.4.1 – Formato do cabeçalho de roteamento Fonte: MARK(1997, p.50) ROUTING TYPE – Define o tipo de roteamento para o datagrama. Atualmente apenas o valor 0 pode ser atribuído. Este valor permite um roteamento de origem Fixo/Livre (STRICT/LOOSE). SEGMENTS LEFT – indica quantos nós faltam para que o datagrama atinja seu destino. Ele é decrementado toda vez que o datagrama passa por um nó apontado no campo DESTINATION ADDRESS do cabeçalho básico. RESERVED – Inicializado como 0 na transmissão e ignorado na recepção. 56 STRICT/LOOSE BIT MAP(S/L) – Atualmente existem dois valores básicos para este campo. o 1 (strict) – A origem especifica qual será o caminho pelo qual o roteador deverá passar. o 0 (loose) – Indica que o datagrama pode ser conduzido conforme orientação dos próprios roteadores durante o percurso entre uma origem e um destino, ou seja, não há regras que definam o percurso. ADDRESS 1 a N – Caso o campo STRICT/LOOSE BIT MAP esteja setado para 1, estes campos irão determinar os endereços pelos quais o datagrama deverá “viajar”. Como já foi dito, os campos de endereços representam o “mapa de viagem” do datagrama. À medida que em que o pacote percorre a rede, o campo SEGMENT LEFT vai sendo decrementado e o campo DESTINATION HOST do cabeçalho básico vai recebendo o próximo endereço da lista. Veja a ilustração 7.4.4.2 que representa bem essa rotina. Observe que os campos de endereços vão sendo trocados à medida em que o datagrama passa por um nó de roteamento. Cada endereço usado é transferido para o topo da lista. 57 Ver=6 Class=4 Payload Length=64 Next Header=43 Next Header=X Reserved=0 Flow Label=80 Next Header=0 Hop Limit=255 Ver=6 Class=4 Payload Length=64 Flow Label=80 Next Header=0 Hop Limit=252 Source Addres=Work1 Source Addres=Work1 Destination=RouterA Destination=Work2 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=3 Strict/Loose bit map=1 Address=RouterB Address=RouterC Adress=Work2 Next Header=43 Next Header=X Reserved=0 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=0 Strict/Loose bit map=1 Address=RouterA Address=RouterB Adress=RouterC Datagrama Work1 Datagrama Work 2 Router B Datagrama Datagrama Router A Ver=6 Class=4 Payload Length=64 Next Header=43 Next Header=X Reserved=0 Flow Label=80 Next Header=0 Hop Limit=254 Router C Ver=6 Class=4 Payload Length=64 Flow Label=80 Next Header=0 Hop Limit=253 Source Addres=Work1 Source Addres=Work1 Destination=RouterB Destination=RouterC Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=2 Strict/Loose bit map=1 Address=RouterA Address=RouterC Adress=Work2 Next Header=43 Next Header=X Reserved=0 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=1 Strict/Loose bit map=1 Address=RouterA Address=RouterB Adress=Work2 Figura 7.4.4.2 – Mecanismo de funcionamento do cabeçalho de roteamento com S/L=1 7.4.5. Cabeçalho Fragment Como já mencionado na introdução do item 7.4.4, a origem deve conhecer qual o menor MTU do caminho pelo qual o seu datagrama deve passar. Uma vez de posse dessa informação, a origem deverá particionar (se necessário) seu pacote em fragmentos que atendam a esse valor de transmissão. O cabeçalho de fragmentação tem esse propósito. 58 NEXT HEADER RESERVED FRAGMENT OFFSET RESERVED RES 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Esse cabeçalho possui o valor 44 e segue o seguinte formato: M STRICT/LOOSE BIT MAP ADDRESS (1) Figura 7.4.5.1 – Formato do cabeçalho de fragmento Fonte: MARK(1997, p.54) NEXT HEADER – Indica o endereço do próximo cabeçalho de extensão. RESERVED – Ainda sem aplicação prática, é inicializado com 0 na origem e ignorado no destino. FRAGMENT OFFSET – Assim como no IPv4, este campo de 13 bits indica a posição, em unidades de 8 bytes, relativa ao inicio dos dados do fragmento. RES - Ainda sem aplicação prática, é inicializado com 0 na origem e ignorado no destino. M – Este campo indica se o datagrama é o último fragmento de uma seqüência. Se setado em 1, ainda há fragmento. Se 0, não há mais fragmentos. IDENTIFICATION – Assim como no IPv4, este campo oferece uma identificação única ao fragmento, porém seu tamanho é duas vezes maior. Um datagrama de fragmentação deve ser montado em duas partes: A parte não fragmentável que consiste do cabeçalho básico, com o endereço de destino conforme indicado no item 7.4.4 (cabeçalho routing), seguido dos cabeçalhos de 59 extensão hop-by-hop, destination e routing e a parte fragmentável, que contém os fragmentos do pacote. A parte não fragmentável acompanha cada datagrama contendo um fragmento do pacote como mostra a figura 7.4.5.2. A ilustração apresenta um pacote com 2902 Bytes e deve passar em um enlace com MTU de 1500 Bytes, incluindo o cabeçalho básico e os cabeçalhos de extensão. Observe que os datagramas devem possuir tamanhos em múltiplos de 8 Bytes. Sendo assim, cada fragmento poderá possuir um tamanho máximo de 1496 bytes. O campo FRAGMENT OFFSET indica onde começa o datagrama do fragmento que no exemplo apresenta múltiplos de 187 (pois a unidade de medida do OFFSET é palavra de 8 bytes. Logo, 187*8=1496 bytes). Outra observação importante é o tamanho do payload. Como já mencionado anteriormente, seu valor apresenta o tamanho do datagrama sem o cabeçalho básico do IPv6 (40 bytes). 60 Ver=6 Class=4 Payload Length=1456 Flow Label=80 Next Header=0 Hop Limit=255 Source Addres=Work1 Datagrama 1 1496 bytes Destination=RouterA Next Header=43 Next Header=44 Reserved=0 Next Header=6 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=3 Strict/Loose bit map=1 Address=RouterB Address=RouterC Adress=Work2 M=1 Reserved=0 Fragment Offset=0 Identification=0x12345678 Payload Data (1420 bytes) Ver=6 Class=4 Payload Length=64 Flow Label=80 Next Header=0 Hop Limit=255 Ver=6 Class=4 Payload Length=1456 Source Addres=Work1 Flow Label=80 Next Header=0 Hop Limit=255 Source Addres=Work1 Destination=RouterA Next Header=43 Next Header=X Reserved=0 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=3 Strict/Loose bit map=1 Address=RouterB Address=RouterC Adress=Work2 Destination=RouterA Datagrama 2 1496 bytes Next Header=43 Next Header=44 Reserved=0 Next Header=6 Payload Data (2902 bytes) Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=3 Strict/Loose bit map=1 Address=RouterB Address=RouterC Adress=Work2 M=1 Reserved=0 Fragment Offset=187 Identification=0x12345678 Payload Data (1420 bytes) Ver=6 Class=4 Payload Length=138 Preparação para encaminhamento do pacote em um MTU de 1500 bytes Flow Label=80 Next Header=0 Hop Limit=255 Source Addres=Work1 Destination=RouterA Datagrama 3 178 bytes Next Header=43 Next Header=44 Reserved=0 Next Header=6 Type=1 Header Length Length=8 Value=X Header Length=96 Routing Type=0 Segment Left=3 Strict/Loose bit map=1 Address=RouterB Address=RouterC Adress=Work2 M=0 Reserved=0 Fragment Offset=374 Identification=0x12345678 Payload Data (62 bytes) Figura 7.4.5.2 – Processo de fragmentação de um datagrama Fonte:STEPHEN(1996, p.118) 61 Para se calcular o tamanho máximo dos datagramas de fragmentação em relação ao menor MTU pelo qual esses irão passar, usa-se a seguinte equação: MTU (bytes) (int) 8 datagrama(bytes) 8 Ex.: 1500 187 8 1496bytes 8 Sabendo-se o tamanho dos cabeçalhos básico e de extensão em bytes, podemos calcular também, quanto de dados irá em cada datagrama utilizando a seguinte fórmula: datagrama(bytes)-Cab.basico(bytes)-cab.ext.1(bytes)-cab.ext.N(bytes)=payload(bytes) Ex.: 1496-40(cab.basico)-8(cab.hop-by-hop)-20(cab.routing)-8(cab.fragment)=1420bytes Já o cálculo do OFFSET é dado pela seguinte fórmula: datagrama(bytes) OFFSET 8 Ex.: 1496 187 8 Em cada fragmento, o campo OFFSET receberá múltiplos do valor calculado. 62 7.4.6. Cabeçalho Authentication Este é o cabeçalho de extensão responsável pelo provimento de integridade e autenticação dos datagramas. Seu código de acionamento é o 51. Um datagrama contendo um cabeçalho Authentication Header (AH) não pode ser fragmentado pela origem. Caso os equipamentos roteadores detectem comportamento de fragmentação em datagramas com AH, estes serão descartados. Isso evita tentativas de ataque por “sobreposição de fragmentos”. Neste caso, os pacotes são descartados em nível de IP, o que garante uma considerável redução em “ataques de negação”. NEXT HEADER PAYLOAD LENGHT 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Vejamos o diagrama do cabeçalho de autenticação: RESERVED SECURITY PARAMETERS INDEX (SPI) SEQUENCE NUMBER AUTHENTICATION DATA (tamanho variável) Figura 7.4.6.1 – Formato do cabeçalho de autenticação Fonte: MARK(1997, p.57) PAYLOAD LENGHT – Este campo apresenta o tamanho do cabeçalho em palavras de 32 bits – 2, ou seja, é o tamanho total do cabeçalho menos os campos NEXT HEADER, PAYLOAD LENGHT, RESERVED e SIP. Seu tamanho mínimo é 1 indicando que apenas o campo SEQUENCE NUMBER será preenchido. RESERVED – Este campo de 16 bits é destinado para uso futuro. Ele é inicializado com zero mas está incluído no calculo dos dados de autenticação, porém é desprezado pelo destinatário. SECURITY PARAMETERS INDEX – Este campo, associado com o ENDEREÇO DE DESTINO, definem uma relação que garante 63 segurança à comunicação e identifica diferentes Security Associations (SAs) para um mesmo destino. Os valores vão de 0 a 255. O 0 é utilizado para implementação local e os demais valores são reservados pela Internet Assigned Numbers Authority (IANA) atualmente chamada de Internte Corporation forAssigned Names and Numbers (ICANN), que é a entidade responsável pelo controle de endereços IP oficiais da internet. Se for utilizado o algoritmo padrão( que atualmente é o Message Digest 5 (MD5), a autenticação dos dados consiste de 16 bytes. Uma chave de autenticação deve ser utilizada pelo computador que inicia a comunicação. Ela deve possuir um tamanho de 128 bits, caso isso não ocorra, vários zeros são incluídos até que a chave atinja o tamanho mínimo requerido. Como alguns campos do datagrama, como o hop limit, são variáveis, esses 128 bits transportam a autenticação dentro do datagrama baseada em cálculos que desprezam esses campos. No destino, o mesmo processo é utilizado. Se os dados enviados e o cálculo realizado forem diferentes, indica que o datagrama não é autentico. SEQUENCE NUMBER – Trata-se de uma seqüência de crescimento monotônico utilizada para proteger a resposta do destinatário. Este não tem obrigação de interpretar este campo. Quando uma SA é estabelecida, esse campo é preenchido com 1 no primeiro datagrama enviado e o seu valor máximo é de 232 1 . Quando a seqüência atinge seu limite, uma nova SA deve ser iniciada e consequentemente uma nova seqüência no campo. 64 AUTHENTICATION DATA – Este campo de tamanho variável e múltiplo de 32 também é conhecido por ICV (Integrity Check Value). Este valor de integridade é calculado na inicialização da SA e despreza os campos mutáveis durante a navegação na rede considerando seus valores sempre como zeros. Vários algoritmos MAC podem ser utilizados para realização destes cálculos. A RFC 1826 recomenda a utilização do MD5, mas o HMACMD5-96 e o HMAC-SHA-1-96 também se aplicam. O cabeçalho de autenticação (AH) pode ser utilizado de duas maneiras: Modo Transporte – modo utilizado apenas pelos hosts e não tratado pelos roteadores, apesar de exigir menos processamento por parte destes, não autentica os campos mutáveis. Modo Túnel – utilizado sempre que se quer utilizar “tunelamento”. Esse conceito se aplica quando um datagrama IP transporta outro como sendo seu conteúdo. Neste caso o AH é calculado depois do “encapsulamento” de um datagrama em outro. Cabeçalho IPv6 Dados Datagrama IP original Novo Cabeçalho IPv6 Cabeçalho IPv6 Dados Datagrama “tunelado” Novo Cabeçalho IPv6 Cabeçalhos Cabeçalho de extensão AH Cabeçalho IPv6 Datagrama com cabeçalho AH em modo túnel Figura 7.4.6.2 – Encapsulamento IP sobre IP Fonte: (TCP/IP Tutorial e Técnico,p.293) Dados 65 Vale observar que no novo cabeçalho IPv6 da figura, os campos mutáveis não entram nos cálculos do AH conforme já mencionado. A RFC 1825 que trata sobre o serviço de “tunelamento”, não obriga a sua utilização, sendo este um dos motivos pelo qual algumas implementações IPSec baseadas nesta requisição, não suportam o AH em modo túnel. 7.4.7. Cabeçalho Encapsulating Security Payload (ESP) Responsável pelos processos de criptografia, sempre deve ser configurado junto com os serviços de checagem de integridade e autenticação (AH) a fim de se evitar ataques do tipo “criptoanalítico”. Esse cabeçalho também se aplica a datagramas encaminhados por gateways. Isso quer dizer que o roteador de borda irá receber o datagrama e aplicar ESP antes de enviá-lo ao próximo nó remoto. Caso este datagrama seja um fragmento, o roteador irá juntar todos os datagramas do pacote, remontá-lo e aplicar o ESP. No caso do roteador receber um datagrama com ESP implementado, este irá avaliar os campos que indicam fragmentação FRAGMENT OFFSET e M do cabeçalho de fragmentação. Caso eles apresentem valores indicativos de fragmento (OFFSET diferente de 0 e/ou M igual a 1), o datagrama é descartado afim de se evitar o “ataque de duplicação de pacotes”. A “descriptografia” do pacote é realizada pelo último gateway antes do destinatário. Quando o “nó de borda” recebe este datagrama autentica-o e verifica sua integridade. Se estas informações forem pertinentes, então a “descodificação” dos dados é realizada e o datagrama segue para o seu destino. Isso diminui o processamento de dados não válidos e evita o “ataque de negação”. 66 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Cabeçalho ESP 0 Vejamos o cabeçalho ESP: SECURITY PARAMETERS INDEX (SPI) SEQUENCE NUMBER Dados de Trailer autenticação ESP ESP PAYLOAD DATA (tamanho variável) PADDING (0-255 octetos) PAD LENGTH NEXT HEADER AUTHENTICATION DATA (tamanho variável) Figura 7.4.7.1 – Formato do cabeçalho criptografia Fonte: MARK(1997, p.59) SPI – Segue a mesma definição do campo SPI do cabeçalho de autenticação (item 7.4.6) SEQUENCE NUMBER – Segue a mesma definição do item 7.4.6, mas uma observação deve ser acrescentada: Como nas especificações originais do ESP, o conceito de número seqüencial não é tratado, as impelementações IPSec mais antigas podem não garantir proteção de resposta do destinatário. PAYLOAD DATA – Este campo de tamanho variável é obrigatório e seu conteúdo consiste em dados provenientes do cabeçalho seguinte chamado pelo campo NEXT HEADER. Os algoritmos DES-DBC, Triplo-DES e o CDMF da IBM são suportados para criptografia. PADDING – Devido à maioria dos algoritmos de cripotografia terem como requisito um número inteiro como valor do bloco, este campo irá 67 fornecer bits adicionais para a preenchimento. Este campo é opcional uma vez que somente será utilizado caso haja a necessidade de sua finalidade. Vale lembrar que a criptografia abrange os campos PAYLOAD DATA, PADDING, PAD LENGTH e NEXT HEADER. PAD LENGTH – Este campo possui oito bits de tamanho e indica quantos bytes foram utilizados para preenchimento. Caso não se tenha utilizado o campo PADDIN, seu valor será 0. NEXT HEADER – Como o cabeçalho de cripotografia é o último antes do protocolo de alto nível (TCP ou UDP por exemplo), este campo irá fornecer um valor que não será de cabeçalho de serviço e sim um dos protocolos IP definidos pelo IANA. (ver tabela 7.4.1.2). AUTHENTICATION DATA – Este campo contém o Valor de Verificação de Integridade (ICV) calculado para o pacote ESP utilizando os campos SPI, SEQUENCE NUMBER, PAYLOAD DATA, PADDING, PAD LENGTH e NEXT HEADER. Este campo somente será utilizado quando a checagem de integridade for solicitada ou quando uma AS for inicializada. Assim como o AH, o ESP pode ser utilizado em Modo Transporte e Modo Túnel: Modo Transporte – O cabeçalho ESP é inserido logo após o cabeçalho IP original. Se o datagrama possuir cabeçalho IPSec, o ESP é inserido antes. O trailer e a Autenticação ESP são inseridos ao final do conteúdo conforme pode ser observado no esquema seguinte. 68 Cabeçalho IPv6 Conteúdo Datagrama IP original Cabeçalho IPv6 Datagrama autenticado Datagrama criptografado Cabeçalho Trailer Conteúdo ESP ESP Autenticação ESP Datagrama com ESP em modo transporte Figura 7.4.7.2 – ESP em modo TRANSPORTE Fonte: TCP/IP Tutorial e Técnico,(2000, p.296) O modo Transporte não prevê encriptação para o cabeçalho IP original, o que torna possível a entrega de pacotes falsos, no entanto, reduz a necessidade de processamento. Sua implementação é feita pelos hosts e não pelos gateways, ou seja, não é requisito que as interconexões suportem tal modo. Modo Túnel – Neste modo, assim como na autenticação, a intenção é encapsular um datagrama IP dentro de outro, só que desta vez, utilizando um processo de criptografia para o datagrama encapsulado, pois o cabeçalho IP do datagrama “encapsulador” continua desprotegido. Sempre que uma associação de segurança for requerida entre dois gateways, este modo será ativado (ao contrário do modo transporte, essa implementação se dá apenas em roteadores de fronteira). Vejamos um esquema de ESP em modo túnel: 69 Cabeçalho IPv6 Conteúdo Datagrama IP original Novo Cabeçalho IPv6 Cabeçalho IPv6 Conteúdo Datagrama “tunelado” Datagrama autenticado Datagrama criptografado Novo Cabeçalho IPv6 Cabeçalho ESP Cabeçalho IPv6 Conteúdo Trailer ESP Autenticação ESP Datagrama com ESP em modo túnel. Figura 7.4.7.3 – ESP em modo TÚNEL Fonte: TCP/IP Tutorial e Técnico (2000, p.297) Na figura seguinte, podemos verificar uma ilustração de onde o cabeçalho de criptografia atua em modo túnel: Datagrama encapsulado Datagrama não encapsulado Internet Datagrama desencapsulado Gatway de segurança Figura 7.4.7.4 – Funcionamento do ESP em modo TÚNEL Fonte: STEPHEN (1996, p.124) Observe que o gateway de segurança cria um novo datagrama e coloca o original em seu campo de dados de modo que este último não pode ser vizualizado. Ao chegar no gateway de destino, ele desempacota o datagrama original e o lança ao seu destino. 70 7.4.8. Endereçamento IPv6 Como dito no início deste trabalho, “o IPv6 eleva substancialmente a quantidade de endereços válidos para a Internet, bem como procura reduzir a utilização de banda de rede com redução de informações no cabeçalho de dados” como vimos itens 7.4.1 a 7.4.7. Endereçamento IPv6, assim como no IPv4, identifica os nós de uma rede. A grande diferença do novo sistema é que passamos a usar 128bits com notação Hexadecimal, agrupada em oito grupos de quatro e separados por dois pontos (:) como mostra a representação 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 FEDC:0000:0000:0000:0008:0800:200C:417A 1 1 1 1 1 1 1 0 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 0 1 1 1 1 0 1 0 Figura 7.4.8.1 – Endereço IPv6 representado em bits A fim de melhorar a escrita, onde houver grupos de zeros, apenas um zero é necessário ser escrito e, os zeros à esquerda de grupos com outros valores, não necessitam ser escritos. Veja a representação do endereço acima de forma mais curta: FEDC:0:0:0:8:800:200C:417A 71 Uma forma mais simplificada de se escrever uma notação de endereço IPv6, é a utilização de um par de : para representar grupos de zeros consecutivos, como mostrado abaixo: FEDC::8:800:200C:417A Cabe ressaltar que somente é permitido uma supressão de zeros por ::. Caso apareçam duas seqüências de zeros, apenas uma deverá receber esta representação. A outra, será representada por um 0 normalmente. FEDC:0000:0000:0008:0000:0000:200C:417ª FEDC::8:0:0:200C:417A A rede baseada em IPv6 também pode ser subdividida em subredes utilizando notação de / como no IPv4. Alguns prefixos de endereçamento já foram estabelecidos e não devem ser utilizados para endereçamentos comuns. Veja a tabela seguinte: 72 Tabela 7.4.8.1 – Alocação de prefixos Alocação Prefixos binários Inicio da faixa de endereçamentos em Hexadecimal Extensão da Máscara em bits Reservado 0000 0000 0:: /8 8 Reservado para NSAP 0000 001 200:: /7 7 Reservado para IPX 0000 010 400:: /7 7 Endereços Unicast Globais Agregados 001 2000:: /3 3 Unicast local ao enlace 1111 1110 10 FE80:: /10 10 Unicast local à instalação 1111 1110 11 FEC0:: /10 10 Multicast 1111 1111 FF00:: /8 8 Fração do espaço de endereços geral 1 256 1 128 1 128 1 8 1 1024 1 1024 1 256 Fonte: TCP/IP Tutorial e Técnico (2000, p. 357) e MARK(1997, p.86) A notação de endereçamento do IPv6 permitiu aos órgãos de controle designar um prefixo para cada país que por sua vez poderá criar subprefixos para cara região ou estado. Vejamos então alguns endereços de uso fixo: Endereço Unicast – Designado para ser entregue a uma única interface. Existem alguns endereços unicast para propósitos especiais como segue: o Loopback – Representado pela notação ::1, segue as mesmas regras do IPv4 (127.0.0.1), ou seja, é um endereço virtual que funciona apenas para o próprio host. o Não especificado – Representado por ::, é utilizado para autoconfiguração do host (DHCP por exemplo). 73 o Compatibilidade com IPv4 – Escrito em notação hexadecimal, separa os octetos do IPv4 em valores hexa como por exemplo: o endereço 10.70.4.10 seria representado por ::0A46:040A. Isso quer dizer que foram utilizados os 32 bits do IPv4 originais e acrescentado 96 zeros à esqueda do endereço. Isto é utilizado quando se necessita encaminhar um datagrama de uma rede IPv6 para outra utilizando tunelamento em redes IPv4. o IPv4 mapeado – Utilizado para comunicações entre hosts que utilizam versões diferentes do IP. Se um equipamento com endereçamento IPv6 qualquer necessitasse estabelecer conexão com outro IPv4 cujo endereço fosse 10.70.4.10, a notação do endereço de destino ficaria ::FFFF:0A46:040A. Só que para a comunicação funcionar, seria necessário um gateway para tradução dos cabeçalhos. o Local ao enlace – São endereços para uso em redes que não se conectam a nenhum outro tipo de rede. Destinado a locais isolados e desprovido de qualquer serviço de roteamento. Seu prefixo é FE80:: e terminam com o endereço da interface contendo 64 bits. 74 o Local à instalação – Assim como no IPv4, alguns endereços são restrito às corporações, como os 192, 10, 168 e 176, e não podem ser roteados para a internet. Eles possuem uma divisão diferenciada conforme esquema a seguir: FEC0::(subnet):(endereço da interface) Onde a subnet possui 16 bits e o endereço da interface, 64 bits. 7.4.8.1. Formato de Endereço Unicast Global Este formato de endereço está relacionado com o modelo de internet de 3 níveis: Topologia Pública – Provedores que oferecem serviços de transito público compondo a internet. Topologia de Instalação Local – Fechado às localidades de uma corporação, mas não provê trânsito público. Identificadores de Interfaces – Identificam de um modo geral, as interfaces em conexões. Os provedores de longa distância são responsáveis pelos grandes backbones de interligação. Já os provedores de vários níveis, têm por objetivo distribuir conexões para provedores finais e corporações. Os assinantes por sua vez, são os usuários ou empresas que utilizam os serviços dos provedores. 75 Veja um esquema que representa a internet em 3 níveis Provedores de longa distancia 1 Provedores de longa distancia 3 Provedores de alocação de troca de endereços 1 Provedores de longa distancia 2 Provedores de alocação de troca de endereços 2 Para outros Provedores de alocação de troca de endereços Provedores de longa distancia 4 Assinante 6 Provedor de vários níveis 1 Assinante 1 Provedor de vários níveis 3 Provedor de vários níveis 2 Assinante 2 Assinante 3 Assinante 4 Assinante 5 Figura 7.4.8.1.1 – Hierarquia de 3 níveis da Internet Fonte: TCP/IP Tutorial e Técnico (2000, p. 358) e MARK(1997, p.94) A próxima ilustração apresenta o formado do endereço unicast global. 0 2 FP 3 15 TLA ID 16 23 24 RES Topologia pública 47 NLA ID 48 63 SLA ID Topologia do site Figura 7.4.8.1.2 – Formato do endereço Unicast Fonte: TCP/IP Tutorial e Técnico(2000, p. 359) e MARK(1997, p.95) 64 127 Interface ID Topologia de Interface 76 FP (Format Prefix) – Prefixo do Formato Unicast. Para este formato, seu valor é sempre 001, conforme a tabela 7.4.8.1. TLA ID (Top-Level Aggregation Identifier) – São os níveis superiores na hierarquia de roteamentos, onde cada roteador necessitará de uma entrada TLA ID na sua tabela de roteamento. RES – Resevado para uso futuro. NLA ID (Next Level Aggregation Identifier) – Utilizado para que as organizações possam criar uma hierarquia própria. Essas organizações não utilizam provedores e podem designar um TLA ID próprio. SLA ID (Site Level Aggregation Identifier) – Este campo permite a criação de hierarquia local para a organização, podendo se definir até 65.535 subredes na corporação. INTERFACE ID (Interface Identifier) – Identifica qual o tipo de interface para o link de comunicação(Ethernet, Tolken Ring, etc). 7.4.8.2. Formato de Endereço Anycast Trata-se de um endereço preparado para comunicação com múltiplas interfaces, normalmente em nós diferentes desde que estejam bem próximos. A distancia pode ser definida pelo protocolo de roteamento. A RFC 1884 define aplicações de uso para o endereço anycast no que se refere a identificar grupos de roteadores que pertençam ao mesmo provedor de serviço de internet, na mesma subrede e dentro do mesmo domínio de roteamento. Endereços anyicast só podem ser designado por roteadores e não devem ser utilizados como de origem de pacotes IPv6. 77 Este endereço se inicia com a parte referente à subrede de tamanho variável (pois depende da máscara aplicada), e a parte referente a host preenchida com zeros. A intenção é utilizá-lo para a comunicação de um nó com membros de grupos de sub-redes remotas. 128 bits Prefixo de Subrede N Figura 7.4.8.2.1 – Formato do endereço Anycast Fonte: TCP/IP Tutorial e Técnico (2000, p. 359) e MARK (1997, p.95) 7.4.8.3. 00000000000000000000 128 – N Formato de Endereço Multicast Este endereço é designado para se identificar um conjunto de hosts onde os pacotes enviados para este endereço serão recebidos por todos do grupo. A próxima figura apresenta o formato do cabeçalho multicast: 0 7 8 11 12 15 16 FP FLAG ESCOP GROUP ID Figura 7.4.8.3.1 – Formato do endereço Multicast Fonte:TCP/IP Tutorial e Técnico (2000, p. 359) e MARK (1997, p.95) 127 FP – O prefixo do formato para multicast é sempre 1111 1111. FLAG – Pode apresentar dois valores: o Se 0000, o endereço é designado permanentemente por uma autoridade de numeração. o Se 0001, o endereço pode ser estabelecido por aplicativos conforme a necessidade e, ao término da utilização, o endereço é liberado para ser reutilizado por outro sistema. 78 ESCOP – Composto de 4 bits, indica o escopo do multicast conforme a tabela seguinte. Tabela 7.4.8.3.1 – Valores possíveis para o campo ESCOP Valor de escopo 0 1 2 3 4 5 6 7 8 9 A B C D E F Descrição Reservado Restrito ao nó local Restrito a nós no enlace local Não utilizado Não utilizado Restrito ao site local Não utilizado Não utilizado Restrito à organização Não utilizado Não utilizado Não utilizado Não utilizado Não utilizado Escopo Global Reservado Fonte: TCP/IP Tutorial e Técnico (2000, p. 360) e MARK (1997, p.102) GROUP ID – Valor que identifica o grupo de multicat Alguns endereços multicast já possuem uma função predefinida com objetivos especiais conforme tabela 7.4.8.3.2: 79 Tabela 7.4.8.3.2 – Valores Multicast reservados Endereços multicast reservados e que não devem ser utilizados FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0 Fonte: MARK (1997, p.103) Tabela 7.4.8.3.3 – Valores Multicast para todos os nós (escopos 1 e 2) Endereços multicast All nodes FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 Descrição Todas a interfaces locais ao nó Todas a interfaces locais ao enlace Fonte: MARK (1997, p.103) Tabela 7.4.8.3.4 – Valores Multicast para todos os nós (escopos 1, 2 ou 5) Endereços multicast All nodes Descrição FF01:0:0:0:0:0:0:2 Todos os roteadores locais ao nó FF02:0:0:0:0:0:0:2 Todos os roteadores locais ao enlace Todos os roteadores locais ao site FF05:0:0:0:0:0:0:2 Fonte: MARK (1997, p.104) Tabela 7.4.8.3.5 – Valores Multicast com outras funções Endereços multicast All nodes FF02:0:0:0:0:0:0:B FF02:0:0:0:0:0:1:2 FF05:0:0:0:0:0:1:3 Fonte: MARK (1997, p.103) Descrição Agentes móveis locais ao enlace Todos os agentes DHCP locais ao enlace Todos os servidores DHCP locais à instalação 80 7.4.9. IEEE EUI-64 O Institute of Eletrical and Eletronics Engineers (IEEE) está trabalhando no sentido de ampliar o tamanho do endereço físico das interfaces de rede (endereços MAC). Segundo Mark A. Miller, em seu livro “Implementing IPv6, Migrating to the next generation internet protocols”, a proposta é ampliar o atual endereço MAC de 48 para 64 bits de tamanho inserindo 2 bytes entre o prefixo que representa a identificação da companhia que fabrica o hardware e a extensão. Isso elevaria a capacidade de endereçar hardwares de rede em aproximadamente um trilhão de endereços. Uma das idéias seria utilizar este novo endereçamento incorporando-o no campo INTERFACE ID do endereço IPv6 a fim de facilitar a implementação em redes pequenas e isoladas. 7.4.10. Internet Control Message Protocol version 6 (ICMPv6) O protocolo ICMP foi desenvolvido para transporte de diagnósticos sobre a transação de datagramas pela rede. Ele é responsável pelas funções de relatar erros de entrega de datagramas, atualizar tabelas de rotas entre outras. Com a versão 6 do protocolo, as funções do IGMP (visto no item 7.3.6.1.1) e do ARP (visto no item 7.3.3.2) foram incorporadas a este, o que o tornou muito mais robusto. O cabeçalho de extensão ICMPv6 é acionado pelo número 58 conforme tabela 7.4.1.2. Seu formato se apresenta na próxima figura: ICMP TYPE ICMP CODE 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 81 CHECKSUN BODY OF ICMP MESSAGE Figura 7.4.10.1 – Formato do cabeçalho ICMPv6 Fonte: STEPHEN (1996, p.128) ICMP TYPES – Este campo provê a parte mais pesada da identificação. Ele é composto por quinze valores distintos que divide as mensagens em duas classes bem definidas: o A primeira classe com os 127 primeiros valores, apresentam as mensagens de erro. o Na segunda classe, estão presentes os valores a partir de 128. Eles apresentam mensagens de informação. A tabela 7.4.10.1 apresenta alguns valores de mensgens ICMP Tabela 7.4.10.1 – Valores e mensagens ICMPv6 Valor 1 2 3 4 128 129 130 131 132 133 134 135 136 137 Mensagem Destination Unreachable error message (destino não encontrado) Packet Too Big error message (pacote muito grande para o canal) Time Exceeded error message (tempo de resposta excedido) Parameter Problem error message (problemas com os parâmetros) Echo Request message (solicitação de resposta) Echo Replay message (resposta à solicitação) Group Membership query (associação de um membro a um grupo) Group Membership report (informações sobre o membro de um grupo) Group Membership termination (saída do membro do grupo) Router Solicitation (solicitação de roteamento) Router Advertisement (aviso de roteamento) Neighbor Solicitation (busca de vizinhos) Neighbor Advertisement (anuncio de vizinho) Redirect message (aviso de redirecionamento) Fonte: STEPHEN (1996, p.129) 82 CHECKSUN – Destinado a proteger as mensagens ICMP contra corrupção. Para atender a esta demanda, é utilizado o TCP como nível de transporte. Antes de se enviar o datagrama, o checksun é calculado e inserido neste campo. Se o valor resultante não for múltiplo de 8 bits, um byte extra é inserido imaginariamente no cálculo do checksun porém não é enviado com o pacote. BODY OF ICMP MESSAGE – Trata-se do corpo da mensagem ICMP onde serão levadas as informações de mensagens ou erros. Alguns sistemas utilizam-se de um pseudo cabeçalho (pseudo header) para envido de suas mensagens. Este é composto de Endereço de Origem e Destino, Tamanho do Conteúdo (payload) e o Próximo Cabeçalho já setado para o ICMP (valor 58) e é inserido entre o último cabeçalho de extensão e o ICMP conforme SOURCE ADDRESS DESTINATION ADDRESS PAYLOAD LENGTH NEXT HEADER=58 ICMP TYPE ICMP CODE BODY OF ICMP MESSAGE Figura 7.4.10.2 – Formato do pseudo cabeçalho ICMPv6 Fonte: STEPHEN (2000,p.130) CHECKSUN 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 podemos ver na figura seguinte. 83 Na criação deste pseudo cabeçalho, o Endereço de Destino deve ser preenchido com o valor que ele deverá conter quando lá chegar. Por este motivo, se estiver utilizando um Cabeçalho de Roteamento, este endereço será diferente do original quando estiver no destino. Quando o datagrama é recebido pelo destino, um cálculo reverso do checksum é realizado. Se o resultado for 0xFFFF, o datagrama será aceito. Caso contrário será invalidado o checksum e conseqüentemente o datagrama. 7.4.11. Protocolo de Descoberta de Vizinhos (NDP – Neighbor Discovery Protocol) Esta é uma das grandes funcionalidades do novo ICMP. Ela substitui o protocolo de resolução de endereços (ARP), o ICMPv4 de descoberta de roteador do protocolo de mensagens e o redirecionamento ICMP, que são usados no IPv4. Isso possibilita aos nós da rede determinarem os MTUs onde seus vizinhos que executam tarefas de roteamento ou rediredionamento estão conectados (conforme comentado no item 7.4.5), configurar seu endereço automaticamente (DHCPv6), descobrir quem são os gateways de sua rede local, determinar o melhor caminho para envio de seus datagramas a partir de informações dos roteadores vizinhos, entre outras . Combinando essas funcionalidades, temos um eficiente disseminador de informações na rede. Cinco tipos de mensagens ICMPv6 foram criadas pra facilitar o trabalho do NDP: 84 Mensagens de Solicitação de Roteador (Router Solicitation message) – Essa solicitação é enviada pelo host a fim de solicitar aos roteadores que enviem informações sobre suas rotas. Isso o auxiliará da definição de um gateway padrão. Mensagens de Anúncios de Rota (Router Advertisement message) – Tem como objetivo a divulgação de informações sobre rotas dos roteadores. A disseminação destes dados é feita periodicamente ou quando há uma Mensagens de Solicitação de Roteador. Mensagem de Solicitação de Vizinhança (Neighbor Solicitation message) – Solicitado pelos nós de origem via multicast, requer informações dos nós vizinhos sobre endereçamentos de portas de saída da rede local, os quais são repassados adiante para outros nós. Para se saber a distância a que estão destes vizinhos, utiliza-se mensagens do tipo unicast. Mensagem de Anúncio de Vizinhança (Neighbor Advertisement message) – É a resposta à Mensagem de Solicitação de Vizinhança enviada ao nó solicitante, ou quando não solicitada, disseminada quando é atualizada localmente no nó. Mensagens de Redirecionamento – O roteador utiliza-se destas mensagem pra informar aos hosts os melhores caminhos pelos quais eles deverão enviar seus datagramas a fim de atingirem seus destinos. 85 7.4.11.1. Processo de descoberta dos MTUs dos caminhos (Path MTU Discovery Process) Como já mencionado no item 7.3.4, MTU é taxa máxima de transferência, em octetos (ou bytes), suportado por um canal de comunicação. Vimos também que, no IPv6 (7.4.4 e 7.4.5), a responsabilidade pela fragmentação é do host e não mais do roteador. Com isso, o host sabendo qual o melhor canal de dados e o MTU mais adequado para o envio, este poderá enviar seus dados com mais eficiência. O processo se baseia em tentativa e erro em uma primeira comunicação, ou seja, um nó assume o MTU do roteador que ele já conhece como sendo o melhor caminho para enviar um datagrama para um host que está em uma rede que ele não conhece. Quando ele envia o datagrama, este roteador vai recebê-lo e encaminhar para o próximo nó que ele conhece. Se o próximo canal de comunicação possuir um MTU igual ou superior, o datagrama segue o curso. Caso esta unidade não suporte o datagrama, uma mensagem de “pacote muito grande” (Packt too Big), é enviada ao host de origem. Com isso, este equipamento irá alimentar sua tabela de rotas com as informações aprendidas e re-fragmentar o pacote. Este procedimento se repete até que o datagrama chegue ao seu destino. Uma vez passado o primeiro pacote, o host já terá conhecimento de que para atingir a rede especifica, o tamanho do datagrama deverá ser sempre aquele. Veja o fluxo: 86 Host de origem assume PMTU=MTU do gatway conhecido Host monta datagrama com tamanho do PMTU e envia para o roteador1 Datagrama é recebido pelo roteador1 Host de origem reduz o valor do PMTU Roteador1 envia datagrama pelo link1 para o roteador2 Mensagem de pacore muito grande é enviada para o host de origem Datagrama é recebido pelo roteador2 S Datagrama > MTU link2 N Datagrama continua o percurso Figura 7.4.11.1 – Processo de reconhecimento do MTU dos links Fonte: MARK (1997, p.153) 7.4.11.2. Autoconfiguração de endereços No IPv6, possuem duas maneiras de se alocar endereços automaticamente: Com estado – onde um host obtém seu endereço IPv6, informações e parâmetros de configuração a partir de um servidor DHCPv6 (ver item 7.4.11.3); Sem estado – trata-se de uma inovação do IPv6 para sites que não necessitam conhecer seus endereços IP. Para tal são utilizados os endereços MAC dos adaptadores de rede associadas a informações disponibilizadas pelos roteadores. Os prefixos IPv6 para este tipo de endereçamento devem começar com 1111 1110 10 conforme tabela 7.4.8.1. Para este tipo de endereçamento, as chances de se encontrar um endereço duplo, quase não existem, uma vez que os NICs, teoricamente, são únicos no mundo, mas, caso aconteça de se encontrar uma placa com mesmo endereço físico de outra na mesma 87 rede, ou se substitui a interface, ou se força um endereço manualmente. Veja a ilustração: + Nic da interface de rede 02-07-01-E6-31-52 56K = Endereço IP da Estação FE8::780:0207:01E6:3152 PCMCIA Prefixo da rede FE80::780 INSERT THIS END Ethernet Figura 7.4.11.2.1 – Processo de auto configuração de endereço “sem estado” Fonte: STEPHEN(1996, p.147) 7.4.11.3. DHCPv6 Assim como na versão 4 do protocolo IP, sua função é distribuir endereços IP e parâmetros de configuração para os hosts de uma rede. Porém algumas inovações foram incluídas. Vejamos as diferenças: As estações configuradas para funcionarem em redes IPv6 com DHCP, utilizam chamadas multicast (ao invés de broadcast como no IPv4) para localizar servidores do serviço na rede; Não é mais necessária a configuração de gateway default no servidor DHCP, pois as estações utilizam o serviço de “busca de vizinhos” (neighbor discovery); O servidor pode encaminhar mensagens de reconfiguração dos endereços distribuídos, sem a necessidade de aguardar uma nova solicitação por parte da estação. 88 O serviço DHCPv6 é baseado em arquitetura Cliente/Servidor e possui 4 tipos funcionais: Client – o nó que requisita e obtém os parâmetros de configuração; Server – o nó que responde às requisições fornecendo o endereço ou o prefixo (para o caso de alocação de endereço sem estado), e outros parâmetros de configuração (que pode ser implementado em um modo misto – parte com e parte sem estado); Relay – o nó que serve de intermédio de entrega de mensagens DHCPv6 entre clientes e servidores; Agent – nó que pode atuar como cliente ou servidor. A comunicação DHCPv6 pode ocorrer de 3 modos diferentes dependendo dos tipos funcionais envolvidos: 1. Interação entre Clientes e servidores de modo direto – Neste caso, o nome do host não necessita ser conhecido. Esta comunicação se dá em três níveis como mostra a figura que se segue: DHCP Server Seu endereço é….. 2 Ethernet 3 OK 1 DHCP Client Figura 7.4.11.3.1 – Processo fornecimento de endereço cliente/servidor Me informe um endereço 89 2. Utilizando um agente Relay – Neste caso, um agente de interação entre o cliente e o servidor intermedia a negociação do endereço. Este agente nunca responde diretamente a uma requisição do cliente. Isso se aplica quando temos duas redes físicas distintas ligadas a uma terceira e não temos a intenção de colocar dois servidores DHCP para disponibilizar endereços como pode ser exemplificado na figura 7.4.11.3.2. 3. Utilização do serviço DHCP associado com o serviço de resolução de nomes (DNS-Domain Name Server) – Neste caso, quando o host conhece seu nome de domínio, ele pode solicitar ao servidor DHCP um endereço a partir de seu nome. Este servidor irá realizar uma consulta ao servidor DNS para saber se seu nome já esta associado a algum IP. Em caso positivo, o servidor DHCP verifica a alocação do endereço e o repassa ao cliente. Caso o DNS desconheça o endereço do nome, o DHCP reserva um endereço dinâmico para o cliente, informa essa locação ao servidor DNS e em seguida o repassa ao cliente. (funcionamento similar ao WINS). 90 Ethernet Ethernet DHCP Client Me informe 1 um endereço DHCP Client OK Seu endreço é….. 4 5 DHCP Client Ethernet DHCP Relay DHCP Server DHCP Relay O endereço é….. 3 2 Meu cliente deseja um endereço Figura 7.4.11.3.2 – Processo fornecimento de endereço com a utilização do DHCP Relay DHCP Server Qual o endereço do host X? 2 3 X não possui end. conhecido OK Ethernet 4 5 Autualize X com o end. IP ….. 6 Seu endereço é….. 1 DNS Server Meu nome é X. Qual meu IP? DHCP Client Figura 7.4.11.3.3 – Processo fornecimento de endereço combinando DHCP e DNS 91 7.5. Compatibilidade entre IPv4 e IPv6 Devido à semelhança entre as duas versões do protocolo IP, há a possibilidade de tê-las funcionando em conjunto. As preocupações não se prendem somente ao formato do endereço, mas a compatibilidade entre os cabeçalhos também deve ser ajustadas. Em termos de endereço, o IPng define dois tipos IPv6 para compatibilizar a comunicação com o IPv4: IPv4 compatível – Trata-se do processo de conversão propriamente dito de endereços IPv4 para IPv6 e vice versa. São utilizados para comunicação entre duas redes IPv6 com a utilização de uma rede IPv4 como caminho de passagem sem a utilização de “tunelamento”. O processo de conversão de endereços se dá com a inclusão de um endereço IPv4 como por exemplo 10.70.4.5 com os 96 bits que faltam para 128bits (tamanho padrão do IPv6) inseridos à esquerda setados em zero da seguinte maneira: 0:0:0:0:0:0:0A:46:04:05 ou simplemente :: 0A:46:04:05. Desta maneira, quando o roteador que vai receber o datagrama, retira os 96 zeros ele entrega um pacote convertido para IPv4 na rede compatível. IPv4 mapeado – Este endereçamento foi desenvolvido para permitir a comunicação entre um host puramente IPv6 com outro puramente IPv4. Seu formato consiste de 80 bits setados em zero, 16 bits em um e o endereço IPv4 do destino. A apresentação deste endereço ficaria da seguinte maneira: 0:0:0:0:0:FFFF:0A46:0405. 92 Apesar da semelhança entre os resultados, o complemento 0:0:0:0:0:FFFF é o parâmetro que indica se o endereço foi convertido ou mapeado. Quanto aos cabeçalhos, a maioria dos campos se mapeia diretamente. O que não é possível, faz-se um processo de conversão. A tabela a seguir apresenta uma lista de compatibilidades entre os cabeçalhos: Tabela 7.5.1 – Processo fornecimento de endereço combinando DHCP e DNS Protocolo IPv4 IPv6 IPv4 IPv4 IPv6 IPv6 Campo HLength Compatibilidades Calculado conforme as opções existentes no cabeçalho do IPv6 Class(valor > O IPv6 recebe os datagramas IPv4 com prioridade 0 7) Type Of Este campo é ignorado pelo IPv6 durante a conversão. Service Flags e Quando recebe um datagrama com cabeçalho de OffSet fragmentação, os 16 bits menos significativos do Fragment cabeçalho de extensão de fragmentação referente às informações do serviço entram como valores deste campo Fragment Recebem os valores do datagrama IPv4 normalmente OffSet e M Flow Labels Ignorado quando da conversão para IPv4 e zerado quando do inverso Fonte: STEPHEN (1996, p.428) Ainda há a possibilidade de se ter um host com pilha dupla, ou seja, que é capaz de conversar tanto com equipamentos IPv6 quanto com equipamentos IPv4. 93 7.6. Comparando as versões do Protocolo Comparando os dois cabeçalhos, observamos que muitos campos do IPv4 VERSÃO DO IP (VERSION) CLASSE DE TRÁFEGO (CLASS) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 foram suprimidos devido a funções re-projetadas no IPv6. RÓTULO DE FLUXO (FLOW LABEL) TAMANHO DO PAYLOAD (PAYLOAD LABEL) PRÓXIMO CABEÇALHO (NEXT HEADER) LIMITE DE SALTOS (HOP LIMIT) .......... ENDEREÇO DE ORIGEM (SOURCE ADDRESS) ENDEÇO DE DESTINO (DESTINATION ADDRESS X VERSÃO DO IP (VERSION) TAMANHO DO CABEÇALH O (HLEN) TIPO DE SERVIÇO (TOS) SINALIZADOR DE FRAGMENTO (FLAG) IDENTIFICAÇÃO TEMPO DE VIDA DO DATAGRAMA (TIME TO LIVE) COMPRIMENTO TOTAL IDENTIFICADOR DE INICIO DO DATAGRAMA FRAGMENTADO (OFFSET FRAGMENT) CHECAGEM DE ERRO DO CABEÇALHO (HEADER CHECKSUM) PROTOCOLO IP DE ORIGEM IP DE DESTINO Figura 7.4.1.4 – Comparação entre os cabeçalhos IP versão 6 e 4 Campos preservados: TCP/IP-Tutorial(2000, p. 350) - Versão do IP - Tipo de Serviço - Tempo de vida, agora chamado de Limite de Saltos. - Protocolo, agora chamado de Próximo Cabeçalho. 94 - Endereço de Origem. - Endereço de Destino. Campos integrados : - SINALIZADOR DE FRAGMENTO e IDENTIFICADOR DE INICIO DO DATAGRAMA FRAGMENTADO – Agora chamada de Rótulo de Fluxo Campos Substituídos: - TAMANHO DO CABEÇALHO e COMPRIMENTO TOTAL DO DATAGRAMA – No IPv6, o cabeçalho possui tamanho fixo, não sendo mais necessário o cálculo deste. O campo TAMANHO DO PAYLOAD informa qual o tamanho do datagrama já subtraindo os 40Bytes do cabeçalho. Campos Eliminados - IDENTIFICAÇÃO – Os cabeçalhos de extensão possuem informações mais completas sobre fragmentação, eliminando assim a necessidade de tal campo. - CHECAGEM DE ERROS – Entendendo que os níveis superiores tratam a questão de checagem de erros, o IPv6 não trata mais as questões de garantia, apesar de existir um cabeçalho opcional de autenticação que certifica que o datagrama foi recebido sem erros. 95 7.7. Reflexões sobre alguns motivos para migração de IPv4 para IPv6 Como vimos ao longo deste estudo, existem uma série de fatores que irão influenciar na decisão das corporações em migrar sua rede para este novo sistema de comunicação de nível 3. Segundo os autores do livro TCP/IP, Tutorial e técnico, podem ser dois os motivos: “necessidade de se ter os requisitos apropriados para os novos recursos que exigem o IPv6, ou a exaustão do espaço de endereços IPv4.” Eles alegam que grandes organizações com um parque computacional muito elevado, poderia ser muito oneroso tomar a decisão de troca de tecnologia, uma vez que a maioria dos seus equipamentos de roteamento e até mesmo outros tipos de hardware teriam que ser substituídos. Para estas empresas, a única motivação, seria o mercado limitar conexões e serviços em IPv6. Caso isso não aconteça, o melhor que elas podem fazer é criar mecanismos de compatibilização, conforme apresentado no item anterior, para permitir que seu ambiente computacional não deixe de falar com clientes e fornecedores e até mesmo para receber os recursos necessários para o bom andamento do seu negócio, mas que sejam puramente IPv6. Sabendo-se que o protocolo ainda está em desenvolvimento, mesmo as novas corporações, devem ficar atentas antes de tomarem a decisão de implementar sua rede com uma plataforma puramente IPv6, mesmo porque elas terão a necessidade de se conectar com o mundo que ainda é IPv4. Para pequenas empresas, onde a convergência pode ser feita de maneira rápida, trata-se de uma boa opção a implantação de redes IPv6, desde que nela possuam mecanismos de compatibilização com redes IPv4. Vantagem pois os mecanismos de distribuição de endereços é facilmente automatizado sem a 96 necessidade de custos adicionais com servidor de DHCP conforme apresentado durante o estudo. A implementação da versão 6 do protocolo IP visa melhorar o tráfego nos links WAN diminuindo a carga de processamento nos roteadores, bem como o aumento significativo na faixa de endereçamento lógico. 97 7.8. Conclusão do estudo Apesar das grandes vantagens que encontramos com a implementação da versão 6 do protocolo, muita cautela antes de se aventurar por este caminho. O serviço ainda está em desenvolvimento e grandes mudanças ainda serão implementadas à medida que a grande massa de usuários começar a utilizar realmente. Muitos hardware e softwares já estão sendo desenvolvidos com compatibilidade para as duas versões. A Cisco já desenvolve roteadores que podem funcionar em qualquer uma ou em ambas. A maioria das distribuições Linux e o próprio Windows 2003 já possuem suporte para esta versão, apesar da Microsoft ainda não permitir encapsulamento V6 em V4. De um modo geral, trata-se de um grande projeto que deve ser estudado antes de ser implementado. Na segunda parte deste trabalho, iremos trabalhar sobre as configurações de uma rede IPv6 de modo a analisar na prática todo o conteúdo discutido neste estudo. Iremos fazer uma simulação de um ambiente com serviços como correio, DNS, DHCP, Segurança e cripotografia, bem como listar os hardwares e softwares já compatíveis e testados com a utilização desta nova tecnologia. 98 Bibliografia COMMER, Douglas E..Interligação de redes com TCP/IP. Vol.1, 5 ed. tradução Daniel Vieira. Rio de Janeiro: Campus,2006. MILLER, Mark A..Implementing IPv6: Migrating to the Next Generation Internet Protocols. New York,USA:M&T Books,1998. MURHAMMER, Martim W. et. all. TCP/IP Tutorial e Técnico. São Paulo: Makron Books,2000 NAUGLE, Matthew G.. Guia ilustrado do TCP/IP: Uma anatomia completa das redes TCP/IP e do conjunto de protocolos IP em um formato de referência rápida. São Paulo:Berkley,2001. THOMAS, Stephen A..IPng and TCP/IP Protocols: Implementing the Next Generation Internet.Canadá,USA:Wiley Computer Publishing, 1996. 99 Outras fontes DHCPv6. Disponível em http://thesource.ofallevil.com/technet/prodtechnol/windowsserver2003/ptpt/library/ServerHelp/5a528933-a78d-4588-8aa1-b158957ba2d5.mspx?mfr=true Neighbor Discovery Protocol. Disponível http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ptbr/library/ServerHelp/55049e22-2aa7-44c9-ab4b-97cf98b96ad2.mspx?mfr=true em
