The European Organisation for Civil Aviation Equipment

L’Organisation Européenne pour l’Equipement de l’Aviation Civile

ED-138 Network Requirements and Performances for Voice over

Internet Protocol (VoIP) Air Traffic Management (ATM) Systems

Part 1: Network Specification

ED-138 Part 1
“Month Year”

102 rue Etienne Dolet Tel: 33 1 40 92 79 30

92240 MALAKOFF, France Fax: 33 1 46 55 62 65
Web Site: www.eurocae.eu Email: eurocae@eurocae.net
 ED-138 Network Requirements and Performances for Voice over
Internet Protocol (VoIP) Air Traffic Management (ATM) Systems

Part 1: Network Specification

ED-138 Part 1
“Month Year”

© EUROCAE, 2009
 i

FOREWORD

1 The document ED-138 “ED-138 Network Requirements and

Performances for VoIP ATM Systems” was prepared by EUROCAE
Working Group 67 and was accepted by the Council of EUROCAE on
“Month Year”.
2 EUROCAE is an international non-profit making organisation. Membership is
open to manufacturers and users in Europe of equipment for aeronautics,
trade associations, national civil aviation administrations and non-European
organisations. Its work programme is principally directed to the preparation
of performance specifications and guidance documents for civil aviation
equipment, for adoption and use at European and world-wide levels.
3 The findings of EUROCAE are resolved after discussion among its members
and, where appropriate, in collaboration with RTCA Inc., Washington D.C.
USA and/or the Society of Automotive Engineers (SAE), Warrendale, PA,
USA through their appropriate committee.
4 The document represents “the minimum specification required for
Manufacturers and Users to qualify Network interconnecting VoIP ATM
Systems”.
5 EUROCAE performance specifications are recommendations only.
EUROCAE is not an official body of the European governments; its
recommendations are valid statements of official policy only when adopted
by a particular government or conference of governments.
6 Copies of this document may be obtained from:

EUROCAE
102 rue Etienne Dolet
92240 MALAKOFF
France

Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: eurocae@eurocae.net
Web Site: www.eurocae.org

© EUROCAE, 2009
 ii

TABLE OF CONTENTS

FOREWORD I

TABLE OF CONTENTS ................................................................................................................ II

CHAPTER I INTRODUCTION...................................................................................................... 1
1.1. Background..................................................................................................... 1
1.2. ED-138 Presentation ...................................................................................... 3
1.3. Terminology for requirements, recommendations, and options ..................... 4
CHAPTER I References ................................................................................................ 5

CHAPTER II NETWORK SPECIFICATION ................................................................................. 6

2.1. General information ........................................................................................ 6
2.1.1. Operational Voice Applications in ATM........................................... 6
2.1.2. Numbering of Requirements, Recommendations and Options....... 7
2.1.3. Network Concepts ........................................................................... 8
2.2. Specific Network and Services Requirements ............................................... 9
2.2.1. IP Addressing and Protocols ........................................................... 9
2.2.2. IP Networking and Routing............................................................ 10
2.2.3. Applications and Quality of Service (QoS) requirements.............. 10
2.3. Network Functional and Performance Requirements................................... 11
2.3.1. Network connectivity ..................................................................... 11
2.3.2. Quality and Performance............................................................... 11
2.3.3. Availability...................................................................................... 11
2.3.4. Class of Service CoS and Quality of Service QoS........................ 11
2.3.5. Maintenance and Diagnostics ....................................................... 13
2.4. Network Management and Procedures ........................................................ 14
2.4.1. Fault Management ........................................................................ 14
2.4.2. Configuration Management ........................................................... 14
2.4.3. Performance Management............................................................ 14
2.5. Specific Safety and Security Requirements ................................................. 16
2.5.1. Security Policy and requirements.................................................. 16
2.5.2. Security Management ................................................................... 16
Chapter II References.................................................................................................. 18

CHAPTER III SECURITY POLICY............................................................................................. 19

3.1. Background................................................................................................... 19
3.2. ATM Security Principles................................................................................ 19
3.2.1. Confidentiality................................................................................ 19

© EUROCAE, 2009
 iii

3.2.2. Integrity.......................................................................................... 19
3.2.3. Availability...................................................................................... 20
3.3. VoIP Security ................................................................................................ 20
3.3.1. Threats in VoIP networks .............................................................. 20
3.4. Network Model.............................................................................................. 22
3.5. Security requirements................................................................................... 24
3.5.1. Zone 1 (IP Core)............................................................................ 24
3.5.2. Zone 2 (Access to the shared IP Core)......................................... 25
3.5.3. Zone 3 (ANSPs and other related Organizations Domain) ........... 26
3.6. General recommendations ........................................................................... 27
Chapter III References................................................................................................. 28

CHAPTER IV IP ADDRESSING................................................................................................. 30
4.1. Background................................................................................................... 30
4.1.1. IPv4 Overview ............................................................................... 31
4.1.2. IPv6 Overview ............................................................................... 33
4.1.3. Why IPv6 ....................................................................................... 37
4.1.4. Transition Mechanisms ................................................................. 38
4.2. Addressing Scheme (Revised iPAX Scheme).............................................. 39
4.2.1. Address Management ................................................................... 40
Annex A : NETWORK Address ASSIGNMENTS ........................................................ 41
Chapter IV References ................................................................................................ 44

LIST OF EUROCAE WG-67 CONTRIBUTORS.......................................................................... 45

© EUROCAE, 2009
 1

CHAPTER I

INTRODUCTION

1.1. BACKGROUND

Components of Ground- Ground ATM voice systems has used digital (TDM/PCM - Time
Division Multiplexing / Pulsed Code Modulation) or analogue technology during a long
time.

Convergence of voice and data into one multimedia network is observed on the market.
As a consequence the ATM communication network is evolving into a common
infrastructure for voice and data services.

As a result of the above described technological trends, the capability of Voice over IP
Technology may fulfil and improve operational and technical ATM communication
requirements, including voice / data convergence, specific Quality of Services (QoS),
security and safety requirements.

So after analysing the situation regarding:

• Operational and Technical Air-Ground (A/G) and Ground-Ground (G/G)

ATM Voice system requirements

• Existing IP Voice protocols and signaling standards

• IP networks capability for Voice services

• Security, QoS, Convergence (infrastructure, protocol, applications)

• Existing IP Voice ATM systems and their service interfaces,

The following tasks were achieved for ground-ground ATM communications and ground-
ground segment of air-ground ATM communications:

• Define IP Voice ATM Systems and identify their components (Voice

Communication System / VCS, Ground based Radio Station / GRS…)

• Determine possible additional operational and technical ATM requirements

for new IP Voice ATM systems, also taking into consideration A/G
communications.

• Accordingly, make recommendations to upgrade current standardisation

documents.

• Develop a Technical Specification for an IP Voice ATM System including:

o Minimum performance and safety / security requirements for the

system and, if appropriate, for components

o Interoperability requirements between IP components of the IP

Voice ATM systems

© EUROCAE, 2009
 2

o Minimum performance requirements of an IP Network aimed to

support Voice in ATM.

o Guidelines for qualification tests of IP Voice ATM systems and IP

Voice ATM components.

So four documents with a common reference to “Vienna Agreement” was provided:

ED-136 VoIP ATM System Operational and Technical Requirements

ED-137 Interoperability Standards for VoIP ATM Components

ED-138 Network Requirements and Performances for VoIP ATM Systems

ED-139 Qualification tests for VoIP ATM Components and Systems

The “Vienna Agreement” defines the different components of the VoIP ATM system
and may be resumed by the following figure on which are described the different
interfaces between the components.

FIGURE 1 VIENNA AGREEMENT

© EUROCAE, 2009
 3

1.2. ED-138 PRESENTATION

The purpose of this document is to specify the network requirements and the needs of
VoIP services for ATM applications in the network - including IP Adressing and Security -
that are to provide the necessary high levels of availability, integrity, performance and
Quality of Service (QoS) for VoIP in ATM applications.

ED-138 is divided into two parts:

• ED-138 Part 1 (this document)
o Network Specification
o Security Policy
o IP Addressing Plan
• ED-138 Part 2 [1]:
o Network Design Guideline

*
ED-138 Part 1 (Network Specification) describes WHAT shall/should/may be done.

ED-138 Part 2 (Network Design Guideline) describes HOW it can be done.

Each chapter in this document is independently referenced, where applicable.

© EUROCAE, 2009
 4

1.3. TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS, AND OPTIONS

The terminology for requirements, recommendations, and options in this document is

based on RFC 2119 [2], which specifies Best Current Practice regarding the use of Key
Words for the Internet Community. As such, the following terminology is applied:

• The word SHALL denotes a mandatory requirement

• The word SHOULD denotes a recommendation
• The word MAY denotes an option

To avoid confusion with their natural meanings in the English language, the words
SHALL, SHOULD, and MAY take on the meaning stated above only where printed in
boldface. When printed in normal (Arial) typeface, the natural English meaning is meant.
Detailed description of terminology:
The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT" and "MAY” in this
document are to be interpreted as described in RFC 2119.

1. SHALL This word has the same meaning as the phrase "REQUIRED" and
means that the definition is an absolute requirement of the specification.

2. SHALL NOT This phrase means that the definition is an absolute prohibition of
the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", means that there

may exist valid reasons in particular circumstances to ignore a particular item, but
the full implications must be understood and carefully weighed before choosing a
different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the particular
behaviour is acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing any behaviour
described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly
optional.

© EUROCAE, 2009
 5

CHAPTER I REFERENCES

[1] ED-138 Network Requirements and Performances for VoIP ATM Systems Part 2:
Network Design Guideline;
http://www.eurocae.org
[2] IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels;
http://www.ietf.org/rfc/rfc2119.txt

© EUROCAE, 2009
 6

CHAPTER II

NETWORK SPECIFICATION

2.1. GENERAL INFORMATION

For the purposes of this document, the reference architecture for specifying network
requirements of VoIP in ATM is shown in Figure 2, based upon the “Vienna Agreement”.

Network
FIGURE 2 WG67 VIENNA AGREEMENT INCLUDING NETWORK CONCEPT

2.1.1. Operational Voice Applications in ATM

Eurocontrol EATM1 G-G Communications Strategy plans to integrate ATM IP Voice

communications with the ATM IP Data Network from 2010 onwards.

WG-67 assumed the responsibility to define the specification of VoIP for ATM Systems to
include the service types as described in Table 1.

1
European Air Traffic Management

© EUROCAE, 2009
 7

SERVICE TYPE APPLICATION DESCRIPTION

GROUND G-G Voice Principally for Centre/Centre and Centre/Tower

COORDINATION coordination within an Air Navigation Service
Provider (ANSP) domain and between neighbouring
ANSPs
This communication is between Voice
Communication Systems (VCS), as shown in Figure
3.
AIR GROUND A-G Voice Principally nationally based but SES2 may require
SERVICES trans-national ground connectivity.
WG-67 only considered communication between
VCS and Radio without air links.

TABLE 1 OPERATIONAL VOICE APPLICATIONS IN ATM

RADIO

WAN

VoIP

VCS 1 VCS 2
VCS = Voice Communication System

FIGURE 3 CONSIDERED VOICE APPLICATIONS IN WG67

2.1.2. Numbering of Requirements, Recommendations and Options

All Requirements, Recommendations and Options in this chapter are marked with a
cardinal number in brackets on the left side of the paragraph

2
Single European Sky; http://www.eurocontrol.int/ses/public/subsite_homepage/homepage.html

© EUROCAE, 2009
 8

2.1.3. Network Concepts

The following are the definitions of the main concepts that are particular to this Document:

• EDGE is the equipment that serves as the interface to the WAN. This could be one
or a combination of devices (e.g., switches, routers, and firewalls) that deliver the
communication service.

• LAN (Local Area Network) is a network covering a relatively small geographic

area.

• WAN shall be understood as being the interconnecting infrastructure of a

communications enterprise, which may be based upon the IP (though not
necessarily so), supported by underlying technologies (e.g., MPLS, Gigabit
Ethernet, Frame Relay, TDM). The WAN serves users across a broad geographic
area and often uses transmission devices provided by common carriers. A WAN
can be a Provider’s Core network, a private network or the combination of both of
them.

• IP Network means the complete physical and logical mapping and connectivity
(up to Layer 3) between end-system network access points, including the LAN,
EDGE and WAN domains.

Figure 4 shows the different Network domains and their terminology.

IP

IP

IP

IP

IP

IP

IP

IP
LAN EDGE WAN EDGE LAN

FIGURE 4 IP NETWORK DOMAIN CONCEPT

© EUROCAE, 2009
 9

2.2. SPECIFIC NETWORK AND SERVICES REQUIREMENTS

The IP [2] [3] infrastructure will be expected to provide smooth delivery of voice and
signalling packets to the end systems. To support this, voice and data traffic are expected
to be prioritized differently on the network, to accommodate the extra sensitivity of voice
traffic to latency and because voice is a continuous streaming that should not be
interrupted.

In addition, factors such as jitter, packet loss, security, and incompatibility can affect the
quality of communication services, and need to be handled by the IP infrastructure.

These and other issues are to be addressed by the following requirements.

(1) The IP network SHALL be compliant with the following criteria to fulfil ATM Voice
communication needs:
• Performance (e.g., bandwidth, response times for call set up and tear down,
maximum latency, packet throughput, maximum packet size)
• QoS/CoS mechanisms (e.g., prioritization of traffic classes to minimize jitter and
packet loss)
• Reliability/Availability
• Security
• Standardized Interfaces

(2) The IP network SHALL be able to support:

• Signalling requirements (e.g., SIP)
• Voice media requirements (e.g., RTP/RTCP)

Detailed explanations of these criteria are provided in this document and solutions are
given in the ED-138 Network Requirements and Performances for VoIP ATM Systems
Part 2: Network Design Guideline [4].

2.2.1. IP Addressing and Protocols

(3) IPv6 (RFC 2460) SHALL be supported by the IP Network.
(4) The defined IP Addressing Scheme in Chapter 4.2 SHALL be used.
A detailed explanation of IP Addressing criteria is provided in Chapter IV.

(5) The transport of Multicast traffic according to PIM SSM (RFC 3569) SHALL be supported
by the IP Network for an efficient distribution of audio streams.
A detailed explanation of Multicast criteria is provided in ED-138 Network Requirements
and Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter V.

© EUROCAE, 2009
 10

2.2.2. IP Networking and Routing

(6) Native Routing of IPv6 packets SHALL be supported by the EDGE; IPv6 transportation
SHALL be supported by the WAN and LAN.
(7) Border Gateway Protocol Version 4+ (BGP4+) [5] and static/default routing SHALL be
supported by the WAN entry point in order to properly route traffic between WANs.
(8) Open Shortest Path First (OSPF) [6] SHOULD be supported within the WAN domain.

A detailed explanation of Routing criteria is provided in ED-138 Network Requirements

and Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter III.

2.2.3. Applications and Quality of Service (QoS) requirements

(9) The IP Network SHALL be able to support the applications with Quality of Service QoS
shown in Table 2. Typically these QoS parameters are defined in Service Level
Agreements (SLA’s).
(10) The IP Network SHALL be able to distinguish between different Classes of Service (CoS)
and different requirements regarding delay, jitter, bandwidth demand, and packet loss.
The different requirements are shown in Table 2.

Application Typical packet Acceptable Acceptable Jitter3 Acceptable

length latency3 (without Packet Loss rate
jitter)
1. payload only
2. with CRTP
3. with CRTP and
IPSec

Default N/A N/A N/A N/A

(best effort)

Telephone voice 1. 160 Bytes 100ms 15ms 0.5%

2. 164 Bytes
3. 212-222 Bytes
Radio voice 1. 160 Bytes 50ms 15ms 0.5%
2. 164 Bytes
3. 212-222 Bytes
Telephone 100ms4 50ms 0.5%
Signalling
Radio 50ms4 50ms 0.5%
Signalling
Recording 100ms 50ms 0.5%

TABLE 2 APPLICATION REQUIREMENTS

3
All latency values are one-way delays
4
Value is given for the network path between two elements involved in the call-setup

© EUROCAE, 2009
 11

2.3. NETWORK FUNCTIONAL AND PERFORMANCE REQUIREMENTS

2.3.1. Network connectivity

(11) Ethernet according to IEEE 802.3 standards SHALL be available in the LAN environment
for the access of client devices to the IP network.
(12) For legal recording local physical Ports which duplicates traffic (Span or Mirror Port) MAY
be available in LAN.
(13) If manual compensation mode for Climax5 is chosen, fixed network paths SHOULD be
used in the IP Network.

2.3.2. Quality and Performance

A detailed explanation of these criteria is provided in ED-138 Network Requirements and
Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter IV.
(14) Maximum amount of possible concurrent voice calls (voice channels) Vmax and signalling
(signalling channels) Smax which are necessary for operational purposes SHALL be
defined for IP Network (for each network-path especially edges). For the WAN area of the
network, SLA’s SHALL be signed with the WAN Provider in order to ensure the required
performances in terms of bandwidth needed.
(15) The IP Network SHALL be able to accommodate up to Vmax + Smax concurrent channels.
(16) For this maximum amount of channels Vmax + Smax, the following parameters SHALL not
be exceeded in the IP Network: acceptable packet loss rate, acceptable latency, and
acceptable jitter. These parameters are dependent on Service Class (see Table 2). If this
requirement cannot be fulfilled in exceptional cases (e.g., delay in long distance
connections, loss of bandwidth), the proper function of the Voice calls associated with the
Expedited Forwarding (EF) Class (see Table 4) SHALL be assured.
(17) Header compression MAY be supported by the IP Network. Note: Header compression on
low speed links and IPsec MAY not be used at the same time for the same service.

2.3.3. Availability
Availability is the probability that the network is operational and functional as required at
any given moment in time.
The expected or measured fraction of time the defined service, device, application, area is
operational. Annual uptime is the amount of time: in days, hours, minutes the item is
operational and functional.
(18) IP Network SHALL achieve the required availability of the overall system.
Note: Availability depends on the overall system architecture and usage of redundancy
and backup-features and last resorts/emergency systems.
A detailed explanation of these criteria is provided in ED-138 Network Requirements and
Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter III.
2.3.4. Class of Service CoS and Quality of Service QoS
(19) Classification: IP Network SHALL provide methods of categorizing traffic into different
classes, also called Class of Service (CoS), and applying QoS parameters to those
classes. IP Network SHALL be able to reapply CoS and QoS parameters to the packets
sourced by different systems in the network, in order to ensure the proper functionality.

5
Multi-station carrier offset mode, with voting override

© EUROCAE, 2009
 12

(20) Prioritisation: IP Network SHALL provide methods of prioritising traffic based on Class of
Service in the LAN area, according to the IEEE 802.1p and IEEE 802.1q standards, based
on a common schema among different participants in the network (ANSPs). IP Network
SHALL provide methods of prioritising traffic based on Class of Service in the Edge and
WAN area.
(21) IP Network SHALL support Differentiated Service (Diffserv) (RFC2474/2475) QoS
architecture and SHOULD support the mapping of different service or traffic classes to
Differentiated Service Code Point DSCP.
(22) The DSCP mapping SHALL be configurable when using Diffserv.
(23) When there is an unrecognized DSCP, assigned traffic SHALL be treated according to a
default Per-hop-behaviour PHB that is ‘Best effort’.
(24) When using Diffserv the DSCP SHALL be set by the six most significant bits of ‘Traffic
Class’ byte in IPv6 header. ‘Traffic Class’ SHALL be set by the VoIP ATM application.
(25) When using Diffserv the DSCP SHALL be used and encoded for cross border
communication as follows (see Table 3):
• Eight Class Selector Codepoints compatible with IPv4 and IP Precedence (CS0-7)
• An Expedited Forwarding (EF) Class
• IP packets are forwarded in N independent AF classes, each having M different
levels of drop precedence. Therefore, the Codepoints with the classes and drop
precedence form a matrix AFij, where 1 ≤ i ≤ N and 1 ≤ j ≤ M. Four classes (N=4)
are defined with three Drop Precedences (M=3).
• Packets in a higher AF Classes SHOULD have a higher transmit priority
• Packets with a higher Drop Precedence SHOULD be more likely to be dropped

DSCP value Codepoint DSCP value Codepoint

000000 CS0 (DEFAULT) 011010 AF31

001000 CS1 011100 AF32
001010 AF11 011110 AF33
001100 AF12 100000 CS4
001110 AF13 100010 AF41
010000 CS2 100100 AF42
010010 AF21 100110 AF43
010100 AF22 101000 CS5
010110 AF23 101110 EF
011000 CS3 110000 CS6
111000 CS7

TABLE 3 DSCP VALUES

© EUROCAE, 2009
 13

(26) For cross border communication the IP Network SHOULD set the DSCP field of outgoing
packets to the values shown in Table 4.
Application DSCP value Codepoint

Default 000000 CS0

(best effort)

Telephone voice 101110 EF

Radio voice
Telephone signalling 100010 AF41
Radio signalling
Recording voice 011010 AF31

TABLE 4 DSCP MAPPING

Note:
• Class Selector code points (CS1-7) are reserved and could be used for backward
compatibility with IP Precedence.

(27) When using Diffserv the DSCP mapping in the IP Network SHOULD be used for national
purposes as shown in Table 4.

Definitions and Standards of Diffserv and DSCP, IPv6 Traffic Class and IP Precedence
can be found in ED-138 Network Requirements and Performances for VoIP ATM Systems
Part 2: Network Design Guideline chapter IV.

2.3.5. Maintenance and Diagnostics

(28) The IP Network SHALL have the capability to conduct maintenance and diagnostic
procedures to support the quality and performance requirements.

© EUROCAE, 2009
 14

2.4. NETWORK MANAGEMENT AND PROCEDURES

2.4.1. Fault Management

The goal of fault management is to detect, filter, log, notify users of (e.g., trigger alarms),
and automatically fix network problems, when possible, to keep the network running
effectively. Because faults can cause downtime or unacceptable network degradation,
fault management is perhaps the most widely implemented in network management
elements. A graphical view of network topology is used to indicate network element
connectivity and faults in real time.
Fault statistics are aggregated to compile long-term failure trends. For example,
availability, reliability, and maintainability metrics may be compiled to assess network
service compliance with service level agreements.

(29) Fault Management SHALL be available for the IP Network to undertake all necessary
actions in order to report the failure, complete diagnosis, and fix network problems.
(30) Preventive fault management actions SHALL be prescribed and maintained to ensure the
availability of primary and backup paths and components for the IP Network.

2.4.2. Configuration Management

The goal of configuration management is to monitor and control network configurations so

that the effects on network operation of various types and versions of hardware and
software elements can be tracked and managed.

The VoIP infrastructure changes dynamically, as various devices and their links are
brought on and off line, and when their naming and addressing plans are adjusted.
Additionally, many of these devices host various types of software, each with its own
release, version, and other identifying information, such as:

• Operating system

• Network Manager Platform

• Switch, router, and gateway platforms and hosted software

• Traffic prioritization
The configuration management subsystem displays and highlights changes of network
elements in real time. It also makes this information available for retrieval. All changes to
system hardware and software configurations are effected through the configuration
management subsystem. When a problem occurs, this archive can be searched for clues
that may help solve the problem.

(31) The IP Network SHALL have a capability to monitor and control network configurations so
that the effects on network operation of various types and versions of hardware and
software elements can be tracked and managed.

2.4.3. Performance Management

The goal of performance management is to measure and optimize various aspects of

network performance to maintain overall quality of service at an acceptable level.

© EUROCAE, 2009
 15

Examples of performance variables that might be monitored include available bandwidth,

jitter, latency, response times, and packet loss.

Within the purview of performance management fall the following disciplines:

• Performance measurement – The measurement of performance variables at the

network and application levels to ascertain compliance with Service Level
Agreements. Tools are available at the appropriate protocol layers to monitor
these variables, trigger alarms when exceeding thresholds, and aggregate
statistics for reporting.

• Forensic analysis – The detailed analysis of protocol message exchanges for

determining causes of performance degradation (e.g., packet retransmissions,
handshake timeouts)

• Capacity planning – The use of modeling techniques to predict the impact of new
applications and increased loading on network performance

• Bandwidth on demand – Dynamic allocation of network capacity based on

utilization and traffic class

• Load generation – Stress testing of networks with scripted usage loads to identify
service saturation levels

(32) The IP Network SHALL have a capability to measure performance variables at the
network level to ascertain compliance with Service Level Agreements.
(33) The IP Network SHOULD have a capability to perform forensic analyses as explained
above.
(34) The IP Network MAY have a capability to perform Capacity planning and Bandwidth on
demand as explained above.

© EUROCAE, 2009
 16

2.5. SPECIFIC SAFETY AND SECURITY REQUIREMENTS

An important consideration for safety and security is the implementation of mechanisms to

ensure that voice communication services are delivered with acceptable security and
availability for controllers in various ATM systems. Key requirements are as follows:

• Fast delivery

• Priority for critical information (e.g., emergency call)

• Service Availability

• Redundancy/Backup services

Tools that could support these requirements include:

• Secure real-time transport protocol (SRTP)

• Security and encryption using IP Security (IPsec)

2.5.1. Security Policy and requirements

(35) Security procedures and mechanisms SHALL be described for the IP Network to protect
against security incidents; principles of Security Policy (CHAPTER III) SHALL be used.
(36) Static firewalling rules MAY be used for Raw RTP sessions in the IP Network.

2.5.2. Security Management

The goal of security management is to control access to network resources in accordance

with the following criteria:

• Authentication – Verify the person attempting to access a resource or service

• Authorization – Verify that the user is permitted to perform certain operations

offered by a resource or service

• Packet integrity – Verify the integrity of the cryptographic data checksum that
confirms the integrity of unaltered packets

• Auditing – Historical tracking of logs used in postmortem investigations as a result

of security incidents or proactive precautionary measures

Aside from securing the enterprise data, security management must also ensure that the
infrastructure (e.g., network, servers) cannot be sabotaged intentionally or unintentionally.
A security management subsystem, for example, can monitor users logging on to a
network resource and can refuse access to those who enter inappropriate access codes.

Security management subsystems work by partitioning network resources into authorized

and unauthorized areas. For some users, access to any network resource is
inappropriate, mostly because such users are usually company outsiders. For other

© EUROCAE, 2009
 17

(internal) network users, access to information originating from a particular department is

inappropriate.

Security management subsystems perform several functions. They identify sensitive

network resources (including systems, messages, and other entities) and determine
mappings between sensitive network resources and user sets. They also monitor access
points to sensitive network resources and log inappropriate access to sensitive network
resources.

(37) The IP Network SHALL have a capability to control access to network elements.
(38) The IP Network SHALL have a capability to perform proactive measures to protect
against security incidents.
(39) The IP Network SHALL have a capability to perform security monitoring, logging and
reporting.
(40) The IP Network SHALL have a capability to take immediate action in the event of
detected security incidents to protect network integrity and performance.

© EUROCAE, 2009
 18

CHAPTER II REFERENCES

[1] NIST Security Considerations for Voice Over IP Systems; D. Richard Kuhn, Thomas J.
Walsh, Steffen Fries
http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf
[2] IETF RFC 791: Internet Protocol (IP) version 4;
http://www.ietf.org/rfc/rfc791.txt
[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification;
http://www.ietf.org/rfc/rfc2460.txt
[4] ED-138 Network Requirements and Performances for VoIP ATM Systems Part 2:
Network Design Guideline;
http://www.eurocae.org
[5] IETF RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
Routing
IETF RFC 2858: Multiprotocol Extensions for BGP-4
http://www.ietf.org/rfc/rfc2545.txt; http://www.ietf.org/rfc/rfc2858.txt
[6] IETF RFC 2740: OSPF for IPv6
http://www.ietf.org/rfc/rfc2740.txt

© EUROCAE, 2009
 19

CHAPTER III

SECURITY POLICY

3.1. BACKGROUND

Current ATM voice switching services for G-G networking are supported with private
dedicated links. Such networks are considered secure, since they are not vulnerable to
network-layer attacks by viruses and other malicious cyber activities.
However, migration of ATM G-G voice communications to a VoIP medium is underway,
which will enable flexible deployment of high-availability services, and cost-effective
sharing of common media with data communications. On the other hand, the accessibility
provided by this technology leaves it open to malicious intrusion. To address such
vulnerabilities, an architecture founded upon robust security protections should be
developed, based upon stakeholder policies and needs, and industry standards and best
practices.

The scope of this chapter is to define the security policy for VoIP implementations to
support ATM communications. This includes the required security architecture and
component mechanisms. This policy only covers information security, and does not
establish requirements for physical security.

Detailed technical solutions are not given in this chapter – they can be found in ED-138
Network Requirements and Performances for VoIP ATM Systems Part 2.

The complexity of ATM security needs in a VoIP environment is best addressed with a
comprehensive policy. This is based upon well-known security principles that encompass
the network, application, and architectural domains. Relevant requirements and
recommendations are described below.

3.2. ATM SECURITY PRINCIPLES

ATM communications security is characterized by the level of confidentiality, integrity, and

availability provided by the supporting infrastructure and connected systems.
3.2.1. Confidentiality
Confidentiality ensures that the information is not disclosed to unauthorized persons or
processes. The concept of confidentiality attempts to prevent the intentional or
unintentional unauthorized disclosure of message content. Loss of confidentiality can
occur in many ways, such as through the intentional release of privileged information or
through a misapplication of network access rights. In the ATM environment, this could be
important for sensitive air traffic situations (e.g., military and government flight missions).
3.2.2. Integrity
Integrity ensures that the information relayed from its source to its intended destination is
authentic, complete, and accurate within specified parameters.

© EUROCAE, 2009
 20

Integrity is enabled with the following approaches:

• Prevention of the modification of information by unauthorized users
• Prevention of the unauthorized or unintentional modification of information by
authorized users
• Preservation of the internal and external consistency

This is crucial for VoIP messaging for ATM, where corrupted or modified messages could
incur safety risks for aviation.

3.2.3. Availability
Availability ensures that authorized users have timely and uninterrupted access to the
information in the system within specified parameters. As such, availability establishes a
quantifiable guarantee that the required information, systems and services are
operationally functional when needed. This is important for ATM operations, where
communication interruptions could result in safety issues and flight operations delays.

3.3. VOIP SECURITY

The key to securing VoIP is to use security policies and mechanisms analogous to those
implemented in data-only networks (e.g., firewalls, encryption, gateways) to emulate the
security level currently available to Private Switched Telephone Network (PSTN) network
users.

3.3.1. Threats in VoIP networks

Potential threats to a VoIP environment exploit vulnerabilities in end-points, servers, and
other network elements. These threats can have impacts on confidentiality, integrity and
availability of a VoIP system.

Confidentiality
Their impact on confidentiality may be exemplified regarding a communications node,
where eavesdropping on conversations is an obvious concern, but the confidentiality of
other information must also be protected to defend against toll fraud, voice and data
interception, and denial of service attacks. Network IP addresses, operating system type,
telephone number-to-IP address mappings, and communication protocols are all
examples of information that, while not critical as individual pieces of data, can make an
attacker’s job easier.
With conventional telephones, eavesdropping usually requires either physical access to
tap a line, or penetration of a switch. Attempting physical access increases the intruder’s
risk of being discovered, and conventional PBXs have fewer points of access than VoIP
systems. With VoIP, opportunities for eavesdroppers increase dramatically, because of
the many nodes in a packet network.

© EUROCAE, 2009
 21

Integrity
Communication nodes must protect the integrity of critical system data (e.g., configuration
messages). Because of the richness of feature sets available on nodes, an attacker who
can compromise the system configuration can accomplish nearly any other goal.
Damaging or deleting information about the IP network used by a VoIP node could result
in a denial of service.
The security system itself provides the capabilities for system abuse and misuse. That is,
compromise of the security system not only allows system abuse but also allows the
elimination of all traceability and the insertion of trapdoors for intruders to use on their next
visit. For this reason, the security system must be carefully protected.
Integrity threats include any in which network functions or data may be corrupted, either
accidentally or because of malicious actions. Misuse may involve legitimate users (i.e.,
insiders performing unauthorized operations) or intruders.
A legitimate user may perform an incorrect or unauthorized operational function (e.g., by
mistake or out of malice) and may cause deleterious modification, destruction, deletion, or
disclosure of sensitive network data. This threat may be caused by several factors,
including the possibility that the level of access permission granted to the user is higher
than what the user needs to remain functional.

Availability
Availability is the most obvious risk for a switch. Attacks exploiting vulnerabilities in the
switch software or protocols may lead to deterioration or even denial of service or
functionality of the switch. A voice over IP system may have additional vulnerabilities due
its exposure to the Internet. As such, attackers may be able to bring down VoIP systems
by exploiting weaknesses in Internet protocols and services.
It is known that any network may be vulnerable to denial of service attacks, simply by
overloading the capacity of the system and interrupting traffic flow. With VoIP, the problem
may be especially severe, because of its sensitivity to packet loss or delay.

The most significant security concerns in a VoIP environment are:

• Denial of Service (DoS) Attacks: Endpoints, such as IP telephones, and VoIP
gateways (w/ embedded SIP proxies), can be attacked via bombardment with
rogue packets to disrupt communications.
• Call Interception: Unauthorized monitoring of voice packets or hacking of the Real-
Time Transport Protocol (RTP) [12].
• Signal Protocol Tampering: Similar to call interception but for signalling traffic, a
malicious user could monitor and capture the packets that set up the call. By doing
this, they can manipulate fields in the data stream and interfere with
communications, which could be used for a DoS attack.
• Presence Theft: Impersonation of a legitimate user sending or receiving data

© EUROCAE, 2009
 22

3.4. NETWORK MODEL

Assumption: Air Navigation Service Provider (ANSP) local domains (either owned and
defined by a single ANSP, or shared within an ANSP group) or other related organization
domains are operated and managed autonomously. These domains (that each may
contain networks and hosts) do not necessarily have mutual trusting relationships with
each other.
Based on this assumption a simplified model was created to define the different security
zones, as follows:

Zone 1: IP Core (e.g., Pan European Network Service (PENS) or an alternative

shared IPv4/IPv6 [1][2][3] Backbone)
This zone is typically used for cross border communication.
Zone 2: Access (from Organizations to the shared IP Core infrastructure)
Zone 3: ANSPs and other related Organizations Domains

Security
Zone 1
IP Core Provider
Responsibility of

IP Core

IP Core IP Core IP Core

Edge Edge Edge
Security
Zone 2
Demarcation Line

Possible Interconnections
ANSPs/Organizations
Responsibility of

Organization Organization Organization

Edge Edge Edge
Security
Zone 3 Organization Organization Organization
(WAN) (WAN) (WAN) Admin
Network
LAN LAN LAN

VoIP VoIP VoIP

FIGURE 5: SIMPLIFIED NETWORK MODEL

Figure 5 shows a simplified model of a multi-national ATM communications network. The

model shows a logical view.
The IP Core is a service offered by a Service Provider (SP); the IP Core Edge is the
customer premises equipment to be installed at the designated access point locations.
This could be a combination of devices (e.g., modems, switches, routers, and cables) in
order to deliver the communication service.

© EUROCAE, 2009
 23

The Demarcation Line is the border between the different responsibilities (i.e.,
Organization and Service Provider domains).
The Organization Edge could also be a combination of devices (e.g., modems, switches,
routers, firewalls and cables) with connection to the IP Core Edge.
Organization and IP Core Edge might be located in the same shelf or computer room –
however different responsibilities are assigned as shown in the figure.
Interconnections between different organization networks are possible without using a
shared IP media (e.g., using dedicated leased lines or TDM links).
Such arrangements (as shown in Figure 5 as Possible Interconnections between
Organization Domains) are only required to comply with the ANSP/Organization Edge
requirements in Section 3.5.2.

© EUROCAE, 2009
 24

3.5. SECURITY REQUIREMENTS

This section describes the security requirements for the Security Zones shown in Figure 5.

3.5.1. Zone 1 (IP Core)

Requirements:

• Edge-to-Edge encryption SHALL be available for the different connections, its

actual use is to be specified in Service-Level-Agreements (SLA’s).
• Network Management services SHALL use encrypted and authenticated
technologies (e.g., SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.

© EUROCAE, 2009
 25

3.5.2. Zone 2 (Access to the shared IP Core)

Requirements and recommendations:

Common requirements
• Network Management capabilities SHALL use encrypted and authenticated
technologies (e.g., SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.
• There SHALL be coordination procedures defined between IP Core Provider and
ANSPs/organizations to mitigate the harmful effects of security incidents (e.g.,
activation of upstream-countermeasures by IP Core Provider in case of an attack-
detection by the ANSPs/organizations).
• Operation of Security elements SHALL stay up-to-date with the evolution of
protection mechanisms.

ANSP/Organization Edge requirements

• Any incoming message source addresses (ANSP point of view) SHALL be
monitored and controlled. If incoming traffic has a source address, which belongs
to the (destination-) ANSP internal address space, the traffic SHALL be discarded.
• Outgoing traffic (ANSP point of view) SHALL be monitored and controlled. If the
source address does not belong to the initiating ANSP or organization domain, the
traffic SHALL be discarded.
• Firewalling rules SHALL be defined and implemented; at least static packet
filtering (“stateless inspection”) SHALL be used to protect the network. Dynamic
packet filtering (“stateful inspection”) SHOULD be used.
• Firewall configuration and maintenance procedures SHALL be defined and
implemented for each organization.

IP Core Edge requirements

• Network Ingress Filtering [4] mechanisms SHALL be used in order to limit possible
Denial of Service (DOS) attacks.
• Mechanisms SHALL be implemented to prevent any unwanted traffic to be
forwarded to the ANSP/Organization Edge (e.g., Intrusion Detection and
Prevention Systems, Sink Holes, Access Rate Control)

© EUROCAE, 2009
 26

3.5.3. Zone 3 (ANSPs and other related Organizations Domain)

Requirements:

• Firewalls and Intrusion Detection/Intrusion Prevention systems (IDS/IPS) SHALL

be used in private networks to control traffic to/from non-operational networks
(e.g., administrative networks). Non-operational networks can be private or public
networks.
• Data and Voice networks SHALL be separated logically (e.g., VLAN technology)
or physically.
• Filtering mechanisms for traffic between servers and clients SHALL be used to
protect the servers.
• The network infrastructure SHALL offer technical means to ensure the integrity of
the overall voice communication service. Any violation of the integrity SHOULD be
detectable.
• The network infrastructure SHALL offer technical means to ensure the
confidentiality of the overall voice communication service. Any violation of
confidentiality SHOULD be detectable.
• The network infrastructure SHALL offer technical means to ensure the authenticity
of the source/destination of the overall voice communication service. Any violation
of the authenticity SHOULD be detectable.
• The management functions SHALL be separated logically (e.g., VLAN, out of
band) or physically.
• Network Configuration Management SHALL use encrypted and authenticated
technologies (e.g., SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.
• Operation of Security elements SHALL stay up-to-date with the evolution of
protection mechanisms.

© EUROCAE, 2009
 27

3.6. GENERAL RECOMMENDATIONS

The most significant security concerns in a VoIP environment are mentioned in chapter
3.3.1.
Countermeasures to these threats include:
• Secure Real-time Transport (SRTP), which provides confidentiality, message
authentication, and replay protection for RTP and Real-time Transport Control
Protocol (RTCP) traffic [5].
• Authentication: Mechanisms should be activated to ensure the integrity of the
voice packets to ensure that what is presented at the destination node is identical
to what was issued from the source node.
• Access control: This is supported by a tool suite to enable blocking of unauthorized
users from invoking voice services

NIST SP 800-58 [1] discusses the impact of these and related issues on VoIP over private
and public networks, for which it recommends the following:

• Appropriate network architecture SHOULD be developed

• Voice and data SHOULD be separated on logically different networks.
• Multimedia protocols SHOULD be isolated from the data network. Strong
authentication and access control SHOULD be used on the voice gateway system,
which interfaces with the PSTN, SIP, H.323, or MGCP [15] connections from data
network.
• Mechanisms SHOULD be deployed for allowing VoIP traffic to traverse firewalls
(e.g., Application Level Gateways, Session Border Controllers).
• Stateful packet filters SHOULD be implemented to track connections and deny
non-compliant packets.
• IPSec [9] [10] [11], MPLS [20], and tunnelling technologies SHOULD be used to
secure network and link layers and TLS [7] SHOULD be used to protect
multimedia protocol signalling for upper layers.
• To enhance performance, encryption at the router or gateway SHOULD be
invoked, not at the endpoints, to provide for IPSec tunnelling.
• Uninterruptible Power Supplies (UPS) and other mechanisms SHOULD be used to
enhance availability and integrity.
• Separate Dynamic Host Configuration Protocol (DHCP) servers SHOULD be
provided to ease the incorporation of intrusion-detection and VoIP firewall
protection [17].
• Softphone systems SHOULD be avoided when security and privacy is a concern.

• Although the thrust of this document is to establish security policy for VoIP ATM
communications, practitioners SHOULD analyse the tradeoff of implementing
security mechanisms with their impact on ATM operational performance.

© EUROCAE, 2009
 28

CHAPTER III REFERENCES

[1] Special Publication 800-58, NIST Security Considerations for Voice Over IP Systems;
D. Richard Kuhn, Thomas J. Walsh, Steffen Fries
http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf
[2] IETF RFC 791: Internet Protocol (IP) version 4;
http://www.ietf.org/rfc/rfc791.txt
[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification;
http://www.ietf.org/rfc/rfc2460.txt
[4] IETF RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing; RFC 3704: Ingress Filtering for Multihomed
Networks
http://www.ietf.org/rfc/rfc2827.txt, http://www.ietf.org/rfc/rfc3704.txt
[5] IETF RFC 3711: The Secure Real-Time Transport Protocol (SRTP);
http://www.ietf.org/rfc/rfc3711.txt
[6] IETF RFC 4301: Security Architecture for the Internet Protocol;
http://www.ietf.org/rfc/rfc4301.txt
[7] IETF RFC 4346: The TLS Protocol Version 1.1; IETF RFC 4366: TLS Extensions;
IETF RFC 4680: TLS Handshake Message for Supplemental Data; IETF RFC 4681:
TLS User Mapping Extension
http://www.ietf.org/rfc/rfc4346.txt, http://www.ietf.org/rfc/rfc4366.txt,
http://www.ietf.org/rfc/rfc4680.txt, http://www.ietf.org/rfc/rfc4681.txt
[8] IETF RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification; IETF RFC 4884: Extended ICMP to Support Multi-part
Messages
http://www.ietf.org/rfc/rfc4443.txt, http://www.ietf.org/rfc4884.txt
[9] IETF RFC 4302: IP Authentication Header (AH); IETF RFC 4835: Cryptographic
Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
http://www.ietf.org/rfc/rfc4302.txt, http://www.ietf.org/rfc/rfc4835.txt
[10] IETF RFC 4303: IP Encapsulating Security Payload (ESP); IETF RFC 4835:
Cryptographic Algorithm Implementation Requirements for Encapsulating Security
Payload (ESP) and Authentication Header (AH)
http://www.ietf.org/rfc/rfc4303.txt, http://www.ietf.org/rfc/rfc4835.txt
[11] IETF RFC 4306: Internet Key Exchange (IKEv2) Protocol
http://www.ietf.org/rfc/rfc4306.txt
[12] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications;
http://www.ietf.org/rfc/rfc3550.txt
[13] IETF RFC 3261: SIP: Session Initiation Protocol; IETF RFC 3265: Session
Initiation Protocol (SIP)-Specific Event Notification; IETF RFC 3853: S/MIME
Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol
(SIP); IETF RFC 4320: Actions Addressing Identified Issues with the Session Initiation
Protocol's (SIP) Non-INVITE Transaction

© EUROCAE, 2009
 29

http://www.ietf.org/rfc/rfc3261.txt, http://www.ietf.org/rfc/rfc3265.txt,
http://www.ietf.org/rfc/rfc3853.txt, http://www.ietf.org/rfc/rfc4320.txt
[14] IETF RFC 3265: Session Initiation Protocol (SIP) – Specific Event Notification;
http://www.ietf.org/rfc/rfc3265.txt
[15] IETF RFC 3435: Media Gateway Control Protocol version 1.0 (section 5); IETF
RFC 3661: Media Gateway Control Protocol (MGCP) Return Code Usage
http://www.ietf.org/rfc/rfc3435.txt, http://www.ietf.org/rfc/rfc3661.txt
[16] IETF RFC 2764: A Framework for IP Based Virtual Private Networks;
http://www.ietf.org/rfc/rfc2764.txt
[17] IETF RFC 3315: DHCP for IPv6; IETF RFC 4361: Node-Specific Client Identifiers
for DHCPv4
http://www.ietf.org/rfc/rfc3315.txt, http://www.ietf.org/rfc/rfc4361.txt
[18] IETF RFC 4251: The SSH Protocol Architecture;
http://www.ietf.org/rfc/rfc4251.txt
[19] IETF STD 62: An Architecture for Describing SNMP Management Frameworks;
http://www.ietf.org
[20] IETF RFC 3031 “Multiprotocol Label Switching Architecture”, RFC 3032 “MPLS
Label Stack Encoding”, RFC 3443 “TTL Processing in MPLS Networks”, RFC 4182
“Removing a Restriction on the Use of MPLS Explicit NULL”
http://www.ietf.org/rfc/rfc3031.txt, http://www.ietf.org/rfc/rfc3032.txt,
http://www.ietf.org/rfc/rfc3443.txt, http://www.ietf.org/rfc/rfc4182.txt
[21] IETF RFC 3414, User-based Security Model (USM) for version 3 of the Simple
Network Management Protocol (SNMPv3)
http://www.ietf.org/rfc/rfc3414.txt

© EUROCAE, 2009
 30

CHAPTER IV

IP ADDRESSING

4.1. BACKGROUND

Voice over IP (VoIP) defines a way to carry voice calls over an IP network including the
digitisation and packetisation of the voice streams. The use of IP telephony and the VoIP
standards will support the creation of an ATM communication system where higher-level
features (e.g., advanced call routing, voice mail, call/contact centre) can be deployed to
support air traffic services.
This chapter proposes a standards-based common addressing structure to accommodate
the heterogeneity of end systems in the national and international ATM domains.
The proposed addressing structure is an extract from the results of the iPAX Task Force6.

Network addressing is embedded in IP packets to enable their routing to intermediate or

end systems (e.g., servers or telephones). The format of this addressing is dependent on
the version of IP being used (i.e., IPv4 [1] [2] or IPv6 [1] [4] [5]), which are described
below.

6
EUROCONTROL EATM Internet Protocol for Aeronautical Exchange Task Force

© EUROCAE, 2009
 31

4.1.1. IPv4 Overview

IPv4 addresses are used to identify device interfaces to hosts, routers, gateways,
adapters, and IPv4 telephones. Each device interface in an IPv4 network must be
assigned to a unique IPv4 address to receive or transmit voice and data packets.
IPv4 uses 32-bit binary numbers to identify the source and destination address in each
information packet. IPv4 addresses are parsed into two portions - Network and Host. The
predominance of one portion over the other within the 32-bit space determines the
Address Class. Those classes are referred to as Class A through Class E [1]. Please see
information about CIDR Address Allocation Architecture in [2].

Figure 6 illustrates the five IPv4 address class formats.

32 bits
0 Byte 2 Byte 3 Byte 4
Class A Byte 1 Host portion
Network portion
1 0
Class B Networking portion Host portion

1 1 0
Class C Networking portion Host portion

1 1 1 0
Class D Multicast address

1 1 1 1 Byte Byte 2 Byte 3 Byte 4

1
Class E Experimental
FIGURE 6: IPV4 ADDRESSING FORMAT

Class A frames are identified by a 0 value high order bit. They provide 7 bits for the
network portion of the address, and 24 bits for the host. Class A addresses were allocated
at the initial deployment of the Internet, and are primarily held by North American
government agencies, and legacy companies that were involved in early Internet research
and development.
Class B frames are identified with the two high order bits set to 10. These addresses are
typically allocated to Internet Service Providers (ISP) and large organizations.

© EUROCAE, 2009
 32

Class C frames are identified with the three high order bits set to 110. Each of these
addresses can support up to 256 hosts. These addresses are typically allocated to LAN
and WAN nodes.
Note: Class A, B, and C addresses are assigned by local, national, or regional Internet
registries (the latter being RIPE NCC [Réseaux IP Européens Network Coordination
Centre] in Europe) to ISPs, from which they assign addresses to their customers.
Class D addresses are identified by the four high order bits set to 1110. These addresses
are used for multi-casting applications, where voice and data packets can be sent to
groups of multiple nodes concurrently. These groups are pre-defined in the network
topology by aggregation of node addresses. Multicasting enables efficient transmission of
high-bandwidth payloads by minimizing multiple streams of voice and data to individual
nodes.
Class E addresses are identified by the four high order bits set to 1111. This address
space is reserved for experimental research.

Table 5 shows the numeric ranges and decimal equivalents.

Class Length of network Address number

address (bits) range (decimal)
A 8 0 – 127
B 16 128 - 191
C 24 192 - 223

TABLE 5: NUMERIC RANGES

To isolate the critical ATM VoIP infrastructure from the public Internet, and to mitigate the
acquisition of scarce addressing from the global IP space, private addressing 0 [7] may be
structured and allocated. However, this architecture may be incompatible with other
independently structured privately addressed domains, or with the public Internet, unless
the Network Address Translation (NAT) mechanisms and firewalls supporting such private
addressing are designed for this type of interfacing.

© EUROCAE, 2009
 33

4.1.2. IPv6 Overview

IPv6 [1], [5], Erreur ! Source du renvoi introuvable., [9], features a much larger
addressing space than IPv4, as shown in Figure 7. This enables an ISP or enterprise
organization to aggregate the prefixes of node or user groups (e.g., customers, or internal
users) under a single Network Prefix for advertisement on the IPv6 Internet.

XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX

Network Prefix Interface ID

Figure 7: IPv6 Addressing Format
XXXX = 0000 through FFFF, while X is a 4-bit hexadecimal value.
The 128-bit IPv6 address is separated into eight 16-bit hexadecimal numbers. In order to
alleviate the cumbersome size of these addresses, the IPv6 community has developed
the following notational shorthand:
• Leading “0”s can be removed
• 0000 = 0 (compressed form)
• “::” represents one or more groups of 16-bits; “0” can only appear once in an address.
For example, 2001:0:13FF:09FF:0:0:0:0001 = 2001:0:13FF:09FF::1
• The lower four 8-bits can use decimal representation of IPv4 address for example,
0:0:0:0:0:0:192.168.0.1

IPv6 addressing encompasses the following types:

• Unicast [6] – used to identify a single interface. Unicast supports the following address
types: Global Unicast Address, Site – Local Unicast address, and Link – Local Unicast
address as illustrated in Figure 8

001 Global routing Prefix Subnet ID Interface ID

(3-bits) (45 - bits) (16 - bits) (64 - bits)
Global Unicast Address Format

1111111011 Subnet ID
or Set value to Site Link Interface ID
FEC0::10 “0” add (16- (64 – bits)
(10 - bits) (38 – bits) bits)
Site – Local Unicast Address Format

1111111010
or Set value to “0” Interface ID
FE80::10 (54 – bits) (64 – bits)
(10 - bits)
Link – Local Unicast Address format

Figure 8: Type of Unicast Addressing format

© EUROCAE, 2009
 34

Table 6 illustrates IPv6 main addressing type.

Allocation Prefix Function of Address Space

Global Unicast Addresses 001 1/8

Link Local Addresses 1111 1110 10 1/1024

Site Local Addresses 1111 1110 11 1/1024

Multicast Addresses 1111 1111 1/256

Table 6: IPv6 Main Addressing Type

Anycast [9] – a global address that is assigned to a set of interfaces belonging to different
nodes. Anycast addresses have the following restrictions:
• An Anycast address must not be used as a source address of an IPv6 packet
• An Anycast address must not be assigned to an IPv6 host. It may be assigned to an
IPv6 router.

Figure 9 shows the anycast addressing format.

Subnet prefix 00000000000000000000

128 – Bits
Figure 9: Anycast Addressing Format

Within each subnet, the highest 128 interface identifier values are reserved for
assignment as subnet anycast addresses. The construction of these addresses depends
upon the IPv6 address type used in the subnet, as indicated by the format prefix of the
address. In particular, IPv6 address types requiring 64 bit interface identifiers in Extended
Unique Identifier-64 (EUI-64) format [11] are constructed as depicted in Figure 10.

Subnet Prefix 111111X1111…. 111 Anycast ID

(64 – bits) (57- bits) (7 – bits)
Figure 10: Reserved subnet anycast address format with EUI-64 interface identifiers
X = “1” if EUI-64 Globally Administrated, and “0” if EUI-64 Locally Administrated.
An IPv6 Address with Embedded IPv4 Address is used in transition techniques when
migrating IPv4 domains to IPv6, as shown in Figure 11. The 16 “X” bits take a value of
“0000” when assigned as a Unicast address to IPv6 nodes in an IPv4 routing

© EUROCAE, 2009
 35

infrastructure, and is known as an “IPv4-compatible IPv6 address”. The 16 “X” bits take a
value of “FFFF” when used to represent IPv4 nodes in an IPv6 address format, and is
known as an “IPv4-mapped IPv6 address” [9].

0000………………………………….0000 XXXX IPv4 address

(80 – bits) (16-bits) (32 – bits)

Figure 11: IPv6 with Embedded IPv4 Address

Multicast [9] is assigned to a set of interfaces that may belong to different nodes. A
packet sent to a multicast address is delivered to all interfaces identified by that address.
Its format is shown in Figure 12.

11111111 Flags (4-bits) Group ID (112 – bits)

(8-bits) and
Scope (4-bits)

Figure 12: Multicast Addressing Format

The leading eight bits (“11111111”) identifies the address as being a multicast address.
“Flags” is a set of four bits, as configured below:
0 0 0 T

T = 0 indicates a permanently assigned address by the Internet Assigned Number

Authority (IANA) [8].
T = 1 indicates a non-permanently-assigned (transient) multicast address.
Scope is a 4-bit field, used to limit the scope of the multicast group. The values are:
1 = Interface – local
2 = Link - local
3 = Subnet - local
4 = Admin - local
5 = Site - local
8 = Organization – local
E = Global

© EUROCAE, 2009
 36

Table 7 illustrates IPv4 concepts and their IPv6 equivalent Erreur ! Source du renvoi
introuvable..

IPv4 Address IPv6 Address

Internet address classes Not applicable in IPv6
Addresses are 32 bits in length Addresses are 128 bits in length
Multicast address (224.0.0.0/4) IPv6 multicast addresses (FF00::/8)
Broadcast addresses Not applicable in IPv6
Unspecified address is 0.0.0.0 Unspecified address is ::
Loop-back address is 127.0.0.1 Loop-back address is ::1
Public IP addresses Global Unicast addresses
Private IP addresses (10.0.0.0/8, Site-local addresses (FEC0::/10)
172.16.0.0/12, and 192.168.0.0/16)
Auto-configured address (169.254.0.0/16) Link-local addresses (FE80::/64)
Text representation: Dotted decimal Text representation: Colon hexadecimal
notation format with suppression of leading zero
and zero compression. IPv4-compatible
addresses are expressed in dotted decimal
notation
Network bits representation: Subnet mask Network bits presentation: Prefix length
in dotted decimal notation or prefix length notation only
IPSec support is optional IPSec support is required

Table 7: IPv4 and IPv6 Equivalent

© EUROCAE, 2009
 37

4.1.3. Why IPv6

IPv4 was initially standardized in 1981. As the Internet became ubiquitous, the inherent
IPv4 QoS, security, addressing, and scalability capabilities were pushed to their limit.
These deficiencies, as well as new network services, exacerbated the strain placed on
IPv4 technology and its quest to accommodate the global needs for Internet services. To
continue using IPv4 under this load required that new features and capabilities be
developed, standardized, and “bolted on”. This approach would have been costly, risky,
and difficult to manage. This resulted in the development of a next generation networking
protocol IPv6. IPv6 was designed to overcome the limitations of IPv4 by:
• Expanding available IP address space to accommodate future demand
• More efficient addressing design and handling at the IP network layer
• Improving QoS to minimize packet loss/drops
• Operating over greater bandwidths for video conferencing and Voice over IP
(VoIP) applications
• Enhancing end-to-end security, which is critical for ATM applications
• Enabling more granularity and flexibility in message dissemination to individuals
and groups
• Establishing a “plug and play” capability for installing devices in an Ipv6 network
• Providing more robust network management on an enterprise scale
• Eliminating the need for network address translation (NAT)
• Incorporating a compact base header structure, which expedites packet routing –
less frequently used options are relegated to extension headers

There are many vendors offering IPv6 product lines that are often bundled with router and
operating system offerings on the market

As ATM communication services proliferate domestically and internationally,

its connectivity and communications capabilities need to become more
robust and scalable. IPv6 is an industry-standard solution that can support
L such growth in communication demand and geographical scope.
The key reason of deploying IPv6 is due to the current IPv4 deployments
between ANSPs which have extensive IP address domain overlaps making
the use of inter-WAN IPv4 too complex

© EUROCAE, 2009
 38

4.1.4. Transition Mechanisms

Support of legacy systems while transitioning to an IPv6 infrastructure is enabled with the
following strategies, as described:

• Dual stack, which requires that all end systems and networking devices host
concurrent IPv4 and IPv6 services in order to maintain connectivity until full
operational capability of IPv6 is achieved. Implementation of this strategy may
incur additional cost and management resources to support the deployment of
dual stacks at the various end systems. At this moment VoIP gateways between
IPv4 and IPv6 remain unavailable.

• Tunnelling, by encapsulating IPv4 traffic from legacy end systems within IPv6
packets to traverse the upgraded backbone

• Translation, via gateways between legacy systems and IPv6 backbone

© EUROCAE, 2009
 39

4.2. ADDRESSING SCHEME (REVISED IPAX SCHEME)

An IPv6 addressing scheme was developed within the context of the iPAX Task Force
(TF) [10], as illustrated in Figure 13.
The addressing scheme follows on from the RIPE allocation to provide /48 assignments.
Indeed, when considering the existing IPv4 addressing schemes, most ANSPs already
work with a private “Class A” address (e.g., 10.x.y.z, where x and y are octets used to
assign sites and subnets). With a /48 allocation, ANSPs have two octets to number their
sites and subnets and can still make use of IPv6 address auto-configuration.

RIPE Responsibilty
(32 bits)

3 13 13 3 3 13 16 64

FP TLA ID Sub-TLA Res. NLA ID SLA ID Interface ID

Net. v4/ Site

F1 F2 LAN ESI
Prefix v6 Location
3 bits 7 bits 1 bit 5 bits variable bits variable bits 64 bits

Common Responsibilty ANSP Authority

(Coordination Body) (80 bits)
(16 bits)

FIGURE 13: PROPOSED IPV6 ADDRESS STRUCTURE

To summarise the iPAX addressing scheme:
• The first 32 bits are fixed to 2001:4b50 (RIPE allocation)
• Field F1 is reserved for future use
• The fixed “Network Prefix” field is used to number each ANSP, organisation or
infrastructure that can be considered as a single entity; network prefix values have
been revised since the iPAX-TF and can be found in Annex A
• The v4/v6 field is a toggle bit that indicates if IP address translation is required at
the network border.
• The F2 field is assigned as defined in Annex A and has been revised since the
iPAX-TF.
ANSPs assign the remaining 80 bits of the address based on their own policies but should
note the advice provided in RFC 3531 (A Flexible Method for Managing the Assignment of
Bits of an IPv6 Address Block) in concert with the Annex A methodology for F2 field
assignments.
If required the use of the F1/F2 fields to number VoIP can be envisaged. The IPv6
addressing scheme is regularly presented to the EUROCONTROL EATM Communication
Team

© EUROCAE, 2009
 40

4.2.1. Address Management

Each European ANSP or EUROCONTROL stakeholder is initially assigned a network
prefix. Based on this network prefix, each organisation can advertise a /42 IPv6 address
prefix at their network border as listed in Annex A.
EUROCONTROL will enter this information into the RIPE database and indicate the
address space as being “sub-allocated”.
Then two /48 prefixes (one for real v6 nodes and the other to represent virtual v4 nodes)
for operational networks and another two for pre-operational networks will be assigned.
Looking at Figure 13, this will correspond to two values of the F2 field, each
complemented by a v4/v6 toggle bit. As agreed with RIPE representatives,
EUROCONTROL will enter this information into the RIPE database on behalf of the
organisation. These four assignments are referred to as the “basic assignment” and are
listed in Annex A.
This process will provide the same address space to all organisations irrespective of their
size. In reality, some organisations may be operating multiple, very large or regional
networks. Therefore, the basic assignment may be insufficient or inappropriate. In such
cases, an alternative assignment can be made within the organisations range as long as it
remains within the RIPE policy and does not compromise the overall addressing scheme.
In order to coordinate the management of address space, a Local Internet Registry (LIR)
is required. EUROCONTROL applied to RIPE (the European Internet Authority) for LIR
status in November 2004. This was accepted in December 2004 and in January 2005;
EUROCONTROL requested its first IPv6 allocation and received the standard LIR /32
allocation, as listed in the inet6num object extracted from the RIPE database
(http://www.ripe.net/db/index.html):

inet6num: 2001:4b50::/32
org: ORG-EitE1-RIPE
netname: BE-EUROCONTROL-20050131
descr: EUROCONTROL, the European Organisation for the Safety of Air Navigation
country: BE
admin-c: EJC2-RIPE
tech-c: EJC2-RIPE
status: ALLOCATED-BY-RIR
notify: eivan.cerasi@eurocontrol.int
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: EURO-HQ-MNT
mnt-routes: EURO-HQ-MNT
changed: hostmaster@ripe.net 20050131
source: RIPE

From this allocation, the EUROCONTROL Agency has begun the assignment of IPv6
addresses.

© EUROCAE, 2009
 41

ANNEX A : NETWORK ADDRESS ASSIGNMENTS

The IPv6 addressing scheme is regularly presented to the EUROCONTROL EATM Communication Team.

TABLE 8: CONFIRMED ASSIGNMENTS

© EUROCAE, 2009
 42

TABLE 9: CONFIRMED INTERLINK ADDRESSES

© EUROCAE, 2009
 43

TABLE 10: PLANNED ASSIGNMENTS

© EUROCAE, 2009
 44

CHAPTER IV REFERENCES

[1] IETF RFC-791, September 1991; IETF RFC-2460, December 1998: Internet Protocol
version 4 and version 6 Specifications
http://www.ietf.org/rfc/rfc791.txt; http://www.ietf.org/rfc/rfc2460.txt
[2] IETF RFC-1518, September 1993; An Architecture for IP Address Allocation with
CIDR
http://www.ietf.org/rfc/rfc1518.txt
[3] IETF RFC-2474, December 1998; Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers
http://www.ietf.org/rfc/rfc2474.txt
[4] IETF RFC-1752, January 1995: The Recommendation for IP Next Generation Protocol
http://www.ietf.org/rfc/rfc1752.txt
[5] IETF RFC-2460, December 1998: Internet Protocol, Version 6 (IPv6) Specification
http://www.ietf.org/rfc/rfc2460.txt
[6] IETF RFC-1887, December 1995 (Information): An Architecture for IPv6 Unicast
Address Allocation
http://www.ietf.org/rfc/rfc1887.txt
[7] IETF RFC-1918, February 1996: Address Allocation for Private Internets
http://www.ietf.org/rfc/rfc1918.txt
[8] IETF RFC-3232, January 2002, (Information): Assigned Numbers: RFC-1700 is
replaced by On-line Database
http://www.ietf.org/rfc/rfc3232.txt
[9] IETF-RFC-4291, February 2006: IPv6 Addressing Architecture
http://www.ietf.org/rfc/rfc4291.txt
[10] Internet Protocol for Aeronautical Exchange Task Force (iPAX-TF); Eivan Cerasi
http://www.eurocontrol.int/communications/public/standard_page/com_network.html
[11] IETF RFC-2526, March 1999: Reserved IPv6 Subnet Anycast Addresses
http://www.ietf.org/rfc/rfc2526.txt
[12] IETF RFC-4213, October 2005: Basic Transition Mechanisms for IPv6 Hosts and
Routers
http://www.ietf.org/rfc/rfc4213.txt
[13] IETF RFC-2766, February 2000: Network Address Translation – Protocol
Translation (NAT-PT); IETF RFC-3596, October 2003: DNS Extensions to Support IP
Version 6
http://www.ietf.org/rfc/rfc2766.txt; http://www.ietf.org/rfc/rfc3596.txt

© EUROCAE, 2009
 45

LIST OF EUROCAE WG-67 CONTRIBUTORS

FIRST NAME SURNAME COMPANY

Catalin Apostol ROMATSA
Annette Maria Balks Cisco
Dragos Baloi ROMATSA
Luca Bertagnolio Cisco
Armin Biegel DFS
Valérie Bruté de Rémur THALES
Hung Do-Duy INEO
Olivier Dupont Cisco
Graham Fellows Nortel
Christian Geiller INEO
Wolfgang Kampichler Frequentis
Pascal Lepers SITA
Davide Merulli OTE SELEX
Valery Pialat SITA
Juan Francisco Ramos González Indra
Mickaël Royer DSNA
Leon Sayadian FAA
Eric Weill SAIC (supporting FAA)
Marcelo Zomignani Indra

© EUROCAE, 2009