[lacnog] Question about 240/4 space

Jue Jul 25 10:26:56 -03 2019

This reminds me to the 5 stages of grief.

https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model

I thought that we were in "acceptance" but it looks that we are going back
to "bargain".

:)

On Thu, Jul 25, 2019 at 3:30 AM Fernando Frediani <fhfrediani en gmail.com>
wrote:

> Hello Jordi, Carlos e Jorge.
> Thanks a lot for your input and views on this subject.
>
> Yes, I think one the main things to look at is this need of firmware
> upgrades everywhere and where it has been blocked to be forwarded as
> legitimate packet. But here it comes the first question: Is that the
> situation on all or majority of big vendors or just some of them ?
>
> On the last proposal I have read it is mentioned there by the authors: "
>
> *The following operating systems support the use of 240.0.0.0/4
> <http://240.0.0.0/4> as unicast, globally reachable address space: Solaris,
> Linux, Android, Apple OSX, Apple IOS, and FreeBSD.  This support has
> existed since    approximately 2008.  There are some issues with parts of
> BSD network stack that treat Class-E addresses as "invalid".  There are
> also cases of translation (NAT64) where checks reject Class-E addresses and
> need small fixes.  In both cases we have the patches under review for
> FreeBSD.  Four out of the top 5 open source IoT stacks already treat 240/4
> as unicast, with a 3 line patch awaiting submission for the fifth. ... **Juniper
> routers block traffic for 240/4 by default, but there has been a simple
> configuration switch to disable that check since 2010, at which point they
> are fully functional."*
>
> One big problem mentioned that remains is about recent versions of
> Microsoft Windows. That would certainly have to be worked out, but in the
> other hand the upgrade is much easier to reach most PCs than a firmware.
>
> I must agree with Carlos mention about an kind 'poor quality IP space' due
> to these various issues that would arise. If that would ever come to be a
> reality it would have to be at some point some level of forced retirement
> of many devices that no longer can receive updates. And certainly this type
> of thing must be accounted on the total cost.
>
> With regards Jordi's mention of a single vendor not willing to do the
> proper updates to support 240/8 I guess that may not be a showstopper, but
> instead just a hindering. Here it comes something interesting: as this
> would be something very apparent and almost impossible to not be unnoticed,
> it would be a lot of damage to those vendors who fail to adapt. I mean, it
> would not be something partial that could or not pass unnoticed in some
> situations like a minor IPv6 of BGP feature not working as expected.
> Obviously this must also be accounted to the total cost of making it happen.
>
> Again, my view is that something like this will not hit IPv6 Deployment. I
> think it is happening well lately and will lucky continue to happen
> exponentially for the next years and a optimistic scenario. But in the
> other hand I still believe the dependency of IPv4 will increase in such way
> that in not much time ahead it will start to cause serious growing
> conflicts that will not be restricted to specific companies. As you very
> well know they will still be need for translations even in a
> near-perferct-IPv6 environment/network, some Hosting scenarios and not to
> be forgotten, the new comers as Autonomous Systems that are equally
> important the others mentioned.
>
> To finish, one question that still keeps hitting my mind remains: Who had
> the idea in first place to put a block in a IP space tagged as "Future Use"
> by IANA ? What came to his/her mind to imagine it would never be used for
> unicast ?
>
> Best regards
> Fernando Frediani
> On 24/07/2019 17:40, Carlos Marcelo Martinez Cagnazzo wrote:
>
> Hi Fernando,
>
> I’ll be answering in Spanish if that is not a problem.
>
> Es una muy buena pregunta. Resumiendo, el espacio IPv4 240.0.0.0/4 está
> marcado en los registros de IANA como “Uso Futuro”. Esta asignación surge
> de la Sección 4 de la RFC 1112 (https://tools.ietf.org/html/rfc1112). La
> pregunta es… ¿no podemos re-designar estos 16 /8s como espacio unicast y
> asignarlos, dado que son tan necesarios?
>
> Es una pregunta muy válida. La RFC 1112 data de 1989, una fecha que parece
> hoy casi prehistórica. La Internet en 1989 era una red pequeña, limitada a
> organizaciones de gobierno, universidades, etc.
>
> Yo tengo mi posición personal, y no estoy convencido de que valga la pena.
> No porque “vaya a demorar el despliegue de IPv6”, sino por otra razón. Este
> espacio de direcciones, si lo comenzamos a asignar, va a ser un espacio de
> direccionamiento de calidad inferior.
>
> ¿Porque?
>
> Para poder utilizar 240/4 como espacio unicast hace falta que los
> fabricantes de equipamiento *todos* actualicen su software y en sus stacks
> permitan que paquetes en este rango de direcciones sea procesado como
> unicast. Estoy hoy no es así.
>
> Ahora bien, no alcanza solo con que los fabricantes actualicen su
> software. TODOS nosotros operadores desde microscópicos a gigantes tenemos
> que actualizer los softwares y firmwares de TODO nuestro equipamiento para
> que estos paquetes en la 240/4 sean tratados de igual manera que digamos,
> los de la 179/8. Todo equipo que hable IP producido en los últimos 30 años
> va a tener que ser actualizado.
>
> Nuestro historial como industria implementando estos cambios en escala es
> muy malo. Hasta el día de hoy hay firewalls que descartan paquetes UDP de
> DNS de mas de 512 bytes (EDNS0 data de 2013), stacks que implementan IPv6
> mal, routers que no soportan ciertos elementos de BGP, etc.
>
> Lo que va a pasar es que eventualmente comencemos a asignar espacio de la
> 240/8, quienes reciban espacio van a tener un servicio de calidad muy muy
> inferior. Van a tener errores de conexión y timeouts muy difíciles de
> depurar. Van a tener problemas con sus clientes. Van a tener problemas en
> conseguir tránsito y peering que soporte esto.
>
> Por este motivo fundamentalmente, no estoy de acuerdo con la propuesta.
> Sin embargo, la discusión está abierta en el IETF y serán todos más que
> bienvenidos en enviar sus comentarios a las listas de correo relevantes.
>
> Saludos,
>
> /Carlos
>
> On Jul 24, 2019, at 4:16 PM, Fernando Frediani <fhfrediani en gmail.com>
> wrote:
>
> Hello folks
>
> I wanted to put a question about this topic in order to learn a bit deeper
> into this question from the community who have better knowledge about it,
> specially those who have more IETF involvement.
>
> The last time I asked why still the 240/4 wasn't turned into usable /8's
> to be distributed to all RIRs and therefore to LIRs and End-users. The
> explanation I was given at the time was that people considered it for quiet
> a while and came to a conclusion that was not worth the cost of 'changing
> everything needed to be changed' in order to make it work as expected. Some
> have mentioned that some network firmware had embedded in it to not even
> forward packets in this IP space.
> On this basis I wanted also to understand also who was the 'clever' idea
> to deny forwarding to this packets in firmware to something tagged as
> "Future Use", therefore that had the expectation to be used one day in the
> future ?
>
> I am asking this because I have been reading some 'yet again' proposals to
> make it viable and wanted to understand what are the the biggest technical
> challenges to make it viable.
> If it is true that some firmware have this limitation, and it goes down to
> a CPE level I can start understanding the amount of work to get every
> single equipment updated to be able to talk to these future networks. Even
> in a ISP/Telecom level one thing that comes to mind is where you have very
> old and EOF routers still in production and people refusing to take them
> our of production, no doubt even if Network vendors would provide an
> updated firmware version those routers would never receive it. Besides that
> what other big concerns are in your view ?
>
> With regards the points some people frequently raise about that any
> extension to IPv4 space is a killer to IPv6 Deployments to come, I
> personally refuse to believe in that, at least not in a binary way was
> sometimes is preached. I see that regardless the improvements in IPv6
> deployment (which I obviously support and actively practice on my day by
> day) I always had the impression that we will live with the IPv4 internet
> for at least, in a very optimistic scenario for another 10 years or more.
> Recently I read a report about this subject that mentioned at least another
> 20 years.
>
> And even when it is said that no matter how much IPv4 becomes available it
> will never be enough and would be exhausted quiet quickly (probably true).
> Well, I would say that if there is any chance for these 'new' IPv4 to
> become functional they should never be intended to be used as they have
> been in the last decades, but instead to certain and specific usages as
> mainly facilitate IPv6 deployment and translation techniques, Hosting and
> other scenarios where no-IPv4-at-all is not an option.
>
> Appreciate any comments and contributions to make it possible to
> understand this subject better.
>
> Best regards
> Fernando Frediani
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> _______________________________________________
> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190725/fa80645a/attachment.html>