Internet Protocol Version 6 (IPv6) Analysis

Published Date: 02 Mar 2018

Overview

Internet Protocol version 6 (IPv6) is the next generation of protocol defined by InternetEngineering Task force (IETF) to replace the exiting IPv4 protocol. At present, the majority of Internet users are still using IPv4 protocol, and given that most of current networking applications and network equipment run in IPv4 environments, the migration from IPv4 to IPv6 can't be accomplished overnight. It is predictable that the migration will be a long-term process (it is forecasted that the process will take 10 - 20 years). During the migration, IPv4 and IPv6 will coexist in a same network. This migration process poses new challenges on the routers that are the core equipment in IP network. Traditional routers can't accommodate new future network with IPv4/v6 coexistence. The routers must be improved and upgraded so that they can support both IPv4 and IPv6.Given that the core router is very important and carries huge Internet traffics, it must be able to support IPv6 forwarding at wire rate. It means ASIC chip, but not software is used to support IPv6 packet processing. At the same time, it is very important that this support can't sacrifice any IPv4 performance. After all, most of current traffics is IPv4. The core router must expand to support IPv6 routing tables and needs to support IPv6 routing protocols, such as BGP4+, OSPFv3, ISISv6, RIPng and etc. It needs to support some migration strategy from IPv4 to IPv6, such as Tunnel, Dual Stack, Translation and etc.

Same as many network technologies, successful deployment of IPv6 relies on the deployment of the operators' IPv6 network. As one core component in IPv6 network, IPv6 core router is key to network building, applications, performance and stability. At present, mainstream router vendors like Cisco and Juniper announce that their routers can support IPv6 while some traditional IT equipment manufactures, especially those in Japan, think Internet upgrade caused by IPv6 will change the whole landscape of router market, which brings significant opportunities for them to enter router market. From 2000 to 2002, Hitachi, NEC and Fujitsu announced IPv6-capable core router to gain some market share in new Internet network.

It must be admitted that IPv6 is still in the initial phase at present, which is reflected in the following aspects: most IPv6 network is in trial phase, the number of access users is low, carried IPv6 traffics can't be comparable to IPv4, the interoperability between IPv6 equipment still needs to be proved, and network engineers lack in experience in large-scale deployment and operation of IPv6 network. The lack of data and experience is one of important causes that make some operators lack in confidence in IPv6 network deployment. Many operators take wait-and-see attitudes. In order to prove IPv6 router (especially IPv6 core router), the support to IPv6, how are they performed and interoperated, provide a practical data basis for the operators to deploy IPv6 network and provide a reference for equipment manufactures to evaluate and improve their equipment, BII(Beijing Internet Institute) collaborate with 6TNet (IPv6 Telecom Trial Network) in China tested IPv6 core routers from 4 vendors (Fujitsu, Hitachi, Juniper and NEC) in Beijing from

October to December 2002. BII performed protocol conformance, performance and interoperability tests. In these tests, we used the test instruments provided by Agilent and received strong technical support from Agilent.

The test is not a comparative performance test in different router vendors. The purpose is to verify the feasibility of IPv6 deployment. With this test, the test team thinks that all SUT (system under test) has the ability to support commercial IPv6 network and provide basic IPv6 capabilities. They can support IPv6 routing protocols, support the forwarding of IPv6 datagram at wire rate and provide interoperability between them. From perspectives of pure technology, the test team thinks the products have been ready to deploy basic IPv6 core network..

Brief Descriptions of Test

The requirements for hardware provided by the SUT (system under test) are as follows:

1. IPv6-capable core router
2. OC48 SM ports (both ports must be in different boards)
3. Supports both FE ports and GE ports. The number of FE ports and GE ports is no less than 3

Finally, all vendors basically meet those requirements, although CX5210 provided by NEC doesn't support FE during the time of testing.

The requirement for IPv6 capabilities provided by the SUT (system under test) include: support of IPv6 forwarding in hardware and support of related IPv6 routing protocols and migration strategy. Finally, all vendors meet our requirements as shown in the following table.

Company IPv6 hardwareDual Stack RIPng OSPFv3 BGP4+ IPv6 over IPv4

forwarding Tunnel

Fujitsu 9 9 9 9 9 9

Hitachi 9 9 9 9 9 9

Juniper 9 9 9 9 9 9

NEC 9 9 9 9 9 9

The SUT (system under test) models and OS versions are shown in the following table.

Company Model Version

Fujitsu Geostream R920 E10V02L03C44

Hitachi GR2000-20H S-9181-61 07-01 [ROUTE-OS6]

Juniper M20 5.5R1.2

NEC CX5210 02.0(2e) 45.08.00

The test instruments we used in the test are as follows:

Agilent Router Tester 900

Version: Router Tester 5.1,Build 11.15. Agilent QA Robot

Version: Router Tester 5.3,Build 5.2

The IPv6 core router test is composed of three parts:

Protocol conformance test, interoperability test and IPv6 performance test.

Basic IPv6 Protocols and RIPng

Basic IPv6 protocols include IPv6 Specification (RFC2460), ICMPv6 (RFC2463), Neighbor Discovery (RFC2461), Stateless Autoconfiguration (RFC2462), Path MTU Discovery (RFC1981), IPv6 address Architecture (RFC1884) and etc., which are basic capabilities provided by an IPv6 implementation.

RIPng is defined by RFC2080 and is the extension and expansion of RIPv2. Its basic capabilities are same as RIPv2. The routing information exchanged by RIPng can carry IPv6 addresses and prefixes. RIPng runs on IPv6 network, uses multicasting address ff02::9 as destination to transfer routing information. RIPng is not compatible with RIPv2. RIP protocol is typically used in small networks and is not deployed in large networks because of its scalability and performance, which is same in IPv6 networks.

The test does not include basic IPv6 protocols and RIPng because we think both capabilities are most basic and most preliminary capabilities that should be provided in an IPv6 router, these capabilities are implemented and interoperated very well in the routers from 4 vendors, and the 4 tested routers have been tested publicly or non-publicly several times in different occasions and provided good data. Therefore, we think it is unnecessary to make efforts to repeat these work and we skipped this test and focused on more challenged test items.

BGP4+ Protocol Conformance Test

At present, the external gateway protocol used in the IPv4 network is BGP4. Its basic protocols

are defined in RFC1771. In order to carry IPv6 network information in BGP4 updates, IETF has defined a special property - multi-protocol BGP (MP-BGP), also called IPv6 NLRI (Network Layer Reachability Information) to exchange IPv6 routing information, which is not a new version of BGP protocol, but an extension to BGP4. The extension is generally called BGP4+, which is compatible with BGP4. Refer to RFC2545 for its definition.

Test Purpose and Used Standards:

Purpose: To test the implementation of BGP4+ and conform with related standards for SUT (System Under Test). The following standards are referred in the test:

1. Bates, T., Chandra, R., Katz, D. and Y. Rekhter, “Multiprotocol Extension for BGP-4”, RFC 2858, Jne 2000.
2. Bates, T., Chandra, R., Chen, E., “BGP Route Reflection - An Alternative to Full Mesh IBGP”, RFC2796, April 2000.
3. Chandra, R. and J.Scudder, “Capabilities Advertisement with BGP-4”, RFC 2842, May 2000.
4. Dupont, F. and P. Marques, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing”, RFC 2545, March 1999.
5. Rekhter, Y. and T. Li, “A Border Gateway Protocol 4 (BGP-4) <draft-ietf-idr-bgp4-14.txt>”.
6. Traina, P., McPherson, D., Scudder, J., “Autonomous System Confederations for BGP”, RFC3065, February 2001.

Test Methods:

All the tests are based on topology emulation. One test port of instrument firstly establishes network topology emulation, then executes pre-written scripts, interacts with the port of SUT, performs related BGP4+ protocol tests individually and each test generates Passed/Failed record. The tests can be divided into active tests and passive tests. Active test means the tester is used to verify the state machine of SUT and the correctness of message format while passive test means the tester is used to interfere with SUT using messages with errors.

Test Topology

Test instrument and SUT use two independent Fast Ethernet or Gigabit Ethernet connections. All BGP4+ runs on the Fast Ethernet or Gigabit Ethernet connections.

The physical topology is as follows:

The logical topology is as follows:

Test Items and Descriptions of Test Results:

The BGP4+ protocol conformance test involves in the BGP multi-protocol extension, setup and transfer of BGP4+ IBGP and EBGP sessions, ability to receive IPv6 route updates, BGP4+ next hop, starting point, MED, local preference, AS_PATH, atom aggregation, community name and various properties, the ability of SUT to correctly process these properties, BGP4+ route reflector capability, BGP4+ federation capability.

These tests can only ensure implementation of BGP4+protocol in SUT comply with the standard defined by RFC, and can't ensure SUT fully and successfully deploy BGP4+ routes in commercial IPv6 network.

The following diagram briefly describes the test results. Attached table 1 includes all test items, description and detailed results of BGP4+ conformance tests for 4 routers. The test items and descriptions are extracted from RFC2858, RFC2545, RFC2842, RFC2796, RFC3065 and draft-ietf-idr-bgp4-14.txt part.

Model Failed test items

Fujitsu GeoStream R920 2

Hitachi GR2000-20H 5

Juniper M20 1

NEC CX5210 3

Analysis of Test Results:

Capabilities not supported

Confederation

Route reflector, Community

Fujitsu's GeoStreamR920 of current version does not support BGP4+ federation capability. In all BGP4+ test items it supported, the general performance is fairly good. What needs to be improved is only one item that is to support the migration of undefined property and handle interim duration.

It is hoped to improve null interface which can't support next hop at present.

Hitachi's GR2000-20H of current version supports all test items, and is only product fully supporting BGP4+ protocols in the core routers from 3 Japanese companies. However, it needs to be improved in the following areas: handling next-hop property of IBGP in BGP4+ protocol, using AS_PATH properties to prevent from route loop, the ability of route reflector to detect ORIGINATOR_ID. At the same time, we found in the interoperability test that GR2000-20H can't establish non-physical direct-connection sessions with IBGP peering entities, which Hitachi needs to improve. It is hoped to add loopback address capability.

Juniper's M20 passes all tests except one item excellently.

NEC's CX5210 of current version doesn't support BGP4+ route reflector and community properties. In all BGP4+ test items it supported, the general performance is fairly good. However, it needs to be improved in handling BGP4+ federation AS_CONFED_SEQUENCE property. It is hoped to add null interface configuration.

Interoperability Test

As above mentioned, IPv6 is in initial phase of commercial deployment at present. A large amount of IPv6-capable network equipments and terminals are available. IPv6 network built by the operators doesn't only use the equipment provided by a vendor. In multi-vendor network environment, the interoperability between equipment is vital.

The interoperability test is composed of BGP4+ interoperability test and OSPFv3 interoperability test. It should be noted that specific items in the interoperability test only cover some most common properties of BGP4+ and OSPFv3, and are not the interoperability tests of all properties of BGP4+ and OSPFv3.

BGP4+ Interoperability

Establish IBGP Sessions

Test Descriptions: The test is to verify GR2000-20H, CX5210, R920,M20 and fully meshed iBGP connections that can be established.

Reference: RFC1771, RFC2545 and RFC2858.

Test steps: GR2000-20H, CX5210, R920, M20 and SUT are connected as shown in the following diagram.

4 routers are in a same autonomous domain and are interconnected using IBGP protocol to form a full-meshed IBGP connection. Test instrument and SUT are interconnected using EBGP

connection. Because GR2000-20H doesn't support IBGP across-router Session connection, we use a FE link to connect GR2000-20H to M20 to form a fully-meshed connection.

Test Results:

We verified whether iBGP sessions were established between GR2000-20H, CX5210, R920 and M20, and it was found all connections were set up successfully.

GR2000-20H CX5210 R920 M20

GR2000-20H N/A OK OK OK

CX5210 OK N/A OK OK

R920 OK OK N/A OK

M20 OK OK OK N/A

EBGP- Route Advertisement

Test Descriptions: To verify GR2000-20H, CX5210, R920 and M20 can advertise routes properly in a fully meshed networks.

References: RFC1771, RFC2545 and RFC2858.

Test steps: Establish network topology according to previous test, establish eBGP connection between tester and SUT, send 100 EBGP routes from tester to SUT.

Results:

We verified whether GR2000-20H, CX5210 and R920 and M20 routing tables were correct, and it was found all routing tables were correct.

GR2000-20H CX5210 R920 M20

GR2000-20H N/A OK OK OK

CX5210 OK N/A OK OK

R920 OK OK N/A OK

M20 OK OK OK N/A

Establish EBGP Sessions

Test Descriptions: The test is to verify GR2000-20H, CX5210, R920 and M20 can establish a fully meshed eBGP connections.

Reference: RFC1771, RFC2545 and RFC2858.

Test steps: GR2000-20H, CX5210, R920 and M20 are connected as shown in the following diagram.

Test Descriptions:

We verified whether EBGP sessions were established between GR2000-20H, CX5210, R920 and M20, and it was found all connections were established successfully.

GR2000-20H CX5210 R920 M20

GR2000-20H N/A OK OK OK

CX5210 OK N/A OK OK

R920 OK OK N/A OK

M20 OK OK OK N/A

EBGP - Route Advertisement

Test Descriptions: To verify GR2000-20H, CX5210, R920 and M20 can advertise EBGP routes properly.

References: RFC1771, RFC2545 and RFC2858.

Test steps: Establish network topology according to previous tests, send routes from each router to all other routers.

Test Results:

We verified whether GR2000-20H, CX5210 and R920 and M20 routing tables were correct, and it was found all routing tables were correct.

GR2000-20H CX5210 R920, M20r

GR2000-20H N/A OK OK OK

CX5210 OK N/A OK OK

R920 OK OK N/A OK

M20 OK OK OK N/A

OSPFv3 Interoperability

OSPF protocols supporting IPv6 is OSPFv3. OSPFv3 routing mechanism is basically same as

OSPFv2. However, OSPFv2 relies primarily on IPv4, while OSPFv3 makes many improvements in OSPFv2 and is not a simple extension, thus OSPFv3, whose corresponding protocol is RFC2740, runs on IPv6. For real world applications, many operators regard OSPFv3 as a brand new protocol, also its stability and maturity need to be further verified, so when IPv6 routing protocols are selected, it tends to use IS-ISv6 (draft-ietf-isis-ipv6-02.txt), which is only a simple extension to IS-ISv4 (RFC1195) (2 TLVs re-defined) and does not make changes fully. However, it is sure the opinion is not authoritative and need to be proved.

Because of the limitations of test instrument, It is required for SUT to provide 100M Ethernet interface. As CX5210 does not support Ethernet interface at present, just M20, R920 and GR2000-20H were involved in the testing. However, it does not imply that CX5210 can't interoperate with other 3 routers and has any problems with functions implementation.

In the test, GR2000-20H is called SUT1 in short, M20 is called SUT2, and R920 is called SUT3.

Establish OSPF Connections - DR Election

Test Descriptions:

1. In the initial status, set different OSPF priority levels for SUT1, SUT2, SUT3 and the test instrument (10, 8, 5, 0). Connect these equipments based on the network topology below.
2. Verify SUT1, SUT2, SUT3 and test instrument to establish OSPFv3 adjacency and vote DR/BDR.
3. After DR/BDR is established properly, put DR off the network, and check whether DR/BDR is established properly.
4. Put off-net equipment on the network, and check whether DR/BDR is established properly.
5. Change OSPF initialization priorities of SUT1, SUT2, SUT3 and test instrument, and implement new test from step 2. Repeat the tests for 4 times, and ensure each SUT and test instrument have one opportunity to be selected as DR and BDR under the intial status.

During the test, all SUTs are in the same OSPF Area 0.

Reference: RFC2740

Test Results:

During the testing, all the OSPF adjacencys can be established between SUTs and DR, also BDR can be elected properly. After DR is off-line, BDR can be re-elected as DR and the one with sub-top priority will be BDR. When off-line equipment is on-line again, no re-electing process occurs. All test results comply with the requirements in related standards.

Exchange LSA Database

Test Descriptions: Test instrument simulates an internal network with 4 routers connected, and sends the routing information to SUT. Then verify the routing information received by SUT DR from test instruments will be sent to DR Other correctly. Same as the previous test item, firstly SUT1 is used as DR, then SUT2, and finally SUT3.

Reference: RFC2740

Test Results:

During the testing, OSPF adjacency can be established properly between all SUTs. DR receive

LSA information from test instrument and properly send the information to DR Other, which can also receive and process LSA information properly.

IPv6 Performance Test

The major approach used for the performance testing was to send the IPv6 traffic with different packet sizes and specific QoS information, via SUT to the destination, and then by the tester measure the throughput, latency and packet loss of SUT in various topologies. For the IPv6 performance test, there are four vendor's high-end IPv6 routers, with OC-48 POS ports on which throughput and latency will be measured, with IPv6 packet sizes of 64 bytes, 128bytes, 256 bytes, 512 bytes, 1024 bytes, 1480 bytes and 1500 bytes. The performance in various of circumstances were measured, including IPv4/IPv6 mixed traffics (IPv4 and IPv6 traffics with different ratio), IPv6 traffic with packet sizes mixtures, Sweep Packet Sizes. Also the maximum routing table entry supported and the performance on manually configured tunnels were verified. Most of the referred standards is extracted from RFC2544.

At present, there are deficient applications for IPv6, and the number of users in the IPv6 network can not be compared to IPv4. The sum of maximum IPv6 of IX(Internet eXchage) traffics is less

than dozens of Mbits/s. These traffics can be handled using a router refitted from a PC. Based on the circumstance, is it necessary to test the performance of OC48 ports ? Actually when the operators build IPv6 network and purchase IPv6 routers, today's IPv6 network is not under their consideration. Their networks should be able to deal with the changes and growth of IPv6 network next 5 - 7 years. In this sense, it is necessary for IPv6 core router to support the IPv6 traffic forwarding capacities at wire rate. Otherwise, what differences can be made between a real IPv6 router and a router refitted from a PC with installed BSD and Zebra ?

The measurement of the number of routing table entry also meets the same situations. At present, there're around 300-400 entries in the IPv6 backbone router routing table, which can't compared

to the huge number of IPv4 (110,000¼130,000 routes). Secondly, IPv6 has drawn experience and lessons from IPv4 in design and address assignment. RIR only assigns the large block and fixed length IPv6 addresses to IPv6 operators, instead of the end users. To some extent, this can protect IPv6 routing tables from the explosive growth. The strict prefix filtering mechanism was set on BGP4+ routers by most of IPv6 network administrators and the router only allows minor prefixes, such as /16, /24, /28, /32, /35 and etc. However, the experience of IPv4 teach us a lesson- “Money Talks!”. In the fiercely competitive ages, it is very difficult for operators to reject user's requirements. Under the conditions that IPv6 doesn't solve the problems of Multi-homing completely, it is possible that the network operators are required to broadcast users' network prefixes into global IPv6 routing tables in order to achieve Multi-homing applications. So far RIR has begun to assign /48 address segment to IPv6 of IX independently, while it is suggested IX doesn't broadcast the addresses. Thirdly, in many IPv6 networks, there are at least two IPv6 addresses segments, from 6BONE(3ffe::/16) and RIR(2001::/16) respectively, and maybe more prefixes will appear in the future. Fourthly, RIR can't ensure IPV6 addresses assigned to IPv6 operators are from a continuous address block. Current assignment policy indicates that /32 addresses of IPv6 assigned to operators can be continuously extended to /29. If new addresses are further required, they must be assigned to discontinuous address blocks and result in the growth of the number of routing tables. To sum up, the test team suggests that the number of IPv6 routing tables supported by the router should be no less than that of IPv4 routing tables, since it is very difficult to estimate the increasing number of routing tables of IPv6 core network right now.

In current IPv6 networks, commercial IPv6 network and IPv6 trial network (6BONE) are interlaced without a explicit boundary between them. A packet from commercial IPv6 network may go through many IPv6 trial network before arriving at another IPv6 network. The network administrators of many trial networks are not regarded as a “operators”, but a “players” It is pretty unstable of their networks, with routers reset very frequently. In the meantime, the networks advertise global IPv6 routes to all peers, making their own IPv6 network to implement transit. It causes the instability of current IPv6 of BGP routes, and thus it is required the capabilities of IPv6 routers cover the flapping and convergence properly, which should be included in this test, however due to limited test time frame, it is a pity the test team has to give up these tests.

The network topology used for the performance test is shown as following:

Ideally, the test topology should be as following, so that the packet forwarding capability of the routers in real-world network environment is shown completely.

Send one traffic from a source port of the tester, via multiple ports of the router to the destination ports of tester, measure the performance of the router. However as the vendors can't provide enough OC48 ports, the test team can only perform the test by simply sending packets from one port and receiving packets form another port. In this sense, this test environment can't simulate completely the performance of the router in the real-world network environment.

The Measurement of Throughput and Latency with Different IPv6 Packets Sizes at OC-48 POS port

Test Descriptions: To test the maximum IPv6 packet forwarding rate of SUT with zero packet loss with different IPv6 packet sizes.

Test Methods: Send IPv6 packets, via SUT to the destination ports of the tester, which measures the packet rate of SUT according to the received IPv6 packets. Set the initial offered load to 2%, and If no packet loss occurs, increase the offered load to 100% and repeat the test. If packet loss occurs, decrease the offered load to (100%+2%)/2=51%, repeat the test again……In a binary search manner, continue to increase or decrease the offered load in subsequent iterations until the difference in offered load between successful and failed tests is less than the resolution for the test. This is the zero-loss throughput rate.

Traffic forwarding mode: full duplex. Offered Packet type: IPv6;

Offered Packet size (bytes): 64 128 256 512 1024 1480 1500 Test duration of each packet type(s): 5

Bandwidth resolution (%): 0.1 Line BER tolerance (10^_): -10

The results are as follows:

Sustainable Throughput of OC-48 POS Port

105.00%

100.00%

95.00%

90.00%

85.00%

80.00%

75.00%

70.00%

65.00%

60.00%

55.00%

50.00%

64 128 256 512 1024 1480 1500

bytes bytes bytes bytes bytes bytes bytes

Test Packets Size

Average Latency (us) at Variable Test Packets Size

100

90

80

70

60

50

40

30

20

10

0

Test Packets Size

Hitachi

NEC

Fujistu Juniper

Hitachi NEC

Fujistu Juniper

Note: About inherent latency of tester

Before we perform tests, we must consider intrinsic latency of tester. The following table indicates inherent latency of tester for different test packet sizes when sending 100% offered load.

Inherent latency of tester (100% offered load)

Packet Size (bytes) 64 128 256 512 1024 1480 1500

Average Inherent 2.74 2.69 2.69 2.65 2.65 2.60 2.60

Latency (us)

From the above, the inherent latency of tester under different packet sizes is about 2.7us. Compared to the tens of us of SUT's latency, there are not significant impacts on the test results. In addition, the impact of inherent latency is fair to these 4 SUTs.

Forwarding Performance of IPv4/IPv6 Packets on OC48 Ports

Test Descriptions: To verify the performance of SUT to forward IPv4/IPv6 packets in offered packets sizes. The test requires SUT to support IPv4/IPv6 dual protocol stacks.

Test Methods: The tester sends IPv4 and IPv6 traffic simultaneously in full duplex configuration, via SUT to the destination port, measure the throughput and latency with various ratio of IPv4 and IPv6 traffic. Send traffic with 50% of IPv4 and 50% of IPv6 and 100% offered load first time. If packet loss occurs, decrease the offered load in 5% resolution until the difference in offered load between successful and failed tests is less than the resolution for the test. This is the zero-loss throughput rate. At the same time, measure the latency at maximum forwarding rate. Then change the ratio of IPv4 and IPv6 traffic to test again. Increase continuously the proportion of IPv6 traffic to simulate the change of traffic characteristics in the real-world network transition.

Test Descriptions:

Offered load (%): initial100% with 5% increment and final 0 Offered packet types: IPv6

Percentage of IPv4 and IPv6 traffic: 50:50—10:90 (IPv4:IPv6) Offered packet size (bytes): 62 512 1518

Test duration of each packet size(s): 5 The test results are as follows:

Sustainable throughput of OC-48 POS port at packet size 64 bytes with different percentage of

IPv4 and IPv6 traffic

Sustainable Throughput of OC-48 POS Port at Packet Size 64 bytes with different Percentage of IPv4 and IPv6 Traffic

105%

100% 95% 90%

85% Hitachi

80% NEC

75% Fujistu

70% Juniper

65% 60% 55% 50%

50/50 40/60 30/70 20/80 10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Sustainable throughput of OC-48 POS port at packet size 512 bytes with different percentage of IPv4 and IPv6 traffic

Sustainable Throughput of OC-48 POS Port at Packet Size 512

bytes with different Percentage of IPv4 and IPv6 Traffic

105%

100% 95% 90%

85% Hitachi

80% NEC

75% Fujistu

70% Juniper

65% 60% 55% 50%

50/50 40/60 30/70 20/80 10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Sustainable throughput of OC-48 POS port at packet size 1518 bytes with different percentage of IPv4 and IPv6 traffic

Sustainable Throughput of OC-48 POS Port at Packet Size 1518 bytes with different Percentage of IPv4 and IPv6 Traffic

105%

100% 95% 90%

85% Hitachi

80% NEC

75% Fujistu

70% Juniper

65% 60% 55% 50%

50/50 40/60 30/70 20/80 10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Average latency (us) at test packets size 64 bytes with different percentage of IPv4 and IPv6 traffic

Average Latency (us) at Test Packets Size 64 bytes with

Different Percentage of IPv4 and IPv6 Traffic

100

90

80

70

60

50

40

30

20

10

0

50/50 40/6 30/70 20/80 10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Hitachi

NEC

Fujistu Juniper

Average latency (us) at test packets size 512 bytes with different percentage of IPv4 and IPv6 traffic

Average Latency (us) at Test Packets Size 512 bytes with Different Percentage of IPv4 and IPv6 Traffic

100

90

80

70

60

50

40

30

20

10

0

50/50 40/60 30/70 20/80 10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Hitachi

NEC

Fujistu Juniper

Average latency (us) at test packets size 1518 bytes with different percentage of IPv4 and IPv6 traffic

Average Latency (us) at Test Packets Size 1518 bytes with

Different Percentage of IPv4 and IPv6 Traffic

100

90

80

70

60

50

40

30

20

10

0

50/50 40/60 30/70 20/80     10/90

IPv4/IPv6 Test Packets Percentage (IPv4/IPv6)

Hitachi

NEC

Fujistu Juniper

IPv6 over IPv4 Configured Tunneling Performance of OC-48 POS Port

Test Description: Tunneling technology is an effective means to connect separate IPv6 networks via IPv4 backbone. This item is to verify the performance of SUT when SUT encapsulates IPv6 data packets into IPv4 payload and forwards the packets.

Test Method: The tester sends IPv6 data packets to SUT, and configures an IPv6 over IPv4 tunnel between SUT and the tester. Thus after SUT receives pure IPv6 packets from the tester, it will encapsulate it into IPv4 packet payload, and send IPv6 packets to destination over IPv4 network. The tester analyzes the packets forwared by the SUT at receiving end, calculates the throughput of SUT for different sizes of packets under the IPv6 over IPv4 configured tunnel. Test Results:

IPv6 packet size: 512

Destination address of sending IPv6 data packets: 3FFE:0:0:4::2/64

Bandwidth range of sending IPv6 traffics: 10% to 100% with 20% increment Duration of sending IPv6 traffics (s): 5

IPv6 over IPv4 Configured Tunneling Performance of OC-48 POS Port

IPv6 over IPv4 Configured Tunneling Performance of OC-48

POS Port

100%

90% 80%

70%

60%

50%

40%

30%

20%

10%

0%

10 30 50 70 90

Offered Traffic Load(%)

IPv6 Sweep Packet Size Test

Hitachi

NEC

Fujistu Juniper

Test Description: This item is to test the forwarding performance of SUT for various packet sizes. The test is designed to find whether there are some problems in the internal structure affecting the forwarding performance for a specific size of packets.

Test Method: We test the packet loss of SUT for various packet sizes within some range under 100% load.

Test Results:

Range of IPv6 packet size: 64 bytes - 1518 bytes; Increased in 80 bytes increment;

Bandwidth of sending test traffics: 100%; Traffic sending mode: Bi-directional

The test results of sweep packet size of OC-48 POS port

Sweep Packet Size of OC-48 POS Port

100.00%

90.00%

80.00%

70.00% Hitachi

60.00% NEC

50.00% Fujistu

40.00% Juniper

30.00%

20.00%

10.00%

Test Packets Size

Throughput When Handling Mixed IPv6 Test Packet Sizes

Test Description: The item is to test the throughput of SUT for various mixed sizes of packets and to simulate the traffics in the real world IPv6 network. Therefore, this test can verify the performance of SUT on the real-world Internet network more realistically. Test Method: The tester sends test traffics containing different sizes of packets, the packets are forwarded to destination port of the tester via SUT. The network load is 100% when the tester initially sends packets. Then “binary search” test method is used to repeat the test until the maximum IPv6 data packet forwarding rate of SUT is detected with zero packet loss.(Note: cause there is no IPv6 traffic analyze as a reference, test team randomly select 64/512/1518 as representative packet length)

Test Results:

Sent packet types: IPv6

Accuracy of sent traffics: 1% of maximum bandwidth

Test packet size (bytes) % percentage

6  55.000

512 15.000

1518 12.000

64 to 1518 18.000

Table 3-3 Test results of throughput with OC-48 POS mixed packet sizes

24

SUT Hitachi Fujitsu Juniper NEC

ThroughPut 100% 100% 100% 99.219%

Maximum Number of Routing Table Entries

Test Description: The tester finds the maximum number of routes that can be received by the SUT. Test Method: The tester sends routes to SUT, the sent routes is increased until the routes of SUT will not increase, then take the current number of routes.

Test Results:

Maximum learnt routes

Hitachi GR2000-20H 25000

NEC CX5210 4000

Fujitsu GeoStream R920 29998

Juniper M20 1000000

Note: After M20 learns 1,000,000 routes, in fact it can still receive more routes. But the test team think it is no sense to continue the test because 1,000,000 routes are enough to handle the foreseeable growth of IPv6 network.(Note: 1.The number of routing table entries is related with the memory size of CPU card of the router.2.When a core router is going to forward a packet, commonly, it will search the FIB table in line card instead of main routing table in CPU card, the size of FIB is usually smaller than main routing table's size)

Acknowledgements

Firstly thanks my colleagues Zhang Haofeng, Ma Min and Wang Xin, who are excellent engineers in BII and perform a lot of test and preparation works. They make use of their expertise to solve many technical problems. This test will not be completed without their hard work. I shall thank Jerome Renner, Zlata Trhuji, Brett White, Liang Yong and Wang Li from Agilent, who provide strong technical support for the test team. I am impressed with their professional spirits and expertise.

About BII

BII Co., Ltd. is evolved from Beijing Internet Institute which was founded in 1995. BII is based in Beijing, China, and as a premier IT R&D and market development firm in China, BII participates directly in the growth of Internet and telecommunication IP network in China. BII has cooperated closely not only with Chinese government , IT and other industries in China, but major research institutes and companies in USA, Japan and Europe in R&D and market development as well. BII has powerful and strong partnership program and rich customer resources. Close and broad cooperation mechanism ensures BII can always understand the latest dynamics of telecommunication and Internet industries in China and in the world, and always lead the development of technologies and solutions.

In 1999, BII formally set up the first IPv6 R&D center in China and has made many efforts in the initial technical research and market tracking since then. In 2000, BII formed the first IPv6 commercial test bed in China, which is connected to 6BONE, the largest IPv6 trial network in the world. In 2001, BII and Information Network Center of Beijing Post and Telecom University cooperated to establish BUPT-BII Next Generation Network R&D Center, building a trial environment to transmit broadband video via IPv6. In March, 2002, BII and RITT (Research Institute of Telecommunication Transmission) of MII cooperated to establish 6Tnet (IPv6 Telecom Trial Net), which is the first IPv6 trial network for commercial multi-operators and multi-vendor interworking in China. In May, 2002, BII and local operators cooperated to establish the first commercial carrier-class IPv6 network in China.

BII is the only total solution provider committed to carrier-class IPv6 solution in China at present. BII is equipped with an excellent engineering team and can provide complete solution and full range of services, from network planning and design, network building, network management, application system development and technical support to service operation planning and cooperation in China and overseas.

About Agilent

Agilent Technologies is on the leading edge of nearly every major trend in communications and life sciences. From optical and wireless communications to disease and discovery research, Agilent delivers product and technology innovations that benefit millions of people around the world. Leading companies - communications equipment manufacturers, Internet service providers, biopharmaceutical companies and more - depend on Agilent's more than 20,000 test, measurement and monitoring devices, semiconductor products and chemical analysis tools to help drive the communications and life sciences revolutions that transform the modern world.

Agilent's RouterTester system offers a powerful and versatile test platform to address the evolving

test needs of metro/edge platforms, core routers and optical switches. RouterTester provides

Network Equipment Manufacturers and Service Providers with the industry's leading tools for wire speed, multiport traffic generation and performance analysis of today's networking devices.

Agilent's industry-leading RouterTester provides thorough and accurate testing of IPv6 devices. Our highly scalable test solution enables testing of the operation, conformance, performance, and scalability of IPv6 control (BGP4+, ISISv6, OSPFv3 and RIPng )and data planes simultaneously.

Appendix

IPv6 BGP4+ protocol conformance test results:

Note: C: Compliant NC: Not compliant NS: Not supported in current version Inc:

Inconclusive

Suite Test Item Test Description

bgp4_rfc_2858_1 bgp4P_rfc_2858_1 Verify IBGP and EBGP

sessions can support BGP

multi-protocol extension

bgp4P_rfc_2858_2 When SUT advertises route

updates to EBGP, its next hop

will be modified into its own

IPv6 interface address

bgp4P_rfc_2858_6 When SUT advertises route

updates to IBGP, its next hop

will not be modified

bgp4P_rfc_2858_8 Route update message

carrying MP_REACH_NLR

NEC Fujitsu Hitachi Juniper

CX5210 GeoStream GR2000-M20

R920 20H

C* C C C

C C C C

C C NC* C

C C C C

bgp4P_rfc_2858_9 bgp4P_rfc_2858_10

must carry ORIGIN and

AS_PATH properties, and must carry local preference property for IBGP

C C C C

C C C C

bgp4P_rfc_2858_11 For route updates of EBGP,NC NC NC NC

the most left AS number in

path property should be AS

number of peers

bgp4P_rfc_2858_12 Route update not carryingC C NC C

NLRI should contain

MP_REACH_NLRI property and should not carry NEXT_HOP property

bgp4P_rfc_2545_1 If BGP peers share aC C NC C

subnetwork and use a global

IPv6 address, link-local

address should be contained in Next Hop

bgp4P_rfc_2545_2 BGP peer can containC C C C

link-local IPv6 address in the next hop when it advertises route update to internal peer

bgp4_rfc_2858_2 bgp4P_rfc_2858_3 SUT, internal and externalNC C C C

peers are located in a same subnetwork. The next hop in route update received by EBGP peer from SUT should be IPv6 address of internal peer

bgp4P_rfc_2858_5 BGP session party should useC C C C

route update in which the next hop is not advertised as peer address. Or if the peer receives such a route update, it should refuse

bgp4_rfc_2858_3 bgp4P_rfc_2858_4 SUT and multiple externalC C C C

peers should be located in a same subnetwork. The next hop in route update received by EBGP peer from SUT should be IPv6 address of external peer that sends route update

draft_ietf_idr_sect4- bgp4P_sect4_3_a Verify SUT can properlyC C C C

10_1 advertise all possible effective

ORIGIN property in the route

updates it receives

bgp4P_sect5_1_2 Verify SUT should not modifyC C C C

AS_PATH property when it

advertises route updates to

internal peers

bgp4P_sect5_1_5 Verify SUT should ignore andC C C C

should not re-advertise

LOCAL_PREF property and send this LOCAL_PREF value to internal peers if LOCAL_PREF is contained in the route update SUT receives

bgp4P_sect5_case2 The order of each property inC C C C

path property should not

affect SUT to properly receive

and advertise route updates

bgp4P_sect5_case3 The times that each propertyC C C C

in path property appears

should be no more than once

bgp4P_sect6_3_case Verify SUT uses AS_PATHC C NC C

7 property to prevent route loop

bgp4P_sect9_1_2_1_ Select optimal route.C C C C

c EGP>IGP

bgp4P_appendix6_1 A route update can containC C C C

multiple NLRI

draft_ietf_idr_sect4- bgp4P_sect9_2_1_1_ Select optimal route. LowerC C C C

10_1_1 c BGP Router ID is preferred

draft_ietf_idr_sect4- bgp4P_sect4_2 Verify SUT can establishC C C C

10_2 properly the session with

IBGP and EBGP

bgp4P_sect4_3e Verify SUT should sendC C C C

default LOCAL_PREF value

to internal peers.

bgp4P_sect4_3_case Verify SUT can advertiseC C C C

1 multiple available or

unavailable IPV6NLRI and

route update with at least 23

bytes

bgp4P_sect6_3_case Verify SUT will not accept theC C C C

1 route update with collision of

path and pointer and will send a Notification message with Error Code 3, Error Subcode

bgp4P_sect6_3_case Verify SUT will not accept theC C C C

6 route update with invalid

ORIGIN value of path property and will send a Notification message with Error Code 3, Error Subcode

bgp4P_sect6_3_case Verify SUT will not accept theC C C C

8 route update with multiple

same type of route properties and will send a Notification message with Error Code 3, Error Subcode 1

bgp4P_sect6_3_case Verify SUT will not close theC C C C

9 session with peers when it

receives the route information

with no NLRI path property

sent by the peers

bgp4P_sect9_1_1_ca Verify SUT should send setC C C C

se2 LOCAL_PREF value to

internal peer

bgp4P_sect9_1_2_ca Verify SUT will advertise theC C C C

se1 rout to the peers when it finds

NEXT_HOP unavailable

bgp4P_sect9_2_1_ca Verify SUT should not takeC C C C

se3 any action when it receives a

removed route about the

route it did not receive

previously

bgp4P_sect9_2_2_ca Verify SUT should remove theC C C C

se2 route when it receives a

removed route about the route it received previously. Verify SUT should update the route when it receives a route update message about the route it received previously

draft_ietf_idr_sect4- bgp4P_sect5_1_4 Verify SUT will not transferC C C C

10_3 MED property between

multiple external peers

bgp4P_sect5_1_6 Verify SUT should not deleteC C C C

previous property when it advertises the route update with ATOMIC_AGGREGATE property

bgp4P_sect5_case1 Verify SUT should not transferC NC C C

non-interim property and

should transfer interim

property

bgp4P_sect8_case1 Verify the interaction ofC C C C

BGP4+ status machine between SUT and peers

bgp4P_sect8_case2 Verify the ability of SUT toC C C C

initialize TCP connection to peers

bgp4P_sect9_case1 Verify SUT should remove theC C C C

route when it receives the message of removal of one

route that it received

previously

bgp4P_sect9_I Verify SUT should update theC C C C

route when it receives the message of update of one

route that it received

previously

bgp4P_sect9_iv Verify SUT should add theC C C C

route when it receives the update message of one route that it did not receive previously

29

bgp4P_sect9_1_3_c Verify SUT receives a routeC C C C

update information before establish a session with another peer and properly sends the route update information after establishing a session

bgp4P_sect9_2_2_ca Verify SUT should remove theC C C C

se1 route when it receives

message of removal of one

route that it received

previously. (The route

information contains multiple

AS sequences)

draft_ietf_idr_sect4- bgp4_sect9_2_1_cas Verify the route update ofC C C C

10_4 e1 IBGP peer received by SUT

will not be advertised to

another IBGP peer

draft_ietf_idr_sect4- bgp4_sect4_3_b Verify SUT should advertiseC C C C

10_5 properly AS_PATH property

value

bgp4_sect9_1_1_cas For NLRI with same lengthC C C C

e1 AS path, that with higher local

preference value will be

advertised by SUT to EBGP

peer

bgp4_sect9_1_2_1_d Select optimal route. SmallerC C C C

_case2 BGP Router ID is preferred

¼ˆ The route information

contains multiple AS

sequences¼‰

bgp4_sect9_2_1_cas Verify SUT will advertise theC C C C

e2 route updates received from

EBGP to all IBGP peers

bgp4_sect9_2_1_cas Select optimal route.C C C C

e5 EGP>IGP

draft_ietf_idr_sect4- bgp4_sect9_1_2_1_a Select optimal route. SmallerC C C C

10_6 MED value is preferred

bgp4_sect9_2_1_cas Select optimal route. SmallerC C C C

e4 BGP Router ID is preferred

bgp4_sect9_2_1_1_a Select optimal route. SmallerC C C C

MED value is preferred. That

with No MED is preferred than

that with MED

draft_ietf_idr_sect4- bgp4_sect9_1_2_1_d Select optimal route. SmallerC C C C

10_6_1 _case1 BGP Router ID is preferred

bgp_rfc_1997 bgp4_communities_1 Verify SUT will not advertiseNS* C C C

to EBGP peers when it receives the route update with

communities value of

NO_EXPORT

bgp4_communities_2 Verify SUT will not advertiseNS C C C

to IBGP and EBGP peers when it receives the route update with communities value of NO_ADVERTISE

bgp4_communities_4 Verify SUT will advertise toNS C C C

IBGP and EBGP peers with

no change when it receives

the route update with

communities value of general

figures

bgp_rfc_1997_appe bgp4_communities_5 Verify SUT can appendNS C C C

nd communities property value of

general figures into received route updates and will advertise route updates to IBGP and EBGP peers

bgp_rfc_1997_noad bgp4_communities_7 Verify SUT can appendNS C C C

vertise communities property value of

NO_ADVERTISE into

received route updates and will not advertise any route

30

updates to IBGP and EBGP peers

bgp_rfc_1997_noex bgp4_communities_6 Verify SUT can appendNS C C C

port communities property value of

NO_EXPORT into received route updates and will not advertise any route updates to EBGP peers

bgp_rfc_2796_1 bgp4_reflect_sect5_2 Verify SUT as a route reflectorNS C C C

can reflect route updates from

clients to non clients and

other clients

bgp4_reflect_sect7_c Verify SUT as a route reflectorNS C C C

ase1 will create an

ORIGINATOR_ID value when

it reflects route updates. If

received route update

contains ORIGINATOR_ID,

SUT will not create it

bgp4_reflect_sect7_c Verify SUT as a route reflectorNS C Inc C

ase2 will ignore the route update if

received route update

contains ORIGINATOR_ID

and it is same as IP address

of SUT

bgp4_reflect_sect7_c Verify SUT as a route reflectorNS C C C

ase3 will create a CLUSTER_LIST

and put its own CLUSTER_ID

into CLUSTER_LIST if

CLUSTER_LIST in received

and reflected route update is

null. If CLUSTER_LIST exists,

it will append its own

CLUSTER_ID into

CLUSTER_LIST

bgp4_reflect_sect7_c Verify SUT as a route reflectorNS C C C

ase4 will discard the route update if

CLUSTER_ID value is same as its own value. UPDATE is sent from emulated non clients

bgp4_reflect_sect8_c Verify SUT as a route reflectorNS C C C

ase1 will not modify NEXT_HOP,

AS_PATH, LOCAL_PREF,

and MED property values of

client route updates

bgp_rfc_2796_2 bgp4_reflect_sect6_c Same asNS C C C

ase1 bgp4_reflect_sect7_case4,

but UPDATE is sent from emulated RR

bgp_rfc_2796_3 bgp4_reflect_sect5_1 Verify SUT as a route reflectorNS C C C

reflects all route updates from non clients to clients and other non clients can't receive route updates

bgp_rfc_3065_1 bgp4_confederation_1 Send route updates betweenC NS C C

IBGP and EBGP within a Federation with AS_PATH

property of

AS_CONFED_SEQUENCE

bgp_rfc_3065_2 bgp4_confederation_2 Send route updates betweenNC NS C C

EBGPs within a Federation with AS_PATH property of AS_CONFED_SEQUENCE

bgp4_confederation_7 Send route updates betweenC NS C C

EBGPs within a Federation with next hop not modified

bgp4_confederation_8 Send route updates betweenC NS C C

EBGPs within a Federation with MED value not modified

bgp4_confederation_9 Send route updates betweenC NS C C

EBGPs within a Federation with local preference value not modifiedbgp_rfc_3065_3 bgp4_confederation_3 Federation AS_PATHC NS C C

modification rule

bgp4_confederation_4 Federation AS_PATHC NS C C

modification rule

bgp4_confederation_5 Federation AS_PATHC NS C C

modification rule

bgp4_confederation_6 Federation AS_PATHC NS C C

modification rule