REGLAS
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 (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.