Skip Navigation Links



Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«

O melhor teclado da microsoft
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!

Pesquisa personalizada
Pesquisar Dicas:

 






CD BufaloInfo
Este treinamento fornece os conceitos sobre o funcionamento de redes TCP/IP e como o TCP/IP é aplicado no NT 4. Preparatório para prova da Microsoft.
Valor : R$ 540,00 ou 5 X de R$ 113,00
I  P  V  6

Neste artigo serão apresentadas as principais características do IPv6, apresentando suas principais modificações em relação ao IPv4. Para um melhor entendimento será visto alguns aspectos históricos e técnicos da evolução do IP, base da pilha de protocolos TCP/IP.

A história do TCP/IP intimamente interligada com a da Internet. O conjunto de protocolos TCP/IP resultou de pesquisas fundadas pelo ARPA (Advanced Research Projects Agent ) para conectar redes dos seus departamentos de pesquisas, a esta rede denominou-se ARPANET. Os primeiros projetos de pesquisas originaram-se da idéia de comutação de pacote, considerada radical na época, em meados de 1960. 

No final da década de 60, precisamente em dezembro de 69, entrou no ar uma rede experimental com quatro nós interligando as instituições UCLA (Universidade de Los Angeles), UCSB ( Universidade de Santa Barbara ), SRI (Instituto de Pesquisa de Stanford) e Universidade de Utah. Através da experiência conseguida nesta rede, alavancou-se grandes pesquisas sobre protocolos, culminando com a criação dos protocolos e do modelo TCP/IP [ Cerl e Kahn, 1974].

Em 1983 o TCP/IP tornou-se o protocolo oficial da ARPANET, levando a uma das primeiras definições de internet, como sendo um conjunto de rede conectadas via TCP/IP; nessa mesma época foi feita na Universidade de Berkeley, a implantação do protocolo ao sistema operacional Unix, conhecido como BSD . Em adição aos protocolos foram oferecidas um conjunto de aplicações que passaria a expandir os serviços do Unix a mais de uma máquina. Com esta implantação o protocolo aumentou sua popularidade.

Conjuntamente a estas aplicações, o BSD ofereceu uma abstração ao seu sistema operacional que permitia acesso aos protocolos TCP/IP, chamada sockets. Isto aumentou a utilização dos protocolos pelos programadores que passaram a enxergar-los num mais alto nível que antes. A partir daí pesquisas foram alavancadas e novas aplicações foram surgindo.

Em 1985 a entidade americana NSF ( National Science Foundation) interligou os supercomputadores de seus centros de pesquisas em rede, que passaram a ser conhecida como NSFNET. Em 1986 esta rede conectou-se a ARPANET. O conjunto de todos os computadores desta rede e sua espinha dorsal passaram a ser conhecidas oficialmente como Internet.

Em 1988 a NSFNET passou a ser mantida pela IBM, MCI ( empresa de telecomunicações americana) e MERIT ( instituição responsável por uma rede pertencente a instituições de Michigan, EUA) estas criaram a ANS ( Advanced Network and Services).

Em 1990 o backbone ( espinha dorsal) ARPANET deixou de existir e no seu lugar foi criado uma outra espinha dorsal conhecida como DRI ( Defense Research Internet ). Em 1990/1993 a ANS criou a ANSNET, que passou a ser a nova espinha dorsal da Internet; paralelamente foi criado a espinha dorsal européia (EBONE), que interligou alguns países da Europa a Internet. A partir de 1993 a rede deixou de ser puramente acadêmica para ser explorada comercialmente. 

Nos últimos anos, a Internet demonstrou uma altíssima taxa de crescimento, que superou as mais otimistas expectativas de uma década atrás.

Isto eventualmente trouxe problemas, que não estavam previstos. Com o grande número de hosts conectados, os endereços IP começaram a se tornar escassos, principalmente pela maneira ineficiente como foram divididos em classes, o que gerou desperdício. Estes dois fatos contribuíram para gerar um crescimento das tabelas utilizadas para roteamento, o que tornou esta atividade lenta e ineficiente. 

Desde 1991, membros da IETF ( Internet Engineering Task Force ) chegaram a conclusão que o crescimento exponencial da rede levaria em poucos anos a exaustão dos endereços utilizados para identificar os computadores na Internet. Isso se as tabelas de roteamento simplesmente não esgotassem toda a capacidade dos hardwares de roteamento da época.

Essa crise foi superada a curto prazo com a adoção do CIDR (Classless Inter-Domain Routing), que consistia resumidamente em dar blocos de endereços IP Classe C contíguos a regiões do planeta (Europa, Ásia, etc), e essas regiões dividiriam seus blocos em blocos menores, mas ainda contíguos, até que todas as redes tivessem seus endereços. Com o uso de máscara de rede, os roteadores usavam uma máscara para endereçar todo um bloco de endereços e assim conseguiam diminuir a tabela de roteamento [TAN96].

Mas o CIDR não seria uma solução duradoura, outra deveria ser projetada a longo prazo e que tivesse uma duração maior. Um novo protocolo precisava ser desenvolvido em substituição ao IPv4. Uma proposta foi a adoção do CLNP [TAN96], que tem um espaço de 160 bits para endereçamento. Entretanto, além de não suportar serviços multimídia como desejado, por ser uma solução OSI não foi bem quista por alguns elementos.

Soluções paliativas então foram criadas para resolver temporariamente este problema. Claramente, o protocolo de rede utilizado, o IPv4 (Internet protocol version 4) necessita ser substituído.

Foi criado um grupo de trabalho pela IETF, para definir uma nova versão do IP ( Internet Protocol ), protocolo utilizado para endereçar e enviar dados que trafegam pela rede. O intuito deste grupo era criar uma nova versão mais eficiente e flexível, e que fosse capaz de resolver os problemas relacionados com a questão do esgotamento de endereços e outros mais. Os principais objetivos foram [TAN 96] :

  • Aceitar bilhões de hosts, mesmo com alocação de espaço de endereço ineficiente; 

  • Reduzir o tamanho das tabelas de roteamento; 

  • Simplificar o protocolo de modo a permitir que os roteadores processem os pacotes com mais rapidez. O IPv6 especifica um cabeçalho mais enxuto ao protocolo. Isto melhora o desempenho do processamento gasto;

  • Oferecer mais segurança ( autenticidade e privacidade ) do que o IP atual. A nova versão inclui mecanismos de autenticação e privacidade na transmissão dos seus datagramas;

  • Dar mais importância ao tipo de serviço, particularmente para os dados em tempo real; 

  • Permitir multicast, possibilitando a especificação de escopos; 

  • Permitir que um host mude de lugar sem precisar mudar de endereço; 

  • Permitir que o protocolo evolua no futuro; 

  • Permitir a coexistência entre o novo e o antigo protocolo durante anos. 

  • Prover segurança (autentificação e privacidade);

Para chegar a um protocolo que atendesse a todos esses requisitos, a IETF convocou os interessados para apresentarem suas propostas na RFC1550.

Foram submetidos 21 trabalhos ao grupo, estes propuseram desde pequenos ajustes do IP, até a eliminação completa com o surgimento de um novo protocolo. Três propostas foram utilizadas como base, e uma versão ajustada foi criada e manteve características da versão atual, possuindo ainda uma transição melhor. Depois de muita discussão, revisão e disputas, foi produzida a recomendação para a nova versão do IP em novembro de 1994, chamada de SIPP ( Simple Internet Protocol Plus), e lhe foi atribuída a designação de Ipv6, que foi inicialmente conhecido como IPng (IP Next Generation).

A grande questão que surge com relação a versão atual do IP ( IPv4 ) é que, este protocolo está chegando ao seu limite de utilização e possue restrições.

O protocolo IP possue 32 bits para endereçamento, mostrando-se um recurso baixo devido ao crescimento exponencial de hosts conectados a Rede.

A proposta do IPv6 é de resolver os problemas da versão anterior mantendo as características que contribuíram para o sucesso do IPv4. Características, como: serviço não orientado a conexão, decisão de escolha do tamanho do Datagrama, o número máximo de roteadores a serem utilizados, facilidade de fragmentação e roteamento foram mantidas, por serem considerados motivos importantes para este sucesso.

O IPv6 modifica totalmente o formato do Datagrama. A figura 1 mostra o formato geral. O Datagrama é formado por uma parte fixa, o cabeçalho base, seguido de zero ou mais extensões de cabeçalho, logo depois vem o dado.

Cabeçalho Base

Extensão de Cabeçalho

...

Extensão de Cabeçalho

Dados

Figura 1 - Formato geral do datagrama IPv6

Apesar de prover mais endereçamento o cabeçalho do IPv6 contém menos informações que o de IPv4. As principais mudanças ocorridas no cabeçalho foram:

  • Algumas informações que aparecem no cabeçalho do IPv4 foram colocadas como opcionais, visando diminuir o processamento; 

  • O tamanho do campo de endereços foi alterado para dezesseis octetos, contra os quatro da versão anterior;

  • Os campos de fragmentação passam a fazer parte das opções, através dos cabeçalhos de extensão. Existe um grande esforço para que ela ocorra somente fim a fim, ou seja, da origem para o destino; 

  • O campo TIME TO LIVE foi trocado por um outro que realmente mede a quantidade de roteadores até chegar ao destino; Campo SERVICE TYPE foi substituído por um outro com muito mais recursos para aplicações em tempo real e vídeo; 

  • Foi retirado o campo PROTOCOL passando a existir sua função em uma outra estrutura.

A figura 2 mostra o formato do cabeçalho fixo do datagrama IPv6. Logo a seguir é dada ema explanação sobre cada um dos seus campos.

 

 

 

 

 

 

 

 

 

 

 

 

 

3

2

B

I

T

S

 

 

 

 

 

 

 

 

 

 

 

 

 

VERSION

PRIORITY

FLOW LABEL

PAYLOAD LENGTH

NEXT HEADER

HOP LIMIT

SOURCE ADDRESS

DESTINATION ADDRESS

Figura 2 - Cabeçalho fixo do datagrama IPv6

O campo de VERSION ( 4 bits) tem a mesma função do IPv4. Ele é sempre 6 para IPv6.

O campo PRIORITY (4 bits ) é utilizada para dar prioridade distintas aos pacotes. Ele diferencia os pacotes que podem ter controle de fluxo, dos que não podem. Os valores de 0 a 7 dão destinados a protocolos capazes de diminuir o fluxo de envio caso ocorra o congestionamento. Para pacotes de aplicações em tempo real que são enviados a taxa constante, valores de 8 a 15 dizem quais datagramas podem ser descartados com prioridade maior para valores mais altos.

O campo FLOW LABEL é utilizado para definir que os roteadores devem tratar o pacote de maneira especial, que garantirá uma específica qualidade de serviço. Por exemplo duas aplicações que necessitam enviar vídeo podem estabilizar um fluxo no qual o delay e a largura de banda seja garantida. Neste campo contém apenas a informação de que se o dado deve ou não tratar este Datagrama de forma especial.

Este campo pode ser dividido em dois sub-campos, como pode ser visto na figura 3. O sub-campo TCLASS especifica a classe do trafego para o datagrama. O restante do campo especifica um identificador para este fluxo. O identificador permite a distinção de diversos fluxos de uma origem para o mesmo destino.

4 bit's

24 bit's

TCLASS

FLOW IDENTIFIER

Figura 3 - Os dois sub-campos do FLOW LABEL

O campo PAYLOAD LENGTH ( 16 bits) determina o tamanho do datagrama, em octetos, excluindo-se o cabeçalho base . O total Length do IPv4, dava o valor total do datagrama incluindo o cabeçalho.

O campo NEXT HEADER ( 8 bit's) indica a existência de cabeçalho adicionais ou caso não exista o protocolo da camada superior ( TCP ou UDP). Esta característica inclui dois compromissos : a generalização e a eficiência. A generalização é conseguida com a inclusão de funções adicionais, como fragmentação, roteamento na origem e autenticação. A eficiência é conseguida a partir do momento que se não forem preciso estas características os seus campos não necessitam estar presentes.

A figura 4 mostra como são utilizados os cabeçalhos de extensão. Cada cabeçalho contém o campo NEXT HEADER que aponta para o próximo campo, o ultimo cabeçalho indica qual protocolo da camada de transporte será utilizado. É utilizado o mesmo princípio de uma lista encadeada.

Cabeçalho Base

NEXT=ROUTER

Cabeçalho de Roteamento

NEXT=AUTH

Cabeçalho de autenticação

NEXT=TCP

Segmento TCP ( dados

Figura 4 - Exemplo de cabeçalho com duas extensões

O campo de oito bits HOP LIMIT é utilizado semelhante ao TIME TO LIVE do IPv4. A grande diferença é que este foi elaborado para de fato contar, de maneira decrescente, o número de roteadores que o mesmo passou. O pacote também, é descartado caso o limite chegue a 0.

O campo SOURCE e DESTINATION ADDRESS indicam respectivamente o endereço de origem e de destino do Datagrama, como diferencial do IPv4 tem o fato de se usar 128 bits ao invés de 32 bits daquela versão.

Cabeçalhos de extensão

Os cabeçalho de extensão foram criados com a finalidade de fornecer informações adicionais relativas as facilidades utilizadas por um determinado Datagrama. Existem atualmente seis cabeçalhos definidos, uma descrição de cada um é dado logo a seguir.

Cabeçalho de extensão

Descrição

Hop-by-hop

Informações diversas para os rotedores

Routing

Rota parcial ou integral a ser seguida

Fragmentation

Fragmentação do Datagrama IP

Authentication

Verificação da identidade do datagrama

Encrypted security payload

Informações sobre o conteúdo encriptado

Destination options

Informações adicionais para o destino

Tabela 1 - Cabeçalhos de extensão do IPv6

Hop-by-hop Options e Destination Options

Os cabeçalhos Hop-by-Hop e Destination Options possuem o mesmo formato, como mostrado na figura 5.

0

8

16 31

NEXT HEADER

HEADER LENGTH

 

ONE OR MORE OPTIONS

Figura 5 - Formato do Hop-by-hop e Destination Options

O campo NEXT HEADER diz o tipo de cabeçalho que vem a seguir.

O campo HEADER LENGTH indica o tamanho total do cabeçalho, pois este cabeçalho não possue tamanho fixo.

A área ONE OR MORE OPTIONS representa uma seqüência de opções individuais. Cada opção é composta pelos campos TYPE, LENGTH e VALUE segundo pode ser visto na figura 6.

0

8

16

TYPE

LENGTH

VALUE ...

Figura 6 - Formato das opções individuais dos cabeçalho de opções

Os dois bits de mais alta ordem do campo TYPE especifica como os roteadores irão tratar as opções, se estas não forem compreendidas conforme a tabela 2.

Dois bits de mais alta ordem

Ação

00

Desconsidere esta opção

01

Descarte o datagrama e não envie uma mensagem ICMP

10

Descarte o datagrama e envie uma mensagem ICMP

11

Descarte o datagrama e envie uma mensagem ICMP para endereços não Multicast

Tabela 2 - Tratamento das opções que não forem compreendidas pelo roteador

Os 5 bits de mais baixa ordem do campo TYPE indicam a opção propriamente dita. O terceiro bit de mais alta ordem indica se os dados desta opção poderão mudar ou não durante o percurso do pacote.

A diferença entre Hop-by-Hop e Destination, é que o primeiro deve ser processado por todos os roteadores, enquanto o segundo somente pelo destino.

Fragmentation

O IPv6, assim como o IPv4, implementa a fragmentação do Datagrama. A grande diferença se dá na maneira com que isto ocorre. No IPv4 cada roteador intermediário deveria fragmentar e reorganizar datagramas de acordo com o MTU da sub-rede. No IPv6, a fragmentação é feita na origem, antes de enviar um Datagrama, utiliza a técnica de enviar um Path MTU Discovery para descobrir qual o menor dos MTU'S. Quando o envio se dá, a origem fragmenta de maneira que cada fragmento deverá ser menor que o MTU mínimo descoberto. Desta forma a fragmentação não ocorre nos roteadores intermediários. Caso haja a necessidade de uma fragmentação não esperada nos rotedores intermediários ( mudança de rotas ) eles encapsulam o datagrama em um novo e o fragmenta. A figura 7 mostra o formato do cabeçalho de fragmentação.

0

8

16

29

31

NEXT HEADER

RESERVED

FRAGMENT OFF SET

RES

MF

IDENTIFICATION

Figura 7 - Formato do cabeçalho de fragmentação

O campo NEXT HEADER indica como foi explicado anteriormente, o próximo cabeçalho de extensão.

O campo RESERVED foi reservado para uso futuro

O campo FRAGMENT OFF SET indica a que ponto do datagrama original o fragmento pertence.

O campo RES reserva-se para o futuro.

O FLAG MF indica se existem mais fragmentos ou se este trata-se do último.

IDENTIFICATION identifica unicamente o fragmento assim como o IPv4. O número de bits deste campo foi ampliado devido as redes de alta velocidade.

Routing

Este cabeçalho lista um ou mais roteadores que devem ser visitado durante o percurso do datagrama. Pode-se utilizar os dois tipos de roteamento, assim como no IPv4, Strict e Loose, com a variação de poderem ser combinados. A figura 8 indica seu formato.

0

8

16

24

31

NEXT HEADER

ROUTING TYPE

NUMBER ADDRESS

NEXT ADDRESS

RESERVED

BIT MAP

1 - 24 ADDRESS

Figura 8 - Formato do cabeçalho de extensão

O campo NEXT HEADER possue mesma função de todos os outros cabeçalhos, ou seja, indica o próximo tipo de cabeçalho.

O campo ROUTING TYPE indica o tipo de roteamento, atualmente está definido em 0.

O campo NUMBER ADDRESS indica o número de endereços presentes neste cabeçalho ( de 1 a 24 ).

O campo NEXT ADDRESS indica o próximo endereço para o qual o datagrama poderia ser enviado. Este campo inicia com 0 e é incrementado cada vez que um endereço é visitado.

O campo BIT MAP é um mapa de bits que serve para indicar qual dos tipos de tratamento deve ser tomado a cada um dos roteadores. O endereço pode ser visitado diretamente depois do que o antecede (Strict) ou fazê-lo indiretamente, podendo existir roteadores intermediários ( Loose).

Authentication ( AH)

O cabeçalho de autenticação oferece um mecanismo que permite que o host de origem saiba se o datagrama enviado é mesmo de quem diz ser. Neste tipo de serviço, a privacidade da comunicação é garantida mas sem confidencialidade, isto é, os dados não são encriptados. Um dos objetivos da autenticação de datagramas é evitar ataques de máquina conhecido como IP spoof. O IP spoof consiste em utilizar o endereço de uma máquina em outra. Se a máquina de destino confiar neste endereço ( isto é possivel no UNIX ) é aberta então uma possibilidade de invasão.

Antes de ser iniciada uma comunicação, é necessário que o transmissor e o receptor defina uma ou mais chaves secretas, conhecidas somente por eles, criando uma associação. A associação é um relacionamento unidirecional entre o transmissor e o receptor, identificada pelo endereço do transmissor e um Security Parameter Index, presentes no cabeçalho de segurança. Os parâmetros desta associação são os algoritmos de autenticação e suas chaves de criptografia. Como algoritmo padrão do IPv6 foi definido o MD5 ( Message Digest 5 ) [ TAN 96 ] mas outros poderão ser utilizados.

A autenticação no IPv6 é feito através de um cabeçalho de segurança que suporte a integridade e autenticação dos dados. O formato deste encontra-se na figura 9.

0

8

16

24 31

NEXT HEADER

PAYLOAD LENGTH

RESERVED

SECURITY PARAMETER INDEX

SEQUENCY NUMBER

DATA

Figura 9 - Formato do cabeçalho de autenticação.

O NEXT HEADER identifica o próximo cabeçalho.

O campo LENGTH indica o comprimento do cabeçalho em palavras de 32 bits.

O campo SECURITY PARAMETER INDEX é o número chave de 32 bits que em conjunto com os endereços de destino identifica unicamente a associação segura. De posse deste número o receptor localiza a chave secreta e calcula a soma de verificação do datagrama confirmando ou não a associação segura.

O campo SEQUENCE NUMBER contém um contador que é incrementado a cada transmissão. O transmissor e o receptor são setados em 0 quando uma associação segura é iniciada. Este número é utilizado para evitar um replay de pacotes. Um replay consiste em capturar o datagrama e enviar um outro montado com informações modificadas. Este numero não é cíclico, e quando chegar o seu valor máximo o receptor e o transmissor devem colocá-lo em zero e iniciar uma nova associação segura.

O campo AUTHENTICATION identifica os dados da autenticação em palavras de 32 bits. O que este campo contém vai depender do algoritmo de autenticação utilizado. Ele é calculado utilizando o Datagrama todo e atribuindo zero, àqueles campos que se modificam durante o percurso.

Encrypted Security Payload ( ESP )

Este cabeçalho provê a integridade e confidencialidade aos datagramas. Se utilizado em conjunto com o de autenticação forma uma solução completa de segurança. O serviço de segurança pode ser aplicado entre dois roteadores , entre dois hosts ou entre um host e um roteador. A figura 10 mostra o formato do cabeçalho de encriptação de dados.

O princípio básico deste cabeçalho é de enviar dados encriptados utilizando para isto um algoritmo, que deverá ser conhecido pelo transmissor e pelo receptor, bem como as chaves utilizadas para gerá-los. Por questão de compatibilidade um algoritmo padrão foi escolhido, o DES-CBC (Data Encryption Standard in Cipher-Block Chaining ) maiores informações deste algoritmo pode ser conseguidas em Tanebaum
[ TAN 96 ]. Poderão ser usados, no entanto, outros algoritmos.

O ESP pode ser utilizado de dois modos. O primeiro é conhecido como Tunnel-Mode, que encapsula o datagrama inteiro no cabeçalho. O segundo é o Transpot-Mode, que encapsula os dados vindos da camada superior ( TCP e UDP ) dentro do cabeçalho.

O processamento de um cabeçalho ESP deverá aumentar o tempo de latência nos roteadores. Isto acontecerá devido ao tempo necessário para processar os complexos algoritmos de encriptacao utilizados, o que pode requerer roteadores com um maior poder de processamento e uma implementação dos algoritmos em hardware. Entretanto, o uso de ESP não deverá impactar nos roteadores intermedários que não participarão desta associação de segurança.

0

8

16

24 31

SECURITY PARAMETERS INDEX

SEQUENCE NUMBER

PAYLOAD DATA

 

PADDING ( 0 - 255 bytes)

 

PAD LENGTH

NEXT HEADER

AUTHENTICATION DATA

 Figura 10 - Formato do cabeçalho de encriptação de dados

O campo SECURITY PARAMETERS INDEX é um número de 32 bits que identifica juntamente com os endereços de destino uma associação segura para o datagrama.

O campo SEQUENCE NUMBER contém um contador que é incrementado a cada transmissão. O transmissor e o receptor são setados em 0 quando uma associação segura é iniciada. Este número é utilizado para evitar um replay de pacotes assim como no cabeçalho de item anterior.

O campo PAYLOAD DATA é o dado descrito pelo campo Next Header. Este campo deverá ser múltiplo de 8 bytes e corresponder a carga útil encriptada a ser transmitida. Se o algoritmo usado necessitar de sincronização de dados, um vetor de inicialização se faz necessário e é colocado no início deste campo [TAN 96].

O campo PADDING é utilizado para incluir valores ao campo anterior caso o algoritmo necessite que o mesmo seja múltiplo de um número.

O campo PAD LENGTH indica o número de octetos utilizados no campo anterior. Um valor 0 indica que nenhum PADDING foi incluído.

O NEXT HEADER indica o tipo de dado contido no campo PAYLOAD DATA, por exemplo, se neste campo contém TCP, indica que a carga útil é o dado vindo da camada de transporte.

O campo AUTHENTICATION DATA é um campo calculado sobre o cabeçalho ESP retirando-se o mesmo. Este campo é opcional e, é incluído somente se houver uma necessidade de autenticação.

Endereçamento no IPv6

Como já foi visto anteriormente, cada endereço do IPv6 ocupa 16 octetos (128 bits ), isto faz com que o IPv6 suporte um número bem maior de níveis de hierarquia de endereços e de nós endereçáveis. Segundo Tanenbaum [TAN 96], se for colocado um computador em cada pedaço do planeta, incluindo a água, o IPv6 permitiria que fosse colocado 7 x 1023 endereços IP por metro quadrado. A quantidade de endereços no IPv6 possui quatro vezes o numero de bits utilizados para endereçamento no IPv4, tanto que engloba todos estes endereços para manter a compatibilidade.

Assim como a versão anterior o IPv6 associa um endereço a uma conexão de rede e não a um computador, permitindo, por exemplo, a um host ou a um roteador ter mais de um endereço associado a uma mesma interface física. Além disto o IPv6 amplia o endereçamento em três categorias: 

  • Unicast - o endereço de destino é associado a somente um computador;

  • Multicast -o endereço de destino é um grupo de computadores possivelmente em locais diferentes. Uma cópia do Datagrama é dado para cada membro do grupo;

  • Anycast - o destino é um conjunto de computadores. O Datagrama é entregue a somente um dos computadores, normalmente o mais próximo. Cabe ao roteador decidir qual deles.

  •  

Notação de endereços no IPv6

O IPv6 usa uma notação diferente para seus endereços. Enquanto o IPv4 agrupa seus bits em oito e os representa em forma decimal, O IPv6 agrupa seus bits em 16 e os representa sob a forma hexadecimal. A notação decimal se fez ineficiente devido a dificuldade de tratá-la. Dessa maneira uma notação em decimal para um endereço IPv6 seria: 104.230.140.100.255.255.255.255.0.0.17.128.150.10.255.255. O mesmo endereço usando a notação padrão do IPv6 é: 68E6:8C64:FFFF:FFFF:0:1180:96 A: FFFF. Esta notação tem a vantagem de requerer poucos dígitos e poucos pontos para separação dos campos agrupados.

Uma simplificação ainda é possível no caso de haver muitos zeros no endereçamento. Uma seqüência repetida de zeros é simplificada por um par de ": " por exemplo, citamos o endereço: FF05:0:0:0:0:0:0:B3. Este endereço poderia ser escrito da seguinte forma : FF05: :B3. Esta redução somente poderá ser usada uma vez para impedir valores ambíguos.

Os endereços IPv4 ganharam uma notação especial. Eles podem ser escritos com um par de dois pontos seguidos da sua notação tradicional, por exemplo: : : 200.137.131.2

Tipos de endereçamento no IPv6

O IPv6, ao contrário do IPv4, não utiliza a idéia de classes de endereços. Porém utiliza o mesmo tipo de prefixação que passam a indicar os diferentes usos dos endereços. A tabela 3 mostra estas faixas.

Prefixo (binário)

Utilização

Fração

0000 0000

Reservado (incluindo IPv4)

1/256

0000 0001

Não definido

1/256

0000 001

Endereço OSI NSAP

1/128

0000 010

Endereço Novell NetWareIPX

1/128

0000 011

Não definido

1/128

0000 1

Não definido

1/32

0001

Não definido

1/16

001

Não definido

1/8

010

Endereço baseado no Provedor

1/8

011

Não definido

1/8

100

Endereço baseado na localização geográfica

1/8

101

Não definido

1/8

110

Não definido

1/8

1110

Não definido

1/16

1111 0

Não definido

1/32

1111 10

Não definido

1/64

1111 110

Não definido

1/128

1111 1110 0

Não definido

1/512

1111 1110 10

Endereço para uso local do enlace

1/1024

1111 1110 11

Endereços para uso local do site

1/1024

1111 1111

Multicast

1/256

 Tabela 3 - Endereços IPv6 

Os endereços com oito primeiros bits em zero é reservado para o futuro e para compatibilidade com o IPv4. Os endereços IPv4 terão os oitenta primeiros bits com valor zero e os dezesseis bits restantes em um ou zero .

Foi reservado duas faixas de endereços para encapsulamento de protocolos que não sejam o IP, como o OSI NSAP e o Novel IPX.

Uma das faixas destes endereços foi reservado para empresas provedoras de acesso a Internet que passaram a ganhar uma grande parcela de endereçamento e a dividirão hierarquicamente, como mostrado na figura 11. Os três primeiros bits representam o prefixo. O campo REGISTER ID identifica o registro do provedor identificado pelo PROVIDER ID. O campo SUBSCRIBER ID é utilizado pelo provedor para alocar porções deste aos usuários. O SUBNET ID identifica uma ligação física, uma sub-rede. O ultimo campo indica o endereço da interface.

3 bits

N bits

M bits

X bits

Y bits

X-Y bits

010

REGISTRY ID

PROVIDER ID

SUBSCRIBER ID

SUBNET ID

INTERFACE ID

 Figura 11 - Endereço baseado no provedor

O prefixo Geographic Based é igual ao modelo atual. Este prefixo indicaria a região geográfica da rede.

Os endereços para uso local do enlace e de site são utilizados localmente para auto-configuração e redes não conectadas diretamente a Internet. As figuras 12 e 13 mostram o formato destes endereços. Estes endereços poderão ser utilizados para configuração de endereços das interfaces de roteadores ou para redes do tipo Intranet.

10 bits

N bits

118-N bits

1111111010

0

INTERFACE ID

Figura 12 - Endereço para uso local do enlace 

10 bits

N bits

M bits

118-N-M bits

1111111011

0

SUBNET ID

INTERFACE ID

 Figura 13 - Endereço para uso local do site

Os endereços Multicast, como foi citado anteriormente, identificam um grupo de interfaces. Endereços deste tipo possuem o formato da figura 14:

8 bits

4 bits

4 bits

112 bits

11111111

FLAGS

SCOP

GROUP ID

 Figura 14 - Endereços de Multicast 

Os endereços de Multicast são formados por 4 campos, O primeiro campo identifica o prefixo. O seguinte, FLAGS, são sinalizações onde os três primeiros bits estão reservados e o de mais baixa ordem é utilizado para indicar se o endereço é permanente ( valor 0 ) ou provisório ( valor 1 ), ou seja, alocado temporariamente por terceiro.  O campo SCOP indica o escopo do grupo dentro da rede, mostrado na tabela 4. O campo GROUP ID identifica o grupo multicast dentro do escopo dado.

Valor

Escopo

0

Reservado

1

Nó local

2

Link local

3

Não usado

4

Não usado

5

Site local

6

Não usado

7

Não usado

8

Organização Local

9

Não usado

A

Não usado

B

Não usado

C

Não usado

D

Não usado

E

Global

F

Reservado

Tabela 4 - Escopo para um endereço multicast

O fato do IPv6 ter em sua faixa de endereço a do IPv4, não garante a compatibilidade entre eles, pois os datagramas destas versões são incompatíveis, por este motivo esta transição tem sido elaborada de uma maneira bem cuidadosa.

Dois pontos são importantes a considerar sobre a transição destas duas versões: a atualização e a facilidade de fazê-la. Devido a impossibilidade de atualização ao mesmo tempo de todos os computadores e roteadores para a nova versão, os protocolos deverão coexistir durante um certo tempo ( alguns autores falam em até uma década). Isto implica que estes deverão ter seus programas de rede trocados, sem que o resto do mundo precise fazê-lo também. A facilidade por um outro lado deve haver, para que não haja uma relutância pela mudança e assim teríamos a metade da Internet com uma versão e a outra parte mantendo a anterior.

Alguns pontos são levados em conta para que esta transição seja amena. Um deles é que deve se ter pré- requisitos mínimos e especificamente nenhum para roteadores. Um outro, é que as máquinas ao sofrerem atualização deverão poder manter seus endereços IPv4, usando os prefixos reservados para isto. Deverá impor custos baixos. E finalmente, os hosts IPv6 poderão comunicar-se como outro de mesma versão ou da anterior, utilizando toda a infra-estrutura da versão atual. Dois mecanismos foram elaborados para resolver ultima questão: o Dual Stack e o Tunneling.

O Dual Stack consiste em ter as duas camadas completas em um mesmo host. Através do campo Version do seu cabeçalho é decidido qual pilha processará o Datagrama. Para impedir que todos os computadores tivessem as duas pilhas, uma técnica razoável seria a idéia de usar um tradutor. Para usar o tradutor um host IPv6 que precise comunicar-se com um IPv4, gera um datagrama com o endereço IPv4 codificado e utiliza o tradutor para comunicar-se com o destino.

O segundo mecanismo, consiste em transmitir o Datagrama IPv6 como parte dos dados de um Datagrama IPv4. O IPv4 é visto então como um túnel e no final deste túnel, encontra-se o outro computador IPv6.

Através dos estudos realizados neste artigo, percebeu-se que o IPv4 em sua "adolescência", não está apto as novas exigências das tecnologias atuais. Aplicações com características diferentes das existentes, na época que o IPv4 foi criado, foram aparecendo ao longo do tempo exigindo uma reformulação na sua atual estrutura. Além disto, o aumento da popularidade da Internet reforça ainda mais esta idéia, uma vez que não suportará a grande demanda de equipamentos e usuários que ainda irão conectar-se, se a taxa de crescimento da rede permanecer a mesma, dobrando a cada ano.

Historicamente o IPv4 vem sendo gerido por instituições que não tinham o intuito de mantê-lo em um ambiente restrito. A natureza aberta e flexível do IPv4 o tornou, provavelmente, no protocolo mais utilizado no mundo. Qualquer atualização neste, deve considerar o fato para não estar fadado a morrer em pouco tempo.

O IPv6 tem hoje a grande incumbência de substituir o IPv4, mantendo suas melhores características e oferecendo soluções para as várias restrições do IP atual. A solução de migração utilizada, porém, manterá uma convivência harmoniosa entre as duas versões, podendo ocorrer somente quando se fizer necessária.

"A ampliação dos endereçamentos, suporte a aplicações em tempo real, segurança, permissão de evolução no futuro, cabeçalhos mais simplificados, tornando a rede Internet um ambiente estável, confiável e apto para o futuro".

Palavras como estas ditas por pessoas intimamente ligadas a Internet há alguns anos atrás, reforça a idéia da real necessidade de mudança da versão 4 do IP ( IPv4 ). Além disto, este protocolo que tem sua versão lançada no início da década de 70, não acompanhou a evolução tecnológica atual.

 

Sócrates C. Quintanilha
socrates@bufaloinfo.com.br





Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : Patrícia Albuquerque E-Mail : prarezende@yahoo.com.br
Muito esclarecedor e didático.
Nome : Eider E-Mail : davi@fg.com.br
Davi, dá uma verificada neste trabalho
Nome : Eliene E-Mail : elieneoliveira@rjz.com.br
Imprimir para ESTUDAR INF145
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::



Quer saber mais?
Faça um curso na Búfalo Informática, Treinamento e Consultoria e
Prepare-se para o Mercado!
Veja o que a Búfalo tem para você.

� Búfalo Informática, Treinamento e Consultoria - Rua Álvaro Alvim, 37 Sala 920 - Cinelândia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br