Internet DRAFT - draft-durand-v6ops-v4v6v4nat
draft-durand-v6ops-v4v6v4nat
Internet Engineering Task Force A. Durand
Internet-Draft Comcast
Intended status: Informational November 12, 2007
Expires: May 15, 2008
Non dual-stack IPv6 deployments for broadband providers
draft-durand-v6ops-natv4v6v4-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The common thinking for the last 10+ years has been to say that dual
stack was the answer to v6 transition and that most things would be
converted to dual stack way before we ran out of v4. Well, it has
not happened. We are going to run out of IPv4 addresses soon, way
before any significant IPv6 deployment will have occur. As a result,
broadband deployments now need to contemplate IPv6-only provisioning
and NAT as a classic solution to maintain some form of connectivity
between those environments and the legacy Internet.
Durand Expires May 15, 2008 [Page 1]
Internet-Draft Abbreviated Title November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. IPv4 exhaustion coming sooner than expected . . . . . . . . . . 3
3. Handling the legacy . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Legacy edges of the Internet for broadband customers . . . 3
3.2. Content and Services available on the Internet . . . . . . 4
3.3. Burden on service providers . . . . . . . . . . . . . . . . 4
4. Solution space . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Double IPv4->IPv4->IPv4 NAT . . . . . . . . . . . . . . . . 4
4.3. Double IPv4->IPv6->IPv4 NAT . . . . . . . . . . . . . . . . 5
4.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Durand Expires May 15, 2008 [Page 2]
Internet-Draft Abbreviated Title November 2007
1. Introduction
This memo will present a service provider view on IPv6 deployment and
some of the necessary technologies to achieve it.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. IPv4 exhaustion coming sooner than expected
Global public IPv4 addresses coming from the IANA free pool are
running out faster than predicted a few years ago. The current model
shows that exhaustion could happen as early as 2010. See
http://ipv4.potaroo.net for more details. Those projection ares
based on the assumption that tomorrow is going to be very similar to
today, ie looking at recent address consumption figures is a good
indicator of future consumption patterns. This of course, does not
take into account any new large scale deployment of IP technology or
any human reaction when facing an upcoming shortage.
The prediction of the exact date of exhaustion of the IANA free pool
is outside the scope of this document, however one conclusion must be
drawn from that study: there will be in the near future a point where
new global public IPv4 addresses will not be available and thus any
new broadband deployment may have to consider the option of not
provisioning any IPv4 addresses to the WAN facing interface of edge
devices. The IPv6 deployment model known as "dual stack" can be a
non starter in such environments.
3. Handling the legacy
3.1. Legacy edges of the Internet for broadband customers
Broadband customers have a mix and match of IP enable devices at
home. The most recent operating systems (eg Windows Vista or
MacOS-X) can operate in an IPv6-only environment, however most of the
legacy one can't. It has been reported, for example, that windows XP
cannot process DNS requests over IPv6 transport. Expecting broadband
customers to massively upgrade their software (and in most cases the
corresponding hardware) to deploy IPv6 is a very tall order.
Durand Expires May 15, 2008 [Page 3]
Internet-Draft Abbreviated Title November 2007
3.2. Content and Services available on the Internet
IPv6 deployment has been very long to take off, so the current
situation is that almost none of the content and services available
on the Internet are accessible over IPv6. This will probably change
in the future, but for now, one has to make the assumption that most
of the traffic generated by (and to) broadband customers will be sent
to (and originated by) IPv4 nodes.
3.3. Burden on service providers
As a conclusion, broadband service providers may be faced with the
situation where they have IPv4 customers willing to communicate with
IPv4 servers on the Internet but may not have any IPv4 addresses left
to assign to them...
4. Solution space
A number of solution can be studied in that space: IPv6-only, double
IPv4>IPv4->IPv4 NAT, double IPv4->IPv6->IPv4 NAT, and IPv4 over IPv6
tunneling.
4.1. IPv6-only
The first solution that comes to mind is simply to provision new
broadband customers with only IPv6 addresses. However, two immediate
issues come to mind:
a. Legacy devices in the customer home will not be able to
communicate with the outside.
b. New IPv6-only capable devices will not be able to communicate
with legacy IPv4-only servers in the Internet.
4.2. Double IPv4->IPv4->IPv4 NAT
This solution consists of provisioning broadband customers with a
private [RFC1918] address on the WAN side of the home gateway, and
then translate this private IPv4 address somewhere within the service
provider network into a global IPv4 address. Devices behind the home
gateway will then be translated twice, once by the home gateway
itself, and another time by the NAT within the service provider.
This solution has the advantage of reducing the total number of
global IPv4 addresses needed by consolidating the traffic of multiple
customers on a unique IPv4 addresses. The first drawback is that
some applications may have a more difficult time going through two
Durand Expires May 15, 2008 [Page 4]
Internet-Draft Abbreviated Title November 2007
levels of NAT. Another drawback that can be a show stopper is that
this solution limits the number of customer within an access network
to the size of net 10, ie somewhere between 10 and 16 million
depending on address efficiency. Note that very large networks such
as Comcast have already ran out of RFC1918 space a few years ago.
4.3. Double IPv4->IPv6->IPv4 NAT
When private address space is running out as well, the next step is
to have the home gateway translate internal RFC1918 space into global
IPv6 addresses. However, as the final destination may not be
configured with IPv6, those packets will have to be translated a
second time into IPv4 packets. This second translation will have to
occur within the service provider network.
The implications of this second level of translation is very similar
to those in the model above of a double IPv4->IPv4->IPv4 translation.
There will be a need for a far of translator within the service
provider network operating at line speed. Some applications may have
a harder time working through a second level of NAT. On top of that,
some MTU adaptation will have to take place to accommodate for the
longer IPv6 header.
4.4. Tunneling
When IPv6-only connectivity is offered to the customer, one could be
tempted to look at IPv4 over IPv6 tunnels to re-establish
connectivity for the legacy IPv4 hosts. The Softwire hub and spoke
solution, based on L2TP tunnels could be the perfect candidate in
that space.
However, the main drawback of that solution is that it would require
an IPv4 address to be configured on that tunnel. More, that address
could not be shared among subscribers. As such, this solution would
not consume less IPv4 addresses than a regular dual-stack deployment
and will be be a non starter in environment where IPv4 addresses are
rare.
5. Acknowledgements
Send the author comments if you want your name listed here.
6. IANA Considerations
This memo includes no request to IANA.
Durand Expires May 15, 2008 [Page 5]
Internet-Draft Abbreviated Title November 2007
This draft does not request any IANA action.
7. Security Considerations
Security issues associated with NAT have long been documented. A
future version of this document may include some references here to
previous work.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Alain Durand
Comcast
1500 Market st
Philadelphia, PA 19102
USA
Email: alain_durand@cable.comcast.com
Durand Expires May 15, 2008 [Page 6]
Internet-Draft Abbreviated Title November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Durand Expires May 15, 2008 [Page 7]
