Minha jornada até o CCIE RS — IPv6

Giuliano Barros
TechRebels
Published in
11 min readFeb 27, 2019
Adoção de IPv6 por país de acordo com Google — Brazil não faz feio :)

E aí pessoal, tudo bem?

Continuamos percorrendo esta série de artigos compartilhando centenas de páginas de notas e informações acumuladas ao trabalhar com Routing and Switching. Acredito que estas informações podem ajudar no dia-a-dia de outros network engineers como eu.

Para quem não leu os artigos anteriores da série, seguem os links: “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição”, “MPLS”, “DMVPN — Parte 1”, “DMVPN — Parte 2” e “DMVPN — Parte 3” e “DMVPN — Parte 4”.

Hoje exploraremos Internet Protocol version 6, vulgo IPv6!!! Ao final uma lista de comandos “show” + filtros que considero eficiente.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a dar “claps” aí do lado esquerdo do artigo e compartilhar nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

IPV6

Especificado na RFC 2460 “Internet Protocol, Version 6”. O principal motivo do desenvolvimento do IPv6 foi claramente um espaço de endereçamento infinitamente maior.

  • IPv4 — 32 bits (4 bytes) — 2³² -> 4,2 bilhões de endereços
  • IPv6 — 128 bits (16 bytes) — 2¹²⁸ -> 3,4*10³⁸ endereços (aproximadamente 340 undecilhões, ou 340 bilhões bilhões bilhões bilhões de endereços… ou 6.6 × 10²³ endereços por metro quadrado da Terra… acho que é suficiente pra hoje).
  • IPv4 — 4 casas decimais separadas por ponto (.)
  • IPv6 — 8 campos hexadecimais (0–9,A-E) separados por (:)

DOC: BGP Table Statistics (bgp.potaroo.net) mostra estatísticas sobre prefixos IPv4 e IPv6 na Internet.

Adoção de IPv6 por usuários de acordo com Google — Atualmente 25% dos usuários

Endereçamento IPv6

Definido pela RFC 4291 “IP Version 6 Addressing Architecture”.

  • Unspecified — ::/128
  • Loopback — ::1/128
  • Multicast — FF00::/8
  • Link-local — FE80::/10 (equivalente a 169.254.0.0/16)
  • Global Unicast — todo o resto

Link-Local

Endereço localmente significante, gerado automaticamente quando habilitamos IPv6 no link.

  • Inicia com FE80::/10 (1111 1110 10).

Link-local é utilizado para:

  • Stateless Address Autoconfiguration (SLAAC)
  • Neighbor Discovery (ND)
  • Router Discovery (RD)

Endereço link-local nunca é roteado entre interfaces. Permite a IGP rotear tráfego através do router mesmo sem permitir tráfego destinado para o router.

Site Local

Endereços internos a um “site”.

  • Inicia com FEC0::/10 (111 1110 11).

Na RFC 3879 “Deprecating Site Local Addresses” (mais recente) sua definição foi depreciada porque não houve comum acordo sobre o que é um “site”. Já tentou definir um “site”?!?

Tecnicamente podem ser usados em ambientes de produção porque não são publicamente roteáveis, porém oficialmente foram substituídos por endereços Unique Local.

Unique Local

ULA é o endereçamento privado para IPv6.

  • Inicia com FC00::/7 (1111 110), começa com FC ou FD.

Definido na RFC 4193 “Unique Local IPv6 Unicast Addresses”, é o equivalente a RFC 1918 para IPv4 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).

Tal endereçamento não deveria ser roteável via BGP (externamente), mas devido ao imenso espaço de endereçamento é muito provável que sejam únicos (mas pra quê arriscar?). Portanto este endereçamento pode ser utilizado sem solicitação ao IANA (Internet Assigned Numbers Authority).

Global Unicast

Tecnicamente é todo o espaço de endereçamento sobrando tirando todas as definições anteriores.

IANA está atualmente alocando 2000::/3 (https://bit.ly/2tr5its), uma pequena parte do endereço disponível.

De acordo com RFC, hosts devem utilizar formato EUI-64 para interface ID, portanto /64. Este é o formato utilizado pelo Stateless Auto-configuration. Na prática, podemos configurar qualquer endereço para os equipamentos de rede, mas devemos utilizar /64 para as redes de acesso, assim os hosts podem usar Stateless Auto-configuration.

EUI-64 modificado

Definidos na RFC 4291, apêndice A “Creating Modified EUI-64 Format Interface Identifiers”. Especifica como o EUI-64 é definido para uso de endereçamento automático.

No caso de ethernet, a conexão para EUI-64 ocorre:

  • Checa MAC address;
  • Inverte o bit Universal/Local (U/L) que é o 7o bit mais significante;
  • Insere 0xFF + 0xFE (FFFE) no meio do endereço.

Não é recomendado utilizar auto-configuration para roteadores, a menos que haja alguma forma de mapeamento externo (DNS). Obviamente, trabalhar com endereço EUI-64 para cada interface pode ser bem cansativo porque precisaríamos manter mapeado cada MAC.

Neighbor Discovery

Processo de neighbor discovery (ND) é especificado na RFC 4861 “Neighbor Discovery for IP version 6 (IPv6)” e faz parte da stack ICMPv6.

ICMPv6 ND substitui o ARP na resolução L3->L2. (ARP foi desenvolvido como protocolo separado do IPv4).

  • Neighbor solicitation (NS) — equivalente a ARP request
  • Neighbor Advertisement (NA) — equivalente a ARP reply
  • Router Solicitation (RS)
  • Router Advertisement (RA)

IPv6 Stateless Auto-configuration (SLAAC)

Referencia um prefixo Global Address para ser usado por todos os hosts no link de forma stateless.

  • Router permite SLAAC por default através de RAs.

Não é o mesmo que DHCPv6, porque só inclui o prefixo e não as opções (ex: não inclui DNS Server).

NBMA

Assim como IPv4, há algumas considerações ao implementar IPv6 sobre NBMA (Frelay, multipoint ATM).

RFC 3122 especifica Inverse ND, que é o equivalente do inverse ARP porém IOS da Cisco ainda não suporta a funcionalidade.

Portanto, IPv6 sobre NBMA requer mapeamento estático L3->L2 (além das mesmas considerações sobre multicast e broadcast… através de pseudo-broadcast, etc).

DOC: Livro “IPv6: Theory, Protocol, and Practice” de Peter Loshin explica os problemas que tenta resolver, que são especificados nas RFCs.

OBS: Os protocolos de roteamento IPv6 rodam sobre o endereço link-local. Portanto, pingar ou se comunicar através do endereço Global Unicast não significa que o roteamento irá funcionar.

IPv6 over DMVPN

IPv6 over IPv4 DMVPN

  • Configure DMVPN IPv4;
  • Utilizar IPv6 NHRP para resolver mapeamento IPv6 IGP.

DMVPN over IPv6

  • Utiliza IPv6 mGRE para transport;
  • — <#tunnel mode gre multipoint ipv6>
  • — <#ipv6 NHRP nhs A:B::C nbma A:B::C> já mapeia NHS e NBMA no mesmo comando.
  • <sh dmvpn> mostra para IPv4 e IPv6

Roteamento IPv6

Roteamento IPv6 é desabilitado por default no IOS. Ao habilitar roteamento <ipv6 unicast-routing> também se habilita ICMPv6 ND RAs.

Roteamento IPv6 é suportado por todos os protocolos: estático, RIPng, EIGRPv6, OSPFv3, IS-IS, MP-BGP e Policy Routings.

Rotas aprendidas por IGP dinamicamente realizam recursividade para endereços next-hop link-local remoto. Portanto endereços Global Unicast não são requeridos.

  • Isto também implica na necessidade de mapeamento estático L3->L2 em redes multipoint NBMA para os endereços link-local (não somente para Global Unicast).

IPv6 permite a implementação de uma topologia utilizando somente link-local entre os equipamentos e global unicast apenas para os end hosts. Principalmente por segurança, isto permite que usuários consigam comunicar somente com outros end-hosts em redes Global Unicast, sem possuir nenhuma informação sobre os links entre os dispositivos (endereço link-local não são roteáveis) porque link-local são considerados caminhos de trânsito.

OBS: É comum a implementação de apenas uma loopback acessível para “inband management” e todas as outras como link-local.

VRF podem suportar IPv4 e IPv6

  • Não usar <ip vrf ABC>;
  • Usar <vrf definition ABC> e habilitar IPv6 como AF.
  • — #vrf definition VRF
  • — (vrf)# address-family ipv6

OBS: opções adicionais de <ipv6 route> são diferentes e confusas.

Roteamento estático

Rotear para o next-hop implica na resolução L2 do next-hop.

Rotear para uma interface multipoint implica na resolução L2 do destino final. Até o momento, IOS não suporta Proxy ND ou Proxy Inverse ND, portanto isso é algo que não se deve fazer para IPv6 (e geralmente também não para IPv4).

Rotear para uma interface P2P não requer nenhuma resolução.

OBS: Alguns switches Cisco não alocam buffer para IPv6 por default. A alteração dos buffer via Switch Database Management (SDM) para poder utilizar IPv6 requer reload.

OBS: Um workaround (gambiarra) ao usar rota estática para interface multiponto é mapear estaticamente o IP do destino para o MAC do next-hop. Obviamente para esta gambiarra precisa mapear todos os IPs de destino (não escala né).

Roteamento dinâmico

Relembrando, todos os protocolos de roteamento IPv6 utilizam como next-hop o endereço link-local remoto e isso implica que é sempre necessário mapeamento L3->L2 para que o roteamento ocorra (cuidado ao usar NBMA).

Por default, protocolos IPv6 redistribuem prefixos de outro protocolo instalados na RIB mas não as interfaces conectadas utilizando este protocolo. Diferente do IPv4 que redistribui tanto os prefixos na RIB e as interfaces.

RIPng

  • Definido na RFC 2080 “RIPng for IPv6”.
  • Operação é similar no RIPv2 e as principais diferenças são o uso de UDP 521 para multicast FF02::9.
  • Split-horizon é habilitado globalmente por default.

OBS: RIPng segue as mesmas regras do RIPv2 incluindo que somente as rotas instaladas na RIB são propagadas.

EIGRPv6

Sua operação é similar ao EIGRP, utilizando protocolo 88 para unicast e muticast FF02::A (tradução para 224.0.0.10).

Requer uso de Router-ID no forma IPv4, mesmo que só esteja usando endereços IPv6.

  • OBS: Tanto IPv6 EIGRP, OSPF e BGP usam router ID de 4 bytes.

IPv6 EIGRP classic mode

Processo global EIGRPv6 é desabilitado por default e um dos erros mais frequentes é esquecer de habilitar <no shut>.

IPv6 EIGRP named mode

Enquanto no IPv6 classic mode o processo é desabilitado por default, no named mode ele é habilitado automaticamente em todas as interfaces. Precisa excluir todas que não queremos:

  • — <#af-int X>
  • — <#shut>

OBS: Tanto para IPv4 quanto para IPv6 o mapeamento multicast do NHRP deve apontar para o endereço NBMA (seja ele IPv4 ou IPv6).

DMVPN PHASE 2 está suscetível as mesmas regras para IPv6 EIGRP.

  • Desabilitar split-horizon;
  • Desabilitar ip-nexthop-self.

OSPFv3

Especificado na RFC 5340 “OSPF for IPv6”.

Operação também é similar com OSPFv2, utilizando protocolo de transporte 89 e multicast FF02::5 e FF02::6.

As regras normais de OSPF ainda se aplicam, utilizando os mesmos parâmetros de adjacência, mesmos “network types”, etc.

OSPF requer Router-ID no formato IPv4, mesmo que só tenha interfaces IPv6 (segue as mesmas regras de escolha do OSPFv2).

OBS: No OSPFv3, ao especificar um neighbor devemos utilizar endereço link-local.

Novos LSAs:

  • Type 8 — (link) usado para link-local address;
  • Type 9 — (Intra Area Prefix) usado para prefixos nos links.

Novidade no OSPFv3 é o suporte a autenticação e criptografia do control-plane (payload). OSPFv3 usa IPSec para:

  • Autenticação: AH ou ESP
  • Encriptação: ESP

Não suporta ISAKMP. Portanto, as chaves devem ser configuradas manualmente (copia e cola em todos).

IPSec no OSPF gera IPSec SAs da mesma forma, de modo que o crypto-map exiba ProxyACL para protocolo 89 (OSPF).

  • <#sh crypto ipsec sa ipv6>

OSPFv3 pode divulgar IPv4 e IPv6 NLRI (multi-af). Forma dois grafos separados para v4 e v6 rodando independentemente mas usam as mesmas estruturas de dados (Uma adjacência para os dois protocolos). Neste caso, para propagar IPv4 NLRI precisa ter IPv6 e IPv4 rodando no link.

Mudanças na sintaxe:

  • <#int X>
  • — <#ospfv3 Y (ipv4|ipv6] area Z>
  • <#router ospfv3 Y>
  • <#sh ospfv3>

MP-BGP for IPv6

Definido na RFC 2545 “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-domain Routing”.

Um conceito que deve ficar claro é de que o transporte do BGP e a propagação da NLRI são processos completamente separados. Neighbors podem utilizar protocolo de transporte IPv4 ou IPv6 para adjacências MP-BGP enquanto propagam NLRI IPv4 ou IPv6 (unicast ou multicast) através de address-families do MP-BGP.

IPv6 unicast utiliza AFI 2 e SAFI 1.

Uma vez estabelecida a adjacência, todas as regras normais de BGP se aplicam.

Por default, a única AFI habilitada é IPv4 unicast. Para habilitar o uso de BGP para IPv6 precisa:

  1. Habilitar AFI e SAFI (IPv6 unicast).
  2. Ativar neighbors para tal AFI.

Toda configuração relacionada a IPv6 deve ser realizada dentro da AFI (incluindo route-maps).

OBS: Ao implementar IPv6 sobre IPv4 ou vice-versa, pode resultar em problemas de next-hop aparecendo inacessível e precisar ajustar através de route-maps.

OBS: Por causa da quantidade de configuração necessária para implementar BGP e AFs, é recomendável trabalhar todas as informações antes no bloco de notas para garantir que as configs estejam similares e que nada foi esquecido.

OBS: Para usar IPv6 link-local para adjacência o endereço deve estar no formato <neighbor FE80::X%InterfaceY>. Do contrário o router não sabe qual interface usar.

  • <neighbor FE80::5%FastEthernet1/1 remote as 10>
  • Ao utilizar link-local address como peer, os peers IBGP automaticamente realizam next-hop-self porque não conseguem acessar o link-local de router remoto.

BGP IPv6 sobre Transporte IPv4

Prefixos IPv6 sobre transporte IPv4 utilizam next-hop no formato ::FFFF:X.X.X.X.

  • Soluções para isso incluem:
  • — route-map com next-hop-self em ambos os peers;
  • — <no bgp default ipv6-nexthop> em ambos os peers (porque afeta outbound).

IPv6 Tunneling

Obviamente, IPv6 pode ser o protocolo de transporte ou o payload de um túnel.

GRE é o modo default utilizando protocolo de transporte 47. A desvantagem do GRE é que, por ser multi-protocolo, gera mais overhead que IPv6IP.

IPv6IP é implementado de forma similar ao GRE e usa protocolo de transporte 41. Principal diferença é que não suporta outros tipos de payload, apenas IPv6.

Teredo tunnel é um tipo de túnel IPv6 transparente sobre UDP em IPv4. Geralmente utilizado por end hosts para se conectarem a outros end-hosts em redes IPv6 (como ferramenta transitória).

IPv4 over IPv6 GRE seria a solução inversa tendo IPv4 como payload (solução necessária no futuro).

Túneis Automáticos para Ipv6

6to4

Utilizado para tunelamento inter-site entre os border routers. Funciona como túnel “IPv6IP multi-point inter-site”.

Principal desvantagem é que requer uso de endereço especial independente do endereço global utilizado.

6to4 opera derivando o endereço IPv4 do router de destino do endereço IPv6 de destino (formato 2002:endereço_IPV4::/48). O prefixo /48 deve ser adotado por todos os hosts atrás do border routes de destino.

  • Ex: IP de destino 150.28.10.10 origina 2002:961C:0A0A::/48. Este prefixo /48 deve ser utilizado por todo host atrás do router permitindo por default 16 bits para subredes internas, completando /64.
  • Outros prefixos podem ser utilizados mas 2002::/16 é reservado pelo IANA especificamente para 6to4.
  • OBS: Ponto negativo desta solução é que, se estiver utilizando um endereço IPv6 Global Unicast, a rede toda atrás do router precisa ser re-endereçada ou rodar múltiplos endereços. Outro ponto é que não permite uso de roteamento dinâmico.

ISATAP

Intra-Site Automatic Tunnel Addressing Protocol foi desenvolvido como host-to-host protocol sobre rede IPv4.

DMVPN

Dynamic Multipoint VPN funciona como túnel GRE multipoint. Implementação é mais complicada e possui vantagens como criptografia. Para saber mais sobre “DMVPN — Parte 1”.

Comandos Show para IPv6

  • sh ipv int x/x
  • sh ipv int bri
  • sh ipv nhrp
  • sh ipv prot

RIP

  • sh ipv rip
  • sh ipv route rip

EIGRP

  • sh ipv ei int
  • sh ipv ei nei
  • sh ipv eigrp topo
  • sh ipv route ei
  • sh ipv prefix-list

OSPF

  • sh ipv os
  • sh ipv os int
  • sh ipv os int bri
  • sh ipv os nei
  • sh ipv os nei det
  • sh ipv os data
  • sh ipv os border
  • sh ipv os events
  • sh ipv os rib
  • sh ipv os sham
  • sh ipv os sum
  • sh ipv os virtual
  • sh ipv route os

BGP

  • sh bgp ipv6 uni
  • sh bgp ipv6 uni nei
  • sh bgp ipv6 uni sum
  • sh ipv route bgp

O que achou desse artigo sobre IPv6? Te ajudará no dia-a-dia?

Fala pra gente nos comentários?

Se gostou do conteúdo, dê palmas para o artigo aí do lado esquerdo e compartilhe nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Engineer & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS e Cisco Champion pela Cisco Systems, trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros

--

--

Giuliano Barros
TechRebels

DevOps Network Engineer | CCIE RS #49619 | Cisco Champion | Blogger