ACP/WGN05-WP14
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
Working Group – N (Networking)
Working Paper
Comparison of Internet Protocol Version 4 (IPv4) Versus
Internet Protocol Version 6 (IPv6) For Aeronautical
Telecommunication Network (ATN)
Prepared by Leon Sayadian
USA FAA (ATO-P)
April 2005
SUMMARY
This working paper describes the capabilities and services of IPv4 versus IPv6 for
consideration in developing ATN Standards and Recommended Practices (SARPs) in
future Air Traffic Management (ATM) Systems.
1
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., data, voice, and
video). Current plans have adopted IPv4 technology to support this new approach. However, its
limitations in end-to-end security, scalability, addressability, mobility, and Quality of Service
(QoS) capabilities may hamper the deployment of future ATM communication services. It is
therefore recommended that Working Group N (WG-N) evaluate IPv6, which was developed to
address such deficiencies in IPv4.
This paper presents the technical factors to be considered by Subgroup N1 of WG-N for
evaluating Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) in
developing ATN SARPs for future ATM systems. A comparison of capabilities and benefits of
IPv4 and IPv6 protocols are described herein for review and consideration.
This paper will focus on IPv6, which provides the networking services found in IPv4, as well as
these additional features:








Larger address spaces
More efficient addressing design and handling at the IP network layer
Better QoS support
Imbedded security
Mobility and broadcasting
Increased support for a variety of communication services
Ensure future compatibility with industry, government, and international
systems
Airline industry is collaborating on a standard for airborne IPv6 [8].
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 by:







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
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
-2-
There are many vendors offering IPv6 products that are often bundled with router and operating
systems on the market, especially in the Asia/Pacific region [5, 12, 13].
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 intradomain 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
-3-
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 FY09 [5, 9, 10, 11].
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-
4.0 Issues
Cost considerations include:




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)
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.
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
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 WG-N and subgroups should begin planning to support IPv4 and IPv6 across the ATM
enterprise in order to exploit emerging converged communications services, which will enable
stakeholder organizations to decrease costs, reduce complexity, and provide new ATM
communication services. This includes dual stack, tunneling, translation and IPv6 transition
guidance materials that identify key communication requirements that can be supported by IPv4
and IPv6.
-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
6
Appendix
-7-
IPv4 and IPv6 Headers
• IPv4 Header
Version
IHL
Type of Service Figure
Identification
Flags
Time-to-live
Protocol
Total Length
Fragment Offset
Header Checksum
Source Address
Destination Address
Options
Padding
• IPv6 Header
Version
Class
Flow Label
Payload Length
Next Header
Source Address
Destination Address
-8-
Hop Limit
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
Fragmentation Flags
Fragment Offset
Removed in IPv6. Fragmentation information is not
included in the IPv6 header. It is contained in a Fragment
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
routers is present within the IPv4 header
Packet flow identification for QoS handling by routers is
included in the IPv6 header using the Flow Label field
Fragmentation is done by both routers and the sending
host
Fragmentation is not done by routers, only by the sending
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
ARP Request frames are replaced with multicast Neighbor
Solicitation messages
Internet Group Management Protocol (IGMP) is used
to manage local subnet group membership
IGMP is replaced with Multicast Listener Discovery (MLD)
messages
ICMP Router Discovery is used to determine the IPv4
address of the best default gateway and is optional
ICMP Router Discovery is replaced with ICMPv6 Router
Solicitation and Router Advertisement messages and is
required
Broadcast addresses are used to send traffic to all
nodes on a subnet
There are no IPv6 broadcast addresses. Instead, a link-local
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
fragmented)
Must support a 1280-byte packet size (without fragmentation)
- 10 -