ED-138 Network Requirements and Performances for Voice over Internet Protocol (VoIP) Air Traffic Management (ATM) Systems

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

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

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

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

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 groundground 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

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

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.

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.

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

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 EATM 1 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

7 SERVICE TYPE APPLICATION DESCRIPTION GROUND COORDINATION AIR GROUND SERVICES G-G Voice Principally for Centre/Centre and Centre/Tower 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. A-G Voice Principally nationally based but SES 2 may require 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

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 LAN EDGE WAN EDGE LAN IP FIGURE 4 IP NETWORK DOMAIN CONCEPT

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.

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 length 1. payload only Acceptable latency 3 (without jitter) Acceptable Jitter 3 Acceptable Packet Loss rate 2. with CRTP 3. with CRTP and IPSec Default (best effort) N/A N/A N/A N/A Telephone voice Radio voice Telephone Signalling Radio Signalling 1. 160 Bytes 2. 164 Bytes 3. 212-222 Bytes 1. 160 Bytes 2. 164 Bytes 3. 212-222 Bytes 100ms 15ms 0.5% 50ms 15ms 0.5% 100ms 4 50ms 0.5% 50ms 4 50ms 0.5% 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

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 Climax 5 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) V max and signalling (signalling channels) S max 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 V max + S max concurrent channels. (16) For this maximum amount of channels V max + S max, 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

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 AF ij, 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

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 (best effort) 000000 CS0 Telephone voice 101110 EF Radio voice Telephone signalling 100010 AF41 Radio signalling Recording voice 011010 AF31 Note: TABLE 4 DSCP MAPPING 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.

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.

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.

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

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.

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

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.

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.

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

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: Zone 2: Zone 3: 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. Access (from Organizations to the shared IP Core infrastructure) ANSPs and other related Organizations Domains Security Zone 1 Security Zone 2 Responsibility of IP Core Provider IP Core Edge IP Core IP Core Edge IP Core Edge Demarcation Line Possible Interconnections Security Zone 3 Responsibility of ANSPs/Organizations Organization Edge Organization (WAN) LAN Organization Edge Organization (WAN) LAN Organization Edge Organization (WAN) LAN VoIP VoIP VoIP Admin Network 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.

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.

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.

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 attackdetection 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)

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.

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.

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

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

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 Force 6. 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

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 Class D 1 1 1 0 Multicast address Class E 1 1 1 1 Byte 1 Byte 2 Byte 3 Byte 4 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.

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 (bits) Address number 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.

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 (3-bits) Global routing Prefix (45 - bits) Subnet ID (16 - bits) Global Unicast Address Format Interface ID (64 - bits) 1111111011 or FEC0::10 (10 - bits) 1111111010 or FE80::10 (10 - bits) Set value to 0 (38 bits) Subnet ID Site Link add (16- bits) Site Local Unicast Address Format Set value to 0 (54 bits) Link Local Unicast Address format Interface ID (64 bits) Interface ID (64 bits) Figure 8: Type of Unicast Addressing format

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 (64 bits) 111111X1111. 111 (57- bits) Anycast ID (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

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 (80 bits) XXXX (16-bits) IPv4 address (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 (8-bits) Flags (4-bits) and Scope (4-bits) Group ID (112 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

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) Text representation: Dotted decimal notation Network bits representation: Subnet mask in dotted decimal notation or prefix length IPSec support is optional Link-local addresses (FE80::/64) Text representation: Colon hexadecimal format with suppression of leading zero and zero compression. IPv4-compatible addresses are expressed in dotted decimal notation Network bits presentation: Prefix length notation only IPSec support is required Table 7: IPv4 and IPv6 Equivalent

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 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

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

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 F1 Net. Prefix v4/ v6 F2 LAN ESI 3 bits 7 bits 1 bit 5 bits Site Location variable bits variable bits 64 bits Common Responsibilty (Coordination Body) (16 bits) ANSP Authority (80 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

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.

41 ANNEX A : NETWORK ADDRESS ASSIGNMENTS The IPv6 addressing scheme is regularly presented to the EUROCONTROL EATM Communication Team. TABLE 8: CONFIRMED ASSIGNMENTS

42 TABLE 9: CONFIRMED INTERLINK ADDRESSES

43 TABLE 10: PLANNED ASSIGNMENTS

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

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