[lacnog] Question about 240/4 space
Arturo Servin
arturo.servin en gmail.com
Jue Jul 25 12:15:16 -03 2019
>Well, trying with 0/8 and 127/8 really looks strange, but the reason I
asked this question in first place is to understand what really happened
I think Carlos explained very well.
Too much work, no real gain. Then, move on.
>44/8 in NANOG
I think that is another issue (related to the scarcity of v4 but unrelated
to the 240/4) as for some people discussing in the thread it was not a
clear "ownership" of the space to sell it.
Regards
as
On Thu, Jul 25, 2019 at 5:06 PM Fernando Frediani <fhfrediani en gmail.com>
wrote:
> Well, trying with 0/8 and 127/8 really looks strange, but the reason I
> asked this question in first place is to understand what really happened
> a while back to come into this situation and find out who actually
> caused this having the idea of blocking traffic with this IP space and
> throw in the bin not less than 268 million IP addresses, more than the
> entire population of Brasil and Argentina, together.
>
> As mentioned I personally find concerning what is already happening and
> the conflicts that are arising due to exhaustion of IPv4. If some here
> haven't seen yet, I invite to watch the discussion about the selling of
> part of 44/8 in NANOG. It looks like we will have situations worst than
> that in the near future, regardless how well the IPv6 deployments go
> when that issue start to hit harder people's business.
>
> Regards
> Fernando
>
> On 25/07/2019 10:41, Carlos Marcelo Martinez Cagnazzo wrote:
> > Then why not go after 127/8 also ? After all we only use one host out of
> the whole /8.
> >
> >> On Jul 25, 2019, at 9:38 AM, Luis Balbinot <luis en luisbalbinot.com>
> wrote:
> >>
> >> And now for something completely different...
> >>
> >>
> https://hub.packtpub.com/linux-kernel-announces-a-patch-to-allow-0-0-0-0-8-as-a-valid-address-range/
> >>
> >> Luis
> >>
> >> On Thu, Jul 25, 2019 at 10:27 AM Arturo Servin <arturo.servin en gmail.com>
> wrote:
> >>>
> >>> 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
> 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 list
> >>>> LACNOG en lacnic.net
> >>>> https://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
> >>> _______________________________________________
> >>> 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 list
> >> LACNOG en lacnic.net
> >> https://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
> _______________________________________________
> 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/4e27adf5/attachment-0001.html>
Más información sobre la lista de distribución LACNOG