Implementation of Internet Protocol Version 6 (Ipv6) for the Aeronautical Telecommunication

WP No. __

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

Subgroup N-1/3 (Internet Communications/G-G Applications)

Working Paper

Implementation Internet Protocol Version 6 (IPv6) For Aeronautical Telecommunication Network (ATN)

Prepared by Leon Sayadian/Kelly Kitchens USA FAA (ATO-P)

March 2006

SUMMARY

This working paper describes the limitation of Internet Protocol version 4 (IPv4) and consideration in IPv6 for implementing in ATN Standards and Recommended Practices (SARPs) in future Air Traffic Management (ATM) Systems.

1.0 Purpose and Scope

Air Traffic Management (ATM) communication services will be migrating to a common infrastructure approach that provides support for multimedia applications (e.g., voice and data). Current plan have adopted Transmission Control Protocol (TCP)/Internet Protocol version 4 (IPv4) infrastructures to support ATN. However, there are limitations in IPv4, which may be inhibitors to the end-to-end paradigm of Internet and achievement of ATM vision. It is recommended that subgroup N-1/3 evaluate IPv6, which was developed to address deficiencies in IPv4.

This paper presents the technical factors to be considered by evaluating IPv6 in developing ATN SARPs for future ATM systems. The capabilities and benefits of IPv6 protocols are described herein for review, consideration and implementation.

IPv4 was initially standardized in 1981 [1]. As the Internet became more 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 need 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 [2] was designed to overcome the limitations of IPv4 as follow:

 Expanding available IP address space to accommodate future demand  Improving QoS to minimize packet loss/drops  Operating over greater bandwidths for video conferencing and Voice over IP (VoIP) applications  Stateless and stateful address configuration  Enhancing end-to-end security, which is critical for the ATM  Providing more robust system management on an enterprise scale  Eliminating the need for Network Address Translation (NAT)  Incorporating a fixed header structure, which expedites packet routing  Mobility and multicasting  Airline industry is collaborating on a standard for airborne IPv6 [8].

There are many vendors already offering IPv6 products that are often bundled with router and operating systems on the market, especially in the North America, Asia, Europe, Latin America, and China region [5, 12, 13 and 14].

Why IPv6?

As discussed above, many large-scale domains have begun migrating from IPv4 to IPv6, citing the following advantages:

1. Increased address space – IPv4 has limited addressing capability (4-byte), whereas IPv6 has 16-byte capability (up to 3.4 x 1038 unique addresses!)

2. Improved efficiency in routing and packet handling – IPv6 supports hierarchical route aggregation, which streamlines backbone routing by reducing the volume of data routing information stored in the router infrastructure

3. Support for auto-configuration – Expedites network reconfiguration, plug-and-play capability for network devices, and node renumbering, for flexibility and scalability

4. Support for Internet Protocol Security (IPSec) – IPSec is native to the IPv6 protocol suite, expediting end-to-end security services, such as access control, confidentiality, authentication, and data integrity

5. Enhanced mobile service – The auto-configuration capability of IPv6 enables rapid convergence of dynamic addressing and routing for mobile applications

6. Elimination of the need for NAT – Cumbersome NAT implementations, which were often required for IPv4 implementations, is not necessary with IPv6, due to its larger address space

7. Support for widely deployed routing protocols – IPv6 supports inter- and intra- domain routing protocols, increased number of multicast addresses, and improved support of unicast and any-cast addressing

8. Neighbor Discovery – This IPv6 feature enables newly introduced IP hosts to easily discover the network topology, and obtain new, globally unique IPv6 addresses

9. Prioritization and QoS – These capabilities, supported by IPv6 environments, include packet classification, traffic shaping, queuing, and marking for various Internet communication streams, enabling prioritization of messages based upon criticality.

10. Cost savings – IPv6 has a robust set of native capabilities that would have to be individually deployed under IPv4

11. Interoperability with future industry, government, and international stakeholder systems – Inherent flexibility of IPv6, provided by the capabilities listed above, will expedite the accommodation of newly evolving systems among interdependent domains that are vital for seamless global ATM.

Details on the packet structures for IPv4 and IPv6, and a table comparing their features, are shown in the Appendix.

2.0 Benefits

As ATM communication services proliferate domestically and internationally, the connectivity and communications capabilities of their infrastructure need to become more robust and scalable. IPv6 is an industry-standard solution that can support such growth in communication demand and

geographical scope. This is especially significant regarding ATM future and legacy interfaces to stakeholder systems, which have migrated, or are poised to transition, to IPv6 [3, 4].

Regarding international interfaces, the International Civil Aviation Organization (ICAO) has standardized the use of the ATN schema [6] with 20-byte addressing. IPv4 cannot accommodate this, due to its limited address space of 4 bytes. IPv6, however, uses 16-byte addressing and extended header options, which readily accommodates the ATN addressing space [7].

Evolution of legacy ATM applications and deployment of new services and capabilities (as listed above) are readily supported in an IPv6 environment. The enhanced capabilities and features of IPv6 can enable the implementation of future services in a secure, flexible, and manageable environment. Due to the growing interest in IPv6, many COTS end systems and networking devices offer it as a native feature, making this a cost-effective approach for new deployment or transitioning from legacy communication infrastructures.

Stakeholder organizations are making progress towards adopting IPv6 in their enterprises, with plans to fully deploy it by FY08 [5, 9, 10, 11 and 14].

3.0 Migration Strategies

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.

 Tunneling, 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

4.0 Issues

1. Planning – Effort should be expended for transitioning IPv6 into a full operational capability. This includes consideration of equipment deployment, technical refreshment, and logistical considerations (e.g., equipment requiring enhancement) 2. Transition – Impact on operations must be assessed in deploying IPv6 capabilities and services, particularly when determining which approach in Issue #1 above is to be adopted, and whether candidate vendors can adequately meet this challenge. 3. Implementation – Replacement of extant end-system assets (i.e., hardware, software) is a significant factor in cost, but may be mitigated by extending the deployment schedule to take advantage of legacy system end-of-life-cycle milestones

4. Operations – Although too often minimized as a concern, consideration must be given for training operational and technical personnel on IPv6, and to adapt legacy applications to run with IPv6 functionality.

5.0 Recommendation

The SGN-1/3 should develop guidance material to support IPv4 in order to enable integration with IPv6 across the ATM enterprise. This will enable the ATN to exploit emerging converged communications services and allow stakeholder organizations to decrease costs, reduce complexity, and provide new ATM communication services, while continuing to use existing IPv4 networks. The topic recommendation for guidance material includes information on dual stack, tunneling, translation and IPv6 transition that will identify key communication requirements that should be supported by the ATN.

- 5 - 6.0 List of References

[1] RFC 791, “Internet Protocol”, Internet Engineering Task Force, September 1981

[2] RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification”, Internet Engineering Task Force, December 1998

[3] www.usipv6.com/2003arlington/main.html

[4] www.usipv6.com/2004santamonica/main.html

[5] www.ipv6forum.com

[6] ICAO Document 9705-AN/956, Third Edition, “Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)”, 2002

[7] ICAO/ATN Working Paper 405, “Additional Mapping Formats between Network Access Point Addresses (NSAPA) and Internet Protocol version 6 (IPv6) Addresses”, July 2002

[8] “ARINC Project Paper 664, Part 8”, Airlines Electronic Engineering Committee, Aircraft Data Networks (ADN) Working Group, November 10, 2003

[9] http://www.eurocontrol.int/ipax/

[10] http://www.nav6tf.org/slides/NAv6TF_Response_NTIA_IPv6_RFC_FINAL.pdf

[11] http://www.ntia.doc.gov/ntiahome/ntiageneral/ipv6

[12] http://www.netlec.com/it/ipv6.html

[13] http://www.usipv6.com

[14] http://www.gao.gov/new.items/d05471.pdf

Appendix

- 7 - IPv4 and IPv6 Headers

• IPv4 Header

Version IHL Type of Service Total Length Figure Identification Flags Fragment Offset Time-to-live Protocol Header Checksum Source Address Destination Address Options Padding

• IPv6 Header

Version Class Flow Label Payload Length Next Header Hop Limit

Source Address

Destination Address

- 8 - IPv4 Header Field IPv6 Header Field Version Same field but with different version numbers.

Internet Header Length Removed in IPv6. IPv6 does not include a Header Length field because the IPv6 header is always a fixed size of 40 bytes. Each extension header is either a fixed size or indicates its own size. Type of Service Replaced by the IPv6 Traffic Class field.

Total Length Replaced by the IPv6 Payload Length field, which only indicates the size of the payload. Identification Removed in IPv6. Fragmentation information is not Fragmentation Flags included in the IPv6 header. It is contained in a Fragment Fragment Offset extension header.

Time to Live Replaced by the IPv6 Hop Limit field. Protocol Replaced by the IPv6 Next Header field. Header Checksum Removed in IPv6. In IPv6, the link layer performs bit-level error detection for the entire IPv6 packet. Source Address The field is the same except that IPv6 addresses are 128 bits in length. Destination Address The field is the same except that IPv6 addresses are 128 bits in length. Options Removed in IPv6. IPv6 extension headers replace IPv4 options.

- 9 - IPv4 IPv6 Addresses are 32 bits in length Addresses are 128 bits in length

IPSec support is optional IPSec support is required

No identification of packet flow for QoS handling by Packet flow identification for QoS handling by routers is routers is present within the IPv4 header included in the IPv6 header using the Flow Label field Fragmentation is done by both routers and the sending Fragmentation is not done by routers, only by the sending host host Header includes a checksum Header does not include a checksum Header includes options All optional data is moved to IPv6 extension headers Internet Address Resolution Protocol (ARP) uses broadcast ARP Request frames are replaced with multicast Neighbor ARP Solicitation messages Internet Group Management Protocol (IGMP) is used IGMP is replaced with Multicast Listener Discovery (MLD) to manage local subnet group membership messages ICMP Router Discovery is used to determine the IPv4 ICMP Router Discovery is replaced with ICMPv6 Router address of the best default gateway and is optional Solicitation and Router Advertisement messages and is required Broadcast addresses are used to send traffic to all There are no IPv6 broadcast addresses. Instead, a link-local nodes on a subnet scope all-nodes multicast address is used Must be configured either manually or through DHCP Does not require manual configuration or DHCP

Must support a 578-byte packet size (possibly Must support a 1280-byte packet size (without fragmentation) fragmented)

- 10 -