PIT DOMINICANO
Inicio
Infraestructura
Route Servers
Miembros Activos
Estadísticas
Recursos
Instalaciones
Registro
Formulario En Linea (MPLA)
Formulario PDF (MPLA)
Requisitos
Beneficios
DERECHOS, DEBERES y OBLIGACIONES
Políticas
Reglas - Normas
Recomendaciones
PeeringDB
Sobre Nosotros
Contacto
Miembros
Misión - Visión
Cobertura
Contacto
Menu
Políticas
Las reglas de operación del Punto de Intercambio de Tráfico Dominicano establecen las normativas para facilitar el intercambio de tráfico entre los participantes del PIT DOMINICANO.
CONSIDERANDO
El propósito del PIT DOMINICANO es fomentar el intercambio de tráfico de Internet mediante una estructura de conmutación multicapa que proporciona puertos de acceso Ethernet y opera bajo el Protocolo de Internet (IP), garantizando neutralidad y transparencia.
Un Punto de Intercambio de Tráfico, conocido también como Internet Exchange Point (IXP), es una infraestructura de red que usualmente consta de switches y routers que utilizan el Protocolo de Internet (IP) en sus versiones 4 y 6. Estos dispositivos operan en las capas 2 y 3 del modelo OSI, proporcionando servicios para interconectar Sistemas Autónomos (AS) de las entidades participantes.
Todos los puertos de los equipos de red conectados al PIT DOMINICANO deben implementar el protocolo BGP-4. Este protocolo, utilizado por defecto en la Capa 3 por los Sistemas Autónomos en Internet, permite a cada sistema informar y obtener de sus pares los prefijos de red de otros sistemas conectados a través de sesiones BGP. Este intercambio de información facilita la visión de Internet como una red única o una red de redes. Cada participante está requerido a anunciar prefijos con una máscara de hasta 24 bits.
En un IXP, no es imprescindible que cada equipo de red de los participantes establezca sesiones BGP individuales con todos los demás participantes. En su lugar, se utilizan route servers para que los participantes anuncien sus prefijos a través de ellos. Esto posibilita que, mediante una sola sesión BGP establecida con el route server, cada equipo de red del participante pueda recibir los prefijos anunciados por todos los demás participantes. Este enfoque promueve una economía general de recursos al simplificar la gestión de las sesiones BGP y reducir la carga en los equipos de los participantes en el IXP.
Que en el PIT DOMINICANO se tienen al menos dos route-servers.
Para asegurar que la infraestructura del PIT DOMINICANO funcione eficientemente se emiten las siguientes:
REGLAS - NORMAS
1. El participante de PIT DOMINICANO debe poseer al menos un ASN válido (Autonomous System Number).
2. El participante de PIT DOMINICANO debe poseer al menos un bloque válido de direcciones IPv4 o IPv6.
3. El participante de PIT DOMINICANO debe utilizar BGP en IPv4, IPv6 como protocolo de enrutamiento externo.
4. El participante de PIT DOMINICANO y su ASN deben estar registrados en PeeringDB
https://www.peeringdb.com/
.
5. Los prefijos menores a /24 en IPv4 y menores a /48 en IPv6 serán filtrados y descartados.
6. Se aceptará en nuestros Route Servers el anuncio de prefijos registrados en LACNIC u otros RIR.
7. El ASN que utilice el participante para establecer sesiones de peering bilateral o multilateral, es decir con los Route Servers, debe pertenecer al participante de PIT DOMINICANO.
8. Quien anuncie a nuestros Route Servers un prefijo deberá cursar el tráfico que se origine y termine en el prefijo anunciado.
9. Sólo se podrá enviar tráfico hacia las redes anunciadas via BGP por cada uno de los miembros.
10. No se permite la utilización de “default gateway” (0.0.0.0/0), (::/0), rutas de último recurso y/o rutas estáticas.
11. Las direcciones IPv4 e IPv6 entregadas por PIT DOMINICANO para hacer peering sólo podrán ser utilizadas por el participante de PIT DOMINICANO que en ningún caso podrá ceder, vender, prestar, arrendar o permitir que sean utilizadas bajo cualquier concepto por un tercero.
12. Las direcciones IPv4 e IPv6 entregadas por PIT DOMINICANO para hacer peering en la VLAN pública no deben ser anunciadas a otros BGP. Estas direcciones IP sólo deben utilizarse para peering. Cualquier otro uso NO está permitido. En la VLAN de peering (VLAN Pública) sólo se podrán utilizar las direcciones IP asignadas por PIT DOMINICANO.
13. Los participantes podrán solicitar a PIT DOMINICANO VLAN bilaterales adicionales las que están afectas a cobro por tratarse de un recurso escaso y limitado.
14. Para ser miembro de PIT DOMINICANO debe contar con una conexión física. No se aceptan sesiones BGP Multihop.
15. Sólo se permite el uso de paquetes UNICAST. Las dos únicas excepciones son broadcast ARP para resolución de direcciones IPv4 del segmento de peering y multicast IPv6 NS/NA para resolución de direcciones IPv6 del segmento de peering.
16. No se permite ninguna forma de tráfico mal intencionado, ataques entre los participantes, spoofing de direcciones, DDoS, Flood en todas sus variantes, ataques de amplificación en todas sus variantes, etc.
17. Los siguientes tipos de tráfico no son permitidos sobre las interfaces de conexión hacia PIT DOMINICANO:
- Paquetes Bridge Protocol Data Units (BPDU).
- Protocolos de descubrimiento Cisco Discovery Protocol (CDP).
- Protocolos de enlace de VLAN Trunking Protocol (VTP), Dynamic Trunking Protocol (DTP).
18. Se descartan todos los “martians” y “bogons” conocidos. (Direcciones privadas y reservadas definidas por RFC 1918, RFC 5735 y RFC 6598).
19. Asegurarse de que haya al menos 1 ASN y menos de 64 ASNs en el AS Path.
20. Asegurarse de que el ASN del participante sea el mismo que el primer ASN en el AS Path.
21. Descartar cualquier prefijo donde la dirección IP del siguiente salto no sea la misma que la dirección IP del participante. Esto evita el secuestro de prefijos.
22. Descartar cualquier prefijo con un ASN de una red de tránsito conocida en el AS Path.
23. Asegurarse de que el ASN de origen esté en el conjunto de ASN de IRRDB AS-Set del cliente. (Si no se especifica un conjunto, todos los prefijos deben originarse en el ASN del miembro).
- Si el prefijo se evalúa como RPKI válido, aceptarlo.
- Si el prefijo se evalúa como RPKI no válido (inválido), descartarlo.
- Si el prefijo se evalúa como RPKI no encontrado (no existe ROA), vuelva al filtrado del prefijo IRRDB estándar:
- Todos los ASN de origen deben figurar como miembros: en as-set: (AS Macro) en el IRRDB.
- Debe haber un objeto route: o route6: con un correcto origin: ASN para que se acepte el prefijo.