Technical Summary
Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that
enable operators to multiplex public IPv4 addresses while
provisioning only IPv6 to users. This document discusses the
deployment issues and describes requirements for the deployment and
operation of Dual-Stack Lite.
Working Group Summary
This document was discussed in depth and well-reviewed. WG
consensus is strong to publish this document.
Document Quality
This is deployment discussion rather than a protocol definition,
while DS-Lite has been deployed/tested in some production networks.
Personnel
Softwire co-chair, Yong Cui, is the Document Shepherd. Ralph Droms
is the Responsible AD.
RFC Editor Note
Please make the following changes when this document is published:
Section 2.6:
OLD:
Alternatively, AFTR may perform accounting for IPv4 traffic.
However, operators must be aware that this will introduce some
challenges especially in DSL deployment. In DSL deployment, the AAA
transaction normally happens between the edge router (i.e., Broadband
Network Gateway) and AAA server. [RFC6333] does not require the AFTR
to interact with the AAA server or edge router. Thus, AFTR may not
have the AAA parameters (e.g., Account Session ID) associated to
users to generate IPv4 accounting record. The accounting process at
the AFTR is only necessary if the operator requires separating per
user accounting records for IPv4 and IPv6 traffic. If the per user
IPv6 accounting records, collected by the edge router, are
sufficient, and the additional complexity of enabling IPv4 accounting
at the ATFR is not required. It is important to notice that, since
the IPv4 traffic is encapsulated in IPv6 packets, the data collected
by the edge router for IPv6 traffic already contain the total amount
of traffic (i.e. IPv4 and IPv6).
NEW:
Alternatively, AFTR may perform accounting for IPv4 traffic.
However, operators must be aware that this will introduce some
challenges especially in DSL deployment. In DSL deployment, the
AAA transaction normally happens between the edge router (i.e.,
Broadband Network Gateway) and AAA server. [RFC6333] does not
require the AFTR to interact with the AAA server or edge router.
Thus, AFTR may not have the AAA parameters (e.g., Account Session
ID) associated to users to generate IPv4 accounting record. IPv4
traffic accounting at the AFTR is not recommended when the AAA
parameters necessary to generate complete IPv4 accounting records
are not available. The accounting process at the AFTR is only
necessary if the operator requires separating per user accounting
records for IPv4 and IPv6 traffic. If the per user IPv6 accounting
records, collected by the edge router, are sufficient, and the
additional complexity of enabling IPv4 accounting at the ATFR is
not required. It is important to notice that, since the IPv4
traffic is encapsulated in IPv6 packets, the data collected by the
edge router for IPv6 traffic already contain the total amount of
traffic (i.e. IPv4 and IPv6).
END
In section 3.2.2:
OLD:
Operators should assign the same IPv4 address
(i.e., 192.0.0.2/32) to all AFTRs. IANA allocates 192.0.0.0/29
[RFC6333] Section 5.7 that can be used for this purpose.
NEW:
Operators should assign the same IPv4 address
(e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated
the 192.0.0.0/29 network prefix to provide IPv4 addresses for this
purpose [RFC 6333].
END
Section 2.4:
OLD:
AFTR is a NAT device. It enables multiple users to share a single
public IPv4 address. [RFC6269] discusses some considerations when
sharing an IPv4 address. When a public IPv4 address is blacklisted
by a remote peer, this may affect multiple B4 elements sharing the
same IPv4 address. Operators deploying DS-Lite should be aware that
Internet hosts may rely solely on source IP address to identify an
abusive household and may not be aware that a given single IPv4
address is actually shared by multiple households. A content
provider may block services for a shared IPv4 address and this will
impact all households sharing this particular IPv4 address. The
operator may receive calls of service outage and will need to take
appropriate actions. Such corrective actions include but not limited
to notifying the content provider to combine the IPv4 address with
transport (e.g., TCP) and application protocol (e.g., HTTP) to
identify abusive household. [RFC6302].
[I-D.ietf-intarea-nat-reveal-analysis] analyzes different approaches
to identify a user in a shared address environment.
NEW:
AFTR is a NAT device. It enables multiple users and/or hosts to
share a single public IPv4 address. [RFC6269] discusses some
considerations when sharing an IPv4 address. When a public IPv4
address is blacklisted by a remote peer, this may affect multiple
users or hosts. Operators deploying DS-Lite should be aware that
Internet hosts may not be aware that a given single IPv4 address is
actually shared by multiple users or hosts. A content provider
might block services for a shared IPv4 address and this would then
impact all users and hosts sharing this particular IPv4 address.
The operator would be likely to receive calls related to service
outage and would then need to take appropriate corrective actions
re-establishing connectivity.
END