Internet Engineering Task Force Q. Ma Internet-Draft China Mobile Intended status: Informational October 15, 2012 Expires: April 18, 2013 Test about deployment of dual-stack lite draft-ma-softwire-dslite-test-00 Abstract This document introduces the test about deployment of dual-stack lite firstly，then describe two major problems about CPE devices in the test,address assignment and packet fragmentation. Status of this Memo This Internet-Draft is submitted to IETF 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, 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 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. Ma Expires April 18, 2013 [Page 1] Internet-Draft TEST-RESULT October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Test overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. test rusult of address assignment . . . . . . . . . . . . . . . 4 4. test result of fragmentation . . . . . . . . . . . . . . . . . 4 4.1. Test topology . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Result Description . . . . . . . . . . . . . . . . . . . . 4 4.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Ma Expires April 18, 2013 [Page 2] Internet-Draft TEST-RESULT October 2012 1. Introduction With the exhaust of IPv4 address space, the deployment of IPv6 became imperative to the Internet service providers.Dual-Stack lite technology which defined in RFC6333 has the potential to be widely used in the IPv6 evoluation process. In order to verify whether the existing equipments be able to support Dual-Stack lite technology, and meet the operational needs of network operators, it is necessary to test the various equipments and technical aspects involved in Dual-Stack lite. In this document, the content of Dual-stack deployment test is introduced fristly, after that, two problems about CPE devices found in the test are described, one is a few CPE devices's WAN interface can not support to achieve 128bits IPv6 Address by DHCPv6-NA, another is a few CPE devices handling jumbo frames with a different fragmentation manner compare to the definiton of RFC6333. 2. Test overview Through test the functionality, performance, reliability and other aspects of B4, AFTR, CGN devices or function modules which invlved in dual-stack lite technology, the service provider be able to understand the technical maturity of the various equipment manufacturers, obtain the crisis data and technical support to the deployment of dual-stack lite. The test mainly include the following aspects: -functionality of dual-Stack lite, including obtain and distribute addresses, IPv4-in-IPv6 tunnel, NAT ,application level gateway and other tests. - functionality of Radius, including authentication, accouting, recording extended attributes of NAT,tracing and other tests; - control policies, including the limit of ipv6 address ranges, limit of NAT sessions and other tests; - reliability test, including warm standy, hot standby of Address Family Transition Routers; - performance test, including the number of tunnels, the number of NAT sessions, forwarding performance and other tests; - DSLite+ NAT444 test,including deploy dual-stack lite and NAT444 at the same time, switching between dual-stack lite and NAT444, and Ma Expires April 18, 2013 [Page 3] Internet-Draft TEST-RESULT October 2012 other tests; 3. test rusult of address assignment A dual-stack lite CPE is an IPv6-aware CPE with a B4 interface implemented in the WAN interface. The IPv6 address of B4 element can be configured using several methods. In the test, we used methods of neighbor discovery mechanism and DHCPv6 options. The B4 element gets a 128-bit address by neighbor discovery negotiation, which is a directed link address and is usually different from the IPv6 prefix assigned by DHCPv6 prefix delegation (RFC 3633). The result shows that all test equipment can support this function. In the method of DHCPv6 options, the B4 element could directly get 128-bit global address in IA_NA option, or auto-configures a 128-bit address with the IPv6 prefix in the IA_PD option. A DS-Lite CPE could share the same prefix pool with the hosts connecting the CPE. The test result shows that some home gateways with FE ports cannot support the method of DHCPv6 IA_NA option. That means some low-end CPEs don't support DHCPv6 well. 4. test result of fragmentation 4.1. Test topology |--------| |-----| |------------| |----------| |--------| | Tester |--| CPE |---|Aggregation |---|BRAS/BNG |--| Tester | | | | | | Device | | AFTR/CGN | | | |--------| |-----| |------------| |----------| |--------| Figure 1: Test topology 4.2. Result Description Tester simulates end users which send IPv4 packets to remote, the CPE device encapsulates these IPv4 packets into IPv4-in-IPv6 tunnel, then AFTR device decapsulates them and send the IPv4 packets to their destinations. In the test scenarios, if the original IPv4 frame is larger than 1462bytes, it has to be fragmented when be transited in the IPv4-in-IPv6 tunnel. We found that there are some problems about a few provider's CPE devices, when the IPv4 larger than 1462bytes was transited by AFTR, it had not been reassembled, but the fragmented IPv4 packet were forwarded. Ma Expires April 18, 2013 [Page 4] Internet-Draft TEST-RESULT October 2012 4.3. Analysis After analyse the mirroring packets, we realized that the reason of the above phenomenon is a few CPE devices fragment the original IPv4 packet into two smaller IPv4 packets, then encapsulates these packets into tunnel, and when those packets arrived at the AFTR, they were be decapsulated and transfered as the normal process. The AFTR did not know the decapsulated IPv4 packets need to be reassembled. In the RFC6333 section 5.3, fragmentation and reassembly in the B4 element had be defined as follow: The inner IPv4 packet MUST NOT be fragmented. Fragmentation MUST happen after the encapsulation of the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv4 packet. A few CPE devices did not accomplish the fragmentation function according the definition of RFC6333. The fragmented IPv4 packets need to be reassembled by the final recipient, so an extra burden was bringed to the recipient. Due to the fragmented IPv4 packet may be smaller than the handling requirement of some device in the transfer path, the packet could even be discarded. 5. Security Considerations It needs to be further identified. 6. IANA Considerations TBD 7. Acknowledgement Thanks for the contributions from Tang Hao. Author's Address Ma Qiongfang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: maqiongfang@chinamobile.com Ma Expires April 18, 2013 [Page 5]