IPv6 - Internet Protocol version 6 - FCULwebpages.fc.ul.pt/~sgclaudio/webfiles/04-IPv6v3.pdf · História do IPv6 • O sucessor do IPv4 começou a ser desenvolvido no inicio dos

IPv6 - Internet Protocol version 6

Motivação

• Esgotamento do espaço de endereçamento do IPv4

• IPv4 tem 30 anos, já não satisfazia as exigências dos utilizadores e serviços de hoje em dia

24-05-2013 ISEL - ADEETC 2

História do IPv6

• O sucessor do IPv4 começou a ser desenvolvido no inicio

dos anos 90 pelo Internet Engineering Task Force (IETF)

• Existiram várias propostas

• Tornou-se num IETF Standard em Dezembro de 1998

• Nota: O IPv5 não existe dado o número de versão 5 ter sido

atribuído a um protocolo experimental.

24-05-2013 ISEL - ADEETC 3

Objectivos

Simplicidade;

Escalabilidade;

Flexibilidade topológica;

Desempenho;

Robustez;

Transição;

Independência do meio;

24-05-2013 ISEL - ADEETC 4

Orientação ao datagrama;

Facilidade de configuração;

Segurança;

Multicast ;

Mobilidade;

Qualidade de serviço;

Potencialidade de evolução.

Objectivos

Facilidades suportadas pelo IPv6

• Novo formato do header

• Grande espaço de endereçamento

• Endereçamento hierárquico e estrutura de endereçamento

(routing) eficiente

• Configuração de endereços stateless e stateful

• Segurança integrada (built-in)

• Melhor suporte de QoS

• Novo protocolo para interacção entre vizinhos

• Extensível

24-05-2013 ISEL - ADEETC 5

1 - IPv6 versus IPv4

Comparação do header do IPv4 com o do IPv6

24-05-2013 ISEL - ADEETC 7

4 bits

Version = 6

4 bits 4 bits

Version = 4 Header length

4 bits

Flags

Source address

32 bits

Destination address

0 up to 320 bits

IP options

Identification

16 bits

Header checksum

12 bits

Fragment offset

8 bits

Protocol

8 bits

Time to live

32 bits

20 bits

Flow label

8 bits

Traffic class

8 bits

Type of service

Destination address

16 bits

Total length

16 bits

128 bit

Source address

128 bits

16 bits

Payload length Next header

8 bits 8 bits

Hop Limit

Principais alterações do IPv4 para o IPv6

• Capacidade estendida de endereçamento e mecanismos de

auto configuração

• Simplificação do formato do header

• Melhoria do suporte para as extensões e opções

• Extensões para autenticação e privacidade

• Capacidade de marcar os fluxos de tráfego

24-05-2013 ISEL - ADEETC 8

Resumo da funcionalidade (1)

• Expansão da capacidade de endereçamento

– 128 bits: 2128 endereços;

– Assumindo o formato 64+64 bits: 1,8E+19 redes

– 1E+16 redes, assumindo eficiência idêntica à do IPv4

– 1 milhão de redes por cada humano

– 20 redes por cada m2 da terra

• Simplificação do formato do cabeçalho – comprimento fixo de 40 bytes

• Mecanismos de auto configuração – Plug and play - Ligação ainda mais simples que no IPX

24-05-2013 ISEL - ADEETC 9

Resumo da funcionalidade (2)

• Melhoria do suporte do Multicast

• Novo tipo de endereço – Anycast

• Melhoria do suporte das extensões e das opções

• Extensões para autenticação e privacidade (integridade e confidencialidade de dados)

• Mobilidade eficiente:

– Redes ad-hoc simples e instantâneas

– IP Móvel, sem servidores, sem “dogleg”

• Capacidade de marcar fluxos de dados

24-05-2013 ISEL - ADEETC 10

2 - Estrutura do protocolo IPv6

Cabeçalho IPv6 Características principais

• Extensão das capacidades de endereçamento e encaminhamento

• Simplificação do formato de cabeçalho

• Suporte para extensões de cabeçalho e opções

• Suporte para autenticação e privacidade

• Suporte de auto configuração

• Suporte para selecção de percurso pelo remetente

• Transição simples e flexível

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

24-05-2013 ISEL - ADEETC 12

Cabeçalho IPv4 Alterações

• 20 octetos, sem opções

24-05-2013 ISEL - ADEETC 13

4 bits 4 bits

Version = 4 Header length

4 bits

Flags

Campos alteradosCampos removidos

32 bits

Source address

32 bits

Destination address

0 up to 320 bits

IP options

8 bits 8 bits 16 bits

Time to live Protocol Header checksum

Type of service Total length

16 bits 12 bits

Identification Fragment offset

8 bits 16 bits

Cabeçalho IPv6 Formato

• 40 octetos, sem extensões

24-05-2013 ISEL - ADEETC 14

4 bits

Version = 6

20 bits

Flow label

8 bits

Traffic class

Destination address

128 bit

Source address

128 bits

16 bits

Payload length Next header

8 bits 8 bits

Hop Limit

Cabeçalho IPv6 Elementos inalterados

• O único campo do cabeçalho que manteve o mesmo formato e posição

foi o de versão

– Na prática não é usado na multiplexagem. É recomendado que tal

seja feito ao nível da “datalink” (Ex. IPv6 sobre Ethernet usa “Type”

0x86DD em vez do 0x0800 do IPv4).

24-05-2013 ISEL - ADEETC 15

Cabeçalho IPv6 Simplificações (1)

• Formato fixo para todos os cabeçalhos – Dispensa do campo: Header Length - o header do IPv6

tem dimensão fixa (40 octetos)

– Optimizado para a grande maioria do tráfego

– Situações menos comuns usam cabeçalhos adicionais encadeados (em lista)

• Remoção do “checksum” – Minimizar processamento

– Assumir a realidade: As “data link” actuais já fazem essa função e com mais robustez e eficiência

24-05-2013 ISEL - ADEETC 16

Cabeçalho IPv6 Simplificações (2)

• Acabar com a fragmentação em trânsito

– Dispensa dos campos IPv4: Identification, Flags, Fragment Offset

– Optimizar processamento nos nós

– Fragmentos perdidos causavam retransmissões, atrasos e ocupação de recursos (memória)

– Obrigatório o uso do procedimento do IPv6 “Path MTU discovery”

– MTU mínimo de 1280 octetos

– Inclui um procedimento de fragmentação extremo a extremo

• Alteração do campo ToS

– Raramente é usado pelas aplicações e redes

– QoS com abordagem mais genérica para o problema

24-05-2013 ISEL - ADEETC 17

Cabeçalho IPv6 Campos revistos

• “Total Length” passa a “Payload Length”

– Só conta com a dimensão do “payload”

– Suporte de datagramas de dimensão elevada (> 64K bytes) baseado no cabeçalho “Jumbogram” (nesses casos PL = 0)

• “Protocol Type” passa a “Next Header”

– Reflecte a estrutura em “lista” dos cabeçalhos

• “Time-to-Live” torna-se “Hop Limit”

– Nada como ter o nome correspondente à função que desempenha!

– Esquece a recomendação que no IPv4 dizia para se decrementar também o tempo de processamento e espera e que era de difícil implementação

24-05-2013 ISEL - ADEETC 18

Cabeçalho IPv6 Novos campos (1)

• “Flow Label”

– Usado para identificar fluxos com necessidades de tratamento

idêntico.

– Um fluxo é identificado pelo flow label e pelo endereço de origem

• Exemplo: RSVP (Resource Reservation Protocol)

– Potencia técnicas de encaminhamento similares às do MPLS

directamente no IPv6

24-05-2013 ISEL - ADEETC 19

Cabeçalho IPv6 Novos campos (2)

• “Class – Traffic class”

– Primeiro bit D para indicar tráfego sensível a atrasos

– Três bits seguintes com uso idêntico ao “Precedence Field” do

IPv4 na marcação e tratamento do tráfego (DiffServ/IntServ)

– Últimos 4 bits reservados (há intenções de os usar de forma para

lidar com as congestões) – RFC 2474

• Ajudas preciosas para o tratamento de tráfego com características

de tempo real.

24-05-2013 ISEL - ADEETC 20

Cabeçalho IPv6 Extensões – Next header

• Podem existir zero, um ou mais headers de extensão entre o header IPv6 e o header do protocolo da camada superior

• Existem dependências entre extensões do header

• Formato em “lista” é essencial para lidar com situações especiais

• Os headers de extensão devem ser processados pela mesma ordem em que aparecem na “lista” (cabeça do pacote)

• Só o nó de destino processa os headers de extensão excepção para o header de Hop-by-hop Options. A informação que transporta deve ser examinada e processada em todos os nós do caminho. Se presente, o header Hop-by-hop deve seguir-se ao do IPv6.

24-05-2013 ISEL - ADEETC 21

Cabeçalho IPv6 Extensões ao header

IPv6 Header

TCP Header + Data

Next Header = TCP

IPv6 Header Routing Header

TCP Header + Data

Next Header = Routing Next Header = TCP

IPv6 Header Routing Header Fragment Header

TCP Header + Data

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

24-05-2013 ISEL - ADEETC 22

Para se manter o alinhamento o comprimento dos headers de extensão são múltiplos

de 8 bytes.

O não processamento dum header de extensão por parte dum nó, por este não

conseguir identificar o valor no campo Next Header, implica o jogar fora do pacote e o

envio duma mensagem ICMP

Cabeçalho IPv6 Tipo de extensões ao header

• Hop-by-hop options

• Routing

• Fragment

• Destination Options

• Authentication

• Encrypted Security Payload

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

24-05-2013 ISEL - ADEETC 23

Cabeçalho IPv6 Ordem de processamento das extensões

As especificações recomendam a seguinte ordem:

1 – IPv6

2 – Hop-By-hop Options Header

3 – Destination Options Header (1)

4 – Routing Header

5 – Fragment Header

6 – Authentication Security Payload Header

7 – Destination Options Header (2)

8 – Upper-Layer Header (TCP, UDP, ICMP, etc.)

Destination Options Header aparece duas vezes para contemplar situações de “túneis”:

(1) – A processar em todos os nós que constem no Routing header.

(2) – A processar pelo nó destino final.

24-05-2013 ISEL - ADEETC 24

Cabeçalho IPv6 Hop-by-Hop Options Header (HType=0)

• Transporta informações opcionais (options) que devem ser analisada

em todos os nós ao longo do caminho do pacote

• Mesmo formato que o “Destination Options Header”

• Para funções de gestão e “debugging”

• Interessante para protocolos de encaminhamento Multicast Listener

Discovery (MLD) e RSVP

24-05-2013 ISEL - ADEETC 25

Cabeçalho IPv6 Opção Jumbo Payload – RFC 2675

• Especificação actual define também a opção “Jumbo Payload” com o Type = 194

– Usada em substituição do campo do “Length” do cabeçalho base que neste caso

vem a zero

Type = 194 Opt Data Len = 4

Jumbo Payload Length

Jumbo Payload Option

24-05-2013 ISEL - ADEETC 26

Cabeçalho IPv6 Routing Header (HType = 43)

• Função idêntica ao “source routing” do IPv4

• Todas as implementações têm de suportar o “Type 0”

• “Hdr Len” em palavras de 64 bit, não contando os primeiros 64bit

• “Segments Left” de 0 a 23

• Forçar “strict” abandonado após as primeiras especificações (Campo “Reserved”)

• Matéria em debate, com diversas variações do formato genérico

Next Header Hdr Ext Len Routing Type = 0 Segments Left

Reserved

Address[1]

Address[2]

Address[n]

Type 0 Routing Header

Next Header Hdr Ext Len Routing Type Segments Left

Type-specific Data

Generic Routing Header

24-05-2013 ISEL - ADEETC 27

Cabeçalho IPv6 Routing Header – Source Routing

• A lista dos endereços destino é incluída no “routing header”

• O endereço destino é sempre o próximo router da lista, em

que o último é o da máquina destino

• O endereço destino do datagrama é alterado em cada router

da lista

• No Mobile IPv6 o “Care-of Address” é o “next router” e o

“Home Address” é o destino final

24-05-2013 ISEL - ADEETC 28

Cabeçalho IPv6 Fragment Header (HType = 44)

• Usado pelas máquinas origem (routers não fragmentam!)

• Tratamento idêntico ao do IPv4 quando o bit “don’t fragment” está activo

• “Identification” idêntico ao do IPv4, agora a 32 bits

• “Fragment Offset”, 13bit com a posição relativa do fragmento em múltiplos de 8 bytes, também com papel idêntico ao que tinha no IPv4, para manipular basta interpretar o valor como se fosse a 16bit, assumindo os bit RES e M a zero.

• Bit M (“more”) activo em todos os fragmentos excepto o último IPv6 Header Fragment Header 1 First 1400 octets

IPv6 Header Fragment Header 2 Last 1400 octets

2800 octetos separados em dois fragmentos

Next Header Reserved Fragment Offset Res M

Identification

Fragment Header

24-05-2013 ISEL - ADEETC 29

Cabeçalho IPv6 Fragment Header (HType = 44)

• Todos os headers, por exemplo os de routing, que precedem o de

fragmentação têm de ser repetidos em todos os datagramas com

fragmentos.

24-05-2013 ISEL - ADEETC 30

Cabeçalho IPv6 Destination Options Header (HType=60)

• Transporta opções para o destinatário final

• “Hdr Ext Len” a 8 bit, dimensão da opção em palavras de 64bit ( 0 8 octetos)

• O campo “options” contém uma lista de opções, cada uma de dimensão variável

Next Header Hdr Ext Len Fragment Header

Options

Options Header

24-05-2013 ISEL - ADEETC 31

Cabeçalho IPv6 Options

• Os campos “Option Type” e “Opt Data Len” são a 8 bit

• “Option Type” ainda se subdivide em 3 campos:

– “Action” (2 bit) – O que fazer se a opção não for reconhecida

• 00 – Passar à frente

• 01 – Descartar pacote sem enviar a mensagem ICMP (“parameter problem”)

• 10 – Descartar pacote mas avisar usando ICMP, mesmo que o endereço destino seja multicast

• 11 – Descartar pacote mas avisar usando ICMP, se o endereço destino não for multicast

– “C” (1 bit) – A opção pode ou não ser alterada em trânsito

– “Number” (5 bit) – Identificação da opção

24-05-2013 ISEL - ADEETC 32

Option Type Opt Data Len Option DataAction C number

Option Type

Impacto nas camadas superiores Checksums

• Novo formato de “pseudo headers” para cálculo dos “checksums” do TCP e UDP

• Para detectar entregas erradas, se por alguma razão o endereço origem ou destino são alterados em trânsito o “checksum” falha

• Passa a ser sempre obrigatório no UDP

Source Address

Destination Address

Payload Length

zero Next Header

IPv6 Pseudoheader for TCP and UDP

24-05-2013 ISEL - ADEETC 33

Formato utilizado sobre as tramas Data Link IEEE

24-05-2013 ISEL - ADEETC 34

Nas tramas

em formato

Ethernet II

Nas tramas em formato SNAP e

derivadas (RFC1042 e IEEE802.1h)

3 - Endereçamento em IPv6

Encaminhamento e Endereçamento Arquitectura

• Basicamente uma versão de maiores dimensões dos endereços IPv4

• Tal como no IPv4, um endereço IPv6 identifica determinada interface de uma máquina, não a máquina em si

– Uma máquina “multi-homed” terá tantos endereços quantas as interfaces que possua

• Previsto de base a existência de múltiplos endereços por interface

– Facilita o encaminhamento e gestão

24-05-2013 ISEL - ADEETC 36

Endereços Aumento de dimensão

• A mudança de 32 para 128 bit permite:

– Conectividade global

• Fim das redes e máquinas “escondidas”

• Todas as máquinas são acessíveis e podem ser “servidores” (aplicações “peer to peer”)

– Flexibilidade

• Múltiplos níveis de hierarquia no espaço de endereçamento

– Auto configuração

• O uso dos endereços “data link” a 64 bit embebidos no endereço fornecem uma garantia de unicidade

24-05-2013 ISEL - ADEETC 37

Endereços Notação

• 128 bit representados como oito inteiros em formato hexadecimal separados pelo carácter “dois pontos” (:)

– Ex.: 2001:0690:2008:ABCD:0100:1DF3:AAC0:0001

• Insensível a maiúsculas/minúsculas

• Formato compacto, mais fácil de manipular que a notação usada no IPv4

• Permitidas algumas simplificações de representação para facilitar a gestão

– É quase impensável memorizar endereços IPv6

24-05-2013 ISEL - ADEETC 38

Endereços Simplificações

• Para facilitar a fase inicial, em que muitos dos bits estarão a 0, é permitido um formato compacto:

– Dentro de cada bloco de 16 bit, os “nibbles” de maior peso a 0 podem ser omitidos, mantendo um único 0 caso sejam todos 0

• 1080:0000:0000:0000:0008:0800:200C:417A

• Simplificado como: 1080:0:0:0:8:800:200C:417A

– Um conjunto de blocos de 16 bit a 0 pode ser representado como:

• Uma única vez por endereço para evitar ambiguidades

• Simplificado como: 1080::8:800:200C:417A

24-05-2013 ISEL - ADEETC 39

Endereços Prefixos

• Os prefixos (componente fixa do endereço) são explicitados com a

notação CIDR (já frequentemente usada em IPv4 nos últimos anos)

• A notação FEDC:BA98:7600::/40 descreve um prefixo de 40 bit

• Evitar descrever prefixos com bits activos fora dos que compõem o

prefixo para evitar problemas de interpretação

– FEDC:BA98::0076/64 parece idêntico a FEDC:BA98:0:76::/64 mas

na realidade deve ser visto como FEDC:BA98:0000:0000 o que é

bem diferente de FEDC:BA98:0000:0076, o outro prefixo

24-05-2013 ISEL - ADEETC 40

Endereços Migração

• Para evitar problemas na conversão, os endereços IPv6 podem ser

baseados nos IPv4 já atribuídos

– Têm os 96 bit de maior peso a 0

– Os 32 bit de menor peso podem ficar representados na notação

IPv4

– O endereço IPv4 193.137.220.1 pode ser usado para criar o

endereço IPv6 ::193.137.220.1

– Na prática só usado para permitir que as estruturas de dados

usadas nos sockets (API) possam ser comuns e facilitar a

conversão de aplicações para suporte dual stack.

24-05-2013 ISEL - ADEETC 41

Endereços Uso nos URL

• Num URL aparece entre parênteses rectos

– Ex: http://[2001:1:4F3A::206:AE14]:8080/index.html

• Os “parsers” dos “browsers” têm de ser adaptados

• “Assustador” para os utilizadores

– Essencialmente para fins de diagnóstico

– Quando o DNS inclui o endereço IPv6, o browser trata de obter o

endereço correspondente ao nome indicado.

24-05-2013 ISEL - ADEETC 42

Endereços Categorias

• Unicast

– Endereços que identificam exactamente uma interface (mais correctamente, dentro do seu “scope” de validade)

• Multicast

– Identifica grupos de estações

• Anycast

– Identifica um grupo de estações

– Diferenças em relação ao multicast ao nível do encaminhamento

– Um datagrama enviado para um endereço anycast será entregue ao elemento mais próximo pertencente ao grupo

24-05-2013 ISEL - ADEETC 43

Endereços IPv6 Anycast (funcionalidade)

• O IPv6 define um endereço anycast, o qual pode ser atribuído a uma

ou mais interfaces (normalmente em nós diferentes). Os pacotes enviados para um endereço anycast serão encaminhados (routed) para a interface mais próxima que possuir esse endereço.

• A definição do mecanismo dos endereços anycast está no RFC2373 e lista as seguintes capacidades e restrições:

– Um endereço anycast não se distingue dum endereço unicast

– Um endereço anycast pode ser atribuído a múltiplas interfaces de múltiplos nós

– Um endereço anycast não deve ser atribuído a um host IPv6. Só pode ser atribuído a um router IPv6

– Um endereço anycast não pode ser utilizado como endereço de origem num header IPv6 de uma iniciação de comunicação

24-05-2013 ISEL - ADEETC 44

Endereços Distribuição Inicial

• Distribuição tendo em conta que esta seria com certeza revista no futuro – Ideia também presente na definição de opções e parâmetros

• Para evitar comprometimentos, as implementações não devem assumir

o total conhecimento dos formatos e prefixos

• Na maioria dos casos tratados como “strings” de 128 bit

• Nas tabelas de encaminhamento serão apenas prefixos com dimensão variável entre 1 e 128 bit

• Excepção para os endereços especiais. – Máquinas em geral e routers têm de dar tratamento especial aos

endereços de multicast e especiais

24-05-2013 ISEL - ADEETC 45

Endereços Distribuição Actual (1)

0000::/8 Reserved by IETF [RFC4291]






2000::/3 Global Unicast [RFC4291]




A000::/3 Reserved by IETF [RFC4291]

C000::/3 Reserved by IETF [RFC4291]

E000::/4 Reserved by IETF [RFC4291]

F000::/5 Reserved by IETF [RFC4291]

F800::/6 Reserved by IETF [RFC4291]

FC00::/7 Unique Local Unicast [RFC4193]

FE00::/9 Reserved by IETF [RFC4291]

FE80::/10 Link Local Unicast [RFC4291]

FEC0::/10 Reserved by IETF [RFC3879]

FF00::/8 Multicast [RFC4291]

24-05-2013 ISEL - ADEETC 46

Actualizado em Outubro-2012

Ref: http://www.iana.org/assignments/ipv6-address-space

Endereços Distribuição Actual (2)

• Detalhes do prefixo 2000::/3 no RFC 3587 – Têm que ter os identificadores de interface a 64bit segundo o formato EUI-64

(IEEE)

• Os endereços "unspecified", "loopback” são retirados do prefixo “0000::/8” (RFC 4291)

• Os endereços multicast têm todos o octeto de maior peso a 0xFF (FF00::/8)

• Cerca de 70% do espaço de endereçamento não tem função atribuída

24-05-2013 ISEL - ADEETC 47

Endereços Global Unicast

• Uso genérico, com conectividade global

• Atribuídos pelo IANA

– Aos “Regional Registries” (RIPE, ARIN, APNIC, ...)

– Destes aos “Providers” de primeiro nível

– Destes aos “Providers” intermediários

– Depois às entidades finais

– Estes, às suas sub-redes

24-05-2013 ISEL - ADEETC 48

Endereços Global Unicast – Formato

• Qualquer endereço excepto os começados por 000 (binário)

podem ser usados como global unicast

• Actualmente o prefixo 2000:/3 está a ser distribuído pela

IANA e assume o seguinte formato:

24-05-2013 ISEL - ADEETC 49

| 3 | 45 bits | 16 bits | 64 bits |

+---+---------------------+-----------+----------------------------+

|001|global routing prefix| subnet ID | interface ID |

+---+---------------------+-----------+----------------------------+

| n bits | 64-n bits | 64 bits |

+-------------------------+-----------+----------------------------+

| global routing prefix | subnet ID | interface ID |

+-------------------------+-----------+----------------------------+

Endereços Global Unicast – Exemplo

• O prefixo atribuído ao IPL (onde o ISEL está inserido) foi:

2001:690:2008::/48

• Decompondo:

– 001 – ID Global Unicast

– 0000 0110 1001 0 – RIRs = RIPE / FCCN

– 000 0010 0000 0000 1000 = IPL

24-05-2013 ISEL - ADEETC 50

Endereços EUI-64

• Usados para a componente “host” nos identificadores de interface auto configurados sem recurso a DHCP

• Se determinada interface tem o endereço MAC

00-90-27-17-fc-0f

O endereço EUI-64 resultante 0290:27ff:fe17:fc0f é usado como identificador da interface (últimos 64 bits) no endereço IPv6

24-05-2013 ISEL - ADEETC 51

Endereços Multicast

• Não existe broadcast no IPv6

• O multicast é usado como alternativa ao broadcast, tipicamente,

localmente por troço

• Uso de endereços “Scoped”

– Node, Link, Site, Organization, Global

– Sem TTL como era no IPv4

• Formato

– FF<flags><scope>::<multicast group>

24-05-2013 ISEL - ADEETC 52

Endereços Multicast

24-05-2013 ISEL - ADEETC 53

O bit 4 da flags quando a 0 indica um endereço permanente, bem conhecido, refere, por exemplo, o

OSPF, a 1 indica um endereço de utilização temporária.

Endereços Multicast – Scope

Valor Descrição

0 Reserved

1 Node-local scope (nome alterado para interface-local no novo draft)

2 Link-local scope

3,4 Unassigned

5 Site-local scope

6,7 Unassigned

8 Organization-local scope

9,A,B,C,D A, B, C, D Unassigned

E Global scope

F Reserved

24-05-2013 ISEL - ADEETC 54

Endereços Multicast – Reservados – Exemplos (RFC 2375)

• Alguns dos endereços de multicast reservados

24-05-2013 ISEL - ADEETC 55

Endereços Solicited-Node Multicast Address

• Este tipo de endereço é utilizado na descoberta de endereços duplicados (Duplicate Address Detection - DAD).

• Deve ser criado um por cada endereço unicast ou anycast utilizado por cada nó.

• Utilizam-se os 24 bits de menor peso dum endereço IPv6 aos quais se junta o prefixo:

FF02:0:0:0:0:1:FF00::/104

ficando este tipo de endereços entre:

FF02:0:0:0:0:1:FF00:0000 e FF02:0:0:0:0:1:FFFF:FFFF

• Exemplo:

Se uma máquina tiver o endereço “link-local”:

FE80::203:47FF:FED7:1D78

o seu endereço multicast “solicited-node” será:

FF02::1:FFD7:1D78

24-05-2013 ISEL - ADEETC 56

Endereços Multicast – Transporte sobre IEEE 802.3 e derivadas

• Os 32 bit de menor peso do endereço IPv6 multicast são juntos ao prefixo 33:33 para formar o endereço MAC a 48 bit.

• Exemplo: Uma máquina com endereço MAC: 00-03-47-D7-1D-78 tem o endereço “link-local”: fe80::203:47ff:fed7:1d78 O seu endereço multicast “solicited-node” será: ff02::1:ffd7:1d78

Os pedidos ICMPv6 “Neighbour Solicitation” das máquinas adjacentes terão como endereço IPv6 destino o endereço “Solicited-Node” e como endereço MAC destino:

33-33-ff-d7-1d-78

24-05-2013 ISEL - ADEETC 57

Endereços Especiais

• Unspecified:

– Usado quando ainda nenhum endereço está disponível

• Pedido inicial de DHCP

• Detecção de endereços duplicados

– 0:0:0:0:0:0:0:0 ou ::

• Loopback:

– Identifica a própria máquina como o 127.0.0.1 no IPv4

– 0:0:0:0:0:0:0:1 ou ::1

24-05-2013 ISEL - ADEETC 58

Endereços “Scoped” – Link-Local

• Para ser usado entre máquinas sobre o mesmo troço (VLAN, subnet, etc)

• Não podem ser encaminhados

• Automaticamente configurados para cada interface

– Baseado no endereço MAC da interface

• Formato

– FE80:0:0:0:<identificador da interface EUI-64>

• Dá aos nós um endereço para iniciarem as comunicações

24-05-2013 ISEL - ADEETC 59

Endereços “Scoped” – Site-Local / Unique Local Unicast

• Só podem ser usados entre as máquinas de uma rede autónoma

• Não podem ser encaminhados para o exterior (Internet)

• Similares aos endereços privados no IPv4 (RFC1918)

• Não configurados automaticamente

• Formato

– FEC0:0:0:<subnet id>:<interface id>

– “Subnet id” a 16bit = 64K subredes

• Permite um plano de endereçamento para uma rede completa

• Descontinuado, apesar de alguns sistemas ainda os usarem (Windows nos forwarders DNS por omissão)

• Actualmente com funcionalidade similar definida no RFC4193 mas usando o bloco FC00::/7 (Unique Local Unicast)

24-05-2013 ISEL - ADEETC 60

Endereços Exigidos por máquina terminal

• Link-local para cada interface

• Loopback

• Unicast atribuídos

• Multicast “all-nodes”

• Multicast “solicited-node” para cada um dos seus endereços unicast e anycast

• Multicast de cada um dos grupos aos quais pertença

• Site-local, caso sejam usados

24-05-2013 ISEL - ADEETC 61

Endereços Exigidos para os routers

• Todos os requeridos para uma máquina terminal mais:

– Multicast “All-routers”

– Multicast específicos aos protocolos de encaminhamento

– Anycast de “subnet-router” nas interfaces configuradas para funcionarem como tal

– Outros de Anycast configurados

24-05-2013 ISEL - ADEETC 62

Endereços Selecção problemas

• Uma máquina pode ter vários endereços IPv6

• Qual deve usar como origem ou destino de determinada comunicação?

• Algumas situações a contemplar:

– Os endereços “scoped” são inatingíveis dependendo do destino

– Endereços preferidos e descontinuados

– IPv4 ou IPv6 quando o DNS retornar os dois

– IPv4 “local-scope” (169.254/16) e IPv6 “global scope”

– IPv6 “local scope” e IPv4 “global scope”

– Endereços “Mobile IP”, temporários, de scope, etc.

24-05-2013 ISEL - ADEETC 63

4 - ICMPv6

Evolução

• Incorpora as funções do ICMPv4, IGMP (Internet Group Multicast Protocol) e ARP/RARP

• Foi introduzido o ND (Neighbor Discovery)

• Suporte do Mobile IPv6

• Descontinua funcionalidades definidas mas não usadas do ICMPv4

• Incompatível com o ICMPv4

• Identificado com HType = 58 para evitar confusões

• Conhecido como ICMPv6

24-05-2013 ISEL - ADEETC 65

Formato geral das mensagens

Type Code Checksum

Message body

24-05-2013 ISEL - ADEETC 66

• Type (1 byte) - Especifica o tipo da mensagem

• Code (1 byte) - Especifica um “tipo” dentro do tipo

• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do de IPv6

• Message body (variável) - Depende do type e do code. Não deve exceder 1280 bytes.

Tipos de mensagens – Campo Type

• Mensagens de erro

– 1 a 4 - Descrevem erros

• Mensagens de informação

– 128 e 129 - Equivalente às mensagens de “echo” do ICMPv4

– 130 a 132 - Usadas para as funções correspondentes ao IGMP (no

IPv4) – registo de grupos de multicast

– 133 a 140 - Usados nas funções de “Neighbour Discovery” e auto

configuração

– 141 e 142 - Inverse Neighbour Discovery (RFC 3122)

– 150 a 153 – Mobile IPv6

24-05-2013 ISEL - ADEETC 67

Regras de processamento das mensagens

(RFC 2463) (1)

• Se um nó receber uma mensagem de erro ICMPv6 de tipo

desconhecido deve passá-la para a camada superior.

• Se um nó receber uma mensagem de informação ICMPv6

de tipo desconhecido deve jogá-la fora silenciosamente.

24-05-2013 ISEL - ADEETC 68

Regras de processamento das mensagens

(RFC 2463) (2)

• Se uma mensagem deve ser passada para o protocolo da

camada superior este é determinado analisando o header do

pacote incluído nos dados, caso não seja possível determinar

o protocolo, por existirem demasiados headers no pacote

IPv6, o pacote ICMPv6 deve ser descarregado

silenciosamente.

• Deve ser incluída na mensagem ICMPv6 de erro, tanto

quanto possível da mensagem que causou o erro. Não deve

ultrapassar o MTU mínimo.

24-05-2013 ISEL - ADEETC 69

Tipos de mensagens de erro

1 Destination Unreachable 0 No route to destination

1 Communication with destination administratively prohibited

2 Beyond scope of source address (draft)

3 Address unreachable

4 Port unreachable

2 Packet Too Big

3 Time Exceeded 0 Hop limit exceeded in transit

1 Fragment reassembly time exceeded

4 Parameter Problem 0 Erroneous header field encontered

1 Unrecognized next header type encontered

2 Unrecognized IPv6 option encontered

128 Echo Request

129 Echo Reply

130 Multicast Listener Query

131 Multicast Listener Report

132 Multicast Listener Reduction

133 Router Solicitation

134 Router Advertisement

135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect

138 Router Renumbering

139 ICMP Node Information Query

140 ICMP Node Information Response

141 Inverse ND Solicitation

142 Inverse ND Advertisement

150 ICMP Home Agent Address Discovery Request

151 ICMP Home Agent Address Discovery Reply

152 ICMP Mobile Prefix Solicitation Message Format

153 ICMP Mobile Prefix Advertisement Message Format

Tipo de mensagem Tipo de código

Tipos definidos no ICMPv6

Mensagens de erro

Mensagens de informação

24-05-2013 ISEL - ADEETC 70

Mensagens de erro - Causas

• Quatro causas possíveis

– Destino inatingível

– Mensagem demasiado grande

– “Hop Count” excedido

– Problema de parâmetros

• Não devem ser enviadas

– Em resposta a pacotes de multicast (*- excepções)

– Em resposta a pacotes ICMP (loops)

24-05-2013 ISEL - ADEETC 71

Mensagem “Destination Unrechable”

Type Code Checksum

Unused

Data

24-05-2013 ISEL - ADEETC 72

• Type (1 byte) – 1

• Code (1 byte) – 0 a 4


• Unused (4 bytes)

• Data (variável) – Header do IPv6 e tanto quanto possível dos dados originais. Não deve exceder 1280 bytes.

Mensagem “Destination Unrechable”

• “Destination Unrechable” (Type =1)

– Code = 0 – No route to destination (no encaminhamento)

– Code = 1 – Communication with destination administratively

prohibited (packet filter)

– Code = 3 – Address unreachable (entrega final)

– Code = 4 – Port unreachable (máquina final sem o serviço activo)

24-05-2013 ISEL - ADEETC 73

Mensagem “Packet too big”

Type Code

Data

Checksum

MTU


• Code (1 byte) – 0


• MTU (4 bytes) – “Maximum Transmit Unit” da ligação seguinte


24-05-2013 ISEL - ADEETC 74

Mensagem “Packet too big”

• “Packet too big” (Type =2, Code =0)

– MTU da ligação que motivou o erro

– Este tipo de mensagem é uma excepção à regra de que não

devem ser geradas respostas a pacotes com endereço IPv6

destino multicast, endereço link-layer multicast ou broadcast.

24-05-2013 ISEL - ADEETC 75

Mensagem “Time exceeded”

Type Code Checksum

Unused

Data


• Code (1 byte) – 0 a 1

• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do IPv6

• Unused (4 bytes) - Deve ser zero


24-05-2013 ISEL - ADEETC 76

Mensagem “Time exceeded”

• “Time Exceeded” (Type = 3)

– Code =0 – Hop limit exceeded in transit

– Code =1 – Fragment reassembly time exceeded (fragmentos

perdidos)

• Utilizado no TraceRoute

24-05-2013 ISEL - ADEETC 77


• Todos as mensagens definidas no IPv6, que não são de erro, são

consideradas como sendo de informação.

• Têm funções tão distintas como dar suporte ao Ping, ao multicast, à

descoberta de vizinhos, à auto configuração, etc.

24-05-2013 ISEL - ADEETC 78


128 Echo Request

129 Echo Reply

130 Multicast Listener Query

131 Multicast Listener Report

132 Multicast Listener Reduction

133 Router Solicitation

134 Router Advertisement

135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect

138 Router Renumbering

139 ICMP Node Information Query

140 ICMP Node Information Response

141 Inverse ND Solicitation

142 Inverse ND Advertisement

150 ICMP Home Agent Address Discovery Request

151 ICMP Home Agent Address Discovery Reply

152 ICMP Mobile Prefix Solicitation Message Format

153 ICMP Mobile Prefix Advertisement Message Format


Tipo de mensagem Tipo de código

Tipos definidos no ICMPv6

24-05-2013 ISEL - ADEETC 79

Mensagens Echo Request e Echo Reply

Type Code

Data

Seq. NumberIdentifier

Checksum

• Type (1 byte) – 128 (Request) e 129 (Reply

• Code (1 byte) –

• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do IPv

• Identifier (2 bytes) – Associar um Echo Request a um Echo Reply

• Sequence number (2 bytes) - Associar um Echo Request ao Echo Reply

• Data (variável) – Podem ser qualquer dados.

24-05-2013 ISEL - ADEETC 80

Mensagens Echo Request e Echo Reply

• Mensagens com formato semelhante às do IPv4.

• Uma das utilizações principais é no suporte do comando

Ping (Packet INternet Groper).

• As mensagens de Echo Request e Echo Reply podem ser

autenticadas usando um header de autenticação IPv6.

24-05-2013 ISEL - ADEETC 81

Descoberta de vizinhos (RFC 4861)

• Um vizinho, neste contexto, é uma máquina ou router, no mesmo segmento.

• Substitui o ARP do IPv4, com funcionalidades acrescidas.

• Baseado em mensagens ICMPv6.

• Usado para:

– Saber o endereço “data link” das máquinas vizinhas

– Descobrir routers vizinhos

– Manter uma relação da conectividade com os vizinhos

– Envio de informações acerca da rede para máquinas e routers

• Protocolo usado na auto configuração de máquinas

• Todas as mensagens ND (Neighbor Discovery) têm de ter “Hop Limit” a 255

– Para se ter a certeza de que foram iniciadas e terminam no mesmo troço, se o “Hop Limit” for inferior a mensagem vai para o lixo.

• Utiliza as mensagens de Neighbor Solicitation e de Neighbor Advertisement

24-05-2013 ISEL - ADEETC 82

Descoberta de vizinhos (RFC 4861)

• No ICMPv6 este procedimento vem substituir o ARP e o ICMP Router Discovery e o Redirect do ICMPv4 usados com o IPv4. Acrescenta também novas funcionalidades.

• O ND é utilizado pelos nós IPv6 para os seguintes propósitos:

– Determinar os endereços de nível 2 dos nós no mesmo segmento

– Encontrar os routers vizinhos que possam encaminhar os seus pacotes

– Manter actualizada a lista de vizinhos que são atingíveis e detectar endereços da camada data link alterados

24-05-2013 ISEL - ADEETC 83

Descoberta de vizinhos (RFC 4861) (1)

• Melhorias face ao IPv4:

– A descoberta do router é agora parte do protocolo

– As mensagens de Router Advertisement contêm os endereços data link do router. O mesmo se passa com a mensagem de Redirect.

– As mensagens Router Advertisement contêm o prefixo do segmento.

– Os mecanismos de descoberta de vizinhos permite renumerar a rede facilmente.

– As mensagens de Router Advertisement possibilitam o endereçamento stateless (autoconfiguração) e podem notificar os hosts de quando devem utilizar configuração de endereços stateful (DHCP).

24-05-2013 ISEL - ADEETC 84

Descoberta de vizinhos (RFC 4861) (2)

• Os routers podem avisar sobre o MTU a utilizar num segmento.

• Múltiplos prefixos podem ser atribuídos a um segmento.

• Detecção de vizinhos não contactáveis faz parte do protocolo.

• Router Advertisement e ICMP Redirects usam endereços link-

local para identificar os routers.

• As mensagens de descoberta de vizinhos têm um hop limit de

255. Pedidos com hop limit inferior não são respondidos.

• A descoberta de vizinhos é utilizada para a detecção de

endereços IP duplicados num segmento.

• Podem ser utilizados mecanismos de segurança do próprio IPv6

na descoberta de vizinhos.

24-05-2013 ISEL - ADEETC 85

Router Solicitation e Router Advertisement

• Os routers enviam periodicamente mensagens de Router

Advertisement.

• Um host pode pedir uma mensagem de Router Advertisement

enviando uma mensagem de Router Solicitation. Isto provoca um envio

imediato de mensagens de Router Advertisement independentemente

do timing do router.

24-05-2013 ISEL - ADEETC 86

Mensagem Router Solicitation

Type Code Checksum

Reserved

Options

• Type (1 byte) – 133



• Reserved (4 bytes)

• Options (variável) – Endereço da camada data link do emissor, se conhecida

24-05-2013 ISEL - ADEETC 87

Mensagem Router Solicitation

• O header do datagrama IPv6 que transporta esta mensagem ICMPv6

deve ter como endereço destino o endereço de multicast “all-routers

multicast” FF02::2

• Se o endereço de origem não for especificado (tudo zeros), o campo

de opção não é usado.

• Os routers que receberem a mensagem Router Solicitation devem

responder com a mensagem Router Advertisement.

24-05-2013 ISEL - ADEETC 88

Mensagem Router Advertisement (1)

Type CodeCurrent

hop limitFlags

Retrans Timer

Options

Checksum

Reachable Time

Router Lifetime

24-05-2013 ISEL - ADEETC 89

• Type (1 byte) – 134



• Current Hop Limit (1 byte) – Valor por defeito para o campo Hop Limit


• Flags (1 byte):

– M – Managed address config flag (1 bit, RFC4861)

– O – Other stateful config flag (1 bit, RFC4861)

– H – Mobile IPv6 Home Agent Flag (1 bit, RFC3775)

– Prf – Router selection preferences (2 bit, RFC4191) • 00 Medium, 11 Low, 01 High, 10 Reserved

– P – Neighbor discovery proxy flag (1 bit, RFC4389)

– R – Reserved (2 bit)

24-05-2013 ISEL - ADEETC 90


• Pelo endereço IPv6 utilizado no pacote de transporte da mensagem ICMPv6 pode-se determinar se esta é periódica ou solicitada, se o endereço for “all-nodes multicast” (FF02::1) é periódica, se for um endereço unicast é solicitada. – Alguns routers não respeitam esta regra.

• O Hop Limit no pacote IPv6 de transporte desta mensagem é 255.

• O bit M indica, se for 1, que deve ser utilizada configuração stateful

baseada em DHCPv6, para além da eventual auto-configuração.

• O bit O indica que podem ser obtidos parâmetros adicionais usando DHCPv6 (normalmente os DNS resolvers) como complemento à configuração stateless.

24-05-2013 ISEL - ADEETC 91


• O campo Router Lifetime só é importante se o router for um router por

omissão para os nós do link. O valor 0 indica que o router não está

disponível para ser o router por omissão, um valor diferente indica o

tempo de vida deste router enquanto router por omissão. Máximo de

18.2 horas.

• O campo Reachable Time é o tempo durante o qual um host assume

que os vizinhos podem ser atingidos após terem recebido a

confirmação que os podem contactar. Zero significa não especificado.

24-05-2013 ISEL - ADEETC 92


• O campo Retrans Timer é utilizado pelos mecanismos de resolução de

endereços e de detecção de vizinhos não contactáveis; indica o tempo

entre transmissões desta mensagem.

• O campo de opções pode conter varias opções com os tipos:

– 1 - Endereço de origem data-link

– 2 - MTU

– 3 - Informação do prefixo

– 25 – Recursive DNS servers (RFC6106)

– 31 – DNS Search list (RFC6106)

24-05-2013 ISEL - ADEETC 93

Mensagem Neighbour Solicitation

• Substitui o ARP do IPv4, com funcionalidades acrescidas

• Baseado em mensagens ICMPv6

• Usado para:

– Saber o endereço “data link” das máquinas vizinhas

– Descobrir routers vizinhos

– Manter uma relação de conectividade com os vizinhos

– Envio de informações acerca da rede por máquinas e routers

• Protocolo usado na auto-configuração de máquinas

• Todas as mensagens ND têm de ter “Hop Limit” a 255

– Para se ter a certeza de que foram iniciadas e terminam no mesmo troço. Se “Hop Limit” menor que 255, lixo!

• Utiliza as mensagens de Neighbor Solicitation e de Neighbor Advertisement

24-05-2013 ISEL - ADEETC 94

Type Code

Options

Checksum

Reserved

Target Address

24-05-2013 ISEL - ADEETC 95

• Type – 135

• Target address – Utilizado apenas quando da detecção de vizinhos

• Options – Endereço data link de origem


• Enviada pelas máquinas para determinarem o endereço “data link” das

máquinas adjacentes

• =~ ARP request

• Conteúdo da mensagem

– Endereço origem = Endereço “link-local”

– Destino = Endereço multicast “solicited-node”

– Os dados contêm o endereço “data link” da origem

• Para eficiência (caching)

– A pergunta é: diz-me o teu endereço de “data link”?

– ICMP Type 135

24-05-2013 ISEL - ADEETC 96


Type Code

Options

Checksum

Flags

Target Address

24-05-2013 ISEL - ADEETC 97

Type – 136

Flags (4 bytes):

R (1 bit) - router flag

S (1 bit) - solicited flag

O (1 bit) - override flag

Reservados

Target address – Utilizado apenas quando da detecção de vizinhos

Options – Endereço data link

Mensagem Neighbour Advertisement

• Resposta a um Neighbour Solicitation

• =~ ARP response

• Descrição do pacote

– ICMPv6 Type 136

– Endereço origem = Endereço “link-local”

– Destino = Endereço de quem perguntou

– Campo Option inclui o endereço “data link” solicitado.

24-05-2013 ISEL - ADEETC 98

Mensagem Neighbor Advertisement

Auto configuração (1)

• Foi pensada de maneira a ser possível eliminar a tarefa de configuração manual de qualquer máquina que utilize IPv6 antes de as ligar à rede, qualquer que seja a dimensão desta última.

• Se o IPv6 passar a ser usado por todos os tipos de equipamentos, como telefones, electrodomésticos, etc. não faz sentido dependerem de servidores DHCP.

• Em IPv6 pode-se usar configuração stateful, dependente dum servidor DHCP, simplesmente configuração stateless/auto configuração ou ambas.

24-05-2013 ISEL - ADEETC 99

Auto configuração (2)

• As máquinas podem gerar os seus endereços IPv6 a partir dos seus endereços MAC e de informação recebida dos routers.

• Por motivos de anonimização é comum gerarem adicionalmente endereços temporários com a informação recebida dos routers e usando como componente host um valor aleatório.

• Os routers podem anunciar vários prefixos sendo estes utilizados pelas máquinas.

• A alteração de prefixo(s) numa rede implica apenas a alteração destes no router. Por exemplo, se se mudar de ISP com a consequente necessidade de utilização de novos prefixos. Todas as máquinas ligadas a este router se irão auto configurar com o novo prefixo.

24-05-2013 ISEL - ADEETC 100

• Um endereço IPv6 pode estar em vários estados:

– Tentative address – Ainda não foi testada a sua unicidade

– Preferred address – É único e pode ser usado sem restrições

– Deprecated address – O seu tempo expirou. Pode ser usado mas

não como endereço de origem de novas comunicações

24-05-2013 ISEL - ADEETC 101

Auto configuração – Estados dos endereços

Auto configuração – DAD (1)

Quando um nó se auto configura executa os seguintes passos:

1 – É gerado um endereço link-local usando o prefixo FE80 e

juntando-lhe a parte obtida a partir do identificador da interface (EUI-64) ou a partir da geração dum número

aleatório com 64 bits se o EUI-64 não for utilizado.

2 – O nó junta-se aos seguintes grupos de multicast: all-nodes multicast (FF02::1) e solicited-node multicast para o endereço que está a tentar usar.

24-05-2013 ISEL - ADEETC 102


3 – É enviada uma mensagem de Neighbor Solicitation com o

endereço que está a tentar usar como endereço target; o

endereço IP de origem vai todo a zeros; como endereço destino

vai o solicited-node multicast. Isto detecta se existe outro nó com

o mesmo endereço no segmento. Se o nó existir ele responde

com uma mensagem Neighbor Advertisement e o mecanismo de

auto configuração pára. Neste caso é necessária a configuração

manual da máquina. Se não houver resposta ao Neighbor

Solicitation é seguro utilizar o endereço; o endereço é atribuído à

interface e o estado do endereço passa a “prefered”. Até aqui o

processo é igual para máquinas e routers. Só as máquinas, os

routers não, é que executam o próximo passo.

24-05-2013 ISEL - ADEETC 103


4 – De forma a determinar que routers existem e qual os prefixos, uma máquina envia uma mensagem de Router Solicitation para o endereço all-routers multicast FF02::2.

5 – Todos os routers no segmento respondem com a mensagem Router Advertisement. Para cada prefixo em Router Advertisement com a flag de autonomous activa, é gerado um endereço, combinando o prefixo com a parte obtida a partir do identificador da interface. Estes endereços são adicionados à lista de endereços da interface.

24-05-2013 ISEL - ADEETC 104

Auto configuração

• Se não existir um router numa rede uma máquina poderá gerar um endereço link-local apenas com o prefixo FE80, sendo este suficiente para comunicar com os outros nós no segmento a que está ligada.

• As configurações stateless e stateful podem ser associadas de maneira a que um nó auto configure os seus endereços mas recorra a um servidor, por exemplo de DHCP, para obter parâmetros adicionais.

• Um endereço IPv6 é atribuído a um nó por um determinado tempo. Terminado esse tempo o endereço torna-se inválido. Para ter a certeza que um endereço é único num segmento um nó deve correr o processo DAD (RFC 2462).

24-05-2013 ISEL - ADEETC 105

Descoberta do MTU do caminho (RFC 1981)

• No IPv4 os routers podiam fragmentar os pacotes se necessário.

• No IPv6 os routers não fragmentam os pacotes. Quem envia é que é responsável por essa tarefa.

• A “descoberta do MTU do caminho” é responsável por determinar qual o maior MTU possível em cada caminho utilizado.

• O MTU dum caminho é o menor MTU dos segmentos desde a origem até ao destino.

• O MTU mínimo é de 1280 bytes.

24-05-2013 ISEL - ADEETC 106

Descoberta do MTU do caminho (RFC 1981)

• O processo de descoberta começa por enviar um pacote com o MTU do segmento local. Qualquer router que não possa deixar passar o pacote por MTU excessivo deita-o fora e devolve mensagem de erro ICMPv6 “Packet Too Big”. Esta mensagem inclui o MTU do próximo segmento onde o pacote não cabia. O pacote deve ser enviado de novo, com o novo MTU. E, assim sucessivamente até não haver mensagens de erro por MTU excessivo.

• No caso de pacotes multicast são devolvidas as mensagem de erro ICMPv6 “Packet Too Big” (excepção à regra de em multicast não serem devolvidos erros) sendo o MTU a utilizar o menor de todos os MTUs devolvidos.

• Como o MTU dum caminho pode variar a origem dos pacotes tentará aumentar a sua dimensão periodicamente.

24-05-2013 ISEL - ADEETC 107

24-05-2013 ISEL - DEETC - RCD - CRC 108

Gestão de grupos de multicast

• Endereços de grupo de multicast são utilizados como identificador dum

grupo de nós.

• Os endereços multicast são identificados pelo byte de maior ordem que

tem o valor FF.

• É necessário um protocolo para gerir o encaminhamento eficiente dos

pacotes com endereços multicast como destino.


Gestão de grupos de multicast

• No IPv4 a gestão dos grupos de multicast era efectuada pelo IGMP (Internet Group Multicast Protocol).

• O IPv6 utiliza mensagens ICMPv6 para esta função e designam-se por Multicast Listener Discovery (MLD) (RFC 2710).

• Uma mensagem MLD é enviada com um endereço de origem IPv6 do tipo link-local e um hop limit de 1 para se ter a certeza que se mantém na rede local. Se o pacote tiver o header de Hop-by-hop terá a flag de Router Alert activada para que os routers não o ignorem, mesmo que não estejam à “escuta” naquele grupo de multicast.


Mensagem Multicast Listener

• Type (1 byte) – 130 (query), 131(report) e 132 (done)

• Máx. Response Delay (2 bytes) – Valor máximo (em milisegundos) do intervalo para o valor aleatório a gerar relativo ao atraso a introduzir na resposta. Pode-se evitar assim que várias máquinas dêem a mesma resposta – quando uma vê que outra já respondeu cala-se.

Type Code

Multicast Address

Max Response Delay Reserved

Checksum



Existem dois tipos de mensagens de query:

• Uma é o query geral que é usada para determinar que endereços de

multicast têm “ouvintes” no segmento;

• O outro é um query especifico para determinar se um determinado

endereço multicast tem “ouvintes” no segmento.

O campo “multicast address” é 0 nos query gerais. Nos outros casos

contém o endereço multicast específico sobre o qual se está a inquirir.

Os querys gerais são enviados para o endereço link-local “all-nodes

multicast” FF02::1.

O tempo de resposta aos querys é aleatório.



Nas mensagens de Report e Done o campo de “multicast address” contém

o endereço de multicast em que a máquina escuta ou que está a deixar.

Os routers utilizam o MLD para descobrirem que endereços de multicast

são usados em cada um dos seus segmentos.

Para cada segmento o router mantêm uma lista de endereços multicast

que aí são usados.


Tipos de mensagens e endereços destino

Tipo de mensagem Endereço IPv6 destino

General query Link-local scope all-nodes (FF02::1)

Multicast-Address-Specific Query Endereço multicast a ser questionado

Report Endereço multicast a ser relatado

Done Link-local scope all-routers (FF02::2)

5 - Segurança em IPv6


Tipos de ameaças

Negação de serviço, interrupção

Modificação, introdução ou eliminação de informação

Recolha de informação.


Requisitos de segurança

• Confidencialidade

– A informação guardada ou transmitida não pode ser lida ou alterada por

entidades não autorizadas.

• Integridade

– Qualquer alteração da informação guardada ou transmitida deve ser detectada.

• Autenticidade

– A identidade do fornecedor de informação (e em alguns casos do receptor) deve

poder ser comprovada.

• Não-repudiação

– Uma acção especifica como enviar, receber ou apagar informação não pode ser

negada (não fui eu!) por qualquer das partes envolvidas.


Técnicas básicas

• Encriptação – Fornecer confidencialidade

– Encriptação simétrica – chaves privadas conhecidas por ambos

os intervenientes - Problemas: distribuição, missing obligation

(quem cifrou a informação?)

– Encriptação assimétrica – (chave pública, chave privada)

• Checksums seguros – Fornecer integridade e autenticidade

– Assinaturas digitais

• Conjunção da cifra assimétrica e simétrica para se

conseguir confidencialidade e autenticidade


Soluções actuais

• Filtragem de pacotes nos routers e firewalls

• Protecção da camada de transporte

– Secure Socket Layer (SSL) -> Transport Layer Security (TLS) do

IETF RFC2246

• Segurança das aplicações

– Secure shell (SSH)

– Kerberos

– Pretty Good Privacy (PGP)


Assuntos de segurança em aberto na Internet

• Demasiados sistemas de cifra/autenticação que não funcionam juntos.

• Falta de uma infra-estrutura pública de distribuição de chaves (PKI).

• Debate sobre que serviços de segurança e em que camada?

• Muitos componentes e muitas dependências mútuas leva a uma maior

complexidade.

• Módulos e métodos proprietários muitas vezes incompatíveis com os

sistemas de segurança já instalados.

• Politicas distintas de segurança uns cifram tudo, outros apenas

algumas coisas, outros ainda tudo mas de formas diferentes.

• Problemas de integração dos produtos de segurança.

• Bugs e deficiências no software utilizado.


Elementos de segurança Associações de Segurança (SA)

• Os parceiros numa comunicação necessitam acordar num conjunto de informação antes de poderem utilizar os elementos de segurança do IPv6: – Uma chave

– Algoritmo de autenticação e/ou de cifra a utilizar e respectivos parâmetros

• Este tipo de acordos constituem uma Associação de Segurança (SA - Security Association) entre parceiros duma comunicação.

• Os SAs são unidireccionais e é necessária uma por cada serviço de segurança; donde, dois parceiros que pretendam comunicar e que pretendam ambos cifrar e autenticar uma ligação bidirecional necessitam dum total de quatro SAs (uma por cada serviço – autenticação e cifra, em cada direcção).



• Dois tipos de SA: – Modo transporte

– Modo túnel

• Modo transporte

• O SA é definido entre dois sistemas finais e descreve quer a autenticação quer a cifra da carga de todos os pacotes IP relacionados com essa ligação em particular.

• Modo túnel

• O SA é definido entre dois gateways de segurança que colocam os pacotes IP dentro de outros pacotes IP aplicando quer cifra quer autenticação a todo o pacote interior, incluindo o header.



• Alguns problemas:

– Na autenticação em modo transporte alguns campos no cabeçalho

IP não são protegidos. Algumas aplicações podem necessitar de

protecção para esses campos.

– A reescrita dos campos de endereços IP pelo NAT não funciona no

modo transporte, porque o checksum protege os campos de

endereços.

• Os problemas anteriores podem ser resolvidos através da

utilização de túneis entre duas entidades de segurança.


Elementos de segurança Autenticação

• Authentication Extension Header – AH - (Next Header tipo

51) providencia integridade e autenticação para todos os

dados transportados em pacotes IP entre os extremos.

Na sequência de Extension Headers o AH (se presente) está

localizado a seguir ao End-to-end Extension Header (se

presente) e antes do Encrypted Security Payload (ESP)

Extension Header (Next Header tipo 50) (se presente), e

antes dos headers dos protocolos de transporte (ex. TCP e

UDP), controlo da rede (ex. ICMP) ou de encaminhamento

(ex. OSPF)



Payload

Flow label

Source IP address

Destination address

Payload

lengthReserved

TCP header

Sequence number

Acknowledgment number

H-len Reserved Code bitsWindow

size

Source port Destination port

Sequence Number

Authentication data (variable length)

Checksum Urgent pointer

Options Padding

Autentication header

Next

header

Payload lengthNext

headerHop limit Security Parameter Index (SPI)

IP header

Version Class

Cada header de Autentication Extension contém uma sequência fixa de

elementos do protocolo:

• Next header (1 byte)

• Payload length (1 byte) – Dimensão dos campos, medido em

múltiplos de 32 bits, a seguir ao SPI

• Security Parameter Index (SPI) (4 bytes) – Indica que algoritmo de

checksum foi utilizado.



• Sequence number (4 bytes) – Evita ataques por repetição se a

ligação utilizar menos do que 232 pacotes.

• Authentication data (dimensão variável) - Checksum seguro, do ponto

de vista da cifra, sobre a carga (payload), assim como sobre alguns

campos do IP e alguns headers, concatenado com a chave secreta

negociada durante a iniciação do Security Association (SA) e indexada

pelo campo SPI.

Payload

Flow label

Source IP address

Destination address

Payload

lengthReserved

TCP header

Sequence number



size


Sequence Number



Options Padding


Next

header

Payload lengthNext


IP header

Version Class



Payload

(Variable

length)

Flow label

Source IP address

Destination address

Payload

lengthReserved

Inner IP header

Version Class

TCP header

Sequence number



size


Sequence Number



Options Padding

Flow label

Payload length


Next

header

Next

headerHop limitPayload length

Next


IP header

Version Class

Source IP address

Destination address

Utilização de túneis para transporte de informação autenticada.


Elementos de segurança Cifra

Payload

(Variable

length)

Flow label

Source IP address

Destination address

TCP header

Sequence number



size



Options Padding

Encryption header

Security Parameter Index (SPI)

Payload lengthNext

headerHop limit Sequence Number

IP header

Version Class

Encryption parameters (e.g. Initialization

vector)

Encryption trailer

Padding

Padding length

Payload type

Authentication data (optimal)

Sempre que for necessária protecção contra modificação ou publicação da

informação é necessário utilizar cifra.

O Encrypted Security Payload Extension header (ESP, Next header tipo

50) providencia integridade e confidencialidade aos dados transportados

nos pacotes IP entre os extremos da ligação.



Payload

(Variable

length)

Flow label

Source IP address

Destination address

TCP header

Sequence number



size



Options Padding

Encryption header


Payload lengthNext


IP header

Version Class

Encryption parameters (e.g. Initialization

vector)

Encryption trailer

Padding

Padding length

Payload type


Cada header ESP contém uma sequência fixa de elementos do protocolo,

sendo o único header dividido em duas partes:

Security parameter Index (4 bytes): Indica o algoritmo de cifra utilizado

(o DES-CBC - Data Encryption Standard em modo Cypher Block

Chaining - deve ser sempre suportado).

Sequence Number (4 bytes): Evita ataques por repetição se a ligação

utilizar menos do que 232 pacotes.

Encryption parameters: Vector de iniciação da cifra, se necessário.



Payload

(Variable

length)

Flow label

Source IP address

Destination address

Inner IP header

Version Class

TCP header

Sequence number



size



Options Padding

Flow label

Payload length

Encryption header

Next

headerHop limit


Payload lengthNext


IP header

Version Class

Source IP addressEncryption parameters (e.g. Initialization

vector)

Destination address

Encryption trailer

Padding

Padding length

Payload type


Versão utilizando túnel IP.


Segurança Combinar autenticação e cifra

• A ideia original era providenciar integridade, autenticação e

confidencialidade aos pacotes IP utilizando ambos os

headers AH e ESP.

• Dado que, na maioria dos casos, a utilização de autenticação

e de cifra é simultânea a função de autenticação foi incluída

no ESP (à cauda). Evita-se assim a utilização simultânea de

dois headers de extensão com o consequente aumento da

dimensão do datagrama IP.

• O programador pode optar por um ou outro modo de

conseguir autenticação e cifra em simultâneo.


Segurança Problemas

• Túneis: Análise nos gateways e firewalls.

• NAT: A reescrita dos headers IP colide com os mecanismos

de autenticação utilizados.

• Qualidade de serviço: A perda de pacotes IP é considerada

uma violação da segurança.

• Mobilidade: A atribuição de endereços IP dinâmicos neste

contexto colide com os mecanismos de segurança.

6 - Qualidade de serviço em IPv6


Qualidade de serviço

No IPv4 o campo TOS (Type Of Service) no header IP não teve grande

sucesso dado basear-se em auto classificação de umas aplicações face a

outras.

A indicação do tipo de serviço pretendido pode não ser suficiente sendo

preferível a indicação de limites inferiores e superiores.

O QoS continua a ser um tópico de pesquisa.


Qualidade de serviço Paradigmas

• QoS baseado em sistemas finais – Simplicidade, não se aumenta a escala facilmente para ser utilizável com verdadeiros serviços multimédia.

• QoS baseado em serviços – Diferentes grupos de multicast para diferentes tipos de tráfego (por exemplo áudio a 5.5, 11, 22 e 44KHz). Quem envia e quem encaminha (routers) tem de estar consciente da diferenciação a dar ao diferente tráfego.

• QoS baseado em classe/prioridade – Para lidar com tráfego multimédia os routers necessitam de informação explicita sobre a forma como lidar com os pacotes com diferentes necessidades de serviço.

• QoS baseado em reserva de recursos – É a forma mais complexa de suporte de QoS e que implica o conhecimento dos routers sobre os fluxos que os atravessam. Utiliza, por exemplo, RSVP.



• O IPv6 não impõe qualquer tipo de suporte de QoS.

• O protocolo IPv6 suporta vários mecanismos de suporte de QoS, quer no header IP base quer nos headers de extensão.

• Header IPv6 base

• Fluxos

• Comunicado aos routers por RSVP, header IP base ou header Hop-By-Hop extension. Os fluxos são identificados por endereço de origem e campo flow label quando diferente de zero.

• Todos os pacotes dum fluxo devem possuir headers Hop-by-hop e Routing extension idênticos, com excepção do campo Next header.

• Flow label

• O IPv6 possui um campo flow label de 20 bits no header base e o seu valor pode ser escolhido aleatoriamente entre 00001 e FFFFF. Quando não for necessário deve ir a zero.



• Priority/class

• Possui um campo de 8 bits no header base. Tendo o flow

label passado de 24 para 20 bits.

• É possível utilizar este campo para a diferenciação de

serviços.


Referências

• #1 - http://www.huitema.net/ipv6-howlong.asp

• #2 - http://www.di.fc.ul.pt/~pmv/ipv6.ppt

• #3 - IPv6 Essentials – Silvia Hagen – O’Reilly

• #4 - IPv6 The New Internet Protocol, 2nd Edition – Christian Huitema – Prentice Hall PTR ( http://www.prenhall.com )

• #5 - http://www.iana.org/ipaddress/ip-addresses.htm

• #6 - http://www.viagenie.qc.ca/en/ipv6/

• #7 - Internet Protocol, Version 6 (IPv6) Specification , RFC 2460, December 1998, http://www.normos.org/ietf/rfc/rfc2460.txt

• #8 - IP version 6 Addressing Architecture, Hinden and Deering, RFC2373, July 1998, http://www.normos.org/ietf/rfc/rfc2373.txt

• #9 - An IPv6 Aggregatable Global Unicast Address Format , Hinden, O'Dell and Deering, RFC 2374, July 1998, http://www.normos.org/ietf/rfc/rfc2374.txt

• #10 - Default Address Selection for IPv6, Richard Draves, IETF internet-draft, May 2001, http://www.normos.org/ietf/draft/draft-ietf-ipngwg-defaultaddr-select-04.txt

• #11 - IPV6 Top Level Aggregation Identifier Assignments, http://www.iana.org/assignments/ipv6-tla-assignments

• #12 - Proposed TLA and NLA Assignment Rules, R. Hinden, RFC2450, December 1998, http://www.rfc-editor.org/rfc/rfc2450.txt

• #13 - IPv6 Tutorial, 40th RIPE, October 2001, Prague, http://www.viagenie.qc.ca/en/ipv6/presentations/ripe40-ipv6tutorial-praha-oct2001.pdf

• #14 - Allocation Guidelines for IPv6 Multicast Addresses, B. Haberman, RFC3307, August 2002, ftp://ftp.rfc-editor.org/in-notes/rfc3307.txt

• #15 - Transmission of IPv6 Packets over Ethernet Networks, M. Crawford, December 1998, RFC2464, http://www.ietf.org/rfc/rfc2464.txt?number=2464

http://www.huitema.net/ipv6-howlong.asp



http://www.di.fc.ul.pt/~pmv/ipv6.ppt

http://www.prenhall.com/

http://www.iana.org/ipaddress/ip-addresses.htm



http://www.viagenie.qc.ca/en/ipv6/

http://www.normos.org/ietf/rfc/rfc2460.txt



http://www.normos.org/ietf/draft/draft-ietf-ipngwg-defaultaddr-select-04.txt











http://www.iana.org/assignments/ipv6-tla-assignments





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



http://www.viagenie.qc.ca/en/ipv6/presentations/ripe40-ipv6tutorial-praha-oct2001.pdf







ftp://ftp.rfc-editor.org/in-notes/rfc3307.txt





http://www.ietf.org/rfc/rfc2464.txt?number=2464

IPv6

Fim da apresentação

24-05-2013 ISEL - ADEETC 138

Documents

IPv6 - Internet Protocol version 6 - FCULwebpages.fc.ul.pt/~sgclaudio/webfiles/04-IPv6v3.pdf · História do IPv6 • O sucessor do IPv4 começou a ser desenvolvido no inicio dos