HowTo: Como levantar un peering en IPv6 Only v1.0

Introducción

  El siguiente artículo presenta de manera ordenada los pasos a seguir para levantar un peering BGP entre dos routers IPv6 Only.

  En el argot de BGP peering se conoce como ( traducido de [1]):

“Dos enrutadores que han establecido una conexión para intercambiar información BGP se denominan pares BGP. Dichos pares BGP intercambia información de enrutamiento entre ellos a través de sesiones BGP ….. “

Prerrequisitos

• Dos enrutadores

• Conectividad entre los enrutadores

• Soporte IPv6 en ambos equipos tanto en conectividad como en BGP

Topología

Para Enrutador R1:

• IPv6 de R1: 2001:db8:12::1/64  

• Router-ID de R1: 10.111.111.1

• Prefijo v6 que será anunciado por R1: 2001:db8:1::/48

• IPv6 /128 de Loopback:  2001:db8:1:11::cafe/128

Para Enrutador R2:

• IPv6 R2: 2001:db8:12::2/64

• Router-ID de R2: 10.222.222.2

• Prefijo v6 que será anunciado por R2: 2001:db8:2::/48

• IPv6 /128 de Loopback:  2001:db8:2:11::cafe/128

Pasos a seguir

Paso 1 - Conectividad IPv6 entre los enrutadores

Para establecer y probar la conectividad entre los enrutadores debemos:

1. Establecer la conexión física:

• Asegurarse que esté realizada la conexión física entre las interfaces asignadas de ambos enrutadores.

• Verificar que dicho enlace esté UP.

2. Configurar IPv6 en las interfaces relacionadas:

• Asignar el direccionamiento IPv6 de WAN que se utilizará en el enlace. Todo el direccionamiento utilizado en este documento pertenece al segmento 2001:db8::/32 reservado para documentación.

• Configurar IPv6 en las interfaces relacionadas.

3. Probar conectividad IPv6:

• Realizar un Ping IPv6 desde alguno de los dos equipos.

• Si no se puede alcanzar es imprescindible arreglar esta situación antes de continuar.

• Es posible que el destino esté filtrando los paquetes de Ping IPv6 (ICMPv6 Echo Request/Reply y eso no implica que no vaya a funcionar BGP; verificar en el otro equipo.

Nota: BGP por defecto piensa que su vecino se encuentra directamente conectado, es decir, el vecino es el siguiente dispositivo en la red. En caso de no ser así se puede requerir mayor configuración tal como eBGP Multihop [2], pero este tema no lo cubriremos en este howto.

Cisco (IOS-15.4)

R1

Estado de Interfaz:

R1#sh int et0/0

Ethernet0/0 is up, line protocol is up 

  Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)

Configuración de Interfaz:

interface Ethernet0/0

 description ## R1 to R2 ##

 no ip address

 ipv6 address 2001:DB8:12::1/64

 ipv6 nd ra suppress #recomendado, no envía mensajes de RA

R2

Estado de Interfaz:

R2#sh int et0/0    

Ethernet0/0 is up, line protocol is up 

  Hardware is AmdP2, address is aabb.cc00.0200 (bia aabb.cc00.0200)

Configuración de Interfaz:

interface Ethernet0/0

 description ## R2 to R1 ##

 no ip address

 ipv6 address 2001:DB8:12::2/64

 ipv6 nd ra suppress

Prueba de conectividad:

R2#ping ipv6 2001:DB8:12::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:12::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/6 ms

R2#

R2#sh ipv6 neighbors 

IPv6 Address                              Age Link-layer Addr State Interface

2001:DB8:12::1                              0 aabb.cc00.0100  REACH Et0/0

FE80::A8BB:CCFF:FE00:100                   12 aabb.cc00.0100  STALE Et0/0

¿Crear la sesión BGP entre direcciones Link Local (LLA) o Global Unicast Addresses (GUA)?

En algunas ocasiones tendremos que tomar la decisión de cómo crear la sesión BGP, existen 3 posibilidades: 

• Utilizar direcciones Link Local (LLA), 

• Utilizar direcciones globales (GUA),

• Utilizar direcciones ULA (Unique Local Address). 

Las primeras dos opciones son las más comúnmente utilizadas. 

Entonces, ¿qué utilizo para crear la sesión BGP?. 

Te daremos una respuesta directa, sin embargo queremos realizar la explicación como es debido. 

Repasa estas premisas:

1. Recordemos que los mensajes BGP contienen atributos, siendo uno de ellos el atributo NextHop [3]. Este atributo contiene una información muy sencilla: el salto que se debe utilizar para alcanzar un destino. 

2. Un router (un eBGP Speaker) al aprender un prefijo de otro AS copia el atributo de nexthop hacia su red iBGP.

3. Una red de speakers iBGP tradicionalmente tendrá un IGP.

4. Las direcciones Link Local tienen alcance local, tan solo el propio bus de la red, la LAN, el SSID, etc. No pueden ser enrutadas.

Quizás ya en este momento te has respondido que utilizar :-)  

Nuestra recomendación es crear la sesión BGP sobre GUA y ahora que repasamos las premisas es fácil responder con una pregunta:  ¿Cómo un eBGP speaker va a copiar una dirección Link Local en el nexthop hacia sus iBGP speakers?.   Sencillo, no puede (claro, existen algunos trucos pero no lleguemos hasta ello).

Paso 2 - Definir el Router-ID en los diferentes routers

Debido a que estamos hablando de equipos IPv6 Only, asumimos que los dispositivos no tendrán direccionamiento IPv4. ¿Qué tiene que ver?

Explicamos brevemente:

• ¿Para qué un router-id?. El router-id es un campo de 32 bits que viaja en el mensaje OPEN de BGP, dicho campo (llamado BGP Identifier) es obligatorio y se representa en un formato de dirección IPv4.

• Los enrutadores tienen un mecanismo para obtener su router-id. 

• Si el router es IPv6 Only el equipo no podrá averiguar su router-id

• Si el router no puede averiguar su router-id el administrador debe configurar uno explícitamente dentro del proceso BGP. 

Paso 3 - Realizar las configuraciones en los routers

Vamos a mostrar dos ejemplos: Mikrotik y Cisco.Podremos darnos cuenta que la información es exactamente la misma, lo que cambia es la manera y comandos del sistema operativo. En el caso de Mikrotik utilizaremos la versión 6.x. 

Configuración en routers

Mikrotik (RouterOS v6)

Enrutador R1

Configuración de la interfaz loopback

/interface bridge add name=loopback protocol-mode=none disabled=no

/ipv6 address add address=2001:db8:1:11::cafe/128 advertise=no interface=loopback

Configuración del proceso/instancia BGP

/routing bgp instance add name=AS65001 as=65001 router-id=10.111.111.1

Configuración del Peer

/routing bgp peer add name=HACIAR2 instance=AS65001 remote-address=2001:db8:12:2 remote-as=65002 address-families=ipv6

Anuncio de prefijo

routing bgp network add network=2001:db8:1::/48 synchronize=no

Enrutador R2

Configuración de la interfaz  loopback

/interface bridge add name=loopback protocol-mode=none disabled=no

/ipv6 address add address=2001:db8:2:11::cafe/128 advertise=no interface=loopback

Configuración del proceso/instancia BGP

/routing bgp instance add name=AS65002 as=65002 router-id=10.222.222.2

Configuración del Peer

/routing bgp peer add name=HACIAR1 instance=AS65002 remote-address=2001:db8:12:1 remote-as=65001 address-families=ipv6

Anuncio de prefijo

routing bgp network add network=2001:db8:2::/48 synchronize=no

Revisar la sesión BGP/Troubleshooting

Desde R2

Es importante que la letra “E” aparece en la salida, la misma indica que la sesión BGP se encuentra establecida correctamente

Cisco (IOS-15.4)

Habilitar IPv6

Antes de comenzar con la configuración de BGP, en algunas versiones de IOS, es necesario primero habilitar:

• ipv6 unicast-routing: Habilita el enrutamiento de paquetes IPv6.

• ipv6 cef: Habilita Cisco Express Forwarding para paquetes IPv6 de esta manera el procesamiento de dichos paquetes se realiza en Hardware, sino se realizaría en Software impactando directamente en la CPU del equipo.

R1#configure terminal #entramos en modo configuración

R1(config)#

R1(config)#ipv6 unicast-routing 

R1(config)#ipv6 cef

R1

Entramos en Modo Configuración:

R1#configure terminal

R1(config)#

Configuramos la interface Loopback0:

R1(config)#interface loopback 0 #configuración de la interfaz loopback

R1(config-if)#ipv6 address 2001:db8:1::1/128 #dirección ipv6 de la interfaz loopback

R1(config-if)#exit

R1(config)#

Configuramos BGP:

R1(config)# router bgp 65001 #creamos el proceso de BGP con el ASN

R1(config-router)# bgp router-id 10.111.111.1 #definimos el router-id

R1(config-router)# no bgp default ipv4-unicast #desactivar la configuración default de un neighbor en el AF IPv4

R1(config-router)#neighbor 2001:DB8:12::2 remote-as 65002 #definimos el neighbor

R1(config-router)# address-family ipv6 #entramos en el AF de IPv6

R1(config-router-af)#  neighbor 2001:DB8:12::2 activate #activamos el neighbor en este AF

R1(config-router-af)#  network 2001:DB8:1::/48 #prefijo a ser anunciado

R1(config-router-af)#exit

R1(config-router)#exit

R1(config)#ipv6 route 2001:db8:1::/48 Null0 #Cisco necesita que el prefijo a ser anunciado se encuentre en la tabla de enrutamiento

R1(config)#exit

R1#

R2

Entramos en Modo Configuración:

R2#configure terminal

R2(config)#

Configuramos la interfaz Loopback0:

R2(config)#interface loopback 0

R2(config-if)#ipv6 address 2001:db8:2::1/128

R2(config-if)#exit

R2(config)#

Configuramos BGP:

R2(config)#router bgp 65002

R2(config-router)# bgp router-id 10.222.222.2

R2(config-router)# no bgp default ipv4-unicast

R2(config-router)# neighbor 2001:DB8:12::1 remote-as 65001

R2(config-router)# address-family ipv6

R2(config-router-af)#  neighbor 2001:DB8:12::1 activate

R2(config-router-af)#  network 2001:DB8:2::/48

R2(config-router-af)#exit-address-family 

R2(config-router)#exit 

R2(config)#ipv6 route 2001:db8:2::/48 Null0 #Cisco necesita que el prefijo a ser anunciado se encuentre en la tabla de enrutamiento

R2(config)#exit

R2#

Revisar la sesión BGP/Troubleshooting

show bgp ipv6 unicast summary

Con este comando podemos revisar los peers existentes. Un indicador de que la sesión BGP se encuentra levantada es revisar la columna “State/PfxRcd” y revisar que contenga un número. Dicho número indica la cantidad de prefijos recibidos. En nuestro caso esperamos recibir 1 prefijo (la IPv6 de la interfaz loopback del neighbor):

R1#show bgp ipv6 unicast summary                 

BGP router identifier 10.111.111.1, local AS number 65001

BGP table version is 3, main routing table version 3

2 network entries using 328 bytes of memory

2 path entries using 208 bytes of memory

2/2 BGP path/bestpath attribute entries using 288 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 848 total bytes of memory

BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

2001:DB8:12::2  4        65002      14      13        3    0    0 00:08:39        1

R1#

show bgp ipv6 unicast

Con este comando se puede observar la tabla BGP IPv6 del equipo e identificar detalladamente los prefijos aprendidos.

R1#show bgp ipv6 unicast 

BGP table version is 3, local router ID is 10.111.111.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  ::                       0         32768 i #prefijo IPv648 local

 *>  2001:DB8:1::/48  2001:DB8:12::2           0         0 65002 i #prefijo IPv6 remoto

R1#

Verificar conectividad end-to-end

Luego de que estamos seguros de que ambos routers aprenden correctamente el prefijo del vecino podemos verificar la conectividad IPv6 entre las IPs de las Interfaces Loopback en ambos extremos:

Ping desde R1:

R1#ping ipv6 2001:db8:2::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:2::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/5 ms

R1#

Chequeo de Conectividad PING6 de R1 a R2, a nivel de las IPv6 de Loopback

Un aspecto interesante de Mikrotik es que para hacer PING (IPv4) y PING6 (IPv6) se utiliza el mismo comando y Mikrotik identifica la IP destino y procede a realizar el PING ó PING6 de acuerdo al protocolo correspondiente. En otros routers, esto no ocurre y hay que explicitar que el PING es IPv6 usando comandos distintos como ‘ping6’ (Cisco Nexus) ó ‘ping ipv6’. 

[admin@R1] > /ping 2001:db8:2:11::cafe src-address=2001:db8:1:11::cafe count=4

  SEQ HOST                                     SIZE TTL TIME  STATUS                                             

    0 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    1 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    2 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    3 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    sent=4 received=4 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 

Ejemplo Filtros Básicos en BGP

En esta sección mostraremos un ejemplo básico de como realizar filtros salientes y entrantes en BGP.

Se configuran los siguientes filtros para que solo se propaguen los direccionamientos de las Interfaces Loopback0 de ambos routers:

• Filtro saliente en R1 permitiendo anunciar solo su Loopback0 a R2.

• Filtro entrante en R2 permitiendo recibir solo la Loopback0 de R1.

• Filtro saliente en R2 permitiendo anunciar solo su Loopback0 a R1.

• Filtro entrante en R1 permitiendo recibir solo la Loopback0 de R2.

Conceptos previos a la configuración:

• Prefix-List:

• Las Listas de Prefijos se utilizan para definir los prefijos a utilizar en el filtro.

• En nuestro caso utilizaremos:

• PREFIXES-AS6500X: Para identificar los prefijos del ASN.

• ALL-v6: Todos los prefijos IPv6. Para poner al final y filtrar todo el resto.

• Route-map:

• Es una secuencia ordenada de sentencias de permiso o rechazo.

• En este caso se utiliza para permitir o rechazar el anuncio de prefijos en BGP.

Filtrado Básico BGP Mikrotik

Ejemplo en Mikrotik

En mikrotik existen varias formas de programar los filtros a ser utilizados en las sesiones eBGP. Existen desde aquellas muy sencillas y básicas, pasando por las de detalles y complejidad intermedia hasta las más avanzadas que incluyen filtrado basado en manejo y configuración de atributos avanzados como MED, NEXT_HOP, AS_PATH, LOCAL_PREF, entre otros tantos. En este caso, a objeto de ilustrar de primera mano el concepto, haremos uso de una configuración básica y sencilla del filtrado BGP, y haremos uso solamente de los parámetros PREFIX y PREFIX_LEN para la definición de los filtros.

Al igual que en toda configuración de filtrado de sesiones BGP, debemos configurar un filtro BGP de entrada (IN) y un filtro BGP de salida (OUT) en cada par BGP. Esto es, para R1 debemos configurar un filtro para IN y otro para OUT, y para R2 debemos definir un filtro para IN y otro para OUT. Dicho esto, definiremos los siguientes parámetros de configuración para cada router de la sesión eBGP:

Router R1:

• ·         Nombre del Filtro IN:                 ebgp-r2-ipv6-IN

• ·         Nombre del Filtro OUT:            ebgp-r2-ipv6-OUT

• ·         Prefijo IPv6 a Anunciar:            2001:db8:1::/48

Router R2:

• ·         Nombre del Filtro IN:                 ebgp-r1-ipv6-IN

• ·         Nombre del Filtro OUT:            ebgp-r1-ipv6-OUT

• ·         Prefijo IPv6 a Anunciar:            2001:db8:2::/48

La configuración de los filtros en Mikrotik se realiza en la sección de configuración ‘/routing filter’. Las configuraciones, para Mikrotik RouterOS v6, serían las siguientes:

Para Router R1:

[admin@RouterOS-v6-R1] > /routing filter

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-IN

prefix=2001:db8:2::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R1] /routing filter > add chain= ebgp-r2-ipv6-IN

prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R1] /routing filter > print where

Chain=ebgp-r2-ipv6-IN

Flags: X - disabled

 0   chain=ebgp-r2-ipv6-IN prefix=2001:db8:2::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r2-ipv6-IN prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

 [admin@RouterOS-v6-R1] > /routing filter

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-OUT prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R1] /routing filter > print where chain=ebgp-r2-ipv6-OUT

Flags: X - disabled

 0   chain=ebgp-r2-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r2-ipv6-OUT prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

Para Router R2:

[admin@RouterOS-v6-R2] > /routing filter

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-IN

prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R2] /routing filter > add chain= ebgp-r1-ipv6-IN

prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R2] /routing filter > print where Chain=ebgp-r1-ipv6-IN

Flags: X - disabled

 0   chain=ebgp-r1-ipv6-IN prefix=2001:db8:1::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r1-ipv6-IN prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

 [admin@RouterOS-v6-R2] > /routing filter

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-OUT prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R2] /routing filter > print where chain=ebgp-r1-ipv6-OUT

Flags: X - disabled

 0   chain=ebgp-r1-ipv6-OUT prefix=2001:db8:2::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r1-ipv6-OUT prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

Luego de crear los filtros de IN y OUT, tanto para R1 como para R2, debemos entonces asignar esos filtros a las sesiones eBGP correspondientes. A continuación los comandos para esta configuración:

Para Router R1:

[admin@RouterOS-v6-R1] > /routing bgp peer

[admin@RouterOS-v6-R1] /routing bgp peer> set [find name=HACIAR2]

in-filter=ebgp-r2-ipv6-IN

[admin@RouterOS-v6-R1] /routing bgp peer> set [find name=HACIAR2] 

out-filter=ebgp-r2-ipv6-OUT

[admin@RouterOS-v6-R1] /routing bgp peer> print detail

Para Router R2:

[admin@RouterOS-v6-R2] > /routing bgp peer

[admin@RouterOS-v6-R2] /routing bgp peer> set [find name=HACIAR1]

in-filter=ebgp-r1-ipv6-IN

[admin@RouterOS-v6-R2] /routing bgp peer> set [find name=HACIAR1] 

out-filter=ebgp-r1-ipv6-OUT

[admin@RouterOS-v6-R2] /routing bgp peer> print detail

Importante: Un detalle de configuración importante es lo relativo a la configuración del prefijo IPv6 a anunciar. La forma más comúnmente utilizada es configurar dicho  prefijo IPv6 en la sección ‘/routing bgp network’ con el atributo ‘synchronize=no’. De esta forma, Mikrotik (versión 6) anunciará el prefijo IPv6 de manera ‘incondicional’ (ojo: pasado por los correspondientes filtros de OUT) . Como forma alternativa, podemos colocar el prefijo IPv6 en los BGP networks de Mikrotik y colocando el atributo ‘synchronize=yes’, pero en este caso el prefijo será anunciado si y sólo si se encuentra activo en la tabla de rutas IPv6 de Mikrotik. Por último, también se pueden hacer uso de técnicas de ‘redistribute’ para anunciar prefijos IPv6. También, es importante comentar que podemos anunciar vía eBGP cualquier prefijo con longitud entre /32 y /48 (ambos inclusive), tomado de nuestro prefijo base asignado por LACNIC.

Ejemplo en Cisco

R1:

ipv6 prefix-list ALL-v6 seq 5 permit ::/0 le 128

!

ipv6 prefix-list PREFIXES-AS65001 seq 5 permit 2001:DB8:1::/48

!

ipv6 prefix-list PREFIXES-AS65002 seq 5 permit 2001:DB8:2::/48

!

route-map RM-R1-R2-IN permit 10 #permite recibir los prefijos del AS65002

 match ipv6 address prefix-list PREFIXES-AS65002

!

route-map RM-R1-R2-IN deny 20 #no permite recibir ningún otro prefijo

 match ipv6 address prefix-list ALL-v6

!

route-map RM-R1-R2-OUT permit 10 #permite anunciar los prefijos del AS65001

 match ipv6 address prefix-list PREFIXES-AS65001

!

route-map RM-R1-R2-OUT deny 20 #no permite anunciar ningún otro prefijo

 match ipv6 address prefix-list ALL-v6

!

router bgp 65001

 address-family ipv6

  neighbor 2001:DB8:12::2 route-map RM-R1-R2-IN in #asocia el route-map al neighbor

  neighbor 2001:DB8:12::2 route-map RM-R1-R2-OUT out #asocia el route-map al neighbor

 exit-address-family

!

R2:

ipv6 prefix-list ALL-v6 seq 5 permit ::/0 le 128

!

ipv6 prefix-list PREFIXES-AS65001 seq 5 permit 2001:DB8:1::/48

!

ipv6 prefix-list PREFIXES-AS65002 seq 5 permit 2001:DB8:2::/48

!

route-map RM-R2-R1-IN permit 10

 match ipv6 address prefix-list PREFIXES-AS65001

!

route-map RM-R2-R1-IN deny 20

!

route-map RM-R2-R1-OUT permit 10

 match ipv6 address prefix-list PREFIXES-AS65002

!

route-map RM-R2-R1-OUT deny 20

 match ipv6 address prefix-list ALL-v6

!

router bgp 65002

 address-family ipv6

  neighbor 2001:DB8:12::1 route-map RM-R2-R1-IN in

  neighbor 2001:DB8:12::1 route-map RM-R2-R1-OUT out

 exit-address-family

!

Verificación

R1:

R1#show bgp ipv6 unicast 

BGP table version is 9, local router ID is 10.111.111.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  ::                       0         32768 i

 *>  2001:DB8:2::/48  2001:DB8:12::2           0             0 65002 i

R1#

R2:

R2#show bgp ipv6 unicast 

BGP table version is 9, local router ID is 10.222.222.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  2001:DB8:12::1           0             0 65001 i

 *>  2001:DB8:2::/48  ::                       0         32768 i

R2#

Errores comunes

  A pesar de que pueden existir muchos errores en el mundo de sesiones BGP quisimos enumerar dos casos muy típicos: 

1. La sesión BGP no levanta

Pueden existir muchas razones por la cual una sesión BGP no levante entre dos peers. Las más probables son:

1. No hay conectividad IP entre ellos

2. Existe discrepancia de información entre los peers (por ejemplo, dirección IP, sistema autónomo incorrectos)

2. Mi prefijo no se encuentra anunciado

Nuevamente pueden haber muchas razones por la cual no se encuentra anunciado un prefijo, las tres más comunes son:

1. Existe algún filtro implementado saliente en la sesión BGP que prohíbe el anuncio del prefijo

2. El prefijo que deseas anunciar no se encuentra en la tabla de enrutamiento

3. Modernas implementaciones de BGP exigen implementaciones de políticas en la sesión BGP antes de realizar los anuncios de los prefijos

Conclusiones

  Levantar una sesión BGP (léase crear un peering BGP) es algo muy sencillo, tan solo hay que conocer los parámetros adecuados y saber colocarlos en la configuración según el dispositivo.

  La parte complicada de BGP entra al momento de tener varios peers, necesitar filtros de entrada y/o salida en las sesiones BGP, y sobre todo cuando un sistema autónomo hace tránsito de tráfico y prefijos de otros ASs.  La recomendación general es estudiar mucho y ser excesivamente cauteloso al momento de realizar cualquier configuración.

TODO

  Siempre es importante estar muy pendiente de la seguridad, anuncios, filtros y operación de BGP. Se sugiere revisar el siguiente BCP BGP (Operations and Security):

  https://datatracker.ietf.org/doc/html/rfc7454

  A su vez en LACNIC tenemos gran cantidad de videos sobre BGP:

https://www.youtube.com/c/lacnicstaff/search?query=bgp

  Y tenemos un curso en nuestro CAMPUS donde cubrimos bastante esta temática:

https://campus.lacnic.net/mod/page/view.php?id=10647

  Seleccionar el Router-ID de cada router “sabiamente”

Referencias

https://blog.cdemi.io/beginners-guide-to-understanding-bgp/

https://datatracker.ietf.org/doc/html/rfc7454

[2] https://networklessons.com/bgp/ebgp-multihop

[3] https://www.networkurge.com/2017/06/bgp-next-hop-attribute-and-rules.html

Autores:

Por: Jose G. Cotua (@SimeonSpa) / Alejandro D’Egidio (@Ale_Degidio) / Alejandro Acosta (@ITandNetworking)

서민통합지원센터
Elder Law Attorney - Elder Law Lawyer Evergreen Elder Law Our goal is to help you put a flexible, thoughtful plan in place that protects as much of your estate as possible. We know you’ve worked hard to build up your estate and understand how hard it is to just let it go to pay for long-term care.

Entrevista con Cisco - Entrevista con los expertos – “Alejandro Acosta”

 

Despliegue de DNSSEC en la región - Estadística y mediciones

 dnssec mediciones

Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / Alejandro Acosta (@ITandNetworking)

Introducción

En el presente post queremos conversar sobre unas recientes investigaciones que hemos realizados 

sobre un tema que nos apasiona mucho: DNSSEC. Por favor notar que hablamos en plural: 

“investigaciones”, debido a que son dos estudios sobre DNSSEC que comenzamos a la vez… 

¡favor continua leyendo para que entiendas de que se tratan ambas dos!

Sobre DNSSEC

DNSSEC añade un plus de seguridad al protocolo DNS que permite comprobar la integridad

 y autenticidad de los datos, previniendo ataques de suplantación y falsificación, mediante

 el uso de criptografía asimétrica o mejor conocida como clave pública / privada. 

Mediante el uso de estas claves y las firmas generadas a partir de ellas, se puede saber 

si una consulta fue modificada, permitiendo garantizar la integridad y autenticidad del 

mensaje. Si al comprobar estas firmas no coinciden entre ellas, quiere decir que la cadena 

de confianza se ha roto y la consulta no puede ser validada como legítima.

Contar con DNSSEC depende del ISP o del proveedor de servicios de internet que tenga 

contratado, que es quien debe configurarlo. Para saber si cuenta con DNSSEC existen varias 

herramientas en Internet que lo permiten como:

https://dnssec-analyzer.verisignlabs.com/

https://dnsviz.net/

Como muchos saben DNSSEC es un protocolo que ha venido creciendo mucho en los 

últimos años. Dos aspectos han marcado su aumento del despliegue:

1) DNSSEC viene habilitado por defectos en algunos servidores recursivos (BIND) y

2) Grandes avances en facilitar habilitar DNSSEC en los diferentes dominios por los 

registradores más importantes.

3) Todos los grandes recursivos públicos hacen validación DNSSEC (google public dns, 

cloudflare, quad9, etc)

4) Apple acaba de mencionar que iOS16 y macOS Ventura permitirán hacer validación 

DNSSEC en el stub final.

DNSSEC ha sido un tema muy importante para LACNIC, hemos realizado gran cantidad 

de eventos y actividades en torno a este tema, sin embargo hasta la fecha no teníamos 

ningún estudio propio al respecto.

¿De qué trata el estudio?

Desde el área I+D de LACNIC quisimos realizar un estudio con el fin de conocer el estado 

y el avance respecto al despliegue de DNSSEC en la región.

Origen de la Data

Tenemos dos fuentes de datos muy confiables

• Utilizamos los probes ATLAS de RIPE https://atlas.ripe.net/

• Realizamos capturas (tcpdump) que posteriormente fueron anonimizadas en 

• servidores autoritativos

Fechas:

La obtención de la data comenzó en Noviembre de 2021, actualmente se lleva a cabo de 

una manera automatizada con reportes semanales y mensuales [1]

¿Cómo se identifica que un servidor realice DNSSEC?

Hay que verlo desde dos aspectos:

Sondas Atlas:

Se envían solicitudes de resolución DNS a todas las sondas disponibles en latinoamérica y el caribe, por un nombre de dominio que intencionalmente tiene sus firmas incorrectas y por lo tanto no valida según DNSSEC. Si la respuesta es error (SERVFAIL), quiere decir que el resolver que utiliza esa sonda sí utiliza correctamente DNSSEC. Si por el contrario se obtiene respuesta (NOERROR), quiere decir que dicho resolver no realiza ninguna validación. Nótese que interesantemente la idea es que la respuesta del servidor DNS sea negativa, *esto es la clave* para saber si el recursivo valida DNSSEC o no. 
Te dejamos este ejemplo: si visitas dnssec-failed.org y puedes abrir la página significa que tu DNS recursivo no hace DNSSEC, si no la puedes abrir es bueno! :-). 

Captura (tcpdump):

Antes de indicar que hacemos con la captura vamos a expandir un poco el concepto de DNSSEC. Así como existen los registros tradicionales en DNS (A, AAAA, MX, etc) para la utilización de DNSSEC se agregaron nuevos registros, estos mismos son DS, RRSIG, NSEC, NSEC3 y DNSKEY. Es decir, un servidor DNS recursivo puede consultar el registro AAAA para conocer la dirección IPv6 de un registro y puede consultar el registro DS (Delegation Signer) para verificar la autenticidad de las zonas hijas. La parte clave de este estudio es que los servidores que no hacen validaciones DNSSEC no consultan registros DNSSEC!. 

En base a lo anterior, al momento de realizar la captura se le pide a tcpdump que tome todo el paquete (flag -s 0),  de esa manera tenemos todo el contenido del mismo, desde capa 3 hasta capa 7, durante el procesamiento del paquete buscamos por los registros específicos de DNSSEC (nuevamente: DS, RRSIG, NSEC, NSEC3 y DNSKEY), si conseguimos alguno de ellos entonces el recursivo si hace DNSSEC, en caso contrario no hace. 

¿Donde se realiza la captura mencionada?

La captura se hace especificamente en una de las instancias del servidor DNS 

Reverso D (D.IP6-SERVERS.ARPA). El comando utilizado es: /usr/sbin/tcpdump 

-i $INTERFAZ -c $CANTIDAD -w findingdnssecresolvers-$TODAY.pcap -s 0 dst port 

$PORT and ( dst host $IP1 or dst host $IP2 )

Procesamiento de la información

Primero, el procesamiento de los datos consta de varias partes, todas realizadas 

completamente con software Open Source, específicamente con Bash, Perl y Python3 

sobre Linux.

Segundo, recordemos que existen dos fuentes de información: Captura de tráfico (PCAPs) 

y Probe Atlas. Aquí la metodología seguida en cada caso:
  a) Procesamiento de los PCAPs: Luego de obtener los PCAPs se realizan una serie de 

paso, entre ellos:

    1) El procesamiento de los .pcap se realiza en Python3 utilizando la librería pyshark.
    2) Limpieza de los datos improcesables (paquetes malformados, dañados, no-procesables, etc)
    3) Remoción de direcciones duplicadas
    4) Anonimización de datos
    5) Generación de resultados
    6) Generación de las gráficas y open data

  b) Procesamiento de la información obtenida en RIPE Atlas:
La captura de datos se realiza con mediciones mensuales en la plataforma RIPE Atlas, 

utilizando su API por línea de comandos. Luego se recogen y procesan en una serie de 

scripts utilizando lenguaje Perl, para finalmente graficar utilizando la API de Google Charts 

y adicionalmente dejamos los datos disponibles siempre en Open Data.
Favor recordemos que para detectar si una sonda está utilizando un resolver con validación, 

se utiliza un nombre de dominio que intencionalmente tiene sus firmas incorrectas. De 

esta forma, al intentar resolver ese nombre, una sonda que valide debe responder con error, 

porque el nombre no es válido según DNSSEC. Por el contrario, si se obtiene una respuesta 

positiva frente al nombre, quiere decir que el resolver no está validando, ya que ignoró la 

firma incorrecta.

Resultados obtenidos

Esta gráfica muestra la cantidad de servidores estudiados que utilizan DNSSEC y cuáles no 

lo usan. Las líneas azules determinan los servidores con DNSSEC activo, las rojas los que 

no lo tienen.

Grafico 1

Se puede apreciar que para el 2 de Junio 2022 existen más servidores recursivos sin realizar 

DNSSEC que los que lo hacen. Se analizaron entre 33.000 a 55.000 direcciones IP cada semana. 

En líneas generales, se mantiene un promedio aproximado de un 55% de servidores que no utilizan 

el protocolo y un 45% de muestras positivas.

Grafico #2

En el gráfico #2 podemos apreciar el histórico de consultas DNSSEC en IPv6. Un dato no menor 

que llama mucho la atención es que en varios periodos de muestreo, existen más cantidad de 

consultas DNSSEC sobre v6 que en v4. Indiscutiblemente la intención es que la línea roja 

disminuya y la azul aumente de forma gradual.

Ranking de países con mayor validación DNSSEC

Utilizando la plataforma de mediciones de RIPE Atlas, es posible medir en cada una de ellas su 

capacidad de validar DNSSEC o no. Cada medición se puede agrupar por país, creando un ranking:

Grafico #3

Ranking ordenado con el porcentaje de validación DNSSEC promedio desde redes de países 

en Latinoamérica y el Caribe correspondiente a mayo de 2022.

Los números dentro de las barras indican la cantidad de ASs participantes por cada país. Se 

descartan países donde medimos un solo ASs.

Resumen

Desde el estudio basado en captura de tráfico, con los datos obtenidos en un lapso de 8 

meses la gráfica sugiere una disminución lenta de número de servidores NO-DNSSEC; 

adicionalmente parece existir un mayor despliegue de DNSSEC en servidores IPv6 que en IPv4.

En el caso del análisis de sondas Atlas, es esperable un mayor despliegue de validación que 

con otras fuentes de datos más genéricas, considerando que las sondas generalmente son 

hospedadas en redes más avanzadas o por usuarios que podrían activar deliberadamente 

DNSSEC. Pero representa de alguna manera el “límite superior” de penetración, y también 

es un indicador importante de la evolución a través del tiempo.

OpenData

Como es habitual en LACNIC siempre deseamos dejar nuestra información disponible para su 

trabajo por quien así lo desee:

https://stats.labs.lacnic.net/DNSSEC/opendata/

https://mvuy27.labs.lacnic.net/datos/

Estos datos que estamos dejando disponibles también poseen el espíritu de “Time Series 

Data”. Es decir, estamos dejando los datos recolectados durante el tiempo lo que hará muy 

sencillo tener fluctuaciones de nuestras estadísitcas en el tiempo y saber si el despliegue de 

DNSSEC aumenta y/o disminuye por país, región, etc.

Como siempre cuando realizamos este tipo de proyectos, son bienvenidas sugerencias de 

mejora tanto en la implementación como en la visualización de la información obtenida.

Referencias:

[1] https://stats.labs.lacnic.net/DNSSEC/dnssecstats.html

https://mvuy27.labs.lacnic.net/datos/dnssec-ranking-latest.html

Solución "Unable to parse package file " luego de apt

 Problema:

    Obtenemos un error después de ejecutar cualquier comando apt en Linux

Solución:

    La solución es muy fácil, les comento que pasé muchas horas arreglándolo.

    Solo tiene que eliminar el archivo mencionado en el error, en mi caso obtuve: "E: Unable to parse package file /var/lib/apt/extended_states (1)"

    Acabo de borrar el archivo /var/lib/apt/extended_states

  Ejemplo:

    #sudo rm /var/lib/apt/extended_states

  Eso es todo, suerte!

Despliegue de IPv6 en la región LACNIC - Bar Chart Race IPv6 a Junio 2022

El video muestra la adopción de IPv6 en la región atendida por LACNIC desde Mayo 20214 a Junio 2022. Hecho con https://flourish.studio/

Video: Retirada Implícita y Explícita de prefijos en BGP / BGP Explicit/Implicit Withdraw

En el video se explica con detalle los conceptos de Retirada Implícita y Retirada Explicita de prefijos en BGP. Se realiza un Demo con 5 enrutadores utilizando un prefijo IPv6. Finaliza con capturas de wireshark de los mensajes UPDATE.

El Metaverso será posible gracias al IPv6

El Metaverso promete ser uno de los desarrollos tecnológicos que mayor impacto traerá en el futuro las formas de uso y consumo en Internet[1].

Aunque por ahora la promesa de Mark Zuckerberg sigue siendo un poco gaseosa y el uso práctico en la actualidad se reduce a la comunidad de los denominados “GAMERS”, el desarrollo, masificación y despliegue del denominado “Metaverso”  será posible gracias a la tecnología que soporta el protocolo IPv6[1].

¿Por qué el IPV6 es tan importante para el Desarrollo del Metaverso?

Por: Gabriel E. Levy B. y Alejandro Acosta
www.galevy.com – blog.acostasite.com

En su casi medio siglo de vida los protocolos TCP/IP han servido para conectar a miles de millones de personas.

Desde la creación de Internet, han sido los estándares universales sobre los cuales se transmite la información por la red, haciendo posible que Internet funcione[3].

La sigla IP puede referirse a dos conceptos vinculados entre ellos; El primero es un protocolo (Internet Protocol – Protocolo de Internet en Español) y su principal función es el uso bidireccional (origen y destino) de transmisión de datos basado en la norma OSI (Open System Interconnection)[4].

La segunda posible referencia cuando se habla de IP, está vinculada a una asignación numérica de direcciones físicas conocida como Dirección IP, un identificativo lógico y jerárquico asignado a una interfaz de un dispositivo dentro de una red que utilice el protocolo de Internet (Internet Protocol – IP), la cual corresponde al nivel de red o nivel 3 del modelo de referencia OSI.

IPv4 hace referencia al Protocolo de Internet en su cuarta versión (en inglés, Internet Protocol version 4, IPv4), un estándar de interconexión de redes basados en Internet, y que fue implementado en 1983 para el funcionamiento de ARPANET y la posterior migración a Internet[5].

El IPv4 usa direcciones de 32 bits, equivalentes a 4.2 mil millones de bloques de numeración únicas, una cifra que, para la década de los años 80 parecía sencillamente inagotable, no obstante, y por el crecimiento enorme e inesperado de Internet, para el año 2011 pasó lo que nunca se creyó que fuera a ocurrir, todas las direcciones se agotaron[6].

IPv6 como solución al Cuello de botella

Para solucionar la falta de direcciones disponibles, conocido como “RECURSOS”, los grupos de ingeniería responsables de Internet, han recurrido a múltiples soluciones que van desde la creación de subredes privadas, de tal forma que con una misma dirección se puedan conectar múltiples usuarios, hasta la creación de un nuevo protocolo denominado IPv6 que promete ser la solución definitiva del problema y el cual fue lanzado oficialmente el 6 de junio de 2012[7]:

“Previendo el agotamiento de la dirección disponibles en IPv4 y como una solución de largo plazo, el organismo que se encarga de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó una nueva versión del Protocolo de Internet, concretamente la versión 6 (IPv6), con una casi inagotable disponibilidad, a partir de una nueva longitud de 128 bits, es decir alrededor 340 sextillones de direcciones”[8].

Es importante aclarar que la creación del protocolo IPv6, no implica una migración, es decir un cambio de un protocolo a otro como si fuera un proceso de remplazo, sino que se diseñó un mecanismo que permite por un tiempo la coexistencia articulada de ambos protocolos.

Para garantizar una transición transparente para los usuarios y que garantice un tiempo prudencial para que los fabricantes incorporen la nueva tecnología y los proveedores de Internet la implementen en sus propias redes, la organización encargada de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó junto con el mismo protocolo IPV6, una serie de mecanismos que se denominan de transición y coexistencia.

“Es como una balanza, en la que hoy en día el lado con el mayor peso representa el tráfico IPv4, pero poco a poco, gracias a esta coexistencia, conforme más contenidos y servicios estén disponibles con IPv6, el peso de la báscula irá hacia el otro lado, hasta que IPv6 sea predominante. Esto es lo que llamamos la transición”[9].

El diseño del protocolo IPv6 da preferencia a IPv6 frente a IPv4, si ambos están disponibles (IPv4 e IPv6). De ahí que se produzca ese desplazamiento del peso en “nuestra balanza”, de una forma natural, en función de múltiples factores, y sin que podamos determinar durante cuánto tiempo seguirá existiendo IPv4 en la Red y en qué proporciones. Posiblemente podamos pensar, intentando mirar en la bola de cristal, que IPv6 llegará a ser predominante en 3-4 años, y en ese mismo entorno de tiempo, IPv4 desaparecerá de Internet, al menos en muchas partes de ella” [10].

 Sin IPv6 quizás no haya metaverso

Cómo lo analizamos en pasados artículos, los Metaversos o Metauniversos, son entornos donde los humanos interactúan social y económicamente como iconos, a través de un soporte lógico en un ciberespacio, como una metáfora amplificada del mundo real, pero sin las limitaciones físicas o económicas[11].

“Puedes pensar en el Metauniversos como una Internet encarnada.

En lugar de ver contenido, estás en él y te sientes presente con otras personas como si estuvieras en otros lugares teniendo diferentes experiencias que no podrías tener en una aplicación 2D o página web“. Mark Zuckerberg Ceo de Facebook[12].

El Metaverso necesariamente “corre” o se “Ejecuta” sobre Internet, que a su vez utiliza el IP o (Internet Protocol) para funcionar.

El Metaverso es un tipo de simulación que mediante “Avatares” permite a los usuarios tener conexiones mucho más inmersivas y realistas, desplegando un universo virtual que corre en línea, razón por la cual se hace necesario garantizar que el Metaverso sea Inmersivo, multisensorial, Interactivo, que corran en tiempo real, que permitan diferenciar de manera precisa a cada usuario, que despliegue herramientas gráficas simultáneas y complejas, entre muchos otros elementos, que simplemente sería imposible de garantizar sobre el Protocolo IPv4, puesto que ni existen suficientes “Recursos IP” para cada conexión, ni es posible garantizar que con tecnologías como el NAT pueda correr adecuadamente.

Los elementos claves:

• El IPV6 es el único protocolo puede garantizar la cantidad suficiente de “Recursos IP” para soportar el Metaverso.
• El IPV6 evita el mecanismo de NAT en las redes que complicaría tecnológicamente el despliegue del Metaverso.
• El RTT/Delay de los enlaces de IPv6 es mucho menor que el de IPv4, permitiendo que las representaciones gráficas de los “avatares”, incluyendo los hologramas puedan desplegarse de forma sincrónica.
• Teniendo en cuenta la alta cantidad de datos que implica el despliegue del Metaverso, es necesario garantizar la menor perdida de datos posible, razón por la cual el IPv6 se convierte en la mejor opción pues la evidencia muestra que la pérdida de datos es un 20% menor que la de IPv4[13].

El Rol de los Pequeños ISP

Teniendo en cuenta que los pequeños ISP son los grandes responsables de la conectividad de millones de personas en las regiones más apartadas de todo Latinoamérica y como lo hemos analizado anteriormente, son los grandes responsables de la disminución de la Brecha Digital[14], es muy importante que estos operadores aceleren el proceso de migración hacia IPV6, no solamente para ser más competitivos frente a sus grandes competidores, sino para que puedan garantizarle a sus usuarios que tecnologías como El Metaverso funcionarán en sus dispositivos sin mayores traumatismos tecnológicos.

En Conclusión, si bien aún es incierto el alcance real que tendrá El Metaverso, su despliegue, implementación y masificación será posible gracias al Protocolo IPv6, una tecnología que ha dado solución a la disponibilidad de los recursos IP, evitando el engorroso procedimiento de la traducción de NAT, mejorando los tiempos de respuesta, disminuyendo el RTT o Delay y evitando la perdida de muchos paquetes, al tiempo que facilitará la simultaneidad de usuarios.

Todo lo anterior nos permite afirmar que El Metaverso sin IPv6, no sería posible.

 

Descargo de Responsabilidades: Este artículo corresponde a una revisión y análisis en el contexto de la transformación digital en la sociedad de la información, y está debidamente soportado en fuentes académicas y/o periodísticas confiables y verificadas, las cuales han sido demarcadas y publicadas.

La información que contienen este artículo periodístico y de opinión, no necesariamente representa la postura de Andinalink, o las entidades con las que desarrolla sus relaciones comerciales.

^[1] Artículo Andinalink: Metaversos y el Internet del Futuro

^[2] Artículo Andinalink: Metaversos: Expactativas VS Realidad

[3] En el artículo: El agotamiento del protocolo IP explicamos las características del protocolo TCP: El Agotamiento del Protocolo IP

[4] Documento estándar de referencia sobre el Modelo de conectividad OSI

[5] En el artículo: ¿Fue creada Arpanet para soportar una guerra nuclear?, se detalla las características e historia de Arpanet.:

[6] Documento de Lacnic sobre las fases del agotamiento de IPV4

[7] Documento de IETF sobre el lanzamiento oficial de IPV6 en su sexto aniversario

[8] Guía de referencia de Transición de IPV6 de Mintic Colombia

[9]  Guía de referencia de Transición de IPV6 de Mintic Colombia

[10]  Guía de referencia de Transición de IPV6 de Mintic Colombia

^[11] Artículo Andinalink sobre los Metaversos

[12] MARK IN THE METAVERSE: Facebook’s CEO on why the social network is becoming ‘a metaverse company: The Verge Podcast

^[13] Análisis de Alejandro Acosta de LACNIC, sobre el impacto del IPV6 en sistemas táctiles.

^[14] Artículo Andinalink: Los Wisp disminuyen la brecha digital