Políticas de ruteo IPv6 en la RedCUDI

 

Resumen:

 

Este documento es una actualización del RFCMX3 que describe el direccionamiento IPv6 en CUDI, las políticas de Ruteo IPv6 que han servido de lineamientos a los miembros actuales y posteriores que se conecten a la red de Internet2 de México (RedCUDI), así como el tráfico que se permite transportar o no en esta red.

La implementación de estas políticas ayudará a prevenir el crecimiento incontrolable de las tablas de enrutamiento, detener los anuncios no autorizados y mantener actualizadas las políticas de ruteo de acuerdo a los cambios de las asignaciones de prefijos IPv6 a nivel global y regional.

 

Palabras claves: Políticas de Ruteo IPv6, Internet2 de México, RedCUDI, Direccionamiento IPv6, cambios de asignaciones.

 

Derechos de Copia

Copyright (C) CUDI-CDR-Grupo de IPv6 (2012). Todos los derechos Reservados

La distribución de este memo no está limitada.

 

Tabla de contenido:

 

  1. Introducción
  2. Obligaciones de los Asociados Académicos
  3. Obligaciones de los Afiliados Académicos
  4. Políticas de Ruteo IPv6 en RedCUDI
  5. Políticas de Ruteo IPv6 en RedCUDI que ya no aplican
  6. Datos autores

 

1. Introducción

 

La Corporación Universitaria para el Desarrollo de Internet (CUDI), mediante el grupo de trabajo IPv6, obtuvo de NIC-México su bloque propio de direcciones IPv6 para servicios de producción, que para propósitos de documentación, en este documento se mencionará como 2001:0DB8::/32.

 

De este bloque de direcciones se han asignado dos rangos:

 

  • Uno para el direccionamiento del Backbone.
  • Otro para asignaciones a los Asociados Académicos.

 

El detalle del direccionamiento del Backbone y de los Asociados se encuentra en los documentos “draft-cudi-ipv6-direccionamiento-2006-01” [1], de acceso público, y “Direccionamiento IPv6 para el Backbone de la red Internet2 de México (RedCUDI)” [2], de acceso restringido.

 

 

2. Obligaciones de los Asociados Académicos

 

Los Asociados Académicos tienen la obligación de implementar y operar su ruteo IPv6 de manera que la red CUDI y la del propio Asociado no vean afectados negativamente su desempeño. Particularmente en lo que se refiere a las redes anunciadas por los Asociados Académicos, y a las redes recibidas de enlaces internacionales.

 

3. Obligaciones de los Afiliados Académicos

 

Los Afiliados Académicos tienen la obligación de implementar y operar su ruteo IPv6 de manera que la red del Asociado y la de CUDI no vean afectados negativamente su desempeño. Particularmente en lo que se refiere a las redes anunciadas por los Afiliados Académicos, y a las redes recibidas de parte del Asociado correspondiente.

 

4. Políticas de Ruteo IPv6 en RedCUDI

 

            Las políticas de ruteo para IPv6 a implementar son referentes a: las redes que no deben ser anunciadas hacia la red, conocidas como “Improper routes” (ver definición) y al tamaño de las redes recibidas por parte de los Asociados Académicos y de los Afiliados, conocidas como “Import routing policy” (ver definición).

 

En base a lo anterior se establecen las siguientes Políticas de Ruteo IPv6 en RedCUDI:

 

  • Aceptación temporal de tráfico IPv6 con fines experimentales, proveniente de los miembros de CUDI, en un período de hasta 1 año siempre y cuando este tráfico no afecte a las demás aplicaciones y en general al tráfico académico existente, pudiéndose fijar límites y los filtros necesarios. Esta política estará sujeta a modificaciones cuando se considere pertinente.

 

  • Aceptación de los prefijos 6to4 (solo /16), siempre y cuando este tráfico no afecte a las demás aplicaciones y en general al tráfico académico existente, pudiéndose fijar límites y los filtros necesarios. Esta política estará sujeta a modificaciones cuando se considere pertinente.

 

  • En la RedCUDI solo se anunciará el bloque propio /32, y se realizará agregación y sumarización del mismo sin embargo, se aceptarán bloques /32 y /48 de los miembros de CUDI del tipo agregable global, definidos internacionalmente en la IANA [3], previo acuerdo de agregación y sumarización de su parte, para ser anunciados.

      De tal manera que se garantice el anuncio hacia las redes académicas        internacionales (Abilene, Cenic, CLARA, GÉANT y otras).

 

  • De acuerdo a la “Import routing policy” cualquier otro bloque /32 y /48 del tipo agregable global, será aceptado únicamente de otras redes avanzadas e instituciones de carácter académico, o de otras entidades con las cuales CUDI haya establecido algún convenio, previo acuerdo de agregación y sumarización de su parte.

 

  • Solo se aceptarán bloques /48 del tipo agregable global de los miembros de CUDI que hayan sido asignados por la misma corporación, y aquellos asignados a los propios miembros por parte de NIC-México al no poder recibir un bloque /32 [4].

 

De lo anterior se presenta la siguiente recomendación:

 

A las instituciones pertenecientes a CUDI se les recomienda adquirir su propio bloque de direcciones IPv6, a fin de evitar el anuncio de bloques de mayor tamaño (más específicos) y de garantizar la salida hacia las redes internacionales.

 

  • Cualquier otro bloque /48 será filtrado temporalmente y se solicitará a quien esté anunciándolo que deje de hacerlo.

      En caso de seguir recibiendo al bloque /48 se enviarán tres avisos a la otra parte, y se dará de baja la conexión en algunos casos, previo aviso; y en otros se       pondrá necesariamente un filtro permanente, en el equipo de Backbone correspondiente.

  • Los prefijos conocidos como “Improper routes” mostrados en la tabla 1.1, de acuerdo a [5] y a RFC 5156 [6], no se anunciarán para evitar la propagación de estas rutas.

 

Notación IPv6

Tipo de dirección

Referencia

::/128

No especificada

RFC 4291 [7]

::/96

Reservada por IETF*

 

::1/128

Loopback

RFC 4291 [7]

::ffff:0:0/96

Mapeadas-IPv4

RFC 4291 [7]

0100::/8

Discard-only prefix**

 

2001:0002::/48

BMWG

RFC 5180 [8]

2001:10::/28

ORCHID

RFC 4843[9]

2001:DB8::/32

Para documentación

RFC 3849[10]

FE80::/10

Unicast de enlace local

RFC 4291 [7]

FEC0::/10

Reservada por IETF***

RFC 3879 [11]

3FFE::/16

6Bone ****

 

Tabla 1.1.  Prefijos que deben ser filtrados o no ruteados.

 

 * Fue definida como un prefijo de dirección IPv6 IPv4-compatible, revocada por IETF.

** Recientemente definida en un Draft [12]

*** Fue definida como un prefijo de dirección de ámbito de sitio local, revocada por IETF y sustituida por  FC00::/7.

****Prefijo utilizado en la red mundial experimental 6Bone, ya no debe usarse en el Internet como lo establece el RFC 3701. [13]

 

 

 

Notación IPv6

Tipo de dirección

Referencia

2001:0000::/32

Teredo

RFC 4380 [14]

 

2002::/16

6to4

RFC 3056 [15]

 

FC00::/7

Local Única

RFC 4193 [16]

 

FF00::/8

Multicast

RFC 4291 [7]

Tabla 1.2.  Prefijos cuyo ruteo se define en el alcance (scope).

 

5. Políticas de Ruteo IPv6 en RedCUDI que ya no aplican

 

Se aceptaron (no filtrado) prefijos de 6BONE temporalmente hasta /32 de los miembros de CUDI por plazos hasta de 9 meses, que no pudieron extenderse más allá del 6 de junio de 2006 como lo establece el RFC 3701. [13] 

    • De Entrada:

Se aceptaron los prefijos de 6Bone de los miembros de CUDI mientras renumeraron sus redes, en plazos de 1 o 2 meses desde el momento de su conexión.

·         De salida:

Se anunciaron los prefijos de 6Bone de aquellas instituciones localizadas físicamente en México que hubieron manifestaron su compromiso de renumerar en el plazo establecido desde el momento de su conexión a CUDI.     

    • Esta política de no filtrado tuvo vigencia hasta el 6 de junio de 2006, y a partir de esta fecha se tienen que filtrar estos prefijos.

 

6. Datos autores

 

Azael Fernández Alcántara

Universidad Nacional Autónoma de México (UNAM)

Dirección General de de Cómputo y de Tecnologías de Información y Comunicación (DGTIC)

Laboratorio de Tecnologías Emergentes de Red (NETLab)

Circuito Exterior S/N, C.U.

México, DF, 04510

Tel.: (55) 562-28857

e-correo: azael@ipv6.unam.mx

 

Tobías Gallegos Cielo

Instituto Nacional de Astrofísica Óptica y Electrónica (INAOE)

Luis Enrique Erro #1 Sta. María Tonantzintla

San Andrés Cholula, Puebla

Tel: (222)-266-31-00 Ext. 8125

e-correo: tobigal@inaoep.mx

 

Centro de Operación de la RedCUDI

Tel.: (55) 5211-3049

e-correo: noc@cudi.edu.mx

Definiciones:

 

Abilene – Red académica de los Estados Unidos de América.

CLARA – Corporación Latinoamericana de redes avanzadas.

GÉANT - Proyecto y red académica europea.

IANA – Internet Assignment Number Authority.

Improper routes – son las direcciones de red que no deben ser anunciadas globalmente hacia Internet.

Import routing policy – se refiere a las políticas de acceso para las redes de los Asociados y Afiliados Académicos.

 

 

Referencias:

 

[1] draft-cudi-ipv6-direccionamiento-2006-01

 

[2] Direccionamiento IPv6 para el Backbone de la red Internet2 de México (RedCUDI) versión 2.0 Enero 2007. Que substituyó a: Nuevo Direccionamiento IPv6 para el Backbone de la red Internet2 de México (RedCUDI) versión 1.2 Marzo 2006. Documentos internos.

 

[3] IPv6 Global Unicast Address Assignments
http://www.iana.org/assignments/ipv6-unicast-address-assignments

 

[4] T. Gallegos. “IPv6 en el INAOE.”  Junio 2012. http://www.cudi.edu.mx/eventos/2012/IPv6_INAOE-Lanzamiento-IPv6-Tobias.pdf

 

[5] IANA IPv6 Special Purpose Address Registry

http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml

 

[6] RFC 5156. “Special-Use IPv6 Addresses”. M. Blanchet. Abril 2008.
http:// www.ietf.org /rfc/rfc5156.txt

 

[7] RFC 4291. “IP Version 6 Addressing Architecture”. R. Hinden. Febrero 2006.
http:// www.ietf.org /rfc/rfc4291.txt

 

[8] RFC 5180. “IPv6 Benchmarking Methodology for Network Interconnect Devices”. C. Popoviciu. Mayo 2008.
http:// www.ietf.org /rfc/rfc5180.txt

 

[9] RFC 4843. “An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)”. P. Nikander. Abril 2007.
http:// www.ietf.org /rfc/rfc4843.txt

 

[10] RFC 3849. “IPv6 Address Prefix Reserved for Documentation”. G. Huston. Julio 2004. http:// www.ietf.org /rfc/rfc3849.txt

 

[11] RFC 3879. “Deprecating Site Local Addresses”. C. Huitema. Septiembre 2004. http:// www.ietf.org /rfc/rfc3879.txt

 

[12] A Discard Prefix for IPv6 http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-discard-prefix-05

 

[13] RFC 3701. “6Bone (IPv6 Testing Address Allocation) Phaseout”. R. Fink. Marzo 2004. http://www.ietf.org/rfc/rfc3701.txt

 

[14] RFC 4380. “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”. C. Huitema. Febrero 2006.

 

[15] RFC 3056. “Connection of IPv6 Domains via IPv4 Clouds”. B. Carpenter, Febrero 2001.

 

[16] RFC 4193. “Unique Local IPv6 Unicast Addresses”. R. Hinden. Octubre 2005.