Internet Draft L. Donnerhacke Category: Proposed Standard IKS GmbH Expires: November 27, 2010 May 27, 2010 More specific unicast routing for IPv6 transition technologies draft-donnerhacke-softwire-ipv6-6to4-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 27, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document extends the stability of 6to4 and Teredo routing by defining the global anycast routes 2002::/16 and 2001::/32 as a routes of last resort. More specific unicast routes are allowed in order to create a more stable environment. Donnerhacke Expires November 27, 2010 [Page 1] Internet Draft Unicast routing for 6to4 May 27, 2010 Table of Contents 1. Introduction .................................................. 2 2. Allowing more specific unicast routes ......................... 2 2.1. Allowing more specific unicast routes for 6to4 ........... 2 2.2. Allowing more specific unicast routes for Teredo ......... 2 3. Rationale ..................................................... 3 4. Security Considerations ....................................... 4 5. IANA Considerations ........................................... 4 6. References .................................................... 4 6.1. Normative References ..................................... 4 6.2. Informal References ...................................... 4 7. Changes history ............................................... 5 8. Acknowledgements .............................................. 5 1. Introduction 6to4 [RFC3056] and Teredo [RFC4380] define successful technologies to connect IPv6 networks over legacy only backbones. By allowing large ISPs to announce a more specific of the default anycast routes, the operational domain of transition technologies is extended from the service provider network under its direct control to the global net- work. From the perspective of customer sites and the global IPv6 Internet the IPv6 service provided by the service provider is equiva- lent to native IPv6. 2. Allowing more specific unicast routes The main purpose of this document is to legitimate announcements of more specific unicast routes into the global Internet. This document does only deals with the transition technologies of 6to4 and Teredo. It it not applicable to other anycasted services. 2.1. Allowing more specific unicast routes for 6to4 The relevant part of section 5.2 of RFC3056 6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16. is changed to 6to4 prefixes more specific than 2002::/16 are allowed to be Donnerhacke Expires November 27, 2010 [Page 2] Internet Draft Unicast routing for 6to4 May 27, 2010 propagated in native IPv6 routing, as long as the more specific matchs exactly the mapped most aggregated IPv4 route originated by the same AS. In order to prevent misuse, the route objects in the routing databases for such more specifics can only be created by the RIR which allocated the corresponding IPv4 prefix. So if an ISP announces a IPv4 prefix aa.bb.cc.0/20, it is now allowed to announce the 6to4 prefix 2002:aabb:cc00::/36, too, if it deploys 6to4 to it's customers. 2.2. Allowing more specific unicast routes for Teredo RFC4380 does not specify how the IPv6 Teredo prefix is to be announced by the Teredo relays. It does only state, that normal rout- ing technology should be used: Teredo relays are IPv6 routers that advertise reachability of the Teredo service IPv6 prefix through the IPv6 routing protocols. So if an ISP announces a IPv4 prefix aa.bb.cc.0/20, it is now allowed to announce the Teredo prefix 2000:0:aabb:cc00::/52, too, if it deploys Teredo to it's customers. 3. Rationale Several 6to4 routers and Teredo relays out there are broken and nobody cares about fixing them. There is not enough deployment to fix those problems by reporting errors. In order to provide stable routing over their IPv4-only backbones ISPs prefers to keep the 6to4 and Teredo traffic as long as possible in the IPv6 network. One proposal ist 6rd [I-D.ietf-softwire- ipv6-6rd] with allows every ISP to assign it's own unicast prefix similar to 2002::/16. This is a huge waste of address space. Announcing more specifics of an anycast default route allows opera- tors to drop routing announcements without disrupting the service. This way the impact to the local routing tables can be minimized, if necessary. If an autonomous system chooses to drop some or all more specifics, it can still reach the systems by routing to the anycast default. Because a filtering autonomous systems does not reannounce the filtered prefixes to peers, there is no chance to create routing loops: The more specific routing will ignore the filtering autonomous systems at all. Disconnected routing partitions for the more specific prefixes will still work, because the announcing 6to4 router or Teredo relay is always reachable within the partition it spans. Donnerhacke Expires November 27, 2010 [Page 3] Internet Draft Unicast routing for 6to4 May 27, 2010 4. Security Considerations Announcing more specifics of anycast addresses drastically changes the routing system. In order to obtain the same result for the any- cast and the unicast routing, the originating AS for the more spe- cific unicast 6to4 route MUST match the originating AS for the corre- sponding, valid IPv4 route. In order to ease filtering at BGP level, route objects SHOULD NOT be created and maintained by any LIR itself. The RIR allocating the IPv4 address space MUST create an corresponding route object for unicast 6to4 routes on request. More specifics than route for the correspond- ing IPv4 allocate SHOULD NOT be created. 5. IANA Considerations No assignments by the IANA are required. 6. References 6.1. Normative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. 6.2. Informal References [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [I-D.ietf-softwire-ipv6-6rd] Townsley, W. and Troan, O., "IPv6 Rapid Deployment on IPv4 Infrastructures", draft-ietf-softwire-ipv6-6rd (work in progress), May 2010. Donnerhacke Expires November 27, 2010 [Page 4] Internet Draft Unicast routing for 6to4 May 27, 2010 7. Changes history This section will not appear in the final document. It does provide some convenience hints what changed between the document version. It is not complete nor normative. Important differences from 00 to 01: - More specifics for Teredo - Consequences of filtering more specifics in autonomous systems 8. Acknowledgements This proposal was influences by the valuable input of several people from the DENOG group. They convined me to keep this proposal up to date and raised several important questions about the impact to the global routing. Authors' Addresses Lutz Donnerhacke IKS GmbH Leutragraben 1 07743 Jena Germany Tel: +49-3641-573561 (1.6.5.3.7.5.1.4.6.3.9.4.e164.arpa. NAPTR) EMail: lutz@iks-jena.de Donnerhacke Expires November 27, 2010 [Page 5]