TKM-IX Peering Policy:

About Route Server:
The Route Server (RS) is a network service that simplifies peering between TKM-IX participants and allows them to reduce the number of individually administered peering sessions. The RS retransmits BGP announcements between the connected participants, thus peering with the RS means establishing peering relations with all the other TKM-IX participants connected to the RS.

Route Server service doesn't influence cross-network delays as the traffic between interfaces of participants is transferred directly.

Available on the common peering VLAN, the RS operates over IPv4 and IPv6 and supports 16bit and 32bit AS numbers.

How to start using RS?
All participants using the RS must comply with the Technological Requirements.

To start using the RS, a participant must perform the following steps to establish a BGP peering session with Route Server autonomous system (see configuration table upper):

Add peering with Route Server AS to the routing policy description of your AS. The routing policy description must be maintained in RIPE, ARIN, or RADB Internet Routing Registry (IRR).

Send application from authorized contact address to noc@tkm-ix.net containing the ID of the organization, the AS number and the IP address of the border router (IPv4 and/or IPv6).

Configure BGP-sessions with both instances of the RS.

Disable first-as check in your BGP configuration by issuing no bgp enforce-first-as command (or it's counterparts for your vendor).

Information about TKM-IX participants peering with the RS may be retrieved at Customer Portal TKM-IX.

Information about RS routing policy may be retrieved from the RIPE database (see https://www.ripe.net or whois -h whois.ripe.net as[Route Server AS]).

Use the RS Looking Glass to view and debug BGP announcements to the RS.

RS routing policy

The RS exchanges the routing information with connected participants via BGP4 protocol as described in RFC4271. By default, the RS announces the best of all routes received from its peers. The Next-Hop attribute contains the IP-address of the host from RS received the announcement. The AS_PATH attribute is passed unchanged. Thus, the traffic is exchanged between RS peers directly.

RS is processing the BGP routes on the following rules:
RS does not accept routes of private networks, default route and networks with special purpose (RFC6890).

RS does not accept routes of private AS and AS with special purpose (RFC5398, RFC6996, RFC7300, RFC7607).

RS does not accept routes for networks where the value "origin" of the object "route/route6" in the database IRR does not match with the starting AS number in the AS_PATH attribute.

RS does not accept routes for networks for which the number of the last added AS in the AS_PATH attribute does not match the AS number of the participant established BGP session.

RS performs RPKI check (RFC6480) for the given route and mark result with special BGP community. Routes with RPKI_INVALID status are rejected.

BGP community attributes

RSAS means Route Server AS number in your city. Route Server supports two groups of BGP community attributes: basic and extra. Basic communities are applied in the table order. The processing priority of BGP Community: Large > Standard.

Basic

Technological Requirements:

The Customer shall clearly specify the duplex speed and mode in their IX network connection interfaces of the types 100BASE-TX or 1000BASE-T.

When using the Services, the Customer shall comply with the standards determined in IETF STD1 (http://www.rfc-editor.org/rfcxx00.html).

The Customer shall have the number of an autonomous system (“Autonomous System” or “AS”) registered with one of the regional internet registries (“Regional Internet Registry” or “RIR”).

The Customer shall maintain and update the data about the network routing policy of its AS in one of the following internet routing registries (“Internet Routing Registry” or “IRR”): RIPE, ARIN, RADB, AFRINIC, APNIC or LACNIC.

The Customer shall turn off Proxy ARP, broadcast forwarding, spanning tree, IP redirects, Link Layer Discovery Protocols (LLDP, etc.), as well as the protocols of hardware manufacturers that initiate transmission of external Ethernet frames (CDP, Layer 2 keepalive, etc.), except for LACP, in the interfaces connecting to the IX network.

The Customer shall provide the Contractor with the MAC addresses of all the logical interfaces used to connect to the IX network. For each physical interface used by the Customer to connect to the IX network, it is only permitted to use one MAC address, except during periods when the Customer’s equipment is being replaced, upon prior agreement with the Contractor.

The Customer shall not transfer multicast Ethernet frames to the IX network via the Peering VLAN, except for ICMPv6 Neighbor Discovery.

The Customer shall transfer only Ethernet frames of the following types via the IX network (http://www.iana.org/assignments/ethernet-numbers): 0x0800 – IPv4, 0x0806 – ARP, 0x86dd – IPv6, 0x8100 – 802.1Q

The Customer shall use only the IP addresses and network masks dedicated by the Contractor, in the IX network connection interfaces.

The Customer shall not advertise the IP addresses of the IX network outside its AS.

The Customer shall use the BGP4 protocol to establish peering sessions on the Peering VLAN.

The Customer shall use only one number of the AS in each logical interface of the IX network connection for BGP4 protocol interactions.

The Customer shall route traffic via the IX network only to the networks advertised to the Customer from the IX network and ensure that traffic is transmitted from the IX network to the networks advertised by the Customer in the IX network.

The Customer shall specify the value of IPv4/IPv6 MTU as 1,500 bytes in the logical interfaces of the IX network connection.

The Customer shall maintain and update route and/or route6 objects in the Internet Routing Registry for the networks of its AS advertised by the Customer on RS.
The Customer shall establish BGP sessions with every route server of the IX network according to the data available on the Contractor’s website.

The Customer shall advertise RS of the network in line with the network data routing policy in the Internet Routing Registry. In particular, in the AS_PATH attributes of the advertised networks, the number of the last AS shall match the ‘origin’ field of the respective route and/or route6 object in the Internet Routing Registry.

The Customer shall not advertise private networks, private autonomous systems, a default route or the complete routing chart, on RS.

TKM-IX Peering Rules:

Permitted Traffic Types on Unicast Peering LANs

Important: The TKM-IX Network Operations Center (NOC) may disable any ports that violate the following rules.

To maintain the efficient operation of the TKM-IX infrastructure, we enforce specific restrictions on the types of traffic allowed on the peering fabric. Below is an overview of these restrictions.

1. Ethernet Framing

The TKM-IX infrastructure uses the Ethernet II standard. LLC/SNAP encapsulation (802.2) is not permitted.
Frames sent to TKM-IX ports must have one of the following Ethernet types:

• 0x0800: IPv4
• 0x0806: ARP
• 0x86dd: IPv6
• 0x8100: IEEE 802.1Q

2. MAC Address Policy

All frames forwarded to an individual TKM-IX port on a single VLAN must originate from the same source MAC address.

3. Prohibition of Proxy ARP

Proxy ARP cannot be used on the router interface connected to the Exchange.

4. Unicast Traffic Only

Frames forwarded to TKM-IX ports must not have a multicast or broadcast MAC destination address, with the following exceptions:

• Broadcast ARP packets
• Multicast ICMPv6 Neighbor Discovery, Neighbor Solicitation, and MLD packets (excluding Router Solicitation or Advertisement packets).

5. No Link-Local Traffic

Link-local protocol traffic must not be forwarded to TKM-IX ports. This includes, but is not limited to:

• ICMP redirects
• IEEE 802 Spanning Tree
• Vendor-specific protocols such as:
• Discovery protocols: CDP, EDP, LLDP, etc.
• VLAN/trunking protocols: VTP, DTP
• Interior routing protocol broadcasts (e.g., OSPF, ISIS, IGRP, EIGRP)
• BOOTP/DHCP
• PIM-SM, PIM-DM, DVMRP
• ICMPv6 ND-RA
• UDLD
• L2 Keepalives

Exceptions: ARP and IPv6 ND protocols are allowed.

6. No Directed Broadcasts

IP packets directed to the broadcast address of the TKM-IX peering LAN must not be forwarded to TKM-IX ports.

7. No Export of TKM-IX Peering LAN

IP address space assigned to TKM-IX Peering LANs must not be advertised to other networks (including Internet) without explicit permission from TKM-IX.

8. Prohibition of Malicious Activities

Using application layer protocols to carry out malicious activities against other TKM-IX customers over the TKM-IX infrastructure is strictly forbidden.
TKM-IX reserves the right to disable a customer’s port if complaints of attacks or abuse originating from that customer are received. Prohibited attacks include, but are not limited to:

• BGP hijacking
• DNS amplification/flood
• HTTP flood
• NTP amplification
• UDP flood
• ICMP flood
• Simple Service Discovery Protocol (SSDP) abuse

TKM-IX Joining Procedure

To connect to TKM-IX, follow these steps:

1. Contact a TKM-IX administrative representative and determine the technical parameters for the connection, including the city, node address, and port configuration on the TKM-IX network.

2. Sign a service agreement with TKM-IX.

3. Obtain your organization's identifier and the coordinates of the dedicated port for connection to the TKM-IX network.

4.Pay the invoice for the one-time service setup fee.

5. Arrange a communication line between your equipment and the dedicated port on the TKM-IX network. Inform TKM-IX technical representatives of the communication line's labeling. To receive a confirmation letter from TKM-IX for the acceptance of the communication line, send a request to the TKM-IX administrative representative by email.

6. Notify the TKM-IX administrative and technical representatives of your readiness to connect. Include the following in your email:

• The MAC address of your router
• The fully qualified domain name (FQDN) of your router for the PTR record in the reverse DNS zone (required only for access to the general peering VLAN)
• The desired connection protocol: IPv4 and/or IPv6 (default is IPv4).

7. Upon connection to the TKM-IX network, your port will be placed in a quarantine VLAN. Configure your setup and send a notification of readiness to the TKM-IX NOC (noc@tkm-ix.net). If no errors are found, your port will be moved to a VLAN according to the service parameters specified in the agreement. The troubleshooting period may be extended if the technical conditions are not met.

8. Establish BGP protocol interaction with the Route Servers and/or other TKM-IX participants. Don't forget to update your routing policy description in the RIPE database and your information in PeeringDB.