Internet Engineering Task Force C. Zhou
Internet-Draft Huawei Technologies
Intended status: Informational T. Tsou
Expires: January 10, 2013 Huawei Technologies (USA)
C. Grundemann
Cablelabs
July 16, 2012
Scenarios of IPv4 sunsetting
draft-zhou-sunset4-scenarios-01
Abstract
This document describes scenarios at subscriber, carrier and
enterprise sites during IPv4 sunsetting. In each site, there may be
different requirements and issues. The aim of this document is to
put forward some issues in these scenarios and to identify whether
further specifications are needed to solve these issues to facilitate
IPv4 sunsetting.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 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
Zhou & Tsou Expires January 10, 2013 [Page 1]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Subscriber Site Scenario . . . . . . . . . . . . . . . . . . . 3
4. Carrier Site Scenario . . . . . . . . . . . . . . . . . . . . . 3
4.1. Traceback . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Stateless CGN . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. High Availability . . . . . . . . . . . . . . . . . . . . . 4
4.4. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Enterprise Site Scenario . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Zhou & Tsou Expires January 10, 2013 [Page 2]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
1. Introduction
There are already a set of documents in IETF which to some extent
facilitate IPv6 transition. For example,
[I-D.ietf-behave-lsn-requirements] describes the common requirements
of CGN (NAT44). For devices which implement NAT, MIB module is
introduced in [I-D.ietf-behave-nat-mib]. However, there are many
scenarios and issues encountered at subscriber, carrier and
enterprise sites, e.g., source trace, high availability, and ALG
issues at carrier site scenario. In this document, these scenarios
will be proposed in detail and some issues in these scenarios will be
discussed.
2. Conventions
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.
3. Subscriber Site Scenario
Some subscribers have the need to run some servers at home, for
example, web server, webcam, FTP server, etc. Sometimes when a
subscriber equipment reboots it may be assigned a new IP address
which is different from the previous one. To accomadate this IP
address change, DDNS is used. If NAT is used in subscribe premise,
static port-forwarding can be configured for a specific service so
that DDNS can continue to work. But if CGN is deployed in the
operator's network, one CGN will serve a lot of users, static port-
forwarding configuration will require a lot of operational work, and
there will be IP address and port conflict if multiple subscribers
require a same purlic IP address and / or port. A traditional
solution is to assign public IP address to scribers who needs to run
a server at home, but this will also require extra operational work,
make the network more complicated. In such a case, a possible
solution is that DDNS system works together with some dynamic NAT
traversal technologies, e.g. UPnP/PCP, or the CGN provide DDNS
proxy.
4. Carrier Site Scenario
For carrier site case, we provide some scenarios and issues as below
for the working group discussion.
4.1. Traceback
Before CGN is introduced, the servers use the source IPv4 address as
an identifier to treat incoming packets differently. When the
Zhou & Tsou Expires January 10, 2013 [Page 3]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
address sharing scheme is proposed, the server could not identify
which host sends the packet because the packets are from the same
source address. [I-D.boucadair-intarea-nat-reveal-analysis] proposed
solutions to identify each host sharing the same IP address with a
unique host identifier. But there are at least two issues existing
in the traceback solutions: logging architecture and port allocation
algorithm.
As described in section 4 of [I-D.ietf-behave-lsn-requirements], the
destination addresses or ports should not be logged in CGN in order
to reduce the logs in CGN. [RFC6302]provides recommendations for
Internet-facing servers logging incoming connections. But it does
not provide any recommendations about logging on carrier-grade NAT.
So, a logging architecture in CGN to maintain records of the relation
between a customer's identity and IP/port resources is needed.
[RFC6431] provides port set options for port range allocation:
contiguous, non-contiguous and random. In the random-based solution,
the algorithm should be reversible in order to trace the host. But
this may bring some security problems.
4.2. Stateless CGN
Carrier-grade NAT44 is one of the solutions to deal with the IPv4
address shortage problem. But the current NAT44 CGN(Carrier-grade
NAT) is stateful and TCP/UDP session based, which makes the CGN
complex. There have been a number of efforts at IETF moving the NAT
function from a stateful carrier grade NAT to the CPEs by allocating
port sets to each customer, e.g., MAP/4RD-U, LAFT6, and etc. There
is also a requirement for NAT44 CGN to become completely stateless.
4.3. High Availability
In most ISP networks, one CGN device may serve large number of
customers. For stateful NAT, if there is a single point of failure
in the CGN, the service may be interrupted or degraded. Therefore,
redundancy capabilities (including hot and cold standby) of the CGN
devices are strongly needed to deliver highly available services to
customers. [I-D.xu-behave-stateful-nat-standby] may be a possible
way to solve this problem. In addition, pre-configuring a pool of
public IPv4 addresses to the CGN device when it is in failure may
also be a candidate solution.
4.4. ALG
Carrier-grade NAT44 performs NAT-44 and inherits the limitations of
NAT. Some protocols require ALGs in the CGN to traverse through the
NAT, e.g., FTP, RTP. However, in most ISP's network, CGN is a shared
Zhou & Tsou Expires January 10, 2013 [Page 4]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
network device which needs to support a large number of sessions. It
is a huge work load for CGN to implement every ALGs, which will
obviously bring bad performance for CGN. How to make CGN more
efficiency under the pressure of ALG becomes an issue. One possible
solution is to let the CPE or host implement ALG instead of CGN, or a
flexible way to make ALG at either CPE or CGN is needed.
5. Enterprise Site Scenario
NAT is a basic feature of enterprise network. The firewall/NAT
device is deployed at the entrance of the enterprise network,
following by the web server and the terminal. Part of the web
servers are required to open publically to provide one domian name
and corresponding IP address (Two ways: the enterprise has its own
DNS server; the enterprise has no DNS server and needs to publicize
one public address). NAT device is required to support this specific
case. In addition, the terminal or the web server following NAT
device need to access Internet. There are requirements for the
enterprise users to record the NAT translation information.
Some basic requirements of NAT device are also valid in enterprise
scenarios, e.g., NAT traceback, port range allocation and NAT
standby. NAT device needs to record the NAT translation log in
traceback solutions. NAT server is required to support port range
allocation. Two NAT devices should store the information of each
other to guarantee normal operation when one device is in failure in
enterprise scenarios.
6. IANA Considerations
No request to IANA.
7. Security Considerations
TBD
Authors' Addresses
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
EMail: cathy.zhou@huawei.com
Zhou & Tsou Expires January 10, 2013 [Page 5]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
EMail: tina.tsou.zouting@huawei.com
Chris Grundemann
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Phone: 303.661.3779
Email: c.grundemann@cablelabs.com
Zhou & Tsou Expires January 10, 2013 [Page 6]
Internet-Draft IPv4 Sunsetting Scenarios July 2012
8. Normative References
[I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata,
I., Miyakawa, S.,
Nakagawa, A., and H.
Ashida, "Common
requirements for Carrier
Grade NATs (CGNs)",
May 2012.
[I-D.ietf-behave-nat-mib] Perreault, S., Tsou, I.,
and S. Sivakumar,
"Additional Definitions
of Managed Objects for
Network Address
Translators (NAT)",
April 2012.
[I-D.boucadair-intarea-nat-reveal-analysis] Boucadair, M., Touch,
J., Levis, P., and R.
Penno, "Analysis of
Solution Candidates to
Reveal a Host Identifier
in Shared Address
Deployments",
September 2011.
[I-D.xu-behave-stateful-nat-standby] Xu, X., Boucadair, M.,
Lee, Y., and G. Chen,
"Redundancy Requirements
and Framework for
Stateful Network Address
Translators (NAT)",
October 2010.