Fulfill the technical conditions

The following technical requirements determine DTEL-IX service provision conditions (hereinafter referred to as “the Services”) and are targeted at guaranteeing maximum protection and quality of the Services provided to the DTEL-IX Participants.
1. DTEL-IX Services may be provided to the Participant (legal entity) that has an Autonomous System (AS) number and is registered in a Regional Internet Registry (RIR). The territory of Ukraine is under the RIPE NCC registry (http://www.ripe.net).

2. The Participant using the Services shall comply with all standard requirements as provided in IETF STD1 document (http://www.rfc-editor.org/rfcxx00.html).

3. The Participant shall keep up-to-date its autonomous system routing support policy information at the Internet Routing Registry (IRR) RIPE, ARIN or RADB.
4. At all DTEL-IX connection interfaces the Participant shall turn off the autonomous speed synchronization and duplex (auto-negotiation) function and shall clearly define its interface configuration.
5. At all DTEL-IX connection interfaces the Participant shall turn off ARP proxy, Broadcast forwarding, Spanning tree, IP Redirects, CDP, as well as any type of layer2 protocols, except for ARP і ICMPv6 Neighbor Discovery. Multicast Ethernet frame transfer via DTEL-IX network shall be allowed exclusively on multicast VLAN.
6. The Participant shall inform DTEL-IX of all logic interface MAC addresses used for connecting to DTEL-IX.
7. At each DTEL-IX connection interface the Participant shall transfer Ethernet frames only to the MAC addresses received via the interface.
8. For each individual DTEL-IX port, the Participant shall transfer Ethernet frames on general and multicast VLAN from only one logic interface.
9. On general and multicast VLAN the Participant shall transfer only Ethernet frames of the following types (http://www.iana.org/assignments/ethernet-numbers): 0x0800 - IPv4, 0x0806 - ARP, 0x86dd - IPv6.
10. The Participant shall at all DTEL-IX connection interfaces use only the IP addresses and net masks provided by DTEL-IX. The Participant shall not announce DTEL-IX IP addresses without prior written consent.
11. The Participant shall use BGP4 protocol for establishing peering sessions on the general VLAN.
12. The Participant shall use MSDP/MBGP protocols for establishing peering sessions on the multicast VLAN.
13. The Participant shall direct traffic via DTEL-IX only to autonomous systems (networks) announced to the Participant thought DTEL-IX.
14. It is prohibited for the Participant to use “static route” on any DTEL-IX Participants.
15. The provisions of Clauses 15.1 - 15.4 shall be applied only in case of use of Route Server (RS) service:
15.1. Filter update at DTEL-IX route servers for each Participant is done automatically, with the use of the up-to-date records in RIPE, ARIN or RADB data bases once a day. The update time shall be determined by the technical team.
15.2. The Participant undertakes to establish BGP sessions with each DTEL-IX route server.
15.3. The Participant undertakes to announce to DTEL-IX route servers (AS31210) networks in accordance with their routing policy description at the RIPE, ARIN or RADB data bases. As well as in the AS_PATH attributes of the announced networks the number of the most recent AS must be identical with the origin field of the corresponding object of route and/or route6 type in the Internet Routing Registry.

15.4. The Participant shall not announce to DTEL-IX route servers (AS31210) any private networks, private AS, default route, full view.
15.5. The Participant shall ensure no Route Leaking, i.e. shall not announce to DTEL-IX route servers any networks of its peering partners that have not been obtained from the peering partners DIRECTLY.


Should the Participant breach the Technical Requirements provided in this Annex, DTEL-IX has the right to stop providing the Services and to move the Participant’s port (ports) to quarantine VLAN having notified the Participant ahead of time by sending a message via electronic mail to an administrative or technical representative of the Participant.


The Participant’s port (ports) configuration restoration can be done by DTEL-IX within 24 hours of receipt of an electronic mail message from the Participant’s administrative or technical representative on elimination of the breach of the Technical Requirements provided in this Annex, as well as after a detailed inspection by DTEL-IX targeted at verification of the fact of elimination of the breach.

 

The following technical requirements determine DTEL-IX service provision conditions (hereinafter referred to as “the Services”) and are targeted at guaranteeing maximum protection and quality of the Services provided to the DTEL-IX Participants.

1. DTEL-IX Services may be provided to the Participant (legal entity) that has an Autonomous System (AS) number and is registered in a Regional Internet Registry (RIR). The territory of Ukraine is under the RIPE NCC registry (http://www.ripe.net).

2. The Participant using the Services shall comply with all standard requirements as provided in IETF STD1 document (http://www.rfc-editor.org/rfcxx00.html).

3. The Participant shall keep up-to-date its autonomous system routing support policy information at the Internet Routing Registry (IRR) RIPE, ARIN or RADB.

4. At all DTEL-IX connection interfaces the Participant shall turn off the autonomous speed synchronization and duplex (auto-negotiation) function and shall clearly define its interface configuration.

5.  At all DTEL-IX connection interfaces the Participant shall turn off ARP proxy, Broadcast forwarding, Spanning tree, IP Redirects, CDP, as well as any type of layer2 protocols, except for ARP і ICMPv6 Neighbor Discovery. Multicast Ethernet frame transfer via DTEL-IX network shall be allowed exclusively on multicast VLAN.

6. The Participant shall inform DTEL-IX of all logic interface MAC addresses used for connecting to DTEL-IX.

7. At each DTEL-IX connection interface the Participant shall transfer Ethernet frames only to the MAC addresses received via the interface.

8. For each individual DTEL-IX port, the Participant shall transfer Ethernet frames on general and multicast VLAN from only one logic interface.

9. On general and multicast VLAN the Participant shall transfer only Ethernet frames of the following types (http://www.iana.org/assignments/ethernet-numbers): 0x0800 - IPv4, 0x0806 - ARP, 0x86dd - IPv6.

10. The Participant shall at all DTEL-IX connection interfaces use only the IP addresses and net masks provided by DTEL-IX. The Participant shall not announce DTEL-IX IP addresses without prior written consent.

11. The Participant shall use BGP4 protocol for establishing peering sessions on the general VLAN.

12.  The Participant shall use MSDP/MBGP protocols for establishing peering sessions on the multicast VLAN.

13. The Participant shall direct traffic via DTEL-IX only to autonomous systems (networks) announced to the Participant thought DTEL-IX. 

14. It is prohibited for the Participant to use “static route” on any DTEL-IX Participants.

15. The provisions of Clauses 15.1 - 15.4 shall be applied only in case of use of Route Server (RS) service:

15.1. Filter update at DTEL-IX route servers for each Participant is done automatically, with the use of the up-to-date records in RIPE, ARIN or RADB data bases once a day. The update time shall be determined by the technical team.

15.2. The Participant undertakes to establish BGP sessions with each DTEL-IX route server.

15.3. The Participant undertakes to announce to DTEL-IX route servers (AS31210) networks in accordance with their routing policy description at the RIPE, ARIN or RADB data bases. As well as in the AS_PATH attributes of the announced networks the number of the most recent AS must be identical with the origin field of the corresponding object of route and/or route6 type in the Internet Routing Registry.

 

15.4. The Participant shall not announce to DTEL-IX route servers (AS31210) any private networks, private AS, default route, full view.

15.5. The Participant shall ensure no Route Leaking, i.e. shall not announce to DTEL-IX route servers any networks of its peering partners that have not been obtained from the peering partners DIRECTLY.

Should the Participant breach the Technical Requirements provided in this Annex, DTEL-IX has the right to stop providing the Services and to move the Participant’s port (ports) to quarantine VLAN having notified the Participant ahead of time by sending a message via electronic mail to an administrative or technical representative of the Participant.

The Participant’s port (ports) configuration restoration can be done by DTEL-IX within 24 hours of receipt of an electronic mail message from the Participant’s administrative or technical representative on elimination of the breach of the Technical Requirements provided in this Annex, as well as after a detailed inspection by DTEL-IX targeted at verification of the fact of elimination of the breach.