NAPs

Autor: Roque Gagliano, LACNIC.

Resumen:

Este documento da una descripción de cómo implementar IPv6 en un Punto de Intercambio de Tráfico (por sus siglas IXP en inglés y comúnmente llamados también NAP). Incluye información sobre la configuración de la matriz de conmutación, las opciones para el plan de direccionamiento y operaciones generales de gestión. Los IXPs son básicamente un dispositivo de capa 2 (la matriz de conmutación) y en muchos casos la mejor recomendación dice que el tráfico y la gestión IPv6 no deben ser manejados en forma diferente a lo que ya se hace para IPv4.

Índice:

1- Introducción.
2- Configuración de la matriz de conmutación.
3- Direccionamiento.
4- Reverso DNS.
5- Configuración de servidor de rutas.
6- Servicios internos y externos.
7- Políticas de un NAP sobre IPv6.
8- Multicast IPv6.
9- Agradecimientos.
10- Referencias.

1- Introducción

La gran mayoría de los Puntos de Intercambio de Tráfico (IXP) trabajan en el nivel 2, haciendo la adopción de IPv6 una tarea sencilla. Sin embargo, los IXP normalmente implementan servicios auxiliares como ser estadísticas, servidores de rutas, acceso a información de rutas, herramientas de control sobre tráfico de broadcast que pueden ser impactados por la adopción de IPv6. En muchos casos la mejor recomendación es no tratar al tráfico y a la gestión de IPv6 diferente a IPv4. Este documento da una guía general sobre el impacto de IPv6 en un IXP nuevo o ya en funcionamiento, de forma que puede no ajustarse a una implementación particular. A finales del año 2008, existe ya una basta experiencia operativa sobre IPv6 en IXP a nivel global y muchas de las experiencias han sido recogidas en este documento. El documento asume una matriz de conmutación Ethernet, aunque pueden existir otros dispositivos en funcionamiento.

2- Configuración de la matriz de conmutación

La matriz de conmutación es un dispositivo de nivel 2 (en general un switch), por lo que el tráfico IPv6 será conmutado de la misma forma que el tráfico IPv4. Sin embargo, algunas funcionalidades de gestión pueden necesitar el soporte de IPv6. Estas funcionalidades pueden incluir: gestión del equipo, SNMP y análisis de flujos (flow).

Existen dos configuraciones típicas para el soporte de IPv6 en los puertos de un IXP:

• VLAN doble pila: en esta configuración el tráfico tanto de IPv4 como de IPv6 comparten una misma VLAN. No se requiere configuración extra en el switch. En general los participantes del IXP configurarán sus interfaces también como doble pila pero la configuración de puertos independientes puede ser una opción.
• VLAN independiente: una o varias VLANs IPv6 son configuradas para el transporte del tráfico IPv6. Si los participantes de un IXP ya tienen puertos etiquetados hacia el switch, esta configuración sólo requiere la adición de nuevas etiqueta en la misma interfaz. Si los participantes utilizan conexiones sin etiquetar, necesitarán un puerto separado y específico para la VLAN IPv6.

La configuración "VLAN independiente" permite la separación física del tráfico IPv4 e IPv6, simplificando el análisis diferencial del tráfico. Sin embargo, la configuración puede involucrar mayores costos de capital (dado que necesita posiblemente nuevos puertos) y operacionales.

Por otro lado, la configuración en doble pila permite una implementación de IPv6 libre de costos de capital, evitando la transformación de puertas de acceso en puertas etiquetadas. En esta configuración la separación del tráfico para su análisis estadístico puede realizarse a través del técnicas basadas en flujos, en particular separando por el campo "ethernet type" (0x0800 para IPv4 y 0x86DD para IPv6).

El soporte de paquetes con un MTU gigante debe ser evaluado. El único requerimiento técnico en IPv6 respecto al MTU es el soporte de para un tamaño de paquete mayor que o igual a 1280bytes [RFC 2460]. Tamaños típicos de MTU son: 1500 bytes, 4470bytes o 9216bytes.

3- Direccionamiento

Todos los Registros Regionales de Internet (RIRs) cuentan con políticas específicas para la asignación de direcciones IPv6 independientes del proveedor (PI) a los IXPs. Estas asignaciones son normalmente de un /48 [RIR_IXP_POLICIES]. Dependiendo del país y la región, la asignación puede ser realizada por un registro nacional de direcciones (NIR).

A partir del prefijo /48 asignado, siguiendo las recomendaciones del RFC 4291 [RFC4291], un prefijo /64 debería ser asignado a cada LAN del punto de intercambio de tránsito. Un prefijo /48 permite la configuración de 65536 LANs. Prefijos más largos (/65 a /127), son técnicamente posibles utilizando configuración estática de direcciones, pero deberían ser en general evitadas, de forma de mantener la compatibilidad con el formato EUI-64 y CGA (Cryptographically Generated Addresses) [RFC3972]. Consideraremos entonces un prefijo /64 para cada LAN.

La práctica usual para asignación del identificador de interfaz es realizar una configuración estática, desactivando la auto-configuración en cada interfaz. También, es importante que en una LAN donde todos los nodos presentes son enrutadores, se deberá desactivar la funcionalidad de publicación de rutas (o route advertisement del RFC4861) [RFC4861]. El objetivo es que ningún enrutador de esa LAN se configure a sí mismo como ruta por defecto para el resto de la LAN. Un equipo de monitoreo puede ser colocado en la LAN para el tráfico a las direcciones de multicast locales del link (ff02::/16), permitiendo sólo el tráfico ICMPv6 para el descubrimiento de vecinos (mensajes ICMPv6 Neighbor Solicitation y Neighbor Advertisement).

Cuando seleccionando el uso de identificadores de interfaces (IID) estáticos, existente diferentes opciones de cómo asignar "inteligentemente" estos 64 bits (o 16 caracteres hexadecimales). A continuación presentamos una lista no exhaustiva de mecanismos de selección de los IID:

1. Algunos IXP incluyen el número de ASN de los participantes, dentro de cada dirección IPv6. El número de ASN decimal es representado a través de la codificación binaria decimal (o BCD) logrando una lectura más amigable como se representa en el siguiente ejemplo:
   
   IXP LAN ejemplo: 2001:DB8::/64
   ASN: 64496
   Dirección IPv6: 2001:DB8::6449:6000:0000:0001/64 o su representación equivalente 2001:DB8::6:4496:1/64
   
   Por favor recordar que para el caso de ASNs de 32 bits, se requiere un máximo de 10 caracteres. Al tener disponibles 16 caracteres, para cada ASN es posible configurar hasta 2^16 direcciones IPv6.
    
2. A pesar que la representación BCD es más fácil de leer para una persona, algunos IXP prefieren el uso de la codificación hexadecimal del número de ASN, de la siguiente forma:
   
   IXP LAN ejemplo: 2001:DB8::/64
   ASN: 64496 (DEC) or FBF0 (HEX)
   Dirección IPv6: 2001:DB8::0000:FBF0:0000:0001/64 o su representación equivalente 2001:DB8::FBF0:0:1/64
   
   Los cuatro ceros delante del ASN (bits 63-96) serán utilizados para los ASNs de 32 bits.
    
3. Un tercer esquema para la asignación de direcciones IPv6 en forma estática a los participantes se alcanza a través de relacionar una porción de su dirección IPv6 a su dirección IPv4. En el siguiente ejemplo, los últimos tres decimales de la dirección IPv4 son copiados a los tres últimos caracteres IPv6, utilizando la codificación BCD:
   
   IXP LAN ejemplo: 2001:DB8::/64
   Dirección IPv4: 240.0.20.132/23
   Dirección IPv6: 2001:DB8::132/64
    
4. Un cuarto mecanismo puede ser vincular el IID IPv6 con el ID interno del participante en el IXP.

La misma práctica utilizada en la actualidad por el IXP respecto a la publicación de sus prefijos IPv4 en la DFZ (zona libre de ruta por defecto de Internet) también debe ser utilizada para IPv6. Servicios externos (como ser dns, página web o servidor ftp) podrá ser parte del prefijo asignado al IXP o de otro prefijo. Tener en cuenta que los prefijos para IXP pueden no pasar filtros estrictos de prefijos al ser de largo /48, si bien se encuentran descriptos en las páginas web de registro.

4- Reverso DNS

El administrador del IXP deberá configurar los registros PTR de todas las direcciones IPv6 asignadas a participantes bajo la zona reversa "ip6.arpa".

5- Configuración de Servidor de Rutas

Algunos IXPs ofrecen el servicio de Servidor de Rutas (o "route server"), tanto sea para para servicios de gestión (o "looking glass") como para soportar acuerdos de Peering Multi-lateral (MLPA). El soporte a IPv6 necesita ser adicionado a los enrutadores utilizados como extremos BGP. El equipamiento a utilizar tiene que soportar el transporte de tráfico IPv6 y las extensiones de BGP Multiprotocolo (MP-BGP) para la familia de direcciones IPv6 (RFC 2545 y RFC 4760).

Una buena práctica es de intercambiar la información de alcanzabilidad IPv6 sobre sesiones también establecidas sobre IPv6/TCP e independientes de las sesiones IPv4. Esta configuración permite que si existe un problema de alcanzabilidad con cualquier vecino IPv6, la sesión se caerá, sin afectar la sesión IPv4. Por favor considerar el uso de MD5 (y mejor IPSEC) para autenticar la sesión BGP.

En caso de brindar el servicio de espejado de rutas (Looking Glass) el mismo deberá estar disponible para su acceso externo por vía de IPv6, ya sea a través de una página web o de una consola terminal.

6- Soporte para servicios internos y externos

Ya se han mencionado algunos servicios externos que necesitan soporte IPv6, como ser gráficas de tráfico, servidores DNS, FTP, Web y Looking Glass. Otros servicios como servidores NTP o SIP gateways debe ser evaluados también. En general, todo servicio que se accede a través de IPv4 o que manipula direcciones IPv4 debe ser estudiado su comportamiento en IPv6.

Servicios internos son también importantes cuando se estudia la adopción de IPv6 en un IXP. Estos servicios pueden no tener interacción con tráfico IPv6 pero sí manipular direcciones IPv6, como es el caso del sistema de aprovisionamiento, de análisis de logs y estadísticas. Bases de datos y sus herramientas también deben ser evaluadas para determinar su soporte de IPv6.

7- Políticas de un IXP hacia IPv6

Las políticas internas de un IXP (o reglamento interno) deberán ser revisadas para estudiar si existe alguna mención al protocolo IP y determinar si la referencia es genérica, o específica para IPv4 o IPv6. La interpretación actual es que IP se refiere al Protocolo de Internet, independientemente que su versión sea IPv4 o IPv6. En el caso de contratos y reglamentos de usos, se deberán revisar también para lograr la adecuación de los términos IP, IPv4 e IPv6.

Políticas específicas para IPv6 puede ser necesarias para el control de ICMPv6 Route Advertisements, el control del tráfico Multicast local del link o la conexión de Peering Multilateral (MLPA).

Al igual que IPv4, el éxito del IXP va a ser medido por la cantidad relativa de tráfico a través de su matriz de conmutación y de participantes conectados. Para lograr la incorporación de participantes IPv6, es necesario realizar tareas de difusión que pueden incluir:

• Anuncio de la existencia del servicio IPv6 en la página de inicio del IXP y vía un comunicado de prensa.
• Anuncio de la existencia del servicio IPv6 mediante el anuncio en listas de correos.
• Incluir en la lista de participantes que se anuncia en la web del IXP qué participantes se encuentran conectados en IPv6.
• Incluir información IPv6 en bases de datos como peeringdb.com o napla.lacnic.net.

8- Multicast IPv6

Multicast IPv6 no es diferente desde el punto de vista de un IXP a multicast IPv4. Nuevamente, un IXP puede decidir utilizar una VLAN reservada para el tráfico multicast o intercambiar el tráfico multicast en la misma VLAN que el tráfico unicast. Como ya fue mencionado en el documento, el tráfico multicast local al link puede ser monitoreado para reducirlo a únicamente al descubrimiento de vecinos ICMPv6 [RFC4861] y al protocolo MLD (Multicast Listener Discovery) [RFC 3810].

9 - Agradecimientos

Quisiera agradece las contribuciones de las siguientes personas: Martin Levy (Hurricane Electric), Carlos Friaças of FCCN (GIGAPIX), Arien Vijn (AMS-IX), Louis Lee (Equinix) y Bill Woodcock (PCH).

10 - Referencias

[RIR_IXP_POLICIES] RIRs Allocations Policies for IXP. NRO Comparison matrix: http://www.nro.net/documents/comp-pol.html#3-4-2.

[RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC3810] L. Costa, Ed, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.