One document matched: draft-lee-softwire-dslite-deployment-00.txt
Softwire Y. Lee
Internet-Draft Comcast
Intended status: Informational R. Maglione
Expires: April 18, 2011 Telecom Italia
C. Williams
MCSR Labs
C. Jacquenet
M. Boucadair
France Telecom
October 15, 2010
Deployment Considerations for Dual-Stack Lite
draft-lee-softwire-dslite-deployment-00
Abstract
This document discusses the deployment issues and describes
requirements for the deployment and operation of Dual-Stack Lite.
This document describes the various deployment scenarios and
applicability of the Dual-Stack Lite protocol.
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 April 18, 2011.
Copyright Notice
Copyright (c) 2010 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
Lee, et al. Expires April 18, 2011 [Page 1]
Internet-Draft Deployment Considerations for DS-Lite October 2010
carefully, as they describe your rights and restrictions with respect
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AFTR Deployment Considerations . . . . . . . . . . . . . . . . 3
2.1. MTU Considerations . . . . . . . . . . . . . . . . . . . . 3
2.2. Lawful Intercept Considerations . . . . . . . . . . . . . 4
2.3. Logging at the AFTR . . . . . . . . . . . . . . . . . . . 4
2.3.1. AFTR's Policies . . . . . . . . . . . . . . . . . . . 5
2.4. AFTR Impacts on Internal Accounting Systems . . . . . . . 5
2.4.1. AFTR Impacts on Accounting Process in Broadband
Access . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Reliability Considerations of AFTR . . . . . . . . . . . . 6
2.6. Strategic Placement of AFTR . . . . . . . . . . . . . . . 6
2.7. AFTR Considerations for Geographically Aware Services . . 7
2.8. Impacts on QoS . . . . . . . . . . . . . . . . . . . . . . 7
2.9. Port Forwarding Considerations . . . . . . . . . . . . . . 7
3. B4 Deployment Considerations . . . . . . . . . . . . . . . . . 7
3.1. DNS deployment Considerations . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Lee, et al. Expires April 18, 2011 [Page 2]
Internet-Draft Deployment Considerations for DS-Lite October 2010
1. Overview
Dual-stack Lite (DS-Lite) [I-D.ietf-softwire-dual-stack-lite] is a
transition technique that enable operators to multiplex public IPv4
addresses while provisioning only IPv6 to users. DS-Lite is designed
to address the IPv4 depletion issue and allow the operators to
upgrade their network incrementally to IPv6. DS-Lite combines IPv4-
in-IPv6 tunnel and NAT44 to share a public IPv4 address more than one
user. This document discusses various deployment considerations for
DS-Lite by operators.
2. AFTR Deployment Considerations
Address Family Transition Router (AFTR) is the function deployed
inside the operator's network. AFTR can be a standalone device or
embedded into a router. AFR is the IPv4-in-IPv6 tunnel termination
point and the NAT44 device. It is deployed at the IPv4-IPv6 network
border where the tunnel interface is IPv6 and the NAT interface is
IPv4. Although an operator can configure a dual-stack interface for
both functions, we strongly recommended to configure two individual
interfaces (i.e. one dedicated for IPv4 and one dedicated for IPv6)
to segregate the functions.
In this section, the deployment considerations for AFTR are
described.
2.1. MTU Considerations
DS-Lite is part tunneling protocol. Tunneling introduces some
additional complexity and has a risk of MTU or other mis-
configurations. With tunneling comes additional header overhead that
implies that the tunnel's MTU is smaller than the raw interface MTU.
The second problem is that between the B4 and AFTR networking
entities there may exist further tunnels inside tunnel, so that the
tunnel ingress is not necessarily aware of the true tunnel MTU. The
third problem is that the routing of the interior of the tunnel may
change, so that the tunnel MTU may be variable. The issue that the
end user will experience is that they cannot download Internet pages
or transfer files using File Transfer Protocol (FTP) but may be able
to ping successfully.
For fragmentation problem shares among all the tunneling protocols,
this is not unique to DS-Lite. The IPv4 packet isn't over-sized, it
is the v6 encapsulation that MAY cause the oversized issue. So the
tunnel points are responsible to handle the fragmentation. In
general, the Tunnel-Entry Point and Tunnel-Exist Point should
fragment and reassemble the oversize datagram. This mechanism is
Lee, et al. Expires April 18, 2011 [Page 3]
Internet-Draft Deployment Considerations for DS-Lite October 2010
transport protocol agnostic and work for both UDP and TCP. For TCP,
we could potentially avoid fragmentation by modify MSS option. The
B4 networking component may send an ICMP Destination Unreachable-
Fragmentation Needed and DF Set message back to the sending host in
the subscriber network.
2.2. Lawful Intercept Considerations
Because of its IPv4-in-IPv6 tunneling scheme, interception in DS-Lite
architecture must be performed on the AFTR itself. Timestamped
logging of the address and port mappings at the AFTR must be
maintained, which in turn can add a heavy resource burden to the AFTR
devices.
Logging to a storage device off the AFTR may also contribute to
network load. Wiretapping of a single subject may mean statically
mapping the user to a certain range of ports on a single address, to
remove the need to follow dynamic port mappings. A single IPv4
address, or some range of ports for each address, might be set aside
for wiretapping purposes to simplify such procedures. But any
requirement that users behind a given AFTR be logged is going to mean
logging not only traffic but all changes to the mapping tables.
2.3. Logging at the AFTR
The timestamped logging of address and port mappings is essential not
only for lawful intercept but also for tracing back specific users
when a problem is identified from the outside of the AFTR. Such a
problem is usually a misbehaving user in the case of a spammer or a
DoS source, or someone violating a usage policy. Knowing the user
may result in black-listing. Without time-specific logs of the
address and port mappings, a misbehaving user stays well hidden
behind the AFTR.
Blacklisting might restrict others in the home or office from
accessing the website but altogether few innocent bystanders are
affected. What happens, though, if a website bans an IPv4 address on
the outside of an AFTR? In the effort to restrict a single user,
hundreds of people may be inadvertently restricted generally all
subscribers on a CMTS or a group of BNASes behind the AFTR.
Black- or white-listing may need to be split in an AFTR architecture.
Polices applying to incoming sources must be implemented on the
outside of the AFTR. Once the packets are translated, they cannot be
easily identified by IPv4 address without some correlation with the
AFTR mapping table.
Lee, et al. Expires April 18, 2011 [Page 4]
Internet-Draft Deployment Considerations for DS-Lite October 2010
2.3.1. AFTR's Policies
Polices applying on the NAT-ed addresses must be implemented on the
external interface of the AFTR. Once the packets are translated,
they cannot be easily identified by IPv4 address without some
correlation with the AFTR mapping table. Policies applying to
outgoing sources must be implemented on the customer-facing side of
the AFTR for the same reason. In order to be able to deploy
different services offers, multiple set of policies (e.g. QoS and
ACL settings) can be configured on the AFTR: each set of policies can
then be applied to a different logical tunnel interface on the ATFR.
2.4. AFTR Impacts on Internal Accounting Systems
Single points of failure, potential address pool depletion attacks,
performance and scalability, effects on fragmented packets, effects
on asymmetric traffic flows, required modifications to provisioning
systems, required modifications to internal accounting systems.
2.4.1. AFTR Impacts on Accounting Process in Broadband Access
DS-Lite introduces challenges to IPv4 accounting process. In a
typical DSL/Broadband access scenario where the Residential Gateway
(RG) is acting as a B4 element, the BNAS is the IPv6 edge router
which connects to the AFTR. The BNAS is normally responsible for
IPv6 accounting and all the subscriber manager functions such as
authentication, authorization and accounting. However, given the
fact that IPv4 traffic is encapsulated into an IPv6 packet at the B4
level and only decapsulated at the ATFR level, the BNAS can't do the
IPv4 accounting without examining the inner packet. AFTR is the next
logical place to perform IPv4 accounting, but it will potentially
introduce some additional complexity because the AFTR does not have
detailed customer identity information.
The accounting process at the AFTR level is only necessary if the
Service Provider requires separate per user accounting records for
IPv4 and IPv6 traffic. If the per user IPv6 accounting records,
collected by the BNAS, are sufficient, the additional complexity to
be able to implement IPv4 accounting at the ATFR level is not
required. It is important to consider that, since the IPv4 traffic
is encapsulated in IPv6 packets, the data collected by the BNAS for
IPv6 traffic already contain the total amount of traffic (i.e. IPv6
plus IPv4).
Even if detailed accounting records collection for IPv4 traffic may
not be required, in some scenarios it would be useful for a Service
Provider, to have inside the RADIUS Accounting packet, generated by
the BNAS for the IPv6 traffic, a piece of information that can be
Lee, et al. Expires April 18, 2011 [Page 5]
Internet-Draft Deployment Considerations for DS-Lite October 2010
used to identify the AFTR that is handling the IPv4 traffic for that
user. This can be achieved by adding into the IPv6 accounting
records the RADIUS attribute information specified in
[I-D.ietf-softwire-dslite-radius-ext]
2.5. Reliability Considerations of AFTR
The service provider can use techniques to achieve high availability
such as various types of clusters to ensure availability of the IPv4
service. High availability techniques include the cold standby mode.
In this mode the AFTR states are not replicated from the Primary AFTR
to the Backup AFTR. When the Primary AFTR fails, all the existing
established sessions will be flushed out. The internal hosts are
required to re-establish sessions to the external hosts. Another
high availability option is the hot standby mode. In this mode the
AFTR keeps established sessions while failover happens. AFTR states
are replicated from the Primary AFTR to the Backup AFTR. When the
Primary AFTR fails, the Backup AFTR will take over all the existing
established sessions. In this mode the internal hosts are not
required to re-establish sessions to the external hosts. The final
option is to deploy a mode in between these two whereby only selected
sessions such as critical protocols are replicated. Criteria for
sessions to be replicated on the backup would be explicitly
configured on the AFTR devices of a redundancy group.
2.6. Strategic Placement of AFTR
The public IPv4 addresses are pulled away from the customer edge to
the outside of the centralized AFTR where many customer networks can
share a single public IPv4 address.
The AFTR architecture design, then, is mostly figuring out the
strategic placement of each AFTR to best use the capacity of each
public IPv4 address without oversubscribing the address or overtaxing
the AFTR itself. Although only a few studies of per-user port usage
have been done, an AFTR should be able to support 3000 - 5000 users
per public IPv4 address.
By centralizing public IPv4 addresses, each address no longer
represents a single machine, a single household, or a single small
office. The address now represents thousands of machines, homes, and
offices related only in that they are behind the same AFTR.
Identification by IP address becomes difficult or impossible and thus
applications that assume such geographic information may not work as
intended.
Lee, et al. Expires April 18, 2011 [Page 6]
Internet-Draft Deployment Considerations for DS-Lite October 2010
2.7. AFTR Considerations for Geographically Aware Services
Various applications and services will place their servers in such a
way to locate them near sets of user so that this will lessen the
latency on the client end. In addition, having sufficient
geographical coverage can indirectly improve end-to-end latency. An
example is that nameservers typically return results optimized for
the DNS resolver's location. Deployment of AFTR must be done in such
a way as not to negatively impact the geographical nature of these
services. This can be done by making sure that AFTR deployments are
geographically distributed so that existing assumptions of the
clients source IP address by geographically aware servers can be
maintained.
2.8. Impacts on QoS
As with tunneling in general there are challenges with deep packet
inspection with DS-Lite for purposes of QoS. Service Providers
commonly uses DSCP to classify and prioritize packets. It is
recommended the AFTR to copy the DSCP value in the IPv4 header to the
IPv6 header after the encapsulation.
2.9. Port Forwarding Considerations
Some applications require accepting incoming UDP or TCP traffic.
When the remote host is on IPv4, the incoming traffic will be
directed towards an IPv4 address. Some applications use (UPnP-IGD)
(e.g., XBox) or ICE [I-D.ietf-mmusic-ice] (e.g., SIP, Yahoo!, Google,
Microsoft chat networks), other applications have all but completely
abandoned incoming connections (e.g., most FTP transfers use passive
mode). But some applications rely on ALGs, UPnP IGD, or manual port
configuration. Port Control Protocol (PCP)
[I-D.wing-pcp-design-considerations] is designed to address this
issues.
3. B4 Deployment Considerations
In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs
the IPv6 address of the AFTR element. This IPv6 address can be
configured using a variety of methods, ranging from an out-of-band
mechanism, manual configuration or a variety of DHCPv6 options. In
order to guarantee interoperability, a B4 element SHOULD implement
the DHCPv6 option defined in
[I-D.ietf-softwire-ds-lite-tunnel-option]. The DHCP server must be
reachable via normal DHCP request channels from the B4, and it must
be configured with the AFTR address. In Broadband Access scenario
where AAA/RADUIS is used for provisioning user profiles in the BNAS,
Lee, et al. Expires April 18, 2011 [Page 7]
Internet-Draft Deployment Considerations for DS-Lite October 2010
[I-D.ietf-softwire-dslite-radius-ext] may be used. BNAS will learn
the AFTR address from the RADIUS attribute and act as the DHCPv6
server for the B4s.
3.1. DNS deployment Considerations
[I-D.ietf-softwire-dual-stack-lite] recommends configuring the B4
with a DNS proxy resolver, which will forward queries to an external
recursive resolver over IPv6. Alternately, the B4 proxy resolver can
be statically configured with the IPv4 address of an external
recursive resolver. In this case, DNS traffic to the external
resolver will be tunneled through IPv6 to the AFTR. Note that the B4
must also be statically configured with an IPv4 address in order to
source packets; the draft recommends an address in the 192.0.0.0/29
range. Even more simply, you could eliminate the DNS proxy, and
configure the DHCP server on the B4 to give its clients the IPv4
address of an external recursive resolver. Because of the extra
traffic through the AFTR, and because of the need to statically
configure the B4, these alternate solutions are likely to be
unsatisfactory in a production environment. However, they may be
desirable in a testing or demonstration environment.
4. Security Considerations
This document does not present any new security issues.
[I-D.ietf-softwire-dual-stack-lite] discusses DS-Lite related
security issues. General NAT security issues are not repeated here.
Some of the security issues with carrier-grade NAT result directly
from the sharing of the routable IPv4 address. Addresses and
timestamps are often used to identify a particular user, but with
shared addresses, more information (i.e., protocol and port numbers)
is needed. This impacts software used for logging and tracing spam,
denial of service attacks, and other abuses. Devices on the
customers side may try to carry out general attacks against systems
on the global Internet or against other customers by using
inappropriate IPv4 source addresses inside tunneled traffic. The
AFTR needs to protect against such abuse. One customer may try to
carry out a denial of service attack against other customers by
monopolizing the available port numbers. The AFTR needs to ensure
equitable access. At a more sophisticated level, a customer may try
to attack specific ports used by other customers. This may be more
difficult to detect and to mitigate without a complete system for
authentication by port umber, which would represent a huge security
requirement.
Lee, et al. Expires April 18, 2011 [Page 8]
Internet-Draft Deployment Considerations for DS-Lite October 2010
5. Conclusion
DS-Lite provides new functionality to transition IPv4 traffic to IPv6
addresses. As the supply of unique IPv4 addresses diminishes,
service providers can now allocate new subscriber homes IPv6
addresses and IPv6-capable equipment. DS-Lite provides a means for
the private IPv4 addresses behind the IPv6 equipment to reach the
IPv4 network.
This document discusses the issues that arise when deploying DS-Lite
in various deployment modes. Hence, this document can be a useful
reference for service providers and network designers. Deployment
considerations of the B4, AFTR and DNS have been discussed and
recommendations for their usage have been documented.
6. Acknowledgement
TBD
7. IANA Considerations
This memo includes no request to IANA.
8. References
8.1. Normative References
[I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-05 (work in
progress), September 2010.
[I-D.ietf-softwire-dslite-radius-ext]
Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
Stack Lite", draft-ietf-softwire-dslite-radius-ext-00
(work in progress), October 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[I-D.wing-pcp-design-considerations]
Lee, et al. Expires April 18, 2011 [Page 9]
Internet-Draft Deployment Considerations for DS-Lite October 2010
Wing, D., "PCP Design Considerations",
draft-wing-pcp-design-considerations-00 (work in
progress), September 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
8.2. Informative References
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-v6ops-ipv6-cpe-router]
Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", draft-ietf-v6ops-ipv6-cpe-router-07 (work in
progress), August 2010.
[I-D.xu-behave-stateful-nat-standby]
Xu, X., "Redundancy and Load Balancing Framework for
Stateful Network Address Translators (NAT)",
draft-xu-behave-stateful-nat-standby-05 (work in
progress), September 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
Lee, et al. Expires April 18, 2011 [Page 10]
Internet-Draft Deployment Considerations for DS-Lite October 2010
Authors' Addresses
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A.
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Roberta Maglione
Telecom Italia
Via Reiss Romoli 274
Torino 10148
Italy
Email: roberta.maglione@telecomitalia.it
URI: http://www.telecomitalia.it
Carl Williams
MCSR Labs
Philadelphia
U.S.A.
Email: carlw@mcsr-labs.org
Christian Jacquenet
France Telecom
Rennes
France
Email: christian.jacquenet@orange-ftgroup.com>
Mohamed Boucadair
France Telecom
Rennes
France
Email: mohamed.boucadair@orange-ftgroup.com
Lee, et al. Expires April 18, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:22 |