Exploração da implementação actual de IPv6 no kernel do Linux§ão... · Com base no estudo realizado, explora-se o suporte do IPv6 no Kernel do Linux, fazendo uma análise detalhada

INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA

Departamento de Engenharia de Electrónica e Telecomunicações e

de Computadores

ISEL

Exploração da implementação actual de IPv6 no

kernel do Linux

Márcio Moeda

(Licenciado)

Trabalho de projecto realizado para obtenção do grau de Mestre em

Engenharia Informática e de Computadores

Orientador:

Professor adjunto Pedro Ribeiro, ISEL

Júri:

Presidente: Professor adjunto Vítor Almeida, ISEL

Vogais:

Professor adjunto João Ascenso, ISEL

Março de 2011

Exploração da Implementação actual de IPv6 no Kernel do Linux ii

Agradecimentos

Em primeiro lugar agradeço o meu orientador Pedro Ribeiro, pelo acompanhamento,

auxílio e disponibilidade que mostrou durante todo este período.

Agradeço o apoio de toda a minha família e dos meus amigos, e em especial dos meus

pais pelo incondicional apoio e permanente incentivo que tenho recebido ao longo dos

anos.

Agradeço a todas as pessoas que contribuíram para a concretização desta dissertação.

Finalmente, um agradecimento especial à Sheila Maritza T. P. Monteiro pelo amor, apoio,

incentivo e pela enorme ajuda que me deu ao ajudar na correcção do trabalho.

A todos muito Obrigado.

Exploração da Implementação actual de IPv6 no Kernel do Linux iii

Resumo

A presente dissertação visa retratar a exploração do suporte do protocolo Internet

versão seis (IPv6) no kernel do Linux, conjuntamente com a análise detalhada do estado

da implementação dos diferentes aspectos em que se baseia o protocolo.

O estudo incide na experimentação do funcionamento em geral do stack, a identificação

de inconsistências deste em relação aos RFC’s1 respectivos, bem como a simulação

laboratorial de cenários que reproduzam casos de utilização de cada uma das facilidades

analisadas.

O objectivo desta dissertação não é explicar o funcionamento do novo protocolo IPv6,

mas antes, centrar-se essencialmente na exploração do IPv6 no kernel do Linux. Não é

um documento para leigos em IPv6, no entanto, optou-se por desenvolver uma parte

inicial onde é abordado o essencial do protocolo: a sua evolução até à aprovação e a sua

especificação.

Com base no estudo realizado, explora-se o suporte do IPv6 no Kernel do Linux, fazendo

uma análise detalhada do estado de implementação dos diferentes aspectos em que se

baseia o protocolo. Bem como a realização de testes de conformidade IPv6 em relação

aos RFC’s.

1 RFC é um acrónimo para o inglês Request for Comments, é um documento que descreve os

padrões dos protocolos propostos para a Internet antes de serem considerados um standard.

Exploração da Implementação actual de IPv6 no Kernel do Linux iv

Abstract

The aim of this dissertation is to describe the support exploration protocol of Internet

version six (IPv6) in the Linux kernel in conjunction with a detailed analysis of the

implementation state of the different aspects on which the protocol is based.

This study focuses on the general working experimentation of stack, the identification of

its inconsistencies in relation to the corresponding RFCs as well as laboratory simulation

of scenarios, which reproduce instances of use of each of the facilities analyzed.

The goal of this dissertation is not to explain how the new IPv6 protocol works; rather, it

focuses primarily on the exploration of Linux’ IPv6 kernel. This is not a document for

people who are not familiar with IPv6. However, we opted to develop an initial part in

which we address the fundamentals of the protocol namely, its evolution and approval and

its specification.

Based on this study, we explore the support of IPv6 in Linux’ Kernel through a detailed

analysis of the implementation state of the different aspects on which this protocol is

based. Also, conformity tests were conducted in relation to RFC’s.

Exploração da Implementação actual de IPv6 no Kernel do Linux v

Acrónimos

TN Nó que realiza o teste

NUT Nó que é testado

NA Neighbor Advertisement

NS Neighbor Solicitation

ICMPv6 Internet Control Message Protocol for the Internet Protocol Version 6

PDU Protocol Data Unit

USAGI UniverSAL playGround for IPv6

SIP Simple Internet Protocol

PIP ―P‖ Internet Protocol

SIPP The Simple Internet Protocol Plus

IPAE IP Address Encapsulation

TUBA TCP and UDP with Bigger Addresses

CATNIP Common Architecture for the Internet

IPng IP Next Generation Protocol

IESG Internet Engineering Steering Group

IANA Internet Assigned Numbers Authority

ICANN Internet Corporation for Assigned Names and Numbers

ARPANET Advanced Research Projects Agency Network

QoS Quality of Service

CIDR Classless InterDomain Routing

NAT Network Address Translation

Exploração da Implementação actual de IPv6 no Kernel do Linux vi

Índice

Agradecimentos ................................................................................................................. ii

Resumo ............................................................................................................................ iii

Abstract ............................................................................................................................ iv

Acrónimos.......................................................................................................................... v

Índice ................................................................................................................................ vi

Índice de Figuras ............................................................................................................... x

Índice de tabelas............................................................................................................... xi

Capítulo I ......................................................................................................................... 13

Considerações Gerais ..................................................................................................... 13

1.1. Introdução .........................................................................................................13

1.2. Pergunta de partida ou problema da investigação .............................................15

1.3. Objectivos ..........................................................................................................16

1.4. Síntese dos capítulos ........................................................................................17

Capítulo II ........................................................................................................................ 18

IPv6 ................................................................................................................................. 18

1.1. Considerações Gerais .......................................................................................18

1.2. Evolução do Protocolo Internet (IPv6) ................................................................19

1.3. Porquê o IPv6? ..................................................................................................22

1.4. Limitações do IPv4 ............................................................................................23

1.5. Especificação do IPv6 .......................................................................................26

Simplificação do cabeçalho ......................................................................................28

Capítulo III ....................................................................................................................... 31

Ferramenta de conformidade da especificação IPv6 ....................................................... 31


1.2. Procedimento comum de limpeza dos testes .....................................................33

1.3. Definição da estrutura do pacote .......................................................................33

1.4. Exemplos de Funções Disponíveis na API ........................................................34

Exploração da Implementação actual de IPv6 no Kernel do Linux vii

Capítulo IV ....................................................................................................................... 36

Descrição dos testes IPv6 realizados .............................................................................. 36

1. Considerações Gerais ...........................................................................................36

2. Testes em relação à especificação base do IPv6 ..................................................37

2.1. Teste ao Campo Versão (Version Field).........................................................37

2.1.1. Objectivo .................................................................................................37

2.1.2. Corpo do Teste .......................................................................................37

2.1.3. Resultado esperado do Teste .................................................................40

2.2. Teste ao campo Traffic Class .........................................................................40

2.2.1. Objectivo .................................................................................................41

2.2.2. Corpo do Teste .......................................................................................41


2.3. Teste ao campo Flow Label ...........................................................................42

2.3.1. Objectivo .................................................................................................43

2.3.2. Corpo do Teste .......................................................................................43

2.3.3. Resultado do Teste .................................................................................44

2.4. Teste ao campo Payload Length ....................................................................44

2.4.1. Objectivo .................................................................................................44

2.4.2. Corpo do Teste .......................................................................................44


2.5. Teste campo Next Header irreconhecível .......................................................46

2.5.1. Objectivo .................................................................................................47

2.5.2. Corpo do Teste .......................................................................................47


2.6. Teste campo Hop Limit igual a zero ...............................................................49

2.6.1. Objectivo .................................................................................................49

2.6.2. Corpo do Teste .......................................................................................49


3. Testes referentes ao processamento das Opções e Cabeçalhos de Extensões ....51

3.1. Pacote Echo Request usado nos testes .........................................................53

3.2. Teste ao campo Next Header do cabeçalho de Extensão ..............................54

3.2.1. Objectivo .................................................................................................54

3.2.2. Corpo do teste ........................................................................................54

Exploração da Implementação actual de IPv6 no Kernel do Linux viii

3.2.3. Resultado esperado do teste ..................................................................55

3.3. Teste à ordem do cabeçalho de extensão Hop-by-Hop num pacote com mais

de um cabeçalho extensão .......................................................................................56

3.3.1. Objectivo .................................................................................................57

3.3.2. Corpo do teste ........................................................................................57


3.4. Teste ao cabeçalho de extensão Hop-by-Hop ................................................59

3.5. Teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop

62

3.5.1. Objectivo .............................................................................................63

3.5.2. Corpo do teste .....................................................................................63

3.5.3. Resultado esperado do teste ...............................................................65

3.6. Teste à codificação dos dois bits de maior ordem do indicador Option Type

66

3.6.1. Objectivo .............................................................................................67

3.6.2. Corpo do Teste ....................................................................................67

3.6.3. Resultado esperado do teste ...............................................................69

4. Testes referentes à fragmentação no IPv6 ............................................................69

4.1. Fragmentos de pacote usados nos testes ......................................................74

4.2. Teste à reconstituição de fragmentos (ordem normal/ ordem inversa) ...........75

4.2.1. Objectivo .................................................................................................75

4.2.2. Corpo do teste ........................................................................................75


4.3. Teste à reconstituição de fragmentos (Payload size = 65.536 bytes) .............77

4.3.1. Objectivo .................................................................................................77

4.3.2. Corpo do teste ........................................................................................77


4.4. Teste à reconstituição de fragmentos quando é excedido o tempo (1st only) .78

4.4.1. Objectivo .................................................................................................79

4.4.2. Corpo do teste ........................................................................................79


Capítulo V ........................................................................................................................ 80

Resultado dos Testes Realizados .................................................................................... 80


Exploração da Implementação actual de IPv6 no Kernel do Linux ix

1.2. Resultado dos testes .........................................................................................80

1.3. Análise dos resultados .......................................................................................82

1.4. Comparação entre sistemas operativos .............................................................85

Capítulo VI ....................................................................................................................... 87

Conclusão........................................................................................................................ 87


1.2. Verificação das hipóteses teóricas e práticas ....................................................87

1.3. Limitações da Investigação ................................................................................88

1.4. Investigações futuras .........................................................................................88

Bibliografia ....................................................................................................................... 89

Exploração da Implementação actual de IPv6 no Kernel do Linux x

Índice de Figuras

Figura 1 - Linux Kernel 2.1.8. ...........................................................................................15

Figura 2 - Crescimento da internet ...................................................................................24

Figura 3 - Cabeçalho IPv4. ..............................................................................................28

Figura 4 - Cabeçalho IPv6. ..............................................................................................28

Figura 5 - Programa de execução Automática .................................................................33

Figura 6 - Cabeçalho de Extensão ...................................................................................52

Figura 7 - Cabeçalho Hop-by-Hop Option ........................................................................59

Figura 8 - Captura do Cabeçalho Hop-by-Hop Option ......................................................59

Figura 9 - Formato do campo opções. .............................................................................61

Figura 10 - Valor do tipo de opção Pad1 de um pacote IPv6 ...........................................62

Figura 11 - PadN Option. .................................................................................................62

Figura 12 - Cabeçalho de Extensão Fragmentation .........................................................70

Figura 13 - Fragmentação de pacotes. ............................................................................71

Figura 14 - Pacote original. ..............................................................................................71

Figura 15 - Pacotes fragmentados. ..................................................................................72

Exploração da Implementação actual de IPv6 no Kernel do Linux xi

Índice de tabelas

Tabela 1 - Script de teste disponível ................................................................................32

Tabela 2 - Script Status Code ..........................................................................................34

Tabela 3 - Funções disponíveis na API ............................................................................34

Tabela 4 - Exemplo vSend ...............................................................................................35

Tabela 5 - Exemplo vRec .................................................................................................35

Tabela 6 - Funções do script IH_BadIPv6Ver.seq ............................................................38

Tabela 7 - Pacotes gerados pelo script IH_BadIPv6Ver.seq ............................................39

Tabela 8 - Acções executadas no teste ao campo Versão ...............................................39

Tabela 9 - Função do script TC_NonZeroToHost.seq ......................................................41

Tabela 10 - Acções executadas no teste ao campo Traffic Class ....................................42

Tabela 11 - Função do script FL_NonZeroToHost.seq .....................................................43

Tabela 12 - Acções executadas no teste ao campo Flow Label .......................................44

Tabela 13 - Função do script PL_OddToHost.seq ...........................................................45

Tabela 14 - Pacote gerado pelo script PL_OddToHost.seq .............................................45

Tabela 15 - Acções executadas no teste ao Campo Payload Length ...............................46

Tabela 16 - Alguns valores possíveis que o campo Next Header pode assumir ..............47

Tabela 17- Função do script IH_UnrecognizedNextHeader.seq .......................................48

Tabela 18 - Pacote gerado pelo script IH_UnrecognizedNextHeader.seq ........................48

Tabela 19 - Acções executadas no teste ao campo Next Header ....................................49

Tabela 20 - Função do script HL_ZeroToHost.seq ...........................................................50

Tabela 21 - Acções executadas no teste ao campo Hop Limit .........................................50

Tabela 22 - Cabeçalho de Extensão ................................................................................52

Tabela 23 - Pacote Echo Request usado nos testes ao Cabeçalho de extensão .............53

Tabela 24- Função do script EH_UnrecognizedNextHeader.seq .....................................54

Tabela 25 - Pacote gerado pelo script EH_UnrecognizedNextHeader.seq ......................55

Exploração da Implementação actual de IPv6 no Kernel do Linux xii

Tabela 26 - Acções executadas no teste ao campo Next Header do cabeçalho de

extensão ..........................................................................................................................55

Tabela 27 - Ordem dos Cabeçalhos de Extensão ............................................................56

Tabela 28 - Função do script EH_HBHOptAfterDstOpt.seq .............................................57

Tabela 29 - Pacote gerado pelo script EH_HBHOptAfterDstOpt.seq ...............................58

Tabela 30 - Acções executadas no teste à ordem do cabeçalho de extensão Hop-by-Hop

........................................................................................................................................58

Tabela 31 - Função do script EH_HBHOptAfterDstOpt.seq .............................................63

Tabela 32 - Pacote gerado pelo script HH_Pad1.seq e HH_PadN.seq ............................64

Tabela 33 - Acções executadas no teste ao campo Opção Pad1/PadN ..........................65

Tabela 34 - Identificadores Option Type ..........................................................................66

Tabela 35 - Terceiro bit mais significativo do Option Type ...............................................66

Tabela 36 - Primitivas usadas no script HH_Type.seq .....................................................68

Tabela 37 - Pacotes gerados pelo script HH_Type.seq ...................................................68

Tabela 38 - Bit M do cabeçalho de extensão Fragment ...................................................70

Tabela 39 - Fragmentos de um Pacote Echo Request usado nos testes à fragmentação 74

Tabela 40 - Primitivas usadas para gerar fragmentos de um pacote ................................76

Tabela 41 - Acções executadas no teste ao campo Opção Pad1/PadN ..........................78

Tabela 42- Acções executadas no teste à reconstituição de fragmentos .........................79

Tabela 43 - Resultado dos Testes de Conformidade IPv6 realizados ..............................81

Tabela 44 - Teste de Conformidade IPv6 à distribuição Ubuntu e FreeBSD ....................85

Exploração da Implementação actual de IPv6 no Kernel do Linux 13

Capítulo I

Considerações Gerais

1.1. Introdução

A Internet, que na sociedade actual, assume um papel preponderante, surgiu da

necessidade de ligar computadores de forma a permitir e facilitar a partilha da

informação. O protocolo Internet (IP) é o responsável pelo transporte de dados na

internet. Existem duas variantes deste protocolo: IPv4 e IPv6.

Desde que a primeira versão do protocolo IP (IPv4) foi desenvolvida, o poder de

processamento das máquinas cresceu muito. Com o crescimento rápido da Internet, esta

tecnologia (IPv4) tem-se esgotado e muitos esforços têm sido feitos para a sua evolução.

Neste cenário é premente a necessidade de serem criadas alternativas para a solução de

problemas que começaram a surgir. A escassez de endereçamento IP para alguns

continentes, a necessidade de tratamento diferenciado aos fluxos de tráfego de serviços

em tempo real e aspectos ligados à segurança, fizeram com que os órgãos internacionais

ligados a essas matérias e os responsáveis pela elaboração das especificações do

protocolo IPv4 tivessem as suas atenções voltadas para um novo estudo.

Em 1993, o IESG2 (Internet Engineering Steering Group) criou um grupo de trabalho para

uma nova versão do protocolo IP, o IPngWG (IP Next Generation Working Group), com

base em alguns objectivos que deveriam ser alcançados.

2 O IESG é responsável pela gestão técnica das actividades IETF. http://www.ietf.org/iesg/

http://www.ietf.org/iesg/

Capítulo I – Considerações Gerias


O grupo de trabalho seleccionou três protocolos para a camada de rede da arquitectura

TCP/IP.

O primeiro designado de IPAE (IP Address Encapsulation), o segundo designado de SIP

(Simple Internet Protocol) e o terceiro designado de PIP (“P” Internet Protocol). A

combinação de aspectos positivos dos três protocolos deu origem a um novo protocolo

designado de SIPP (Simple Internet Protocol Plus).

O protocolo indicado pelo grupo foi o SIPP3 (Simple Internet Protocol Plus), por ser o

mais próximo do IPv4, e por ter um plano de transição melhor.

O protocolo IPv6 é uma nova versão do protocolo IP. A base do IPv6 é o IPv4, isto é, foi

criado sobre uma plataforma comprovadamente eficaz, o que é fundamental tanto para a

transição entre a versão 4 e a 6, quanto para a excelência do IPv6.

O IPv6 foi concebido numa lógica de estabilidade do sistema, assim sendo, pretendeu-se

que a transição se efectuasse de forma suave e eficaz. Este factor de transição foi tido

como um factor muito importante na altura da sua concepção. Todavia, a transição para o

IPv6 não ocorrerá de forma rápida e imediata, este cenário mais não é que uma

estratégia da nova versão do protocolo, onde se pretende uma coexistência das duas

versões por um período de tempo considerável. Durante os próximos anos, irão ocorrer

duas etapas distintas, uma primeira em que existirão pequenas redes IPv6 no universo

IPv4 (situação actual) e, seguidamente, o contrário, ou seja, quando o protocolo IPv6

estiver generalizado irão prevalecer pequenas redes IPv4 no universo IPv6.

3 Simple Internet Protocol Plus (SIPP) http://www.faqs.org/rfcs/rfc1710.html

http://www.faqs.org/rfcs/rfc1710.html



1.2. Pergunta de partida ou problema da investigação

O primeiro código relacionado ao IPv6 foi adicionado ao kernel do Linux na versão

2.1.8 por Pedro Roque da Faculdade de Ciências de Universidade de Lisboa, ainda com

muitas limitações4 de implementação.

Figura 1 - Linux Kernel 2.1.8.

O suporte ao IPv6, com a versão 2.2.x, passou a ser incluído no código fonte do kernel e

já ostentava maior estabilidade em relação às versões anteriores, entretanto ainda não

vinha activado por defeito. Actualmente, a maioria das distribuições Linux vem com o

suporte ao IPv6 activado e com algumas funcionalidades disponíveis, possibilitando a

utilização das principais novidades do IPv6.

A universalidade do IPv6 leva a um grande número de implementações. O IPv4,

contrariamente, começou com um pequeno grupo fechado, a interoperabilidade tem sido

sempre considerada como um elemento essencial para a comunidade da Internet.

Grande número de implementações de funcionalidades do IPv6 no kernel do Linux e de

outros sistemas operativos não acompanhou os ―Drafts‖ ou os RFC’s recém-lançados.

A ausência de manutenção fez com que algumas funcionalidades passassem a estar

desactualizadas. Para atenuação e/ou eliminação dessas falhas, foi lançado um projecto

designado por USAGI5 (UniverSAL playGround for IPv6) que trabalha em parceria com

outros projectos tais como WIDE Project, KAME Project e TAHI Project.

4 Retirado do documento do Peter Bieringer: http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-

0.html 5 O projecto USAGI pode ser consultado no seguinte link: http://www.linux-ipv6.org/

http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-0.html

http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-0.html

http://www.linux-ipv6.org/



Estes projectos têm como objectivo primordial o desenvolvimento do IPv6 principalmente

para sistemas operativos Linux, isto é, visam melhorar o IPv6 no ambiente Linux e

implementar a Internet IPv6 no mundo.

Presentemente, conseguiram-se alcançar muitas melhorias no kernel, bibliotecas e

aplicativos. O resultado desse trabalho foi integrado no kernel 2.6.

1.3. Objectivos

Para a elaboração desta dissertação foram estabelecidos três objectivos gerais, sobre

os quais se definem com maior especificidade os objectivos concretos, de acordo com a

evolução verificada.

Existem objectivos ao nível do trabalho prático, sendo estes mais imediatos, uma vez

que, se prendem com a exploração do suporte de IPv6 no Kernel do Linux, com a análise

detalhada do estado de implementação dos diferentes aspectos em que se baseia o

protocolo e outros de índole mais teórica, visto que se pretende tirar conclusões sobre o

estudo/análise anteriormente referido.

O primeiro objectivo é o estudo das características e a arquitectura do protocolo IPv6.

Apresenta-se a nova versão do protocolo IP, o IPv6, descreve-se a sua evolução até a

aprovação, e, ainda, detalhadamente a sua especificação.

O segundo objectivo, consiste na exploração do suporte de IPv6 no Kernel do Linux, com

a análise detalhada do estado de implementação dos diferentes aspectos em que se

baseia o protocolo. Serão objectivos a experimentação do funcionamento em geral do

stack, a identificação de inconsistências deste em relação aos RFC’s respectivos bem

como a simulação laboratorial de cenários que reproduzam casos de utilização de cada

uma das facilidades analisadas.

O terceiro, comparação entre o suporte de IPv6 no Kernel de várias distribuições Linux e

outros sistemas operativos.

O quarto, considerações finais sobre o tema.



1.4. Síntese dos capítulos

Esta dissertação é composta por seis (6) capítulos. Neste primeiro capítulo faz-se

uma introdução, na qual é referido o enquadramento do trabalho, bem como a referência

à organização da dissertação. A este capítulo introdutório, segue-se, no segundo

capítulo, uma análise detalhada do estado de implementação dos diferentes aspectos em

que se baseia o protocolo IPv6 no Kernel do Linux. No terceiro capítulo, faz-se uma

descrição sobre a ferramenta de testes utilizada. No quarto capítulo, realizam-se os

testes de conformidade IPv6 em relação aos RFC´s, testes esses que se incidem sobre a

especificação base do IPv6, definidos no RFC 2460. No quinto capítulo, faz-se a análise

dos resultados obtidos dos testes realizados. No sexto capítulo, faz-se as conclusões e

recomendações.


Capítulo II

IPv6

1.1. Considerações Gerais

A internet é vista como uma tecnologia relativamente nova, embora os protocolos

e tecnologias que a fazem funcionar tenham sido desenvolvidos entre 1970 e 1980,

actualmente a maioria das redes públicas e privadas usam o IPv4. O protocolo Internet

(IP) corresponde à linguagem comum da Internet, sendo usada por todos os dispositivos

que se encontram ligados à Internet.

A versão actual do protocolo Internet, versão 4 (designado por IPv4) tem várias lacunas

que dificultam, e em alguns casos apresentam barreiras para o desenvolvimento da

Internet. A revolução trazida pelo IPv6 vem remover essas barreiras e proporcionar um

ambiente rico em recursos para o futuro da rede Global.

O protocolo IP versão 6 (o 6 corresponde ao número da versão em causa) designado de

IPv6 constitui a nova geração do protocolo base da Internet. Foi recomendada pela Área

de Administração da IPng da Internet Engineering Task Force, na reunião do IETF em

Toronto 25 de Julho de 1994 no RFC 17526. A recomendação foi aprovada pelo Internet

Engineering Steering Group, foi feita uma proposta de norma (Proposed Standard7) em

17 de Novembro de 1994.

Foi projectado para funcionar bem em redes de alto desempenho (por exemplo, Gigabit

Ethernet, ATM, etc.).

6 The Recommendation for the IP Next Generation Protocol http://www.faqs.org/rfcs/rfc1752.html

7 Proposed Standard http://playground.sun.com/ipv6/doc/ipng-recomm-proposed-standard.txt


http://playground.sun.com/ipv6/doc/ipng-recomm-proposed-standard.txt

Capítulo II – IPv6


1.2. Evolução do Protocolo Internet (IPv6)

A história em torno do IPv6 começou no início dos anos noventa, quando as

projecções indicavam que o espaço de endereçamento da Internet (endereço IPv4)

tornava um recurso cada vez mais limitado. Esta situação desafiou a comunidade da

Internet a procurar novas soluções.

O Internet Engineering Task Force (IETF) iniciou o esforço para escolher um sucessor

para o IPv4. Houve uma conjugação de esforços de vários grupos de trabalho, com vista

à exploração de possíveis soluções para as limitações de endereçamento do IPv4 e

também para fornecer funcionalidades adicionais. Deste esforço conjunto e também da

evolução de diferentes propostas da Internet Engineering Task Force (IETF) surgiu uma

nova geração do protocolo IP, designado de IP the Next Generation8, o seu nome original

foi logo substituído por IP versão 6, que é agora o nome definitivo. Os principais

arquitectos do novo protocolo foram Steven Deering e Robert Hinden9.

Cronologicamente a evolução da nova geração do protocolo IP (IPng) foi a seguinte

segundo o RFC 1752: [1]

1990 - No encontro IETF de Vancouver, Frank Solensky, Phill Gross e Sue Hares

afirmaram que à taxa de atribuição do espaço de endereçamento IPv4, às classes do tipo

B esgotariam por volta de Março de 1994. A solução seria atribuir vários endereços

classe C em vez dos endereços classe B, o que traria outro problema aumentando o

tamanho das tabelas de Routing que cresciam a um ritmo inquietante. Na incerteza de

escolher entre aceitar ou limitar a taxa de crescimento da internet, ou a interrupção da

internet alterando-a para novas técnicas ou tecnologias foi criado um novo grupo de

trabalho (ROAD)10, Cuja finalidade primordial era dirimir as duvidas existentes

1991 - A IETF forma o grupo de trabalho Routing and Addressing (ROAD) no encontro de

Santa Fé com o objectivo de encontrar uma solução para a exaustão do espaço de

endereçamento IPv4.

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:

8 The Recommendation for the IP Next Generation Protocol http://tools.ietf.org/html/rfc1752

9 Grupo de trabalho IPv6 http://playground.sun.com/ipv6/

10 IESG Deliberations on Routing and Addressing http://www.ietf.org/rfc/rfc1380.txt

http://tools.ietf.org/html/rfc1752

http://playground.sun.com/ipv6/

http://www.ietf.org/rfc/rfc1380.txt



CNAT

IP Encaps

Nimrod

Simple CLNP

1992 (finais) – Surgem mais três propostas:

The P Internet Protocol (PIP)

The Simple Internet Protocol (SIP)

TP/IX

Em Novembro (1992), no seio da IETF, decorreu uma sessão denominada Selection

Criteria BOF com o objectivo de obter consenso em relação ao critério a aplicar na

escolha do sucessor do protocolo IPv4. Dos dois documentos preparatórios em discussão

e dos pontos de vista expressos na reunião saiu um novo documento contendo os

critérios de selecção tidos como consensuais.

Dispondo da sugestão do Internet Engineering Steering Group (IESG) em relação ao

critério técnico a adoptar na escolha do próximo protocolo IP delineada no RFC 138011 e

dos resultados da discussão dentro do próprio IETF anteriormente referida, e o IETF

considerou necessário um debate alargado sobre este tópico e emitiu um ―call for white

paper‖. [2]

Em resposta a esta solicitação foram recebidos vinte e três artigos contendo os pontos de

vista dos sectores industrial, tecnológico e comercial.

1993 - Phil Gross (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.

1993 (finais) – SIP evoluiu, abrangendo características do IP Address Encapsulation

(IPAE)12. SIP e PIP deram origem à proposta The Simple Internet Protocol Plus (SIPP).

Ao mesmo tempo, a proposta TUBA alterou o nome para Common Architecture for the

Internet (CATNIP).

1994 - Aprovação do documento The Recommendation for the IP Next Generation

Protocol13 como norma oficial de desenvolvimento do IPng.

1995 – Foi publicado o primeiro conjunto de RFC’s especificando o IPv6 [RFC 1883]14

11

IESG Deliberations on Routing and Addressing http://www.rfc-editor.org/in-notes/rfc1380.txt 12

O IPAE foi adoptado como estratégia de transição para o SIP (Simple IP), proposto por Steve Deering em Novembro de 1992 http://tools.ietf.org/html/draft-ietf-ipae-ipv7-criterias-00 13

The Recommendation for the IP Next Generation Protocol http://www.ietf.org/rfc/rfc1752.txt

http://www.rfc-editor.org/in-notes/rfc1380.txt

http://tools.ietf.org/html/draft-ietf-ipae-ipv7-criterias-00




1995 – Concepção do Projecto 6Bone

1996 (Março) – Formalização do projecto 6bone em Março, no encontro IETF em Los

Angeles.

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 Laboratory15 (NRL/US) e a CISCO16

(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).

1996 (Dezembro) – Formação do grupo de trabalho 6bone (actualmente NGtrans).

1997 (Agosto) – No encontro do grupo de trabalho ngtrans-6bone que decorreu 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.

1997 (Dezembro) – No encontro de Washington, a 6bone apresentava já 206 sites em 30

países participantes.

1998 (Março) – No encontro de Los Angeles, a 6bone apresentava 240 sites IPv6 em 32

países.

2010 (Setembro) – Segundo estimativas actuais de Geoff Houston17, conceituado

responsável da APNIC, os endereços IPv4 ficarão completamente esgotados em Janeiro

de 2012.

2011 (Janeiro) - A Internet Assigned Numbers Authority (IANA) entregou dois dos últimos

sete blocos de endereços Internet em IPv4. Tudo indica que os últimos cinco blocos são

entregues em breve. O esgotamento de endereços está iminente.

14

Internet Protocol, Version 6 (IPv6) http://www.ietf.org/rfc/rfc1883.txt 15

Naval Research Laboratory http://www.nrl.navy.mil/ 16

Cisco http://www.cisco.com/ 17

Geoff Houston – ―Potaroo‖ IPv4 Address Report http://www.potaroo.net/tools/ipv4/


http://www.nrl.navy.mil/

http://www.cisco.com/

http://www.potaroo.net/tools/ipv4/



1.3. Porquê o IPv6?

Segundo a Internet Corporation for Assigned Names and Numbers (ICANN18), a

inovação e o crescimento contínuo da Internet, trazem novos desafios que mantém a

estabilidade. Na concepção do protocolo IP, há aproximadamente duas décadas, não

foram previstas necessidades emergentes da sociedade e da sua relação com os

sistemas de comunicação actuais, em particular com a Internet. Devido a este facto, há

características que necessitam de alterações.

Essas características necessárias são espaços de endereçamento, auto-configuração,

mobilidade, segurança na camada da rede, qualidade de serviço e suporte de aplicações

no tempo real.

Tal como qualquer versão superior, o IPv6 baseia-se essencialmente na resolução

de antigos problemas e implementação de novas funcionalidades. Isso não quer dizer

que o protocolo IPv4 esteja mal implementado, muito pelo contrário. O IPv4, especificado

desde 1981, obteve um grande sucesso e continua a tê-lo, por isso mesmo se adivinha

ainda difícil a curto prazo, a tarefa da sua substituição pelo IPv6.

O IPv6 é um pouco controverso no que diz respeito à sua necessidade actual. Opções a

curto prazo têm sido escolhidas em detrimento do IPv6, mas o desenvolvimento dessas

estratégias tende a tornar-se desmotivador.

A nova versão do protocolo não é uma necessidade urgente, como o mediático bug do

ano 2000. O IPv6 implicará uma movimentação bem mais vagarosa por parte do mundo

empresarial, ao contrário do que aconteceu com o bug. Mas esta necessidade é real e a

força que mais o impulsiona é o rápido crescimento da Internet. [3]

A motivação primária para mudanças no IP advém do espaço de endereçamento

limitado. Quando o IP foi definido, existiam somente algumas redes. Foi usado 32 bits

para o endereçamento IP, o que permitiria que a internet incluísse mais de um milhão de

redes. Porém, a internet está crescendo exponencialmente, com o seu tamanho

duplicando em menos de um ano. Na taxa de crescimento actual, cada um dos actuais

prefixos de rede possível serão logo atribuídos, e nenhum crescimento adicional será

possível. Deste modo, a motivação primária para definir uma nova versão do IP surgiu da

limitação de espaço de endereçamento – são necessários endereços maiores para

acomodar o crescimento contínuo da internet. [4]

18

ICANN (acrónimo em inglês para Corporação da Internet para Atribuição de Nomes e Números)

http://www.icann.org/

http://www.icann.org/



As motivações primárias e secundárias para mudanças no IP surgiram das novas

aplicações e serviços existentes na internet. Por exemplo aplicações que disponibilizam

áudio e vídeo precisam entregar os dados em intervalos regulares. Para manter tais

informações cruzando a internet sem interrupções, o IP deve evitar variar frequentemente

as rotas. Embora o actual cabeçalho do pacote IP inclua um campo que pode ser usado

para solicitar um tipo serviço, o protocolo não define um tipo de serviço que pode ser

usado para entregar em tempo real de áudio e vídeo. [4]

Outras causas para mudanças no IP baseiam-se nas especificações do protocolo IPv6

que são mais claras e optimizadas, eliminando as características não utilizadas e

obsoletas do protocolo anterior (IPv4) atingindo assim uma optimização do protocolo IP.

Especificações essas que podem definir-se sucintamente como:

Protocolo auto-configurável.

Protocolo mais seguro.

Protocolo com mais responsabilidade a nível de QoS.

Protocolo com vista à mobilidade.

Protocolo mais eficiente.

Protocolo virado para o modelo ponto-a-ponto.

Mecanismos de transição entre os dois protocolos.

1.4. Limitações do IPv4

Não houve mudanças expressivas no protocolo IPv4 desde o RFC 791, publicada

em 1981. O protocolo IPv4 provou ser robusto e facilmente implementável, conseguindo

sustentar uma rede informática (ARPANET) que inicialmente foi pensada apenas para

fins militares e académicos nos Estados Unidos tendo-se depois expandido globalmente

para os dias de hoje ficando conhecida como a Internet. [5]

A internet prosperou de um protótipo de pesquisa para um sistema global de

comunicação. Contudo, o seu tamanho não é tão surpreendente como é a sua taxa de

crescimento. A figura 219 ilustra esse crescimento. A figura contém um gráfico com o

número de computadores ligados à internet em função do ano (1995 a 2010).

19

Estatísticas sobre o crescimento da internet:



Figura 2 - Crescimento da internet20

No ano de 1994 a Internet era composta por cerca de 40 mil redes. Em 1996 já eram 100

mil redes e a taxa de crescimento parecia duplicar o número de redes a cada ano. Hoje o

crescimento da Internet é independente das Universidades ou dos Centros de Pesquisa.

Existe uma forte massificação das sociedades em torno das questões relacionadas com a

sociedade da informação.

O tamanho do endereço de 32 bits faz com que o protocolo IPv4 seja um recurso com um

limite relativamente baixo. Mesmo assim, a alocação dos endereços IP's em boa parte

das vezes é mal feita.

O desenho inicial do protocolo IPv4 não antecipou os seguintes pontos:

Escassez de endereços devido ao crescimento exponencial da internet (China e

Índia).

http://www.internetworldstats.com/emarketing.htm

20 Crescimento da internet, medido pelo número de computadores ligados a cada ano.

http://www.internetworldstats.com/emarketing.htm



Necessidade de simplificar e automatizar a configuração de redes devido ao

aumento de computadores e dispositivos que utilizam endereços IP.

Falta de suporte para serviços e aplicações emergentes. Estes novos serviços e

aplicações são mais exigentes e requerem garantia de entrega de pacotes de

dados em tempo real, garantia de disponibilidade e segurança da largura de

banda. [6]

A necessidade de segurança na Internet.

Necessidade de melhorar o suporte de entrega de pacotes de dados em tempo

real – denominado QoS (Quality of Service).

Devido ao problema da exaustão da capacidade de endereçamento e outras

limitações do IPv4, foram desenvolvidas e aplicadas soluções a curto prazo tais como: [7]

Atribuição de endereços que permitam atribuir várias classes C a organizações

que necessitem de mais do que 256 endereços mas para as quais uma classe B

seja excessiva;

Classless Inter-Domain Routing CIDR21 é mais um "balão de ar" do que

propriamente uma solução, pois permite apenas adiar, por mais algum tempo, a

data de exaustão do espaço de endereçamento. [8]

O problema do tamanho excessivo das tabelas de encaminhamento foi parcialmente

contornado com a adopção do Classless InterDomain Routing (CIDR) descrito pelo RFC

4632. [9]

A ideia básica do CIDR é alocar as redes de classe C restantes (cerca de 2 milhões) em

blocos de tamanho variável. Se um site precisa de, por exemplo, 2000 endereços,

receberia 8 classes C contínuas que representam 2048 endereços.

Além disso, o RFC 4632 apontou novas regras para a alocação de redes de classe C

baseada na sua localização geográfica. O mundo foi dividido em 4 grandes zonas:

Europa, América do Norte, América Central e do Sul, Ásia e Pacífico. Assim sendo, cada

uma destas zonas teriam 32 milhões de endereços para serem alocados e outros 320

milhões de endereços classes C de 204.0.0.0 a 223.255.255.255. Com a solução CIDR,

21

Classless Inter-domain Routing http://www.rfc-editor.org/rfc/rfc4632.txt

http://www.rfc-editor.org/rfc/rfc4632.txt



as antigas classes A, B e C não são mais usadas para encaminhamento. A compreensão

de como se comportou o crescimento passado pode contribuir em muito na projecção de

um protocolo que tenha uma vida útil maior.

Network Address Translation (NAT) para contornar a falta de endereços IP. O

NAT mapeia múltiplos endereços IP privados para um único endereço IP público.

Possibilita a reutilização do espaço de endereçamento IP privado, mas não

suporta padrões base de segurança ao nível da camada de rede nem o correcto

mapeamento de todas as camadas protocolares acima dessa camada. Este

mecanismo, apesar de parecer à primeira vista perfeito, também pode criar

problemas quando duas organizações estão conectadas e utilizam um espaço de

endereçamento IP privado. Para além disso, o crescimento dos dispositivos e

aplicações ligados à Internet provam que o espaço de endereçamento IP público

irá acabar.

1.5. Especificação do IPv6

O IPv6 contém muitas das características que fizeram o IPv4 ser tão bem sucedido.

Apesar de reter os conceitos básicos do IPv4, o IPv6 modifica todos os detalhes. As

funcionalidades do IPv4 que não têm um bom desempenho ou que não são usadas com

frequência foram removidas ou tornadas opcionais. Certas capacidades novas que se

consideram necessárias foram adicionadas sem, no entanto, alterar os conceitos do IPv4.

[4]

As principais alterações efectuadas do IPv4 para o IPv6 podem ser agrupadas na

seguinte categoria: [10]

Extensão das capacidades de endereçamento e encaminhamento – O tamanho

de endereços passa de 32 bits na versão 4 para 128 bits na versão 6, o que

permite o suporte de um número muito superior de nós, uma melhor

hierarquização do espaço de endereçamento essencial à escalabilidade do

encaminhamento e uma maior facilidade em termos de auto configuração. A

escalabilidade dos endereços Multicast é também aumentada através da adição

do campo ―scope‖. E também é definido novo tipo de endereço designado

―anycast‖ usado para enviar um pacote para qualquer um dos grupos de nós.

Simplificação do formato do cabeçalho – Alguns campos do cabeçalho IPv4 foram

removidos ou passaram a ser opcionais de forma a simplificar o tratamento de um



pacote comum. O cabeçalho IPv6 tem um comprimento fixo de 40 bytes, em vez

dos variáveis 20 bytes do IPv4.

Suporte para cabeçalho de Extensão e de opções – Mudanças na forma como as

opções do cabeçalho IP são codificados permitem um encaminhamento mais

eficaz. Este suporte permite também que outras opções futuras possam vir a ser

incorporadas dando assim maior flexibilidade.

Capacidade de Flow Labeling – É adicionada uma nova funcionalidade para

identificar fluxos com necessidade de tratamento idêntico, sendo o fluxo

identificado pelo Flow Label e pelo endereço de origem. Esta identificação é feita

recorrendo apenas ao campo Flow Label ao endereço de origem, sem ter de

recorrer á análise profunda dos pacotes.

Suporte para autenticação e privacidade – Foram incluídas novas extensões ao

protocolo que oferecem suporte para autenticação, integridade de dados e

confidencialidade.

Suporte de auto-configuração – Foram incluídos mecanismos destinados a gestão

e configuração de ambientes IP através da utilização de mecanismos de auto-

configuração. Foram definidos mecanismos de auto-configuração com

manutenção de estados e mecanismos sem manutenção de estados.

Suporte para tráfego com garantia de qualidade de serviço;

Suporte para Jumbograms – Possibilidade de enviar pacotes com dimensão

superior a 64Kb. O limite de um pacote Jumbogram é de 4Gb. Esta propriedade é

útil para as redes com grande largura de banda.

Mapeamento de endereços e Nomes;

Encaminhamento



Simplificação do cabeçalho

O cabeçalho IPv6 foi simplificado em relação ao cabeçalho IPv4 no que se refere

aos campos de controlo, porém o seu tamanho passou de 20 a 40 bytes fixos para

qualquer tipo e tamanho de datagrama. Esta alteração deve-se ao facto do tamanho do

endereço passar de 4 para 16 octetos.

Um cabeçalho básico IPv6 contém menos informações do que um cabeçalho IPv4.

Alguns campos do cabeçalho IPv4 foram retirados ou passaram a ser opcionais de forma

a simplificar o tratamento de um pacote comum. Embora os endereços IPv6 sejam 4

vezes maiores que os endereços IPv4, o cabeçalho é apenas duas vezes maior (40

bytes).

Figura 3 - Cabeçalho IPv422

.

Figura 4 - Cabeçalho IPv623

.

22

Figura retirada do RFC 791: http://www.faqs.org/rfcs/rfc791.html 23

Figura retirada da Secção 3 - IPv6 Header Format do RFC 2460: http://tools.ietf.org/html/rfc2460#section-4


http://tools.ietf.org/html/rfc2460#section-4



Simplificações (Campos Removidos):

Campo IHL – A remoção do campo IHL (Internet Header Length) advém do facto

de este campo essencialmente especificar o offset para a porção de dados do

cabeçalho IP. Este conceito, que obrigava a uma informação adicional acerca do

endereço dos dados, foi removido no IPv6.

Campos Identification, Flags e Fragment Offset – Estes três campos são

referentes ao processo de fragmentação que poderá ser necessário utilizar ao

longo de todo o caminho do pacote. São campos de controlo e identificação dos

fragmentos. A fragmentação no IPv6 é feita usando os Cabeçalhos de Extensão e

é feito extremo a extremo, isto é, a fragmentação apenas é efectuada na origem,

usando o protocolo PMTU [11] libertando os routers dessa tarefa, onde descartam

todos os pacotes maiores que o MTU da rede. Isso faz com que não seja

desperdiçado processamento em campos desnecessários quando não ocorre

fragmentação.

Campo Header Checksum – Este campo serve para verificação de erros apenas

no cabeçalho IP. Foi removido devido a um conjunto de situações:

Geralmente os pacotes são corrompidos na camada 2 (Data Link), e essa camada

tem geralmente melhores mecanismos para detecção de erros;

Se mesmo assim existir algum problema, a camada acima poderá solucionar esse

problema.

Se o pacote estiver corrompido, então o nó destino deverá estar preparado para o

recusar, apesar de algum impacto a nível de processamento;

Os meios de transmissão existentes (fibra óptica) são mais fiáveis a assegurar

uma comunicação com menos falhas.

O campo Header Checksum tinha de ser recalculado em cada nó devido à

alteração do campo Hop Limit sobrecarregando os routers.

Campos Options e Padding - O campo Padding serve para completar o pacote

(tamanho múltiplo de 32 bits). Em relação ao campo Options, tem alguma

utilidade a nível de encaminhamento, mas raramente é utilizado. O IPv6 junta um

pouco a funcionalidade deste campo à do campo Protocol e utiliza-os no conceito

dos Cabeçalhos de Extensão. De certa forma algumas funcionalidades do campo



Options são passadas para os Cabeçalhos de Extensão. O campo Protocol é

substituído pelo Next Header, parecido com o campo Protocol do IPv4, que

interliga todos os cabeçalhos de Extensão.

Campos revistos:

Substituição do campo Type of Service – Este campo era o responsável por

algum QoS que pudesse existir no IPv4, no entanto nunca foi adoptado pelos

routers, principalmente por ser muito pequeno. No IPv6 o QoS divide-se em dois

campos: o campo Traffic Class e o campo Flow Label; o primeiro é direccionado

ao catálogo de tráfego (DiffServ) e o segundo à geração de fluxos prioritários

(IntServ).

Substituição do campo Total Length – Este campo indica o tamanho total do

pacote, incluindo os dados. Foi substituído pelo campo Payload Length que

representa o tamanho do resto do pacote que se segue ao cabeçalho IPv6, ou

seja, o tamanho do cabeçalho IPv6 não é neste caso necessário, pois o

cabeçalho tem tamanho fixo.

Substituição do campo Time to Live – A substituição desde campo é devido a

questões de interpretação. Ao contrário do que o nome indica, este campo é

medido em saltos e não em tempo, pelo que a designação Hop Limit vem corrigir

esta pequena confusão. Nada como ter o nome correspondente à função que

desempenha.

Substituição do campo Protocol – Apesar de o nome ser diferente, o novo

campo Next Header funciona de uma forma semelhante ao campo Protocol. No

IPv4 indicava o protocolo da camada acima que ia ser encapsulado. No IPv6

indica o protocolo de camada superior ou o Cabeçalho de Extensão seguinte. É

como que um campo que interliga todos os Cabeçalhos de Extensão. Quando não

se verificarem mais Cabeçalhos de Extensão, então indicará o protocolo da

camada acima correspondente, tal como o campo Protocol.

Alteração dos campos Source Address e Destination Address – Esta

alteração é a mais evidente e consiste na passagem dos endereços de 32 bits

para 128 bits. Verifica-se então, nas alterações efectuadas, uma maior

preocupação em relação a questões como a eficiência e a simplicidade. Eficiência

na medida em que só é processado aquilo que é realmente obrigatório.


Capítulo III

Ferramenta de conformidade da especificação IPv6


Para a realização dos testes de conformidade do IPv6, será utilizado uma ferramenta

de teste designado por TAHI IPv6 Suite teste de conformidade, desenvolvida pelo

projecto TAHI com a finalidade de desenvolver e fornecer mecanismos que permitam

verificar a conformidade da tecnologia IPv6 em relação aos RFC´s.

Esta ferramenta consiste em duas componentes, numa plataforma de teste e num

conjunto de scripts de teste. Sendo a plataforma de teste designada por ferramenta de

teste de conformidade IPv6 (―IPv6 Conformance Test Tool‖) e o script de testes

designado por Pacote de Programa de teste de conformidade do IPv6 (―IPv6

Conformance Test Program Package‖)

O IPv6 Conformance Test Tool (v6eval) é um pacote de ferramentas que permite a

execução de testes de conformidade para o IPv6. Essas ferramentas permitem:

Definir qualquer pacote a ser enviado;

Definir qualquer pacote a ser recebido;

Programar as acções anteriores em qualquer ordem usando scripts Perl.

IPv6 Conformance Test Program Package (ct) é um conjunto de scripts contendo

testes de conformidade IPv6 em relação a grande parte dos RFC´s IPv6 existentes.

Capítulo III – Ferramenta de conformidade da especificação IPv6


Na tabela seguinte serão listados alguns scripts contendo um conjunto de testes

disponíveis por categoria.

Nome Categoria do teste

Spec RFC2460: Especificação do IPv6

Icmp RFC2463: ICMPv6 para o IPv6

Nd RFC2461: Descobrimentos de vizinhos (Neighbor Discovery)

Pmtu RFC1981: Path MTU Discovery for IPv6

IPsec RFC2401: Security Architecture for the IP

Tabela 1 - Script de teste disponível

Ambos os pacotes ―ct‖ e ―v6eval‖ podem ser obtidos do site: http://www.tahi.org

Para a realização dos testes de conformidade, serão utilizadas algumas distribuições

Linux: FreeBSD, Ubuntu e Centos. Em que a distribuição FreeBSD será utilizada como

o nó de teste e será designado por TN, e as outras distribuições serão utilizadas como

nós em teste e serão designados por NUT. Onde o TN será o nó que realiza o teste e o

NUT será o nó testado.

O TN e o NUT terão um ficheiro de configuração designado respectivamente de tn.def e

nut.def. Nestes ficheiros encontram-se definidos configurações específicos referentes a

cada nó.

Os testes podem ser executados de forma manual recorrendo à linha de comando ou de

forma automática recorrendo a um programa de execução automática de testes

(autorun). Para a realização deste trabalho os testes serão executados de forma

automática recorrendo a um programa de execução automática de testes (autorun). A

execução automática dos testes consiste em enviar um conjunto de pacotes e verificar as

respostas. Os testes a serem realizados são especificados no ficheiro Index, e o

programa de teste ao executar os testes verifica o ficheiro de configuração do TN e do

NUT, e com base nesses ficheiros realiza os testes anteriormente especificados e os

resultados verificados serão listados num ficheiro HTML designado de ―./index.html‖,

como se ilustra na figura seguinte:

http://www.tahi.org/



IndexReport Index

(HTML)Autorun

Test scriptPacket.def

Exec with Option Status

Figura 5 - Programa de execução Automática

1.2. Procedimento comum de limpeza dos testes

A limpeza da cache de vizinhança (Neighbor Cache) do NUT (nó em teste) após cada

execução de um teste é um procedimento comum em todos os testes. Este procedimento

consiste na transição das entradas da cache de vizinhança do NUT criada durante a

execução do teste para o estado NO Neighbor Cache Entry e a remoção de qualquer

entrada do router por defeito e a também da lista de prefixo no caso do NUT ser um

router.

1.3. Definição da estrutura do pacote

O pacote a ser enviado/recebido é criado usando a API Perl, através da definição de

cada um dos seus componentes:

Frame – composto pelos seguintes elementos (Header, Packet);

Pacote – pacote_IPv6, pacote_IPv4, pacote_ARP, pacote_RARP;

Payload – dados.

Ao executar o teste de conformidade automaticamente, as seguintes regras se aplicam

aos nomes de arquivo de scripts.

A extensão é ". seq".



Os scripts de teste encontram-se definidos dentro das directorias utilizados para

classificar os arquivos de acordo com o RFC, não sendo necessário a definição

manual dos pacotes a ser enviado.

A tabela seguinte lista os valores possíveis de retorno da execução dos scripts de teste.

Código Constante Descrição

0 $exitPass PASS

1 $exitIgnore Terminação normal

2 $exitNS Ainda não suportado

3 $exitWarn Não pode ser identificado como uma falha porque a especificação não é clara

4 $exitHostOnly Teste suportado apenas por host

5 $exitRouterOnly Teste suportado apenas por router

32 $exitFail Fail

64 $exitFatal Erro interno

Tabela 2 - Script Status Code

1.4. Exemplos de Funções Disponíveis na API

Existem disponível um conjunto de funções:

Funções Disponíveis na API

vStop()

vClear()

vCapture()

vSend()

vRecv()

vLog ()

vRemote ()

vErrmsg ()

vRoundoff ()

vSleep ()

Tabela 3 - Funções disponíveis na API



Na tabela seguinte serão exemplificadas a algumas das funções definidas anteriormente

vSend ()

Descrição Permite especificar um pacote a ser enviado para a interface especificada.

Argumento sub vSend($@) {my (

$ ifname, # nome da interface do target

@ Frames, # nome pacote a ser enviado

) = @_;

Valor de retorno

É retornado um valor de hash. A key e o valor é o seguinte: SentTimeN

Tabela 4 - Exemplo vSend

vRecv

Descrição O teste é realizado para determinar quando é que um determinado pacote pode ser recebido da interface especificada

Argumento sub vRec($$$$@) {my (

$ ifname, # nome da interface do target

$ timeout,

$ seektime, # procurar pelo pacote a partir do tempo

$ count, # esperar por quantas frames

@ Frames, # nome da frame a ser enviado

) = @_;

Valor de retorno

É retornado um valor de hash. A key e o valor é o seguinte: = 0 – Terminação normal = 1 – Terminação com Timeout = 2 – o pacote especificado foi recebido, mas o pacote esperado

não foi recebido >=3 – erro

Tabela 5 - Exemplo vRec


Capítulo IV

Descrição dos testes IPv6 realizados

1. Considerações Gerais

Os testes realizados neste capítulo abrangem a especificação base do IPv6,

definidos no RFC 2460, bem como o processamento das Opções e Cabeçalhos de

Extensões, em particular o Hop-by-Hop Option, Destination Option.

São especificados o cabeçalho IPv6 e os cabeçalhos de Extensão e Opções. Também

serão abordados questões relacionados com o tamanho do pacote, a semântica do Flow

Label e Traffic Classes.

Em relação à especificação base do IPv6 estes testes têm a finalidade de verificar

a disponibilidade da implementação do IPv6, onde serão verificados se o nó em teste

(NUT) processa correctamente os campos: Version, Traffic Class, Flow Label, Payload

Length, Next Header e Hop Limit. Também será verificado se o nó em teste (NUT)

transmite a mensagem ICMPv6 apropriada em resposta à recepção de um campo

inválido ou desconhecido.

Em relação ao processamento das Opções e Cabeçalhos de Extensões, em

particular o Hop-by-Hop Option, Destination Option os testes realizados têm a finalidade

de verificar se o nó em teste (NUT) processa e gera correctamente o campo Header

Extension Length do Cabeçalho de Extensão, os campos Option Type e Option Data

Length do campo Option. Será igualmente, verificado o nó em teste (NUT) se envia a

mensagem ICMPv6 apropriada em resposta ao envio de pacotes, com campos inválidos

ou desconhecidos.

Capítulo IV – Descrição dos testes IPv6 realizados


2. Testes em relação à especificação base do IPv6

2.1. Teste ao Campo Versão (Version Field)

O campo Versão tem 4 bits que indicam a versão do protocolo. No caso do IPv6 é o

número 6. A versão 5 não poderia ser usada porque já havia sido atribuída para um

protocolo experimental.

2.1.1. Objectivo

O objectivo deste teste consiste em verificar se o nó em teste (NUT) processa

correctamente o campo Versão (Version) de um pacote recebido.

2.1.2. Corpo do Teste

O nó de teste (TN) envia dois pacotes Echo Request para o nó em teste (NUT),

em que o primeiro pacote contém o campo versão inválido (campo versão igual a 5) e o

segundo pacote um pacote valido contendo o campo versão igual a 6.

Para a realização do teste o programa de execução automática utilizou o script

IH_BadIPv6Ver.seq onde se encontram definidos funções que permitem gerar pacotes

Echo Request validos/inválidos.

Na tabela seguinte encontram-se listadas as funções usadas para gerar os dois pacotes

Echo Request.

Funções definidas no script IH_BadIPv6Ver.seq

Echo Request inválido FEM_icmp6_echo_request(

echo_request_wrong_v6ver,

_HETHER_tn2nut,

{Version=5;},

{

Identifier = PING_ID;

SequenceNumber = PING_SN;

payload = echo_data8;

}

)

Echo Request válido FEM_icmp6_echo_request(

echo_request,

_HETHER_tn2nut,

{},

{




}



)

Neighbor Solicitation FEM_icmp6_ns(

ns,

_HETHER_nut2tnsolnode,

{

_SRC(oneof(nutv6(),

nut2v6(_GLOBAL0_UCAST_PRFX,

_GLOBAL0_UCAST_PRFXLEN)));

_DST(_IPV6_SOLNODE_MCAST(tnv6()));

HopLimit = 255;

},

{

TargetAddress = tnv6();

option = _SLLOPT_nut;

}

)

Tabela 6 – Funções do script IH_BadIPv6Ver.seq

Na tabela seguinte encontram-se listados as estruturas dos pacotes gerados pelas

funções anteriores.

Send Echo Request (but invalid version)

Frame_Ether (length:70) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:56) | | Hdr_IPv6 (length:40) | | | Version = 5 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 16 | | | NextHeader = 58 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37888 calc(37888) | | | Identifier = 65535 | | | SequenceNumber = 1 | | | Payload (length:8) | | | | data = 01020304 05060708

Send Echo Request


Neighbor Solicitation



Frame_Ether (length:86) | Hdr_Ether (length:14) | | DestinationAddress = 33:33:ff:00:01:00 | | SourceAddress = 00:0c:29:1f:b2:72 | | Type = 34525 | Packet_IPv6 (length:72) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 32 | | | NextHeader = 58 | | | HopLimit = 255 | | | SourceAddress = fe80::20c:29ff:fe1f:b272 | | | DestinationAddress = ff02::1:ff00:100 | | ICMPv6_NS (length:32) | | | Type = 135 | | | Code = 0 | | | Checksum = 49505 calc(49505) | | | Reserved = 0 | | | TargetAddress = fe80::200:ff:fe00:100 | | | Opt_ICMPv6_SLL (length:8) | | | | Type = 1 | | | | Length = 1 | | | | LinkLayerAddress = 00:0c:29:1f:b2:72

Tabela 7 - Pacotes gerados pelo script IH_BadIPv6Ver.seq

As sequências de acções executadas pelo programa de execução automática no

decorrer do teste ao campo versão encontram-se listadas na tabela seguinte:

Nº Sequências de acções realizados pelo Conformance Tool

Descrição

1 Start

2 Start Capturing Packets (Link0)

3 vSend(Link0,echo_request_wrong_v6ver) Envio do pacote Echo Request com o

campo versão inválido

4 vRecv(Link0,) timeout:5 cntLimit:0 seektime:0

vRecv() return status=1

Não recebe nenhum Echo Replay a acção vRecv retorna o status 1 que é o valor correspondente ao Timeout

5 vSend(Link0,echo_request)

Send Echo Request

Envio do pacote Echo Request com o

campo versão válido

6 vRecv(Link0,ns echo_reply) timeout:5 cntLimit:0 seektime:0

Recv Neighbor Solicitation

Recebe o Neighbor Solicitation enviado

pelo NUT

7 vSend(Link0,na)

Send Neighbr Advertisement

Envio do Neighbor Advertisement

8 vRecv(Link0,echo_reply) timeout:5 cntLimit:0 seektime:0

Recv Echo Reply (Link-Local Address)

Recebe o Echo Replay

9 OK

10 End

Tabela 8 - Acções executadas no teste ao campo Versão



Na acção nº 7 o NUT envia um Neighbor Solicitation após o envio do Echo Request

valido uma vez que no final do teste anterior foi executado o procedimento comum de

limpeza o que fez com que a cache de vizinhança do NUT fosse limpa.

2.1.3. Resultado esperado do Teste

O NUT deve ignorar o Echo Request inválido, não gerando nenhuma mensagem

pacote inválido e deve apenas responder com Echo Replay ao Echo Request válido.

2.2. Teste ao campo Traffic Class

O campo Traffic Class tem 8 bits e substitui o campo tipo de serviço em IPv4.

Facilita a manipulação de dados em tempo real e de todos os outros dados que requerem

uma manipulação especial. Os nós que originam um pacote devem identificar diferentes

classes ou prioridades de pacotes IPv6, usando o campo Traffic Class do cabeçalho IPv6

para fazer essa identificação. Este campo também é usado pelos routers para identificar

e distinguir entre classes ou prioridades diferentes dos pacotes IPv6.

Os seguintes requisitos gerais que se aplicam ao campo Traffic Class: [10]

A interface usada pelo nó IPv6 deve fornecer o valor dos bits Traffic Class

para o protocolo de camada superior. Os bits Traffic Class devem constar

nos pacotes originados pelo protocolo da camada superior. O valor por

defeito deve ser zero para todos os 8 bits.

Nós que suportam alguns dos bits Traffic Class ou todos podem alterar o

valor desses bits. Podendo apenas alterar os valores dos pacotes que

originam, enviam ou recebem de acordo com o uso específico desses bits.

Os nós devem ignorar e não alterar qualquer bit do campo Traffic Class

que não suportam o seu uso.

O valor dos bits do campo Traffic Class de um pacote recebido pode não

ser igual ao valor enviado pelo emissor. Logo um protocolo da camada

superior não deve assumir que o valor dos bits do campo Traffic Class de

um pacote recebido



2.2.1. Objectivo

O objectivo deste teste consiste em verificar se o NUT processa correctamente o

campo Traffic Class de um pacote recebido e gera um valor válido no pacote transmitido.


O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com

o valor do campo Traffic Class igual a 0x12 (formato hexadecimal), que equivale a 18

(formato decimal), que é diferente de zero.


TC_NonZeroToHost.seq onde se encontram definidas algumas funções entre elas uma

que permite gerar um pacote Echo Request com o campo Traffic Class diferente de zero.

Na tabela seguinte encontra-se listada a função descrita anteriormente.

Funções definidas no script TC_NonZeroToHost.seq

Echo Request com campo Traffic Class diferente de zero

FEM_icmp6_echo_request(

echo_request,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

TrafficClass = 0x12;

},

{


}

)

Tabela 9 - Função do script TC_NonZeroToHost.seq

O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definido

no script ―TC_NonZeroToHost.seq‖ é semelhante ao pacote gerado pelo script

―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Traffic

Class que é igual a 18.


decorrer do teste ao campo Traffic Class encontram-se listadas na tabela seguinte:


1 Start





Send Echo Request (Non-Zero Traffic Class)

4 vRecv(Link0,ns echo_reply_tc echo_reply) timeout:5 cntLimit:0 seektime:0 Recv Echo Reply (Zero Traffic Class)

5 OK

6 End

Tabela 10 - Acções executadas no teste ao campo Traffic Class


O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido. Caso

o NUT suporte um uso específico do campo Traffic Class, o campo Traffic Class do Echo

Replay pode ser diferente de zero, caso contrário o campo Traffic Class deverá ser zero

2.3. Teste ao campo Flow Label

Campo que ocupa 20 bits no cabeçalho IPv6 e que permite a identificação de fluxos24

de pacotes. Por omissão o seu valor é zero (0), qualquer valor diferente de zero indicará

uma diferenciação de fluxo.

Este campo indica se um pacote pertence a uma sequência específica de pacotes entre a

origem e o destino, requerendo tratamento especial por parte dos routers IPv6

intermédios.

Podem existir múltiplos fluxos activos de uma origem para um destino, como também

pode existir tráfego que não é associado a qualquer fluxo. Um fluxo é exclusivamente

identificado pela combinação de um endereço de origem e uma etiqueta de fluxo não

nula. Pacotes que não pertencem a um fluxo contêm uma etiqueta de fluxo com valor

nulo.

Aos nós e routers que não suportam funções de Flow Label é exigido que preencham o

valor do campo Flow Label com zero (0) quando geram um pacote, ao reencaminhar um

pacote o valor do campo Flow Label deve ir inalterado e ao receber um pacote devem

ignorar o campo.

24

Sequência de pacotes enviados por um determinado emissor para um destino específico para o qual, o

originador deseja um tratamento especial por parte dos routers intervenientes no encaminhamento de pacotes.



2.3.1. Objectivo


campo Flow Label de um pacote recebido e gera um valor válido no pacote transmitido.



o valor do campo Flow Label igual a 0x34567 (formato hexadecimal), que equivale a

214375 (formato decimal).


FL_NonZeroToHost.seq onde se encontram definidas funções que permitem gerar

pacotes Echo Request com o campo Flow Label diferente de zero. A função utlizada para

gerar o pacote Echo Request é semelhante à função descrita na tabela 8

(TC_NonZeroToHost.seq), com a diferença num dos parâmetros de entrada onde foi

substituído o parâmetro (Traffic Class = 0x12;) pelo (Flow Label = 0x34567;) como se

pode ver na tabela seguinte:

Funções definidas no script FL_NonZeroToHost.seq

Echo Request com campo Flow Label diferente de zero


echo_request,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

FlowLabel = 0x34567; // 20bit

},

{


}

)

Tabela 11 - Função do script FL_NonZeroToHost.seq

O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definida

no script ―FL_NonZeroToHost.seq‖ é semelhante ao pacote gerado pelo script

―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Flow

Label que é igual a 0x34567.


decorrer do teste ao campo Flow Label encontram-se listadas na tabela seguinte:




1 Start



Send Echo Request (Non-Zero Flow Label)

4 vRecv(Link0,ns echo_reply_fl echo_reply) timeout:5 cntLimit:0 seektime:0

Recv Echo Reply (Zero Flow Label)

5 OK

6 End

Tabela 12 - Acções executadas no teste ao campo Flow Label

2.3.3. Resultado do Teste

O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido. Caso

o NUT suporte o uso do campo Flow Label, o campo Flow Label do Echo Replay pode

ser diferente de zero, caso contrário o campo Flow Label deverá ser zero.

2.4. Teste ao campo Payload Length

O campo Payload Length indica em bytes, o tamanho total do pacote IP excluindo o

cabeçalho, ou seja, representa o número de bytes que se seguem ao cabeçalho. O

tamanho máximo do pacote IP é de 65.535 bytes, para valores superiores, é atribuído o

valor 0 e a opção Jumbo payload é usada nas opções Hop-by-Hop do cabeçalho de

extensão.

2.4.1. Objectivo


campo Payload Length de um pacote recebido.



o valor do campo Payload Length igual 15.




PL_OddToHost.seq onde se encontram definidas algumas funções entre elas uma que

permite gerar um pacote Echo Request com o campo Payload Length diferente de zero.


Funções definidas no script PL_OddToHost.seq

Echo Request com campo Payload Length diferente de zero


echo_request,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

},

{




}

)

Tabela 13 - Função do script PL_OddToHost.seq

Na tabela seguinte encontra-se listado o pacote Echo Request gerado pela função

definida anteriormente.

Send Echo Request


Tabela 14 - Pacote gerado pelo script PL_OddToHost.seq




decorrer do teste ao campo Payload Length encontram-se listadas na tabela seguinte:


1 Start



Send Echo Request (Odd Payload Length)


Recv Echo Reply (Odd Payload Length)

5 OK

6 End

Tabela 15 - Acções executadas no teste ao Campo Payload Length


O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido.

2.5. Teste campo Next Header irreconhecível

O campo Next Header é um campo de 8 bits, que indica o tipo possível do

cabeçalho de extensão que segue o cabeçalho IPv6. Este campo indica quer o tipo do

primeiro cabeçalho de extensão (caso exista), quer o protocolo na camada acima PDU

(tais como TCP, UDP, ICMPv6). No caso de ser indicado o protocolo da camada acima

PDU, este campo usa os mesmos valores usados no campo do protocolo IPv4. Na tabela

seguinte estão listadas alguns dos valores possíveis que este campo pode assumir:

Valor Descrição

0 Num cabeçalho IPv4: reservado e não usado Num cabeçalho IPv6: a seguir vem um cabeçalho Hop-by-Hop Option

1 Internet Control Message Protocol ICMPv4

2 Internet Group Management Protocol IGMPv4

4 IP dentro de IP (encapsulamento)

6 TCP

8 Exterior Gateway Protocol (EGP)

9 IGP – qualquer Gateway interior privado (usado pela Cisco para IGRP)

17 UDP

41 IPv6

43 Cabeçalho de Routing



44 Cabeçalho de Fragmentação

50 Cabeçalho Encrypted Security Payload

51 Cabeçalho Authentication

58 ICMPv6

59 Não existe Next Header para IPv6

60 Cabeçalho Destination Options

134-254

Sem Atribuição

255 Reservado

Tabela 16 - Alguns valores25

possíveis que o campo Next Header pode assumir

O não processamento de um cabeçalho de Extensão por parte dum nó, por este não

conseguir identificar o valor do campo Next Header, implica descartar pacote e o envio de

uma mensagem de erro (ICMPv6) ao originador com o campo Code (código) a 1

("Unrecognized Next Header Type encountered") e o campo Pointer contendo o offset do

valor irreconhecível do pacote original.

2.5.1. Objectivo

O objectivo deste teste consiste em verificar o não processamento de um

cabeçalho de Extensão por parte do NUT, por este não conseguir identificar o valor no

campo Next Header do cabeçalho IPv6, e também verificar se o NUT gera a resposta

apropriada ao receber um pacote com o campo Next Header do cabeçalho IPv6

irreconhecível.


O nó de teste (TN) envia um pacote com o valor do campo Next Header do

cabeçalho IPv6 irreconhecível.


IH_UnrecognizedNextHeader.seq onde se encontram definidas algumas funções entre

elas uma que permite gerar um pacote com o valor do campo Next Header do cabeçalho

IPv6 irreconhecível.

25

A lista completa do Protocol Numbers encontra-se definida no site IANA: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml




Funções definidas no script IH_UnrecognizedNextHeader.seq

FEM_hdr_ipv6_exth(

unrecog,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

NextHeader = 128; //

unrecognized value

},

{

header = _HDR_IPV6_NAME(unrecog);

upper = apl;

}

) Tabela 17- Função do script IH_UnrecognizedNextHeader.seq

Na tabela seguinte encontram-se listadas as estruturas dos pacotes gerados pela função

anterior.

Pacote contendo o campo Next Header do cabeçalho IPv6 irreconhecível

Send Unrecognized Next Header in IPv6 Header at 21:33:36 Frame_Ether (length:64) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:50) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 10 | | | NextHeader = 128 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Payload (length:10) | | | data = 00000000 00000000 0000

Tabela 18 - Pacote gerado pelo script IH_UnrecognizedNextHeader.seq




1 Start


3 vSend(Link0,unrecog)

Send Unrecognized Next Header in IPv6 Header

4 vRecv(Link0,ns icmperr) timeout:5 cntLimit:0 seektime:0



Recv ICMP Error (Parameter Problem, unrecognized Next Header type encountered)

9 OK

10 End

Tabela 19 - Acções executadas no teste ao campo Next Header


O NUT ao receber um pacote com o valor do campo Next Header do cabeçalho IPv6

irreconhecível, deve gerar uma mensagem de erro ICMPv6 (Parameter Problem

message) com o valor do campo Code a 1 (Unrecognized Next Header Type

encountered) e com o campo Pointer a 0x06 (offset do campo Next Header).

2.6. Teste campo Hop Limit igual a zero

Campo que indica o número máximo de nós intermédios que um pacote pode

percorrer até alcançar o destino. Este campo é semelhante ao campo TTL, mas agora

com a medida em saltos (Hop) e não em segundos. Cada valor unitário do Hop Limit

significa uma passagem por um router, um salto. Sendo decrementado em cada salto, e

quando o pacote atinge o valor 0 é descartado pelo router que envia uma mensagem

ICMPv6 Time Exceeded-Hop Limit Exceeded in transit para o destino e descarta o pacote

2.6.1. Objectivo

Verificar se um nó processa correctamente o campo Hop Limit de um pacote

recebido e gera um valor válido no pacote transmitido.


O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com o valor

do campo Hop Limit igual zero e o NUT deve gerar o pacote Echo Replay correspondente

com o valor do campo Hop Limit diferente de zero (Hop Limit default 64).


“HL_ZeroToHost.seq‖ onde se encontram definidas algumas funções, entre elas uma



que permite gerar pacotes Echo Request com o campo Hop Limit igual zero. A função

utlizada para gerar o pacote Echo Request é semelhante à função descrita na tabela 8

(TC_NonZeroToHost.seq), com a diferença num dos parâmetros de entrada onde foi

substituído o parâmetro (Traffic Class = 0x12;) pelo (Hop Limit = 0;) como se pode ver na

tabela seguinte:

Funções definidas no script HL_ZeroToHost.seq

Echo Request com campo Hop Limit diferente de zero


echo_request,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

HopLimit = 0;

},

{


}

)

Tabela 20 - Função do script HL_ZeroToHost.seq

O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definida

no script ―HL_ZeroToHost.seq‖ é semelhante ao pacote gerado pelo script

―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Hop Limit

que é igual a zero.


decorrer do teste ao campo Hop Limit encontram-se listadas na tabela seguinte:


1 Start



Send Echo Request (Hop Limit 0)


Recv Echo Reply

9 OK

10 End

Tabela 21 - Acções executadas no teste ao campo Hop Limit




O NUT ao receber um pacote Echo Request com o campo Hop Limit a zero, deve gerar o

pacote Echo Replay correspondente, com o valor do campo Hop Limit maior do que zero

(Hop Limit default 64).

3. Testes referentes ao processamento das Opções e Cabeçalhos

de Extensões

No IPv6 existe um novo conceito de uma lista ordenada de Cabeçalhos de Extensão

(Extension Headers) que permite que os routers apenas analisem aquilo que é

necessário para o normal funcionamento da rede.

Os cabeçalhos de Extensão vem substituir o campo Options do IPv4, com vantagens,

pois enquanto este último estava limitado a 40 bytes no IPv6 o limite é apenas o tamanho

do pacote. Este campo permite assim adicionar ao cabeçalho fixo do IPv6

funcionalidades para comunicações ponto a ponto para além das básicas como o

encaminhamento de pacotes, ToS e o QoS baseado na Flow Label.

Os cabeçalhos de Extensão são os responsáveis por grande parte da eficiência do IPv6

(a utilização dos Cabeçalhos de Extensão, tem como finalidade aumentar a velocidade de

processamento dos routers, no sentido em que o único Cabeçalho de Extensão

processado em cada router é o Hop-by-Hop, os demais são tratados apenas pelo nó

identificado no Endereço Destino do cabeçalho base), podem ser vistos numa localização

intermédia, existente entre a camada de rede e a camada de transporte, não fazendo

parte do normal cabeçalho IPv6, apesar de o complementarem. Podem existir zero, um

ou mais Cabeçalhos de Extensão entre o cabeçalho IPv6 e o cabeçalho do protocolo da

camada superior. No caso de existirem vários, interligam-se todos uns com os outros

através do campo Next Header. Os Cabeçalhos de Extensão suportam funções

específicas, pré determinadas (cada um com um código identificador próprio, o Next

Header), e são adicionadas e encadeadas como necessário. Cada Extensão tem um

apontador para a próxima. À última Extensão segue-se o código para o protocolo do nível

seguinte (upper layer), já inserido no payload.



Como se ilustra na figura seguinte:

IPv6 Header Next Header = TCP

TCP Header + Data

IPv6 Header Next Header = Routing

Routing Header Next Header = TCP

TCP Header + Data

IPv6 Header Next Header = Routing

Routing Header Next Header = Fragment

Fragment Header Next Header = TCP

TCP Header + Data

Figura 6 - Cabeçalho de Extensão

Com a excepção do cabeçalho Hop-by-Hop onde a informação transportada é analisada

e processada em todos os nós, os restantes apenas são processados pelo nó destino.

Quando atingido o destino, os Cabeçalhos de Extensão deverão ser sempre processadas

pela ordem indica no pacote IP.

A razão pela qual o Cabeçalho de Extensão Hop-by-Hop é uma excepção, no que

respeita ao tratamento dos Cabeçalhos de Extensão, deve-se ao facto de este campo

transportar informação que deve ser examinada e processada por todos os nós ao longo

do percurso do pacote, incluindo os nós origem e destino.

Actualmente encontram-se já definidos os seguintes Cabeçalhos de Extensão:

Valor Descrição

0 Hop-by-Hop Options Header

43 Routing Header (Tipo 0)

44 Fragment Header

50 Encapsulating Security Payload

51 Authentication Header

59 No Next Header

60 Destination Options Header

Tabela 22 - Cabeçalho de Extensão26

Alguns cabeçalhos de Extensão são bastantes parecidos e completamente novos (Hop-

by-Hop Options header, Destination Options header), outros não trazem novidades

26

A lista de Cabeçalhos de Extensão foi retirada do seguinte endereço: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml



(Authentication header, Encapsulating Security Payload), e outros são um aproveitamento

de alguns conceitos anteriores, misturados com algumas novidades (Routing header,

Fragment header).

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").

Os 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 si.

3.1. Pacote Echo Request usado nos testes

Pacote Echo Request usado nos vários testes encontra-se listado na tabela

seguinte:

Pacote Echo Request

Frame_Ether (length:62) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:48) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 8 | | | NextHeader = 60 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Destination (length:8) | | | | | | (…) | | |

Tabela 23 - Pacote Echo Request usado nos testes ao Cabeçalho de extensão

Será utilizada uma primitiva específica em cada teste, que permitirá gerar um pacote

Echo Request semelhante ao pacote apresentado anteriormente (pode ter variações no

tamanho do pacote IPv6), adicionando o cabeçalho de extensão necessário para a

realização do teste em causa.



3.2. Teste ao campo Next Header do cabeçalho de

Extensão

Se, como resultado do processamento de um cabeçalho, um nó necessitar de

avançar para o próximo cabeçalho mas o valor no campo Next Header não for

reconhecido pelo nó actual, este deve descartar o pacote, ou seja o não processamento

de um cabeçalho de Extensão por parte dum nó, por este não conseguir identificar o valor

no campo Next Header, implica descartar pacote e o envio de uma mensagem de

problema ICMP (ICMP Parameter Problem message) para o nó de origem do pacote.

3.2.1. Objectivo

Verificar se o nó descarta um pacote, por este não conseguir identificar o valor do

campo Next Header do cabeçalho de Extensão pelo facto do valor estar irreconhecível ou

o valor não corresponder ao Next Header esperado e se após descartar o pacote o nó

transmite uma mensagem ICMPv6 (ICMPv6 Parameter Problem message).

3.2.2. Corpo do teste

O nó de teste (TN) envia um pacote com o valor do campo Next Header do

cabeçalho Destination Options header igual a 128 (formato decimal) valor irreconhecível.


“EH_UnrecognizedNextHeader.seq‖ onde se encontram definidas algumas funções

entre elas uma que permite gerar um pacote com o valor do campo Next Header do

cabeçalho de extensão irreconhecível.


Funções definidas no script EH_UnrecognizedNextHeader.seq

FEM_hdr_ipv6_exth(

unrecog,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

},

{

header = _HDR_IPV6_NAME(unrecog);

exthdr = _dst;

upper = apl;

} ) Tabela 24- Função do script EH_UnrecognizedNextHeader.seq



Na tabela seguinte encontra-se listado a estrutura do pacote gerado pela função anterior.

Ao pacote Echo Request base definido anteriormente (ponto 3.1) foi adicionado o

cabeçalho de extensão.

Pacote contendo o campo Next Header do cabeçalho de extensão irreconhecível

| | Hdr_Destination (length:8) | | | NextHeader = 128 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | Payload (length:0) | | | data =

Tabela 25 - Pacote gerado pelo script EH_UnrecognizedNextHeader.seq




1 Start


3 vSend(Link0,unrecog)

Send Unrecognized Next Header in Extension Header

4 vRecv(Link0,ns icmperr) timeout:5 cntLimit:0 seektime:0

Recv ICMP Error Recv ICMP Error (Parameter Problem, unrecognized Next Header type encountered)

9 OK

10 End

Tabela 26 - Acções executadas no teste ao campo Next Header do cabeçalho de extensão

3.2.3. Resultado esperado do teste

O NUT ao receber um pacote com o valor do campo Next Header do cabeçalho

da extensão irreconhecível, deve gerar uma mensagem de erro ICMPv6 (Parameter

Problem message) com o valor do campo Code a 1 (Unrecognized Next Header Type

encountered) e com o campo Pointer a 0x06 (offset do campo Next Header do cabeçalho

Destino).



3.3. Teste à ordem do cabeçalho de extensão Hop-by-Hop

num pacote com mais de um cabeçalho extensão

Da mesma forma que o não processamento de um cabeçalho de Extensão por

parte dum nó, por este não conseguir identificar o valor no campo Next Header, implica

descartar pacote e o envio de uma mensagem de problema ICMP (ICMP Parameter

Problem message) para o nó de origem do pacote. Deverá ser executada a mesma

acção caso for encontrado o valor zero (0) no campo Next Header de qualquer outro

cabeçalho que não seja o cabeçalho IPv6

Quando existem mais do que um cabeçalho de Extensão num pacote, é recomendado

que estes devem aparecer pela seguinte ordem:

Cabeçalho IPv6

Cabeçalho Hop-by-Hop Options

Cabeçalho Destination Options

Cabeçalho de Routing

Cabeçalho Fragment

Cabeçalho de autenticação

Cabeçalho Encapsulating Security Payload

Cabeçalho Destination Options (para o destino

final)

Tabela 27 - Ordem dos Cabeçalhos de Extensão

Os cabeçalhos de extensão devem ser processados, estritamente, na ordem pela qual

aparecem no pacote, com excepção ao cabeçalho Hop-by-Hop, este quando presente,

tem de aparecer imediatamente a seguir ao cabeçalho IPv6, sendo a sua presença

indicada pelo valor zero (0) no campo Next Header do cabeçalho IPv6.



3.3.1. Objectivo

Verificar se o nó descarta um pacote, quando existe mais do que um cabeçalho de

extensão, em que o cabeçalho Hop-by-Hop está presente, e este não aparece

imediatamente a seguir ao cabeçalho IPv6 e se após descartar o pacote o nó transmite

uma mensagem ICMPv6 (ICMPv6 Parameter Problem message).


O nó de teste (TN) envia um pacote Echo Request contendo um cabeçalho de

extensão Hop-by-Hop, em que este não precede o cabeçalho IPv6, isto é o valor do

campo Next Header do cabeçalho IPv6 corresponde a 60, valor este que indica que o

cabeçalho seguinte é o Destination Options Header.


“EH_HBHOptAfterDstOpt.seq‖ onde se encontram definidas algumas funções entre elas

uma que permite gerar um pacote Echo Request contendo o cabeçalho de extensão Hop-

by-Hop depois do cabeçalho de extensão Destination Option Header.


Funções definidas no script EH_HBHOptAfterDstOpt.seq

FEM_icmp6_echo_request_exth(echo_request,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

},

{

header =

_HDR_IPV6_NAME(echo_request);

exthdr = _dst;

exthdr = _hbh;

upper = _ICMPV6_NAME(echo_request);

},

{


}

)

Hdr_Destination _dst {

option = _Pad6; }

Hdr_HopByHop _hbh {

option = _Pad6; } Tabela 28 - Função do script EH_HBHOptAfterDstOpt.seq



Na tabela seguinte encontra-se listado a estrutura do pacote gerado pela função anterior.

Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop depois do

cabeçalho de extensão Destination Option Header

| Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:72) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 32 | | | NextHeader = 60 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Destination (length:8) | | | NextHeader = 0 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708

Tabela 29 - Pacote gerado pelo script EH_HBHOptAfterDstOpt.seq


decorrer do teste à ordem do cabeçalho de extensão Hop-by-Hop encontram-se listadas

na tabela seguinte:


1 Start



Send Echo Request (Hop-by-Hop Options Header after Destination Options Header)


Send Echo Request (Hop-by-Hop Options Header after Destination Options Header)

9 OK

10 End

Tabela 30 - Acções executadas no teste à ordem do cabeçalho de extensão Hop-by-Hop




O NUT ao receber um pacote Echo Request contendo um cabeçalho de extensão

Hop-by-Hop, em que este não precede o cabeçalho IPv6, deverá enviar uma mensagem

de erro ICMPv6 (Parameter Problem message) com o valor do campo Code a 1

(Unrecognized Next Header Type encountered).

3.4. Teste ao cabeçalho de extensão Hop-by-Hop

O Cabeçalho de opções Hop-by-Hop é usado para transportar informação opcional

que deve ser analisada em todos os nós ao longo do percurso de um pacote. É

identificado pelo valor zero (0) no campo Next Header do cabeçalho IPv6. É o cabeçalho

utilizado, quando não existe qualquer estratégia possível de poupança de processamento

a alguns routers, para se obter a função pretendida.

A figura seguinte ilustra o Cabeçalho de Extensão Hop-by-Hop e a respectiva captura.

Options

Next HeaderHeader Extension

Lenght

Figura 7 - Cabeçalho Hop-by-Hop Option

Figura 8 - Captura do Cabeçalho Hop-by-Hop Option



Análise da figura Captura do Cabeçalho Hop-by-Hop Option

A estrutura do cabeçalho é bastante simples. Existe o campo Next Header, depois

um campo responsável pelo tamanho da opção e a respectiva opção. No final, poderá ser

necessário um campo de padding, para completar o tamanho do pacote.

O campo Next Header do cabeçalho IPv6 contém o valor zero (0), correspondente ao

Hop-by-Hop Options, pela numeração definida. De seguida, o campo Next Header do

cabeçalho Hop-by-Hop Options contém o valor para o próximo cabeçalho ICMPv6.

A opção escolhida neste caso foi a Router Alert. [12] Esta opção exclusiva do IPv6

permite dar informações adicionais aos routers de como tratar o pacote. Este tipo de

informação adicional refere-se à informação que não pode ser transportada, no normal

cabeçalho IP.

O Cabeçalho de Extensão Hop-by-Hop é constituído pelos campos Next Header,

Header Extension Length e Options que contém uma ou mais opções. O valor do campo

Header Extension Length é composto pelo número de blocos de 8 bytes contido no

campo Options Extension Header, não incluindo os primeiros 8 bytes. No entanto, para

um Hop-by-Hop Options Header de 8 bytes, o valor do campo Options Extension Header

é 0.

As restantes opções são usadas para garantir limites de 8 bytes. O campo Header

Extension Length é um dos exemplos de como foram feitos os possíveis para optimizar o

processamento de pacotes IPv6 nos routers intermediários.

Uma das primeiras operações a ser feita aos pacotes IPv6 é determinar o tamanho do

seu cabeçalho. Para garantir robustez na implementação de IPv6, os campos cujos

valores validos comecem pelo valor 1 têm de ser verificados para que não permitam que

o valor 0 lhes seja atribuído. Esta verificação tem de ser feita antes de qualquer

processamento adicional seja feito.

Correntemente, o valor 0 é um valor válido e não é preciso efectuar qualquer verificação

de valores inválidos pois o número de bytes no Hop-by-Hop Options Header é calculado

de acordo com a seguinte fórmula: (tamanho do Header Extension + 1) x 8, ou seja, é

sempre adicionado o valor 1 para que nunca ocorra o caso deste campo assumir o valor

0.

Uma opção é um grupo de campos que descreve características específicas de entrega

de pacotes. As opções são enviadas no cabeçalho Hop-by-Hop Options e no cabeçalho



Destination Options. Cada opção está codificada no formato TLV (Type-Length-Value)

que é normalmente utilizado nos protocolos TCP/IP

Option Type Opt Data Len Option Data

Figura 9 - Formato do campo opções.

Podemos observar os seguintes campos:

Option Type – identifica a opção e determina a forma como ela vai ser tratada

pelo nó.

Opt Data Len – O campo Option Data Length indica o número de bytes da opção,

não incluindo os primeiros 8 octetos.

Option Data – campo de dimensão variável que identifica os dados específicos

associados à opção.

Uma opção pode ter necessidade de preparação para garantir que os campos

específicos que se encontram dentro da opção se encontrem nos desejados limites

(múltiplo de 8 bytes). Por exemplo, é mais fácil processar um endereço IPv6 se este

estiver limitado a 8 bytes.

A necessidade de preparação é expressa utilizando a notação xn + y, indicando que essa

opção tem de começar nos limites de um byte igual ao inteiro múltiplo de x bytes mais y

bytes desde o início do cabeçalho Para facilitar a preparação requerida, o

encapsulamento ocorre antes de uma opção e é feita entre cada opção quando existem

múltiplas opções definidas.

A sequência de opções dentro do cabeçalho deve ser processado pela mesma ordem

que aparecem no cabeçalho, o receptor não deve, por exemplo, pesquisar por um tipo de

opção particular dentro do cabeçalho, antes de processar todas as anteriores.



3.5. Teste ao campo Opção Pad1/PadN do cabeçalho de

extensão Hop-by-Hop

Existem duas opções de enchimento (padding Options): Pad1 e PadN que são

usados quando necessários para alinhar as opções subsequentes e para preencherem o

tamanho do cabeçalho com múltiplos de 8 octetos.

As 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 os 8 bits zero. A opção Pad1 é o único caso particular que não respeita

a estrutura geral das opções.

Quando seja necessário 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).

As opções de enchimento (padding Options) devem ser reconhecidas por todas as

implementações IPv6:

Pad1 Option (alignment requirement: none)

0

Figura 10 – Valor do tipo de opção Pad1 de um pacote IPv6

O formato da opção Pad1 é um caso especial – que não tem o comprimento nem o valor

do campo.

É utilizado para inserir um octeto de enchimento para a área ―Options‖ do cabeçalho. No

caso de ser preciso mais do que um octeto de enchimento, deve ser utilizado a opção

PadN Option, ao invés de múltiplas opções Pad1.

PadN Option (alignment requirement: none)

1 Opt Data Len Option Data

Figura 11 - PadN Option.



A opção PadN é usada para inserir dois ou mais octetos de enchimento na área Options

do cabeçalho. Para N octetos de enchimento, o campo de dados Opt Len contém o N-2,

e Option Data consiste em N-2 valor zero octetos.

3.5.1. Objectivo

Verificar se um nó processa correctamente as opções e age de acordo com os 2

bits de maior ordem da opção


Para realizar o teste Pad1 o nó de teste (TN) envia um pacote Echo Request

contendo um cabeçalho de Extensão Hop-by-Hop Options com seis opções Pad1.

Para realizar o teste PadN o nó de teste (TN) envia um pacote Echo Request

contendo um cabeçalho de Extensão Hop-by-Hop Options com 6 bytes PadN Option.

Para a realização do teste Pad1 e PadN o programa de execução automática utilizou o

script “HH_Pad1.seq‖ e ―HH_PadN.seq‖, onde se encontram definidas algumas

primitivas que permitem gerar um pacote Echo Request contendo um cabeçalho de

Extensão Hop-by-Hop Options com seis opções Pad1 e com 6 bytes PadN Option

respectivamente.


Primitivas usadas para gerar o cabeçalho Hop-by-Hop Pad1/PadN

Primitivas #define OPT_PAD opt_Pad1

#define OPT_PAD opt_PadN

Echo Request Pad1 %pktdesc = (

echo_request_ex => 'Send Echo Request (Hop-

by-Hop Options:Pad1)' );

Echo Request PadN %pktdesc = (

echo_request_ex => 'Send Echo Request (Hop-

Echo Request Pad1by-Hop Options:PadN)' );

Tabela 31 - Função do script EH_HBHOptAfterDstOpt.seq



Na tabela seguinte encontram-se listados as estruturas dos pacotes gerados pelas

funções anteriores.

Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop Pad1

Frame_Ether (length:78) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:64) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 24 | | | NextHeader = 0 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708

Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop PadN

Frame_Ether (length:78) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:64) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 24 | | | NextHeader = 0 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708

Tabela 32 - Pacote gerado pelo script HH_Pad1.seq e HH_PadN.seq



Como se pode ver no pacote Hop-by-Hop PadN apresentado na tabela anterior, para N

octetos de enchimento (N = 6), o campo de dados Opt Len contém o N-2, ou seja o valor

do campo Opt Len é igual a 4.


decorrer do teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop

encontram-se listadas na tabela seguinte:

Sequências de acções realizados pelo Conformance Tool

Nº Pad1 PadN

1 Start


3 vSend(Link0,echo_request_ex)

Send Echo Request (Hop-by-Hop

Options:Pad1)

vSend(Link0,echo_request_ex)

Send Echo Request (Hop-by-Hop Options:PadN)

4 vRecv(Link0,ns echo_reply echo_reply_ex)

timeout:5 cntLimit:0 seektime:0

Recv Echo Reply

vRecv(Link0,ns echo_reply echo_reply_ex)

timeout:5 cntLimit:0 seektime:0

Recv Echo Reply

5 OK

End

Tabela 33 - Acções executadas no teste ao campo Opção Pad1/PadN


O NUT ao receber um pacote Echo Request contendo um cabeçalho Hop-by-Hop

com seis Pad1 Option ou com 6 bytes PadN Option, deverá responder com um Echo

Replay para o TN.



3.6. Teste à codificação dos dois bits de maior ordem do

indicador Option Type

Os identificadores Option Type são internamente codificados no formato TLV

(Type-Length-Value) de tal forma que os dois bits de maior ordem (bits mais

significativos) especificam a acção que deve ser tomado caso o nó que processa o

pacote não reconheça o tipo da opção:

Valor Acção

00 Ignorar a opção e continuar o processamento do cabeçalho

01 Descartar o pacote

10 Descartar o pacote e, independentemente do endereço de destino ser um endereço

Multicast ou não enviar uma mensagem ICMP (ICMP - Parameter Problem), com o

campo Code 2, a mensagem deve ser enviada ao endereço Origem do pacote

11 Descartar o pacote e, e enviar uma mensagem ICMP (ICMP - Parameter Problem)

apenas se o endereço de destino não for um endereço Multicast

Tabela 34 - Identificadores Option Type

O terceiro bit de maior ordem (3º bit mais significativo) do indicador Option Type

especifica se durante o percurso o campo Option Data pode ou não sofrer alterações

(mudar de rota para o destino final). O valor zero (0) indica que não se pode mudar de

rota e um (1) indica que pode mudar de rota. Esta "flag" é importante na presença de um

cabeçalho de extensão de autenticação. Quando este bit possui valor, para efeitos de

validação os dados respeitantes a esta opção serão considerados zero.

Valor Acção

0 Opção de dados não mudar de rota

1 Opção de dados pode mudar de rota

Tabela 35 – Terceiro bit mais significativo do Option Type

Os três bits de maior ordem (os 3 bits mais significativos) acima descritos devem ser

tratados como parte da Option Type, e não de forma independente da Option Type. Ou



seja, uma determinada opção é identificada pelo seu identificador Option Type que são 8-

bit, não apenas pelos 5 bits de menor ordem da Option Type.

A mesma numeração do Option Type é usada tanto para o cabeçalho Hop-by-Hop como

para o cabeçalho Destination Options. No entanto, a especificação de uma determinada

opção pode restringir sua utilização para apenas um desses dois cabeçalhos.

Opções individuais (individual Option) podem ter requisitos de alinhamento específicos,

para garantir valores múltiplos de 8 octetos no campo Option Data. Por exemplo, é mais

fácil processar um endereço IPv6 se este estiver limitado a 8 bytes.

3.6.1. Objectivo

Verificar se um nó processa correctamente as opções e age de acordo com os 2 bits

de maior ordem do identificador Option Type.


O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT),

contendo um cabeçalho de Extensão Hop-by-Hop Options com o valor do campo Option

Type desconhecido, em que os dois bits de maior ordem do identificador Option Type

assumem os seguintes valores:

a) Option Type (00)

b) Option Type (01)

c) Option Type (10)

d) Option Type (11), sendo o endereço destino um Multicast local

Para a realização do teste para as situações a,b,c e d o programa de execução

automática utilizou os scripts HH_Type00.seq, HH_Type01.seq, HH_Type10.seq e

HH_Type11.seq respectivamente.

Na tabela seguinte encontra-se listada algumas primitivas usadas no script para gerar os

pacotes de teste.

Primitivas usadas para gerar o cabeçalho Hop-by-Hop Pad1/PadN

Primitivas #define OPT_PAD opt_Type00

#define OPT_PAD opt_Type01





opt_Type01 %pktdesc = (

echo_request => 'Send Echo Request

(Preparation)',

echo_request_ex => 'Send Echo Request

(Unrecognized Option:Type 01)');

Tabela 36 – Primitivas usadas no script HH_Type.seq

Na tabela seguinte encontram-se listados as estruturas dos pacotes contendo o

cabeçalho de Extensão Hop-by-Hop Options com o valor do campo Option Type

desconhecido gerados pelas primitivas listadas anteriormente.

Option Type (00)

| | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_ANY (length:6) | | | | OptionType = 2 | | | | OptDataLength = 4 | | | | data = 00000000

(…)

Option Type (01)


Option Type (10)


Option Type (11)


Tabela 37 - Pacotes gerados pelo script HH_Type.seq




O NUT ao receber um pacote Echo Request contendo um cabeçalho Hop-by-Hop

com o valor do campo Option Type desconhecido deverá agir de acordo com os dois bits

de maior ordem do identificador Option Type.

a) Option Type (00) – deverá ignorar a opção e continuar o processamento

do cabeçalho

b) Option Type (01) – deverá descartar o pacote

c) Option Type (10) – deverá descartar o pacote e, independentemente do

endereço de destino ser um endereço Multicast ou não enviar uma

mensagem ICMP (ICMP - Parameter Problem), com o campo Code igual a

2, a mensagem deve ser enviada ao endereço Origem do pacote

d) Option Type (11) – deverá descartar o pacote e, e enviar uma mensagem

ICMP (ICMP - Parameter Problem) apenas se o endereço de destino não

for um endereço Multicast

4. Testes referentes à fragmentação no IPv6

O conceito de fragmentação não é novo, assim como a versão 4 do protocolo IP a

versão 6 também suporta a fragmentação de pacotes. A grande diferença está na forma

como a fragmentação é efectuada. Em IPv6 a fragmentação é feita pelo nó de origem

antes do envio do pacote. É utilizada a técnica de enviar um Path MTU27 Discovery para

descobrir qual o menor dos MTU´s até ao destino. No processo de envio do pacote, o nó

de origem fragmenta-o de maneira que cada fragmento seja inferior ou igual ao MTU

mínimo descoberto. Desta forma, a fragmentação não ocorre nos routers intermédios.

27

Path MTU - mais pequeno MTU num caminho entre duas máquinas



A figura seguinte ilustra o cabeçalho de extensão Fragment.

Next Header Reserved Fragment Offset Res M

Identification

Figura 12 - Cabeçalho de Extensão Fragmentation

As definições de cada campo do cabeçalho são as seguintes:

Next Header (8 bits) – o campo Next Header identifica o tipo do próximo

cabeçalho de extensão;

Reserved – o campo Reserved é reservado para utilização futura;

Fragment Offset – o campo Fragment Offset indica a que ponto do pacote

original pertence o fragmento;

Res – o campo Res é reservado para utilização futura;

M – a flag M indica se existem mais fragmentos ou se, se trata do último

fragmento. Este campo admite um de dois valores:

Valor Descrição

0 Indica que é o último fragmento

1 Indica que existem mais

fragmentos

Tabela 38 – Bit M do cabeçalho de extensão Fragment

Identification – o campo Identification identifica de forma unívoca o fragmento. O

número de bits deste campo foi ampliado relativamente ao IPv4, devido às redes

de alta velocidade.

O cabeçalho de extensão Fragment é identificado pelo valor 44 no campo Next Header

do cabeçalho IPv6, e é utilizado quando o pacote IPv6 a ser enviado é maior que o

caminho para o destino. Nessas situações o nó de origem divide o pacote em vários

fragmentos e envia cada fragmento como um pacote separado. No destino são

reagrupados os vários fragmentos.

Para todos os pacotes fragmentados é gerado, pelo nó de origem, um valor de

Identificação. Este valor de identificação é diferente de qualquer outro pacote



fragmentado que não tenha sido enviado recentemente com o mesmo endereço de

origem e destino. O termo recentemente corresponde ao período máximo de vida

provável de um pacote, incluindo o tempo de trânsito da origem para o destino e o tempo

gasto na reconstrução. Porém, não se requer a um nó de origem que conheça o período

máximo de vida de um pacote. Assume-se que um valor de identificação de 32 bits para

um contador cíclico de identificação é suficiente. [10]

Num pacote existe informação que não é possível fragmentar, separando-se

assim duas partes distintas, a parte fragmentável e a parte não fragmentável.

Para a análise seguinte o termo ―pacote inicial‖ considera-se como sendo o pacote

grande e não fragmentado.

Parte não Fragmentável

Parte Fragmentável

Figura 13 - Fragmentação de pacotes.

A parte não fragmentável consiste no cabeçalho IPv6 mais os cabeçalhos de extensão

que devem ser processados pelos nós até ao destino, por exemplo, cabeçalho de routing

e cabeçalho Hop-by-Hop.

A parte fragmentável engloba o resto do pacote, isto é, todos os cabeçalhos de extensão,

que apenas têm que ser processados pelo nó de destino, mais o cabeçalho da camada

superior e os dados.

A parte fragmentável do pacote original é dividida em fragmentos. Com excepção do

último, o comprimento de cada fragmento é múltiplo de 8 octetos. Os fragmentos são

transmitidos em ―pacotes fragmentados‖ separados como se ilustra na figura seguinte:


1º Fragmento 2º Fragmento ... Ultimo Fragmento

Figura 14 - Pacote original.




Cabeçalho de Fragmentação

1º Fragmento



2º Fragmento



Ultimo Fragmento

Figura 15 - Pacotes fragmentados.

A composição de cada pacote fragmentado é a seguinte:

Parte não fragmentável do pacote inicial, com uma alteração no tamanho do

payload relativamente ao inicial. O tamanho do payload é alterado

correspondendo agora a apenas ao tamanho do fragmento, excluindo inclusive o

tamanho do cabeçalho IPv6. O campo Next Header do último campo da parte não

fragmentável é alterado para 44 de forma a indicar a presença dos fragmentos.

O cabeçalho do fragmento é composto por:

O valor do campo Next Header que identifica o primeiro cabeçalho da parte

fragmentável do pacote original;

O campo Fragment Offset indica a distância do fragmento, em unidades de 8

octetos, relativamente ao começo da parte fragmentável do pacote original. O

Fragment Offset do primeiro fragmento é 0;

A flag M que, caso seja 0, indica o último fragmento;

Uma identificação;

O próximo fragmento.

A parte não fragmentável do pacote reconstituído é composta por todos os

cabeçalhos até ao cabeçalho de fragmento, com exclusão deste, do primeiro pacote

fragmentado, (ou seja, o pacote cujo Fragment Offset é zero) com duas alterações.

O campo Next Header do último cabeçalho da parte não fragmentável é obtido do

campo Next Header do primeiro cabeçalho de fragmento, da parte fragmentável.



O tamanho do Payload do pacote reconstituído é calculado a partir do tamanho

da parte não fragmentável e do tamanho do Offset do último fragmento.

A parte fragmentável do pacote reconstituído é construída com fragmentos que

seguem ao cabeçalho de fragmento em cada um dos pacotes de fragmento. O tamanho

de cada fragmento é calculado subtraindo ao tamanho do Payload do pacote o tamanho

dos cabeçalhos entre o cabeçalho IPv6 e o do próprio fragmento, a sua posição relativa

na parte fragmentável é calculada a partir do seu valor de Fragment Offset. O cabeçalho

de fragmentação não esta presente no pacote final reconstituído.

Na reconstituição do pacote podem surgir as seguintes situações de erro:

Se são recebidos fragmentos insuficientes para completar a reconstituição de um

pacote num intervalo de 60 segundos, desde a recepção do primeiro fragmento

que foram recebidos devem ser descartados.

Se o tamanho de um fragmento, como derivou do tamanho do campo Payload

Length do pacote de fragmento, não é um múltiplo de 8 octetos e a flag M daquele

fragmento é 1, então aquele fragmento deve ser descartado e uma mensagem de

ICMPv6 (ICMPv6 Parameter Problem), código zero (0), deve ser enviada à fonte

do fragmento, apontando o problema no campo Payload Length do pacote de

fragmento.

Se o tamanho e o Offset de um fragmento são tais que o tamanho do Payload do

pacote reconstituído excederia 65.535 bytes, então o fragmento deve ser

descartado e uma mensagem de ICMP (ICMP Parameter Problem), código zero

(0), deve ser enviada à fonte do fragmento, apontando para o campo Fragment

Offset do pacote.

Existem outras situações que, em regra, podem não ocorrer, mas caso ocorram não são

consideradas erro. Essas situações são:

O número e conteúdo dos cabeçalhos que procedem o cabeçalho de fragmento,

de fragmentos diferentes do mesmo pacote original, podem diferir. Sempre que

existam cabeçalhos antes do cabeçalho de fragmento são processados quando o

pacote chega, antes dos fragmentos serem guardados para reconstituição.



Os valores do campo Next Header nos cabeçalhos de fragmento, de fragmentos

diferentes do mesmo pacote original, podem diferir. Só o valor do campo do

fragmento com Offset zero é usado para a reconstituição.

4.1. Fragmentos de pacote usados nos testes

Na tabela seguinte encontram-se listados as estruturas dos dois fragmentos de

um pacote Echo Request usados nos vários testes.

Fragmento 1

Frame_Ether (length:582) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:568) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 528 | | | NextHeader = 44 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Fragment (length:8) | | | NextHeader = 58 | | | Reserved1 = 0 | | | FragmentOffset = 0 | | | Reserved2 = 0 | | | MFlag = 1 | | | Identification = 235 | | Payload (length:520)

Fragmento 2

Frame_Ether (length:574) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:560) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 520 | | | NextHeader = 44 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Fragment (length:8) | | | NextHeader = 58 | | | Reserved1 = 0 | | | FragmentOffset = 65 | | | Reserved2 = 0 | | | MFlag = 0 | | | Identification = 235 | | Payload (length:512)

Tabela 39 – Fragmentos de um Pacote Echo Request usado nos testes à fragmentação

Como se pode ver na tabela anterior o campo Next Header do cabeçalho IPv6 é igual a

44 de forma a indicar a presença dos fragmentos. O campo FragmentOffset do



fragmento1 é igual a zero (0), visto que o valor deste campo do primeiro fragmento é 0, e

o tamanho do campo payload corresponde apenas ao tamanho do fragmento, excluindo

inclusive o tamanho do cabeçalho IPv6.

4.2. Teste à reconstituição de fragmentos (ordem normal/

ordem inversa)

O tamanho dos fragmentos é escolhido de acordo com o MTU do caminho para o

destino dos pacotes. No destino os fragmentos são reconstituídos, de forma a reconstruir

o pacote original. Um pacote original é reconstituído apenas com os pacotes de

fragmento que tenham o mesmo Endereço de Origem, Endereço de Destino e

Identificação de fragmento.

4.2.1. Objectivo

Verificar se o NUT reconstitui correctamente os fragmentos e se faz a distinção

entre fragmentos usando o Endereço de Origem, Endereço de Destino e Identificação de

fragmento e também verificar se após receber os fragmentos pela ordem inversa os

reconstitui correctamente.


O nó de teste (TN) envia um pacote dividido em dois fragmentos (Fragmento 1 e

fragmento 2) contendo o mesmo Endereço de Origem, Endereço de Destino e

Identificação de fragmento.

Para o teste à ordem inversa dos pacotes o TN envia os dois fragmentos em que

o primeiro fragmento a ser enviado é o fragmento 2 que corresponde ao último fragmento

e de seguida o fragmento 1 que corresponde ao primeiro fragmento.

Para a realização dos testes o programa de execução automática utilizou os scripts

“FH_Normal.seq e FH_Reverse.seq‖ onde se encontram definidas primitivas que

permitem gerar vários fragmentos de um pacote.




Primitivas usadas para gerar fragmentos de um pacote

Primitivas usadas na construção do fragmento 1

Hdr_Fragment frag_1st {

NextHeader = 58;

FragmentOffset = 0;

MFlag = 1;

Identification = FRAG_ID;

}

Payload payload_1st {

data =

substr(_PACKET_IPV6_NAME(echo_request), 40, 520);

} Primitivas usadas na construção do fragmento 2

Hdr_Fragment frag_2nd {

NextHeader = 58; // ignored

FragmentOffset = 65; // 520/8

MFlag = 0;

Identification = FRAG_ID;

}

Payload payload_2nd {

data =

substr(_PACKET_IPV6_NAME(echo_request), 560, 512);

}

Pacote Echo Request do 1º fragmento

FEM_hdr_ipv6_exth(

echo_request_1st,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

},

{

header =

_HDR_IPV6_NAME(echo_request_1st);

exthdr = frag_1st;

upper = payload_1st;

}

)

Pacote Echo Request do 2º fragmento

FEM_hdr_ipv6_exth(

echo_request_2nd,

_HETHER_tn2nut,

{

_SRC(tnv6());

_DST(nutv6());

},

{

header =

_HDR_IPV6_NAME(echo_request_2nd);

exthdr = frag_2nd;

upper = payload_2nd;

}

)

Tabela 40 – Primitivas usadas para gerar fragmentos de um pacote




O NUT ao receber os dois fragmentos (fragmento 1 e fragmento 2) enviados pelo

nó de teste (TN), pela ordem normal ou inversa, deverá reconstitui-los e enviar um pacote

Echo Replay para o TN, em resposta ao pacote Echo Request resultante da

reconstituição dos dois fragmentos.

4.3. Teste à reconstituição de fragmentos (Payload size =

65.536 bytes)

Se o tamanho e o Offset de um fragmento são tais que o tamanho do Payload do

pacote reconstituído exceda 65.535 bytes, então o fragmento deve ser descartado e uma

mensagem de ICMP (ICMP Parameter Problem), deve ser enviada ao nó de origem do

fragmento.

4.3.1. Objectivo

Verificar se o fragmento é descartado quando o tamanho do campo Payload do

pacote reconstituído excede os 65.535 bytes, e se é enviado uma mensagem de ICMP

(ICMPV6 Parameter Problem), código zero (0) para o nó de teste (TN). O MTU utilizado é

1500 (Ethernet)


O nó de teste (TN) envia 46 fragmentos para o NUT, sendo 45 fragmentos

contendo o campo Payload igual 1448 bytes e 1 fragmento contendo o campo Payload

igual a 376 bytes o que faz com que o tamanho do campo Payload do pacote

reconstituído seja igual a 65.536.

Para a realização dos testes o programa de execução automática utilizou os scripts

“FH_Big65536.seq‖ onde se encontram definidas primitivas que permitem gerar vários

fragmentos de um pacote.




decorrer deste teste encontram-se listadas na tabela seguinte:


1 Start


3 vSend(Link0,echo_request_1)

Send Echo Request fragment 1

… …





50 vRecv(Link0,icmp_type4_code0) timeout:5 cntLimit:0 seektime:0

Recv ICMP Error (Parameter Problem, erroneous header field encountered)

51 OK

52 End

Tabela 41 - Acções executadas no teste ao campo Opção Pad1/PadN


Se o tamanho do campo Payload do pacote reconstituído pelo NUT exceda os

65.535 bytes, então o NUT deverá descartar o fragmento e enviar uma mensagem de

ICMP (ICMP Parameter Problem), para o TN.

4.4. Teste à reconstituição de fragmentos quando é

excedido o tempo (1st only)

Se são recebidos fragmentos insuficientes para completar a reconstituição de um

pacote num intervalo de 60 segundos, desde a recepção do primeiro, os fragmentos

recebidos devem ser descartados.



4.4.1. Objectivo

Verificar o que acontece quando são recebidos fragmentos insuficientes para

completar a reconstituição de um pacote num intervalo superior a 60 segundos.


O nó de teste (TN) envia um pacote Echo Request contendo o único fragmento

(fragmento 1) enviado para o NUT. Fragmento este contendo a flag M a 1, o que indica

que existem mais fragmentos.


./FH_1stOnly.seq.


decorrer do teste encontram-se listadas na tabela seguinte.


1 Start


3 vSend(Link0,echo_request_1st)

Send Echo Request (1st fragment only)

4 vRecv(Link0,time_exceeded_1st) timeout:65 cntLimit:0 seektime:0

5 OK

6 End

Tabela 42- Acções executadas no teste à reconstituição de fragmentos


O NUT não deve gerar um Echo Replay para o TN, uma vez que não recebeu

todos os fragmentos. Deverá descartar o pacote e enviar uma mensagem de erro

ICMPv6 (ICMPv6 – Fragment Reassembly Time Exceeded).


Capítulo V

Resultado dos Testes Realizados


Neste capítulo será feito a análise aos resultados dos vários testes de

conformidade IPv6 realizados no capítulo anterior, testes esses que capítulo abrangem a

especificação base do IPv6, definidos no RFC 2460, bem como o processamento das

Opções e Cabeçalhos de Extensões, em particular o Hop-by-Hop Option, Destination

Option. E também será efectuado uma comparação dos resultados obtidos do mesmo

conjunto de testes efectuados sobre outras distribuições linux.

1.2. Resultado dos testes

Os resultados dos vários testes de conformidade em relação ao IPv6 realizados

encontram-se listados na tabela na tabela seguinte.

Nº Nome do teste Resultado

1 Campo Versão errado Passou

2 Traffic Class Passou

3 Flow Label Passou

4 Payload Length Passou

Capítulo V – Resultado dos testes IPv6 realizados


5 Next Header do cabeçalho IPv6 irreconhecível

Passou

6 Hop Limit Passou

7 Next Header do cabeçalho de extensão irreconhecível

Passou

8 Teste à ordem do cabeçalho de extensão Hop-by-Hop num pacote com mais de um cabeçalho

Passou

9/ 10 Teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop

Passou

11

a

Teste à codificação dos dois bits de maior ordem do indicador Option Type 00

Passou

11 b Teste à codificação dos dois bits de maior ordem do indicador Option Type 01

Passou

11 c Teste à codificação dos dois bits de maior ordem do indicador Option Type 10

Passou

11 d Teste à codificação dos dois bits de maior ordem do indicador Option Type 11

Passou

12 a Teste à fragmentação ordem normal Passou

12 b Teste à fragmentação ordem inversa Passou

13 Teste à reconstituição de fragmentos superiores a 65.536

Passou

14 Teste à reconstituição de fragmentos quando é excedido o tempo

Passou

Tabela 43 - Resultado dos Testes de Conformidade IPv6 realizados



1.3. Análise dos resultados

Baseando-se no valor de retorno da execução dos scripts de teste e da análise das

sequencias de acções executadas pelo programa de execução automática no decorrer de

cada teste conclui-se que:

Nº 1 - O NUT passou no teste. Ao receber o primeiro pacote Echo Request inválido, o

NUT não gera nenhum pacote Echo Reply (como se pode ver na acção nº4 o vRec()

terminou com timeout), ao receber um segundo pacote que já é um pacote Echo Request

valido o NUT gera e envia um pacote Echo Replay.

Nº 2 – O NUT passou no teste. Ao receber um pacote Echo Request com o valor do

campo Traffic Class igual a 0x12 (18 em decimal), que é diferente de zero o NUT gera um

Echo Replay com o valor do campo Traffic Class igual a zero (0).


campo Flow Label igual a 0x34567 (214375 em decimal), que é diferente de zero o NUT

gera um Echo Replay com o valor do campo Flow Label igual a zero (0).


campo Payload Length igual a 15, gera o Echo Replay correspondente.

Nº 5 – O NUT passou no teste. Ao receber um pacote com o valor do campo Next Header

do cabeçalho IPv6 irreconhecível, gera uma mensagem de erro ICMPv6 (Parameter


encountered) e com o campo Pointer a 0x06 (offset do campo Next Header).

Nº6 – O NUT passou no teste. Ao receber um pacote Echo Request com o campo Hop

Limit a zero gera o Echo Replay correspondente, com o valor do campo Hop Limit maior

do que zero (Hop Limit default 64).

Nº 7 – O NUT passou no teste. Ao receber um pacote com o valor do campo Next Header

do cabeçalho Destination Options header irreconhecível (128), gera uma mensagem de

erro ICMPv6 (Parameter Problem message) com o valor do campo Code a 1

(Unrecognized Next Header Type encountered) e com o campo Pointer a 0x06 (offset do

campo Next Header do cabeçalho Destino).

Nº 8 – O NUT passou no teste. Ao receber um pacote Echo Request contendo mais do

que um cabeçalho de extensão, em que o cabeçalho de extensão Hop-by-Hop não

precede o cabeçalho IPv6, gera e envia uma mensagem de erro ICMPv6 (Parameter


encountered).



Nº 9 / Nº 10 – O NUT passou no teste. Ao receber um pacote Echo Request contendo um

cabeçalho Hop-by-Hop com seis Pad1 Option ignora o Cabeçalho de Extensão Hop-by-

Hop, uma vez que o valor do campo Option Type é zero (0) e continua o processamento

do Cabeçalho seguinte que é um Echo Request e, em resposta ao Echo Request envia

um Echo Replay para o TN. Ao receber um pacote Echo Request contendo um cabeçalho

Hop-by-Hop com 6 bytes PadN Option, responde com um Echo Replay para o TN.

Nº 11 – O NUT passou no teste. Ao receber um pacote Echo Request contendo um

cabeçalho de extensão Hop-by-Hop com o valor do campo Option Type desconhecido:

a) Com o campo Option Type igual a 2 (formato decimal), que é equivalente a

00000010 em binário em que os dois bits de maior ordem que especificam a

acção que deve ser tomada caso o NUT não reconheça o tipo da opção são 00, o

NUT ignora o Option Type e continua o processamento do Cabeçalho seguinte

que é um Echo Request e, em resposta ao Echo Request envia um Echo Replay

para o nó de teste. Ou seja a opção desconhecida é ignorada e é processada o

próximo cabeçalho.

b) Com o campo Option Type igual a 66 (formato decimal), que é equivalente a



NUT descarta o pacote Echo Request e não gera nenhuma resposta.

c) Com o campo Option Type igual a 130 (formato decimal), que é equivalente a



NUT descarta o pacote e responde com uma mensagem ICMPv6 (ICMPv6-

Parameter Problem) em que o campo Code é igual a 2 (Unrecognized IPv6

Option encountered) e o campo Pointer é 0x02a.

d) Com o campo Option Type igual a 226 (formato decimal), que é equivalente a

11100010 em binário onde os dois bits de maior ordem (bits mais significativos)

especificam a acção que deve ser tomada caso o nó que processa o pacote não

reconheça o tipo da opção são 11, o NUT descarta o pacote, e como o endereço

destino é um endereço Multicast, não responde com uma mensagem ICMPv6

(ICMPv6-Parameter Problem).



Nº 12 (a,b) – O NUT passou no teste. Ao receber dois fragmentos enviados (ordem

normal/inversa) pelo TN, reconstitui-os e envia um Echo Replay para o nó de teste (TN),

em resposta ao Echo Request resultante da reconstituição dos dois fragmentos.

Nº 13 – O NUT passou no teste. Ao receber 46 fragmentos do TN, onde os primeiros 45

fragmentos têm o valor do campo Payload igual a 1448 bytes e o último fragmento

contendo o valor do campo Payload igual a 376 bytes, o NUT faz a reconstituição dos 46

fragmentos. Como o tamanho do Payload do pacote reconstituído excede 65.535 bytes, o

NUT descarta o pacote e envia uma mensagem de ICMPv6 (ICMPv6 Parameter

Problem), código zero (0) para o nó de teste (TN).

Nº 14 – O NUT passou no teste. Ao receber apenas um único fragmento contendo a flag

M a 1, o que indica que existem mais fragmentos e passados um intervalo superior a 60

segundos, desde a recepção do primeiro fragmento o NUT descarta o pacote e envia

uma mensagem e de erro ICMPv6 (ICMPv6 – Fragment Reassembly Time Exceeded),

para o TN, ma vez que não foram recebidos fragmentos suficientes para completar a

reconstituição do pacote enviado pelo nó de teste (TN).



1.4. Comparação entre sistemas operativos

Nesta secção é feita uma descrição detalhada sobre os resultados da execução dos

testes em quatro núcleos diferentes.

Resultado da Implementação do IPv6 no Linux [kernel 2.2.15]. (Teste

retirado da página www.linux-IPv6.org)

Resultado da Implementação do IPv6 KAME, que é avaliada como uma

implementação IPv6 de referência [FreeBSD 3.4].

Resultado da Implementação do IPv6 no Linux nas distribuições testadas

[kernel 2.6.22-14 Ubuntu 7.10 , Kernel 2.6.18-164.el5 -Centos]

Tabela 44 - Teste de Conformidade IPv6 à distribuição Ubuntu e FreeBSD

Da análise aos resultados dos testes de conformidade IPv6 referentes aos núcleos

apresentados na tabela anterior conclui-se que:

O kernel 2.2.15 falhou em 2 testes, porque a implementação do IPv6 no Linux

desse kernel tem um problema na reconstituição dos fragmentos de um pacote

IPv6.

A 1º falha foi devido ao facto do NUT não responder com um

pacote Echo Replay em resposta ao envio de um pacote Echo

Request contendo o Offset = 0 (indica o 1º fragmento) e a Flag M =

0 (Indica que é o último fragmento).

NUT Funcionalidades

Testadas RFC Nº de Testes

Realizados Sucesso Falha Taxa de

Sucesso Kernel 2.2.15 IPv6 Specification 2460 35 33 2 94% FreeBSD 3.4 IPv6 Specification 2460 35 35 0 100% Ubuntu 7.10 (kernel 2.6.22-14-

Generic)

IPv6 Specification 2460 35 35 0 100%

Centos (Kernel 2.6.18-

164.el5)

IPv6 Specification 2460 35 35 0 100%



A 2º falha foi devido ao facto do tamanho do Payload pacote

reconstituído pelo NUT exceder os 65.535 bytes e o TN não

receber nenhuma mensagem ICMP (ICMP Parameter Problem).

Como se pode ver na tabela anterior a implementação do IPv6 do

Kame e os outros NUT´s testados passaram nos testes realizados.

Da análise aos resultados dos testes de conformidade IPv6 referentes às

distribuições seguintes: (Centos, FreeBSD e Ubuntu), conclui-se que essas

distribuições se encontram em conformidade com as especificações definidas

no RFC 2460 para os testes realizados.


Capítulo VI

Conclusão


No geral os objectivos propostos para esta dissertação foram alcançados, sendo o

estudo dividido em duas partes: numa primeira, pretendeu-se conferir um enquadramento

teórico ao tema, deste modo, procedeu-se à explicação dos vários componentes do IPv6,

numa segunda, o enfoque foi dado à aplicabilidade prática do IPv6, onde foi feita uma

análise orientada aos detalhes da sua implementação no sistema operativo Linux.

No presente capítulo, pretende-se retratar as conclusões retiradas do estudo realizado,

estabelecendo os objectivos alcançados, as limitações de investigação e a apreciação

final.

1.2. Verificação das hipóteses teóricas e práticas

No que diz respeito às hipóteses teóricas, verifica-se que o IPv6 contém muitas das

características que fizeram o IPv4 ser tão bem sucedido. Apesar de reter os conceitos

básicos do IPv4, o IPv6 procede, por um lado, à modificação de alguns dos pontos

fundamentais tais como: Expansão da capacidade de endereçamento; Simplificação do

formato do cabeçalho; Mecanismos de auto configuração; Melhoria do suporte do

Multicast; Novo tipo de endereço (Anycast); Melhoria do suporte das extensões e da

extensão para autenticação e privacidade (integridade e confidencialidade de dados).

E, por outro, corrige os problemas do IPv4, ao eliminar e/ou tornar opcionais as

funcionalidades do IPv4 que não têm bom desempenho ou que não são frequentemente

utilizadas, conferindo assim uma maior optimização do protocolo IP.

Capítulo VI – Conclusão


No que concerne à especificação base, o IPv6 mantém a mesma especificação, contudo,

com algumas alterações, onde se destacam alguns dos RFC´s que foram actualizados e

outros que se tornaram obsoletos.

Todavia, no que diz respeito às hipóteses práticas, a nível da implementação, o

suporte IPv6 no sistema operativo Linux tem variado ao longo do tempo, houve muitas

melhorias e a tendência é de existir cada vez mais funcionalidades implementadas ou

corrigidas. Grande parte das melhorias no suporte IPv6 no Linux resulta da contribuição

dada por organizações tais como WIDE Project, KAME Project e TAHI Project e outras

associações ou grupos de voluntários de diversos países.

A nível prático o estudo realizado consistiu em analisar a implementação do IPv6 no

stack do Linux tendo sido efectuados testes de conformidade em relação à especificação

base do IPv6 definidos no RFC 2460, onde são especificados o cabeçalho IPv6 e os

cabeçalhos de Extensão e Opções.

1.3. Limitações da Investigação

Infelizmente, nem todas as funcionalidades apresentadas no referencial teórico foram

testadas neste trabalho, por forma a evitar um prolongamento das actividades e, ainda,

por força das dificuldades encontradas na implementação de alguns cenários de teste,

principalmente, devido às limitações do ambiente virtual (VMware). Não foi possível

realizar testes de conformidade em relação à especificação do Neighbor Discovery

devido a limitações do ambiente virtual de teste, sendo um dos requisitos de configuração

do cenário de teste, a utilização de uma ligação em série entre o nó de teste e o nó em

teste. Os testes de conformidade efectuados ao longo do presente trabalho incidiram

apenas sobre testes entre hosts.

1.4. Investigações futuras

Nesta secção serão traçadas algumas linhas de orientação sobre perspectivas de

investigações futuras. Em termos de trabalho futuro, deverá ser equacionado:

Testes de conformidade entre host e routers.

Estudar os aspectos relacionados com a segurança no IPv6 e a realização testes

de conformidade sobre o IPsec.

Estudar os aspectos relacionados com a mobilidade no IPv6 e realizar testes de

conformidade sobre o MIPv6.


Bibliografia

1. S. Bradner, A. Mankin. RFC1752- The Recommendation for the IP Next Generation

Protocol. [Online] 1995. http://www.ietf.org/rfc/rfc1752.txt.

2. —. RFC 1550 - IP: Next Generation (IPng) White Paper Solicitation. [Online] 1993.

http://tools.ietf.org/html/rfc1550.

3. Morton, David. Understandig IPv6. [Online]

http://www.techsupportalert.com/pdf/c0655.pdf.

4. Comer, Douglas. Computer networks and internets: with Internet applications. s.l. :

Pearson Prentice Hall, 2004.

5. Davies, Joseph. Understanding IPv6. 2002.

6. Windows Server TechCenter. [Online] 2010. http://technet.microsoft.com/en-

us/library/cc738582(WS.10).aspx.

7. Cruz, Ademar. Resumo histórico. [Online] 1999.

http://civil.fe.up.pt/acruz/Mi99/asr/historico.htm.

8. V. Fuller, T. Li. RFC 1338 -Supernetting: an Address Assignment and Aggregation

Strategy. [Online] 1992. http://www.faqs.org/rfcs/rfc1338.html.

9. (CIDR), RFC 4632 - Classless Inter-domain Routing. [Online] 2006. http://www.rfc-

editor.org/rfc/rfc4632.txt.

10. S. Deering, R. Hinden. RFC 2460 -Internet Protocol, Version 6 (IPv6) Specification.

[Online] 1998. http://tools.ietf.org/html/rfc2460#section-4.

11. J. McCann, S. Deering, J. Mogul. RFC 1981 - Path MTU Discovery for IP version 6.

[Online] http://tools.ietf.org/html/rfc1981.

12. Nordmark, E. RFC 2765 - Stateless IP/ICMP Translation Algorithm (SIIT). [Online]

2000. ftp://ftp.rfc-editor.org/in-notes/rfc2765.txt.


13. Bieringer, Peter. Linux IPv6 HOWTO. [Online] http://tldp.org/HOWTO/Linux+IPv6-

HOWTO/.

14. K. Nichols, S. Blake,F. Baker. RFC 2474 - Definition of the Differentiated Services

Field in the IPv4 and IPv6 Headers. [Online] http://tools.ietf.org/html/rfc2474.

15. Linux IPv6: Which One to Deploy. Haddad, Ibrahim. 2002.

16. [Online] http://www.tahi.org/.

Documents

Exploração da implementação actual de IPv6 no kernel do Linux§ão... · Com base no estudo realizado, explora-se o suporte do IPv6 no Kernel do Linux, fazendo uma análise detalhada