draft-ietf-intarea-shared-addressing-issues-04.txt   draft-ietf-intarea-shared-addressing-issues-05.txt 
Internet Engineering Task Force M. Ford, Ed. Internet Engineering Task Force M. Ford, Ed.
Internet-Draft Internet Society Internet-Draft Internet Society
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: August 26, 2011 France Telecom Expires: September 4, 2011 France Telecom
A. Durand A. Durand
Juniper Networks Juniper Networks
P. Levis P. Levis
France Telecom France Telecom
P. Roberts P. Roberts
Internet Society Internet Society
February 22, 2011 March 03, 2011
Issues with IP Address Sharing Issues with IP Address Sharing
draft-ietf-intarea-shared-addressing-issues-04 draft-ietf-intarea-shared-addressing-issues-05
Abstract Abstract
The completion of IPv4 address allocations from IANA and the RIRs is The completion of IPv4 address allocations from IANA and the RIRs is
causing service providers around the world to question how they will causing service providers around the world to question how they will
continue providing IPv4 connectivity service to their subscribers continue providing IPv4 connectivity service to their subscribers
when there are no longer sufficient IPv4 addresses to allocate them when there are no longer sufficient IPv4 addresses to allocate them
one per subscriber. Several possible solutions to this problem are one per subscriber. Several possible solutions to this problem are
now emerging based around the idea of shared IPv4 addressing. These now emerging based around the idea of shared IPv4 addressing. These
solutions give rise to a number of issues and this memo identifies solutions give rise to a number of issues and this memo identifies
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2011. This Internet-Draft will expire on September 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 28 skipping to change at page 5, line 28
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64 Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate],
Address+Port (A+P) proposals [I-D.ymbk-aplusp], Address+Port (A+P) proposals [I-D.ymbk-aplusp],
[I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26 [I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26
provides a classification of these different types of solutions and provides a classification of these different types of solutions and
discusses some of the design considerations to be borne in mind when discusses some of the design considerations to be borne in mind when
deploying large-scale address sharing. Whether we're talking about deploying large-scale address sharing. Whether we're talking about
DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view
from the outside that matters, and given that, most of the issues from the outside that matters, and given that, most of the issues
identified below apply regardless of the specific address sharing identified below apply regardless of the specific address sharing
scenario in question. Issues specific to A+P proposals are addressed scenario in question.
in [I-D.thaler-port-restricted-ip-issues].
In these new proposals, a single public IPv4 address would be shared In these new proposals, a single public IPv4 address would be shared
by multiple homes or small businesses (i.e., multiple subscribers) so by multiple homes or small businesses (i.e., multiple subscribers) so
the operational paradigm described above would no longer apply. In the operational paradigm described above would no longer apply. In
this document we refer to this new paradigm as large-scale address this document we refer to this new paradigm as large-scale address
sharing. All these proposals extend the address space by adding port sharing. All these proposals extend the address space by adding port
information, they differ in the way they manage the port value. information, they differ in the way they manage the port value.
Security issues associated with NAT have long been documented (see Security issues associated with NAT have long been documented (see
[RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across [RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across
skipping to change at page 22, line 18 skipping to change at page 22, line 18
would be for a 6to4 IPv6 address to embed not only an IPv4 address would be for a 6to4 IPv6 address to embed not only an IPv4 address
but also a port range value. but also a port range value.
Subscribers allocated with private addresses will not be able to Subscribers allocated with private addresses will not be able to
utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize
Teredo [RFC4380]. Teredo [RFC4380].
Some routers enable 6to4 on their WAN link. 6to4 requires a publicly- Some routers enable 6to4 on their WAN link. 6to4 requires a publicly-
routable IPv4 address. Enabling 6to4 when the apparently public IPv4 routable IPv4 address. Enabling 6to4 when the apparently public IPv4
WAN address is in fact behind a NAT creates a disconnected IPv6 WAN address is in fact behind a NAT creates a disconnected IPv6
island. Issues created by assigning the same public address space island.
across multiple hosts are specifically addressed in
[I-D.thaler-port-restricted-ip-issues].
18. Introduction of Single Points of Failure 18. Introduction of Single Points of Failure
In common with all deployments of new network functionality, the In common with all deployments of new network functionality, the
introduction of new nodes or functions to handle the multiplexing of introduction of new nodes or functions to handle the multiplexing of
multiple subscribers across shared IPv4 addresses could create single multiple subscribers across shared IPv4 addresses could create single
points of failure in the network. Any IP address sharing solution points of failure in the network. Any IP address sharing solution
should consider the opportunity to add redundancy features in order should consider the opportunity to add redundancy features in order
to alleviate the impact on the robustness of the offered IP to alleviate the impact on the robustness of the offered IP
connectivity service. The ability of the solution to allow hot connectivity service. The ability of the solution to allow hot
skipping to change at page 26, line 42 skipping to change at page 26, line 42
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010. progress), July 2010.
[I-D.ietf-pcp-base] [I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F. Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F.
Dupont, "Port Control Protocol (PCP)", Dupont, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-05 (work in progress), February 2011. draft-ietf-pcp-base-06 (work in progress), February 2011.
[I-D.ietf-softwire-dual-stack-lite] [I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010. in progress), August 2010.
[I-D.shirasaki-nat444] [I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011. in progress), January 2011.
[I-D.thaler-port-restricted-ip-issues]
Thaler, D., "Issues With Port-Restricted IP Addresses",
draft-thaler-port-restricted-ip-issues-00 (work in
progress), February 2010.
[I-D.ymbk-aplusp] [I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage", Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-09 (work in progress), February 2011. draft-ymbk-aplusp-09 (work in progress), February 2011.
[IANA_Ports] [IANA_Ports]
Geoff Huston, "IANA Port Number Assignments", Geoff Huston, "IANA Port Number Assignments",
February 2011, February 2011,
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[IPv4_Pool] [IPv4_Pool]
skipping to change at page 29, line 7 skipping to change at page 28, line 51
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
January 2011. January 2011.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD) V 2.0", December 2010, Gateway Device (IGD) V 2.0", December 2010,
<http://upnp.org/specs/gw/igd2/>. <http://upnp.org/specs/gw/igd2/>.
[Windows-Logo] [Windows-Logo]
Microsoft, "Windows Logo Program Device Requirements", Microsoft, "Windows Logo Program Device Requirements",
2006, <http://www.microsoft.com/whdc/winlogo/ 2006, <http://www.microsoft.com/whdc/winlogo/
hwrequirements/default.mspx>. hwrequirements/default.mspx>.
Authors' Addresses Authors' Addresses
Mat Ford (editor) Mat Ford (editor)
 End of changes. 9 change blocks. 
16 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/