STF 276 Colloquium
June 22nd 2005
1
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
2
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:
“IPv6 takes the Internet where no other
network has been before”
 Why do we need it and is it better?
 Is it being adopted?
 And where is ETSI on the IPv6 Roadmap?
3
Hugely Increased Address Space

PROBLEM: IPv4 is running out of addresses

IPv4 has 32 bit addresses


IPv6 has 128 bit addresses


roughly the same as the number of a bucket full of sand grains
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!
4
More ‘Efficient’ Header
IPv6 Header
Variable length payload up to 64KB

PROBLEM: IPv4 headers not the most efficient (variable length)

IPv6 has fixed length header (40 bytes)


IPv6 Fields









Tailored for fast throughput and to run on Giga Ethernet and ATM
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
5
Extension Headers for Options
IPv6 Header


Fragmentation of large payloads (negotiated through MTU)
Info for destination node (e.g., to carry home address in mobile IP)
Authentication header


Specifies explicit nodes (routers) that must be in the path
Destination 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).
Fragment header


Ext. Header n
Routing header


Ext. Header 2
Used to specify protocol options such as:
Hop-by-hop options header


Ext. Header 1
Security
Encrypted Security Payload header

Security
6
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)
7
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
8
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)
9
Mobility
3
payload
3
1
payload
1
1
HA
IPv6
IPv4
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
 Gradual transition envisaged
 No sudden emergence of IPv6
 Two main transmission mechanisms
 Dual stacks
 Tunnelling
Application
Application
IPv4
Application
IPv6
11
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
12
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
13
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
14
Awareness, Promotion etc.


IPv6 Forum
IPv6 Task Forces



Regular Global IPv6 Summits
IPv6 Ready



Vendors
Operators
IMS will be important for IPv6
NGN (well, its IMS based to start ...)
Experimental networks




Certification Scheme
PlugtestsTM very active
Many large ETSI members





North America, Europe, Asia etc.
6 Bone, Moonv6, Euro6IX, various operators
Core network ...
... and applications (e.g., VoIP)
... and STF276
15
STF276@Work
16
STF 276

TC MTS project to produce test specifications for interoperability of IPv6
products




Two phases







Interoperability test specifications
Conformance test specifications
Library of TTCN-3 test code freely available
All tests are validated



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




Led by PTCC
eEurope funding
Significant voluntary expert contribution by ETSI members (at least 134 days in 2005)
On STF276 Testbed
By member companies
For more info visit: www.ipt.etsi.org
17
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
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 / IPV6 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
 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
20
Requirements Process
3G Mobile
Specifications
Industry
Practice
IPv6 Forum &
other sources
RFC
RFC
RFC
Requirements
Catalogue
21
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
22
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
23
Example Requirement
24
Interoperability Process
3G Mobile
Industry
IPv6 Forum &
Specifications
Practice
others
RFC
RFC
RFC
Requirements
Catalogue
Interoperability
Test
Purposes
(TPLan)
Test
Descriptions
(Natural
Language)
25
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)
26
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)
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 { 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' }
}
28
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
29
Example Test Description
Test:
COR_001_02
Selection Criteria:
Mandatory
Title:
Auto configure QE using a unique address in a simple network
Test Purpose:
ensure that {
when { etc……….
Pre-test conditions:



Step
Selected:
Yes
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
Verdict
Test description
1
Turn on QE1 interface and wait a few seconds
2
EUT sends an echo request to the Link-Local address of QE1
3
Check:
4
QE1 sends an echo request to the Link-Local address of EUT
5
Check:
does EUT receive an echo reply from QE1?
does QE1 receive an echo reply from EUT?
Pass
Fail
Yes
No
Yes
No
Observations:
30
Conformance Process
3G Mobile
Specifications
Industry
Practice
IPv6 Forum &
others
RFC
RFC
RFC
Requirements
Catalogue
Interoperability
Conformance
Test Specific
Definitions
(TTCN-3)
Test
Purposes
(TPLan)
Test
Purposes
IPv6 Specific
Definitions
(TTCN-3)
Common
Definitions
(TTCN-3)
Test
Cases
(TTCN-3)
Test
Descriptions
31
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)
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 ‘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‘ }
}
33
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
34
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/productCd0470012242.html
35
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 } }
36
}
Validation Platform
Open Source Op. Syst.
•FreeBSD
•Fedora Core Linux
•RedHat Linux
Internet
 Remote controllable
 Secured (Private key + Pwd)
 Validate our own test suites locally
SSH
(secured remote control)
R
IPv4 control network
H
H
R
IPv6 testbed
R
37
Validation Platform
Open Source Op. Syst.
•FreeBSD
•Fedora Core Linux
•RedHat Linux
Internet
 Remote controllable
 Secured (Private key + Pwd)
 Validate our own test suites locally
SSH
(secured remote control)
& remotely
R
H
H
IPv6 testbed
R
R
38
STF276 IPv6 test bed
 IPv4 @ only
Internet
(IPv4)
Test networks
 IPv6 @ 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.255.255.0
PLUGTESTS
212.234.160.x
212.234.161.1
.252
FW
ETSI_PUBLIC
217.167.116.1
PF1000: 2001:660:5503:1000 /64
PF6: 2001:660:5503:6 /64
Ns6.etsi.org
renaters ::1
R
6Wind
2Mb
FErouter1
Fedora core 3
meeting ::6
inrias ::2
PF3000
IPv6
RHhost2
Linux Redhat ES4
+
TTCN-3 tools
FBrouter5
FreeBSD 5.3
RHhost3
Linux Redhat ES4
+
TTCN-3 tools
FBrouter4
FreeBSD 5.3
A
B
PF276a: 2001:660:5503:276a /64
PF276b: 2001:660:5503:276b /64
39
Library Process
3G Mobile
Specifications
Industry
Practice
IPv6 Forum &
others
RFC
RFC
RFC
Requirements
Catalogue
Conformance
Test Specific
Definitions
Interoperability
Test
Purposes
Test
Purposes
IPv6
Library
IPv6 Specific
Definitions
Common
Definitions
Requirements
Test
Cases
Test
Descriptions
40
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
41
IPv6 Test Library
3G Mobile
Specifications
Industry
Practice
IPv6 Forum &
other sources
RFC
RFC
RFC
Requirements
Catalogue
Conformance
Test Specific
Functions
Interoperability
Test
Purposes
Data
Specifications
Generic
Functions
Requirements
Test
Purposes
IPv6 Library
Test
Descriptions
Test
Cases
Test Suite
Test Suite
Test Suite
42
Thank You!
43