STF 276 Colloquium June 22 nd 2005 1

STF 276 Colloquium June 22 nd 2005 1

Structure of this Presentation q q Introduction to IPv 6 Benefits and Driving Forces Overview of STF 276 IPv 6 Interoperability testing Ø Steve Randall q STF 276 IPv 6 Conformance testing Ø Peter Schmitting q STF 276 IPv 6 testbed and validation Ø Alexandre Berge q STF 276 IPv 6 test specification library and close Ø Anthony Wiles 2

What Is IPv 6? q ‘New’ version of current Internet Protocol (IPv 4) Ø Next Generation Internet (IPng) q First proposed in the early 1990’s Ø Many candidates q Proponents include early IP pioneers such as Vint Cerf: “IPv 6 takes the Internet where no other network has been before” q Why do we need it and is it better? q Is it being adopted? q And where is ETSI on the IPv 6 Roadmap? 3

Hugely Increased Address Space q PROBLEM: IPv 4 is running out of addresses q IPv 4 has 32 bit addresses Ø roughly the same as the number of a bucket full of sand grains q IPv 6 has 128 bit addresses Ø roughly the same as the number of sand grains in the volume of sun. q So everyone and everything could have its own unique IP address Ø Ø But the allocation mechanism is wasteful so the address space is not ‘infinite’ Maybe not even enough for emerging NGN ubiquitous computing • e. g. , even disposable items (like a can of beans in your fridge) q FE 80: 0000: 0202: B 3 FF: FE 1 E: 8329 q FE 80: : 202: B 3 FF: FE 1 E: 8329 q OPPONENTS: Problem is solved for maybe 5 -10 yrs with NATs and other tricks Ø Ø OK for the US maybe Asia and the Pacific rim need the address space! 4

More ‘Efficient’ Header IPv 6 Header Variable length payload up to 64 KB q PROBLEM: IPv 4 headers not the most efficient (variable length) q IPv 6 has fixed length header (40 bytes) Ø Tailored for fast throughput and to run on Giga Ethernet and ATM q IPv 6 Fields Ø Ø Ø Ø Version Class Flow Label (for Qo. S and efficiency) Payload Length (max 64 KB, but jumbograms allowed) Next Header (value 59 means no next header) Hop Limit Source Address Destination Address q OPPONENTS: IPv 6 packets are too large! Extension headers require processing similar to IPv 4 5

Extension Headers for Options IPv 6 Header Ext. Header 1 Ext. Header 2 Ext. Header n q Used to specify protocol options such as: q Hop-by-hop options header Ø Specifies actions to be taken by each router in the path (e. g. , RSVP). Without this header routers can ignore the extension headers (efficient as some options are endto-end). q Routing header Ø Specifies explicit nodes (routers) that must be in the path q Fragment header Ø Fragmentation of large payloads (negotiated through MTU) q Destination options header Ø Info for destination node (e. g. , to carry home address in mobile IP) q Authentication header Ø Security q Encrypted Security Payload header Ø Security 6

Plug ‘n Play q Auto configuration Ø Eliminates need for manual configuration of hosts Ø Especially useful for example in devices at home Ø But also for large networks q Manual configuration possible Ø Stateful configuration (using DHCP) q Use local information (e. g, MAC address) and Router information Ø Router Advertisments provide router specific prefix Ø DAD (Duplicate Address Detection) algorithm ensures uniqueness Router provided prefix Site Local Address (SLA) 7

Built-in Security q Security Framework known as IPSEC q Security elements of IPv 6 Ø General description of security requirements an mechanisms (security architecture) Ø Payload encryption (extension header) Ø Authentication (extension header) Ø Algorithms for encryption and authentication Ø Security policies Ø Key management 8

Support for QOS q Not just an IPv 6 issue but there are some mechanisms in IPv 6 that facilitate Qo. S q Several Qo. S paradigms Ø End system based Qo. S e. g. , extrapolation of missing data, error recovery etc. Ø Service-based Qo. S Ø Class/priority based Qo. S Ø Resource reservation (RSVP) q Not defined by IPv 6 but the Ø Ø Flow Label (real-time flows, for example) Class (to request differentiated services) Routing header (to request specific route) Hop-by-hop header (can be used to request specific handling of each packet by each router) 9

Mobility 3 payload 3 1 payload 1 1 HA IPv 6 IPv 4 payload 3 2 FA 3 1 payload 1 1 Destination Hdr 1 3 2 3 3 1 payload 2 2 Destination Hdr 1 2 payload 10

Transitioning q Gradual transition envisaged Ø No sudden emergence of IPv 6 q Two main transmission mechanisms Ø Dual stacks Ø Tunnelling Application IPv 4 Application IPv 6 11

Other IPv 6 Protocols q q ICMPv 6 OSPFv 3 RIPng DHCP for v 6 q TCP and UDP should not be affected but. . . q Application protocols such as HTTP, FTP and Telnet clients need to make connections with both IPv 4 and IPv 6 servers 12

Summary of Benefits q q q q Vast address space Cheaper, faster routers Plug ‘n Play Better Security Support Qo. S Built-in Mobility Phased transition mechanisms q So, IPv 6 is more efficient, more secure, more flexible, gives true end-to-end communication etc. . . q. . . but is there a business case? Ø There is a HUGE legacy in IPv 4 13

Driving Forces q Slow start but uptake is increasing Ø IPv 6 will happen q Military Ø US Do. D and NATO q EU Ø IPv 6 infrastructure Ø e. Europe, e. Everything q 3 GPP and NGN Ø Adoption of IPv 6 in IMS q Technically developing regions Ø Regions that do not have a lot of IPv 4 address space allocated to them • E. g. , Asia and the Pacific rim Ø New networks and infrastructures • Why put in IPv 4? q Applications Ø Ø Peer-2 -Peer applications Grid computing Ubiquity (e. g. , automotive) Those that need security 14

Awareness, Promotion etc. q IPv 6 Forum q IPv 6 Task Forces Ø North America, Europe, Asia etc. q Regular Global IPv 6 Summits q IPv 6 Ready Ø Ø Certification Scheme Plugtests. TM very active q Many large ETSI members Ø Ø Vendors Operators IMS will be important for IPv 6 NGN (well, its IMS based to start. . . ) q Experimental networks Ø Ø Ø 6 Bone, Moonv 6, Euro 6 IX, various operators Core network. . . and applications (e. g. , Vo. IP) q. . . and STF 276 15

STF 276@Work 16

STF 276 q TC MTS project to produce test specifications for interoperability of IPv 6 products Ø Ø Ø Led by PTCC e. Europe funding Significant voluntary expert contribution by ETSI members (at least 134 days in 2005) q Two phases Ø Ø IPv 6 core RFCs (Ongoing) IP SEC (estimated start October 2005) Mobile IP (estimated start October 2005) Ipv 4 – IPv 6 Transitioning (estimated start Jan 2006) q IPv 6 Test Framework q Requirements Catalogue q Test specifications Ø Ø Ø Interoperability test specifications Conformance test specifications Library of TTCN-3 test code freely available q All tests are validated Ø Ø On STF 276 Testbed By member companies q For more info visit: www. ipt. etsi. org 17

Major Players q ETSI members: Ø Mainly vendors Ø Require IPv 6 test specifications using ETSI methods and test languages Ø A component designed to be part of 3 GPP’s IPv 6 testing strategy (when it starts) q European Commission: Ø Mandate for IPv 6 device interoperability Ø Amplify Europe’s voice in IPv 6 testing q Aligned with the IPv 6 Logo Program 18

STF 276 Members STF 276 Participants 1 AW Anthony Wiles (STF leader) ETSI PTCC Manager 2 AF Annie Floch IRISA 3 BG Basavanna Gowda Motorola 4 CO César Olvera Consulintel SL / IPV 6 Forum 5 ECT Emmanuelle Chaulot-Talmon ETSI PTCC Assistant 6 DT Dirck Tepelmann Testing Technologies 7 LV Laurent Vreck ETSI Technical Officer 8 PK Péter Krémer Ericsson 9 PS Peter Schmitting FSCOM 10 RC Ranganai Chaparadza FOKUS 11 SAM Scott Moseley Farbum Scotus 12 SM Sebastian Mueller FSCOM 13 SR Steve Randall PQM Consultants 14 SS Stephan Schulz NOKIA 15 XF Xiaoming Fu IITB 19

Task Leaders q STF task leaders Ø IPv 6 Testing Framework • Steve Randall Ø Requirements Catalogue • Scott Moseley Ø Conformance Test Specs • Peter Schmitting Ø Interop Test Specs • Steve Randall Ø Validation testbed • Sebastian Mueller q For more info visit: www. ipt. etsi. org 20

Requirements Process 21

The Requirements Catalogue q Our approach to Requirements Engineering Ø Phase 1 has 6 RFCs, 200 pages of specification containing approximately 1, 000 requirements Ø Requirements types: MUST, SHOULD, MAY, NOTs Ø Group of requirements may be spread across several documents Ø Three requirements subjects: Node, Host, and Router Ø Need a link between requirement source and resulting test purpose and test case/description Ø Multiple user needs for requirements 22

The Requirements Catalogue (cont’d) q Basic Concepts Ø A scalable database containing all requirement elements Ø HTML view of selected database elements Ø HTML links between RFC, requirement, test purpose, and test case/description Ø Mapping between RFC and IPv 6 Logo requirements Ø Mapping between RFC and 3 GPP requirements Ø A user-extendable tool to identify requirements for procurement or implementation 23

Example Requirement 24

Interoperability Process 25

Interoperability Test Purposes q q q Defines the function being tested—the WHAT Does not define HOW to test the function Grouped to form a logical structure One Requirement may derive several TPs An interoperability TP is on the functional level Specified in ETSI’s Test Purpose Language (TPLan) 26

Test Purpose Language (TPLan) q Keywords and syntax provide clear and consistent structure q Keywords chosen for communications applications (sends, receives etc. ) q Text between keywords not part of syntax so free expression possible q A TP’s basic structure (corresponding keyword): Ø Ø Header (TP id) Pre-conditions (with) Stimulus (when) Expected response (then) 27

TPLan Example for Interoperability TP id Summary RQ ref Config TD ref : : : TP_COR_1719_02 'EUT sends packet to All-RT LL M/cast address' RQ_COR_1719 CF_021_I TD_COR_1719_02 with { QE 1 'configured as a router' and QE 2 'configured as a router'} ensure that { when { EUT is requested to 'send packet to All-Routers Link-Local M/cast addr' } then { QE 1 indicates 'receipt of the packet' and QE 2 indicates 'receipt of the packet' } } 28

Interoperability Test Descriptions q Specify detailed steps to be followed to achieve stated test purpose q Steps are specified clearly and unambiguously without unreasonable restrictions on actual method: Ø Example: • Answer incoming call NOT • Pick up telephone handset q Written in a structured and tabulated natural language so tests can be performed manually q Can be automated using TTCN‑ 3 when EUT has software interfaces 29

Example Test Description Test: COR_001_02 Selection Criteria: Mandatory Title: ensure that { when { etc………. Pre‑test conditions: Yes Auto configure QE using a unique address in a simple network Test Purpose: Selected: Step Configure the equipment to ensure that QE 1 will not intend to use the same link-local address than the one used by EUT (EUT and QE 1 interfaces carry different Interface identifiers and both run stateless autoconfig, or EUT Link-Local address configured manually). EUT interface is up and carries a link-local address QE 1 interface is down Verdict Test description Pass 1 Check: 4 Check: Yes No QE 1 sends an echo request to the Link-Local address of EUT 5 No EUT sends an echo request to the Link-Local address of QE 1 3 Yes Turn on QE 1 interface and wait a few seconds 2 Fail does EUT receive an echo reply from QE 1? does QE 1 receive an echo reply from EUT? Observations: 30

Conformance Process 31

Conformance Test Purposes q q q Defines WHAT is tested Does not define HOW to accomplish the test Grouped to form a logical structure One Requirement may require many TPs A conformance TP is on the protocol level Specified in ETSI’s Test Purpose Language (TPLan) 32

TPLan Example for Conformance TP id : TP_COR_0047_01 Summary : ‘hop limit of one' RQ Ref : RQ_COR_0047 Config : CF_02_C TC Ref : TC_COR_0047_01 ensure that { --Stimulus when { IUT receives ‘Ipv 6 packet' from ‘HS' containing ‘IPv 6 Header' indicating ‘Hop limit' set to ‘ 1‘ } --Expected response then { IUT sends ‘ICMPv 6 Time Exceeded' to ‘HS‘ containing ‘ICMP code' set to ‘ZERO‘ } } 33

Conformance Test Cases q Detailed TTCN-3 test script that implements test purpose Ø can be compiled and executed q Composition Ø a preamble Ø test body (i. e. , implementation of the Test Purpose) Ø A postamble q Assigns test verdicts q Handles unexpected behaviour as well as the behaviour in the test purpose q Can be distributed over parallel test components q Can be entirely automated q Configurable at run-time, e. g. , SUT address 34

What is TTCN-3? q q Internationally standardized testing language Look and feel of a regular programming language Allows unambiguous implementation of tests Independent of execution environment due to separate test system interface standards q Wide range of applications from mobile (radio) communications to Internet to software q Good tool support q Good book: Ø http: //eu. wiley. com/Wiley. CDA/Wiley. Title/product. Cd 0470012242. html 35

Example TTCN-3 Test Case testcase TC_COR_0047_01() runs on Ipv 6 Node system Ether. Net. Adapter { f_cf 02 Up(); // Configure test system for HS->RT // No preamble required in this case f_TP_Hops. Set. To. One(); // Perform test // No postamble required in this case f_cf 02 Down(); // Return test system to initial state } function f_TP_Hops. Set. To. One() runs on Ipv 6 Node { var Ipv 6 Packet v_ip. Pkt; var Fnc. Ret. Code v_ret : = f_echo. Time. Exceeded( 1, v_ip. Pkt ); if ( v_ret == e_success and v_ip. Pkt. icmp. Code == 0 ) { setverdict(pass); } else { setverdict(fail); } } function f_echo. Time. Exceeded(in UInt 8 p_hops, out Ipv 6 Packet p_íp. Pkt ) runs on Ipv 6 Node return Fnc. Ret. Code { var Ipv 6 Packet v_ip. Packet; var Fnc. Ret. Code v_ret; ip. Port. send( m_echo. Req. With. Hops(p_hops) ); alt { [] ip. Port. receive( mw_any. Time. Exceeded ) -> value p_ip. Pkt { return e_success } [] ip. Port. receive { return e_error } } 36 }

Validation Platform Open Source Op. Syst. • Free. BSD • Fedora Core Linux • Red. Hat Linux Internet ü Remote controllable ü Secured (Private key + Pwd) ü Validate our own test suites locally SSH (secured remote control) R IPv 4 control network R H H IPv 6 testbed R 37

Validation Platform Open Source Op. Syst. • Free. BSD • Fedora Core Linux • Red. Hat Linux Internet ü Remote controllable ü Secured (Private key + Pwd) ü Validate our own test suites locally SSH (secured remote control) & remotely R H H IPv 6 testbed R R 38

STF 276 IPv 6 test bed IPv 4 @ only Internet (IPv 4) Test networks IPv 6 @ only SSH ETSIHQ (secured remote control) Oleane control network 172. 27. x. x CUxxx . 17 172. 27. 1. 1 UUnet . 253 . 57 ETSI_ONLINE 212. 234. 161. x Mask: 255. 0 PLUGTESTS 212. 234. 160. x 212. 234. 161. 1 . 252 FW ETSI_PUBLIC 217. 167. 116. 1 PF 1000: 2001: 660: 5503: 1000 /64 PF 6: 2001: 660: 5503: 6 /64 Ns 6. etsi. org renaters : : 1 R 6 Wind 2 Mb FErouter 1 Fedora core 3 meeting : : 6 inrias : : 2 PF 3000 IPv 6 RHhost 2 Linux Redhat ES 4 + TTCN-3 tools FBrouter 5 Free. BSD 5. 3 RHhost 3 Linux Redhat ES 4 + TTCN-3 tools FBrouter 4 Free. BSD 5. 3 A B PF 276 a: 2001: 660: 5503: 276 a /64 PF 276 b: 2001: 660: 5503: 276 b /64 39

Library Process 40

The TTCN-3 Library q Each test uses this library Ø Decreases test code size and improves its quality Ø Reduces time to develop new tests q Contains useful definitions for different purposes Ø Ø Ø Test component synchronization Basic IPv 6 packet exchanges Preamble, test purpose, and postamble code Test configurations Code for driving upper IPv 6 interface • for conformance testing • and automated interoperability testing q Extensively documented q Easily add tests to test suites 41

IPv 6 Test Library 42

Thank You! 43