rules

The packet:IX exists as a cooperative effort and the following rules ensure the short and long term health of the exchange fabric:

• Peering is bilateral with the exception of route servers. There is no Multi-Lateral Peering Agreement (MLPA).
• Participants must use BGP-4 or its successor and must set NEXT_HOP_SELF if advertising routes from other packet:IX participants.
• Participants may not point default or otherwise use another participant's or packet:IX's resources without permission.
• There are only three ethertypes allowed: 0x0800 (IPv4), 0x0806 (ARP), and 0x86dd (IPv6).
• The only non-unicast traffic allowed is broadcast ARP and multicast ICMPv6 Neighbor Discovery packets . Per-neighbor timeouts that result in flooded (broadcast/multicast) packets should be set to 4 hours or as close to that as able in the case of vendor limitations. Short timeouts may result in quarantine.
• Participant ACLs must not violate neighbor discovery norms, since doing so will result in excess flooded packets on the community fabric and burden for packet:IX administrators. For IPv4 this means that a participant's router must be configured to receive and respond to ARP packets from all packet:IX participants, even those that are not direct peers. For IPv6, this means that participant routers must receive and respond to ICMPv6 neighbor solicitation packets from both fe80::/10 and all packet:IX participant addresses, including those that are not direct peers, directed toward fe80::/10, ff02::1:ff00:0/104, and the participant's unicast packet:IX assignments. Pseudo-ACL examples of this are available in the packet:IX FAQ.
• Participants must not allow packet:IX subnets to propagate externally from their network and should minimize internal propagation as much as able. If a participant's network beyond their packet:IX edge router(s) can reach the packet:IX subnet addresses, ACLs are requested in order to prevent this.
• Participants may not sniff traffic between other participants.
• Participants must be responsive to other participants and packet:IX administrators in order to protect the short and long term health of the exchange fabric. Urgent issues may result in suspension of a participant in order to protect the fabric. For non-urgent issues, if a participant is unresponsive to concerns raised by a packet:IX administrator, a packet:IX administrator will notify the non-responding participant via their PeeringDB and packet:IX contact emails, of their need to respond in order to avoid suspension from the packet:IX. The length of time to determine if a participant is unresponsive, and time to suspension, will depend on the severity of the matter, each not to exceed two weeks.