1. 1 STF 276 Colloquium June 22 nd 2005

2. 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. 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. 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. 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 HeaderVariable length payload up to 64KB

6. 6 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 IPv6 Header Ext. Header 1Ext. Header 2 Ext. Header n

7. 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 Site Local Address (SLA)Router provided prefix

8. 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. 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. 10 Mobility 31payload 12 12 31 31 31 2 3 1 HAFA 32payloadDestination Hdr 132payloadDestination Hdr 1 IPv4IPv6

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

12. 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. 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. 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. 15 Awareness, Promotion etc.  IPv6 Forum  IPv6 Task Forces  North America, Europe, Asia etc.  Regular Global IPv6 Summits  IPv6 Ready  Certification Scheme  Plugtests TM 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. 16 STF276@Work

17. 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.orgwww.ipt.etsi.org

18. 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. 19 STF 276 Members STF 276 Participants 1AW Anthony Wiles (STF leader)ETSI PTCC Manager 2AF Annie FlochIRISA 3BG Basavanna GowdaMotorola 4CO César OlveraConsulintel SL / IPV6 Forum 5ECT Emmanuelle Chaulot-TalmonETSI PTCC Assistant 6DT Dirck TepelmannTesting Technologies 7LV Laurent VreckETSI Technical Officer 8PK Péter KrémerEricsson 9PS Peter SchmittingFSCOM 10RC Ranganai ChaparadzaFOKUS 11SAM Scott MoseleyFarbum Scotus 12SM Sebastian MuellerFSCOM 13SR Steve RandallPQM Consultants 14SS Stephan SchulzNOKIA 15XF Xiaoming FuIITB

20. 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.orgwww.ipt.etsi.org

21. 21 Requirements Process

22. 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. 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. 24 Example Requirement

25. 25 Interoperability Process

26. 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. 27 Test Purpose Language (TPLan)  Keywords and syntax provide clear and consistent structure  Keywords chosen for communications applications ( sends, receives etc.)  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. 28 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' and QE2 'configured as a router'} ensure that { when { EUT is requested to 'send packet to All-Routers Link-Local M/cast addr' } then { QE1 indicates 'receipt of the packet' and QE2 indicates 'receipt of the packet' } } TPLan Example for Interoperability

29. 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. 30 Example Test Description Test: COR_001_02 Selection Criteria:Mandatory Selected:Yes Title:Auto configure QE using a unique address in a simple network Test Purpose: ensure that { when { etc………. Pre ‑ test conditions:  Configure the equipment to ensure that QE1 will not intend to use the same link-local address than the one used by EUT (EUT and QE1 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  QE1 interface is down StepTest description Verdict PassFail 1Turn on QE1 interface and wait a few seconds 2EUT sends an echo request to the Link-Local address of QE1 3Check:does EUT receive an echo reply from QE1? YesNo 4QE1 sends an echo request to the Link-Local address of EUT 5Check:does QE1 receive an echo reply from EUT? YesNo Observations:

31. 31 Conformance Process

32. 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. 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' set to ‘1‘ } --Expected response then { IUT sends ‘ICMPv6 Time Exceeded' to ‘HS‘ containing ‘ICMP code' set to ‘ZERO‘ } }

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

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

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

40. 40 Library Process

41. 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. 42 IPv6 Test Library

43. 43 Thank You!