STF 276 Colloquium June 22 nd 2005

1. STF 276 ColloquiumJune 22nd 2005

2. Structure of this Presentation • Introduction to IPv6 • Benefits and Driving Forces • Overview of STF276 • STF 276 IPv6 Interoperability testing • Steve Randall • STF 276 IPv6 Conformance testing • Peter Schmitting • STF 276 IPv6 testbed and validation • Alexandre Berge • STF 276 IPv6 test specification library and close • Anthony Wiles

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

4. Hugely Increased Address Space • PROBLEM: IPv4 is running out of addresses • IPv4 has 32 bit addresses • roughly the same as the number of a bucket full of sand grains • IPv6 has 128 bit addresses • roughly the same as the number of sand grains in the volume of sun. • 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) • FE80:0000:0000:0202:B3FF:FE1E:8329 • FE80::202:B3FF:FE1E:8329 • OPPONENTS: Problem is solved for maybe 5-10yrs with NATs and other tricks • OK for the US maybe • Asia and the Pacific rim need the address space!

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

6. Ext. Header 1 Ext. Header 2 IPv6 Header Ext. Header n Extension Headers for Options • Used to specify protocol options such as: • 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 end-to-end). • Routing header • Specifies explicit nodes (routers) that must be in the path • Fragment header • Fragmentation of large payloads (negotiated through MTU) • Destination options header • Info for destination node (e.g., to carry home address in mobile IP) • Authentication header • Security • Encrypted Security Payload header • Security

7. Plug ‘n Play • Auto configuration • Eliminates need for manual configuration of hosts • Especially useful for example in devices at home • But also for large networks • Manual configuration possible • Stateful configuration (using DHCP) • 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)

8. Built-in Security • Security Framework known as IPSEC • Security elements of IPv6 • 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

9. Support for QOS • Not just an IPv6 issue but there are some mechanisms in IPv6 that facilitate QoS • Several QoS paradigms • End system based QoS e.g., extrapolation of missing data, error recovery etc. • Service-based QoS • Class/priority based QoS • Resource reservation (RSVP) • Not defined by IPv6 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)

10. 1 3 3 3 1 1 payload payload 1 2 1 2 payload payload 3 3 1 1 HA 2 payload Destination Hdr 1 3 2 FA 3 2 Destination Hdr 1 payload Mobility IPv4 IPv6

11. Application Application Application IPv6 IPv4 Transitioning • Gradual transition envisaged • No sudden emergence of IPv6 • Two main transmission mechanisms • Dual stacks • Tunnelling

12. Other IPv6 Protocols • ICMPv6 • OSPFv3 • RIPng • DHCP for v6 • TCP and UDP should not be affected but ... • Application protocols such as HTTP, FTP and Telnet clients need to make connections with both IPv4 and IPv6 servers

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

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

15. Awareness, Promotion etc. • IPv6 Forum • IPv6 Task Forces • North America, Europe, Asia etc. • Regular Global IPv6 Summits • IPv6 Ready • Certification Scheme • PlugtestsTM very active • Many large ETSI members • Vendors • Operators • IMS will be important for IPv6 • NGN (well, its IMS based to start ...) • Experimental networks • 6 Bone, Moonv6, Euro6IX, various operators • Core network ... • ... and applications (e.g., VoIP) • ... and STF276

16. STF276@Work

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

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

19. STF 276 Members

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

21. Requirements Process

22. The Requirements Catalogue • 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

23. The Requirements Catalogue (cont’d) • 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 IPv6 Logo requirements • Mapping between RFC and 3GPP requirements • A user-extendable tool to identify requirements for procurement or implementation

24. Example Requirement

25. Interoperability Process

26. Interoperability Test Purposes • 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)

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

28. TPLan Example for Interoperability TP id : TP_COR_1719_02 Summary : 'EUT sends packet to All-RT LL M/cast address' RQ ref : RQ_COR_1719 Config : CF_021_I TD ref : TD_COR_1719_02 with { QE1'configured as a router' andQE2'configured as a router'} ensurethat { when { EUT is requested to 'send packet to All-RoutersLink-Local M/cast addr' } then { QE1 indicates'receipt of the packet' andQE2 indicates'receipt of the packet' } }

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

30. Example Test Description

31. Conformance Process

32. Conformance Test Purposes • 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)

33. 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‘Ipv6 packet'from‘HS' containing‘IPv6 Header' indicating‘Hop limit'setto‘1‘ } --Expected response then {IUTsends‘ICMPv6 Time Exceeded'to‘HS‘ containing‘ICMP code'setto‘ZERO‘ }}

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

35. What is TTCN-3? • 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 • Wide range of applications from mobile (radio) communications to Internet to software • Good tool support • Good book: • http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470012242.html

36. Example TTCN-3 Test Case testcase TC_COR_0047_01() runs on Ipv6Node system EtherNetAdapter { f_cf02Up(); // Configure test system for HS->RT // No preamble required in this case f_TP_HopsSetToOne(); // Perform test // No postamble required in this case f_cf02Down(); // Return test system to initial state } function f_TP_HopsSetToOne() runs on Ipv6Node { var Ipv6Packet v_ipPkt; var FncRetCode v_ret := f_echoTimeExceeded( 1, v_ipPkt ); if ( v_ret == e_success and v_ipPkt.icmpCode == 0 ) { setverdict(pass);} else { setverdict(fail); } } function f_echoTimeExceeded(in UInt8 p_hops, out Ipv6Packet p_ípPkt ) runs on Ipv6Node return FncRetCode { var Ipv6Packet v_ipPacket; var FncRetCode v_ret; ipPort.send( m_echoReqWithHops(p_hops) );alt { [] ipPort.receive( mw_anyTimeExceeded ) -> value p_ipPkt { return e_success } [] ipPort.receive { return e_error } } }

37. Validation Platform • Open Source Op. Syst. • FreeBSD • Fedora Core Linux • RedHat Linux • Remote controllable • Secured (Private key + Pwd) • Validate our own test suites locally Internet SSH(secured remote control) R IPv4 control network H H R R IPv6 testbed

38. Validation Platform • Open Source Op. Syst. • FreeBSD • Fedora Core Linux • RedHat Linux • Remote controllable • Secured (Private key + Pwd) • Validate our own test suites locally & remotely Internet SSH(secured remote control) R H H IPv6 testbed R R

39. STF276 IPv6 test bed ETSIHQ control network IPv4 @ only Test networks IPv6 @ only Internet(IPv4) SSH(secured remote control) 172.27.x.x CUxxx Oleane .17 172.27.1.1 .252 .57 UUnet .253 FW ETSI_ONLINE Mask: 255.255.255.0 212.234.161.x PLUGTESTS 212.234.161.1 ETSI_PUBLIC 217.167.116.1 212.234.160.x PF1000: 2001:660:5503:1000 /64 PF6: 2001:660:5503:6 /64 FErouter1 Fedora core 3 R Ns6.etsi.org 6Wind meeting ::6 2Mb inrias ::2 renaters ::1 PF3000 IPv6 RHhost2 Linux Redhat ES4+ TTCN-3 tools RHhost3 Linux Redhat ES4+ TTCN-3 tools FBrouter5 FreeBSD 5.3 FBrouter4 FreeBSD 5.3 A PF276a: 2001:660:5503:276a /64 PF276b: 2001:660:5503:276b /64 B

40. Library Process

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

42. IPv6 Test Library

43. Thank You!