Mostrando entradas con la etiqueta ip. Mostrar todas las entradas
Mostrando entradas con la etiqueta ip. Mostrar todas las entradas

lunes, 15 de septiembre de 2025

Manos a la obra - Nuevo espacio de Documentación IPv6: Un Enfoque Práctico (3FFF::/20)

Introducción

El 23 Julio de 2024 la IANA asignó el bloque de direcciones 3FFF::/20 como un nuevo espacio de direccionamiento para documentación de IPv6, agregando así un nuevo bloque de direcciones al ya existente (2001:db8::/32). Esta solicitud fue realizada en el draft https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/ que reza de la siguiente manera (traducido al español):


“El documento describe la reserva de un prefijo de dirección IPv6 adicional para su uso en la documentación. Esta actualización del RFC 3849 amplía el bloque de direcciones 2001:db8::/32 existente con la reserva de un prefijo adicional más grande. La adición de un /20 permite que los ejemplos documentados reflejen fielmente una gama más amplia de escenarios de implementación realistas y actuales y se alinean más estrechamente con los modelos de asignación contemporáneos para redes grandes”.

A raíz de esta ampliación, desarrollaremos en este artículo un plan de direccionamiento IPv6 a modo de ejemplo, con el bloque de direcciones 3FFF::/20.


Importancia de un Plan de Direccionamiento IP

¿Qué es un plan de direccionamiento IP (v4|v6)?

Un plan de direccionamiento IP se define como el modo, las acciones o el modelo sistemático para llevar a cabo las asignaciones de direcciones IP en una red [1].


¿Por qué debo hacer un plan de direccionamiento IP?

  1. Ayuda a mantener el orden en la documentación de la red.
  2. Políticas de asignación más fáciles de implementar.
  3. Ayuda en el crecimiento ordenado de la red (asignaciones futuras/escalamiento)
  4. Eficiencia en el performance de la red (tablas de rutas más pequeñas).
  5. Facilita el Troubleshooting.
  6. Gestión más sencilla de la red.

¿Cómo debe ser el plan de direccionamiento IP? ¿Qué debo buscar en él?

  1. Debe ser escalable (imaginemos cómo crecerá la red de aquí a 2, 5, 10 y 15 años).
  2. Debe ser flexible. Por ejemplo, el día de mañana pueden haber nuevos servicios o expandir la cobertura hacia otras ciudades.
  3. Debe ser simple y entendible, es decir, que evite complicar las cosas.
  4. Debe armarse con las mejores prácticas.
  5. Debe separar Infraestructura de clientes (importante).


Recomendaciones para empezar a hacer el plan de Direccionamiento IPv6.

1)   El principal consejo y uno de los más básicos es manipular los bloques por nibbles, en pocas palabras, por cada carácter de la dirección IPv6.

¿Cómo quedaría visualmente el nuevo prefijo 3FFF::/20?

Como se observa en la siguiente imagen, debido a que el prefijo es un /20, los 5 primeros nibbles son fijos y todos los caracteres en “X” son los modificables:


2)   Mapear los nibble para una función

Una práctica habitual es mapear un nibble o un grupo de nibbles a “algo”, siendo ese “algo” una función, un país, un servicio, tipo de clientes, entre otros.

Con el siguiente gráfico se detalla lo antes mencionado:

Para ISP:



Para Usuario Final (EU):



Importante: recordemos que los últimos 64 bits (C5, C6, C7 y C8) usualmente son asignados por el proceso de autoconfiguración y/o manualmente por el administrador.


Nota: Estos ejemplos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.

Ejemplo práctico de un Plan de Direccionamiento IPv6:

Aquí te dejamos un par de ejemplos de un plan de direccionamiento utilizando el nuevo prefijo 3FFF::/20.


Nota: Estos ejemplos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.Plan de Direccionamiento IPv6 para un ISP:

Para este escenario se ha considerado un ISP que opera en 3 países y 3 ciudades en cada país. Por lo que, utilizando la nomenclatura del ejemplo anterior, se han colocado valores y reemplazado los caracteres, de acuerdo con la categoría que representan, según se observa en la siguiente tabla:

Caracteres a ser modificadosCategoríaValoresDescripción de lo que representan
PPPPaís058Venezuela
057Colombia
051Perú
CCCCiudad212Caracas
261Maracaibo
241Valencia
601Bogotá
604Medellín
605Cartagena
031Lima
032Arequipa
033Cusco
SSServicio10Internet HFC
20Internet GPON
30Internet Satelital
TTipo de Cliente1Empresa
2Entidad del gobierno
3Residencial
4ONG

El Plan de Direccionamiento IPv6 de ejemplo para un ISP quedaría de la siguiente manera:

Prefijo IPv6PaísPrefijo asignado al país [NET_ID]CiudadSubred asignada la ciudad [Subnet]ServicioTipo de clienteSubred asignada al servicio y tipo de cliente [Divison]
3FFF::/20Venezuela3FFF:0058::/32Caracas3FFF:0058:0212::/48Internet HFCEmpresa3FFF:0058:0212:0101::/64
Entidad del gobierno3FFF:0058:0212:0102::/64
Residencial3FFF:0058:0212:0103::/64
ONG3FFF:0058:0212:0104::/64
Internet GPONEmpresa3FFF:0058:0212:0201::/64
Residencial3FFF:0058:0212:0203::/64
Maracaibo3FFF:0058:0261::/48Internet GPONEmpresa3FFF:0058:0261:0201::/64
Entidad del gobierno3FFF:0058:0261:0202::/64
Residencial3FFF:0058:0261:0203::/64
ONG3FFF:0058:0261:0204::/64
Valencia3FFF:0058:0241::/48Internet GPONEmpresa3FFF:0058:0241:0201::/64
Entidad del gobierno3FFF:0058:0241:0202::/64
Internet SatelitalResidencial3FFF:0058:0241:0303::/64
ONG3FFF:0058:0241:0304::/64
Colombia3FFF:0057::/32Bogotá3FFF:0057:0601::/48Internet HFCEmpresa3FFF:0057:0601:0101::/64
Entidad del gobierno3FFF:0057:0601:0102::/64
Residencial3FFF:0057:0601:0103::/64
ONG3FFF:0057:0601:0104::/64
Medellín3FFF:0057:0604::/48Internet GPONEmpresa3FFF:0057:0604:0201::/64
Entidad del gobierno3FFF:0057:0604:0202::/64
Residencial3FFF:0057:0604:0203::/64
ONG3FFF:0057:0604:0204::/64
Cartagena3FFF:0057:0605::/48Internet GPONEmpresa3FFF:0057:0605:0201::/64
Entidad del gobierno3FFF:0057:0605:0202::/64
Internet SatelitalResidencial3FFF:0057:0605:0303::/64
ONG3FFF:0057:0605:0304::/64
Perú3FFF:0051::/32Lima3FFF:0051:0031::/48Internet GPONEmpresa3FFF:0051:0031:0201::/64
Residencial3FFF:0051:0031:0203::/64
Internet SatelitalResidencial3FFF:0051:0031:0303::/64
Arequipa3FFF:0051:0032::/48Internet HFCEmpresa3FFF:0051:0032:0101::/64
Entidad del gobierno3FFF:0051:0032:0102::/64
Residencial3FFF:0051:0032:0103::/64
ONG3FFF:0051:0032:0104::/64
Internet GPONEmpresa3FFF:0051:0032:0201::/64
Entidad del gobierno3FFF:0051:0032:0202::/64
Residencial3FFF:0051:0032:0203::/64
ONG3FFF:0051:0032:0204::/64
Cusco3FFF:0051:0033::/48Internet GPONEmpresa3FFF:0051:0033:0201::/64
Residencial3FFF:0051:0033:0203::/64
Internet SatelitalONG3FFF:0051:0033:0304::/64
Bloques de Reserva3FFF:0004::/32 – 3FFF:0FFF::/32Bloques IPv6 de reserva/32
  • Plan de Direccionamiento IPv6 para un Usuario Final (EU):

En el escenario de Usuario Final (EU) se va a plantear el ejemplo utilizando el caso de una Universidad (con 3 sedes). Se han colocado valores y reemplazado los caracteres, de acuerdo con la categoría que representan, según se observa en la siguiente tabla:

Caracteres a ser modificadosCategoríaValoresDescripción de lo que representan
UUUSede/Ubicación001Campus Principal
002Campus Secundario 1
003Campus Secundario 2
EEEEdificio111Edificio 1
222Edificio 2
333Edificio 3
SSServicio10Internet HFC
20Internet GPON
FFacultad1Derecho/ legal
2Medicina
3Administración
4Ingeniería

El Plan de Direccionamiento IPv6 de ejemplo para un Usuario Final (EU) quedaría de la siguiente manera:

Prefijo IPv6Sede/ UbicaciónPrefijo asignado a la Sede [NET_ID]EdificioSubred asignada al edificio [Subnet]ServicioFacultadSubred asignada al servicio y a la facultad [Divison]
3FFF::/20Campus principal3FFF:0001::/32Edificio 13FFF:0001:0111::/48Internet HFCDerecho/ legal3FFF:0001:0111:0101::/64
Medicina3FFF:0001:0111:0102::/64
Administración3FFF:0001:0111:0103::/64
Ingeniería3FFF:0001:0111:0104::/64
Internet GPONDerecho/ legal3FFF:0001:0111:0201::/64
Administración3FFF:0001:0111:0203::/64
Edificio 23FFF:0001:0222::/48Internet GPONDerecho/ legal3FFF:0001:0222:0201::/64
Medicina3FFF:0001:0222:0202::/64
Administración3FFF:0001:0222:0203::/64
Ingeniería3FFF:0001:0222:0204::/64
Edificio 33FFF:0001:0333::/48Internet GPONDerecho/ legal3FFF:0001:0333:0201::/64
Medicina3FFF:0001:0333:0202::/64
Campus secundario 13FFF:0002::/32Edificio 13FFF:0002:0111::/48Internet HFCDerecho/ legal3FFF:0002:0111:0101::/64
Medicina3FFF:0002:0111:0102::/64
Administración3FFF:0002:0111:0103::/64
Ingeniería3FFF:0002:0111:0104::/64
Edificio 23FFF:0002:0222::/48Internet GPONDerecho/ legal3FFF:0002:0222:0201::/64
Medicina3FFF:0002:0222:0202::/64
Campus secundario 23FFF:0003::/32Edificio 13FFF:0003:0111::/48Internet GPONDerecho/ legal3FFF:0003:0111:0201::/64
Administración3FFF:0003:0111:0203::/64
Edificio 23FFF:0003:0222::/48Internet GPONDerecho/ legal3FFF:0003:0222:0201::/64
Administración3FFF:0003:0222:0203::/64
Bloques de Reserva3FFF:0004::/32 – 3FFF:0FFF::/32Bloques IPv6 de reserva/32

Conclusiones

Se debe buscar que el plan de direccionamiento IPv6 sea escalable, fácil de entender y que ayude en la administración de la red. Si bien no existe una única manera de elaborar un plan de direccionamiento IPv6, se recomienda considerar importante la separación por caracteres nibbles y asignar una función/tarea a cada caracter nibble. Esto permitirá mantener un orden durante las asignaciones durante la operación de la red.

Referencias

[1]  https://blog.acostasite.com/2018/06/concepto-que-es-un-plan-de.html?m=1

https://datatracker.ietf.org/doc/rfc9637

[2] LACNIC Podcast  Ampliación del espacio documentación IPv6

Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.

sábado, 1 de enero de 2022

Microcuento de navidad de IPv4 e IPv6

Transcurre el año 2043, en un pequeño pueblo en Netland, justo antes de navidad, IPv6 se encuentra sentado en un pequeño microchip dentro de un router; como si fuese una chimenea sentía el calor de las compuertas lógicas y justo antes de ser inyectado en la red WiFi percibe una soledad y vienen muchos recuerdos, una imagen que ya hace mucho no se podría recuperar del caché del equipo, viene a su memoria un viejo compañero de guerra, un señor llamado IPv4 que casi nunca aparece en estos días. Lo primero que viene a su memoria eran las competencias que existían 20 años atrás, cuando su dueño les pedía hacer algo salían juntos lo más rápido con el objetivo de llegar primeros y darle respuesta lo más rápido posible. Siempre fue una carrera muy cerrada y el pronóstico del ganador era siempre reservado. Luego recuerda con dolor aquellos sufrimientos por los que pasaba IPv4 antes de llegar a su destino, era literalmente una mutación lo que ocurría, IPv6 nunca lo entendió pero sabe que no fueron momentos agradables, IPv4 a veces incluso ganaba la carrera pero el dueño no quedaba contento y no recibía su premio. Un recuerdo nada satisfactorio era la pérdida de algún compañero, sobre todo al comienzo de la misma, muy frecuentemente IPv4 sencillamente desaparecía en esos primeros 100 metros. Existía un recuerdo que siempre le sacaba una sonrisa a IPv6, rememoraba aquellos primeros momentos, cuando era aún un pequeño bebé en sus primeros años y no tenía buenos resultados en sus recorridos, comúnmente perdía. Hoy en día se llena de orgullo pensando que es un ganador que luchó innumerables batallas ante un gran guerrero. Nanosegundos antes sentir el viento dentro de la red WiFi, IPv6 toma ánimo, a pesar de que ya es un ganador no baja la guardia, lucha sus batallas y como deseo de año nuevo pide cosas sencillas: a) que no existan congestión de redes, b) adiós a las colisiones, c) que no haya pérdida de paquetes y que todo el planeta tenga Internet. Feliz navidad 2021 y feliz año 2022. Alejandro Acosta,

miércoles, 11 de marzo de 2020

Tunel GRE entre Linux y Cisco IOS

Lado del linux:

[root@server]# ip tunnel add tun0 mode gre remote $public_ip_cisco local $public_ip_linux ttl 255
[root@server]# ip link set tun0 up

[root@server]# ip addr add 172.20.0.2/30 dev tun0


Del lado del Cisco

interface Tunnel0
 description Tunel hacia sitio remoto
 ip address 172.20.0.1 255.255.255.252
 tunnel source $public_ip_cisco
 tunnel destination $public_ip_linux

end

  Para enrutar cierta red desde el Cisco hacia el linux via el tunel: 

ip route $prefix $mask 172.20.0.2 


Espero sea útil.

Saludos





jueves, 13 de febrero de 2020

Análisis sobre la publicación de prefijos/redes IPv6 en LAC

Introducción

En el presente estudio deseamos mostrar de manera resumida el estado de visibilidad de prefijos IPv6 en nuestra región.

Motivación

Dentro de LAC hemos identificado que existe una gran cantidad de organizaciones que aún no realizan el anuncio de su prefijo IPv6 a pesar de contar con el mismo. Esperemos con este análisis concientizar aquellas entidades que teniendo su prefijo IPv6 den el primer paso para su uso.

Fuente de los datos
  Las fuentes de datos utilizadas son: 
  1. El delegated extended de LACNIC [1] para la obtención de los prefijos IPv6
  2. El API de Routing Status de RIPE [2] para conocer el estado de los prefijos IPv6 en la DFZ


Procedimiento

El proceso es bastante lineal, básicamente por cada prefijo IPv6 de LACNIC se busca su estado en la tabla global de enrutamiento.

Ejemplos de resultados:
  Caso 1: Prefijo asignado se encuentra en la tabla global de enrutamiento idéntico:




El resultado es un JSON y en el mismo podemos apreciar que indica el origins para el prefijo consultado resource lo que indica que en la tabla BGP el anuncio del prefijo es idéntico al asignado por LACNIC.

data
query_time "2020-01-17T16:00:00"
resource "2803:6680::/32"  ←--- Prefijo anunciado = prefijo asignado por LACNIC
origins
0 ←--- ID para cada origins
origin 267789   ←--- AS que hace el anuncio


  Caso 2: Prefijo asignado se encuentra anunciado en subredes más específicas (y no un anuncio idéntico al asignado):


En este caso el resource aparece pero sin origins:


data
query_time "2020-01-17T16:00:00"
resource "2001:13c7:6010::/44"
origins []   ←--- Vacio




Y adicionalmente en el json más abajo tenemos una sección llamada “more_specifics” la cual nos indica claramente que subredes del prefijo original son las anunciadas

more_specifics
0 ←--- ID 0
origin 52375  ←--- AS origin de una subred del prefijo orignal
prefix "2001:13c7:6011::/48" ←--- Una subred dentro del prefijo original
1
origin 52404  ←--- AS que hace el anuncio de una subred del prefijo orignal
prefix "2001:13c7:6013::/48"  ← recordar el prefijo original era: /44
2
origin 52500  ←--- AS que hace el anuncio de una subred del prefijo orignal
prefix "2001:13c7:6014::/48"


  Caso 3: Prefijo asignado no se encuentra anunciado




Tanto el origins en el prefijo original como la sección “more_specifics” se encuentra sin información:


data
query_time "2020-01-17T16:00:00"
resource "2801:80:1d40::/48"
origins []  ←--- Vacio
less_specifics []
more_specifics [] ←--- Vacio


Otros casos


Pudiesen existir otros casos, por ejemplo que el prefijo se encuentre anunciado en su totalidad y adicionalmente existan otros anuncios más específicos, sin embargo no los tomamos en cuenta porque no aporta en el objetivo del estudio

Procesamiento de la data
  Todo el procesamiento, limpieza y depuración de la información fue realizado con python3


Verificación de los resultados


Se tomó al menos 2 docenas de resultados aleatorios y fue comparado con diferentes looking glass en Internet, principalmente el looking glass de Hurricane Electric [3]

Periodo estudiado
  Del 16 al 18 de Enero 2020


Población y muestra
  9781 prefijos IPv6 asignados al 16 de Enero 2020 por LACNIC
  2 prefijos fueron removidos indica como país US
  9749 prefijos procesados satisfactoriamente


Resultados (solo mostrando países donde se obtuvieron y procesaron al menos 5 prefijos):
  
Leyenda:
AC=Anuncio completo (prefijo asignado = prefijo visto en la DFZ (Default Free Zone o Tabla de enrutamiento Global))
AP=Anuncio parcial (prefijo asignado no se observa en la DFZ sin embargo al menos una subred más chica sí)
NA=No anunciada (prefijo asignado ni prefijos más chicos de la misma se observan en la DFZ )
Total=Total de prefijos IPv6 del país
%AC = Porcentaje de AC respecto al Total
%AP = Porcentaje de AP respecto al Total
%NA = Porcentaje de NA respecto al Total


PAIS
AC
AP
NA
TOTAL
%AC
%AP
%NA
AR
162
28
742
932
17.38
3
79.61
BO
7
2
30
39
17.95
5.13
76.92
BR
3309
300
3395
7004
47.24
4.28
48.47
BZ
7
2
18
27
25.93
7.41
66.67
CL
39
11
203
253
15.42
4.35
80.24
CO
110
29
162
301
36.54
9.63
53.82
CR
40
10
51
101
39.6
9.9
50.5
CU
2
0
3
5
40
0
60
CW
7
0
8
15
46.67
0
53.33
DO
27
3
24
54
50
5.56
44.44
EC
36
19
98
153
23.53
12.42
64.05
GF
1
0
4
5
20
0
80
GT
18
4
21
43
41.86
9.3
48.84
HN
23
1
78
102
22.55
0.98
76.47
HT
3
0
6
9
33.33
0
66.67
MX
47
31
190
268
17.54
11.57
70.9
NI
9
1
12
22
40.91
4.55
54.55
PA
18
6
45
69
26.09
8.7
65.22
PE
17
7
65
89
19.1
7.87
73.03
PY
33
4
33
70
47.14
5.71
47.14
SV
10
2
26
38
26.32
5.26
68.42
SX
3
0
3
6
50
0
50
TT
3
1
7
11
27.27
9.09
63.64
UY
10
2
16
28
35.71
7.14
57.14
VE
32
3
59
94
34.04
3.19
62.77


Tabla 1


Resumen de resultados

- Los países con mayor anuncios de prefijos completos (AC) son Saint Maarten y República Dominicana (con 50%) seguidos por Brasil (47.24%).

- El país con mayor porcentaje de anuncios parciales es Ecuador (12.42%). Es interesante destacar en este renglón no esperamos obtener un número muy grande debido a la naturaleza de este valor sin embargo puede resultar de interés conocer el motivo del mismo.

- Podemos observar que el país con mayor porcentaje de prefijos IPv6 no anunciados es CL (80.24%) seguido por Guyana Francesa (80%) y Argentina (79.61%)

-Por último, Intentando una perspectiva diferente, podemos averiguar cual es el país con mayor % de anuncios de prefijos utilizando la columna %NA, es decir, el menor número en este caso es país con mayor % de anuncios, obtenemos República Dominicana que indica 44.44% lo que quiere decir que tienen un 55.56% de sus prefijos visibles en la DFZ (¡ felicitaciones !)


Conclusión


La cantidad de anuncios de prefijos IPv6 para toda la región no alcanza ni el 50% de número de asignaciones. Hay mucho por hacer; conociendo los países donde el gap es mayor puede significar destinos a donde hay que dedicar mayor tiempo. Tenemos que seguir trabajando en disminuir la diferencia entre asignaciones y publicaciones.

Refencias:
[1] http://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest

Manos a la obra - Nuevo espacio de Documentación IPv6: Un Enfoque Práctico (3FFF::/20)

Introducción El 23 Julio de 2024 la IANA asignó el bloque de direcciones 3FFF::/20 como un nuevo espacio de direccionamiento para documentac...