Work of Study and Research : ************************************* State of the art about known IPv6 stacks and small IPv6 stacks **********************
*************************************
Ibrahim MANROUFOU
M2 STRI
March 2009
State of the art about known IPv6 stacks and small IPv6 stacks
Table of contents Table of contents .......................................................................................................................2 List of figures .............................................................................................................................5 List of tables...............................................................................................................................6 1 Introduction .......................................................................................................................7 1.1 Purpose...............................................................................................................................7 1.2 Study’s context ..................................................................................................................7 1.3 Aeronautical context .........................................................................................................8 1.4 Glossary .............................................................................................................................9 1.5 Referenced documents ....................................................................................................10 1.5.1 Standard Internet documents.....................................................................................10 1.5.2 Web Sites ..................................................................................................................10 1.5.3 Internal documents ....................................................................................................11 2 Presentation of the Internet Protocol ............................................................................12 2.1 Internet Protocol version 4 .............................................................................................12 2.1.1 Overview ...................................................................................................................12 2.1.2 IP over OSI Model ....................................................................................................15 2.1.3 Limitations of IPv4 ...................................................................................................16 2.1.3.1 Addressing ................................................................................................................16 2.1.3.1.1 Address space............................................................................................................16 2.1.3.1.2 Disparity of geographic distribution .........................................................................17 2.1.3.2 Security .....................................................................................................................17 2.1.3.3 QoS (Quality of Service) ..........................................................................................17 2.1.3.4 Mobility.....................................................................................................................18 2.1.3.5 Multicast ...................................................................................................................18 2.1.3.6 Lack of auto configuration function..........................................................................18 2.1.4 Summary ...................................................................................................................18 2.2 Internet protocol version 6 .............................................................................................19 2.2.1 Modification of the header format ............................................................................19 2.2.2 IPv6 addressing .........................................................................................................21 2.2.2.1 Unicast address (One to one) ....................................................................................21 2.2.2.1.1 Global unicast ...........................................................................................................21 2.2.2.1.2 Site-local unicast address ..........................................................................................22 2.2.2.1.3 Link-local unicast address.........................................................................................22 2.2.2.2 Anycast address (one to nearest) ...............................................................................23 2.2.2.3 Multicast address (one to several) .............................................................................24 2.2.2.4 Specifics addresses ....................................................................................................24 2.2.2.4.1 Unspecified address ..................................................................................................24 2.2.2.4.2 Loopback address ......................................................................................................24 2.2.2.4.3 Multicast reserved addresses.....................................................................................24 2.2.3 IPv6 Operation ..........................................................................................................25 2.2.3.1 ICMPv6 .....................................................................................................................26 2.2.3.2 Neighbor discovery (ND)..........................................................................................27 2.2.3.3 Stateless auto configuration and renumbering of IPv6 nodes ...................................31 2.2.3.4 Security .....................................................................................................................32 2.2.3.5 Default address selection (DAS) for IPv6.................................................................33 2.2.3.5.1 Source address selection ...........................................................................................33 2.2.3.5.2 Destination address selection ....................................................................................34 2.2.3.6 Path Maximum Transfer Unit (PMTU) ....................................................................35 2.2.3.7 DHCPv6 and Domain Name Server (DNS)..............................................................35 2
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.3.8 Ipv6 jumbogram ........................................................................................................35 2.2.3.9 Multicast Listener Discovery (MLD) .......................................................................35 2.2.3.10 Mobile IPv6 ..............................................................................................................36 2.3 Summary ..........................................................................................................................37 3 Implementation of IPv6 protocol ...................................................................................38 3.1 Interoperability (IPv4/IPv6) ..........................................................................................38 3.1.1 Communication between IPv6 and IPv6 hosts or IPv4 and IPv4 hosts ....................38 3.1.1.1 Dual stack approach ..................................................................................................38 3.1.1.2 Tunneling approach ..................................................................................................39 3.1.1.2.1 Static tunneling .........................................................................................................39 3.1.1.2.2 Automatic tunneling..................................................................................................41 3.1.2 Communication between IPv4 and IPv6 hosts .........................................................44 3.1.2.1 DSTM (Dual Stack Transition Mechanism) .............................................................44 3.1.2.2 TRT ...........................................................................................................................45 3.1.2.3 SIIT ...........................................................................................................................46 3.1.2.4 NAT-PT ....................................................................................................................47 3.1.2.5 BIS ............................................................................................................................47 3.1.2.6 Socks gateway ...........................................................................................................49 3.1.2.7 TEREDO ...................................................................................................................49 3.1.3 Summary of cohabitation mechanisms .....................................................................50 3.2 IPv6 conformance ...........................................................................................................51 3.2.1 IPv6 Forum ...............................................................................................................51 3.2.1.1 IPv6 Ready Logo Phase Series – Phase-1, Phase-2 and Phase-3 .............................52 3.2.2 LCNA ........................................................................................................................54 3.2.2.1 LCNA features ..........................................................................................................54 3.2.2.2 LCNA node requirement ...........................................................................................54 3.2.3 Summary ...................................................................................................................55 4 Comparative study of existing IPv6 stacks ...................................................................56 4.1 IPv6 stacks for embedded system ..................................................................................56 4.1.1 Generic IPv6 stacks for embedded devices...............................................................56 4.1.1.1 KASAGO IPv6 .........................................................................................................57 4.1.1.2 NexGenIP ..................................................................................................................57 4.1.1.3 Treck IPv4/v6 Dual Stack .........................................................................................57 4.1.1.4 Fusion Embedded TCP/IPv4/v6 Dual-Mode Stack ..................................................57 4.1.1.5 IPNET .......................................................................................................................58 4.1.1.6 Acmet IPv6 Stack by (IN).........................................................................................59 4.1.1.7 uIPv6 stack ................................................................................................................59 4.1.2 Summary of generic stacks for embedded devices ...................................................60 4.1.3 IPv6 stacks for Specific embedded devices ..............................................................61 4.2 IPv6 stack for general specific OS (for non embedded devices) .................................62 4.3 Other Stacks ....................................................................................................................62 4.4 Summary of stacks comparison analysis ......................................................................62 5 Study of IPV6 solution integration in ADCN+ network .............................................63 5.1 ADCN+ Architecture presentation ................................................................................63 5.1.1 Objectives .................................................................................................................63 5.2 IPv6 implementation: impacted elements .....................................................................63 5.3 Possible solutions .............................................................................................................63 5.3.1 uIPv6 stack ................................................................................................................64 5.3.2 Acmet IPv6 Stack .....................................................................................................64 5.3.3 IPNET .......................................................................................................................64 5.3.4 KASAGO IPv6 .........................................................................................................64 3
State of the art about known IPv6 stacks and small IPv6 stacks
5.3.5 NexGenIP ..................................................................................................................64 5.3.6 Treck IPv4/v6 ............................................................................................................64 5.3.7 Fusion Embedded TCP/IPv4/v6 ...............................................................................65 5.4 Summary of possible solutions.......................................................................................65 6 Conclusion .......................................................................................................................66
4
State of the art about known IPv6 stacks and small IPv6 stacks
List of figures Figure 1 : Aircraft Network .................................................................................................................. 8 Figure 2 : IPv4 header format ............................................................................................................. 12 Figure 3 : IP over OSI model .............................................................................................................. 15 Figure 4 : NAT mechanism................................................................................................................. 16 Figure 5 : IPv4 addresses distribution ................................................................................................. 17 Figure 6 : IPv5 header vs. IPv4 header ............................................................................................... 19 Figure 7 : IPv6 extensions................................................................................................................... 20 Figure 8 : Global unicast address ........................................................................................................ 22 Figure 9 : Site-local unicast format ..................................................................................................... 22 Figure 10 : Link-local unicast address format .................................................................................... 22 Figure 11 : Anycast address format .................................................................................................... 23 Figure 12: Anycast illustration............................................................................................................ 23 Figure 13: Multicast address format ................................................................................................... 24 Figure 14: IPv6 node requirement ...................................................................................................... 26 Figure 15:ICMPv6 message format .................................................................................................... 27 Figure 16: Router solicitation message format ................................................................................... 27 Figure 17: Router advertisement message format .............................................................................. 28 Figure 18:Neighbor solicitation message format ................................................................................ 29 Figure 19: Neighbor advertisement message format .......................................................................... 29 Figure 20: Prefix discovery 1 .............................................................................................................. 30 Figure 21: prefix discovery 2 .............................................................................................................. 30 Figure 22: Address resolution ............................................................................................................. 31 Figure 23: MIPv6 ................................................................................................................................ 36 Figure 24: Dual stack approach .......................................................................................................... 38 Figure 25: Tunneling approach ........................................................................................................... 39 Figure 26: Static tunnel ....................................................................................................................... 40 Figure 27: Tunnel broker tunneling .................................................................................................... 40 Figure 28 : 6to4 address format .......................................................................................................... 41 Figure 29 : 6to4 network to 6to4 network .......................................................................................... 41 Figure 30 : 6to4 Network to native IPv6 ............................................................................................ 42 Figure 31: ISATAP address format .................................................................................................... 42 Figure 32: ISATAP ............................................................................................................................. 42 Figure 33 : DSTM ............................................................................................................................... 44 Figure 34 : TRT .................................................................................................................................. 45 Figure 35 : SIIT ................................................................................................................................... 46 Figure 36 : NAT-PT ............................................................................................................................ 47 Figure 37 : BIS .................................................................................................................................... 48 Figure 38 : Socks gateway .................................................................................................................. 49 Figure 39 : IPv6 Forum ....................................................................................................................... 52 Figure 40 : IPv6 phase-1 phase-2 scope ............................................................................................. 53 Figure 41 : LCNA scope ..................................................................................................................... 55 Figure 42 : IPNET architecture ........................................................................................................... 58 Figure 43 : uIPv6 architecture............................................................................................................. 59
5
State of the art about known IPv6 stacks and small IPv6 stacks
List of tables Table 1 : IPv4 options ......................................................................................................................... 14 Table 2: IPv6 functions ....................................................................................................................... 26 Table 3: Default Policy table for "DAS" Protocol .............................................................................. 33 Table 4: Differences between IPv4 and IPv6 ..................................................................................... 37 Table 5: LCNA classification ............................................................................................................. 54 Table 6 : Generic stacks classification ................................................................................................ 60 Table 7: Stacks for specific embedded devices .................................................................................. 61 Table 8 : Stacks for specific OS .......................................................................................................... 62
6
State of the art about known IPv6 stacks and small IPv6 stacks
1 Introduction 1.1 Purpose This document presents a comparative analysis of existing IPv6 stacks and IPv6 small stacks. Indeed, in the future most of existing networks will use Internet Protocol version 6 instead of version 4 which has deployed everywhere nowadays. This is the reason why a study about IPv6 must be done in order to allow next generation aircraft network to communicate with ground station using IPv6 if required. This document is divided in four parts which are: •
Presentation of the Internet Protocol: This part introduces IPV4 and its limitations and the main evolutions within IPv6.
•
Implementation of IPv6 protocol: It describes current solutions used by the most of existing operating systems to integrate IPv6.
•
Comparative study of existing IPv6 stacks: This is the key point of this report. An IPv6 stacks is an implementation of this protocol in compliance with standard RFCs.
•
Study of IPv6 solution integration in ADCN+ network: This part consists in analyzing various existing stacks in order to choose the best solution which will satisfy ADCN+ new needs in IPv6 technology.
At the end of this report, one or more IPv6 stacks are proposed as possible solutions to be integrated into ADCN+ architecture.
1.2 Study’s context In the future IPv4 will disappear and all networks must be compatible with the Internet protocol next generation called IPv6. Indeed, IPv4 is a 28 year old protocol and it has many limitations which are not adapted to the new network generation which interconnects several types of devices (From sensor, small devices like mobile phones to the big servers). Thus we can note that these equipments do not have the same constraints and each one implements adapted protocol stack following its own environment constraints. This is the reason why this report will focus on a comparison of existing IPv6 stacks and an analysis of which stack can be used in avionics domain (see the next sub section).
7
State of the art about known IPv6 stacks and small IPv6 stacks
1.3 Aeronautical context In the aircraft there are different network domains which need different security levels. The figure illustrates in brief aircraft network and interconnection with ground stations.
Secure Interface
Avionic world
Open world
Ethernet
Figure 1 : Aircraft Network
The aircraft network is divided into two main parts which are avionics world (with a determinist QoS) and an open world (with best effort QoS). The open world network communicates with ground station networks. In research context we wonder how open world will communicate with ground station networks which will run with Internet protocol version 6 in a few years. This is the reason why this study tries to give some response elements in which IPv6 stacks could be used in the open world network in order to communicate with airport networks.
8
State of the art about known IPv6 stacks and small IPv6 stacks
1.4 Glossary Acronym
Definition
ACD
Aircraft Control Domain
ACMS
Aircraft Condition Monitoring System
ADCN+
Enhanced Avionic Data Communication Network. “+” means Enhanced.
AISD
Aircraft Information Services Domain
ANSU
A/C Network Server Unit
AOC
Airline Operation Control
ARU
A/C Router Unit
CDAM
Central Data Acquisition Module
CIDR
Classless Inter-Domain Routing is a technique that summarizes a block of Internet addresses as an address in dotted decimal notation followed by a forward slash and a two-digit decimal number giving the number of leading one bits in the subnet mask
CPU
Central Processing Unit
DAS
Default Address Selection protocol
DHCP
Dynamic Host Configuration Protocol
DSP
Digital Signal Processing
E/S & E/S+
End system and enhanced end system
ESLC
End System Low Capacity
FAP
Flight Attendant Panel
IANA
Internet Assigned Number Authority
ICMPv6
Internet Control Message Protocol version 6
IETF
Internet Engineering Task Force
IP
Internet Protocol. IPv4 means Internet version 4 and IPv6 means Internet Protocol version 6.
LCNA
Low Cost Network Appliance
NAT-PT
Network Address Translation – Protocol Translation
ND
Neighbor discovery
OS
Operating System
OSI
Open System Interconnection
PIESD
Passenger Information and Entertainment Services Domain
PMAT
Portable Maintenance Access Terminal 9
State of the art about known IPv6 stacks and small IPv6 stacks
PMTU
Path Maximum Transfer Unit
PODD
Passenger Owned Devices Domain
RFC
Request For Comments. A document that was created to define accepted or proposed Internet standards or standards of practice. The acceptance of a document as an RFC is governed by the IETF
RIR
Regional Internet Registry
SIIT
Stateless IP/ICMP Translation
SLAAC
Stateless Address Autoconfiguration Protocol
TRT
Transport Relay Translator
1.5 Referenced documents 1.5.1 Standard Internet documents • •
• • • • • • • • • • • • • • • • • • • •
RFC 791 : INTERNET PROTOCOL version 4 specification RFC 2460 : INTERNET PROTOCOL version 6 specification RFC 4291: IPv6 addressing architecture RFC 4463 : ICMPv6 specification RFC RFC 4861 :Neighbor discovery RFC 4862 : Stateless Address Autoconfiguration RFC 4303 & RFC 4302: ESP & AH for IPSec. RFC 3484 : Default Address Selection RFC 2675 : Ipv6 jumbogram RFC-2710: MLDv1 RFC-3810 : MLDv2 RFC 3775 : MIPv6 RFC 4213 : Dual stack RFC 3053 : Tunnel broker RFC 3056 : 6to4 tunnel RFC 4214 : ISATAP tunnel RFC 3142 : TRT RFC 2765 : SIIT RFC 2766 : NAT-PT RFC 2767: BIS RFC 3089: Socks gateway RFC 4380: TEREDO
1.5.2 Web Sites • •
http://livre.point6.net (IPv6 presentation in French version) http://www.tahi.org/lcna/internet-draft/draft-okabe-ipv6-lcna-minreq-02.txt specification)
(LCNA 10
State of the art about known IPv6 stacks and small IPv6 stacks
•
http://www.ipv6ready.org/ (certified IPv6 implementations list)
1.5.3 Internal documents • • •
PROPOSITION OF ADMINISTRATION AND IP ADDRESSING STRATEGY ON THE A30X NETWORK , issue 1.0 (November 2008) A30X Information System – Status 11 (December 2008) ADCN+ WP2 – Future Aircraft Communication Report
11
State of the art about known IPv6 stacks and small IPv6 stacks
2 Presentation of the Internet Protocol The Internet protocol was standardized in 1981 which specification is defined by the RFC 791. This chapter can be considered as the theoretical part which will enable to understand this protocol and the main evolutions brought by IPv6. This is an important requirement for apprehending the IPv6 implementation features.
2.1 Internet Protocol version 4 This is a brief presentation of IPv4 which the most used network layer protocol and deployed everywhere around the world. 2.1.1 Overview The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. It provides for transmitting blocks of data called datagram from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The internet protocol also provides for fragmentation and reassembly of long datagram, if necessary, for transmission through "small packet" networks. The internet protocol is specifically limited in scope to provide the functions necessary to deliver datagram from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service. The figure below illustrates the IPv4 header format as defined in the RFC.
Figure 2 : IPv4 header format
12
State of the art about known IPv6 stacks and small IPv6 stacks
Let’s see the meaning of each field: • Version (4 bits): The Version field indicates the format of the internet header. It shall be put to 4 for this version. • IHL (4 bits): Internet Header Length is the length of the internet header. • Type of Service (8 bits): It provides an indication of the abstract parameters of the quality of service desired • Total Length (16 bits): This is the length of the datagram, measured in octets, including internet header and data. • Identification (16 bits): An identifying value assigned by the sender to aid in assembling the fragments of a datagram. • Flags (3 bits): Control Flags (don’t fragment bit or more fragment bit). This means to precise receiver if current packet is a fragment or not. • Fragment Offset (13 bits): This field indicates where in the datagram this fragment belongs. • Time to Live (8 bits): This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed • Protocol (8 bits): This field indicates the next level protocol used in the data portion of the internet datagram. • Header Checksum(16 bits): To check validity of the IP header • Source Address (32 bits): To identify the issuer. • Destination Address (32 bits): To identify the issuer. • Options variable (0 to 40 bytes): The options may appear or not in datagram. They must be implemented by all IP modules (host and gateways).
13
State of the art about known IPv6 stacks and small IPv6 stacks
The following internet options are defined: CLASS NUMBER LENGTH DESCRIPTION 0
0
-
End of Option list. This option occupies only 1 octet; it has no length octet.
0
1
-
0
2
11
No Operation. This option occupies only 1 octet; it has no length octet Security. Used to carry Security.
0
3
variable
Loose Source Routing. Used to route the Internet datagram based on information supplied by the source.
0
9
variable
Strict Source Routing. Used to route the Internet datagram based on information supplied by the source.
0
7
variable
Record Route. Used to trace the route an Internet datagram takes.
0
8
4
2
4
variable
Stream ID. Used to carry the stream identifier. Internet Timestamp Table 1 : IPv4 options
The option classes are: 0 = control 1 = reserved for future use 2 = debugging and measurement 3 = reserved for future use
14
State of the art about known IPv6 stacks and small IPv6 stacks
2.1.2 IP over OSI Model The figure below illustrates how IP packets are processed in a communication with regard to OSI reference model. Network layer
Network layer
Application layer
Application layer
Presentation layer
Data link layer
Data link layer
Presentation layer
Session layer
Physical layer
Physical layer
Session layer
Transport layer
Transport layer
Router 2
Router 1
Network layer
Network layer
Data link layer
Data link layer
Physical layer
Network 1
Network 2
Network 3
Physical layer
Host A Host B
Figure 3 : IP over OSI model
Application running in Host A wants to communicate with another one running in host B through the communication network: 1) Application sends data. Each layer puts it own header. IP which is located in network layer puts it header which contains addressing information. 2) Each router decapsulates data until IP layer in order to analyze IP header for taking routing decision. 3) Only destination decapsulates original data until application layer for processing it.
15
State of the art about known IPv6 stacks and small IPv6 stacks
2.1.3 Limitations of IPv4 This part will focus on description of IPv4 limitation and solution and alternative used solution. 2.1.3.1 Addressing 2.1.3.1.1 Address space As described in the IPv4 header, address length is 32 bits. This implementation provides 4.3 billion possible addresses (232=4 294 967 296 addresses). At the beginning this stock was widely sufficient due to Internet was foreseen restricted community which is military and university Research. Nowadays there are more and more need of IP addresses in several domains as: • Third generation of mobile telecommunication network • Public access to the World Wide Web • Embedded network (Aircraft, trains, automobiles…) The address capacity does not answer the new needs despite the usage of the NAT (see Figure below) or the CIDR to resolve addressing problems.
Figure 4 : NAT mechanism
As shown in this figure, thanks to NAT mechanism a unique public IP address is sufficient connect many Hosts into Internet. In fact all hosts A, B, C, D will have private address (not routable into public network). When they communicate with a host located to the Internet router public IP address will be used.
16
State of the art about known IPv6 stacks and small IPv6 stacks
2.1.3.1.2 Disparity of geographic distribution This figure shows IPv4 address allocation in 2001.
Figure 5 : IPv4 addresses distribution
The half of available IPv4 Addresses was used before creation of Regional Internet Register (RIR). 4% are allocated in Europe (RIPE NCC), 2% in ASIE (APNIC), 5% in the USA (ARIN) and 36 % non allocated addresses kept by IANA authority which will distribute on demand. Among used addresses 74% is used in the USA, 17% in Europe, 9 % in ASIE whereas this last one represents 60 % of world population. 2.1.3.2 Security There is no native security mechanism in IPv4. In fact Internet is a public network, so everyone can intercept data exchanged in this network. To protect communication additional protocols such as IPSec allows secure exchange. 2.1.3.3 QoS (Quality of Service) Some applications which have time constraint require High level quality of service whereas IPv4 does not foresee to provide QoS. Additional Protocol such as DiffServ was developed to use existing field in the IP header in order to offer better QoS when it required.
17
State of the art about known IPv6 stacks and small IPv6 stacks
2.1.3.4 Mobility IP was not designed to perform mobility function. As a matter of fact, when user moves while communicating over Internet, his access router will change and his communication may be interrupted. Mobil IPv4 (MIPv4) was developed to perform this function. Moreover NEMO (NEtwork MObility) was developed in order to manage mobile Network (for instance Sensor Network in an automobile) 2.1.3.5 Multicast IPv4 is not designed to support natively Multicast function which consists on sending data to a group of equipment. IPv4 class D addresses is used to perform this function. This solution eliminates 268 millions addresses. 2.1.3.6 Lack of auto configuration function There is not native mechanism to allow a host to configure itself in the network. The last may use DHCP server to perform this function. 2.1.4 Summary Internet protocol version 4 is 28 year old protocol which was designed for military and university research context. But it was not foreseen for commercial use. To correct several gaps encountered other protocols or tools were developed, these solutions add complexity in network management. In brief the main reasons to use IPv6 are: •
Large address capacity
•
Many native functions unlike IPv4
•
Fixed header length
18
State of the art about known IPv6 stacks and small IPv6 stacks
2.2 Internet protocol version 6 This part is a description of IPv6 features which brings many evolutions with regard to IPv4 especially in large address space, autoconfiguration functions, mobility and security improvements. 2.2.1 Modification of the header format The IPv6 header is defined in RFC 2460 and has been streamlined for efficiency (Figure 6). The new format introduces the concept of an extension header, allowing greater flexibility to support optional features and thus enable a fixed header length. This point is a very interesting mean to bring QoS in ADCN+ Network, unlike with IPv4 header which has variable length and it makes difficult to localize QoS field position on a frame. Fields in the IPv6 header are: • Version (4 bits): Internet Protocol version number, value = 6. • Traffic Class (8 bit): Traffic class field, similar to type of service in IPv4. • Flow Label (20 bits): Flow label, used to identify traffic flow for additional control on quality of service. • Payload Length (16 bit): Unsigned integer, length of the IPv6 payload. • Next Header (8 bits): Selector, used to identify the type of header immediately following the IPv6 header. • Hop Limit (8 bits): Unsigned integer, decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. • Source Address (128 bits): Address of the originator of the packet. • Destination Address (128 bit): Address of the intended recipient of the packet.
Figure 6 : IPv5 header vs. IPv4 header
The extension header is optional in IPv6. If present, extension headers immediately follow the header field. IPv6 extension headers have the following properties: • They are 64-bit aligned, with much lower overhead than IPv4 options. 19
State of the art about known IPv6 stacks and small IPv6 stacks
• They have no size limit as with IPv4. The only limitation is the size of IPv6 packet. • They are processed only by destination node. The only exception is the Hop-by-Hop header option. • The Next Header field of the base IPv6 header identifies the extension header. When multiple extension headers are present in a same IPv6 packet, they occur in this order: • The Hop-by-Hop header carries information that needs to be examined by all the nodes along the delivery path. When present, the Hop-by-Hop option always follows immediately after the basic IPv6 header. • The Destination header carries additional information that can be examined only by the destination node. • The Routing header is used by the source node to list all the nodes the packet needs to traverse on the path to its destination. • The Fragmentation header is used by the source to indicate that the packet has been fragmented to fit within the maximum transmission unit (MTU size). In IPv6, unlike IP4, packet fragmentation and assembly are done by the end nodes instead of routers, which further improve the efficiency of the IPv6 network. • The Authentication and Encapsulating Security Payload headers (AH and ESP) are used in IPSec to provide security services to ensure the authentication, integrity, and confidentiality of a packet. The figure below illustrates how extensions may be encapsulated into IPv6 packet.
Figure 7 : IPv6 extensions
20
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.2 IPv6 addressing IPv6 addressing is defined in RFC 4291, it has 128-bit (16-byte) source and destination addresses. Although 128 bits can provide 2128 possible combinations (over 3.4×1038 addresses), the large address space of IPv6 has been designed to allow for multiple levels of subnetting and address allocation from the Internet backbone to the individual subnets within an organization. Although only a small percentage of possible addresses are currently allocated for use by hosts, there are plenty of addresses available for future use. With a much larger number of available addresses, address-conservation techniques, such as the deployment of NATs, are no longer necessary. The 128-bit IPv6 address is separated into eight 16-bit hexadecimal numbers divided by colons (: ). The preferred format is xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, for example: 2031:0000:1F1F:0000:0000:0100:11A0:ADDF. The following conventions are also used to represent IPv6 addresses, including ways to shorten them and make them easier to represent: • Leading zeros can be removed (0000 = 0 compressed form). • :: represents one or more groups of 16 bits zeros, and 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 addresses. For example, an IPv4-compatible IPv6 address is 0:0:0:0:0:0.192.168.0.1. Unlike an IPv4 node, an IPv6 node allows more than one type of IP address: unicast, anycast, and multicast. The following sub section describes the three address types (unicast, anycast, and multicast), we can note here that broadcast which exists in IPv4 has been replaced by multicast addresses. 2.2.2.1 Unicast address (One to one) Unicast is an address used to identify a single interface. A packet destined for a unicast address is delivered to the interface identified by that address. Based on the reachability of the packets, unicast supports the following address types: • Global unicast • Site-local unicast • Link local unicast 2.2.2.1.1 Global unicast Global unicast address is an address that can be reached and identified globally. A global unicast address consists of a global routing prefix, a subnet ID, and an interface ID (Figure 8). The current global unicast address allocation uses the range of addresses that start with binary value 001 (2000::/3), one-eighth of the total IPv6 address space. 21
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 8 : Global unicast address
2.2.2.1.2 Site-local unicast address Site-local unicast address can only be reached and identified within a customer site, similar to IPv4 private address 10.0.0.0/8 and 192.168.0.0/16. The site-local unicast address contains a FEC0::/10 prefix, subnet ID, and interface ID (Figure 9).
Figure 9 : Site-local unicast format
This address was deprecated by unique local IPv6 address defined by the RFC 4913. 2.2.2.1.3 Link-local unicast address Link-local unicast address is an address that can only be reached and identified by nodes attached to the same local link. A link-local unicast address uses a FE80::/ 10 prefix and an interface ID (Figure 10).
Figure 10 : Link-local unicast address format
22
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.2.2 Anycast address (one to nearest) The anycast address is an address that is assigned to a set of interfaces belonging to different nodes. A packet destined to an anycast address is routed to the nearest interface according to the routing protocols' measure of distance. The anycast address has the following restrictions: • An anycast address must not be used as source address of IPv6 packet. • An anycast address must not be assigned to an IPv6 host. It may be assigned to an IPv6 router. This figure illustrates anycast address format:
Figure 11 : Anycast address format
Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses. As illustrate in the figure below anycast address is used for load balancing in order to ensure high availability.
Figure 12: Anycast illustration
In this case host in network A wants to use service X presents in network B and D. If this service is available in Network B router R1 will use it else Service in network D will be used. 23
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.2.3 Multicast address (one to several) As in IPv4, a multicast address is assigned to a set of interfaces belonging to different nodes. A packet destined to a multicast address is routed to all interfaces identified by that address. The IPv6 multicast address uses the FF00::/8 prefix, 1/256 of the total IPv6 address space (Figure 13).
Figure 13: Multicast address format
2.2.2.4 Specifics addresses 2.2.2.4.1 Unspecified address The address 0:0:0:0:0:0:0:0 (can be noted ::/128 ) is called the unspecified address. It must never be assigned to any node. It indicates the absence of an address. 2.2.2.4.2 Loopback address The unicast address 0:0:0:0:0:0:0:1 (can be noted ::1/128) is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It may never be assigned to any physical interface. 2.2.2.4.3 Multicast reserved addresses There are some Multicast addresses which are reserved and shall never be assigned to any group. All Nodes Addresses:
FF01:0:0:0:0:0:0:1 (=FF01::1) FF02:0:0:0:0:0:0:1 (=FF02::1)
The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interfacelocal) or 2 (link-local). All Routers Addresses:
FF01:0:0:0:0:0:0:2 (=FF01::2) 24
State of the art about known IPv6 stacks and small IPv6 stacks
FF02:0:0:0:0:0:0:2 (=FF02::2) FF05:0:0:0:0:0:0:2 (=FF05::2) The above multicast addresses identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local). Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX Solicited-node multicast addresses are computed as a function of a node's unicast and anycast addresses. A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range: FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02:0:0:0:0:1:FF0E:8C6C(=FF02::1:FF0E:8C6C). 2.2.3 IPv6 Operation RFC 4294 defines Ipv6 nodes and routers requirements which can be classified into three main categories (Functions which must be supported, Functions which should be supported or Function which may be supported). The table below summarizes specified functions; their descriptions will be done on next sub section: Functions
MUST, SHOULD or MAY
Comments
Ipv6 specification (RFC 2460)
MUST
Defined in section 2.2.1
Ipv6 addressing architecture (RFC 4291)
MUST
Defined in section 2.2.2
ICMPv6 (RFC 4463)
MUST
ESP (RFC 4303) and AH (RFC 4302)
MUST
SLAAC (RFC 4862)
MUST
Default address selection (RFC 3484 )
MUST
Neighbor discovery (RFC 4861)
SHOULD
IP Forwarding Table MIB (RFC 4292)
SHOULD
IP MIB (RFC 4293)
SHOULD
Privacy extension for SLAAC (RFC3041)
SHOULD
Path MTU discovery (RFC 1981)
SHOULD
Multicast: MLDv2 (RFC 3810) and MLDv1
Security
Defined in section 2.2.3.2
Should if required 25
State of the art about known IPv6 stacks and small IPv6 stacks
(RFC 2710) DNS
Should if required
Mobility
Should if required
IPv6 Router Alert Option (RFC 2711)
Should if required
DHCPv6 (RFC 3315)
MAY
Network Management
MAY
Ipv4
MAY
Ipv6 Jumbograms (RFC 2675)
MAY
Router only
Table 2: IPv6 functions
The figure below illustrates IPv6 node requirements.
Figure 14: IPv6 node requirement
2.2.3.1 ICMPv6 As defined in RFC 4463, ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of IPv6 and MUST be fully implemented by every IPv6 node. ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified as such by having a zero in the high-order bit of their message Type field 26
State of the art about known IPv6 stacks and small IPv6 stacks
values. Thus, errors messages have message Types from 0 to 127. Informational messages have message Types from 128 to 255. The ICMPv6 messages have the following general format:
Figure 15:ICMPv6 message format
2.2.3.2 Neighbor discovery (ND) The neighbor discovery protocol enables IPv6 nodes and routers to determine the link-layer (level 2 OSI model) address of a neighbor on the same network, and to find and track neighbors. The IPv6 neighbor discovery process uses IPv6 ICMP (ICMPv6) messages and solicited-node multicast addresses to determine the link-layer address of a neighbor on the same network, verify the reachability of a neighbor, and keep track of neighbor routers. The only problem is that ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., NBMA links) alternative protocols or mechanisms to implement those services will be specified
The following functions are defined in ND’s specification:
Router Solicitation (RS): When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements (described in the next message type) immediately rather than at their next scheduled time.
Figure 16: Router solicitation message format
•
Reserved field must be initialized to zero by the sender and must be ignored by the receiver.
Router Advertisement (RA): Routers advertise their presence together with various link and Internet parameters either periodically or in response to a Router Solicitation message.
27
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 17: Router advertisement message format
•
The Hop limit value a node should place in the IPv6 header.
•
M: 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration
•
O: 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information.
•
The lifetime information of the included network prefix. A Lifetime of 0 indicates that the router is not a default router and should not appear on the default router list
•
Reachable time: The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm.
•
Retransmission Timer: The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (NUD)
•
The maximum transmission unit (MTU) size a node should use in sending packets.
•
The network prefix a node should use to form the unicast address.
•
Whether the originating router should be used as default router.
Neighbor Solicitation (NS): It is
sent by a node to determine the link layer address of a neighbor or to verify that a neighbor is
still reachable via a cached link layer address. Neighbor Solicitations are also used for Duplicate Address Detection. 28
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 18:Neighbor solicitation message format
Neighbor Advertisement (NA): This is a response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a link layer address change.
Figure 19: Neighbor advertisement message format
•
R is a Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host.
•
S is a Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It must not be set in multicast advertisements or in unsolicited unicast advertisements.
•
O is Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address.
Redirect: Used by routers to inform hosts of a better first hop for a destination. These functions define mechanisms for solving each of the following problems:
29
State of the art about known IPv6 stacks and small IPv6 stacks
Router Discovery: How hosts locate routers that reside on an attached link.
Prefix Discovery: How hosts discover the set of address prefixes that define which destinations are on-link for an attached link. (Nodes use prefixes to distinguish destinations that reside on-link from those only reachable through a router.) The figure below illustrates two cases for discovering network prefix. The first case Host A arrives in the network and has not network prefix information. Host A sends Router solicitation (RS) to all routers (destination address: FF02::2).Router answers by sending Router advertisement (RA) containing prefix information to host A.
Figure 21: prefix discovery 2 Figure 20: Prefix discovery 1
The second case Router advertisements messages are sent out periodically on each configured interface of an IPv6 router.
Parameter Discovery: How a node learns such link parameters as the link MTU or such Internet parameters as the hop limit value to place in outgoing packets.
Address Autoconfiguration: How nodes automatically configure an address for an interface.
Address resolution: 30
State of the art about known IPv6 stacks and small IPv6 stacks
How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address.
The figure below illustrates how Host A process to obtain Host D Mac address. 1) Host A sends Neighbor Solicitation (NS) using host D solicited node address. 2) Host D answers by sending Neighbor Advertisement containing it own Mac address.
Figure 22: Address resolution
Next-hop determination: The algorithm for mapping an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next-hop can be a router or the destination itself.
Neighbor Unreachability Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried.
For both routers and hosts, address resolution can be
performed again.
Duplicate Address Detection: How a node determines that an address it wishes to use is not already in use by another node. 2.2.3.3 Stateless auto configuration and renumbering of IPv6 nodes Stateless auto configuration enables serverless basic configuration of IPv6 nodes and easy renumbering. The following is a summary of the steps a device takes when using stateless autoconfiguration: 1) Link-Local Address Generation: The device generates a link-local address 31
State of the art about known IPv6 stacks and small IPv6 stacks
2) Link-Local Address Uniqueness Test: The node tests to ensure that the address it generated isn't for some reason already in use on the local network. It sends a Neighbor Solicitation message. Then, it listens for a Neighbor Advertisement in response that indicates that another device is already using its link-local address; if so, either a new address must be generated, or autoconfiguration fails and another method must be employed. 3) Link-Local Address Assignment: Assuming the uniqueness test passed, the device assigns the link-local address to its IP interface. This address can be used for communication on the local network, but not on the wider Internet (since link-local addresses are not routed). 4) Router Contact: The node next attempts to contact a local router for more information on continuing the configuration. This is done either by listening for Router Advertisement messages sent periodically by routers, or by sending a specific Router Solicitation to ask a router for information on what to do next 5) Router Direction: The router provides direction to the node on how to proceed with the autoconfiguration. It may tell the node that on this network “stateful” autoconfiguration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell the host how to determine its global Internet address. 6) Global Address Configuration: Assuming that stateless autoconfiguration is in use on the network, the host will configure itself with its globally-unique Internet address. This address is generally formed from a network prefix provided to the host by the router, combined with the
device's
identifier
as
generated
in
the
first
step.
Renumbering of IPv6 nodes is possible through router advertisement messages, which contain both the old and new prefix. A decrease in the lifetime value of the old prefix alerts the nodes to use the new prefix, while still keeping their current connections intact with the old prefix. During this period, nodes have two unicast addresses in use. When the old prefix is no longer usable, the router advertisements will include only the new prefix. 2.2.3.4 Security Optional in IPv4, IPSec is a mandatory part of the IPv6 protocol suite. IPv6 provides security extension headers, making it easier to implement encryption, authentication, and virtual private networks (VPNs). By providing globally unique addresses and embedded security, IPv6 can provide end-to-end security services such as access control, confidentiality, and data integrity with less impact on network performance.
32
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.3.5 Default address selection (DAS) for IPv6 All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in RFC 3484. In fact The IPv6 addressing architecture allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated". Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses". The mobility architecture introduces "home addresses" and "care-of addresses". In addition, multi-homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default.
To choose source address and destination address Ipv6 implementation applies appropriate algorithm through configuration table. DAS speciation define default policy table as define below. Prefix ::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96
Precedence
Label 50 40 30 20 10
0 1 2 3 4
Table 3: Default Policy table for "DAS" Protocol
Let see how host take decision. These algorithms are taken from RFC 3484. 2.2.3.5.1 Source address selection These rules are defined to choose source address •
Rule 1: Prefer same address.
•
Rule 2: Prefer appropriate scope.
•
Rule 3: Avoid deprecated addresses.
•
Rule 4: Prefer home addresses.
•
Rule 5: Prefer outgoing interface.
•
Rule 6: Prefer matching label. .
33
State of the art about known IPv6 stacks and small IPv6 stacks
•
Rule 7: Prefer public addresses.
•
Rule 8: Use longest matching prefix.
2.2.3.5.2 Destination address selection When equipment wants to communicate, this laster sends DNS request which may return more than one addresses. Thus these rules are defined to choose better address to be used: •
Rule 1: Avoid unusable destinations.
•
Rule 2: Prefer matching scope.
•
Rule 3: Avoid deprecated addresses.
•
Rule 4: Prefer home addresses.
•
Rule 5: Prefer matching label.
•
Rule 6: Prefer higher precedence.
•
Rule 7: Prefer native transport.
•
Rule 8: Prefer smaller scope.
•
Rule 9: Use longest matching prefix.
•
Rule 10: Otherwise, leave the order unchanged.
34
State of the art about known IPv6 stacks and small IPv6 stacks
2.2.3.6 Path Maximum Transfer Unit (PMTU) IPv6 routers do not handle fragmentation of packets, which is done, when necessary, by the originating or source node of the packet. IPv6 uses ICMP error reports to determine whether the packet size matches the MTU size along the delivery path. When a node reports packet too big via an ICMP error report, the source node will reduce the size of the transmit packet. The process is repeated until there is no packet too big error along the delivery path. This allows a node to dynamically discover and adjust to differences in the MTU size of every link along a given data path. Minimal implementations may choose to not support PMTU and avoid large packets. 2.2.3.7 DHCPv6 and Domain Name Server (DNS) In addition to stateless auto configuration, IPv6 also supports stateful configuration with DHCPv6. The IPv6 node has an option to solicit an address via DHCP server when a router is not found. The operation of DHCPv6 is mostly similar to that of DHCPv4; however, DHCPv6 uses multicast for many of its messages. IPv6 also introduces a new record type to accommodate IPv6 addresses in Domain Name Servers. The AAAA record, also known as quad A, has been recommended by the IETF for mapping a host name to an IPv6 address. 2.2.3.8 Ipv6 jumbogram A jumbogram is defined in RFC 2675 as an IPv6 packet containing a payload longer than 65 535 octets. The payload length field of IPv4 and IPv6 has a size of 16 bits (capable of encoding 216 different unsigned integers, from 0 up to 216 − 1 = 65 535); hence, IP packets are limited to a maximum size of up to one byte less than 64 KB. An optional feature of IPv6, the jumbo payload option, allows the exchange of packets of up to one byte less than 4 GB (i.e., 232 − 1 = 4 294 967 295 bytes), by making use of a 32-bit length field. Packets with such long payloads are called jumbograms. 2.2.3.9 Multicast Listener Discovery (MLD) MLD for Multicast Listener Discovery allows group management in IPv6. Nodes that need to join multicast groups should implement MLDv2 (RFC-3810). However, if the node has applications that only need support for Any-Source Multicast (RFC-3569), the node MAY implement MLDv1 (RFC-2710 ) instead. If the node has applications that need support for Source-Specific Multicast
35
State of the art about known IPv6 stacks and small IPv6 stacks
(RFC-3569), the node must support MLDv2. When MLD is used, the rules in the "Source Address Selection for the MLD Protocol" (RFC-3590) must be followed. 2.2.3.10 Mobile IPv6 Mobile IP, defined in an IETF standard (RFC 3775), allows mobile devices to move around without breaking their existing connections an increasingly important network feature. Unlike IPv4, IPv6 mobility uses built-in auto configuration to obtain the Care-Of-Address (temporary IP address for a mobile device), eliminating the need for a Foreign Agent. In addition, the binding process allows the Correspondent Node to communicate directly with the Mobile Node, avoiding the overhead of triangular routing required in IPv4. The result is a much more efficient Mobile IP architecture in IPv6. Here is how it works.
Figure 23: MIPv6
1. The Mobile Node (MN) travels to a foreign network and gets a new care-of-address. 2. The MN performs a binding update to its Home Agent (HA) (the new care-of-address gets registered at HA). HA sends a binding acknowledgement to MN. 3. A Correspondent Node (CN) wants to contact the MN. The HA intercepts packets destined to the MN. 4. Then the HA tunnels all packets to the MN from the CN using MN's care-of-address.
36
State of the art about known IPv6 stacks and small IPv6 stacks
5. When the MN answers the CN, it may use its current care-of-address (and perform a binding to the CN) and communicate with the CN directly (optimized routing) or it can tunnel all its packets through the HA.
2.3 Summary The following table summarizes the main differences between IPv4 and IPv6. IP v4
IPv6
Source and destination addresses are 32 bits (4 bytes) in length. IPSec support is optional. IPv4 header does not identify packet flow for QoS handling by routers.
Source and destination addresses are 128 bits (16 bytes) in length. IPSec support is required. IPv6 header contains Flow Label field, which identifies packet flow for QoS handling by router. Both routers and the sending host fragment Only the sending host fragments packets; routers packets. do not. Header includes a checksum. Header does not include a checksum. IP header must be checked into upper layer (TCP,UDP) Address Resolution Protocol (ARP) uses Multicast Neighbor Solicitation messages resolve broadcast ARP Request frames to resolve an IP addresses to link-layer addresses. IP address to a link-layer address Internet Group Management Protocol Multicast Listener Discovery (MLD) messages (IGMP) manages membership in local subnet manage membership in local subnet groups. groups. ICMP Router Discovery is used to determine ICMPv6 Router Solicitation and Router the IPv4 address of the best default gateway, Advertisement messages are used to determine and it is optional. the IP address of the best default gateway, and they are required. Broadcast addresses are used to send traffic IPv6 uses a link-local scope all-nodes multicast to all nodes on a subnet. address Must be configured either manually or Does not require manual configuration or DHCP through DHCP. Uses host address (A) resource records in Uses host address (AAAA) resource records in Domain Name System (DNS) to map host DNS to map host names to IPv6 addresses. names to IPv4 addresses. Must support a 576-byte packet size Must support a 1280-byte packet size (without (possibly fragmented). fragmentation). Table 4: Differences between IPv4 and IPv6
37
State of the art about known IPv6 stacks and small IPv6 stacks
3 Implementation of IPv6 protocol IPv6 provides many benefits over legacy IPv4 technology; however, all agree that any successful strategy for IPv6 deployment requires it to coexist with IPv4 for some extended period of time. A number of strategies have been developed for managing this complex and prolonged transition from IPv4 to IPv6. The following subsections describe several of these strategies. In second part of this chapter (3.2) conformance authority which ensure implementation conformance will be introduced.
3.1 Interoperability (IPv4/IPv6) To ensure cohabitation between IPv4 and IPv6 solutions was developed for the two main cases: • Communication between IPv6 and IPv6 through IPv4 backbones • Communication between IPv4 and IPv6 hosts 3.1.1 Communication between IPv6 and IPv6 hosts or IPv4 and IPv4 hosts This solution is based on dual stack approach or tunneling. The main differences between tunneling mechanism are tunneling approach, which could be manual (requires human intervention for configuring tunnel endpoints) or automatic (no human intervention for tunnel configuration). Among automatic tunnels, some are adapted for communication in site local or campus network and other for communication over the Internet. 3.1.1.1 Dual stack approach Dual stack is defined in RFC 4213. It is an integration method where a node has connectivity to both an IPv4 and IPv6 network; thus the node has two protocol stacks, as illustrated in figure 23.
Figure 24: Dual stack approach
38
State of the art about known IPv6 stacks and small IPv6 stacks
In this example Host A can communicate with Host D using IPv4 stack, it will also be able to communicate with Host C using IPv6 stack or with Host B which can uses IPv6 or IPv4 stack. But Host C will not be able to communicate with Host D. This method implies that all dual stack nodes have an IPv4 and IPv6 address. 3.1.1.2 Tunneling approach IPv6 tunneling is the process of encapsulating an IPv6 packet inside an IPv4 packet and forwarding it across the IPv4 Internet, where it is then decapsulated and forwarded on to its IPv6 destination (Figure 24). Tunneling can also work in reverse to move IPv4 packets across an IPv6 Internet, with an edge gateway encapsulating IPv4 packets inside IPv6 packets and forwarding them across the IPv6 infrastructure.
IPv4 Tunnel
IPv6 Packets
IPv4 Encapsulation
IPv6 Packets
IPv6 Packets
Figure 25: Tunneling approach
Two types of tunneling are defined by IETF which are static or automatic 3.1.1.2.1 Static tunneling •
6over4 static tunnel Consider the scenario shown in Figure 25, with two isolated v6 end nodes, two dual-stack
routers, a v4 infrastructure, and a tunnel. End nodes A and B, both IPv6 nodes, are separated by an IPv4-only network. For A and B to exchange IPv6 packets, they would require a 6over4 static tunnel between the dual-stack routers located at either end of the IPv4 network. Node A could then send IPv6 packets destined for node B to the local dual-stack router X, which encapsulates A’s IPv6 packets into IPv4 packets. These packets can then be routed across the IPv4 network to router Y, which strips off the IPv4 headers to restore the original IPv6 packets and forward them to their original IPv6 destination (Node B).
39
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 26: Static tunnel
Static tunnel requires that the dual-stack routers be able of encapsulating and decapsulating IPv6 packets in IPv4 packets. It also requires human intervention to record and configure tunnel Endpoints (X and Y). •
Tunnel broker Tunnel broker is defined in RFC 3053; it is another semi automatic alternative solution
which consists on looking for tunnel configuration in dedicated server which can be kept by third party.
Figure 27: Tunnel broker tunneling
Let see scenario when node A wants to communicate with node B. A sends packet to the local dual stack router X 1) X sends IPv4 request to the tunnels broker 2) Tunnel broker creates tunnel request to Y. 3) Tunnel broker sends tunnel configuration to X 4) X creates tunnel and send packet to Y which will forward it to node B.
40
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.1.2.2 Automatic tunneling There are two main methods for deploying automatic tunnel. •
6to4
tunnel
As defined by RFC 3056, 6to4 tunneling uses an IPv4 address embedded in the IPv6 address to identify the end point of the tunnel and setup tunnel automatically (Figure 27).
Figure 28 : 6to4 address format
This figure below describes scenario when two 6to4 networks communicate.
Figure 29 : 6to4 network to 6to4 network
The two edge routers (X and Y) have public IPv4 addresses. 6to4 mechanism will construct IPv6 address automatically thanks IPv4 address. When Node A wants to communicate with node C router X will detect 2002 prefix and deduce that there is an IPv4 address inside. Then router X will construct IPv4 packet with embedded IPv4 address and send it to router Y which will decapsulate IPv6 packet and send it to node C. The power of the mechanism is the ability to automatically allocate a unique IPv6 address from a unique IPv4 address. The real power, though, is that, since the IPv6 address space is 128 bits where the IPv4 address space is 32 bits, an entire unique IPv6 network can be generated from a single unique IPv4 address. The next figure illustrates how 6to4 network could communicate with a native IPv6 network. In this case new equipment called 6to4 relay is required to interconnect native IPv6 network to a 6to4 network. 41
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 30 : 6to4 Network to native IPv6
•
ISATAP (Intra Site Automatic Tunnel Addressing Protocol) As defined by RFC 4214, ISATAP tunneling is very similar to 6to4 tunneling, but is
designed for use in a local site or campus network. The ISATAP address contains the 64-bit network prefix, 0000:5EFE, and an IPv4 address identifying the address of the tunnel end point (Figure 30).
Figure 31: ISATAP address format
The figure below illustrates how an IPv4 address host can communicate with native Ipv6 host.
Figure 32: ISATAP
42
State of the art about known IPv6 stacks and small IPv6 stacks
The ISATAP host uses the services of an “ISATAP router” typically a router that has a native v6-interface and a v4-only interface designated as the ISATAP interface. The network administrator assigns an “ISATAP prefix” to the router (in our case 3ffe:80f0:4:300::/64). The IPv4 address of the router is also added to the enterprise DNS under the well-known name “ISATAP.” The ISATAP router will then forward v6-packets onto the native v6 network from ISATAP hosts using the router as its ISATAP tunnel-endpoint. Here’s how it works, host C asks the DNS for the address of “ISATAP.” The DNS replies with the v4-address of ISATAP router. Next, Host C tunnels a router discovery packet (IPv6-in-IPv4 as described in figure 30) to ISATAP router, and ISATAP router responds with a router advertisement (including the network prefix for Host C to use—3ffe:80f0:4:300::/64). Upon receipt of
the
prefix,
Host
C
constructs
its
globally
unique
IPv6
address,
3ffe:80f0:4:300:0:5efe:172.16.12.30 (the “0:5efe” in the address is a reserved value that specifies an ISATAP address). At this point, Host C has obtained full IPv6 capability via the services provided by the ISATAP router.
43
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.2 Communication between IPv4 and IPv6 hosts This section describes method which enables IPv4 hosts to communicate with IPv6 hosts. These approaches are based on translation protocol mechanism. The main differences in this approach are the layer where translations are done (Network layer, transport layer or application layer) and the address format used for encapsulating IP packet. 3.1.2.1 DSTM (Dual Stack Transition Mechanism) The DSTM translation mechanism is for dual-stack hosts in an IPv6 domain that have not yet had an IPv4 address assigned to the IPv4 side, but need to communicate with IPv4 systems or allow IPv4 applications to run on top of their IPv6 protocol stack. The mechanism requires a dedicated server that dynamically provides a temporary global IPv4 address for the duration of the communication (using DHCPv6), and uses dynamic tunnels to carry the IPv4 traffic within an IPv6 packet through the IPv6 domain.
Figure 33 : DSTM
How host A can communicate with Host B? 1) Host A sends request to DSTM server for obtaining temporary Ipv4 address. DSTM server sends temporary IPv4 address to host A which use it to configure it IPv4 stack 2) Host encapsulate IPv4 packet into IPv6 and send it into DSTM server 3) DSTM gateway decapsulates IPv4 packet and sends it to destination B. This mechanism is not a standard version but an internet draft version.
44
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.2.2 TRT RFC 3142 defines TRT (Transport Relay Translator) method. It enables IPv6-only hosts to exchange {TCP, UDP} traffic with IPv4-only hosts. A TRT system, which locates in the middle, translates {TCP, UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
Figure 34 : TRT
Host A wants to communicate with node B. 1) A encapsulates IPv4 Address into IPv6 using this following IPv6 address format FEC0::1:10.10.0.2 = FEC0::1:0a0a:0002 2) TRT router will extract IPv4 address and establishs connection with host B TRT mechanism work at Transport Level in OSI model, TRT routers establishes two TCP or UDP connections between Host A and Host B.
45
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.2.3 SIIT RFC 2765 defines SIIT (Stateless IP/ICMP Translation). The figure below illustrates how it works.
Figure 35 : SIIT
Let consider the case where host A (IPv6 node) wants to communicate with host B (IPv4 node): 1) A encapsulates IPv4 Address into IPv6 packet using IPv4 Compatible address (0:: 0:10.10.0.2=::0a0a:0002) or IPv4 translated address (0::ffff:10.10.0.2=0::ffff:0a0a:0002) 2) SIIT extracts IPv4 address and sends packet to host B SIIT router interprets an IPv6 header and creates a parallel IPv4 header with equivalent information and the inverse equivalent operation of converting an IPv4 header into an IPv6 header. It works at Network level in OSI reference model.
46
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.2.4 NAT-PT NAT-PT (Network Address Translation – Protocol Translation) is defined in RFC 2766 which is deprecated by RFC 4966.
Figure 36 : NAT-PT
1) A encapsulates IPv4 Address into IPv6 packet using the following format: network prefix::IPv4 address = 3ffe:80f0:4::10.10.0.2 2) NAT-PT will extract IPv4 address and construct IPv4 packet to send to host B. As in SIIT mechanism NAT-PT router interprets an IPv6 header and creates a parallel IPv4 header with equivalent information and the inverse equivalent operation of converting an IPv4 header into an IPv6 header. It works at Network level in OSI reference model. 3.1.2.5 BIS RFC 2767 proposes a mechanism of dual stack hosts using a technique called BIS (Bump-Inthe-Stack). The technique consists of snooping data flowing between a TCP/IPv4 module and network card driver modules. IPv4 traffic is translated into IPv6 and vice versa. The figure bellow illustrates the structure of a host which uses BIS method:
47
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 37 : BIS
Extension Name Resolver: It returns a "proper" answer in response to the IPv4 application’s request. The application typically sends a query to a name server to resolve 'A' records for the target host name. It snoops the query, creates another query to resolve both 'A' and 'AAAA' records for the host name, and sends the query to the server Address mapper: It maintains an IPv4 address spool. The spool, for example, consists of private addresses. Also, it maintains a table which consists of pairs of an IPv4 address and an IPv6 address. When the resolver or the translator requests it to assign an IPv4 address corresponding to an IPv6 address, it selects and returns an IPv4 address out of the spool, and registers a new entry into the table dynamically. Translator: It translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in SIIT section. The mechanism is valid only for unicast communication, but invalid for multicast communication. Multicast communication needs another mechanism. It allows hosts to communicate with IPv6 hosts using existing IPv4 applications, but this cannot be applied to IPv4 applications which use any IPv4 option since it is impossible to translate IPv4 options into IPv6. Similarly it is impossible to translate any IPv6 option headers into IPv4, except for fragment headers and routing headers. So IPv6 inbound communication having the option headers may be rejected.
48
State of the art about known IPv6 stacks and small IPv6 stacks
3.1.2.6 Socks gateway As defined by RFC 3089, the SOCKS-based IPv6/IPv4 gateway mechanism is based on a mechanism that relays two "terminated" IPv4 and IPv6 connections at the "application layer" (the SOCKS server); its characteristics are inherited from those of the connection relay mechanism at the application layer and those of the native SOCKS mechanism. The figure bellow illustrates socks architecture:
Figure 38 : Socks gateway
Here is how it works: • Client application initiates a connection to an external node using a name (FQDN) • Client socks library intercepts name resolution request and initiates an authentificated TCP connection to SOCKS server (port 1080) • SOCKS server returns to clients a “fake Ipv4 address” • SOCKS server initiates a connection with the remote node and works as a relay between client and remote node. Besides it makes the Ipv6 Ipv4 transition based on SIIT. 3.1.2.7 TEREDO As defined by RFC 4380, Teredo provides address assignment and host-to-host automatic tunneling for unicast IPv6 connectivity when IPv6/IPv4 hosts are located behind one or multiple 49
State of the art about known IPv6 stacks and small IPv6 stacks
IPv4 NATs. To traverse IPv4 NATs, IPv6 packets are sent as IPv4-based User Datagram Protocol (UDP) messages using port 3544. 3.1.3 Summary of cohabitation mechanisms This table summarizes main differences between IPv4/IPv6 cohabitation methods Tunneling approach (Communication between IPv6 host and IPv6 host through IPv4 backbone) Name
Main features
Dual stack
Allows communications between IPv4 host and All dual stack hosts need at least IPv6 host.
constraints
two IP addresses (IPv4 and IPv6).
6over4 static tunnel
Allows communications between IPv6 host and Requires human intervention for IPv6 host through IPv4 backbone.
Tunnel broker
configuring tunnel endpoints.
Allows communications between IPv6 host and Need third equipment (broker) to IPv6 host through IPv4 backbones. This configure tunnel. The lost of the mechanism also called semi automatic tunnel
6to4 tunnel
broker stop network activities.
Allows communications between IPv6 host and Foreseen to interconnect two or IPv6 host through IPv4 backbones. Tunnels several sites through Internet endpoints are configured without human scope. intervention either third equipment.
ISATAP
It is similar to 6to4, designed for use in local site or campus network. The main difference between 6to4 is the format IPv6 addresses used to encapsulate IPv4 packet Translation approach(Communication directly between IPv4 host and IPv6 host)
Name
Main features
constraints
DSTM
Dual-stack hosts (but with IPv6 address only) Not a standard at the present time. Requires presence of and obtains Temporary IPv4 address allocated DSTM server and DSTM from pool by a DSTM server. A DSTM gateway. gateway ensures protocol translation
50
State of the art about known IPv6 stacks and small IPv6 stacks
TRT (RFC 3142)
Translation between IPv6 and IPv4 on No end-to-end IPSec. Dedicated dedicated equipment (TRT gateway). TRT gateway is single point of works at transport layer. failure.
SIIT (RFC 2765)
IPv6-only hosts to IPv4-only hosts, No dual No end-to-end IPSec. stack. It works at Network layer.
NAT-PT (RFC 2766 IPv6-only hosts to IPv4-only hosts, No dual No end-to-end IPSec. and RFC 4966)
stack. It works at Network level. The difference regarding to NAT-PT is IPv6 address format used to encapsulate IPv4 packet. It works at Network layer.
BIS (RFC 2767)
IPv4-only hosts communicating with IPv6-only Valid hosts.
Socks
only
for
unicast
communication.
gateway IPv6-only hosts to IPv4-only hosts. It works at Client and gateway software in
(RFC 3089) TEREDO
Application layer.
the host and router.
(RFC IPv6-only hosts to IPv4-only hosts behind IPv4
4380)
NAT by encapsulating IPv6 packet into UDP/IPv4 packets. It works at Transport layer.
3.2 IPv6 conformance This chapter introduces IPv6 Forum which is an organism which provides IPv6 stack certification in order to ensure implementation conformance and interoperability. Then, a brief presentation of LCNA (Low Cost Network Specification) will be done in the second sub section. 3.2.1 IPv6 Forum The IPv6 Forum, a word-wide consortium, with a key focus to provide technical guidance for the deployment of IPv6, launched a single world-wide IPv6 Ready Logo Program (conformance and interoperability testing). The IPv6 Forum has created the IPv6 Logo Committee (v6LC), to manage the IPv6 Ready Logo Program. It comprises representatives from equipment vendors, service providers, academic 51
State of the art about known IPv6 stacks and small IPv6 stacks
institutions, IPv6 organizations, members from the TAHI project (JAPAN), the University of New Hampshire Interoperability Testing Lab (USA), IRISA/INRIA (France), ETSI IPv6 Plugtests (Europe), TTA (KOREA), BLL (China) and CHT-TL (Taiwan).
Figure 39 : IPv6 Forum
The IPv6 Ready Logo Committee mission is to define the test specifications for IPv6 conformance and interoperability testing, to provide access to self-test tools and to deliver the IPv6 Ready Logo. 3.2.1.1 IPv6 Ready Logo Phase Series – Phase-1, Phase-2 and Phase-3 The IPv6 Ready Logo series of tests were progressively enriched, from a minimum coverage with phase-1, to a more complete coverage with the phase 2 and later on with Phase 3. The figure below describes the scope for Phase-2 of the IPv6 Ready Logo Program.
52
State of the art about known IPv6 stacks and small IPv6 stacks
• SIP : Session Initiation Protocol • MIPv6 : Mobility IPv6 • NEMO : Network Mobility • MLD : Multicast Listening Discovery • ADDR : Addressing function • SLAAC: Stateless Address Auto Configuration • ND: Neighbor Discovery • PMTU: Path Maximum Transfer Unit Figure 40 : IPv6 phase-1 phase-2 scope
The Phase-1 Logo
focuses on “core IPv6 protocols”. Its objective is to verify
minimum IPv6 support (Addressing,ICMPv6, Neighbor Discovery and SLAAC). The test is approximately 170 tests and is available since September 2003.
The Phase-2 logo
expands the “core IPv6 protocols” test coverage to approximately
450 tests and adds new extended test categories which are: • IPSec • MIPv6 • NEMO • DHCPv6 • SIP • Management (under development) • MLD (under development) • Transition Mechanisms (under development) The IPv6 Forum encourages vendors to obtain the IPv6 Ready Logo Phase-2 (Gold logo). Indeed this logo verifies optimum compliance because of the complete series of test including the “MUST” and the recommended “SHOULD” for the IETF specifications tested, whereas the Phase-1
53
State of the art about known IPv6 stacks and small IPv6 stacks
Silver Logo tests include only the “MUST” requirements in the IETF specification and are less extensive. 3.2.2 LCNA Resource limitations and cost constraints associated with small-embedded devices make it difficult to implement the entire IPv6 specification. This is the reason why LCNA (Low cost Network Appliance) specification is defined in Draft version (see referenced documents part for the web link). This draft discuss about Host Requirements of IPv6 for LCNA. 3.2.2.1 LCNA features LCNA is destined to a non-PC embedded device such as game-machines, avionics devices, sensors, digital cameras, LCD projectors, and home appliances. The main features are: • Devices are not for general purpose, but are targeted at specific tasks. • A device that has network functionality, but has limited resources to dedicate to that. • A device that is a host, not a router. The table below is a classification of LCNA. Devices PC PDA
L C N A
Avionic equipment Sensor Home appliance
Memory >64MB 2-8MB
CPU Performance Pentium/64bits RISC/32bits (< 50MHz)
OS Windows VxWorks, Others
512KB ROM 20-64KB RAM 512KB ROM 512KB RAM 512KB ROM 16-32KB RAM
RISC/32bits (< 20MHz) 8-16bit MPU 8-16bits MPU
uiTron[ITRON] Monitor
8-16bits MPU
Monitor
PalmOS,
Table 5: LCNA classification
Note that LCAN refers to devices which has less than 1MB of memory and turns over 8-16 bits processor in the most of cases. 3.2.2.2 LCNA node requirement The figure below illustrates LCNA scope. In the LCNA specification (draft version), the requirement focuses on mandatory function. On the top of that many functions such as ICMPv6 , ND and IPSec must be profiled for LCNA IPv6 implementation.
54
State of the art about known IPv6 stacks and small IPv6 stacks
Figure 41 : LCNA scope
We can note here that LCNA specification is foreseen for an only IPv6 network, there is no transition mechanism to enable communication between IPv4 host and IPv6 host. 3.2.3 Summary The IPv6 Ready Logo Program provides conformance and interoperability test specifications based on open standards to support IPv6 deployment across the globe. Effective testing of IPv6 products is of critical importance in ensuring the deployment, interoperability, security and reliability of the IPv6 infrastructure. IPv6 ready phase-3 will be the reference because it will require IPSec which is not mandatory for IPv6 ready phase-2. LCNA is a possible solution but not standardized by IETF. So it could not interoperate with another implementation. Moreover in LCNA specifications several points such as security, multicast are waiting for further study. Nevertheless LCNA could be a long term solution in avionic context because it could be standardized in few years. It could be used for example for a full IPv6 network including AFDX domain.
55
State of the art about known IPv6 stacks and small IPv6 stacks
4 Comparative study of existing IPv6 stacks As described in introduction section and more detailed in part 5, this study aim is to identify possible IPv6 stacks for merging Ethernet World with AFDX one. So this chapter focuses on existing IPv6 Stack based on certified implementation by IPv6 forum as described in appendix A (IPv6 ready phase-1 certified products) and appendix B(IPv6 ready phase-1 certified products). Note these lists must be updated by IPv6 logo committee each time a new product has certified. The stacks are classified as: • Generic IPv6 stack for embedded devices • IPv6 stacks for Specific embedded devices • IPv6 stack for general specific OS (non embedded) • Other Stacks For each stack category there is a certification level (IPv6 ready phase-1 or IPv6 ready phase-2) as described in conformance section in this document. Some examples has taken from appendices en described in the next subsections.
4.1 IPv6 stacks for embedded system An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. 4.1.1 Generic IPv6 stacks for embedded devices The generic IPv6 stacks can be run within any real time operating systems also called RTOS (Real Time Operating System). Certain products can run without RTOS. The common features on these generic stacks are: • Modular design (All unused options may be removed) • No CPU dependencies • No OS dependencies • Developed in ANSI C language Let see the specificity for each one and functions implemented in addition to IPv6 logo program required functions.
56
State of the art about known IPv6 stacks and small IPv6 stacks
4.1.1.1 KASAGO IPv6 This is an IPv6 implementation for hosts provided by Japan Company called Elmic Wescom, INC. It is a phase-2 certified product. It requires around 150 KB minimum for the code (at IPv4/IPv6 dual mode). It main features are: • Generic Packet Tunneling (in IPv6 Specification RFC 2473) • Multicast Listener Discovery (MLDv1) for IPv6 (RFC 2710) • Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893), • IPv6 Router Alert Option • Definition of the Differentiated Services Field 4.1.1.2 NexGenIP This is an IPv6 implementation for hosts provided by French company called NexGen Software. It is a phase-2 certified product. It requires between 30 and 60 KB (code size) It implements IPv6 core (defined by IPv6 logo program) plus multicast and IPSec functions. 4.1.1.3 Treck IPv4/v6 Dual Stack This is an IPv6 implementation for hosts provided by US Company called Treck, Inc. It is a phase-2 certified product. It main features are: • Any 16, 32, or 64 bit microprocessor are supported • Can Run with or without RTOS • MIPv6, • IPSec • Generic IPv6 Tunnels • automatic and configured tunnels • multicast • Many other application layer tools 4.1.1.4 Fusion Embedded TCP/IPv4/v6 Dual-Mode Stack This is an IPv6 implementation for hosts provided by US Company called Unicoi Systems, Inc. It is a phase-2 certified. It main features are: • DSP and microprocessor support 57
State of the art about known IPv6 stacks and small IPv6 stacks
• RFC 2710 Multicast Listener Discovery (MLD) for IPv6 (host-side only) • RFC 2711 IPv6 Router Alert Option • RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers (tunneling IPv6 over IPv4) • IEEE 802.1Q (VLAN) 4.1.1.5 IPNET This is an IPv6 implementation for hosts and routers provided by Swedish company called Interpeak. It is a phase-1 certified product. This product was acquired by Wind River Company since 2006 which is RTOS developers. IPNET is used by Green Hills Company which is also a RTOS developers intended to aircraft and space domain. Wind River and Green Hills have products are phase-2 certified. The figure below illustrates IPNET architecture.
Figure 42 : IPNET architecture
This architecture was tested in several RTOS like INTEGRITY, Itron, Linux, Nucleus, OSE/OSEck and VxWorks. This implementation exists in DSP edition.
58
State of the art about known IPv6 stacks and small IPv6 stacks
4.1.1.6 Acmet IPv6 Stack by (IN) This is an implementation provided by Acmet Technologies Company, it is phase-1 certificated stacks. These main features are • Conformance with Pv6 for a host and LCNA specification • Multicast Listener Discovery • IPSec - AH and ESP • ROM - 60K and RAM - 4K (FULL Includes IPSEC) • ROM - 45K and RAM - 4k (includes IPSEC) • ROM - 20K and RAM - 3k (without IPSEC) 4.1.1.7 uIPv6 stack This is a small open-source, IPv6-ready protocol phase-1 certified stack developed by Amtel, Cisco and Swedish Institute of Computer Science (SICS). It is integrated into Contiki OS (developed by SICS) which provides all the necessary functionalities for networked smart objects. It includes standard IP applications and can be customized for specific requirements. The protocol stack features a small footprint and less memory usage. It requires 0.5kbytes of SRAM for data structures, a minimum of 1.3kbytes of SRAM for buffering, and 11kbytes of Flash for the code. The figure bellow illustrates implemented architecture.
Figure 43 : uIPv6 architecture
59
State of the art about known IPv6 stacks and small IPv6 stacks
4.1.2 Summary of generic stacks for embedded devices This table summarizes existing generic IPv6 stacks with their additional features which are not required at time by IPv6 ready Logo program conformance test (IPv6 Ready phase-1 and IPv6 Ready phase-1). Product Name
Acmet IPv6
Certification
Additional
Memory needed
Phase
functions
(source code)
1
MLD, IPSec
Stack IPNET
1
IPSec, MLD, transition mechanism
uIPv6 stack
1
N/A
Treck IPv4/v6
2
MIPv6,MLD, IPSec, Tunneling
KASAGO IPv6
2
Tunneling, IPSec, MLD, QoS
Fusion
2
tunneling, router
TCP/IPv4/v6
alert option 2
Minimum of 40 KB
Implements LCNA specification Many optional application tools
11KB N/A
Can run with or without RTOS.
150 KB in dual mode
MLD, IPSec,
Embedded
NexGenIP
From 20 to 60 KB
Notes
MLD, IPSec
N/A
N/A
Table 6 : Generic stacks classification
60
State of the art about known IPv6 stacks and small IPv6 stacks
4.1.3 IPv6 stacks for Specific embedded devices As described in second part in annex (A & B) there are many stacks which are foreseen for specific devices such as IP camera, Printer or other devices. This table is a non exhaustive list for theses stacks. A complete list is described in appendix. We can note that this list up to date each time new products satisfy conformance and interoperability test. Product Name
Certification
Notes
Phase KX-HCM230v6
1
Stack for network camera
FXNIC IPv6 Protocol Stack
1
Stack for multi function printer
HP LaserJet P2014n Printer
2
Stack for multi function printer
Windows Mobile,
2
Microsoft embedded operating system
Integrity OS
2
Green Hills operating system
Vxwork
2
Wind river operating system
Windows CE
Table 7: Stacks for specific embedded devices
The only problem is that there are proprietary stacks for specific devices and the most of them their features are not available. Nevertheless their certification phase allow us to know their minimal functions.
61
State of the art about known IPv6 stacks and small IPv6 stacks
4.2 IPv6 stack for general specific OS (for non embedded devices) This table is a non exhaustive stacks list for given non embedded operating system. (See appendix A &B for more information) Product name
Certification
Notes
Phase KAME Protocol Stack
TCP/IP 2
This is a stacks in open source developed for BSD operating system. Source code is available into Kame web site
Linux
2
Kernel.org develop IPv6 stacks acting as hosts or routers for Linux operating system
MIPL-USAGI
2
USAGI/WIDE Project
brings quality on kame IPv6
stacks z/OS
2
IBM operating system
Cisco 1800 series
2
Cisco operating system (IOS)
SAS-500 Series
2
Operating System for Amtec routers
Microsoft vista
2
Microsoft Operating system Table 8 : Stacks for specific OS
Except open source project, the others are proprietary and not evident to have information. Moreover there is no target CPU dependency information on open source project.
4.3 Other Stacks As described in appendices there are many other products not specifically stacks but special devices as router, network controller which could be software or hardware based. The only disadvantage is that there is no more information on these products.
4.4 Summary of stacks comparison analysis In this section we have seen that there are many existing ipv6 stacks. The choice of one depends on the usage. For instance if a company wants to migrate to IPv6 protocol, it could update all operating systems used on its networks and processes on IPv6 migration. For this study, it is not the case, because the aim is to integrate stacks in non existing systems. So there is no visibility on target hardware or used of operating system or not. In this case the generic stacks should be studied to decide which stacks will be in adequation with the new needs.
62
State of the art about known IPv6 stacks and small IPv6 stacks
The list below summarizes IPv6 functions which can be used in the avionic context: •
Static address configuration (Link local IP address scope will be sufficient for an intra site communication and site local IP address for inter site communication for ACD equipment). Global addresses are not necessary in ACD and AISD because there is only communications inside the aircraft and not directly with the ground or with internet.
•
DHCPv6 for non embedded devices which will be connected into open world
•
IPSec fore more security on exchange because there is no SCI gateway so no NAT.
•
Anycast could be used for High availability and load repartition.
•
Multicast could be used for group management
•
Flow Label field in the IPv6 header could be used for QoS.
5 Study of IPV6 solution integration in ADCN+ network One of the ADCN+ project’s aim is to define new ADCN architecture and functionalities for future programs. This chapter focuses on identification of IPv6 implementations which could be used in ADCN+ architecture.
5.1 ADCN+ Architecture presentation This part describes ADCN+ architecture with their subscribers in order to have an overview of the new needs. After that some solutions will be introduced as possible to answer in ADCN+ needs. 5.1.1 Objectives
This part has been deleted for confidentiality reasons 5.2 IPv6 implementation: impacted elements This part has been deleted for confidentiality reasons 5.3 Possible solutions In this part we discuss about possible implementations of IPv6 stacks among generic ones for embedded devices.
63
State of the art about known IPv6 stacks and small IPv6 stacks
5.3.1 uIPv6 stack This stack implements requirement for IPv6 node but IPSec is not implemented for very constraint memory devices. It was certified IPv6 ready pahse-1 in November 2008. uIPv6 was tested by Contiki operating system but it could run in any RTOS. The main advantage of this solution is that it is an open source, licensed under a 3-clause BSD license that allows it to be used in both closed source and open source projects. The only disadvantage is that it does not support IPSec, nor Multicast function. These points could eliminate uIPv6 choice if target environment requires security or multicast 5.3.2 Acmet IPv6 Stack This solution implements all mandatory functions for IPv6 node, it also respects LCNA specification but there is not transition mechanism foreseen. The source code was optimized and requires between 20 to 60 KB through integrated options. 5.3.3 IPNET This solution implements all mandatory function specified in RFC 4294. It is also portable because it was used in several RTOS such as Integrity or Wind River which need high security level. But the only question is that why this solution has only IPv6 ready phase-1 certification. 5.3.4 KASAGO IPv6 This solution implements also implements all mandatory functions but the memory needed for the source code (150 KB) is greater than the other stacks described here. 5.3.5 NexGenIP This solution implements all mandatory functions. There is nor OS nor CPU dependant. Ant it requires between 30 to 60 kB for the source code. 5.3.6 Treck IPv4/v6 Treck IPv4/v6 implements all IPv6 required functions specified in RFC 4294. It is used by Xilinx Company which is specialized in programmable logic solutions. According to the product description it is intended to the embedded devices but there is not specification in technical features such as memory needed for the target devices.
64
State of the art about known IPv6 stacks and small IPv6 stacks
5.3.7 Fusion Embedded TCP/IPv4/v6 This solution also implements all IPv6 required functions specified in RFC 4294. As Treck solution there is no information about target technical features. In this description it is said that this products support any processor, DSP or RTOS.
5.4 Summary of possible solutions At the present time there are not enough elements to choose one stack, this classification will enable to eliminate some solutions, it gives information for future studies. The open world uses commercial operating system which has been certified Phase-2 by IPv6 logo program so among possible solutions uIPv6 stack and IPNET could be eliminated because there is phase-1 certificated. May be in few times uIPv6 will be improved in order to implement IPSec and multicast functions since it has obtained certification in November 2008. Acmet IPv6 Stack could not be used because it implements LCNA which is intended to a full IPv6 network. The five other solutions could be used because their offer full IPv6 implementation including IPSec and multicast. At time there is no certification for some additional functions such as multicast. Soon by the arrival of IPv6 ready phase-3, may be the best solution might be selected among the five ones.
65
State of the art about known IPv6 stacks and small IPv6 stacks
6 Conclusion Through this study we have seen that there are many evolutions brought by IPv6 which may be summarized by: • Simple header format with large space and hierarchical addressing • Native Autoconfiguration functions • Improvement of the mobility functions • More Security On top of that transition mechanism was designed in order to ensure cohabitation with IPv4. A world consortium defines procedure for testing IPv6 implementations in order to ensure interoperability. To choose IPv6 implementation, interoperability is an important point in addition to conformance with RFCs. The second point is to check if implementations answer the applications needs and if the target device will run this implementation. For this study there is not enough information about IPv6 need to choose one stack for ADCN+ architecture. Thanks to this study IPv6 key functionalities have been identified through the two first parts of this report. A complete sorted list of stacks certified at the present time is given into appendices which let us distinguish the main criteria which are platform and OS dependencies to classify existing stacks. Regarding these criteria, the small stacks for embedded devices (uIPv6 stack, Acmet IPv6 Stack, IPNET, KASAGO IPv6, NexGenIP, Treck IPv4/v6, Fusion Embedded TCP/IPv4/v6) seem to be the best solutions to integrate into ADCN+ architecture. Among these solutions a phase-2 certified (KASAGO IPv6, NexGenIP, Treck IPv4/v6, Fusion Embedded TCP/IPv4/v6) product should be privileged. The uIPv6 stack could be eliminated because it does not support multicast functions and IPSec. In the future this could be reevaluated as it may include other functionalities. To conclude this study allows us to have an overview about existing IPv6 stacks in the market and provide an entree point for the future study. In fact, this study has allowed reducing the number of possible stacks from three thousands to seven, However ADCN+ architecture and needs will evaluate in the future and there will be new certified stacks and new updates for the existing ones. This study has constituted a starting point for the next studies.
66
