This document may be copied freely. The current version of this document is available under http://ip6.de.easynet.net/ipv6-minimum-peering.txt Previous versions are available from http://ip6.de.easynet.net/ipv6-minimum-peering-0.4.txt http://ip6.de.easynet.net/ipv6-minimum-peering-0.5.txt Terminology ----------- MIPP Minimum IPv6 Peering Policy. Preliminary name for the set of requirements in this document. [better name anyone?] MIPP Compliant AS An autonomous system which fulfils the requirements stated in this the Minimum IPv6 Peering Policy. MIPPbone The set of MIPP compliant autonomous systems. [better name anyone? MIPPnet?] Bad Tunnel An IPv6-in-IPv4 tunnel where the networks of the IPv4 endpoints do not peer directly AND the RTT between the endpoints is more than 40ms. Opposite of good tunnel. Good Tunnel An IPv6-in-IPv4 tunnel where the networks of the IPv4 endpoints peer directly OR the RTT between the endpoints is less than 40ms. Opposite of bad tunnel. Introduction ------------ The current global IPv6 network suffers from a number of reliability problems. [6MESS] analyses them and proposes a number of solutions. This document provides one which fits under "Create Hierarchy and Control Transit". The overall goal is to establish a high-quality core IPv6 network. In particular, instabilities introduced by experimental IPv6 sites should be isolated so that they don't affect the global core. This document provides a set of conditions on interconnections of autonomous systems. These should be seen as a subset of the network's peering policy, addresses to backbone operators. A network which fulfils these conditions is called "MIPP compliant". The set of all MIPP compliant autonomous systems is called "MIPPbone". Once a critical number of ASes follows these guidelines, routing problems in other ASes do not affect routing between compliant ASes. In particular, 6bone is considered to live outside MIPPbone. Connectivity from and to 6bone sites will not necessarily profit from the stability improvements. Requirements ------------ An AS is MIPP compliant if and only if it fulfils all of the following conditions: 1. Avoid Tunnels. Interconnections between compliant networks SHOULD go via native connections. They MUST NOT use bad tunnels. 2. Filter on prefixes. Incoming prefix filters MUST be installed on all connections to non-compliant networks. Apart from 3FFE::/16, the filter SHOULD only permit the other network's and network's customers' prefixes. If this is not feasible, at least maximum-prefix filter MUST be installed so to not accept full routing tables. Prefixes tagged with the no-announce community MAY be accepted unrestricted. 3. Filter on private ASN. Private ASN SHOULD also be filtered, i.e. any prefix with an AS-Path including a private ASN SHOULD be rejected. 4. Filter on path length. Prefixes with very long AS paths SHOULD be rejected. It is suggested that the currently acceptable maximum path length is between 7 and 10. 5. Internal Network. A core network MUST have full control over the network connections inside their AS. Internally, any tunnels MAY be used as long as the underlying IPv4 infrastructure is controlled by the same operator. 6. DNS Reverse DNS (i.e. PTR records) SHOULD be maintained for all IP addresses used on links visible to the outside. The requirements stated here are only minimal requirements and should not be seen as a comprehensive peering policy. In particular, networks may impose further requirements on their upstreams, like native IPv6 backbone or capacity of the network. These additional requirement are out of the scope of this document. Transition ---------- In the transition phase, transit MAY be received from non-compliant networks. It should, however, be limited as far as possible. Leaf Sites ---------- Is is expected that after some time every pTLA network connects to at least one core network so that the whole RIR land can be reached within MIPPbone. Compliant networks are free to provide transit to any pTLA network, but they SHOULD insist that their networks are not announced in an uncontrolled way. Although undesirable, such leaf sites MAY be connected via tunnels, even bad tunnels. Ghost routes ------------ While ghost routes are annoying in the transition from /35 to /32, the more serious risk is that they can be deliberately abused for a virtually untraceably DoS attack to any IPv6 network, by announcing and quickly withdrawing a more specific prefix. Thus a production-quality network needs a way to reliably avoid them. Ghost routes are most likely generated by single-host 6bone sites operating old software. In the present situation, this can hardly be avoided. We can, however, assure that such ghost routes do not appear within MIPPbone. Filtering will do this, in particular the requirement to go unfiltered only between compliant networks. Supporting Networks ------------------- The following networks implement or will in near future implement the conditions listed under "Requirement" as part of their peering policy. In other words, the following networks confirm to be MIPP compliant. Network ASN Version Person Email ---------------------------------------------------------------------------------- Tele Danmark [1] 3292 0.4 Niels Chr. Bank-Pedersen C&W 3561 0.4 Torsten Blum Easynet 4589 0.4 Robert Kiessling UPC / Aorta 6830 0.4 Steven van Steen Roger Jorgensen noris network AG 12337 0.4 Marco Eulenfeld [1] tentatively, until further notice References ---------- [6MESS] P. Savola, "Moving from 6bone to IPv6 Internet", work in progress, http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt