"Internet Protocol" Versão 6 (IPv6)Professor Adjunto do Departamento de Engenharia Informática do ISEP O "Internet Protocol" Versão 6 (IPv6) é uma nova versão do "Internet Protocol" Versão 4 (IPv4) em uso actualmente. Nesta nova versão (RFC 1883), também conhecida por IPng ("IP Next Generation"), melhorou-se alguns aspectos de acordo com a grande esperimentação acomulada sobre o IPv4. Com o crescente número de utilizadores da "Internet" os endereços de 32 bits do IPv4 estão rapidamente a esgotar-se, no IPv6 procede-se a uma expansão de 32 bits para 128 bits, a definição do formato de endereços IPv6 encontra-se na RFC 1884. Alguns campos dos cabeçalhos são eliminados ou transformados em opções, o número de opções disponíveis é aumentado, incluido a possibilidade de transmissão em tempo real e segurança. Cabeçalho IPv6Um cabeçalho IPv6 é constituido pelos seguintes campos: Versão (4 bits) Prioridade (4 bits) Flow Label (24 bits) Payload Length (16 bits) Next Header (8 bits) Hop Limit (8 bits) Source Address (128 bits) Destination Address (128 bits) O campo Versão deve conter o valor 6. O campo Prioridade pode conter um dos seguintes valores:
O campo Flow Label é usado para associar um "datagrama" a um fluxo com caracteristicas especiais tais como qualidade de serviço especial ou tempo-real. Todos os "datagramas" pertencentas a um fluxo possuem os mesmos endereços de origem e destino, a mesma prioridade e o mesmo identificador de fluxo. O campo Payload Length contém o número de octetos de dados transportados depois do cabeçalho. O campo Next Header identifica o tipo de cabeçalho que se segue (depois do cabeçalho IPv6), são usados os identificadores de protocolo do IPv4, adicionalmente são definidos cabeçalhos de extensão do IPv6 que permitem transportar opções. O campo Hop Limit é idêntico ao tempo de vida do IPv4, o nó de origem inicializa-o e cada "router" por onde o "datagrama" passa decrementa-lhe uma unidade, se atingir zero antes de chegar ao destino é destruído. Endereços IPv6Os endereços de nó IPv6 são constituídos por 128 bits (RFC 1884), a notação aconselhada é a representação hexadecimal de blocos de 16 bits, separados por dois pontos, por exemplo: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 É sugerida a compressão de zeros: FEDC:0:0:0:FEDC:0:0:3210 = FEDC::::FEDC:::3210 FEDC:0:0:0:0:0:FEDC:3210 = FEDC::FEDC:3210 0:0:0:0:0:0:0:FEDC = ::FEDC 0:0:0:0:0:0:0:0 = :: Como os 32 bits menos significativos são em certas condições usados para transportar endereços IPv4 sugere-se também a possibilidade de representar esses bits na forma IPv4, exemplos: 0:0:0:0:0:0:193.136.68.3 0:0:0:0:0:FFFF:192.144.52.38 A RFC 1924 sugere outra forma de representação usando base 85, permitindo representar qualquer endereço IPv6 com exactamente 20 caracteres. Foram escolhidos os seguintes 85 caracteres, em ordem crescente:
'0'..'9', 'A'..'Z', 'a'..'z', '!', '#', '$', '%', '&', '(',
')', '*', '+', '-', ';', '<', '=', '>', '?', '@', '^', '_',
'`', '{', '|', '}', '~'.
Por exemplo o endereço 1080:0:0:0:8:800:200C:417A será representado da seguinte forma: 4)+k&C#VzJ4br>0wv%Yp Existem três tipos básicos de endereços IPv6:
Não existem endereço de "broadcast", trata-se de um caso particular de Multicast. Ao contrário do que acontecia com o IPv4, no IPv6 as interfaces de ligações dedicadas entre "routers" deixam de necessitar de endereços. Tal como acontecia com o IPv4 os bits mais significativos indicam o tipo de endereço de que se trata: Reserved 0000 0000 Reserved for NSAP Allocation 0000 001 Reserved for IPX Allocation 0000 010 Provider-Based Unicast Address 010 Reserved for Geographic-Based Unicast Addresses 100 Link Local Use Addresses 1111 1110 10 Site Local Use Addresses 1111 1110 11 Multicast Addresses 1111 1111 Endereços "unicast"Tal como acontece para o IPv4 existem alguns endereços com utilizações reservadas:
Os endereços "unicast" são identificados por um inicio diferente de 1111 1111. Os endereços "anycast" possuem formato idêntico aos de "unicast". A estrutura interna de um endereço "unicast" pode ser definida conforme as necessidades, no limite pode considerar-se que não existe qualquer estrutura. Numa rede local IEEE 802 propõe-se a utilização dos 48 bits menos significativos para armazenar o endereço MAC da interface, este procedimento torna desnecessário o ARP. Os bits seguintes poderão ser usados pela organização para definir sub-redes internas, a parte mais significativa contém um identificador da organização ("subscriber prefix"). Nada impede a implementação de divisões adicionais, por exemplo uma organização pode decidir usar 48 bits para o endereço MAC e dividir a parte restante de que dispõe (até ao "subscriber prefix") em identificador de área e identificador de sub-rede (dentro da área). Adivinha-se um período de transição do IPv4 para IPv6 mais ou menos longo, torna-se por isso definir mecanismos de inter-operacionalidade, nomeadamente quanto a endereços:
Os endereços "unicast" da gama "Provider-Based Unicast Address" (010...) são estruturados de modo a facilitar uma atribuição hierarquica tal como acontece actualmente com os endereços IPv4. Está prevista a seguinte estrutura:
Os endereços das gamas "Link Local Use Addresses" e "Site Local Use Addresses" são estritamente locais (são ignorados pelos "routers") e têm utilizações especiais tais como em redes não ligadas à internet ou para a atribuicão dinâmica de endereços. Endereços "anycast"Os endereços "anycast" são na realidade endereços "unicast", com a particularidade de um mesmo endereço estar atribuído a vários nós. Pretende-se que ao usar um endereço "anycast" para destino de um "datagrama", seja atingido o nó mais próximo (menor métrica) que possui esse endereço. Para efeitos de "routing" está definido um tipo particular de endereço "anycast" ("Subnet-Router anycast address"): todos os "routers" de uma dada subrede possuem o endereço "anycast" correspondente à subrede, com o valor zero para o identificador de interface. Endereços "multicast"Um endereço "multicast" identifica um grupo de nós (grupo de "multicast"), um nó pode pertencer a vários grupos de "multicast". Um "datagrama" enviado para um dado endereço de "multicast" será recebido por todos os membros do grupo. A estrutura de um endereço "multicast" é a seguinte:
Os valores definidos para o campo Scope são os seguintes: 1 = node-local 2 = link-local 5 = site-local 8 = organization-local E = global A definição da zona de actuação não afecta os identificadores de grupo de "multicast", apenas define as máquinas do grupo que devem receber os dados. Relativamente ao emissor de um "datagrama" os valores definem uma hierarquia de destinos com dimensão crescente, os valores limites são: "node-local" que indica o mesmo nó e "global" que indica toda a "internet". Estão definidos alguns "well known multicast addresses", a sua principal utilização é identificar conjuntos de máquinas que implementam determinados tipos de serviço: O identificador zero está reservado FF0?:0:0:0:0:0:0:0 Todos os nós FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 Todos os "routers" FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 Servidores DHCP IPv6 FF02:0:0:0:0:0:0:C Cabeçalhos de extensão do IPv6Os campos do cabeçalho IPv6 são significativamente menos do que os do IPv4, note-se por exemplo a ausência de qualquer tipo de informação relativamente a fragmentação. O que acontece é que muitos campos passaram a ser opcionais sob a forma de cabeçalhos de extenção. Trata-se de cabeçalhos adicionais que circulam "encapsulados" no "datagrama" IPv6. Um "datagrama" IPv6 pode transportar vários cabeçalhos, cada cabeçalho contém um identificador que indica o tipo do cabeçalho seguinte, depois dos cabeçalhos de extensão encontra-se a informação (cabeçalho + dados) relativa ao protocolo de nível superior (ICMP, TCP, UDP, etc). Neste último caso são usados os mesmos identificadores de protocolo do IPv4, para os cabeçalhos de extensão do IPv6 são definidos novos identificadores. Todos os cabeçalhos de extensão são opcionais, caso existam todos a ordem deve ser a seguinte: Cabeçalho IPv6 ....... Cabeçalhos de extensão do IPv6 ...... Hop-by-Hop Options Destination Options Routing Fragment Authentication Encapsulating Security Payload Destination Options ............................................. Protocolo de Nível Superior O cabeçalho de extensão "Destination Options" que aparece no fim destina-se a opções dirigidas apenas ao nó final. O outro cabeçalho "Destination Options" será processado em todos os nós indicados no cabeçalho "Routing" ("Source Routing"). Formato das OpçõesOs cabeçalhos de extensão que contêm opções ("Hop-by-Hop Options" e "Destination Options") utilizam uma estrutura semelhante para armazenar as opções, as estruturas dos cabeçalhos diferem entre sí. A estrutura usada para guardar opções é a seguinte: Option Type (8 bits) Tipo de opção Option Data Length (8 bits) Número de octetos no campo "Option Data" Option Data Opção de comprimento variável Os dois bits mais significativos do campo "Option Type" indicam a acção a tomar quando um nó não reconhece a opção:
O terceiro bit mais significativo indica se durante o percurso o campo "Option Data" pode sofrer alterações. O valor zero indica que não se produzem alterações e o valor um indica que estas se podem produzir. Esta "flag" é importante na presença de um cabeçalho de extenção de autenticação. Quando este bit possui o valor, para efeitos de validação os dados respeitantes a esta opcão serão considerados zero. Opções de enchimento: Pad 1 e PadNAs opções devem ficar alinhadas a 32 bits com o cabeçalho. Nos casos em que basta um octeto para garantir o alinhamento usa-se a opção Pad 1 (tipo=0), correspondendo a um enchimento com o 8 bits zero. A opção Pad1 é o único caso particular que não respeita a estrutura geral das opções. Quanto são necessários mais do que um octeto utiliza-se a opção PadN (tipo=1), com o comprimento necessário para o enchimento (o campo "Data Length" pode conter o valor zero, correspondendo a dois octetos de enchimento). Cabeçalho de extensão "Hop-by-Hop Options"Este cabeçalho de extensão contém opções a serem processadas em todos os nós percorridos pelo "datagrama", a sua presença é identificada pelo valor zero no campo "next header" do cabelçalho IPv6, o formato deste cabeçalho de extensão é o seguinte: Next Header (8 bits) Comprimento (8 bits) Opções (variável) Além das opcões Pad1 e PadN está actualmente definida a opção "Jumbo Payload" (tipo=194). Esta opção permite o envio de quantidades de dados superiores a 65.535 octetos (o campo "Payload Length" do cabeçalho IP só possui 16 bits). Quando esta opção é usada o campo "Payload Length" do cabeçalho IP deve conter o valor zero, caso contrário o nó receptor envia uma mensagem ICMP "Parameter Problem" com código 0. A opção é constituida da seguinte forma: 194 Tipo de opção 4 Comprimento dos dados da opção Jumbo-Length Número de 32 bits contendo o quantidade de dados "Jumbo", este comprimento não inclui o cabeçalho IPv6, mas inclui o cabeçalho de extensão "Hop-by-Hop". O campo "Jumbo-Length" deve conter sempre um valor superior a 65.535, caso contrário o nó receptor envia uma mensagem ICMP "Parameter Problem" com código 0. A opção "Jumbo Payload" pretende tirar partido de implementações de camadas inferiores que suportam um MTU superior a 65,575 (dados + 40 octetos do cabeçalho IPv6), por esta razão estes "datagramas" nunca são fragmentados. A coexistencia da opção "Jumbo Payload" com um cabeçalho de extensão "Fragment" leva o nó receptor a enviar uma mensagem ICMP "Parameter Problem" com código 0, apontando para o referido cabeçalho. Cabeçalho de extensão "Routing"Este cabeçalho é usado pelo nó de origem para indicar uma lista de nós a visitar no percurso do "datagrama" ("source routing"), é identificado pelo valor 43 no campo "next header" do cabaçalho anterior. Estrutura: Next Header (8 bits) Comprimento (8 bits) Tipo (8 bits) Nós restantes (8 bits) Dependente do tipo (variável) O campo "Next Header" tem os significado habitual, o campo "Tipo" permite identificar variantes deste cabeçalho, a constituição do último campo depende do valor deste campo. O campo "Nós restantes" indica, da lista especificada na fonte, quantos nós falta visitar. Cabeçalho de extensão "Routing" Tipo 0Estrutura: Next Header (8 bits) Comprimento (8 bits) Tipo = 0 (8 bits) Nós restantes (8 bits) Reservado (8 bits) Strict/Loose Bit Map (24 bits) Endereço 1 (128 bits) Endereço 2 (128 bits) .................................. Endereço n (128 bits) O campo "Comprimento" indica o número de octetos do cabeçalho, em unidades de 8 octetos, ignorando os 8 primeiros, ou seja contém o dobro do número de endereços IPv6 transportados. Como no máximo são permitidos 23 endereços, o valor máximo para este campo é de 46. Igualmente para o campo "Nós Restantes", o valor máximo será 23. O campo "Strict/Loose Bit Map" é um mapa de bits associados aos endereços transportados, o primeiro bit refere-se a "Endereço 1" e assim sucessivamente. Um bit a 1 ("strict") indica que o endereço corresponde a um nó visinho do anterior, o valor 0 ("loose") indica que os nós não são viziinhos. Cabeçalho de extensão "Fragment"Tal como o IPv4, o IPv6 suporta fragmentação de "datagramas" de modo a que estes se ajustem ao MTU das camadas inferiores das ligações por onde passa. Ao contrário do que acontecia com o IPv4, a fragmentação no IPv6 não é implementada entre nós intermédios. O nó de origem é obrigado a determinar o valor mínimo do MTU no caminho que o "datagrama" vai seguir, o nó de destino final procede ao reagrupamento. O IPv6 exige que todas as ligações suportem um MTU de no mínimo de 576 octetos. Os nós devem implementar o mecanismo "Path MTU Discovery" (RFC 1191), que permite a determinação do MTU máximo para um dado caminho. O cabeçalho de extensão "Fragment" é identificado pelo valor 44 no campo "Next Header" do cabeçalho anterior, a sua estrutura é a seguinte: Next Header (8 bits) Reservado (8 bits) OffSet (13 bits) Reservado (2 bits) MORE (1 bit) Identificação (32 bits) O campo "Offset" contém a posição em unidades de 8 octetos que os dados que se seguem têm na parte fragmentável do "datagrama" original. A "flag" "MORE" indica se é o último fragmento de um "datagrama" (MORE=1), ou se faltam mais fragmentos (MORE=0). O campo "Identificação" é gerado para cada "datagrama" que um nó decide fragmentar, o objectivo é identificar todos os fragmentos como pertencentes a um dado "datagrama". Para efeitos de fragmentação, um "datagrama" IPv6 divide-se em duas partes:
Cada fragmento contém uma cópia da parte não fragmentável do datagrama original, seguida do cabeçalho de extensão "Fragment" e finalmente o fragmento propriamente dito (da parte fragmentável). O campo "Payload Length" dos cabeçalhos IPv6 de cada fragmento são alterados de modo a conterem o tamanho do fragmento. Cabeçalhos de extensão "Destination Options"Estes cabeçalhos destinam-se a transportar opções adicionais, é identificado pelo valor 60 no campo "Next Header" do cabeçalho anterior, de momento apenas estão definidas as opções PAD-1 e PAD-N, a estrutura deste cabeçalho é idêntica ao "Hop-by-Hop Options": Next Header (8 bits) Comprimento (8 bits) Opções (variável) Ausencia de cabeçalho de extensão seguinteO valor 59 no campo "Next Header" de um cabeçalho indica que nada se lhe segue. Pseudo-Cabeçalho IPv6 para os protocolos de nível superiorOs protocolos de nível superior (que usam o IP), tais como o ICMP, TCP e UDP utilizam uma parte do cabeçalho IP para calculo do seu próprio "checksum" e para acesso aos endereços IP. Para evitar muitas alterações nos protocolos de nível superior foi definida a seguinte estrutura lógica designada por "Pseudo-Cabeçalho" IPv6: Source Address (128 bits) Destination Address (128 bits) Payload Length (32 bits) ZERO (24 bits) Next Header (8 bits) O campo "Payload Length" contém o número de octetos ocupado pelo protocolo de nível superior. Independentemente de existirem ou não cabeçalhos de extensão, o campo "Next Header" identifica sempre o protocolo de nível superior. O pseudo-Cabeçalho" IPv4 era extremamente semelhante, pelo menos em termos de conteúdo: Source Address (32 bits) Destination Address (32 bits) ZERO (8 bits) Protocol (8 bits) Data Length (16 bits) ICMP para IPv6 (ICMPv6)O IPv6 utiliza o ICMP tal como existia para o IPv4, contudo foram necessárias algumas alterações (RFC 1885). O identificador de protocolo 1, usado para o ICMPv4 foi abandonado, um cabeçalho e mensagem ICMPv6 são identificados pelo valor 58 no campo "Next Header" do cabeçalho anterior. Uma mensagem ICMPv6 possui a seguinte estrutura, semelhante à do ICMPv4: Type (8 bits) Code (8 bits) Checksum (16 bits) Dados da Mensagem (variável) Ao contrário do que acontecia com o ICMPv4, o "checksum" é calculado sobre a mensagem, incluindo também o Pseudo-cabeçalho IPv6. O campo tipo pode ter um dos seguintes valores: 1 Destination Unreachable 2 Packet Too Big 3 Time Exceeded 4 Parameter Problem 128 Echo Request 129 Echo Reply 130 Group Membership Query 131 Group Membership Report 132 Group Membership Reduction Tal como já acontecia para o ICMPv4, as mensagens dividem-se em duas categorias: ERRO ("type" menor do que 128) e INFORMAÇÃO ("type" maior do que 127). Devido às variantes de endereçamento proporcionadas pelo IPv6 são importantes alguns cuidados quanto à definição dos endereços de origem para
as mensagens de erro, em função do endereço de destino do "datagrama" onde o erro ocorreu:
Regras gerais de processamento ICMPv6:
Mensagem "Destination Unreachable"Esta mensagem é enviada (geralmente por um "router") quando o destino especificado num "datagrama" não pode ser atingido, por razões que não a congestão de um nó, o código indica o tipo de destino não atingido: 0 no route to destination 1 communication with destination administratively prohibited 2 not a neighbor 3 address unreachable 4 port unreachable O código zero é gerado quando um "router" não sabe para onde enviar o "datagrama". O código 1 é gerado quando existe um filtro/"firewall" que impede a passagem. O código 2 é gerado quando existe um cabeçalho de extensão "routing" e um dado nó especificado como "strict" não é vizinho do anterior. Outras razões para que não se possa atingir o endereço de destino geram o código 3. O código 4 é gerado quando a porta de destino não tem nenhuma aplicação associada para receber os dados. Seja qual for o tipo de erro a camada superior a que pertence o "datagrama" deve ser notificada. Após o "checksum" existem 32 bits reservados que devem ser inicializados com zero, segue-se parte do "datagrama" original. Mensagem "Packet Too Big"O IPv6 implementa fragmentação apenas entre nós finais e não "router" a "router" como acontecia com o IPv4. Quando um "router" IPv6 recebe um "datagrama" ou fragmento e o MTU correspondente ao "hop" seguinte é demasiado pequeno, esta mensagem é enviada à origem com código 0. O MTU do "hop" no qual se dá a falha é enviado num campo de 32 bits após o "checksum". O envio deste valor facilita uma implementação eficiênte do "MTU Path Discovery" (RFC 1191) que permite a determinação do MTU máximo a usar num dado caminho. Quando este erro ocorre, a camada superior a que pertence o "datagrama" deve ser notificada. Mensagem "Time Exceeded"Esta mensagem pode ser gerada em duas situações:
Mensagem "Parameter Problem"Esta mensagem indica que existe um problema no cabeçalho IPv6 ou cabeçalhos de extensão: Código 0 Campo com erro Código 1 "Next Header" desconhecido Código 2 "Opção" desconhecida Depois do "checksum" segue-se um campo de 32 bits que indica o "offset" da localização do erro dentro do "datagrama" original. Mensagens "Echo Request" e "Echo Reply"Não existem diferenças relevantes relativamente ao ICMPv4. Mensagens "Group Membership"Estas mensagens destinam-se à gestão de nós membros de grupos "multicast", junto dos "routers" locais , razão pela qual o "Hop Limit" do respectivo cabeçalho IPv6 é sempre 1. No IPv4 os endereços de "multicast" surgiam como uma extensão sendo necessário um protocolo adicional documentado nas RFC 1112 e RFC 2236 (IGMP - "Internet Group Management Protocol"). No ICMPv6 deixa de ser necessário o IGMP e as mensagens são integradas no ICMP, o seu formato é o seguinte: Type (8 bits) Tipo ICMP (130; 131 ou 132) Código (8 bits) Sempre ZERO Checksum (16 bits) ver formato geral ICMPv6 ----------------------------------------------------------- MAX Delay (32 bits) Tempo máximo de resposta ZERO (32 bits) Endereço MCAST (128 bits) Tipos de mensagem: 130 "Group Membership Query" 131 "Group Membership Report" 132 "Group Membership Reduction" O campo "MAX Delay" é usado apenas no tipo 130, e define o atraso máximo (em milisegundos) para a obtenção de uma resposta. Os principios de funcionamento mantêm-se fieis à RFC 1112. A mensagem "Group Membership Query" é enviada pelos "hosts" aos "routers" para obtenção de informação quanto à existencia de grupos locais de "multicast". O campo "Endereço MCAST" pode ser colocado a zero para obtenção de informação sobre qualquer grupo com membros "General Query" ou conter um endereço "multi-cast" para determinar se existem membros nesse grupo "Group-Specific Query". Os "routers" também enviam periodicamente mensagens "General Query" a que os membros devem responder. A mensagem "Group Membership Report" é enviada em resposta à anterior, ou em certas situações por iniciativa própria de um membro ou de um "router". Por exemplo quando um "router" envia uma mensagem "Group-Specific Query" e não obtém resposta num tempo pré-determinado considera que o grupo não possui membros. A mensagem "Group Membership Report" é usada pelos "hosts" para se tornarem membros de um grupo, basta proceder ao seu envio para um "router" local. A mensagem "Group Membership Reduction" é usada para sair de um grupo de "multi-cast", para tal o membro envia-a ao "router". Existem diversos aspectos de implemntação que são atendidos, nomeadamente quanto a temporizações, por exemplo quando um "router" envia uma mensagem "Group Membership Query" para confirmar o número de membros não é conveniente uma resposta imediata de todos os membros, por esta razão cada membro introduz um atraso aletório no tempo de resposta. |