[GTER] Segestao de RFC

Mon Dec 11 11:22:09 -02 2017

? Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
lembrar que a RFC teria ?mbito mundial.
- No começo eu dei a ideia de quebrar os blocos da RFC2544 em dois /16 já
que é usa RFC com pouco uso, outra opção eh o bloco 128.66.0.0/16 que pelo
que me parece ainda não tem seu uso muito bem definido.

? Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
uma discuss?o que vai dar id?ias mas sem muitos resultados.
- Otima ideia.

Aumento de TTL, tuneis MPLS e outras coisas do tipo resolve o problema do
icmp, mas e o conflito na entrega de servicos?

Pensei em utilizar o bloco de CGNAT para fazer essa interligacao e fugir do
conflito, mas seria pisar em outra RFC.

-----Mensagem original-----
De: gter [mailto:gter-bounces at eng.registro.br] Em nome de
gter-request at eng.registro.br
Enviada em: segunda-feira, 11 de dezembro de 2017 09:50
Para: gter at eng.registro.br
Assunto: gter Digest, Vol 177, Issue 17

Send gter mailing list submissions to
	gter at eng.registro.br

To subscribe or unsubscribe via the World Wide Web, visit
	https://eng.registro.br/mailman/listinfo/gter
or, via email, send a message with subject or body 'help' to
	gter-request at eng.registro.br

You can reach the person managing the list at
	gter-owner at eng.registro.br

When replying, please edit your Subject line so it is more specific than
"Re: Contents of gter digest..."

Today's Topics:

   1. RES:  CGNAT - Aonde colocar? (Junior Corazza)
   2. Segestao de RFC (Junior Corazza)
   3. Re: Segestao de RFC (Jefferson Gondek)
   4. Re: Segestao de RFC (Bruno Cabral)
   5. Re: Segestao de RFC (Danton Nunes)
   6. Re: Segestao de RFC (Douglas Fischer)

----------------------------------------------------------------------

Message: 1
Date: Sun, 10 Dec 2017 12:30:14 -0200
From: "Junior Corazza" <corazza at incert.com.br>
To: <gter at eng.registro.br>
Subject: [GTER] RES:  CGNAT - Aonde colocar?
Message-ID: <000001d371c3$66e15080$34a3f180$@incert.com.br>
Content-Type: text/plain;	charset="iso-8859-1"

Talvez eu tenha me expressado errado.

Eu faco o  CGNAT na mesma caixa onde eu rodo o PPPoE server, ou seja, CE
PPPoE.
Na CPE do cliente fa?o o NAT.

Message: 1
Date: Sat, 9 Dec 2017 12:14:52 -0200
From: <rafael at rafaelduarte.eti.br>
To: "'Grupo de Trabalho de Engenharia e Operacao de Redes'"
	<gter at eng.registro.br>
Subject: [GTER] RES:  CGNAT - Aonde colocar?
Message-ID:

<!&!AAAAAAAAAAAuAAAAAAAAALy2QqjpRHRHr/WMwksPL28BAMO2jhD3dRHOtM0AqgC7tuYAAAAA
AA4AABAAAABE4XOz4+xtQJbub92R+TAcAQAAAAA=@rafaelduarte.eti.br>

Content-Type: text/plain;	charset="iso-8859-1"

CE = Customer Edge ?

Voc? faz o NAT para a rede do Cliente, mas em algum roteador da sua infra
voc? precisa fazer o CGNAT e n?o no roteador do cliente.

Acho que voc? confundiu, nat com cgnat

Att
Rafael A. Duarte

------------------------------

Message: 2
Date: Mon, 11 Dec 2017 07:52:45 -0200
From: "Junior Corazza" <corazza at incert.com.br>
To: <gter at eng.registro.br>
Subject: [GTER] Segestao de RFC
Message-ID: <002c01d37265$cd2f7860$678e6920$@incert.com.br>
Content-Type: text/plain;	charset="iso-8859-1"

Conforme disse em minha apresenta??o na GTER44, em alguns provedores que
faco consultoria devido a falta de endere?os IPs para o acesso resolvi
substituir todos os IPs publicos do backbone para IPs privados da rfc1918.
Com isso ganho alguns endere?os para que sejam aplicados no acesso de
clientes.

Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei alguns
problemas utilizando esses IPs e nao achei nenhum outro documento que defina
um bloco pra isso.

Por isso gostaria de montar um grupo para submetermos ao IETF uma DRAFT de
RFC para que possamos delegar um bloco especifico para essa aplicacao, tendo
em vista que ja temos varias outras RFCs que delegam blocos para usos
espec?ficos nao creio que seja uma tarefa dificil

Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.

__

Junior Corazza

------------------------------

Message: 3
Date: Mon, 11 Dec 2017 09:17:54 -0200
From: Jefferson Gondek <jefferson.gondek at iveloz.net.br>
To: gter at eng.registro.br
Subject: Re: [GTER] Segestao de RFC
Message-ID: <dcefa432-f8c6-f523-20f6-07aa805848e7 at iveloz.net.br>
Content-Type: text/plain; charset=utf-8; format=flowed

Bom dia Junior,

 ? Acho a iniciativa muito v?lida, mas com alguns pontos a serem discutidos.

 ? Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram muito
bem com o uso de IPs da RFC1918.

 ? Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
lembrar que a RFC teria ?mbito mundial.

 ? Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
uma discuss?o que vai dar id?ias mas sem muitos resultados. 
Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o que
os demais tem em mente.

Acompanhando a discuss?o aqui.....

Abra?os.

Jefferson

Em 11/12/2017 07:52, Junior Corazza escreveu:
> Conforme disse em minha apresenta??o na GTER44, em alguns provedores 
> que faco consultoria devido a falta de endere?os IPs para o acesso 
> resolvi substituir todos os IPs publicos do backbone para IPs privados da
rfc1918.
> Com isso ganho alguns endere?os para que sejam aplicados no acesso de 
> clientes.
>
> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei 
> alguns problemas utilizando esses IPs e nao achei nenhum outro 
> documento que defina um bloco pra isso.
>
> Por isso gostaria de montar um grupo para submetermos ao IETF uma 
> DRAFT de RFC para que possamos delegar um bloco especifico para essa 
> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam 
> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>
>   
>
> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>
>   
>
> __
>
> Junior Corazza
>
>   
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 

------------------------------

Message: 4
Date: Mon, 11 Dec 2017 11:24:23 +0000
From: Bruno Cabral <bruno at openline.com.br>
To: "jefferson.gondek at iveloz.net.br" <jefferson.gondek at iveloz.net.br>,
	"Grupo de Trabalho de Engenharia e Operacao de Redes"
	<gter at eng.registro.br>
Subject: Re: [GTER] Segestao de RFC
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Se o problema foi nas conexoes saintes a partir do roteador, nada que um NAT
do IP privado nao resolva

Outra coisa que pode ser feita ? um aumento no TTL dos pacotes, "escondendo"
o IP do roteador

!3runo

--
Cursos e Consultoria BGP e OSPF
________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Jefferson Gondek
<jefferson.gondek at iveloz.net.br>
Enviado: segunda-feira, 11 de dezembro de 2017 09:17:54
Para: gter at eng.registro.br
Assunto: Re: [GTER] Segestao de RFC

Bom dia Junior,

   Acho a iniciativa muito v?lida, mas com alguns pontos a serem discutidos.

   Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram muito
bem com o uso de IPs da RFC1918.

   Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
lembrar que a RFC teria ?mbito mundial.

   Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
uma discuss?o que vai dar id?ias mas sem muitos resultados.
Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o que
os demais tem em mente.

Acompanhando a discuss?o aqui.....

Abra?os.

Jefferson

Em 11/12/2017 07:52, Junior Corazza escreveu:
> Conforme disse em minha apresenta??o na GTER44, em alguns provedores 
> que faco consultoria devido a falta de endere?os IPs para o acesso 
> resolvi substituir todos os IPs publicos do backbone para IPs privados da
rfc1918.
> Com isso ganho alguns endere?os para que sejam aplicados no acesso de 
> clientes.
>
> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei 
> alguns problemas utilizando esses IPs e nao achei nenhum outro 
> documento que defina um bloco pra isso.
>
> Por isso gostaria de montar um grupo para submetermos ao IETF uma 
> DRAFT de RFC para que possamos delegar um bloco especifico para essa 
> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam 
> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>
>
>
> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>
>
>
> __
>
> Junior Corazza
>
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

--
--
gter list    https://eng.registro.br/mailman/listinfo/gter

------------------------------

Message: 5
Date: Mon, 11 Dec 2017 09:22:00 -0200 (-02)
From: Danton Nunes <danton.nunes at inexo.com.br>
To: Grupo de Trabalho de Engenharia e Operacao de Redes
	<gter at eng.registro.br>
Subject: Re: [GTER] Segestao de RFC
Message-ID: <alpine.DEB.2.20.1712110902500.31399 at zaphod>
Content-Type: text/plain; charset=iso-8859-1; format=flowed

On Mon, 11 Dec 2017, Junior Corazza wrote:

> Conforme disse em minha apresenta??o na GTER44, em alguns provedores 
> que faco consultoria devido a falta de endere?os IPs para o acesso 
> resolvi substituir todos os IPs publicos do backbone para IPs privados da
rfc1918.
> Com isso ganho alguns endere?os para que sejam aplicados no acesso de 
> clientes.
>
> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei 
> alguns problemas utilizando esses IPs e nao achei nenhum outro 
> documento que defina um bloco pra isso.

o principal problema, como Rubens bem notou durante tua apresenta??o, ? o
endere?o de retorno de mensagens ICMP, que n?o ser? rote?vel.

creio que o uso de interfaces 'unnumbered' resolveria esse problema pois as
mensagens ICMP viriam com o endere?o da interface referenciada (normalmente
loopback ou algum ethernet).

> Por isso gostaria de montar um grupo para submetermos ao IETF uma 
> DRAFT de RFC para que possamos delegar um bloco especifico para essa 
> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam 
> blocos para usos espec?ficos nao creio que seja uma tarefa dificil

fica a pergunta, ser? que n?o seria trocar seis por meia d?zia? esse novo
bloco, que voc? at? sugeriu qual seria, seria t?o pouco rote?vel quanto os
blocos da BCP-5 (aka RFC-1918). para que fossem rote?veis seria necess?rio
uma autoridade (RIR?) que delegasse os endere?os do bloco para que fossem
?nicos, e que fossem anunciados pelo BGP. N?o creio que um bloco /16 teria
essas caracter?sticas.

se for para ficar sem as mensagens do ICMP ent?o n?o h? porque n?o usar os
endere?os BCP-5.

enquanto voltava para casa na Vila Mariana, espremido como sardinha em lata
no trem da CPTM, pintou uma ideia simples: porque n?o fazer todo o
encaminhamento da central ao cliente em n?vel 2 (ou dois e meio no caso),
sem usar qualquer endere?o IP, atrav?s de uma malha MPLS. Do ponto de vista
de IP a malha toda viraria um ?nico salto e n?o seriam necess?rios endere?os
IP nos roteadores intermedi?rios (ou poderiam ser endere?os BCP-5, ou ainda
IPv6, completamente invis?veis para o mundo externo). Al?m disso MPLS
permite fazer alguma engenharia de tr?fego, tipo controle de banda, e
encaminhamento din?mico para aproveitar caminhos redundantes.

-- Danton

------------------------------

Message: 6
Date: Mon, 11 Dec 2017 09:39:03 -0200
From: Douglas Fischer <fischerdouglas at gmail.com>
To: Jefferson Gondek <jefferson.gondek at iveloz.net.br>,  Grupo de
	Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Subject: Re: [GTER] Segestao de RFC
Message-ID:
	<CAKEr4RR81CoGQz-F2yLUGihJfmjN4HNuWyjwYo9695krEhuwsQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Al?m do Bloco espec?fico para isso, existem outras quest?es que voc? deve se
preocupar nesse draft.

Tens que definir t?cnicas que permitam que pacotes como o que o Rubens Kuhl
mencionou completem suas tarefas...
- "Packet too Big", relacionado a fragmenta??o
- "TTL Expired", usado nos traceroutes e tamb?m e caso de loops de
roteamento.
E por a? vai...

Algumas t?cnicas v?lidas:
- Em cada Router, ter um /32(ou /128) v?lido na DFZ definido numa loopback
  Configurar o Router para que toda resposta de ICMP(e similares) saia dessa
interface.
- Usar uma sub-rede delimitada para isso Ex.: 10.X.X.X/20.
  Definir um IP v?lido para usar para as respostas de todos esses pacotes de
controle
  Fazer um SRC-NAT perto da borda dizendo "Se vier de dentro da minha rede,
sendo dessa faixa, maqueie usando esse /32"
- Uma outra t?cnica seria colocar todo teu backbone em cima de um MPLS, e
esconder os TTL-Decrements.
  Essa inclusive ? uma t?cnica usada por v?rias operadora, onde posso citar
a Oi e a antiga Telef?nica(para o servi?o de VPN-L3).

Em 11 de dezembro de 2017 09:17, Jefferson Gondek <
jefferson.gondek at iveloz.net.br> escreveu:

> Bom dia Junior,
>
>   Acho a iniciativa muito v?lida, mas com alguns pontos a serem
discutidos.
>
>   Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram 
> muito bem com o uso de IPs da RFC1918.
>
>   Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um 
> bloco dedicado para este tipo de servi?o, tendo em falta IPs no 
> mercado. Vale lembrar que a RFC teria ?mbito mundial.
>
>   Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando 
> um bloco dentro do range disponibilizado, dedicado apenas a isso o que 
> tornaria mais r?pido e f?cil um throubleshooting. Visando um aspecto 
> v4, acredito ser uma discuss?o que vai dar id?ias mas sem muitos
resultados.
> Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o 
> que os demais tem em mente.
>
> Acompanhando a discuss?o aqui.....
>
> Abra?os.
>
> Jefferson
>
>
>
> Em 11/12/2017 07:52, Junior Corazza escreveu:
>
>> Conforme disse em minha apresenta??o na GTER44, em alguns provedores 
>> que faco consultoria devido a falta de endere?os IPs para o acesso 
>> resolvi substituir todos os IPs publicos do backbone para IPs privados da
rfc1918.
>> Com isso ganho alguns endere?os para que sejam aplicados no acesso de 
>> clientes.
>>
>> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei 
>> alguns problemas utilizando esses IPs e nao achei nenhum outro 
>> documento que defina um bloco pra isso.
>>
>> Por isso gostaria de montar um grupo para submetermos ao IETF uma 
>> DRAFT de RFC para que possamos delegar um bloco especifico para essa 
>> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam 
>> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>>
>>
>> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>>
>>
>> __
>>
>> Junior Corazza
>>
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>>
> --
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

--
Douglas Fernando Fischer
Eng? de Controle e Automa??o

------------------------------

Subject: Digest Footer

--
gter digest list    https://eng.registro.br/mailman/listinfo/gter

------------------------------

End of gter Digest, Vol 177, Issue 17
*************************************