<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Jordi, Carlos e Jorge.<br>
      Thanks a lot for your input and views on this subject.</p>
    <p>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 ?</p>
    <p>On the last proposal I have read it is mentioned there by the
      authors: "<i>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.<br>
        ...<br>
      </i><i>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."</i></p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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 ?</p>
    <p>Best regards<br>
      Fernando Frediani<br>
    </p>
    <div class="moz-cite-prefix">On 24/07/2019 17:40, Carlos Marcelo
      Martinez Cagnazzo wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:C17D8554-FCD0-4D39-94D9-A96103C721E1@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hi Fernando,
      <div class=""><br class="">
      </div>
      <div class="">I’ll be answering in Spanish if that is not a
        problem.</div>
      <div class=""><br class="">
      </div>
      <div class="">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 (<a
          href="https://tools.ietf.org/html/rfc1112" class=""
          moz-do-not-send="true">https://tools.ietf.org/html/rfc1112</a>).
        La pregunta es… ¿no podemos re-designar estos 16 /8s como
        espacio unicast y asignarlos, dado que son tan necesarios?</div>
      <div class=""><br class="">
      </div>
      <div class="">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.</div>
      <div class=""><br class="">
      </div>
      <div class="">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.</div>
      <div class=""><br class="">
      </div>
      <div class="">¿Porque?</div>
      <div class=""><br class="">
      </div>
      <div class="">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í. </div>
      <div class=""><br class="">
      </div>
      <div class="">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.</div>
      <div class=""><br class="">
      </div>
      <div class="">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.</div>
      <div class=""><br class="">
      </div>
      <div class="">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. </div>
      <div class=""><br class="">
      </div>
      <div class="">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. </div>
      <div class=""><br class="">
      </div>
      <div class="">Saludos,</div>
      <div class=""><br class="">
      </div>
      <div class="">/Carlos</div>
      <div class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On Jul 24, 2019, at 4:16 PM, Fernando Frediani
              <<a href="mailto:fhfrediani@gmail.com" class=""
                moz-do-not-send="true">fhfrediani@gmail.com</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <div class="">Hello folks<br class="">
                <br class="">
                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.<br class="">
                <br class="">
                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.<br
                  class="">
                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 ?<br class="">
                <br class="">
                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.<br class="">
                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 ?<br class="">
                <br class="">
                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.<br class="">
                <br class="">
                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.<br
                  class="">
                <br class="">
                Appreciate any comments and contributions to make it
                possible to understand this subject better.<br class="">
                <br class="">
                Best regards<br class="">
                Fernando Frediani<br class="">
                <br class="">
                <br class="">
                _______________________________________________<br
                  class="">
                LACNOG mailing list<br class="">
                <a href="mailto:LACNOG@lacnic.net" class=""
                  moz-do-not-send="true">LACNOG@lacnic.net</a><br
                  class="">
                <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br
                  class="">
                Cancelar suscripcion:
                <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><br
                  class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
    </blockquote>
  </body>
</html>