[lacnog] Fwd: shared address space... a reality!
Carlos Martinez-Cagnazzo
carlosm3011 en gmail.com
Jue Mar 15 11:50:21 BRT 2012
Hola!
Yo no seguí demasiado de cerca la discusión original, pero recuerdo que
una de las motivaciones era que aparentemente algunos dispositivos cuyo
software esta, digamos, pobremente escrito, toman ciertas decisiones
sobre si obtienen una direccion RFC 1918 en su interfaz WAN. Asumen que
no tienen internet, por ejemplo. Entonces, como forma de engañarlos, se
decidió tomar un bloque que 'parece' publico pero no lo es.
Personalmente los hubiese dejado que se hundan :-) Es decir, si un
software es tan malo se merece morir, pero bueno, si un ISP tiene uno o
dos millones de esos instalados, el punto de vista es otro.
Yo hice algunas pruebas, encadenando un WRT54G detrás de un Airport
Extreme, y un Airport Extreme detrás de un D-Link con modem 3G (esta
ultima obligado por un corte de mi servicio ADSL), y la verdad en ambos
casos me funcionó perfectamente.
Viendo el vaso medio lleno, ya que lo iban a hacer igual (es decir, los
proveedores enfrentados con este problema iban a empezar a re-utilizar
sus bloques publicos, diferentes en cada caso), creo que es preferible
que sea asi ya que justamente nos permite agregarlo a nuestras listas de
acceso.
Reflexión final: este es el feo rostro del agotamiento de IPv4. Este
tipo de parches horribles solo van a hacer las redes mas frágiles y
menos seguras con el paso del tiempo. Quiero mi IPv6 ya!
saludos
Carlos
On 3/15/12 11:41 AM, Tomas Lynch wrote:
> Lo que no entiendo es la decisión de poner una nueva red privada
> cuando justamente "vamos todos a morir" porque no hay más direcciones
> ipv4.
>
> No me quiero meter en la conversación de NANOG ya que tipicamente
> terminan hablando de cualquier cosa generada por roces internos en esa
> comunidad, pero ¿alguien conoce los motivos de hacer eso? ¿quién usa
> tantas direcciones privadas para que un bloque privado haga
> 'overlapping' con el /8, el /12 y el /16 del RFC1918?
>
> Lo digo desde el lado del proveedor de servicios donde le niegan un
> /21 y de pronto separan un /10 para que la gente se divierta.
>
> 2012/3/14 Carlos Martinez-Cagnazzo <carlosm3011 en gmail.com
> <mailto:carlosm3011 en gmail.com>>
>
> Hola a todos!
>
> Mas allá de la opinión de c/u sobre esto es bueno saber que se
> asignó el bloque que se esperaba para 'IPv4 shared space'.
> Básicamente esto surgió de una política de ARIN donde se pidió
> reservar un bloque de direcciones v4 específicamente para utilizar
> de manera compartida en tecnologías de transición a IPv6, que
> pueden ir desde un NAT64, CGN u otras cosas)
>
> El bloque es el 100.64.0.0/10 <http://100.64.0.0/10> y los
> administradores de redes deberían tratarlo de la misma manera que
> al espacio de la RFC 1918, porque es en definitiva lo que es, una
> extensión del espacio privado.
>
> En otros términos, paquetes con origen en estas direcciones son
> 'martians'.
>
> Hay un draft del IETF donde se explica el rationale detrás de esto
> [1] y está la política de ARIN 2011-5 [2]
>
> [1]:
> http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15
> [2]: https://www.arin.net/policy/proposals/2011_5.html
>
> slds
>
> Carlos
>
> -------- Original Message --------
> Subject: shared address space... a reality!
> Date: Wed, 14 Mar 2012 02:22:04 -0400
> From: Christopher Morrow <christopher.morrow en gmail.com>
> <mailto:christopher.morrow en gmail.com>
> To: nanog list <nanog en nanog.org> <mailto:nanog en nanog.org>
>
>
>
> NetRange: 100.64.0.0 - 100.127.255.255
> CIDR: 100.64.0.0/10 <http://100.64.0.0/10>
> OriginAS:
> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20120315/395e8544/attachment.html>
Más información sobre la lista de distribución LACNOG