The IESG has approved the following document: - 'Deployment Considerations for Dual-Stack Lite' (draft-ietf-softwire-dslite-deployment-08.txt) as Informational RFC This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ 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
