Best-Practices in Internet Exchange Point Operation

Sorry, notes for future integration.

• The in-band management logical interface of the IXP switches must not be on the same VLAN as the IXP switch fabric. Ideally, it should be numbered from within an unrelated and not-easily-discovered IP address allocation, on a VLAN other than VLAN 1, the default, and it should be both protected by an access control list, and monitored by an intrusion detection system.

• IXP traffic statistics and participant lists should be available on a web site which is publicly and globally accessible via transit; the in-addr zone associated with the IXP subnet should be maintained with accurate and up-to-date information about the IP address assignments within the subnet; and both of these things should be done in accordance with the IXP Documentation Best Common Practices document.

• IXP policy documents should include provision for switch-fabric extension, to facilitate expansion of the IXP from its original building into other nearby facilities. The process for approving switch-fabric extensions should include technical oversight by the membership or switch operators, but should not be so onerous as to discourage people from implementing it, nor should the owners of existing facilities be able to block implementation of extension into competing facilities. [Links to Seattle, Beirut, Kampala, Sao Paulo policies.](Links to Seattle, Beirut, Kampala, Sao Paulo policies.)

• The IXP peering subnet should not be advertised to anyone's transit, and optionally should not be carried within participants' own networks, in order to avoid opening a path for DDoS attacks against participants' routers.

• All pertinent public information about peers should be documented in TXT records in the peering subnet IN-ADDR DNS, in the traditional format as established by Bill Manning for 198.32.