NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
30 de junho de 1997 | volume 1, número 2

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



O que Vai Mudar na sua Vida com o IPv6

Adailton J. S. Silva <>

Rede Nacional de Ensino e Pesquisa (RNP)

Historico
Novo Formato
Novo Cabecalho
Tipos de Enderecos
Endereco Unicast
Endereco Anycast
Endereco Multicast
Novas Funcionalidades
Considerações para Migracao
Conclusão
Referências

Muitas discussões, algumas mudanças, novas características, novas funcionalidades, algumas controvérsias mas um alto índice de unanimidade, e pronto. Estava pronta a tão esperada nova versão do IP, o IP Next Generation (IPng), ou, oficialmente, o IPv6, que surgiu como uma nova tecnologia para acabar com a possível escassez de endereços da atual versão em uso (IPv4), para freiar o crescimento vertiginoso das tabelas de rotas e, principalmente, para causar uma grande revolução na Internet. Saiba por que, lendo este artigo.

^

Historico

Em Junho de 1992, acontecia um dos encontros do IAB (Internet Activities Board) em paralelo ao congresso da Internet Society. Ja' era evidente a necessidade de uma nova versao para o endereco IP. Durante o en- contro propuseram, tentaram e conseguiram convencer o IAB da adocao do CLNP (Connection-Less Network Protocol) da ISO, como sucessor do IPv4. Com um "draft" discutido e revisado, o IAB estava pronto para convencer a comuni- dade Internet, quando um precipitado anuncio em jornal causou o maior rebu- lico, e com isso os membros da comunidade se sentiram traidos. Achava-se, entao, que estavam "vendendo" a Internet para a ISO, uma "inimiga" contra a qual se tinha lutado por varios anos e que ja' estava vencida, e que o IAB nao tinha o direito de tomar essa decisao sozinho.

No mesmo encontro, surgiram tres propostas. A do CLNP, que foi cha- mada de TUBA (TCP and UDP over Bigger Address). Uma denominada IP versao 7, de Robert Ullman que, em 1993, propos outra versao chamada TP/IX, refletin- do mudancas no TCP e no IP ao mesmo tempo; e, em 1994, propos uma nova ver- sao chamada CATNIP, como ensaio para compatibilidade entre enderecos IP, CLNP e IPX.

A ultima proposta foi chamada de "IP in IP". Em 1993, esta proposta foi modificada e passou a se chamar IPAE (IP Address Encapsulation). O IPAE foi adotado como estrategia de transicao para o SIP (Simple IP), proposto por Steve Deering em Novembro de 1992.

O SIP aumentava o endereco IP para 64 bits, tornava a fragmentacao de pacotes opcional e eliminava varios aspectos obsoletos do IP. Rapidamente, ganhou a adesao de varios fabricantes e cientistas.

Em setembro de 1993, Paul Francis propos uma nova especificacao, o Pip (Paul's internet protocol). Fundamentado no Pip, Francis propos uma nova estrategia de roteamento baseada em listas diretivas. Isso permitiria uma implementacao eficiente de politicas de roteamento, facilitando, inclusive, a implementacao de mobilidade. A uniao do SIP com o Pip foi chamada de SIPP (Simple IP Plus).

Em junho de 1994, a comissao do IPng revisou todas as propostas e publicou sua recomendacao em julho de 94, sugerindo o SIPP como a base para o novo protocolo IP, mas com mudancas em algumas caracteristicas chaves da especificacao original. Particularmente, o novo protocolo teria 128 bits e se chamaria IPv6. O numero 5 havia sido alocado ao protocolo ST (stream), um protocolo experimental para suportar servicos em tempo real em paralelo com o IP.

^

Novo Formato

Uma das mais importantes caracteristicas e' o novo formato de ende- reco. O IPv6 amplia o atual endereco de 32 para 128 bits, acaba definitiva- mente com as classes de enderecos e possibilita um metodo mais simples de auto-configuracao.

Ha' tres formas de representacao do endereco IPv6. A notacao mais usual e' x:x:x:x:x:x:x:x, onde os "x" sao numeros hexadecimais, ou seja, o endereco e' dividido em oito partes de 16 bits, como no seguinte exemplo:

   1080:0:0:0:8:800:200C:417A

Apenas 15% de todo espaco de enderecamento IPv6 esta' previamente alocado, ficando os 85% restantes para uso futuro. Devido a essa pre-alocacao, sera' comum enderecos com longas sequencias de bits zero. Estas sequencias de zeros podem ser substituidas pela string "::". No entanto, esta substituicao so' pode ser feita uma unica vez em cada endereco. A tabela abaixo mostra alguns exemplos na forma completa e na forma abreviada, como apresentado em [RFC1884].


Endereco              Forma Completa                  Forma Abreviada

Unicast               1080:0:0:0:8:800:200C:417A      1080::8:800:200C:417A
Multicast             FF01:0:0:0:0:0:0:43             FF01::43
Loopback              0:0:0:0:0:0:0:1                 ::1
Unspecified           0:0:0:0:0:0:0:0                 ::

A terceira opcao de representacao, mais conveniente quando em ambi- entes mistos com nodes IPv4 e IPv6, e' da forma x:x:x:x:x:x:d:d:d:d, onde os "x" sao numeros hexadecimais (16 bits) e os "d" sao valores decimais de 8 bits referentes `a representacao padrao ja' bem conhecida do IPv4. Por e- xemplo:

   0:0:0:0:0:0:192.168.20.30

ou, na forma abreviada:

   ::192.168.20.30

Esta forma de notacao sera' bastante util durante a migracao do IPv4 para o IPv6 e na coexistencia entre ambos.

^

Novo Cabecalho

Outra caracteristica importante do IPv6 e' o seu novo e simplificado formato de cabecalho. O cabecalho IPv6 e' constituido por um cabecalho inicial de 64 bits, seguido dos enderecos de origem e destino de 128 bits, totalizando 40 bytes.

Enquanto o cabecalho do IPv4 possui 10 campos de cabecalho, dois enderecos de 32 bits cada, e algumas opcoes, o cabecalho IPv6 compoe-se apenas de 6 campos de cabecalho e dois enderecos 128 bits cada. Os seis campos de cabecalho sao: version (4 bits), priority (4 bits), flow label (28 bits) e length of the payload (16 bits).

Ainda comparando-se o formato do IPv6 com o do IPv4, os mecanismos de opcoes foram completamente revisados, seis campos foram suprimidos (header length, type of service, identification, flags, fragment offset e header checksum), tres foram renomeados e, em alguns casos, ligeiramente modificados (length, protocol type e time to leave), e dois foram criados (priority e flow label).

As simplificacoes mais consideraveis do IPv6 foram a alocacao de um formato fixo para todos os cabecalhos, a remocao do checksum de cabecalho e remocao dos procedimentos de segmentacao "hup-by-hop".

A remocao de todos os elementos opcionais nao significa que nao se possa configurar servicos especiais. Estes poderao ser obtidos atraves de cabecalhos denominados "extension headers", que sao anexados ao cabecalho principal.

A remocao do checksum de cabecalho poderia gerar problemas no roteamento dos pacotes, mas o IPv6 pressupoe que as camadas inferiores sao confiaveis, com seus respectivos controles de erros como, por exemplo, o 802.2 LLC (Logical Link Control) para redes locais, o controle das camadas de adaptacao dos circuitos ATM e o controle do PPP para links seriais.

A cada salto de um pacote IPv6, os roteadores nao precisarao se preocupar com o calculo do tamanho do cabecalho, que e' fixo, com o calculo do checksum do cabecalho, e nem com as tarefas de fragmentacao, que serao realizadas pelos hosts. Todas estas modificacoes aumentarao substancialmente o desempenho dos roteadores.

^

Tipos de Enderecos

No IPv6, foram especificados apenas tres tipos de enderecos: Unicast, Anycast e Multicast. Sendo assim, diferente do IPv4, nao mais existem enderecos Broadcast. Esta funcao passa a ser provida pelo endereco Multicast.

^

Endereco Unicast

Identifica apenas uma interface. Um pacote destinado a um endereco unicast é enviado diretamente para a interface associada ao endereco. Foram definidos varios tipos de enderecos unicast, que sao:

Tambem esta' reservado 12,5% de todo espaco de enderecamento IPv6 para enderecos a serem distribuidos geograficamente (geographic-based).

^

Endereco Anycast

Identifica um grupo de interfaces de nodes diferentes. Um pacote destinado a um endereco anycast e' enviado para uma das interfaces identificadas pelo endereco. Especificamente, o pacote e' enviado para a interface mais proxima de acordo com a medida de distancia do protocolo de roteamento.

Devido `a pouca experiencia na Internet com esse tipo de endereco, inicialmente seu uso sera' limitado:

Este tipo de enderecamento sera' util na busca mais rapida de um determinado servidor ou servico. Por exemplo, pode-se definir um grupo de servidores de nomes configurados com um endereco anycast; o host acessara' o servidor de nomes mais proximo utilizando este endereco.

^

Endereco Multicast

Igualmente ao endereco anycast, este endereco identifica um grupo de interfaces, mas um pacote destinado a um endereco multicast e' enviado para todas as interfaces do grupo.

As funcionalidades de multicasting foram formalmente incorporadas ao IPv4 em 1988, com a definicao dos enderecos classe D e do IGMP (Internet Group Management Protocol), e ganhou forca com o advento do MBONE (Multicasting Backbone) mas seu uso ainda nao e' universal. Desta vez, estas funcionalidades foram automaticamente incorporadas ao IPv6. Isto significa que nao mais sera' necessario implementar tuneis MBONE, pois todos os hosts e roteadores IPv6 deverao suportar multicasting.

^

Novas Funcionalidades

Alem de um maior espaco de enderecos e das modificacoes apresenta- das anteriormente, o IPv6 possui varias outras caracteristicas interessan- tes como:

Autoconfiguração

Quando se instala uma estacao cliente numa rede Netware, automaticamente, e' assinalado um endereco IPX para este cliente. Esta caracteristica de autoconfiguracao, denominada "stateless autoconfiguration", estara' presente no IPv6. Isso eliminara' a necessidade de se configurar manualmente as estacoes da rede.

Para um maior controle de redes muito grande, os administradores poderao optar por uma outra forma de autoconfiguracao, conhecida como "stateful autoconfiguration". Esta opcao sera' disponibilizada por uma nova versao do DHCP (DHCPv6).

Seguranca

As especificacoes do IPv6 definiram dois mecanismos de seguranca: a autenticacao de cabecalho (authentication header, [RFC1826]) ou autenticação IP, e a seguranca do encapsulamento IP (encrypted security payload, [RFC1827]).

A autenticacao de cabecalho assegura ao destinatario que os dados IP sao realmente do remetente indicado no endereco de origem, e que o conteudo foi entregue sem modificacoes. A autenticacao utiliza um algoritmo chamado MD5 (Message Digest 5), especificado em [RFC1828].

A seguranca do encapsulamento IP permite a autenticacao dos dados encapsulados no pacote IP, atraves do algoritmo de criptografia DES (Data Encryption Standard) com chaves de 56 bits, definida em [RFC1829].

Os algoritmos de autenticacao e criptografia citados acima utilizam o conceito de associacao de seguranca entre o transmissor e o receptor. Assim, o transmissor e o receptor devem concordar com uma chave secreta e com outros parametros relacionados `a seguranca, conhecidos apenas pelos membros da associacao. Para gerenciar as chaves provavelmente sera' utilizado o IKMP (Internet Key Management Protocol), desenvolvido pelo grupo de trabalho em Seguranca IP.

Suporte a Servicos em Tempo Real

Na especificacao do IPv6, o termo "flow" ou fluxo pode ser definido como uma sequencia de pacotes de uma determinada origem para um determinado destino (unicast ou multicast), na qual a origem requer um tratamento especial pelos roteadores.

Os campos "priority" e "flow label" foram criados especialmente pa- ra facilitar o desenvolvimento de protocolos para controle de trafego em tempo real, como o RSVP (Resource Reservation Protocol), de forma a permitir a implementacao de uma Internet com aplicacoes multimidia e com a integracao de servicos de dados, voz e video em tempo real.

Suporte a Multiprotocolos e Mobilidade

Observa-se, dos tipos de enderecos unicast citados anteriormente, que foi reservada parte do espaco de enderecamento para enderecos NSAP e IPX. Assim, o IPv6 suportara' automaticamente trafego de redes OSI (endereços NSAP) e de rede Netware/Novell (endere cos IPX). Uma grande porção do espaco de enderecamento IPv6 foi reservada para uso futuro. Essa porção tambem podera' ser alocada para outros protocolos que se tornarem padroes de fato.

O suporte a comunicacoes moveis tambem esta' presente no IPv6. Encontra-se em estudo um metodo para que, no estabelecimento inicial de uma sessao, um host IPv6 descubra dinamicamente atraves de um agente central, a localizacao de uma estacao movel.

^

Considerações para Migracao

Ha' pouco mais de um ano, a complementacao das especificacoes IPv6 foi estimada em 70% e que ja', no inicio de 97, os fabricantes de software comecariam a desenvolver seus sistemas incluindo o novo protocolo.

Estima-se tambem que, a partir do inicio de 1998, comecara' o processo de migracao do IPv4 para o IPv6, colocando-se em pratica as estrategias de transicao. Tecnicamente, foram definidas varias delas:

Ha' varias outras questoes e observacoes sobre o processo de transição que devem ser consideradas como: planejamento de alocacao de enderecos, requisitos de software (sistemas operacionais e aplicativos), requitos de hardware (memoria e CPU), velocidade dos links, recursos financeiros, etc. Todos estes fatores serao imprecindiveis para o exito de um plano de transicao.

^

Conclusão

E agora? Voce ja' sabe o que vai mudar em sua vida com a chegada do IPv6? Percebe-se claramente que muita coisa ira' mudar: nova terminologia, novas e interesssantes caracteristicas, novo processo de roteamento com o IDRP (Inter-Domain Routing Protocol), etc.

Para os que trabalham diretamente no projeto e implementacao de redes de computadores TCP/IP, a adaptacao a esta nova tecnologia sera' inevitavel. E, para nao ter que pegar o "bonde" andando, a preparacao para essa revolucao deve ser iniciada desde ja', tendo-se em vista um planejamento criterioso de acoes para o processo de transicao e implementacao do 6-BONE.

^

Referências

[RFC1933] Gilligan, R. e Nordmark, E. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, Sun Microsystems, Inc., Abril/1994.

[RFC1924] Elz, R. "A Compact Representation of IPv6 Addresses", RFC 1924, University of Melbourne, Abril/1996.

[RFC1897] Hinden R. e Postel J. "IPv6 Testing Address Allocation", RFC 1897, Ipsilon Networks e ISI, Janeiro/1996.

[RFC1887] Rekhter, Y. e Li, T. "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, Cisco Systems, Dezembro/1995

[RFC1886] Thomson S., e Huitema, C. "DNS Extensions to support IP version 6", RFC 1886, Bellcore e INRIA, Dezembro/1995.

[RFC1885] A. Conta, A., e Deering S. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment e Xerox PARC, Dezembro/1995.

[RFC1829] Karn, P., Metzger, P. e Simpsom, W. "The ESP DES-CBC Transform", RFC 1829, Qualcomm, Piermont e Daydreamer, Agosto/1995.

[RFC1828] Metzger, P. e Simpsom, W. "IP Authentication using Keyed MD5", RFC 1828, Piermont e Daydreamer, Agosto/1995.

[RFC1827] Atkinson, R. "IP Encapsulating Security Payload (ESP)", RFC 1827, Naval Research Laboratory, Agosto/1995.

[RFC1826] Atkinson, R. "IP Authentication Header", RFC 1826, Naval Research Laboratory, Agosto/1995.

[RFC1825] Atkinson, R. "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, Agosto/1995.

[RFC1519] Fuller, V., Li, T., Yu, J. e Varadahan, K. "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, Cisco, MERIT e OARnet, Setembro/1993.

[RFC1883] Deering, S. e Hiden, R. "Internet Protocol, Verion 6 (IPv6) Specification", RFC 1883, Xerox PARC e Ipsilon Networks, Dezembro/1995.

[RFC1884] Hiden, R. e Deering, S. "IP Verion 6 Addressing Architecture", RFC 1884, Ipsilon Networks e Xerox PARC, Dezembro/1995.

[HUITEMA] Huitema, Christian "IPv6 - The New INTERNET PROTOCOL", Prentice Hall Inc., New Jersey, 1996.

[MENDES] Mendes, Gerald H. "A Nova Geracao de IP Toma Forma", Business Communications Review Brasil, No. 2, Maio/1996.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004