[BPF] Uso de ips RF1918 na rede

[Welisson Tome]

Se me permite, responderei inline ao seu comment, acho mais facil para
entendimento.

Em sex, 5 de abr de 2019 às 16:52, Leonardo Furtado <leofurtadonyc em gmail.com>
escreveu:

> Boa tarde.
>
>
>
> Responderei a sua dúvida de forma mais ampla, bem mais ampla.
>
>
>
> Usar endereçamento IPv4 privativo nos enlaces internos da infraestrutura
> e, em grande parte, para o endereçamento de interfaces loopback (/32),
> tinha como bons argumentos: ter mais endereços IP públicos disponíveis para
> atender clientes, claro, e um aumento razoável da segurança geral, em
> especial ataques lançados sobre ou contra o plano de controle da própria
> infraestrutura (negação de serviço), já que os equipamentos ficam isolados
> de uma comunicação direta com perímetros externos e com a própria Internet.
>
>
>
> No entanto, o argumento da segurança supracitada é anulado completamente
> em ambientes já contando com pilha dupla. De que adianta ter o IPv4
> privativo se pode haver a comunicação as interfaces destes equipamentos
> pelo IPv6?
>

Concordo plenamente com esta sua tese levantada, mas neste caso nem é muito
a questão da segurança, visto que neste caso terá que ser abordado outros
modelos e métodos para tal pratica afim de manter a rede segura(um exemplo
dado por você no BFP é bgp free core, e o mpls unified, este ultimo foi
novidade),  acl's, enfim, qualquer outro modelo para evitar a exaustão do
control-plane da caixa. Porém neste aspecto a questão foi mais voltada a
utilização do ips públicos disponíveis, afim de atender os clientes com os
mesmo, ao invés de coloca-lós para rede, que só fará "trampo" interno.
Mesmo assim se quiser manter algo semelhante em v6 também, uma coisa que me
surgiu agora, seria a rfc4193, mas não faria sentido pela quantidade de
ipv6 disponível, e gerencialmente critico para todos os endereçamento.


>
> Na questão da “limitação do MPLS sobre o IPv6”, isto pode ser facilmente
> saneado por duas abordagens possíveis: projeto com 6PE, ou partindo já para
> a linha do Segment Routing (SRv6), que é inclusive como empresas com a
> Cisco fazem nos dias atuais para a questão do IPv6 com MPLS. Dê uma
> conferida no 6PE aqui neste artigo + vídeo:
> https://wiki.brasilpeeringforum.org/w/Introducao_ao_IPv6_Provider_Edge_over_MPLS_e_6VPE
>
> Não que eu esteja militando pelo conservadorismo dessa solução, até mesmo
> porque eu partiria – e de certa forma parto – para os modelos e práticas
> mais vigentes. No entanto, não posso deixar de reconhecer as vantagens e a
> parte boa de um AS em regime 6PE: toda a rede interna do ISP/AS fica apenas
> com endereçamento IPv4, podendo ser inclusive (recomendo) com endereços
> privativos (ou seja, “isolando” a rede interna da Internet, o que pode
> contribuir para a redução de diversos riscos dentre os quais o caso que
> citei acima), além de viabilizar por completo clientes + serviços em pilha
> dupla, ou seja, IPv4 + IPv6.
>
>
>
> Já com o SRv6 (Segment Routing + IPv6) tem a vantagem da eliminação de
> protocolos, TILFA sub-50msec FRR, maior escalabilidade para TE (já que não
> há a necessidade de manutenção de estados per-flow), além do próprio NFV
> (pois source routing da topologia e serviços podem ser codificados no
> cabeçalho do pacote), dentre outras vantagens e inovações.
>
>
>
> Se você estiver na vanguarda, vai querer optar por uma solução em pilha
> dupla com SRv6 para toda a infraestrutura. Agora se você possui restrições
> ou tem um perfil mais conservador na hora de implantar certas coisas,
> talvez o 6PE seja uma saída mais interessante.
>
>
>
Não estou muito familizarizado ainda co SR, mas vejo com bons olhos para
estudos e posterior implementação, mas isto deixarei para uma abordagem no
futuro próximo.
Relacionado ao 6PE, com certeza é uma solução alternativa para levar v6 as
pontas, bem como no modelo de segregação feita pelo mpls unified,(explicada
por você no link¹)
Porém neste caso a minha duvida seria, usar ou não usar, visto que tal
didática pode interferir em algumas particularidades como quebra de PMTU
Discovery, dificuldades em troubleshoot na outra ponta devido a falta de
resposta de icmp das redes privadas alcanar a ponta A, por não serem
roteáveis publicamente, e outros problemas que possa a vir, então a questão
seria mesmo assim, usar ou não usar, ou como diz "sua conta e risco". ;-)

Welisson

>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20190405/8697cd8f/attachment-0001.html>