Escola Politcnica da Universidade de So Paulo

Laboratrio de Arquitetura e Redes de Computadores

IPv4 e IPv6
Por George Marcel M. A. Smetana (gsmetana@larc.usp.br)

O primeiro n da ARPANET, na UCLA, e um de seus criadores, Leonard Kleinrock.

1. Introduo
Neste artigo sero apresentados os protocolos IPv4, ICMPv4 e IPv6 da camada de rede da arquitetura TCP/IP. Esses protocolos so chamados de protocolos roteveis, porque seus pacotes podem ser roteados utilizando-se a informao do endereo da rede de destino contido neles. Na camada de rede h tambm os chamados protocolos de roteamento, que realizam o roteamento de pacotes baseado no endereo da rede de destino, atravs da utilizao de algum algoritmo. Exemplos de protocolos de roteamento so o RIP, RIPv2, IGRP, EIGRP, OSPF, IS-IS e BGP, que no sero discutidos aqui. Os protocolos ARP e RARP trabalham entre a camada de rede e a camada de enlace e no sero apresentados aqui.

2. Protocolos
2.1. Introduo ao IPv4
Embora o IP seja o protocolo de rede mais conhecido, deve ser mencionado que a idia de se transmitir mensagens por uma rede persegue o homem a milhares de anos. Deixando lendas de lado e atendo-se aos fatos histricos, por volta de 700 aC, j eram utilizados pombos para se transmitir mensagens na Grcia antiga. As comunicaes evoluram muito desde ento... Em 1957, os russos colocaram em rbita o Sputnik, o primeiro satlite artificial, ganhando uma corrida espacial contra os americanos. Como resposta, em 7 de fevereiro de 1958 o Departamento de Defesa dos Estados Unidos (Department of Defense DoD), atravs da Diretiva 5105.15, decidiu criar a (Defense) Advanced Research Projects Agency 1 ((D)ARPA Agncia de Pesquisas de Projetos Avanados de Defesa). A DARPA tinha como misso garantir que os Estados Unidos estivessem sempre na dianteira tecnolgica militar e antecipar quais seriam os avanos tecnolgicos dos adversrios. Com o passar dos anos, a DARPA teve a necessidade de criar um protocolo de comunicao por comutao de pacotes2 capaz de interconectar computadores heterogneos. Ento, a DARPA lanou uma licitao para o projeto de um hardware que eles chamaram de Interface Message Processor (IMP Processador de Mensagens de Interface), que deveria ser o n de comutao de pacotes. Empresas como IBM e AT&T achavam que no era possvel realizar tal tarefa. Ento, uma pequena empresa, formada por dois professores de Cambridge e um ex-aluno de um deles, chamados Bolt, Beranek e Newman, respectivamente, venceu a concorrncia para desenvolver tal tecnologia. A empresa a renomada Bolt, Beranek & Newman, tambm conhecida como BBN. Em 7 de abril de 1969, Steve Crocker criou o primeiro Request for Comments (RFC 1 Host Software Requisitando Comentrios 1 Software de Host), identificando como deveria ser o software de um host em uma rede, no caso, o software do IMP. A BBN trabalhando em conjunto com o Information Processing Techniques Office (Escritrio de Tcnicas de Processamento de Informao) da DARPA desenvolveu a primeira IMP da ARPANET, entregue em 1971, implementado em um minicomputador da Honeywell.

1 2

O nome original era ARPA, depois mudou para DARPA, a voltou a ser ARPA, depois novamente DARPA... A idia original da comutao de pacotes foi apresentada por Leonard Kleinrock, em sua proposta de Ph.D. no MIT em 1959. Seu trabalho gerou a inspirao da ARPANET. O primeiro n (IMP) da ARPANET foi estabelecido na UCLA, sob o comando de uma equipe chefiada por Kleinrock.

Em maio de 1974, Vint Cerf e Bob Kahn publicaram um paper chamado A Protocol for Packet Network Internetworking (Um Protocolo para Comunicao entre Redes de Pacotes), que estabelecia o TCP (Transmission Control Protocol Protocolo de Controle de Transmisso). Foi a primeira vez que o termo Internet foi utilizado. Em 1978, quando Vint Cerf, Steve Crocker e Danny Cohen decidiram passar as funes de roteamento do TCP para um protocolo separado, surgiu o IP. O TCP continuaria com as funes de correo de erro e funes de datagrama. A especificao do IPv4 foi publicada em setembro de 1981, sob o RFC 791, com o auxlio do Information Sciences Institute University of Southern California (Instituto de Cincias da Informao da Universidade do Sul da Califrnia). Em 1982 o TCP e o IP foram adotados como os protocolos oficiais da ARPANET. A popularizao do IP veio quando ele passou a ser distribudo pelo Berkeley Software Distribution UNIX (BSD UNIX), verso 4.2c, em 1983. Ser estudado aqui o IPv4. Chama-se de arquitetura TCP/IP o conjunto de protocolos que utilizam os TCP e o IP para estabelecer a comunicao entre redes. Uma comparao da arquitetura TCP/IP com a do modelo OSI (Open Systems Interconnection Sistemas Abertos de Interconexo) da ISO e da ITUT, como vista na figura abaixo.

Aplicao TCP/UDP IP Rede Local

Arquitetura TCP/IP

Aplicao Apresentao Sesso Transporte Rede Enlace Fsica

Arquitetura OSI

Figura 2.1.1 Comparao da Arquitetura TCP/IP com o modelo OSI de referncia.

2.1.1. A especificao do IPv4

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

Version TTL

IHL Identification

TOS Flags Protocol Source Address Destination Address (Options + Padding) Data

Total Length Fragment Offset Header Checksum

Figura 2.1.1.1 Especificao do IPv4 (RFC 791). Version (Verso): 4 bits. A verso atual a 4. IHL (Internet Header Length Comprimento do Cabealho Internet): 4 bits. Informa o comprimento do cabealho Internet em palavras de 32 bits (4 octetos ou 4 bytes). O tamanho mnimo do cabealho de 5 palavras de 32 bits (20 octetos), e o tamanho mximo (o campo Option 2

+ Padding tem tamanho varivel) de 15 palavras de 32 bits (60 octetos). Aponta para o campo de dados. TOS (Type of Service Tipo de Servio): 8 bits. utilizado para indicar o QoS (Quality of Service Qualidade de Servio) desejado. Seus bits caracterizam os servios escolhidos para serem considerados pelos gateways para processar o pacote, como por exemplo, a precedncia de um pacote. Um roteador (pode ser chamado de gateway) pode em situaes de grande congestionamento, por exemplo, aceitar somente pacotes com um certo nvel mnimo de precedncia. Geralmente, deseja-se baixo atraso, alta confiabilidade e alto throughput (vazo).
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

TOS Figura 2.1.1.2 Subdiviso do campo TOS. Bits 012 Descrio Precedence (Precedncia)

Precedence

3 4 5 67

000: Routine (Rotina) 001: Priority (Prioridade) 010: Immediate (Imediato) 011: Flash (Relmpago) D (Delay 0: Atraso normal. Atraso) 1: Atraso baixo. T (Throughput 0: Vazo normal. Vazo) 1: Alta vazo. R (Relibility 0: Confiabilidade normal. Confiabilidade) 1: Alta confiabilidade. Reservados Obrigatoriamente 00.

Valores 100: Flash Override (Relmpago Precedente) 101: Critic/ECP (Crtico) 110: Internetwork Control (Controle entre Redes) 111: Network Control (Controle de Rede)

Tabela 2.1.1.1 Significado do campo TOS. O nvel de precedncia crescente. Total Length (Comprimento Total): 16 bits. Informa o comprimento do datagrama, em octetos (bytes). O tamanho mximo do datagrama pode ser 65.535 octetos (64 kB). Esse tamanho de octeto impraticvel para a maior parte de hosts e redes. Todos os hosts devem ser capazes de no mnimo aceitar datagramas de at 576 octetos, fragmentados ou no. Esse nmero foi determinado, partindo-se do pressuposto que 512 octetos seria um nmero razovel de dados a ser enviado, considerando-se mais 64 bytes de cabealho, sendo que o tamanho mximo do cabealho Internet de 60 octetos, mas o tamanho tpico de 20 octetos, dando-se margem para cabealhos de outras camadas. Recomenda-se que os hosts s enviem datagramas maiores que 576 bytes se houver a certeza que o endereo destino aceita receber a quantidade de dados enviados. Identification (Identificao): 16 bits. Nmero de identificao do datagrama para permitir que o destino remonte os datagramas. Flags (Sinalizadores): 3 bits. Bits que identificam a transmisso de sinais de controle.
0 1 2 0 1 2

Flags Figura 2.1.1.3 Subdiviso do campo Flags.

DF

MF

Bit Descrio 0 Reservado 1 DF (Don Fragment No Fragmente) t 2

Valores Obrigatoriamente 0. 0: Esse datagrama pode ser fragmentado. 1: Esse datagrama no pode ser fragmentado. MF (More Fragments Mais Fragmentos) 0: Esse datagrama o ltimo fragmento. 1: H mais fragmentos.

Tabela 2.1.1.2 Significado dos bits do campo Flags. Fragment Offset (Deslocamento do Fragmento): 13 bits. Esse campo indica a posio desse fragmento em relao ao do datagrama original. O valor desse campo expresso em unidades de 8 octetos (64 bits), portanto o tamanho mnimo do campo de dados de um fragmento de 64 bits. O primeiro fragmento tem valor 0 nesse campo. TTL (Time to Live Tempo de Vida): 8 bits. Indica o tempo mximo que o datagrama pode permanecer na rede. Se o valor nesse campo for 0, o datagrama deve ser destrudo. A inteno desse campo no permitir que datagramas cujo destino seja inalcanvel fiquem eternamente circulando pela rede. Inicialmente, a unidade do TTL era segundos, mas como cada unidade processadora de datagramas (roteadores, switches de camada 3, etc.) deve diminuir o TTL de uma unidade e o tempo de processamento de pacotes muito inferior a 1 s, o TTL passa a ser somente um limite superior da existncia de cada datagrama. Protocol (Protocolo): 8 bits. Indica o protocolo da camada superior que est utilizando os servios da camada IP. Esses valores esto definidos no RFC 790 Assigned Network Numbers (Nmeros de Redes Designados) de 1981. Esse RFC foi substitudo pelo RFC 1700 Assigned Numbers. O nmero do TCP, por exemplo, 6. Quando o IP estiver encapsulado em outra camada IP, como em uma Virtual Private Network, por exemplo, o valor desse campo 4. Header Checksum (Verificao da Soma do Cabealho): 16 bits. Esse checksum calculado somente sobre o cabealho IP. Como alguns campos mudam freqentemente, como o TTL, esse valor tem que ser recalculado. Para se calcular esse checksum, faz-se o complemento de um de cada palavra de 16 bits do cabealho, soma-se elas e faz-se o complemento de um da soma total (para efeitos de clculo, o campo Header Checksum vale 0). Embora esse algoritmo seja simples, ele suficiente e seguro para a maioria das situaes. Pode ser que ele seja substitudo por um algoritmo do tipo CRC. Source Address (Endereo de Origem): 32 bits. Informa o endereo de origem. Destination Address (Endereo de Destino): 32 bits. Informa o endereo de destino. Essa informao utilizada pelos roteadores para o encaminhamento (roteamento) do datagrama. Alguns equipamentos podem utilizar os campos IP de origem, de destino e at mesmo informaes de protocolos de nveis superiores e o tipo de dado sendo transmitido para realizar o roteamento de pacotes e juntamente realizar algum tipo de priorizao ou QoS. Options (Opes): Tamanho varivel, entre 0 e 320 bits (40 octetos). O que opcional a transmisso ou no desse campo, no a implementao. Todo os roteadores e gateways devem implementar meios de codificao/decodificao desse campo. Pode haver mais de uma opo nesse campo. As opes servem, entre outras coisas, informar se o prprio campo Option deve ou no ser copiado para os fragmentos, caso o pacote venha a ser fragmentado, para embutir um timestamp da rede, adicionar informaes relativas ao nvel de segurana do pacote (confidencialidade) ou para especificar uma rota para um determinado destino. Mais informaes sobre esse campo podem ser encontradas no RFC 791.

 Padding (Enchimento): Tamanho varivel, entre 0 e 31 bits. O campo Padding serve apenas para que o cabealho IP tenha um tamanho mltiplo de 32 bits. S se faz o enchimento (obrigatoriamente com 0), se o tamanho do campo Option no for mltiplo de 32 bits.

2.1.2. O endereamento no IPv4 Os 32 bits de endereamento do IPv4 esto separados em duas partes, sendo que a primeira informa o endereo de rede e a segunda, o endereo de host. A representao do endereo IPv4 feita atravs da chamada notao decimal pontuada. Nela, cada um dos quatro bytes do endereo IPv4 representado pelo seu valor decimal, separados por um .. Originalmente, foram definidas 3 classes de endereo, identificadas pelo valor dos primeiros bits do endereo de rede, para atender s necessidades de redes de diferentes tamanhos. A figura abaixo mostra essa diviso. Classe A: 0.0.0.0 a 127.255.255.255 Aplicao: Para as poucas organizaes que possuem redes com nmero muito grande de hosts.
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

Endereo de rede

Endereo de host

Classe B: 128.0.0.0 a 191.255.255.255 Aplicao: Para organizaes de tamanho mdio, com nmero relativamente grande de hosts.
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

1 0

Endereo de rede

Endereo de host

Classe C: 192.0.0.255 a 223.255.255.255 Aplicao: Para organizaes pequenas, com nmero pequeno de hosts.
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

1 1 0

Endereo de rede

Endereo de host

Modo de endereamento extendido: 224.0.0.0 a 255.255.255.255 Aplicao: Uso experimental.

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

1 1 1

Endereo extendido

Figura 2.1.2.1 Formato original dos endereos, suas classes e as faixas de endereos. Depois, foram definidas mais 2 classes de endereos:

Classe D: 224.0.0.0 a 239.255.255.255 Aplicao: Transmisso de trfego multicast.

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

1 1 1 0 Classe E: 240.0.0.0 a 255.255.255.255 Aplicao: Uso experimental.

0 1 2 3 4 5 6 7 8 9

Endereo multicast

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

1 1 1 1

Endereos experimentais

Figura 2.1.2.2 Classes de endereo adicionais. A tabela abaixo mostra os endereos IPv4 reservados e as faixas de endereos utilizveis. Classe A A A A B B C C Faixa de endereos 0.0.0.0 a 0.255.255.255 10.0.0.0 a 10.255.255.255 127.0.0.0 a 127.255.255.255 Demais faixas de endereos 172.16.0.0 a 172.16.255.255 Demais faixas de endereos 192.168.0.0 a 192.168.255.255 Demais faixas de endereos Utilizao No utilizvel. Endereo de rede reservado para uso em redes privadas. No utilizvel. Loopback para teste de interfaces. Utilizveis comercialmente. Endereo de rede reservado para uso em redes privadas. Utilizveis comercialmente. Endereo de rede reservado para uso em redes privadas. Utilizveis comercialmente.

Tabela 2.1.2.1 Endereos IPv4 reservados. Os endereos de rede reservados para redes privadas est especificado no RFC 1918 Address Allocation for Private Internets (Alocao de Endereos para Redes Privadas) e foram criados para resolver o problema de endereamento do IPv4. Assim, uma empresa com um nmero muito grande de hosts, no precisa receber um endereo classe A da IANA (Internet Assigned Numbers Authorithy Autoridade da Internet dos Nmeros Designados). Ela pode receber qualquer endereo e internamente, utilizar o endereo privado classe A, usando NAT (Network Address Translation Traduo de Endereo de Rede). Com a publicao do RFC 1518 - Classless Inter-Domain Routing (CIDR) Address Allocation Architecture (Alocao de Endereo para Roteamento Inter-Domnio sem Classe) e do RFC 1519 Classless Inter-Domain Routing (CIDR Roteamento Inter-Domnio sem Classe) em setembro de 1993, o endereamento IPv4 ganhou maior flexibilidade, devido ao uso de mscaras para se criar sub-redes, fazendo com que o endereo de rede no fosse mais expresso somente atravs dos 8, 16 ou 24 primeiros bits do endereo IPv4. Desde ento, o endereo de rede pode ter tamanho variado, de acordo com a necessidade de cada organizao. Sub-redes no sero discutidas aqui. No site IP Network Index (http://ipindex.dragonstar.net), pode-se consultar a quem pertence uma determinada faixa de endereos de uma determinada classe. Todas as redes da Amrica do Sul e da Amrica Central pertencem faixa de endereo 200.0.0.0 a 200.255.255.0. No Brasil, h trs excees, que so as redes da FAPESP (143.108.0.0), USP (143.107.0.0) e UNICAMP (143.106.0.0), todas classe B, que receberam esses endereos antes da diviso dos IPs por regies geogrficas e outros critrios. Quem quiser obter um endereo IP deve encaminhar o pedido a um Internet Service Provider (Provedor de Servio de Internet). 6

2.2. ICMPv4
O Internet Control Message Protocol (ICMP) um protocolo obrigatrio da camada de rede da arquitetura TCP/IP e serve para a transmisso de mensagens de erro, controle e obteno de outras informaes relacionadas rede. Apesar do ICMP ser um protocolo da camada de rede, ele utiliza os servios do prprio IP para ser transmitido, sendo que no campo Protocol do IPv4, o valor 1, que o nmero do ICMP. Se uma mensagem ICMP no pode ser enviada, no ser gerada outra em seu lugar, evitando uma enchente de mensagens ICMP. Sua especificao encontra-se no RFC 792 Internet Control Message Protocol DARPA Internet Program Protocol Specification.
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

Type Identifier*

Code

Checksum Sequence Number*

Figura 2.2.1 Especificao do ICMP (RFC 792). O formato do cabealho ICMPv6 varivel. Os campos marcados com * nem sempre esto presentes e pode haver campos adicionais, para informar um timestamp ou o endereo de um gateway, por exemplo. No sero apresentados aqui todos os formatos do ICMPv4. Type (Tipo): 8 bits. Identifica o tipo de mensagem enviada ou de resposta recebida (ver tabela mais adiante). Code (Cdigo): 8 bits. Identifica a causa do tipo de mensagem recebida (ver tabela mais adiante). Type 0 Code Significado Echo Reply (Resposta a Eco) Mensagem recebida de um gateway ou de um host. Um Echo Request foi recebido e a mensagem de resposta deve conter os mesmos dados do Echo Request. Destination Unreachable (Destino Inalcanvel) Mensagem recebida de um gateway. O endereo destino no pode ser alcanado por um dos motivos especificados pelo campo Code. 0 Net Unreachable (Rede Inalcanvel) Mensagem recebida de um roteador. Causa: O pacote foi descartado, porque o roteador no conseguiu enviar o pacote para a rede destino. Ou o roteador no possui uma rota para a rede destino, ou ento o endereo de rede destino no existe. 1 Host Unreachable (Host Inalcanvel) Mensagem recebida de um roteador. Causa: A rede destino foi alcanada, mas no foi possvel entregar o pacote para o host destino, provavelmente por causa de uma sub-mscara configurada erroneamente ou por que o host destino no est acessvel. 2 Protocol Unreachable (Protocolo Inalcanvel) Mensagem recebida de um host. Causa: O host destino provavelmente no suporta o protocolo de camada superior especificado. 3 Port Unreachable (Porta Inalcanvel) Mensagem recebida de um host. Causa: O socket ou a porta TCP no esto disponveis. 4 Fragmentation Needed and DF Set (Fragmentao Necessria e DF Setado) Mensagem recebida de um gateway. Causa: O pacote possua um tamanho maior que 7

3 3

11 11

o MTU (Maximum Transmission Unit Unidade Mxima de Transmisso) de alguma rede por onde ele tentou passar, necessitando ento ser fragmentado, porm o bit Don Fragment do IPv4 estava com valor igual a 1, indicando que o pacote no pode t ser fragmentado. Como resultado o pacote foi descartado. Source Route Failed (Rota da Origem Falhou) Mensagem recebida de um roteador. A rota especificada pela origem no campo Options do cabealho IP no pde ser completada. Source Quench (Estrangulamento da Origem) Mensagem recebida de um gateway ou de um host. Quando um roteador ou um host est com seus buffers cheios e comea (ou est prestes) a descartar pacotes, essa mensagem enviada para a origem, pedindo a ela que pare de mandar mais pacotes. um mtodo de conteno de congestionamento. O roteador ou host continua mandando essa mensagem enquanto estiver com dificuldades em processar pacotes. A origem s volta a transmitir pacotes quando parar de receber essa mensagem. Redirect (Redirecionar) Mensagem recebida de um gateway. Nesse tipo de mensagem ICMP h um campo extra, chamado Gateway Internet Address (Endereo Internet do Gateway), que especifica por qual gateway devem passar os datagramas para a rede destino do cabealho IP. Esse tipo de mensagem recebida na situao a seguir. Um host, H1, est diretamente conectado rede de um gateway, G1. G1 recebe de H1 um datagrama, cujo destino um outro host, Hx, na rede X. Ento, G1 consulta em sua tabela de roteamento e descobre que o prximo gateway na rota para a rede X o gateway G2. Se G2 estiver na mesma rede que o host que originou o datagrama, G1 manda uma mensagem Redirect para o host, avisando-o que os prximos datagramas para a rede X devem ser encaminhados diretamente para G2. Se o host especificar uma rota para um determinado destino, mesmo que G1 conhea uma rota mais curta, a rota especificada ser seguida e no ser enviado um Redirect. Redirect Datagrams for the Network (Redirecionar Datagramas para a Rede) O host deve encaminhar os datagramas cujo destino a rede X para um determinado gateway. Redirect Datagrams for the Host (Redirecionar Datagramas para o Host) O host deve encaminhar os datagramas cujo destino o host Hx para um determinado gateway. Redirect Datagrams for the Type of Service and Network (Redirecionar Datagramas para o Tipo de Servio e Rede) O host deve encaminhar os datagramas cujo destino a rede X e que requerem o Tipo de Servio T para um determinado gateway. Redirect Datagrams for the Type of Service and Host (Redirecionar Datagramas para o Tipo de Servio e Host) O host deve encaminhar os datagramas cujo destino o host Hx e que requerem o Tipo de Servio T para um determinado gateway. Echo Request (Pedido de Eco) Mensagem recebida de um gateway ou de um host. O Echo Request um datagrama enviado pelo comando ping (ser explicado mais adiante) para testar se um destino alcanvel. Os dados enviados devem ser retransmitidos pelo destino para a origem. Time Exceeded (Tempo Excedido) O tempo de vida de um pacote ou o tempo de remontagem de pacotes fragmentados foi excedido. Time to Live Exceeded in Transit (Tempo de Vida Excedido em Trnsito) Mensagem recebida de um gateway. Se o campo TTL de um datagrama chega a 0, ele deve ser descartado e o host que o originou deve ser notificado atravs de uma 8

11

12

13

14

15

16

mensagem Time Exceeded tipo TTL Exceeded in Transit.. Fragment Reassemble Time Exceeded (Tempo de Remontagem do Pacote Excedido) Mensagem recebida de um host. Se um host no receber todos os fragmentos necessrios para a remontagem de um pacote dentro de um determinado tempo, os fragmentos so descartados e uma mensagem Fragment Reassemble Time Exceeded enviada para o host de origem. Se o fragmento 0 no est presente, no enviada a mensagem. Parameter Problem (Problema de Parmetro) Mensagem pode ser recebida de um host ou de um gateway. Se um gateway no conseguir decodificar corretamente os campos de um datagrama e por causa disso ele precisar ser descartado, a origem notificada atravs de uma mensagem Parameter Problem, indicando o campo com problema. Esse tipo de problema mais freqente nos argumentos do campo Option do cabealho IP. Essa mensagem s enviada caso o pacote precise ser descartado. Timestamp (Marca de Tempo) Possui um campo adicional de 32 bits informando o ltimo momento (em ms contados a partir de meia noite de Greenwich) no qual o originador da mensagem mexeu nela. Se no houver sincronismo com o horrio de Greenwich, ou se no for possvel a preciso com ordem de ms, o bit mais significativo desses 32 bits deve ser setado, indicando o uso de uma base de tempo diferente. Timestamp Reply (Resposta da Marca de Tempo) Possui trs campos adicionais de 32 bits informando o momento enviado pelo originador da mensagem, o instante no qual a mensagem foi recebida e o instante no qual ela foi enviada. Information Request (Pedido de Informao) Mensagem enviada por um host, com os campos origem e destino do cabealho IP iguais a 0 (significa esta rede). Esse um modo de um host descobrir a qual rede ele pertence. Information Reply (Resposta ao Pedido de Informao) Mensagem enviada por um host ou um gateway, quando eles recebem um Information Request. A mensagem Information Reply deve conter os endereos preenchidos corretamente. Os campos Identifier e Sequence Number so utilizados para associar corretamente uma Information Reply a uma Information Request.

Tabela 2.2.1 Tipo e cdigo de mensagens ICMP. Checksum (Verificao da Soma): 16 bits. Esse checksum calculado somente sobre o cabealho ICMP. Para se calcul-lo, faz-se o complemento de um de cada palavra de 16 bits do cabealho, soma-se elas e faz-se o complemento de um da soma total (para efeitos de clculo, o campo Checksum vale 0). Identifier (Identificador): 16 bits. Serve para associar um Reply a um Request. Pode ser 0. Sequence Number (Nmero de Seqncia): 16 bits. Tambm serve para associar um Reply a um Request. Pode ser 0. Address Mask (Mscara de Endereo): 32 bits.

2.2.1. O comando ping O comando ping presente em grande parte dos sistemas operacionais e equipamentos de redes nada mais do que uma mensagem ICMP tipo Echo Request. O campo de dados do Echo Request pode trazer protocolos de camadas superiores e outras informaes. O formato geral do comando ping :
ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] | [-k host-list]] [-w timeout] destination-list

Os campos entre [ e ] so opcionais e suas funes so apresentadas na tabela abaixo. Funo Pinga o endereo destino at que o processo seja interrompido (CTRL+C no Windows). Exemplo: ping t 143.107.111.42 -a Pinga o endereo destino, dado o nome do host. Normalmente, a opo a habilitada por default, isto , no precisa-se digitar o a para se pingar um host a partir do nome. Exemplo: ping a www.redes.usp.br -n count Especifica o nmero de Echo Requests a ser enviado. Exemplo: ping n 5 143.107.111.42 -l size Especifica o tamanho em bytes do Echo Request a ser enviado (o campo de dados preenchido com os bytes). Se o tamanho do ping for maior que o MTU da rede, o ping ser fragmentado. Como o campo Total Length tem 16 bits, o valor mximo desse parmetro 65.535. Exemplo: ping l 2000 143.107.111.42 -f Seta o campo Don Fragment (DF=1) do cabealho IPv4, no deixando que o datagrama t seja fragmentado. O MTU da rede Ethernet 1.518 bytes, mas devido aos cabealhos das camadas inferiores (26 bytes da camada de enlace + 20 bytes do cabealho IP), no possvel enviar um ping com mais de 1.472 bytes. Exemplo: ping f l 1473 143.107.111.42 -i TTL Define o valor do campo TTL do cabealho IPv4. O valor mximo 255. O valor default do ping do Windows 32. Exemplo: ping i 2 www.usp.br -v TOS Define o valor (em decimal) do campo TOS, composto pelos sub-campos Precedence, Delay, Throughput, Relibility e bits reservados no cabealho IPv4. Exemplo: ping v 252 143.107.111.42 Campos do TOS (em binrio): Precedence = 111 (Network Control) Delay = 1 (Atraso baixo) Throughput = 1 (Alta vazo) Relibility = 1 (Confiabilidade alta) Bits reservados = 00 -r count Grava a rota para o nmero de hops especificado. O valor mximo 9, isto , no mximo possvel gravar 9 endereos IP. Exemplo: ping r 9 www.yahoo.com -s count Devolve os timestamps (Internet Timestamp) dos hops por onde passou. O valor mximo 4, isto , no mximo possvel guardar 4 timestamps. Exemplo: ping s 4 143.107.111.42 -j host-list Sugere uma rota para o destino, mas a rota no precisa ser seguida exatamente. Exemplo: ping j <IP do primeiro hop> [...] [IP do n-simo hop] <IP destino> 10 -t Opo

-k host-list Especifica uma rota para o destino, que deve ser seguida exatamente. Exemplo: ping k <IP do primeiro hop> [...] [IP do n-simo hop] <IP destino> -w timeout Especifica o tempo em milisegundos que o Echo Reply tem para ser recebido antes de dar timeout. Exemplo: ping w 500 143.107.111.1 Tabela 2.2.1.1 Opes do comando ping. 2.2.2. O comando tracert O comando tracert do Windows (em alguns sistemas, o comando traceroute) mostra a rota por onde o datagrama passou at chegar ao destino. O formato geral do comando tracert :
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Os campos entre [ e ] so opcionais e suas funes so apresentadas na tabela abaixo. Opo -d Funo Mostra a rota por onde o datagrama passou, mas no descobre o nome dos hosts e gateways por onde ele passou. Exemplo: tracert d www.yahoo.com Especifica um nmero mximo de hops para tentar alcanar o destino. Exemplo: ping h 10 www.yahoo.com Sugere uma rota para o destino, mas a rota no precisa ser seguida exatamente. Exemplo: tracert j <IP do primeiro hop> [...] [IP do n-simo hop] <IP destino> Especifica o tempo em milisegundos que cada hop tem para enviar a resposta antes de dar timeout. Exemplo: tracert w 500 143.107.111.1

-h maximum_hops -j host-list -w timeout

Tabela 2.2.2.1 Opes do comando tracert.

2.2.3. O comando netstat O comando netstat do Windows mostra dados e estatsticas da camada de rede. O formato geral do comando :
netstat [[-a] | [-r] | [-s]]

Opo Funo -a Mostra as conexes TCP/UDP ativas e os estados delas. -r Mostra a tabela de roteamento -s Mostra as estatsticas dos protocolos IP, ICMP, TCP e UDP. Tabela 2.2.3.1 Opes do comando netstat.

11

2.2.4. O comando ipconfig O comando ipconfig do Windows NT mostra as configuraes das interfaces de rede do computador. O formato geral do comando :
ipconfig [/? | /all | /release [adapter] | /renew [adapter]]

Opo /? /all /release [adapter] /renew [adapter]

Funo Mostra a ajuda para o comando ipconfig. Mostra todas as informaes disponveis sobre as interfaces de rede e de faxmodem do computador. Quando o endereo IP de uma interface foi obtido atravs de DHCP, essa opo desassocia o endereo IP interface. Associa um endereo IP a uma interface, utilizando o DHCP.

Tabela 2.2.4.1 Opes do comando ipconfig.

2.3. Introduo ao IPv6

O IP verso 6 (IPv6) a nova verso do Internet Protocol, projetado para ser o sucessor do IPv4. O IPv6 foi desenvolvido para atender as necessidades atuais e as de um futuro prximo. Foram considerados os desejos das empresas por redes com arquiteturas mais escalveis, maior segurana e integridade dos dados, extenses ao QoS, autoconfigurao, maior agregao no nvel do backbone global e outras necessidades. Alguns mais interessados podem se perguntar Por que no existe IPv5 ?. O IPv5 foi uma pequena modificao experimental no IPv4 para trafegar voz e vdeo sobre multicast. Sua especificao pode ser encontrada sob o RFC 1819 Internet Streaming Protocol Version 2 (ST2). Apesar de haver vrios backbones com IPv6 em carter experimental, como o 6Bone, que o backbone IPv6 do projeto IPng (Internet Protocol Next Generation Prxima Gerao do Internet Protocol) da IETF (Internet Engineering Task Force Fora Tarefa de Engenharia da Internet), a previso para o incio de operao comercial do IPv6 2010. Por uns 5 anos, os equipamentos devero oferecer compatibilidade entre IPv6 e IPv4, seja por encapsulamento, tunelamento, algum protocolo de roteamento capaz de lidar com ambas as verses ou alguma outra tcnica. Porm, a migrao no ser algo simples. H um grupo de trabalho do IETF, o IPng Transition (ou simplesmente ngtrans), exclusivamente ocupado para levantar os problemas e solues para essa migrao. As principais mudanas com relao ao IPv4 so: Capacidade de endereamento expandida: No IPv6, cada endereo determinado por 128 bits. Foi previsto que os 32 bits de endereamento do IPv4 no seriam suficientes para atender a demanda at o final da primeira dcada do ano 2000. O nmero de hosts possveis no IPv6 2128 = 3,4028 x 1038, um nmero extremamente grande. Para se ter uma noo da grandeza desse valor, assumindo-se a rea do planeta Terra como sendo 510.065.500 x 1012 mm2, poderamos ter 6,6713 x 1017 IP/mm2. Porm, o endereamento do IPv6 no completamente plano, isto , no possvel utilizar todas as combinaes possveis. Se supusermos que sejam efetivamente utilizados 64 bits desses 128 bits, ainda assim teramos mais de 36.000 IP/m2, um nmero suficientemente grande para suprir a demanda por vrias dcadas. Embora tecnologias como a NAT tenham prolongado a sobrevivncia do IPv4 (no caso da NAT, com relao ao nmero de endereos possveis), elas no 12

so suficientes para resolver todos os problemas do IP com relao s necessidades futuras, porque a mesma NAT, por exemplo, inviabiliza ou dificulta alguns tipos de aplicaes, como segurana fim-a-fim e VPN (Virtual Private Networks Redes Privadas Virtuais). Simplificao do formato do cabealho: Alguns campos do cabealho do IPv4 foram descartados ou tornados opcionais, para simplificar o processamento dos pacotes mais comuns e diminuir o overhead do IPv6, que possui um cabealho maior. Maior suporte para campos opcionais e extenses: Os campos opcionais possuem agora menos restries quanto ao seu tamanho, h maior flexibilidade para a introduo de novas extenses no futuro, o encaminhamento de pacotes fica mais simplificado e pode ser diferenciado a cada hop. Capacidade para identificao de fluxo: O originador dos pacotes tem como identificar um fluxo de pacotes para um determinado destino (unicast ou multicast) e pedir tratamento especial desse fluxo por parte do roteador, como QoS diferenciado e servio de tempo real. No IPv4, esse tipo de funcionalidade implementado pelos roteadores e switches de camadas 3 ou 4, sobrecarregando seu processamento. O custo desse processamento foi passado para o originador do pacote e os equipamentos podem utilizar o processamento economizado para outras funes.

2.3.1. A especificao do IPv6 A figura abaixo foi tirada da especificao do IPv6, documentada sob o RFC 2460.
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

Version

Traffic Class Payload Length

Flow Label Next Header

Hop Limit

Source Address (128 bits = 4 x 32 bits)

Destination Address (128 bits = 4 x 32 bits) (Extension Header) Data Figura 2.3.1.1 Especificao do IPv6 (RFC 2460). Version (Verso): 4 bits. Para essa verso, o valor 6. Traffic Class (Classe de Trfego): 8 bits. Esse campo ainda experimental e pode vir a ser modificado. Na primeira especificao do IPv6, RFC 1883, esse campo no existia. Em seu lugar havia um campo de 4 bits chamado Priority (Prioridade). A funo desse campo permitir diferenciao de trfego (classes de trfego) e mecanismos de prioridade, para que os roteadores possam prover tratamento apropriado em cada caso. Algumas idias do TOS e dos bits Precedence do IPv4 foram aproveitadas. Ainda h muita discusso sobre a diviso mais til e eficiente dos vrios tipos de trfego em classes. Cabe camada superior informar a camada IPv6 qual a classe de trfego a ser utilizada. Um roteador pode alterar os bits do campo Traffic Class da forma que desejar. Por esse motivo, uma estao no deve assumir que um determinado tipo de trfego que ela associou a uma certa classe, ser recebido com o campo Traffic Class com o mesmo valor com o qual ela transmitiria. 13

 Flow Label (Identificao do Fluxo): 20 bits. Um flow uma seqncia de pacotes enviados a partir de uma determinada origem, para um determinado destino (unicast ou multicast), requerendo um tratamento especial pelos roteadores, como QoS ou reserva de banda (RSVP Resource Reservation Protocol), por exemplo. O campo Flow Label ainda experimental e pode vir a ser modificado, como j ocorreu desde a primeira especificao do IPv6, onde ele possua 24 bits. As mudanas dependem da identificao das caractersticas que forem surgindo do trfego na Internet. A inteno do Flow Label permitir que a origem possa atribuir uma identificao (padronizada) aos pacotes, para que eles recebam tratamento especial por um roteador (fazer QoS, trfego de tempo real, etc.). Roteadores e hosts que no so capazes de identificar o Flow Label de um pacote devem deixar o campo com valor igual a 0, quando origin-lo, deix-lo inalterado, quando retransmiti-lo, ou ignor-lo, quando receb-lo. Payload Length (Comprimento da Carga): 16 bits. Informa o comprimento dos dados, em octetos, encapsulados pela camada de rede, isto quantos bytes vm depois do cabealho IPv6 (os campos de extenso so contabilizados). Caso esse campo seja 0, indica que o comprimento do payload superior a 65.535 octetos e informado em um Extension Header. Next Header (Prximo Cabealho): 8 bits. Informa qual o protocolo da camada superior que est utilizando os servios da camada IP. A numerao tambm segue o RFC 1700. O UDP, por exemplo, nmero 17. No IPv6, pode haver um campo opcional aps o cabealho. Nesse caso, o valor de Next Header informa qual o tipo de extenso que vem aps o cabealho IPv6. Hop Limit (Limite de Hop): 8 bits. Semelhante ao TTL do IPv4, cada unidade processadora de pacotes (n) decrementa esse valor de 1 unidade e quando esse valor chegar a 0, o pacote descartado. Source Address (Endereo de Origem): 128 bits. Informa o endereo de origem do pacote. Destination Address (Endereo de Destino): 128 bits. Informa o endereo de destino. O endereo de destino pode no ser o endereo do host final, porque pode ser um cabealho de roteamento. Extension Header (Cabealho de Extenso): Tamanho varivel, mas sempre mltiplo de 8 octetos (64 bits). Pode haver mais de um campo de extenso. A presena de um campo de extenso pode ser determinada pelo valor do campo Next Header. Cada Extension Header tem um campo Next Header informando o prximo protocolo, como pode ser observado na figura abaixo. Normalmente, somente o n de destino ir processar os Extension Headers. Os Extension Headers precisam ser processados exatamente na ordem em que eles aparecem. Uma implementao completa do IPv6 tem ser capaz de reconhecer e processar os seguintes tipos de Extension Headers: Hop-by-Hop Options (Opes Hop-a-Hop), Routing Type 0 (Roteamento Tipo 0), Fragment (Fragmento), Destination Options (Opes de Destino), Authentication (Autenticao) e Encapsulating Security Payload (Encapsulando Carga de Segurana). Os quatro primeiros tipos de Extension Header podem ser encontrados no RFC 2460 (o da especificao do IPv6), e os dois ltimos, nos RFCs 2402 e 2406, respectivamente. O Routing Header pode especificar quais so os prximos destinos depois do destino especificado pelo campo Destination Address. Quando houver mais de um Extension Header presente, recomenda-se que eles estejam na seguinte ordem: cabealho IPv6, Hop-by-Hop Options, Destination Options (para o primeiro destino, especificado pelo Destination Address, e pelos prximos destinos, especificados no Routing Header), Routing, Fragment, Authentication, Encapsulating Security Payload, outro Destination Options (para ser processado somente pelo ltimo destino) e depois os cabealho do protocolo da camada superior.

14

IPv6 Header Next Header = TCP IPv6 Header Next Header = Routing IPv6 Header Next Header = Routing Routing Header Next Header = TCP Routing Header Next Header = Fragment

TCP Header + Data TCP Header + Data Fragment Header Next Header = TCP Fragment of TCP Header + Data

Figura 2.3.1.2 Exemplo de Extension Headers do IPv6. Quando ocorrer a migrao para o IPv6, os protocolos da camada superior que incluem o tamanho do campo IP em seus mecanismos de deteco de erro devero ser alterados. No IPv6, h tambm um pseudo-cabealho, aps os Extension Header, mostrado na figura 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

Upper-Layer Packet Length 0

Next Header

Figura 2.3.1.3 Pseudo-cabealho que antecede o cabealho da camada superior no IPv6. Upper-Layer Packet Length (Comprimento do Pacote da Camada Superior): 32 bits. Corresponde ao comprimento em bytes da camada superior, incluindo o cabealho e os dados (PDU e SDU). Para protocolos de camada superior que carregam seu comprimento no prprio cabealho, como o UDP, o valor desse campo o mesmo do presente na camada superior. Next Header (Prximo Cabealho): O Next Header do pseudo-cabealho ser diferente do Next Header do cabealho IPv6, somente no caso em que houver Extension Headers aps o IPv6. Nesse caso, o Next Header do IPv6 informa o valor do Extension Header. O MTU mnimo do IPv6 de 1.280 bytes (no IPv4 era 576 bytes), mas o recomendado que ele seja maior que 1.500 bytes, para que possa ser feita alguma forma de encapsulamento sem que a camada de rede precise fragmentar os dados. Ao contrrio do IPv4, quando o protocolo da camada superior for o UDP, o checksum no opcional. Ele calculado e levado em considerao o tamanho do pseudo-cabealho. Se o valor do checksum der 0x0000, ele deve ser passado para 0xFFFF. Assim, quando um n IPv6 receber um pacote transportando UDP, se o checksum do UDP for 0x0000, o pacote ser descartado. No ser discutido aqui o ICMP do IPv6 (ICMPv6), mas obviamente ele possui algumas modificaes. Uma delas que seu cabealho equivale aos 32 primeiros bits somente do IPv4. Sua especificao encontra-se no RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.

2.3.2. O endereamento no IPv6 Ainda no h uma especificao oficial para a alocao e formao de endereos do IPv6, mas no RFC 2471 IPv6 Testing Address Alocation (Teste de Alocao de Endereo do IPv6), h uma proposta, mostrada na figura abaixo. Embora seja experimental e esteja servindo para testes de implementaes do IPv6, ela segue as recomendaes definidas para a arquitetura IPv6 e o seu formato consistente com o Aggregatable Global Unicast Address Allocation (Alocao Global Agregvel de Endereo 15

Unicast) e com o Top-Level Aggregation and Next-Level Aggregation Assignment Rules (Regras de Designao de Agregao Top-Level e Agregao Next-Level). O endereo IPv6 pode ser definido manualmente, por IPv6 Auto Address Allocation (Alocao Automtica de Endereo IPv6) ou por DHCPv6 (Dynamic Host Configuration Protocol Protocolo Dinmico de Configurao de Host).
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

FP

TLA ID NLA ID (continuao) Interface ID (64 bits = 2 x 32)

NLA ID SLA ID

Figura 2.3.2.1 Proposta do formato do endereamento IPv6. FP (Format Prefix Formato do Prefixo): 3 bits. Valor atual binrio 001. Esse valor utilizado para identificar endereos unicast globais agregveis. TLA ID (Top-Level Aggregation Identifier Identificador da Agregao Top-Level): 13 bits. O valor desse campo 0x1FFE e foi designado pela IANA para uso temporrio pelo 6bone da IETF. No futuro, todos os usurios desse TLA ID tero que mud-lo. NLA ID (Next-Level Aggregation Identifier Identificador da Agregao Next-Level): 32 bits. Esse nmero ser designado pelo administrador do NLA ID, em uma hierarquia de endereos suficiente para identificar redes de transitao e sites de usurios finais, de forma consistente com a topologia e arquitetura do 6bone. Isso dever ser feito para a criao de um servio de transitao multi-level consistente com os testes de situaes de uso real do IPv6 no 6bone. SLA ID (Site-Level Aggregation Identifier Identificador da Agregao Site-Level): 16 bits. Esse nmero deve ser utilizado por cada organizao para criar sua prpria hierarquia de endereos e identificar suas sub-redes. Interface ID (Interface Identifier Identificador da Interface): 64 bits. Esse nmero identifica a interface do n para a camada de enlace. No h ainda uma definio muito boa de como se deve converter os endereos IPv4 para os endereos IPv6 e vice-versa. Uma proposta, especificada no RFC 3056 Connection of IPv6 Domains via IPv4 Clouds (Conexo de Domnios IPv6 Atravs de Nuvens IPv4) que os endereos IPv4 sejam utilizados no campo do NLA ID.

16

3. Bibliografia
[RFC1] Crocker, S., Host Software, RFC 1, 7 April 1969. [RFC791] Postel, J., Information Sciences Institute University of Southern California, Defense Advanced Research Projects Agency Information Processing Techniques Office, Internet Protocol DARPA Internet Protocol Specification, RFC 791, September 1981. [RFC792] Postel, J., Internet Control Message Protocol DARPA Internet Protocol Specification, RFC 792, September 1981. [RFC1122] Braden, R., Requirements for Internet Hosts -- Communication Layers, RFC 1122, October 1989. [RFC1462] Krol, E., Hoffman, E., What is the Internet ?, RFC 1462, May 1993. [RFC1518] Rekhter, Y., and T. Li, An Architecture for IP Address Allocation with CIDR, RFC 1518, September 1993. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC 1519, September 1993. [RFC1700] Reynolds, J., Postel, J., Assigned Numbers, RFC 1700, October 1994. [RFC1819] Delgrossi, L., Berger, L., Internet Stream Protocol Version 2 (ST2) Protocol Specification Version ST2+, RFC 1819, August 1995. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., Groot, G. J. de, Lear, E., Address Allocation for Private Internets, RFC 1918, February 1996. [RFC1958] Carpenter, B., Architectural Principles of the Internet, RFC 1958, June 1996. [RFC2185] Callon, R., Haskin, D., Routing Aspects of IPv6 Transition, RFC 2185, September 1997. [RFC2460] Deering, S., Hinden, R., Internet Protocol Version 6 (IPv6) Specification, RFC 2460, December 1998. [RFC2463] Conta, A., Deering, S., Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, December 1998 [RFC2471] Hinden, R., Fink, R., Postel, J., IPv6 Testing Address Allocation, RFC 2471, December 1998. [RFC2700] Reynolds, J., Braden, R., Internet Official Protocol Standards, RFC 2700, August 2000 [RFC3056] Carpenter, B., Moore, K., Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001. 17

[Internet Draft] King. S., Fax, R., Haskin, D., Ling, W., Meehan, T., Fink, R., Perkins, C., The Case for IPv6, draft-ietf-iab-case-for-ipv6-06.txt, 25 December 1999, http://www.6bone.net/misc/case-for-ipv6.html. [Site] IETF (Internet Engineering Task Force), Request for Comments, http://www.ietf.org/rfc.html. [Site] BBNT (Bolt, Beranek, Newman Technologies), The History of BBN, http://www.gte.com/AboutGTE/gto/history/bbntimeline/index.html. [Site] Protocols.com, Protocols TCP/IP Suite, http://www.protocols.com/pbook/tcpip.htm. [Site] Cisco, Documentation, Internetworking Technology Overview Internet Protocols (IP), http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm. [Site] Leonard Kleinrock's Personal History/Biography, The Birth of the Internet, http://www.lk.cs.ucla.edu/LK/Inet/birth.html. [Site] DARPA (Defense Advanced Research Projects Agency), Mission and Overview, DARPA Over the Years, http://www.darpa.mil. [Site] Anderberg, A., History of the Internet and Web, 24.03.2001, http://www.anderbergfamily.net/ant/history/. [Site] Crossley, J., IP Network Index, http://ipindex.dragonstar.net. [Site] IETF (Internet Engineering Task Force), Next Generation Transition (ngtrans), http://www.ietf.org/html.charters/ngtrans-charter.html. [Site] IPv6 Forum, IPv6 Forum, http://www.ipv6forum.com. [Site] 6bone.net, Testbed for Deployment of IPv6, http://www.6bone.net. [Site] 6bone.net, ngtrans Home Page, http://www.6bone.net/ngtrans/. [Site] 6bone.net, ngtrans Project Status, http://www.6bone.net/ngtrans/ngtrans_project-status.html. [Site] playground.sun.com, IP Version 6 (IPv6), http://playground.sun.com/ipv6/ e http://playground.sun.com/ipng/.

18

[Site] Guardini, I., Fasano, P., Girardi, G., CSELT (Centro Studi E Laboratori Telecomunicazioni), IPv6 Operational Experience within the 6bone, http://carmen.cselt.it/papers/inet2000/index.htm. [Site] IANA (Internet Assigned Numbers Authorithy), IANA Home Page, http://www.iana.org. [Site] NTUA (National Technical University of Athens), The 6bone TLAs and their Tunnels http://www.dbnet.ece.ntua.gr/6bone/. [Site] Hagino, J., IPv6: Internet Protocol Version 6, Frequently Asked Questions, http://www.itojun.org/v6/v6faq.html. [Site] Microsoft, Internet Protocol (IP) Basics, http://www.microsoft.com/TechNet/network/intern.asp

19