Technical Requirements for Interconnection
This document lists the common technical requirements for interconnection between two networks, that have agreed to interconnect. The document covers both Public Interconnection over an Internet Exchange Point, and Private Interconnections. Private interconnection, also referred to as PNIs, are direct point to point circuit between two end networks setup for the purpose of exchanging traffic.
Ethernet is the most common method for both Public and Private Interconnection today (in 2019), and the Layer 2 part of this document is based on it. Additionally, IXPs requirements for their participants are detailed separately in Euro-IX BCP 1, and only a sub-set applicable to private interconnects is covered in this document.
The layer 3 part of the document focuses on IP version 4 (IPv4) and IP version 6 (IPv6) unicast traffic, as the most common type of traffic exchanged today. The document doesn’t cover Multicast traffic exchange.
- Slower speed Ethernet interfaces (10/100) should be configured with duplex, speed and other configurations and not be auto-sensing. GigE and higher speed interfaces should be configured to be auto negotiating.
- Category 5e or higher cables should be for copper interconnects.
- Single-mode Fiber for optical interconnects,
- Use of standards based 1000Base-LX, 10GBase-LR, 10GBase-ER, 100GBase-LR4, and 100GBase-ER4 optics (or their MSA approved -lite or newer versions).
- The ports should support IEEE 802.3ad Link Aggregation (LACP) or multipath to distribute load across multiple interconnect ports
Ethernet MAC Layer
- Frames forwarded towards the interconnect ports shall have one of the following ethertypes:
0x0800 – IPv4
0x0806 – ARP
0x86dd – IPv6
- Frames forwarded on the interconnection circuits should have same source MAC address. For link-aggregated ports, all member interfaces should be treated as a single circuit.
- No broadcast or multicast traffic should be forwarded on the private interconnect.
- Link-local traffic should be limited to the following protocols.
IPv6 Neighbour solicitations and advertisements
Examples of other link-local protocols are: IRDP, ICMP redirects, IEEE802 Spanning Tree, Vendor proprietary discovery protocols (e.g. CDP, EDP), Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP), BOOTP/DHCP, PIM-SM, PIM-DM, DVMRP. These should be disabled on the interconnection facing interfaces.
Private interconnection is recommended to use /31 or /30 for IPv4 link-local addresses, and /127 or /64 for IPv6 link-local addresses. IPv6 site-local addresses shall not be used. rDNS should be configured with mutual agreement.
- Support Border Gateway Protocol (“BGP”) version 4 routing protocol for propagating routing information across the interconnect
- Support both IPv4 unicast and IPv6 unicast traffic as native or dual-stacked
- Accept any appropriately IRR-registered prefix announcements up to /24 in length for IPv4 and 4 and /48 in length for IPv6.
- Employ a routing policy that ensures that traffic generally follows a closest-exit behavior.
- Support BGP prefix filter updates using the Internet Route Registries (“IRR”), with automated router configuration updates occurring no less than every 24 hours: RADB, ALTDB, RIPE, APNIC and ARIN;
Traffic on interconnection interfaces shall forwarded only to routes being advertised across the interconnection. Any kind of static shouldn’t be done.
Looking Glass and non-routing devices:
When a BGP speaker is collecting routing information for analysis and not for immediate routing decisions, the BGP speaker may use a private AS number and should not advertise any routes.
These are evolving requirements, and may be required by some peers, and will be increasingly more important in coming years.
- Support BGP prefix filters using ROAs for origin ASN validation for directly connected peers, or use RPKI based validation for all route and traffic exchange.
- Peers may require that peering partners do not have no end-of-life equipment or software.
- Peers may require that interconnecting parties do not prioritize any Internet traffic which passes across Peers backbone, and customer links except for traffic associated with reasonable network management;
- Peers Support a comprehensive and documented BGP community scheme for marking prefixes sent to each-other identifying: prefix origin (incl. City, State/Province, Country, Continent) and prefix type (customer, internal);
- Support BGP community triggered packet discard (blackholing) of traffic within the Network supporting IPv4 prefixes up to /32 and IPv6 prefixes up to /128;