ipv6 - internet protocol version 6sgclaudio/webfiles/04-ipv6v3.pdf · cabeçalho ipv6 ordem de...
TRANSCRIPT
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]
0100::/8 Reserved by IETF [RFC4291]
0200::/7 Reserved by IETF [RFC4048]
0400::/6 Reserved by IETF [RFC4291]
0800::/5 Reserved by IETF [RFC4291]
1000::/4 Reserved by IETF [RFC4291]
2000::/3 Global Unicast [RFC4291]
4000::/3 Reserved by IETF [RFC4291]
6000::/3 Reserved by IETF [RFC4291]
8000::/3 Reserved by IETF [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
• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do de IPv6
• 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
• Type (1 byte) – 2
• Code (1 byte) – 0
• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do de IPv6
• MTU (4 bytes) – “Maximum Transmit Unit” da ligação seguinte
• Data (variável) – Header do IPv6 e tanto quanto possível dos dados originais. Não deve exceder 1280 bytes.
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
• Type (1 byte) – 3
• 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
• Data (variável) – Header do IPv6 e tanto quanto possível dos dados originais. Não deve exceder 1280 bytes.
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
Mensagens de informação
• 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
Mensagens de informação
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
Mensagens de informação
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
• Code (1 byte) – 0
• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do IPv6
• 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
• Code (1 byte) – 0
• Checksum (2 bytes) - Permite detectar erros no header ICMPv6 e em parte do IPv6
• Current Hop Limit (1 byte) – Valor por defeito para o campo Hop Limit
Mensagem Router Advertisement (2)
• 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
Mensagem Router Advertisement (3)
• 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
Mensagem Router Advertisement (4)
• 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
Mensagem Router Advertisement (5)
• 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
Mensagem Neighbour Solicitation
• 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
Mensagem Neighbour Solicitation
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
Auto configuração – DAD (2)
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
Auto configuração – DAD (3)
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.
24-05-2013 ISEL - DEETC - RCD - CRC 109
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.
24-05-2013 ISEL - DEETC - RCD - CRC 110
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
24-05-2013 ISEL - DEETC - RCD - CRC 111
Mensagem Multicast Listener
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.
24-05-2013 ISEL - DEETC - RCD - CRC 112
Mensagem Multicast Listener
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.
24-05-2013 ISEL - DEETC - RCD - CRC 113
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
24-05-2013 ISEL - DEETC - RCD - CRC 115
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.
24-05-2013 ISEL - DEETC - RCD - CRC 116
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.
24-05-2013 ISEL - DEETC - RCD - CRC 117
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
24-05-2013 ISEL - DEETC - RCD - CRC 118
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)
24-05-2013 ISEL - DEETC - RCD - CRC 119
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.
24-05-2013 ISEL - DEETC - RCD - CRC 120
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).
24-05-2013 ISEL - DEETC - RCD - CRC 121
Elementos de segurança Associações de Segurança (SA)
• 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.
24-05-2013 ISEL - DEETC - RCD - CRC 122
Elementos de segurança Associações de Segurança (SA)
• 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.
24-05-2013 ISEL - DEETC - RCD - CRC 123
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)
24-05-2013 ISEL - DEETC - RCD - CRC 124
Elementos de segurança Autenticação
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.
24-05-2013 ISEL - DEETC - RCD - CRC 125
Elementos de segurança Autenticação
• 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
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
24-05-2013 ISEL - DEETC - RCD - CRC 126
Elementos de segurança Autenticação
Payload
(Variable
length)
Flow label
Source IP address
Destination address
Payload
lengthReserved
Inner IP header
Version Class
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
Flow label
Payload length
Autentication header
Next
header
Next
headerHop limitPayload length
Next
headerHop limit Security Parameter Index (SPI)
IP header
Version Class
Source IP address
Destination address
Utilização de túneis para transporte de informação autenticada.
24-05-2013 ISEL - DEETC - RCD - CRC 127
Elementos de segurança Cifra
Payload
(Variable
length)
Flow label
Source IP address
Destination address
TCP header
Sequence number
Acknowledgment number
H-len Reserved Code bitsWindow
size
Source port Destination port
Checksum Urgent pointer
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.
24-05-2013 ISEL - DEETC - RCD - CRC 128
Elementos de segurança Cifra
Payload
(Variable
length)
Flow label
Source IP address
Destination address
TCP header
Sequence number
Acknowledgment number
H-len Reserved Code bitsWindow
size
Source port Destination port
Checksum Urgent pointer
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)
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.
24-05-2013 ISEL - DEETC - RCD - CRC 129
Elementos de segurança Cifra
Payload
(Variable
length)
Flow label
Source IP address
Destination address
Inner IP header
Version Class
TCP header
Sequence number
Acknowledgment number
H-len Reserved Code bitsWindow
size
Source port Destination port
Checksum Urgent pointer
Options Padding
Flow label
Payload length
Encryption header
Next
headerHop limit
Security Parameter Index (SPI)
Payload lengthNext
headerHop limit Sequence Number
IP header
Version Class
Source IP addressEncryption parameters (e.g. Initialization
vector)
Destination address
Encryption trailer
Padding
Padding length
Payload type
Authentication data (optimal)
Versão utilizando túnel IP.
24-05-2013 ISEL - DEETC - RCD - CRC 130
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.
24-05-2013 ISEL - DEETC - RCD - CRC 131
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
24-05-2013 ISEL - DEETC - RCD - CRC 133
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.
24-05-2013 ISEL - DEETC - RCD - CRC 134
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.
24-05-2013 ISEL - DEETC - RCD - CRC 135
Qualidade de serviço
• 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.
24-05-2013 ISEL - DEETC - RCD - CRC 136
Qualidade de serviço
• 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.
24-05-2013 ISEL - DEETC - RCD - CRC 137
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
IPv6
Fim da apresentação
24-05-2013 ISEL - ADEETC 138