Minimum Technical IPv6 Peering Requirements (MIPP) ================================================== Revision History ---------------- Version 0.1, 2002-11-04 First version published with limited distribution. Version 0.2, 2002-11-04 Change title to "Minimum IPv6 Peering Policy". Move focus to see this as peering policy. Add filtering on private ASN and AS path length. Version 0.3, 2002-11-04 Spelling corrections. Add `Supporting Networks� section. Add revision history. Version 0.4, 2002-11-04 Added clarification what a `good tunnel� is. Version 0.5, 2002-11-06 Change wording of `Supporting Networks� section. Added more supporting networks. Add URL, Author, non-copyright. Change name to MIPPbone. Change maximum path length from 7 to 7-10. Version 0.6, 2002-11-26 Change `network� to `(network) operator� or `AS�. Split tunnel classification into good, mediocre, bad. Clarify and slightly change `Avoid tunnels� requirement. s/MIPPbone/MIPPnet/ Add require about announcement control. Add recommendation to avoid 3FFE space and separate 6bone and production. Other editorial changes. Author: Robert Kiessling 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 http://ip6.de.easynet.net/ipv6-minimum-peering-0.6.txt Terminology ----------- AS [TBD - kind of equivalent to "network"] Operator The organisation responsible for operating an AS. In the RIPE region, this will usually be a Local Internet Registry (LIR). Interconnection An IPv6 network link between two ASes for the purpose of exchanging IPv6 traffic. Routing protocol BGP+ is used. Local operator, local AS The operator/AS in the local side of an interconnetion, i.e. the operator/AS to which the requirements are applied. Peer operator, peer AS The operator/AS on the other end of an interconnection. MIPP Minimum Technical IPv6 Peering Requirements. Preliminary name for the set of requirements outlined in this document. [MIPP is already taken by IETF for something mobile IP related. Ideas for a better abbreviation include 6peer, m6peer, mtpr6, Mi6, Mp6, Peer6, 6sense. Any suggestions welcome - "6" in the name seems like a good idea. Also it should be somehow pronouncable for the equivalent of "MIPPnet"] MIPP Compliant AS An autonomous system which fulfils the requirements in section [Requirements]. MIPP Compliant Operator A network operator implementing the requirements in section [Requirements] in the ASes under his control. MIPPnet The set of MIPP compliant autonomous systems. [Better name anyone?] IPv6-over-IPv4 Tunneling mechanism to transport IPv6 over infrastructure which is only IPv4 capable. The two most commonly used mechanisms are IPv6-in-IPv4 [6in4] and GRE [GRE]. Tunnel A virtual network link between two ASes using Layer 3 transport technology, as opposed to native connection via Layer 2 protocols. Usully IPv6-over-IPv4 is used for this. Every tunnels is exactly one of `good tunnel�, `mediocre tunnel� or `bad tunnel�. Good Tunnel A tunnel where the underlying network infrastructure for the whole path is controlled by the local or the peer operator. There is no limit on the round trip time of such a tunnel. In particular, a good tunnel includes IPv6-over-IPv4 where a direct peering or upstream relationship is established between the ASes of the IPv4 endpoints. Mediocre Tunnel A tunnel with a round trip time of less than 40ms, but going over some Layer 3 infrastructure which is controlled by neither the local not the peer operator. Typically, this would be an IPv6-over-IPv4 tunnel between ASes which don't peer directly. Bad Tunnel A tunnel where underlying Layer 3 infrastructure is used which is not controlled by the local or the peer operator, and at the same time the round trip time is more than 40ms. Peering [TBD - exchange of customer routes only] 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. They should be seen as a subset of a backbone operator's peering policy. An AS which fulfils these conditions is called "MIPP compliant". We call the set of all MIPP compliant autonomous systems "MIPPnet". In particular, 6bone is considered to live outside MIPPnet. 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 MIPP-compliant ASes SHOULD use native connections. If this is not possible, good tunnels SHOULD be used. Mediocre tunnels MAY be used. A bad tunnel MUST NOT be used for any such interconnection. Note that this requirement does not depend on the kind of routes exchanged and thus equally applies to peerings and transits, but only between compliant ASes. 2. Filter on prefixes. Incoming prefix filters MUST be installed on all interconnections with non-compliant ASes. Apart from 3FFE::/16, the filter SHOULD permit only prefixes belonging to the peer operator or their customers. If this is not feasible, the number of prefixes received MUST be limited in order to reject full routing tables (maximum-prefix in IOS, prefix-limit in JunOS). Prefixes tagged with the well-known no-export community MAY be accepted unrestricted. 3. Announcement control. Although undesirable, requirements (1) and (2) do not forbid peering connections or giving transit over bad tunnels to non-compliant ASes. However, care should be taken that those non-compliant ASes do not reannounce to a non-customer any prefix received from the local AS. 4. Filter on private ASN. Private ASN SHOULD be filtered, i.e. any prefix with an AS-Path including a private ASN should be rejected. Private ASN from directly connected peers MUST NOT be reannounced, i.e. the peer-AS in prefixes received from a direct peer with a private ASN must be handles appropriately so that it does not appear in AS-Paths announced to other peers. 5. 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. 6. Internal Network. A MIPP-compliant operator MUST have full control over the network connections inside their AS, i.e. links between routers in the AS MUST take either native connections or a tunnel where the underlying Layer 3 infrastructure (usually an IPv4 network) is controlled by the same operator. 7. DNS Reverse DNS (i.e. PTR records) SHOULD be maintained for all IP addresses used on links visible to the outside. 8. 3FFE::/16 space. Links inside and between MIPP compliant networks should use RIR-allocated address space. In particular, addresses from 3FFE::/16 should be avoided for such links. 9. Separation of 6bone and production. If the operator is also 6bone site, it is recommended that the 6bone parts are kept separate (e.g. two different routers) have carefully controlled connectivity. The requirements stated here are only minimal requirements and should not be seen as a comprehensive peering policy. In particular, operators may impose further technical requirements on their upstreams, like fully native IPv6 backbone or network capacity. These additional technical requirements as well as commercial arrangements are out of the scope of this document. Transition ---------- In the transition phase, transit MAY be received from non-compliant ASes. It should, however, be limited as far as possible. Once a critical number of ASes follows these guidelines, such transit can be dropped. At this point the goal is reached to isolate routing problems caused by non-compliant ASes, such as ghost routes. This point is reached once every AS accouncing RIR space (prefixes from 2001::/16) is connected to a compliant AS. Rationale --------- Ghost routes [6MESS] are annoying in the transition from /35 to /32. Moreover, they pose the more serious risk that they can be deliberately abused for a virtually untraceably DoS attack on any IPv6 network, by announcing and quickly withdrawing a more specific prefix. Avoiding them is a major motivation for this document, which is achieved by limiting non-filtered interconnections. The other main goal is better routing, in particular avoiding tunnels which don't follow the underlying IPv4 network so that round trip times and packet losses can be minimised. Why 40ms? This value is chosen to be less than trans-atlantic RTT, but on the other hand large enough to allow links within one country. Supporting Operators -------------------- The following operators implement or will in near future implement the conditions listed under "Requirement" as part of their peering policy. In other words, the following operators confirm that their ASes are MIPP compliant. Network ASN Version Person Email ---------------------------------------------------------------------------------- Tiscali 3257 0.6 Alexander Koch Tele Danmark [1] 3292 0.4 Niels Chr. Bank-Pedersen C&W 3561 0.4 Torsten Blum Easynet 4589 0.5 Robert Kiessling UPC / Aorta 6830 0.4 Steven van Steen Roger Jorgensen noris network AG 12337 0.4 Marco Eulenfeld Global Access 13129 0.5 Jan Czmok [1] tentatively, until further notice Mailing List ------------ Discussion about this peering policy takes place on a mailin list created for this purpose. Further information about the mailing list can be found on http://www.ipv6.cz/mailman/listinfo/ipv6-peering References ---------- [6MESS] P. Savola, "Moving from 6bone to IPv6 Internet", work in progress, http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt [6in4] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC2893 [GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation", RFC2784