Arquivo

Archive for outubro \29\-03:00 2011

Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)


Todos os infortúnios que vivi me tornaram um homem mais forte,
me ensinaram lições importantes. Aprendi a tolerar os medíocres;
afinal, Deus deve amá-los, porque fez vários deles.

ABRAHAM LINCOLN
16o presidente norte-americano
Prefácio Póstumo
Em “Oportunidades Disfarçadas”, Carlos Domingos.
Editora Sextante 2009

Introdução

O objetivo deste artigo é apresentar a experiência de conexão a um PTT (PTT Belém), através de um Mikrotik incluindo as preocupações, cuidados e o necessário planejamento para que isto seja feito.

Uma ótima referência para o que será dito aqui está em [1].

Planejamento

Os recursos e facilidades envolvidos na conexão e no entorno do PTT Belém são:

  1. Estado inicial.
  2. Conexão ao PTT, propriamente dita.
  3. Rede local, anúncios IPv4 e IPv6 para o PTT e empareados.
  4. Filtros
  5. Trânsito IPv4 via o PTT, em acordo bilateral com o fornecedor do trânsito.
  6. Trânsito IPv6 via Tunnel Broker
  7. Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.
  8. Outras providências

O cenário fica mais claro com a Figura 1, com os comentários a seguir.

 

Figura 1. Cenário existente e projetado, no entorno do PTT Belém.

 

O comentários sobre a Figura 1 são:

  • Está sendo usada uma RB750 com versão 5.7 do Mikrotik. Há um trânsito (considerado como temporário) através da FAEPA. A Tabela 1 exibe o plano das 5 interfaces da RB750 e antecipa as VLANs que serão necessárias para os respectivos empareamentos IPv4 e IPv6. Também, a VLAN de trânsito com a FAEPA através do PTT, que irá substituir o trânsito estático através da interface 1, por um trânsito BGP.

     

    # Nome Tipo
    1 E1-FaepaTemp Ethernet1
    2 E2-PTTBelem Ethernet2
    3 E3-Disponivel Ethernet3
    4 E4-Disponivel4 Ethernet
    5 E5-Disponivel Ethernet5
    6 VLAN-PTTIPv4 VLAN
    7 VLAN-PTTIPv6 VLAN
    8 VLAN-TransitoIPv4-FAEPA VLAN
    9 HE Túnel 6to4

    Tabela 1. Interfaces atuais e projetadas.

  • Sabe-se que o administrador do PTT (aPTT) exigirá VLANs para a conexão no “switch” do PIX. Uma para cada protocolo (IPv4 e IPv6), para as quais ele informará o respectivo ID. Criamos as VLANs (#6 e #7, Tabela 1), na espera do ID. O aPTT irá nos enviar um ID inicial, para cada VLAN, que corresponderá ao período de quarentena (que pode durar até uns 10 dias, aproximadamente). Passado a quarentena e eventuais ajustes de interconexão, o aPTT nos enviará os IDs definitivos. Após a implementação definitiva solicitaremos ao aPTT o ID da VLAN de trânsito via o PTT Belém, tudo com conhecimento do parceiro de trânsito. O cenário com as duas VLANs iniciais pode ser visto conforme a Figura 2 abaixo.

     

    Figura 2. Cenário com as VLANs IPv4 e IPv6.

     

    Importante lembrar que as VLANs são possíveis porque a conexão do Mikrotik está, diretamente, com o “switch” do PIX, em L2 (muitas vezes vê-se, sem sucesso, tentativas usar VLANs em conexões não Ethernet). Na Figura 2, acima, as duas VLANs estão definidas sob a interface 2 do Mikrotik. Também, não se pode esquecer que o Mikrotik estabelece as VLANs em modo transparente (recomendado pelo aPTT). A Figura 3, abaixo, mostra a presença da VLAN para trânsito, criada sob a VLAN IPv4 (Q-in-Q). Neste momento, não estamos seguros se há ou não restrições nesta forma, e portanto, o melhor é confirmar com o aPTT.

     

    Figura 3. VLAN para trânsito via PTT.

     

  • A interface 2 da RB está conectada, como já foi dito, diretamente à porta do “switch” do PIX Faepa. Esta conexão é local, pois nossos servidores estão hospedados no centro de dados da Faepa. No mesmo centro de dados está localizado o PIX Central do PTT Belém. O material do José Eduardo, em [1] permite extrapolar a visão da topologia do PTT Belém.

Estado inicial

A Figura 4, na sequência, exibe o estado inicial da nossa topologia. O Mikrotik já foi configurado de acordo com a Tabela 1.

 

Figura 4. Configuração inicial.

 

O tráfego de trânsito será mantido por algum tempo, mesmo depois da interconexão com o PTT Belém.

Conexão ao PTT

As informações iniciais para conexão em um PTT está em http://sp.ptt.br/adesao.html. Mesmo que o PTT Metro escolhido ainda não esteja divulgado, mas sabe-se que está em fase final.

Dai para frente, siga a sequência das mensagens, e sempre que surgir alguma dúvida, não se acanhe a perguntar ao aPTT. Embora seja perceptível um alto grau de ocupação do pessoal do PTT, já usei o INOC-BR. Por outro lado, se já sabe o caminho das pedras, prepare-se do lado de cá. Já estabeleci um empareamento com o PTT-SP em menos de 5 dias. O PTT Belém, na oportunidade, em construção, levou uns 30 dias ou mais. Como já sabia, não tive pressa.

Rede local, mecanismos de acesso remoto e respectivos anúncios IPv4 e IPv6 para o PTT e empareados.

Para o Belém, o empareamento com a HE via “tunnel broker” levou menos de 15 minutos, pois já havia outro estabelecido. A HE permite até 5 túneis, a princípio. Anunciamos um /48.

O anúncio do IPv4 foi de um /23, pois haviam outros pontos de presença de nossa empresa. Para o PTT Belém o /23 foi dividido em dois /24 e para o trânsito externo (fora do PTT) será anunciado o /23. O trânsito externo é trânsito redundante, simplesmente. Foi incluída, nesta fase, uma interface de “loopback” IPv6, para túneis a serem construídos em futuro próximo. A seguir, as interfaces até o momento disponíveis:

Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                    TYPE               MTU L2MTU  MAX-L2MTU
 0  R  E1-FaepaTemp            ether             1500  1526       1526
 1  R  E2-PTTBelem             ether             1500  1524       1524
 2     E3-Disponivel           ether             1500  1524       1524
 3     E4-Disponivel           ether             1500  1524       1524
 4     E5-Disponivel           ether             1500  1524       1524
 5  R  VLAN-PTTIPv4            vlan              1500  1520
 6  R  VLAN-PTTIPv6            vlan              1500  1520
 7  R  VLAN-TransitoIPv4-FAEPA vlan              1500  1516
 8  R  ;;; Hurricane Electric IPv6 Tunnel Broker
       HE                     sit               1280
 9  R  Loopback-IPv6-Interno  bridge            1500 65535

A interface de “loopback” em IPv6 pode ser construida, no Mikrotik, de várias maneiras. A recomendável é apresentada logo abaixo, onde o MAC administrativo utilizado foi: 01:01:01:01:01:01, pois a “loopback” exige-o. Se precisar de outro, usa-se os MACs do tipo: 02:02:02:02:02:02 e assim, sucessivamente.

/interface bridge add name=Loopback-IPv6-Interno auto-mac=no admin-mac=01:00:00:00:01:00
/ipv6 address add address=abcd:efgh::1/64 advertise=no interface=Loopback-IPv6-Interno

Percebe-se que do /48 anunciado separamos um /64 somente para “loopbacks”.

Filtros

Eis a listagem dos filtros, até o momento:

[admin@Belem] > routing filter print detail 
Flags: X - disabled 
 0   ;;; Route Server 1 IPv4
     chain=RS1-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 1   chain=RS1-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 2   chain=RS1-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 3   chain=RS1-PTT-IPv4_out invert-match=no action=discard 
 4   ;;; Route Server 2 IPv4
     chain=RS2-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 5   chain=RS2-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 6   chain=RS2-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 7   chain=RS2-PTT-IPv4_out invert-match=no action=discard 
 8   ;;; Route Server 1 IPv6
     chain=RS1-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
 9   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
10   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
11   chain=RS1-PTT-IPv6_out invert-match=no action=discard 
12   ;;; Route Server 2 IPv6
     chain=RS2-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
13   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
14   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
15   chain=RS2-PTT-IPv6_out invert-match=no action=discard 
16   ;;; LG IPv4
     chain=LG-PTT-IPv4_in invert-match=no action=discard 
17   chain=LG-PTT-IPv4_out invert-match=no action=accept 
18   ;;; LG IPv6
     chain=LG-PTT-IPv6_in invert-match=no action=discard 
19   chain=LG-PTT-IPv6_out invert-match=no action=accept 
20   ;;; HE Tunel Broker
     chain=Tunel-IPv6-HE_in prefix=::/0 invert-match=no action=discard 
21   chain=Tunel-IPv6-HE_out prefix=rstu:vxyz:1::/48 invert-match=yes action=discard

Comentários sobre os filtros:

  1. De 0 a 15 estão as regras para os dois “Route Servers” de cada protocolo (IPv4 e IPv6). Cada um com 4 regras: (a) não recebe rota default (e recebe tudo mais…); (b) encaminha o bloco desagregado (duas regras); (d) não envia mais nada.
  2. De 16 até 19, duas regras para cada LG: (a) não recebe nada; (b) envia tudo.
  3. De 20 a 21, duas regras para o “tunnel broker”: (a) não recebe rota default; (b) só anuncia o /48. Vale observar o “invert-match=yes” da regra 21 => descarta tudo, menos o /48.

Acordo bilateral de trânsito IPv4 via o PTT

Já foi solicitada a VLAN (tag) para o trânsito via o PTT. Assim que for implementado, as informações serão incluídas neste texto.

Trânsito IPv6 via Tunnel Broker

A referência para o “Tunnel Broker” com a Hurricane Eletric é http://tunnelbroker.net/. É gratuito e há o esquema de implementação para o Mikrotik, disponível no sítio.

Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.

Os filtros não estão garantindo que IPs (v4 e v6), não estejam sendo encaminhados para o PTT, em particular, nas regras dos “Route Servers”. Existem duas soluções para isto:

  • Identificar, manualmente, os bogons no IRR ou outros locais. Construir uma lista de IPs (v4 e v6) e incluir as regras correspondentes. A complicação a a revisão destas listas, em particular, de cada um dos RIRs, pois IPs são liberados sem maiores avisos.
  • Mais confortável, estabelecer um empareamento com o Team-Cymru que enviará as listas atualizadas para serem encaminhadas ao “blackhole” do Mikrotik.

As informações do Team-Cymru, incluindo esquema de implementação no Mikrotik pode ser encontrada em http://www.team-cymru.org/, com muitas outras informações disponíveis. Como o Team-Cymru faz um ótimo trabalho e é de longe a melhor opção. A sugestão no sítio do Team-Cymru, para o Mikrotik é:

# Empareamento
/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru1 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru2 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

# Filtros
/routing filter add action=accept bgp-communities=65332:888 \
 chain=TeamCymru_in comment="" disabled=no invert-match=no \
 set-type=blackhole
/routing filter add action=discard chain=TeamCymru_in comment="" \
 disabled=no invert-match=no
/routing filter add action=discard chain=TeamCymru_out comment="" \
 disabled=no invert-match=no

Eis os comentários e observações úteis sobre as sugestões acima:

  • São dois empareamentos (dois servidores, diferentes), para efeitos de redundância.
  • O empareamento é “multihop” e, com um ASN privativo(!).
  • Um BGP que fala com chave MD5, para adicionar segurança.
  • Os três filtros, na ordem: (a) recebe somente os IPs que chegam associados à comunidade 65332:888, do AS65332. O Team-Cymru diferencia o “full bogon” e o “tradicional bogon”, por comunidades. Todas as rotas que chegam associadas à comunidade 65332:888, são marcadas como “blackhole”. (b) Nada mais é recebido do empareamento com o AS65332. (c) Nada será enviado via o empareamento com o AS65332.
  • As rotas marcadas como “blackhole” são “silenciosamente” descartadas na FIB (uma das tabelas de roteamento), e portanto, nada mais precisa ser feito. As regras de descarte de rotas nas tabelas de roteamento são muitas e complexas para lembra a todo momento, mas podem ser estudadas com carinho, nas seguintes referências:
  • Após o estudo das referências acima, para adquirir mais intimidade com o BGP e sua incrível complexidade, que tal identificar uma outra forma de lidar com os bogons (ainda usando o Team-Cymru)? Por exemplo, sem marcar como “blakhole”? Uma dica: sem necessidade de filtrar a saída em cada empareamento.

 

Implementação

A Figura 5, que segue, mostra o estado dos empareados no nosso Mikrotik. Ainda não foi implementado o empareamento com o Team-Cymru. Portanto, ele não aparece, ainda.

 

Figura 5. Estado dos empareamentos.

 

A visibilidade externa ainda é pequena, mas já pode ser vista em aqui. Por exemplo, o empareamento multilateral com a RNP, no PTT-Belém e dois blocos IPv6, /48, anunciados nos empareamento de Belém e SJCampos.

 

Comentários Finais

A nova versão do Mikrotik está com quase todas as facilidades implementadas em IPv6. Isto significa que é possível deixar de usar o IPv4 nas interconexões inter AS e, também, intra ASes. E os acessos via SSH estão disponíveis a qualquer interface IPv6 (inclusive wireless), vantagem, neste caso para os ISPs. Nos próximos ensaios daremos preferência ao IPv6

Referências

[1] José Eduardo de Oliveira, PTT Metro, 03/01/2011, Disponível em http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/introducao-ao-pttmetro.pdf. Acessado em 29/10/2011 08:08.

A Seta IPv6: adaptando a complexidade do IPv6 à mente humana

Visualizar, calcular, manipular, registrar, organizar e documentar o IPv6

 

Pense um pouco sobre a figura.
Ache os prefixos empareados verticalmente, acima e abaixo da linha divisória (exceto o /64).

 

Uma boa companhia (inclusive, complementar) à Seta IPv6 é o Guia didático de Endereçamento IPv6 (GDEI), desenvolvido pelo pessoal do IPv6.br.

Como usar


É necessário um planejamento inicial. Talvez responder algumas perguntas como:

  1. Qual o bloco recebido do Registro.br? R: Por exemplo, o 2001:0DB8::/32.
  2. Como dividir/conquistar este bloco? R: Depende exclusivamente da experiência e da influência de experiências de terceiros. Digamos que divida em dois /33 e use o primeiro deles, deixando o segundo para outra oportunidade futura.
  3. Quais os recursos disponíveis para documentar o IPv6? R: Quem sabe um editor de textos, qualquer. Ou o Plone, razão pela qual a Seta IPv6 é um esquema favorável. Em ambos os casos pode-se expandir a Seta e colocar o nome dos Clientes, os quais serão os “donos” das redes. A expansão da Seta é a grande motivação para seu uso. Muitas pessoas já devem fazer isto.

Então, na Seta IPv6:

2001:0DB8::/33
2001:0DB8:8000::/33 (Deixar para quando esgotar o primeiro bloco /33)

 

Concentremos no bloco (ou rede, ou prefixo) 2001:0DB8::/33. Digamos, vamos distribuir /48s para nossos Clientes. Empareados (abaixo e acima da Seta IPv6):

2001:0DB8::/48
2001:0DB8:3::/48

 


Aqui precisa-se pensar um pouco sobre o prefixo /48: 48/4 = 12 dígitos hexadecimais.

a. Primeiro conjunto => 2
b. Segundo conjunto  => 0
c. Terceiro conjunto => 0
d. Quarto conjunto   => 1
e. Quinto conjunto   => 0
f. Sexto conjunto    => D
g. Sétimo            => B
h. Oitavo            => 8
i. Nono              => 0
j. Décimo            => 0
k. Décimo primeiro   => 0
l. Décimo segundo    => 0 ou 3

 


Assim, mais claramente, uma representação didática dos dois blocos /48:

2001:0DB8:0000::/48
2001:0DB8:0003::/48

 

O 3 é um dígito hexadecimal representado em binário por [0011]. Sempre colocaremos binários, entre [].

Vale lembrar que o prefixo 48 é um múltiplo de 4 (ou de 8). Mas isto nem sempre contece. Por exemplo, o prefixo /47. Dividindo por 4, temos 11 dígitos hexadecimais e um resto de 3 bits. Para efeitos didáticos, o segundo bloco acima pode ser representado como:

2001:0DB8:000[0011]::/48 

 

Os blocos /47 empareados na Seta, são:

2001:0DB8::/47
2001:0DB8:2::/47

 

O segundo bloco, 2001:0DB8:2::/47, sob a ótica didática:

2001:0DB8:000[001]::/47 

 

onde à direita vê-se 3 bits e não 4, para completar 47 bits (da esquerda para a direita). Pode-se, entretanto, exibir os 4 bits:

2001:0DB8:000[0010]::/47

 

Retornando aos dois blocos /48:

2001:0DB8::/48
2001:0DB8:3::/48

 

O primeiro bloco, contem todos os IPs entre 2001:0DB8:0000::/48 a 2001:0DB8:FFF2::/48. De uma forma mais completa, e didática, os IPs do primeiro bloco /48 são:

2001:0DB8:0000:0000:0000:0000:0000:0000
2001:0DB8:0000:0000:0000:0000:0000:0001
2001:0DB8:0000:0000:0000:0000:0000:0002
...
2001:0DB8:0000:0000:0000:0000:0000:000F
2001:0DB8:0000:0000:0000:0000:0000:0010
2001:0DB8:0000:0000:0000:0000:0000:0020
...
2001:0DB8:0000:0000:0000:0000:0000:00F0
2001:0DB8:0000:0000:0000:0000:0000:00F1
2001:0DB8:0000:0000:0000:0000:0000:00F2
...
2001:0DB8:FFF0:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF1:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF2:FFFF:FFFF:FFFF:FFFF:FFFF

 

e o segundo bloco, 2001:0DB8:3::/48, contem os IPs:

2001:0DB8:0003:0000:0000:0000:0000:0000
2001:0DB8:0003:0000:0000:0000:0000:0001
2001:0DB8:0003:0000:0000:0000:0000:0002
...
2001:0DB8:0003:0000:0000:0000:0000:000F
2001:0DB8:0003:0000:0000:0000:0000:0010
2001:0DB8:0003:0000:0000:0000:0000:0020
...
2001:0DB8:0003:0000:0000:0000:0000:00F0
2001:0DB8:0003:0000:0000:0000:0000:00F1
2001:0DB8:0003:0000:0000:0000:0000:00F2
...
2001:0DB8:FFF3:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF4:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF5:FFFF:FFFF:FFFF:FFFF:FFFF

2001:0DB8:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

 

É intuitivo, principalmente consultando o GDEI, que os dois blocos

2001:0DB8::/48
2001:0DB8:3::/48

 

pertencem a um único bloco do prefixo /48 que, também é representado por:

2001:0DB8::/48

 

A Seta divide este bloco em dois conjuntos com o mesmo número de IPs, para facilitar nossa vida. Poderíamos dividir os blocos deste prefixo em vários outros /48s deste que fosse respeitado os 48 bits da máscara. Como os primeiros 32 bits são intocáveis, pois pertencem ao bloco /32 original. Os /48s são vistos da seguinte forma, didáticamente:

2001:0DB8:0000::/48
2001:0DB8:0001::/48
2001:0DB8:0002::/48
2001:0DB8:0003::/48
2001:0DB8:0004::/48
...
2001:0DB8:000F::/48
2001:0DB8:0010::/48
...
2001:0DB8:00FF::/48
2001:0DB8:0100::/48
2001:0DB8:0101::/48
...
2001:0DB8:FFFF::/48

 

ou sejam, 65.536 blocos (ou redes) /48, conforme diz o GDEI. Mais ainda: para cada /48 acima, os 48 bits iniciais são intocáveis, pois cada um é uma rede independente.

Imagine que a linha divisória da Seta deixa abaixo dela tudo o que iremos usar em outro momento, já que divide os prefixos em duas metades. É uma forma de organizar nossas habilidades para uma imensidão de IPs, “nunca dantes” imaginado!

Decidindo repassar aos Clientes, blocos com prefixo /64, conforme as sugestões iniciais. Cada um dos blocos /48 acima, pode ser divididos em outras 65.536 redes (veja o GDEI) com prefixo /64. O /64 implicam 64 bits de máscara (e intocáveis). Então, usando o primeiro bloco (2001:0DB8:0000:/48), como exemplo, eis os blocos /64 possíveis:

2001:0DB8:0000:0000::/64 => 2001:0DB8::/64
2001:0DB8:0000:0001::/64 => 2001:0DB8:0:1::/64
2001:0DB8:0000:0002::/64 => 2001:0DB8:0:2::/64
...
2001:0DB8:0000:000F::/64 => 2001:0DB8:0:F::/64
2001:0DB8:0000:0010::/64 => 2001:0DB8:0:10::/64
...
2001:0DB8:0000:001F::/64 => 2001:0DB8:0:1F::/64
2001:0DB8:0000:0020::/64 => 2001:0DB8:0:20::/64
...
2001:0DB8:0000:FFFF::/64 => 2001:0DB8:0:FFFF::/64

 

Supondo que o primeiro bloco /64 seja utilizado na empresa detentora do /32, tem-se os seguintes IPs, disponíveis:

2001:0DB8:0000:0000:0000:0000:0000:0000 => 2001:0DB8::/64
2001:0DB8:0000:0000:0000:0000:0000:0001 => 2001:0DB8::1/64
2001:0DB8:0000:0000:0000:0000:0000:0002 => 2001:0DB8::2/64
...
2001:0DB8:0000:0000:0000:0000:0000:000F => 2001:0DB8::F/64
2001:0DB8:0000:0000:0000:0000:0000:0010 => 2001:0DB8::10/64
2001:0DB8:0000:0000:0000:0000:0000:0011 => 2001:0DB8::11/64
...
2001:0DB8:0000:0000:FFFF:FFFF:FFFF:FFFF => 2001:0DB8::FFFF:FFFF:FFFF:FFFF/64

 

Intocável o prefixo 2001:0DB8:0000:0000, portanto! O ambiente que for o “dono” do bloco /64, com seu intocável prefixo de 64 bits pode dividir em outras redes com prefixos maiores: /65, /66/, /67, …, /128. O GDEI recomenda cuidados ao dividir em blocos menores (ou prefixos maiores), do que /64.

Variações do tema

Pode-se usar metade da Seta para documentar as redes que são distribuídas. Se necessário adicionar segmentos da parte de baixo da linha divisória. Se já tem-se a Seta completa, então:

abcd:efgh::/32
 abcd:efgh::/33
  abcd:efgh::/34
   abcd:efgh::/35
    abcd:efgh::/36
     abcd:efgh::/37
      abcd:efgh::/38
       abcd:efgh::/39
        abcd:efgh::/40
         abcd:efgh::/41
          abcd:efgh::/42
           abcd:efgh::/43
            abcd:efgh::/44
             abcd:efgh::/45 
              abcd:efgh::/46
               abcd:efgh::/47
                abcd:efgh::/48

 

Ou quem sabe, começar a documentação a partir de simplesmente:

abcd:efgh::/48

 

e, continuar:

abcd:efgh:0000::/48 - Rede Interna
abcd:efgh:0001::/48 - Reservado
abcd:efgh:0002::/48 - Cliente 1
abcd:efgh:0003::/48 - Reservado
abcd:efgh:0004::/48 - Cliente 2
abcd:efgh:0005::/48 - Reservado
abcd:efgh:0006::/48 - Cliente 3
abcd:efgh:0007::/48 - Reservado
abcd:efgh:0008::/48 - Cliente 4
abcd:efgh:0009::/48 - Reservado
abcd:efgh:000A::/48 - Cliente 5
abcd:efgh:000B::/48 - Reservado
abcd:efgh:000C::/48 - Cliente 6
abcd:efgh:000D::/48 - Reservado
abcd:efgh:000E::/48 - Cliente 7
abcd:efgh:000F::/48 - Reservado
...

 

São 65.536 redes /48. No esquema acima, dá-se ao luxo de reservar as redes ímpares para futuras demandas, e quem sabe, garantir agregação. Se 32.768 redes não satisfaz a demanda, com criatividade pode-se encontrar outra arrumação. De qualquer forma, o esquema acima é uma das possibilidades, entre muitas outras. Por exemplo, deixar duas redes de reservas em cada sequência de distribuição. Ou quatro…

A Internet agradece as preocupações com a agregação.

A propósito, a Seta IPv6 é uma metáfora, puramente, didática!

Categorias:BGP, IPv6, TCP/IP