Internet Draft L. Donnerhacke Category: Proposed Standard IKS GmbH Expires: May 26, 2010 November 26, 2009 More specific unicast routing for 6to4 draft-donnerhacke-softwire-ipv6-6to4-00.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 May 26, 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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 routing by defining the global anycast route 2002::/16 as a route of last resort. More specific unicast routes might be allowed in order to create a more stable environment. Donnerhacke Expires May 26, 2010 [Page 1] Internet Draft Unicast routing for 6to4 November 26, 2009 Table of Contents 1. Introduction .................................................. 2 2. Allowing more specific unicast routes ......................... 2 3. Rationale ..................................................... 3 4. Security Considerations ....................................... 3 5. IANA Considerations ........................................... 3 6. References .................................................... 4 6.1. Normative References ..................................... 4 6.2. Informal References ...................................... 4 1. Introduction 6to4 [RFC3056] defines a successful technology to connect IPv6 net- works over legacy only backbones. By allowing large ISPs to announce a more specific of the default anycast route, the operational domain of unicast 6to4 is extended from the SP network under its direct con- trol to the global network. From the perspective of customer sites and the IPv6 Internet at large connected to the 6to4 SP network, the IPv6 service provided is equivalent to native IPv6. 2. Allowing more specific unicast routes 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 prop- agated 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. Donnerhacke Expires May 26, 2010 [Page 2] Internet Draft Unicast routing for 6to4 November 26, 2009 3. Rationale Several 6to4 routers out there are broken and nobody cares about fixing them. There is not enough 6to4 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 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 oper- ators to drop routing announcements without disrupting the ser- vice. This way the impact to the local routing tables can be mini- mized, if necessary. 4. Security Considerations Announcing more specifics drastically changes the routing system. In order to obtain the same result for the anycast and the unicast routing, the originating AS for the more specific unicast 6to4 route MUST match the originating AS for the corresponding, 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 corresponding IPv4 allocate SHOULD NOT be created. 5. IANA Considerations No assignments by the IANA are required. Donnerhacke Expires May 26, 2010 [Page 3] Internet Draft Unicast routing for 6to4 November 26, 2009 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. [I-D.ietf-softwire-ipv6-6rd] Townsley, W. and Troan, O., "IPv6 via IPv4 Service Provider Networks", draft-ietf-softwire-ipv6-6rd (work in progress), October 2009. 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 May 26, 2010 [Page 4]