[lacnog] Registro de puertos de origen en servidores web / Source Port Logging on Web Servers

Lun Abr 8 10:29:18 -03 2019

Hola Fernando,

El 8/4/19 14:41, "Fernando Gont" <fernando en gont.com.ar> escribió:

    On 7/4/19 23:03, JORDI PALET MARTINEZ via LACNOG wrote:
    > Fernando,
    > 
    > No se que es lo que consideras descalificación, pero no veo que haya
    > dicho nada descalificativo. Los datos que yo aporto te aseguro que
    > son siempre contrastados, otra cosa es que pueda publicar las
    > fuentes.
    > 
    > Insisto, esos datos no siempre son públicos, yo no opero mi propia
    > red de la que poderlos facilitar, los tengo de clientes, pero
    > obviamente no puedo darlos.

    CUando el numero es un numero abstracto, sin especificar contexto y
    demas, y en particular cuando numerosas veces has hecho aseveraciones
    que me constaba que no eran correctas, no puedo creerte la aseveracion
    sin respaldo.

    > Sin embargo, para nada es galerazo como tu dices, son datos que un
    > gran operador ha facilitado en la lista de v6ops, aproximadamente si
    > mi memoria no me falla (y no suele), en octubre del año pasado, y
    > otros han confirmado datos casi idénticos, y los autores del
    > documento los hemos confirmado en privado con otras redes.

    También te he escuchado otras tantas aseveraciones "super confirmadas",
    que me constaba que no eran veridicas.

    > No voy a perder el tiempo en buscar el mensaje de v6ops (el que
    > quiera que lo busque, están todos archivados), porque te daría igual
    > y seguirás discutiendo que como no se demuestran, aunque los diga un
    > operador, tu no te los crees.

    SI el dato es de *una* red, me interesa saber como midieron, en que
    condiciones, y demas. Asi de simple.

    Y si la aseveracion es general, me interesa lo mismo, sumado a la
    metodologia, y la manera en que pueda reproducir la medicion yo mismo.

    Ejemplo: vos has aseverado en conversacion nuestra por twitter (publica)
    que ahora ha mejorado la situacion de los EH en internet. Para tal
    aseveracion, esperaba algo con igual o mayor rigurosidad que RFC 7872.
    TE pedi referencias al menos un apr de veces... y nunca recibi nada.

Acabo de mirar en twitter y tengo que insistir en lo que dije. Bajo mi punto de vista, a algo que dije ("Los protocolos pueden ser perfectos y los operadores o implementaciones, usarlos mal. Ejemplo si un operador filtra DNS, esta mal hecho el protocolo o el operador lo hace mal ?"), tu lo sacaste por la tangente y yo insisto en ello. Podemos tener cualquier protocolo perfecto, y sin embargo los operadores pueden aplicarlo mal. Eso pasa en Internet y en cualquier sector de la actividad.

    [...]
    > Como resumen de ese documento, tienes que el tráfico de video de
    > Internet es del 58%, y su distribución varía de unas regiones a
    > otras, entre NetFlix, Youtube y Facebook. Si a eso le sumas el resto
    > del tráfico del resto de las webs de Google, Facebook, y todos los
    > CDNs y caches, se confirma que, en una red residencial, el tráfico
    > medio supera el 65% que he indicado hacia CDNs, y seguramente me he
    > quedado hasta corto. Y todo ese trafico esta disponible con IPv6.

    En el contexto de tal aseveracion:
    Por que asumis que por estar disponible en IPv6 se lo accede por IPv6?

Por la experiencia en las redes cuyos datos conozco que no es poca, y que coincide con las de otras redes que han hecho públicos sus datos, como T-Mobile en v6ops.

Si tu tienes una red dual-stack y tienes CDNs y caches en tu propia red o en el IX (también con dual-stack, pues desde hace años la mayoría de los CDNs y caches exigen soporte de IPv6 para "conectarse"), salvo que tengas *mal* implementado IPv6 y por lo tanto actúe happy-eyeballs, el trafico será IPv6.

Si actúa happy-eyeballs en algo "auto-contenido" (que eso es básicamente un CDN o caché) en tu propia red o IX (no en algo remoto que te pueden afectar proveedores de transito o de contenidos ajenos a ti), realmente tienes un problema importante.

    [...]
    > 
    > Respecto del mensaje que indicas de v6ops no lo he podido abrir, pero
    > me suena que lo contesto Ole Troan, que obviamente siendo el autor de
    > MAP, no va a defender otra cosa que no sea sus propios protocolos y
    > no CLAT.

    TU aseveracion havia sido arbitraria, en aquel caso tambien.

Yo he visto código fuente de CLAT y de MAP, y es muchísimo mas pequeño en el primer caso. De hecho, en OpenWRT puedes ver que ocupa mucho menos, y lo hemos reportado en el ID:

   As hint to the relative complexity of the mechanisms, the following
   code sizes are reported from the OpenWRT implementations of each
   technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6,
   DS-Lite, MAP-E, MAP-T, respectively.

Si esto son datos arbitrarios tomados en su momento del código de OpenWRT ... no se que serán datos reales.

Por si fuera poco, hicimos también una comparativa con otras implementaciones (VPP) y nos salían las mismas diferencias.    

    -- 
    Fernando Gont
    e-mail: fernando en gont.com.ar || fgont en si6networks.com
    PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.