Internet DRAFT - draft-ma-v6ops-router-test
draft-ma-v6ops-router-test
Internet Engineering Task Force Q. Ma
Internet-Draft R. Gu
Intended status: Informational T. Yang
Expires: April 21, 2014 China Mobile
October 18, 2013
Test for router and BRAS devices on the degree of IPv6 support
draft-ma-v6ops-router-test-00
Abstract
This document introduces the test for the router and BRAS devices on
the degree of IPv6 support. IPv6 functions and performance of the
routers and BRAS widely deployed in current networks are included in
testing items. It turns out that some specific IPv6 functions and
performance are not well-supported by the router and BRAS devices.
The test results have been discussed to share with internet
community.
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 21, 2014.
Copyright Notice
Copyright (c) 2013 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.
Ma, et al. Expires April 21, 2014 [Page 1]
Internet-Draft TEST-RESULT October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Test overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Test topology . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Results and analysis of router devices testing . . . . . . . 4
4.1. Functionality of QPPB . . . . . . . . . . . . . . . . . . 4
4.2. Functionality of NetFlow . . . . . . . . . . . . . . . . 5
4.3. Performance of IPv6 FIB capacity . . . . . . . . . . . . 5
4.4. Summary for routers testing . . . . . . . . . . . . . . . 5
5. Results and analysis of BRAS devices testing . . . . . . . . 5
5.1. Functionality of PPPoE . . . . . . . . . . . . . . . . . 6
5.2. Functionality of DHCPv6 . . . . . . . . . . . . . . . . . 6
5.3. Summary for BRAS testing . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Every device on the Internet must be assigned an IP address in order
to communicate with other devices. With the ever-increasing number
of new devices being connected to the Internet, the need arose for
more addresses than IPv4 is able to accommodate. IPv6 was developed
to deal with the long-anticipated problem of IPv4 address exhaustion
and the deployment of IPv6 became imperative to the global Internet
service providers (ISPs).
In order to deploy IPv6 in current networks, IPv6 support is required
in the network equipments. It's necessary to test the existing
equipments to verify whether they meet the operational needs of
network operators in IPv6 migration. China Mobile processed the IPv6
supporting test to the router and BRAS equipments to ensure that
these equipments will meet the requirement of IPv6 function and
perform well in the future IPv6 commercial networks.
This document has described the detailed test contents such as
functionality, performance and other aspects of IPv6 support in
router and BRAS devices. The test results have been evaluated and
problems of router and BRAS devices in IPv6 support are analyzed.
Results show that the functionality of QPPB, NetFlow and the FIB
capacity performance of the tested router devices in the current
networks do not meet the requirement of IPv6 deployment and the
problems in PPPoE and DHCPv6 function of BRAS devices still exist.
These problems may lead to the conditions that the multicast-based
services may not be well-developed, separate DHCPv6 servers should be
built, and the QoS of the IPv6 network may be largely influenced.
Ma, et al. Expires April 21, 2014 [Page 2]
Internet-Draft TEST-RESULT October 2013
Discussions of the testing results will give technical guidance to
ISPs and device manufacturers in the commercial IPv6 deployment.
2. Test overview
The IPv6 supporting tests contain IPv6 functionality, performance,
and other aspects of router and BRAS devices deployed in the current
networks. Throughout the full test, the service providers will be
able to understand the technical maturity of the various equipment
manufacturers, obtain the crisis data and technical support to the
deployment of IPv6.
The tests mainly include the following aspects:
- functionality test of basic IPv6 protocols including IPv6, ICMPv6,
TCP, UDP, PPP, MLD, etc;
- functionality test of Dual-Stack routing protocols including router
protocol of OSPFv3/ISISv6/BGP4+;
- functionality test of QPPB based on source address or destination
address of IPv4/IPv6;
- functionality test of GR/NSR/NSF, including router protocol of OSPF
/ISIS/BGP;
- functionality test of ECMP, including router protocol of OSPF/ISIS/
EBGP, MPLS-TE, ECMP max link numbers;
- functionality test of Access technology, including QinQ, PPPoEv6,
PPP, DHCPv6 relay;
- -functionality test of DHCPv6 including DHCPv6 protocol, DHCP-PD,
PHCP-PD with PPPoE;
- functionality test of Multicast, including multicast replication,
managed, and source specified;
- functionality test of NetFlow, including IPv4/IPv6 Unicast and
Multicast;
- functionality test of Radius, including authentication and
accounting;
- functionality test of 6PE/6vPE protocol;
- performance test of IPv4/IPv6 FIB capacity;
Ma, et al. Expires April 21, 2014 [Page 3]
Internet-Draft TEST-RESULT October 2013
- performance test of IPv4/IPv6 ACL quantity;
- performance test of QoS queue quantity;
- performance test of the max concurrent sessions and established
link numbers of PPPoE/IPoE;
- performance test of data package forwarding capabilities of IPv6
including throughput and delay;
3. Test topology
|--------| |------------| |-----------| |--------|
| Tester |-----|Aggregation |---|ROUTER/BRAS|----| Tester |
| | | Device | | | | |
|--------| |------------| |-----------| |--------|
Figure 1: Test topology
4. Results and analysis of router devices testing
Router devices play the roles of a traffic director on the Internet.
A data packet is typically forwarded from one router to another
through the networks that constitute the internetwork until it
reaches its destination node. Router devices should support various
IPv6 functionality and IPv6 transition technology in order to perform
smoothly in the transition from IPv4 to IPv6.
All the tested router devices can support basic IPv4 and IPv6
protocol stacks such as OSPFv3 [RFC2740], ISISv6 [RFC5308] and BGP4+
[RFC2545] and have the functionality of 6PE/6vPE. The performance of
IPv4/IPv6 ACL quantity, QoS queue quantity and the data package
forwarding capabilities can meet the requirement of commercial IPv6
deployment. But some specific IPv6 functions are not supported by
the router devices currently adopted in the networks.
4.1. Functionality of QPPB
QoS Policy Propagation via BGP (QPPB) is a mechanism that allows
propagation of quality of service policy and classification by the
sending party based on access lists, community lists and autonomous
system paths in the BGP.
In testing the QPPB functionality, we found out that QPPB based on
source address or destination address in IPv6 is not supported in
Ma, et al. Expires April 21, 2014 [Page 4]
Internet-Draft TEST-RESULT October 2013
some current routers, because the design of router devices adopted in
early networks does not take IPv6 into consideration. In the recent
router version, IPv4 and IPv6 are both considered, which means some
routers in current networks should be upgraded.
4.2. Functionality of NetFlow
NetFlow is a network protocol developed for collecting IP traffic
information, which is used in traffic monitoring and supported on
various platforms. While in multicast NetFlow test, it turns out
that the function of IPv6 multicast NetFlow is not supportive among
several router devices. Even the IPv4 multicast NetFlow is not
supported in some router devices. The result shows that the
functionality of NetFlow in IPv4/IPv6 traffic should be noted in the
transition from IPv4 to IPv6.
4.3. Performance of IPv6 FIB capacity
Forwarding information base (FIB), also known as a forwarding table,
is most commonly used to find the proper interface to which the input
interface should forward a packet in routing networks. However, the
IPv6 FIB of most router devices does not meet the requirement in IPv6
scenario for the reasons such as memory and software designed in the
equipments, which should be taken into consideration in the IPv6
network infrastructures.
4.4. Summary for routers testing
The specific test gives out a result that the router devices deployed
in the current networks are partly supported in the IPv6 deployment
except in the functionality of QPPB, NetFlow and the Performance of
FIB capacity. Thus the multicast-based services may be influenced
and QoS may not satisfy the carriers and users in the commercial IPv6
scenario, which should be noticed by ISPs and device manufacturers.
5. Results and analysis of BRAS devices testing
Broadband Remote Access Server (BRAS), is the aggregation point for
the subscriber traffic. It provides aggregation capabilities between
the Access Network and the Metropolitan Area Network. Besides, it is
also the injection point for access authentication, policy management
and QoS. BRAS is the PPP session termination point at ISP edge.
BRAS should support various IPv6 access technologies, be able to
authenticate and manage IPv6 subscribers, and support IPv6 transition
technology, such as 6PE [RFC4789], 6vPE [RFC4659] and Dual-Stack Lite
technology in the smooth IPv6 transition.
Ma, et al. Expires April 21, 2014 [Page 5]
Internet-Draft TEST-RESULT October 2013
IPv4 and IPv6 protocol stacks are supported by all tested BRAS
devices. Most BRAS devices can support basic PPPoEv6 and DHCPv6
protocols and functions, which allow subscribers to dial-up to
establish a PPP session [RFC5072] from host or routed CPE to BRAS for
the IPv4 and IPv6 traffic, and can assign 128-bit IPv6 address to
subscribers in the DHCPv6 IA_PD option , or assign 64-bit IPv6 prefix
to subscribers through Stateless address auto configuration (SLAAC)
scheme. Most BRAS support the function of AFTR, and can be deployed
as AFTR device in the DS-Lite architecture. But some specific IPv6
functions are not completed by the BRAS devices currently adopted in
the networks.
5.1. Functionality of PPPoE
PPPoE is widely used in large scale broadband ISPs as a broadband
connecting method. For certain tested BRAS devices, some PPPoE
functions for IPv6 are not well-supported.
Some BRAS devices do not support multicast for IPv6 PPPoE session.
Thus the multicast-based services are hardly developed without the
functionality of multicast for IPv6 PPPoE session.
Multilink PPP (MLP) is a variant of PPP used to aggregate multiple
WAN links into one logical channel for the traffic transportation.
It enables the traffic load-balance from different links and allows
some levels of redundancy in case of a line failure on a single link.
Several tested BRAS devices do not support Multilink PPPoE for IPv6.
When accessing IPv6 Internet via PPPoE, the Win7 operating system
cannot work with the 128-bit address, which is assigned to the Win7
OS in IA-NA option and the low order 64-bit is different from the
EUI-64. The low order 64-bit of the address must be the EUI-64
interface ID generated from a EUI-48 MAC address. In other words,
when connecting the IPv6 PPPoE access, Win7 operating system can only
be assigned a 64-bit IPv6 prefix through SLAAC or DHCPv6. The BRAS
configuration in actual networks should set the managed address
configuration flag to 0, assigning IPv6 prefix through SLAAC, or set
the managed address configuration flag to 1, assigning 128-bit IPv6
address with the EUI-64 interface ID through DHCPv6.
5.2. Functionality of DHCPv6
A few BRAS devices do not support DHCPv6 [RFC3315] server, which
means they cannot assign IPv6 address to subscriber in the DHCPv6
IA_PD option , and can only assign 64-bit IPv6 prefix to subscribers
through Stateless address auto configuration (SLAAC) scheme.
Ma, et al. Expires April 21, 2014 [Page 6]
Internet-Draft TEST-RESULT October 2013
Some tested BRAS do not support DHCPv6 relay function, which means
they cannot listen for the DHCPv6 messages and broadcast and route
the messages to a DHCPv6 server on a different subnet.
Prefix delegation [RFC3633] is used to assign a network address
prefix to a user site, configuring the user's router with the prefix
to be used for each LAN. A few BRAS devices do not support prefix
delegation, which means they cannot assign IPv6 prefix to the LAN of
customer premise equipment (CPE) using the Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)
5.3. Summary for BRAS testing
The specific test gives out results that the BRAS devices deployed in
the current networks are well supported in IPv4 and IPv6 protocol
stacks, and the basic PPPoEv6 and DHCPv6 protocols and functions are
partly supported by the tested BRAS devices. The existed problems in
PPPoE and DHCPv6 function have an impact on the deployment of IPv6,
such as operators have to build separate DHCPv6 servers, multicast-
based service cannot be well-developed and the QoS of the IPv6
network may be largely influenced. All these should be noticed by
ISPs and device manufacturers.
6. Security Considerations
It needs to be further identified.
7. IANA Considerations
TBD
8. Normative References
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, March
1999.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Ma, et al. Expires April 21, 2014 [Page 7]
Internet-Draft TEST-RESULT October 2013
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network
Management Protocol (SNMP) over IEEE 802 Networks", RFC
4789, November 2006.
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
Authors' Addresses
Ma Qiongfang
China Mobile
32, Xuanwumenxi Ave.
Xicheng District, Beijing 01719
China
Email: maqiongfang@chinamobile.com
Gu Rong
China Mobile
32, Xuanwumenxi Ave.
Xicheng District, Beijing 01719
China
Email: gurong@chinamobile.com
Yang Tianle
China Mobile
32, Xuanwumenxi Ave.
Xicheng District, Beijing 01719
China
Email: yangtianle@chinamobile.com
Ma, et al. Expires April 21, 2014 [Page 8]
