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]