wdiff rfc5569.original rfc5569.txt

Internet Engineering Task Force
Network Working Group R. Despres

Intended status:
Request for Comments: 5569 RD-IPtech
Category: Informational
Expires: October 9, May 2009

IPv6 Rapid Deployment on IPv4 infrastructures Infrastructures (6rd)
draft-despres-6rd-03

Status of this 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 memo provides information for 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. community. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list does
not specify an Internet standard of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list any kind. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 9, 2009. this
memo is unlimited.

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.

IESG Note

This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.

Abstract

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon
mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy
IPv6 unicast service to IPv4 sites to which it provides customer
premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4
encapsulation in order to transit IPv4-only network infrastructure.
Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in
place of the fixed 6to4 prefix. A service provider has used this
mechanism for its own IPv6 "rapid deployment": five weeks from first
exposure to 6rd principles to more than 1,500,000 residential sites
being provided native IPv6, under the only condition that they
activate it.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Problem statement Statement and purpose Purpose of 6rd . . . . . . . . . . . . . 5 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 . 5
4. Applicability to ISPs that assign private That Assign Private IPv4 addresses Addresses . . . 8 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 9

1. Introduction

After having had a succinct presentation of the 6rd idea, a major
French Internet service provider (ISP), Free of the Iliad group, group
(hereafter Free), did all of the following in an impressively short
delay of only five weeks (November 7th to December 11th 2007):

1. obtain its first IPv6 prefix obtained from its regional Internet Registry
(RIR), its length being 32 (RIR) an IPv6
prefix, the length that of which was that allocated without a
justification and a delay to examine it; it, namely /32;

2. add added 6rd support to the software of its Freebox home-gateway
(upgrading for this an available 6to4 code);

3. provision provisioned PC-compatible platform with a 6to4 gateway software;

4. modify modified it to support 6rd;

5. test tested IPv6 operation with several operating systems and
applications;

6. finish finished operational deployment, by means of new version of the
downloadable software for of their Freeboxes;

7. announce announced IPv6 Internet connectivity, at no extra charge, for all
its customers wishing to activate it.

More than 1,500,000 residential customers thus became able to use
IPv6 if they wished to, wished, with all the look and feel of native IPv6
addresses routed in IPv6. The only condition was an activation of
IPv6 in their Freeboxes, and of course in their IPv6 capable IPv6-capable hosts.

This story is reported to illustrate that ISPs that provide customer
premise equipment (CPE) to their customers clients, with included routing capability (router
CPEs),
capability, and that have so far postponed IPv6 deployment can, with
the dramatically reduced investment and operational costs that 6rd
make possible, decide to wait no longer.

To complete the story, Free announced, on March 6th 2008, that
provided two of its customer sites had IPv6 activated, its Telesites
application (Web sites published on TV) could now be used remotely
between them.

While IPv6 availability was limited in december December 2007 to only one IPv6
link per customer site (with /64 site prefix assignments), it was
upgraded a site-prefix assignments). A few
months later to up to 16 IPv6 links (with /60 site
prefix assignments), later, after Free had detailed its achievement and plans to
its RIR RIR, and then obtained from it a /26 prefix. prefix, up to 16 IPv6 links
per customer became possible (with /60 site-prefix assignments).

Readers are supposed to be familiar with 6to4 [RFC3056].

2. Problem statement Statement and purpose Purpose of 6rd

Having ISPs to rapidly bring IPv6 to customers customers' sites, in addition to
IPv4 and without extra charge, is a way to break the existing vicious
circle that has delayed IPv6 deployment: ISPs wait for customer
demand before deploying IPv6; customers don't demand IPv6 as long as
application vendors announce that their products work on existing
infrastructures (that are IPv4 with NATs); application vendors focus
their investments on NAT traversal compatibility as long as ISPs
don't deploy IPv6.

But most ISPs are not willing to add IPv6 to their current offer, offer at
no charge, charge unless incurred investment and operational costs are
extremely limited. For this, ISPs that provide router CPEs to their
customers have the most favorable conditions: they can upgrade their
router CPEs to support IPv6 encapsulation and can operate gateways between these their IPv4
infrastructures and the global IPv6 Internet to also do
IPv6/v4 encapsulation, so that they can keep the support IPv6
encapsulation in IPv4. They then need no more routing plan of
their plans than
those that exist on these IPv4 infrastructures.

Encapsulation a la 6to4 6to4, as specified in [RFC3056], is very close to be
being sufficient for this: it is simple; it is supported on many
platforms including PC compatible PC-compatible appliances; open-source portable
code is available; its stateless nature ensures good scalability.

There is however a limitation of 6to4 that prevents ISPs to use from using
it to offer full IPv6 unicast connectivity to their customers. While
an ISP that deploys 6to4 can guarantee that IPv6 packets outgoing
from its customer sites will reach the IPv6 Internet, and also
guarantee that packets coming from other 6to4 sites will reach its
customer sites, it cannot guarantee that packets from native IPv6
sites will reach them. A The problem is that a packet coming from a
native IPv6 address needs to traverse, somewhere on its way, a 6to4
relay router to do the required IPv6/IPv4 encapsuation. The problem is that there encapsulation. There is no
guarantee to
have a route that routes toward such a relay exist from everywhere, nor
is there a guarantee that all such relays do forward packets toward
the complete IPv4 Internet.

An ISP,

Also, if it an ISP operates one or several 6to4 relay routers and opens
IPv6 routes toward them on in the IPv6 Internet Internet, for the 6to4 prefix
2002::/16, it may receive in these relays packets destined to an
unknown number of other 6to4 ISPs. If it doesn't forward them, these
packets, it creates a black hole in which packets may be
systematically lost, breaking some of the IPv6 connectivity. If it
does forward them, it can no longer dimension its 6to4 relay routers
in proportion to the traffic of its own customers. Quality of
service, at least for customers of other 6to4 ISPs, will then hardly
be guaranteed.

The purpose of 6rd is to slightly modify 6to4 so that:

1. Packets that, coming from the global Internet, enter 6rd gateways
of an ISP are only packets destined to customer sites of this
ISP.

2. All IPv6 packets destined to 6rd customer sites of an ISP, and
coming from anywhere else on the IPv6 Internet, traverse a 6rd
gateway of this ISP.

3. Specification

The principle of 6rd is that, to build on 6to4 and suppress its
limitation, it is sufficient that:

1. 6to4 functions are modified to replace the standard 6to4 prefix
2002::/16 by an IPv6 prefix that belongs to the ISP assigned ISP-assigned
address space, and to replace the 6to4 anycast address by another
anycast address chosen by the ISP.

2. The ISP operates one or several 6rd gateways (upgraded 6to4
routers) at its border between its IPv4 infrastructure and the
IPv6 Internet.

3. CPE routers are CPEs support IPv6 on their customer-site side and support 6rd
(upgraded 6to4 function). function) on their provider side.

Figure 1 shows how the IPv6 prefix of a customer site is derived from
its IPv4 address.

+---------------//-------.------------------------------+
| 6rd-relays IPv6 prefix | IPv4 address |
| of the ISP | of the customer site |
+---------------//-------'------------------------------+
<-- less or equal to 32 -><------------ 32 ------------->
<-- less or equal to 64 ------------------------------->

FORMAT OF THE IPV6 PREFIX ASSIGNED TO A 6rd CUSTOMER SITE

Figure 1
The chosen address format uses 32 bits

Format of IPv4 address within the IPv6 address for reasons of simplicity and of compatibility with the
existing 6to4 code. Free's customers being essentially residential,
limiting initially their sites Prefix Assigned to one IPv6 subnet per site was not a
significant restriction: most of them would not 6rd Customer Site

Figure 1

Figure 2 shows which nodes have been able to use
several subnets anyway; as soon as Free would get shorter a prefix
than /32, this restriction could be relaxed. upgraded from 6to4 to 6rd, and
which addresses or prefixes have to be routed to them.

IPv4 AND IPv6 customer site
|
| 6rd CPEs 6rd relays
| (modified 6to4) (modified 6to4)
| | |
| | __________________________ |
| | | | |
| | | ISP IPV4 INFRASTRUCTURE | V GLOBAL
V V | | ___ IPV6
___ | | | | INTERNET
| | | | .-----------------|--| |---
|--| |--|-. / | |___|
| |___| | \ / |
| \ / IPv4 | IPv6 Prefix
| O anycast address => | <= of 6rd relays
| ___ | / \ of 6rd relays | of the ISP
| | | | / \ | ___
|--| |--|-' \ | | |
| |___| | '-----------------|--| |---
| | | |___|
| IPv4 addresses |
| <= of customer sites |
|__________________________|

ISP ARCHITECTURE TO DEPLOY IPV6 WITH Architecture to Deploy IPv6 with 6rd

Figure 2

NOTE: The chosen address format uses 32 bits of IPv4 addresses in
IPv6 addresses for reasons of simplicity and of compatibility with
the existing 6to4 code. Limiting initially Free's customer sites to
one IPv6 subnet per site, a consequence of Free's initial prefix
being a /32, was not a significant restriction: since Free's
customers are essentially residential, most of them would have been
unable to use several subnets anyway, and as soon as Free would get a
prefix shorter than /32, this restriction would be relaxed. If it
had been important to immediatly use less than 32 bits of IPv4
addresses in IPv6 prefixes, this would have been possible. Since
Free, like many ISPs, had several RIR allocated RIR-allocated IPv4 prefixes (6 of
them, having lengths from /10 to /16 in the particular case), 6rd
gateways and 6rd CPEs would however have had could for this to support a
variable length have implemented variable-length
mapping table. Some But some of the IPv4 addressing entropy would thus
have been extended to 6rd gateways and CPEs, and
complexity would have been CPEs. Complexity being then
significantly higher. This higher, this would have defeated the objective of
extreme simplicity to favor actual and rapid deployment.

Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and
which addresses or prefixes have to be routed to them.

IPv6 communication between customer sites of a same ISP is direct
across the ISP IPv4 infrastructure: when a CPE sees that the IPv6
destination address of an outgoing packet starts with its own 6rd
relay ISPv6 prefix, it takes the 32 bits that follow this prefix as
IPv4 destination of the encapsulating packet. (Sending and
decapsulation rules of 6to4, duly adapted to the 6rd prefix in place
of the 6to4 prefix, apply as described in [RFC3056] section 5.3.) Section 5.3 of [RFC3056].)

The IPv4 anycast address of 6rd relays may be chosen independently by
each ISP. The only constraint is that routes toward the ISP that are
advertised must not include this address. For example, Free took a
192.88.99.k
192.88.99.201 address, routed with the same /24 prefix as 6to4 but
with
k different from 201 instead of 1 to avoid confusion with 192.88.99.1, the 6to4
anycast address of [RFC3068]. Another possibility is possibility, not retained,
would have been to use the anycast address of 6to4 and to add, in
relays, a test on the IPv6 prefix of the ISP side ISP-side address. If it is
starts with 2002::/16, the packet is 6to4, not 6rd.

4. Applicability to ISPs that assign private That Assign Private IPv4 addresses Addresses

______________________________
| |
| 10.x.x.x/8 private addresses |
| <== |
<-----| IPv4 Anycast anycast address |----->
| of 6rd relays |
6rd-CPEs | ==> | 6rd-relays
| |
<-----| 0.0.0.0/0 |----->
| : |
|______________V_______________|
__|__
ISP-supported NAT(s) | |
|_____|
|
V
IPv4 public addresses

6rd APPLICABILITY TO Applicability to ISPs THAT ASSIGN IPV4 PRIVATE ADDRESSES That Assign IPv4 Private Addresses

Figure 3

Free currently offers a global IPv4 address to each of its
subscribers, which ensures that all IPv4-derived prefixes using 6rd
are unique. Service providers may no longer have this luxury as
available global IPv4 addresses become more and more scarce. This
section describes how 6rd could be used by a service provider who
cannot provide global IPv4 addresses to each subscriber.

If an ISP has assigned to customer sites addresses of an IPv4 private
space of [RFC1918], typically 10.x.x.x/8 10.x.x.x addresses, it can also use 6rd
to offer IPv6 to these sites.

IPv4 packets that contain IPv6 packets don't go to NATs which that this ISP
needs to operate in its infrastructure: they go directly to 6rd
relays because their destination is the 6rd relay anycast address.

Note

It can be noted that in this case case, the 10.0.0.0/8 prefix is common to
all IPv4 addresses of the addressing realm domain in which 6rd is used.
Knowing it, gateways and CPE can CPEs could avoid including this constant
IPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number of
bits of IPv4 addresses to be used that are included in IPv6 prefixes.

If prefixes (but this
was not applicable to Free).

It can also be noted that, if an ISP is large enough to provide
service to more IPv4 endpoints than will fit inside a 10.x.x.x/8 single
10.0.0.0/8 addressing realm, domain, it can configure several such realms, domains,
with 6rd-relay IPv6 prefixes specific of each one. Each of these
prefixes is then the RIR allocated RIR-allocated ISP prefix followed by an ISP assigned realm identifier. a domain
identifier chosen by the ISP.

5. Security Considerations

Security considerations for 6to4 are documented in [RFC3964]. With
the restriction imposed by 6rd that relays of an ISP deal only with
traffic that belongs to that ISP, checks that have to be done become
the following:

o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the
IPv6 destination must no not be, a 6rd address of the site.

o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd
address that matches the IPv4 source. The IPv6 destination must
not start with the ISP 6rd prefix.

o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd-
relays
relay's anycast address of the local ISP, the IPv6 source must not
be a 6rd address of this ISP. Otherwise, the IPv6 source must be
the 6rd address that matches the IPv4 source. source (is the IPv6 prefix
of 6rd relays of the ISP followed by the IPv4 address).

o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd
address of the ISP. The IPv4 destination must not be multicast,
i.e.
i.e., must not start with 224/3. (Notes: The fact that the IPv6
destination starts with the IPv6 prefix of the ISP 6rd relays is
ensured by the routing configuration, but may be double-checked.
If the IPv4 address extracted from the IPv6 destination doesn't
belong to the ISP, the destination CPE should detect that the IPv6
destination contains neither its ISP 6rd prefix, if it has one,
nor the 6to4 prefix, and should discard the packet.)

These precautions being taken, it

It remains that, that where IPv4 address spoofing is possible (IPv4 sites
placing unauthorized source addresses in some packets they send),
IPv6 address spoofing is also
possible. possible, independently of the above
precautions.

6. IANA Considerations

ISPs that provide CPEs to all their customers need no new number
assignment by IANA. Their being allocated an IPv6 prefix by their
RIR, /32 or shorter, is sufficient.

For 6rd to be also used in the future by ISPs that let customers have
their own CPEs, means to communicate 6rd parameters to these CPEs are
would be needed.
For If the IETF specifies such means for this, some
number assignment by IANA has is likely to be solicited, in a registry to eventually
be involved." then defined.

7. Acknowledgements

The author warmly acknowledges the major contribution of Rani Assaf
to 6rd's proven credibility. He readily appreciated 6rd's potential,
and made the daring decision to rapidly immediately implement it and deploy it for a very
rapid deployment on Free's operational network.

Mark Townsley, Brian Carpenter and Patrick Grossetete have to be
thanked for their encouragements encouragements, and for their suggestions as to on how to
proceed for 6rd to be known in the IETF.

Acknowledgments are also due to some IPv6 old timers, in particular
Laurent Toutain, Francis Dupont Dupont, and Alain Durand, who, when the
author came as a late novice on IPV6, taught him a few subtleties of
the subject. Without them, designing 6rd would probably not have
been possible.

8. References

8.1. Normative References

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

8.2. Informative References

[IPv4 addresses]
Internet Assigned Numbers Authority, "Internet Protocol v4
Address Space - http://www.iana.org/assignments/
ipv4-address-space/ipv4-address-space.xhtml",
February 2008.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.

[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.

[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.

Author's Address

Remi Despres
RD-IPtech
3 rue du President Wilson
Levallois,
France

Phone: +33 6 72 74 94 88
Email:
EMail: remi.despres@free.fr