BGP Peering
Policy

General Principles

• Open Peering: NSCIX encourages an open peering policy among its participants. The decision to peer is ultimately at the discretion of each individual participant.
• Neutrality: NSCIX operates as a neutral and transparent platform. It does not interfere with peering negotiations or traffic exchange between participants.
• Stability and Reliability: All participants are expected to configure their BGP sessions in a manner that promotes the overall stability and reliability of the IXP fabric.

Technical Requirements

2.1 Autonomous System Number (ASN)

• All participants must have a valid public ASN assigned by a Regional Internet Registry (RIR) such as ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC.
• Private ASNs (64512–65534 and 4200000000–4294967294) are NOT PERMITTED for peering on the public IXP fabric.

2.2 IP Addressing

• Participants must use the IPv4 and/or IPv6 addresses assigned by NSCIX for peering sessions. These addresses will be provided by the IXP administrator.
• The NSCIX peering LAN uses a shared IPv4 /24 subnet and a shared IPv6 /64 subnet. Each participant is assigned a single IPv4 address and a single IPv6 address from the respective peering LAN block. These addresses must not be used for any purpose other than peering on the IXP fabric.

2.3 BGP Configuration

• Session Type: All peering sessions must be eBGP. iBGP sessions are NOT PERMITTED across the IXP fabric.
• Next-Hop Preservation: Participants must accept that the route server will not next-hop-self or prepend its own ASN — it acts as a best path-relay and remains transparent.
• Route Advertising:
  • Participants should only advertise routes for networks they originate or are authorized to provide transit for.
  • Default routes (0.0.0.0/0 or ::/0) should not be advertised to the IXP route servers.
  • Martian routes and bogon prefixes (including RFC 1918 and RFC 4193 private addresses) MUST NOT be advertised.
  • Prefixes more specific than /24 (IPv4) or /48 (IPv6) MUST NOT be advertised to the route servers.
  • No static routes are permitted.
• Maximum Prefixes: Participants should implement appropriate maximum prefix limits on their BGP sessions to prevent accidental route leaks or denial-of-service conditions. NSCIX may specify recommended or mandatory limits.
• Filtering: Participants are responsible for implementing appropriate ingress and egress filtering on their BGP sessions to ensure the integrity of their advertised routes.
• Route Servers:
  • NSCIX operates route servers to simplify peering. Participants are strongly encouraged to peer with the route servers.
  • Peering with the route servers does not preclude direct bilateral peering with other participants.
  • Participants peering with the route servers must maintain an active session and must not blanket-reject routes received from the route servers.
• IRR Registration: Participants must register their routes in a recognized, authoritative IRR database (e.g., ARIN, RIPE, RADB) and maintain accurate, up-to-date AS-SET objects.
• RPKI Validation: NSCIX performs Route Origin Validation (ROV) on all BGP sessions. The route servers will reject any prefix with an RPKI status of Invalid. Prefixes with a status of NotFound or Valid are processed according to IRR-based filters.

2.3.1 Informational BGP Communities

These communities are attached by the NSCIX route servers to indicate why a route was accepted or rejected. Rejected routes are placed in a filtered table, allowing members to view the rejection reason via the looking glass.

2.3.2 Action BGP Communities

Send these communities on routes advertised to the route servers to control how your prefixes are distributed to peers.

Blackhole

2.4 MAC Addresses

• Only one MAC address per port is allowed on the IXP fabric.
• Spanning Tree Protocol (STP) MUST NOT be enabled on the IXP port.
• Proxy ARP MUST NOT be enabled on the IXP port.

2.5 Allowed Ether Types

• Only three ether types are permitted to traverse the IX fabric:
  • 0x0800 — IPv4
  • 0x0806 — ARP
  • 0x86DD — IPv6
• Only unicast IPv4 and IPv6 traffic is supported. Multicast traffic is NOT PERMITTED on the IXP fabric.

2.6 Supported Optics

• Supported optics are single-mode LR (10G), LR4 (100G), and FR4 (400G). The optic type and port speed must be specified at the time of order. No other optic types are supported on the IXP fabric.

Operational Requirements

• MTU: The Maximum Transmission Unit on the NSCIX peering LAN is 1500 bytes. Participants MUST configure their IXP-facing interfaces accordingly. Jumbo frames are not supported.
• PeeringDB Registration: Participants MUST maintain an active and accurate PeeringDB record (https://www.peeringdb.com). An up-to-date PeeringDB listing is essential to the integrity of interconnection facilitation and is the primary tool prospective peers use to discover and evaluate peering partners. NSCIX's own PeeringDB entry can be found at https://www.peeringdb.com/net/41879.
• Contact Information: Participants must provide and maintain up-to-date 24/7 NOC contact information (email and phone number) with NSCIX.
• Abuse Contact: Participants must provide a valid abuse contact email address.
• Troubleshooting: Participants are expected to cooperate with NSCIX and other participants in troubleshooting network issues.
• Maintenance: Participants must notify NSCIX in advance of any planned maintenance that may affect their peering sessions.
• Compliance: Participants must comply with all applicable laws and regulations.

Policy Violations

• Violations of this peering policy may result in temporary suspension or permanent termination of the participant's connection to the IXP fabric.
• NSCIX reserves the right to take immediate action to protect the stability and integrity of the IXP fabric in the event of a severe policy violation or network instability.

Amendments

• This peering policy may be amended from time to time by NSCIX. Participants will be notified of any changes in advance.