Este sítio web funciona com IPv6. Se o globo estiver girando, você também já usa IPv6!

a. 1990 - No encontro IETF de Vancouver conforme Frank Solensky, Phill Gross e Sue Hares afirmaram que à taxa de atribuição do espaço de endereçamento IPv4, as classes do tipo B estariam esgotadas possivelmente por volta de Março de 1994.
b. 1991 - A Internet Engineering Task Force (IETF) forma o grupo de trabalho Routing and Addressing (ROAD) no encontro de Santa Fé com o objetivo de encontrar uma solução para a exaustão do espaço de endereçamento IPv4.
c. 1992 - A Internet Association Board (IAB) apresenta o documento IP version 7 paralelamente aos esforços do grupo de trabalho ROAD, em que recomenda à IETF a preparação de um plano detalhado para o sucessor do protocolo IP. A IETF rejeita esta sugestão e apresenta pedido de propostas recomendadas pelo grupo ROAD. Como resposta a este pedido surgiram algumas propostas:
- IP Encaps
- Nimrod
- Simple CLNP
d. 1992 (finais) - Surgem mais três propostas:
- The P Internet Protocol (PIP)
- The Simple Internet Protocol (SIP)
- TP/IX
e. 1993 – Phil Gross – Internet Engineering Steering Group (IESG) apresenta um memorando intitulado "_A Direction for IPng_" onde anuncia a criação de uma área temporária para o IPng. CLNP e IP Encaps evoluem, dando origem respectivamente a TCP and UDP with Bigger Addresses, TUBA e IPAE.
f. 1993 (finais) - SIP evoluiu, abrangendo características do IPAE (IP Address Encapsulation). O IPAE foi adotado como estratégia de transição para o SIP (Simple IP), proposto por Steve Deering em Novembro de 1992. O SIP aumentava o endereço IP para 64 bits, tornava a fragmentação de pacotes opcional e eliminava vários aspectos obsoletos do IP.
g. Em junho de 1994, a comissão do IPng revisou todas as propostas, SIP e PIP, deram origem à proposta The Simple Internet Protocol Plus (SIPP) e publicou sua recomendação sugerindo o SIPP como a base para o novo protocolo IP, mas com mudanças em algumas características chaves da especificação original. Particularmente, o novo protocolo teria 128 bits e se chamaria IPv6. Ocorreu então a aprovação do documento The Recommendation for the IP Next Generation Protocol como norma oficial de desenvolvimento do IPng (Rosa, 1999).
| AT | Áustria | AU | Austrália | |
| BE | Bélgium | BG | Bulgaria | |
| BR | Brazil | CA | Canada | |
| CH | Switzerland | CM | Cameroon | |
| CN | China | CZ | Czech Republic | |
| DE | Germany | DK | Denmark | |
| ES | Spain | FI | Finland | |
| FR | France | GB | Great Britain | |
| GR | Greece | HK | Hong Kong | |
| HU | Hungary | IE | Ireland | |
| IT | Italy | JP | Japan | |
| KR | Korea | KZ | Kazakhstan | |
| LT | Lithuania | MX | México | |
| NL | Netherlands | NO | Norway | |
| PL | Poland | PT | Portugal | |
| RO | România | RU | Russian Federation | |
| SE | Sweden | SG | Singapore | |
| SI | Slovenia |
Tabela dos países integrados ao IPv6.
Operacional desde junho de 1996, este backbone é implementado através de uma rede virtual sobre a rede física IPv4 da atual Internet. A rede virtual é composta de redes locais IPv6 ligadas entre si por túneis ponto-a-ponto IPv6 sobre IPv4. Os túneis são realizados por roteadores com pilha dupla (IPv6 e IPv4) com suporte para roteamento estático e dinâmico (RIPng e BGP4+), e as redes locais IPv6 são compostas por estações com sistemas operacionais com suporte a IPv6 ou com pilha dupla (IPv4 e v6). No entanto, a rede 6bone é independente da IETF, sendo um projeto que reúne voluntariamente diversas instituições do mundo inteiro. O projeto 6bone tem sofrido a seguinte evolução:
a. 1995 - Concepção do projeto 6bone.
b. 1996 (Março) - Formalização do projeto 6bone em Março, no encontro IETF em Los Angeles.
c. 1996 (Junho) - Início da rede 6bone, através da criação de dois túneis: um entre a Universidade de Lisboa (UL/PT), o Navy Research Laboratory (NRL/US) e a CISCO (CISCO/US) e o outro entre a UNI-C (UNIC/DK), o grupo G6 do instituto de pesquisa IMAG (G6/FR) e o grupo WIDE, do Japão (WIDE/JP).
d. 1996 (Dezembro) - Formação do grupo de trabalho 6bone (atualmente NGtrans).
e. 1997 (Agosto) - No encontro do grupo de trabalho ngtrans-6bone que teve lugar em Munique, referiu-se que existiam mais de 150 sites IPv6 em 28 países participantes na 6bone. O protocolo de encaminhamento do backbone da 6bone passou a ser o BGP4+. Foi criado o domínio 6bone.net, através do qual se pode aceder às páginas e base de dados 6bone.
f. 1997 (Dezembro) - No encontro de Washington, a 6bone apresentava já 206 sites em 30 países participantes.
g. 1998 (Março) - No encontro de Los Angeles, a 6bone apresentava 240 sites IPv6 em 32 países. Neste encontro, foi acordado que os pTLA usariam entre si o protocolo de encaminhamento BGP4+ (HINDEN, 1994).
a. Aumento do número de endereços na Internet: Passamos assim a ter muitas vezes mais endereços IPs.
b. Melhoramento do Routing: carregando menos os routers é possível ter uma melhor performance na Internet, especialmente quando são routers principais.
c. Possibilitar autoconfiguração: de modo a que seja retirado trabalho para o utilizador final, que deseja conectar a sua máquina em qualquer ponto da rede e obter rede e end. IP.
d. Operação em redes de alto débito: com cada vez mais rápidas redes, é necessário adaptar o protocolo para retirar a maior performance delas. O IPv4 nunca foi pensado para redes de alto débito.
e. Prover melhor segurança, criar mecanismos de proteção no próprio protocolo. Confidencialidade e privacidade: algo que falta no IPv4 e que é implementado a nível aplicacional é justamente a confidencialidade. Torna-se necessário codificar os dados a nível de IP.
f. Capacidade de QoS: dado que existe uma variedade de tipos de tráfego sobre IP, é necessário saber distinguí-los e dar prioridades diferentes para cada caso, de modo a garantir uma qualidade de serviço.
g. Suportar bilhões de hosts, mesmo que os endereços fossem alocados de forma ineficiente.
h. Reduzir o tamanho da tabela de rotas.
i. Simplificar o protocolo para permitir que os roteadores processem os pacotes mais rapidamente.
j. Dar maior atenção ao tipo de serviço trafegado, particularmente para dados de Tempo Real.
k. Permitir o escopo do alcance de um pacote (Multicasting).
l. Fazer o possível para que um host tenha mobilidade sem mudar seu endereço.
m. Permitir que o protocolo evolua no futuro.
n. Permitir que protocolos antigos e novos coexistam por anos.
Licença:
Creative Commons Atribuição 2.5 Brasil (salvo seja especificada outra)
Válido:
XHTML 1.0 -
CSS 3