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

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...