Políticas sobre el enrutamiento

Las siguientes políticas de enrutamiento gobiernan la operación y administración de NAP.EC:

1. El protocolo de enrutamiento utilizado es Border Gateway Protocol 4, BGP-4 (RFC 4271, 4760 y sus respectivas actualizaciones).
2. Una sola sesión BGP por conexión con un servidor de rutas.
3. No se aceptan conexiones con números de sistema autónomo (ASN) de uso privado (RFC 1930, 6996, 7300) o de documentación (RFC 5398).
4. El ASPATH de los prefijos no debe contener ASN de uso privado o de documentación.
5. La longitud máxima permitida para el ASPATH es de 20 sistemas autónomos.
6. La opción BGP route-server-client (RFC 7947 y 7948) se habilita por defecto en todas las sesiones BGP.
7. Se descartan rutas por defecto y rangos de direcciones IPv4 e IPv6 de uso especial (redes privadas, de documentación, de uso experimental o de investigación, rangos reservados por IANA, RFC 1918, RFC 4193, RFC 5735, RFC 5737, RFC 6598, RFC 6890).
8. Se aceptan prefijos IPv4 con máscaras entre 8 y 24 bits.
9. Se aceptan prefijos IPv6 con máscaras entre 24 y 48 bits.
10. No se permite ebgp multi-hop.
11. Los proveedores deben anunciar los mismos prefijos sobre todas sus conexiones a NAP.EC.
12. Se aplica un filtro MAX-PREF que establece un número máximo para la cantidad de prefijos recibidos desde cada participante.
13. Si el participante desea configurar un filtro MAX-PREF para establecer el número máximo de prefijos recibidos desde NAP.EC, debe consultar y coordinar el valor adecuado con la administración de NAP.EC. Actualmente, se sugiere 27000 para IPv4 y 11000 para IPv6.
14. Los prefijos en estado RPKI «invalid» son descartados. Cuando un participante es informado de la presencia de este escenario con algún prefijo, debe dejar de anunciarlo o solucionar el error inmediatamente. Si el recurso IP está bajo administración de otra organización (socia o cliente), el participante de NAP.EC que anuncia dicho prefijo tiene la obligación de reenviar el comunicado a los contactos técnicos adecuados y realizar el seguimiento respectivo hasta que el problema en el enrutamiento sea resuelto. En caso que el participante no solucione el problema oportunamente o los problemas sean reiterados, la conexión será dada de baja hasta que el problema sea resuelto.
15. En NAP.EC se utiliza comunidades BGP estándar de 8 bits y large (RFC 8092 y 8195) de 32 bits. Las comunidades utilizadas tienen el siguiente significado:

    Standard   (8 bits)	Large   (32 bits)	Significado
    no-export	X:0:0	No anunciar a otros peer EBGP
    	X:1000:1	Origen RPKI valid
    	X:1000:2	Origen RPKI not-found
    	X:1000:3	Sin validación de origen RPKI
    	X:1000:4	Origen RPKI invalid
    	X:1900:1	Prefijo recibido en NAP.EC

    X = 52482 en NAP.EC-UIO y 52483 en NAP.EC-GYE
16. Todos los prefijos son anunciados desde NAP.EC con comunidad estándar «no-export».
17. En NAP.EC no se filtran aplicaciones, ni prefijos «públicos válidos”, esto debe cumplirse también en el lado del participante.

Los siguientes tipos de tráfico no son permitidos sobre las interfaces de conexión hacia NAP.EC:

• Paquetes BPDU
• Protocolos de descubrimiento (CDP)
• Protocolos de enlace de VLAN (VTP, DTP)

El MTU en todos los puntos de presencia de NAP.EC es: 1500 bytes.