- Email: [email protected]
IPv6 protocol – Base principles, deployment and industrial applications
IPv6 protocol – Base principles, deployment and industrial applications Tomáš Macho*
*Brno University of Technology, The Faculty of Electrical Engineering and Communication, Brno, Czech Republic (Tel: +420-541-141-163; e-mail: macho@ feec.vutbr.cz).
Abstract: The IPv6 protocol utilizes some principles and mechanisms that are d ifferent from the IPv4 protocol. This article describes an addressing architecture of the IPv6 protocol, new mechanisms such as a neighbor discovery, a stateless and stateful automatic configuration and a development of IPv6 protocol standards. Some security problems of t he IPv6 protocol are discussed and applications of the IPv6 protocol for embedded systems and sensor networks are briefly mentioned. Keywords: IPv6, neighbor discovery, address autoconfiguration, SLAAC, DHCPv6, sensor network.
1. INTRODUCTION Networks based on TCP/IP communication has utilised the IPv4 protocol for more than 30 years. During this period the IPv4 protocol went throw grate development. For example, the addressing mechanism transited from addresses based on classes to CIDR (Classless In ter-Domain Routing), multicast and anycast address types were added and many security mechanisms were developed.
December 1995 by RFC 1883 and the set of the related RFC specifications followed in 1996. However, the industry was not ready to accept the new protocol which was incompatible with currently used IPv4 protocol. The economic cost of the IPv6 deployment would ha ve been probably inacceptable in the end of 1990s . The IPv4 address s pace exhaustion was taken away by NAT (Network Address Translation) technology and CIDR by more than 10 years.
Unfortunately, the IPv4 protocol has serious drawback – small address space. The IANA’s central pool of available IPv4 addresses was exhausted on February 2011. The IPv6 protocol provides enough addresses to allow the Internet to continue to expand and the industry to innovate. However, IPv6 is no t directly compatible with the IPv4 protocol. This fact complicates and slows down the transition to the IPv6 protocol.
It was not meant that all works on the IPv6 development did not continue at all. A new revision of the IPv6 protocol (RFC 2460) was emitted in December 1998 and t he set of related RFCs was p ublished in 1999. The IPv6 protocol was implemented experimentally into many operating systems. For example, a CAME project (1998 - 2006) provided a free IPv6 stack that was i mplemented into most BSD fam ily of operating systems (NetBSD, OpenBSD, FreeBSD, BSD/OS). A mobility support (RFC 3775) was finished in 2004.
The IPv6 protocol brings some new m echanisms as a neighbor discovery or a state less address autoconfiguration. On the other side, same mechanisms widely used i n IPv4 world are implemented differently in IPv6.
The strong interest on the IPv6 development was renewed in 2007. At th is time it was cl ear that the IPv6 address space will be exhausted and there is no mechanism that would avoid it.
This article describ es main differences between IPv6 and IPv4, some new IPv6 features, development of IPv6 standards and security problems of IPv6 deployment. Benefit of the IPv6 protocol for embedded systems and se nsor networks are mentioned.
On October 2007 the RIPE 55 meeting gave up resolution on IPv4 depletion and deployment of IPv6. IPv6 addresses of six root DNS servers were put in Internet on February 2008. Transition Plan (RFC 5211) was published on July 2008.
2. IPv6 PROTOCOL DEVELOPMENT The IPv6 protocol is not so new protocol as som ebody can think. In beginning of 1990s Internet expanded in the commerce and in the indust ry. The IPv4 address space began rapidly diminish. Around 1992 the global shortage of IPv4 addresses was recognized as the serious limiting factor of the future Internet expansion. As the reaction on this problem, the Internet Engineering Task Force (IETF) in itiated the design and the development of a sui te of protocols and standards as early as in 1994. An IPv6 core was specified on
3. IPv6 ADDRESSESING ARCHITECTURE The main motivation for the IPv6 deployment is address space extension so as it will not be able to be exhausted in future. Therefore IPv6 addresses are 128-bits long which gives 3.4x1038 different addresses. The IPv6 addresses are expressed in a hexadecimal notation (for example, 2001:DB8:8::260:97ff:fe40:efab). The use of "::" indicates one or more groups of 16 bits of zeros. RFC 4291 and its update RFC 5952 describe rules for a t extual representation of the IPv6 addresses in more detail.
An IPv6 addressing architecture is defined by RFC 4291. The IPv6 protocol uses u nicast, multicast and anycast address types. There are no broadcast addresses in IPv6. The type o IPv6 address is identified by high-order bits of the address. The currently defined IPv6 a ddress types and t heir IPv4 equivalents are summarised in the Table1. Table 1. IPv6 addresses Prefix ::0 ::1/128 fe80::/10 fc00::/7
Address type Unspecified Loopback Link-Local Unique-Local
ff00::/8 Everything else
Multicast Global
IPv4 equivalent 0.0.0.0 127.0.0.1/8 none 10.0.0.0/8, 172.16.0.0/12, 168.0.0.0/16 224.0.0.0/4 Global IPv4
all Global Unicast addresses other than those that start with binary 000 have a 64-bits interface ID field. High 64-bits of the address remain for a prefix (address of network) which is subdivided further on a global routing prefix and a subnet ID. The global routing prefix is the value representing a cluster of subnets/links assigned to a site. It describes a global routing topology. The subnet ID identifies the link within the site and represents local routing topology. Long discussions have been held about the size of the global routing prefix. RFC 3177 recommended the length of 48-bits for the global routing prefix in the general case and 16-bits for the subnet ID. The most recent RFC 6177 (Ma rch 2011) moves away from the previous recommendation that a single default assignment size make sense for all end sites in t he general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate. Smaller sites c an receive t he 56-bits gl obal routing prefix for example. 3.4 Interface identifiers for unicast addresses
3.1 Link-Local IPv6 Unicast addresses Every interface must have just one Link-Local address which must be aut omatically configured during the interface initialization. This type of the address is new in IPv6. A scope of the Link-Local address is single link (for ex ample, one Ethernet segment). Most of si gnalization messages use Link-Local addresses (for example, neighbor discovery messages or routing protocols as OSPFv3 and RIP-NG). 3.2 Unique-Local IPv6 Unicast addresses Unique-Local IPv6 Unicast addresses (ULA) are de fined by RFC 4193. T hese addresses are globally unique and are intended for local communication. They must not be routed to the global Internet. One possible use of ULA is merging before separated private networks. However, the existence of ULA is infirmed by many authors because the IPv6 address space is extre mely large and every body can get gl obal addresses. 3.3 IPv6 Global Unicast addresses Every prefixes that are no t occupied by other types of addresses create global address space. Today, Global Unicast addresses begin with 2000::/3 but additional free parts of the IPv6 address space can be added in future. Global Unicast addresses are assigned hierarchically. There is an effort to aggregate routing information maximally as is possible because the a ggregation reduces the size of routing tables. The concept of the ag gregation was orig inally included in a structure of Global Unicast addresses (see RFC 2374). Such rigid format showed impractical and was obsoleted by RFC 3587 that introduced the simplified and flexible model. The general format of the IPv6 Global Unicast Addresses is defined by RFC 3587 and RFC 4291. RFC 4291 states that
Interface identifiers are used to identify the interfaces on the link. They are 64 bits long and constructed in a M odified EUI-64 format. (An exception can be addresses that start with the binary value 000). Modified EUI-64 format-base interface identifiers may have the universal scope when they are derived from universal tokens (e.g., IEEE 802 48-bit MAC or IEEE EUI-64) or may have the local scope when universal tokens are not used (e.g., temporary tokens, manually configured identifiers). More details about creating Modified EUI-64 format interface identifiers can be found for instance in RFC 4291, Microsoft Corporation (2008), Satrapa (2011). Interface identifiers that remain constant over tim e can generate a privacy problem. Because t he part of the address stays fixed even when the host move to other network, it is possible to trace the moving of the host and its owner by sniffing the communication at strategic places. This proble m concerns mainly mobile devices (e.g., notebooks, PDAs, etc.). To address this problem and provide a level of anonymity, an alternative IPv6 interface identifier that is randomly generated and changes over time can be generated as i t is described by RFC 4941. Resulting global scope addresses, based on the random interface id entifier that change d over time, are known as tem porary addresses. Another way to assign temporary addresses for clients i s to use stateful DHCPv6. The machine can use the temporary address to c onnect to another machine but the temporary address cannot be used for server applications because it cannot be registered in DNS. Many machines function simultaneously as t he client and the server. Such the machine needs multiple addresses. A “public” server address registered in DNS and a “temporary” address that must not be registered in DNS. The machine uses the temporary address to shield the identity when acting as
the client. The public address is used to accept the incoming connection requests from the other machines. Today, most of the UNIX/Linux systems create the interface identifiers based on the IEEE 8 02 48-bit MAC id entifier in the default configuration. Using the temporary addresses can be optionally enabled. Windows starting with XP SP2 and MAC OS X since OS X 10.7 (Lion) use the temporary addresses in the default configuration. Windows XP and MAC OS X derive the interface identifiers for th e public and Link-Local addresses from the IEEE 802 48-bit MACs. Windows Vista and Windows 7 use random value as the interface identifier for the public and Link-Local address. However, this identifier is different from the identifier for the temporary addresses and do not change over time. 4. NEIGHBOR DISCOVERY Neighbor Discovery (ND) process is set of messages and processes that determine relationships between neighboring nodes (nodes which are on the same link). The ND process is new in IPv6 and has no equivalent in IPv4. Full specification of ND is given by RFC 4861. ND is based on fi ve base IC MPv6 messages: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisement messages and a Redirect message. Two other messages were added for SEND (Secure Neighbor Discovery): Certification path solicitation and Certification path advertisement. These messages are used for the following processes:
Address resolution
Duplicate address detection (DAD)
Router and prefix discovery
Neighbor unreachability detection
Redirection function
IPv6 packet Neighbor Discovery Message Neighbor Discovery Message Header
An IPv6 node uses the address resolution process when it wants to send a uni cast packet to a nei ghbor, but does not know the neighbour’s link-layer address. The Address resolution process replaces ARP (Address Resolution Protocol) used by IPv4. The node stores results of the address resolution process into a neighbor cache. Every IPv6 interface m ust create solicited-node m ulticast addresses for each of their unicast addresses and listen on them. The solicited-node address is constructed by appending a last 24-bi ts of the unicast address to a prefix ff02::1ff00:0/104. An Address Resolution process consists of e xchanging Neighbor Solicitation and Neighbor Advertisement messages. The node searching the link-la yer address sends Neighbor Solicitation message to the solicited-node multicast address. The Neighbor Solicited message contains a targ et IPv6 address and also includes a Source Link-Layer Address option. A receiving node must check the target address contained in the Neighbor Solicitation message because the solicited-node multicast addresses need not be unique. If the target address is equal to any unicast address of the node, the node updates its neighbor cache (using Source Link-Layer Address option) and replays with the Neighbor Advertisement message. The replay is sent to the unicast address. After receiving the Neighbor Advertisement m essage, the node updates its neighbor cache for the target upon the information included in the Target Link-Layer option. Both nodes know their link–layer addresses and ca n exchange packets mutually. 4.2 Duplicated Address Detection
All ND messages have a single format (Fig. 1).
IPv6Header Next Header = 58 (ICMPv6)
4.1 Address resolution
Neighbor Discovery Message Options
Fig. 1. ND message format. Neighbor Discovery Message Options have the form of TLV (Type Length Value). Five options are defined: Source LinkLayer Address, Target Link-Layer Address, Prefix Information, Redirected Header and MTU (Maximum Transition Unit).
The Duplicate Address Detection (DAD) is used by node to verify uniqueness of the address before it can be assi gned to the interface. DAD also consists of exchanging Neighbor Solicitation and Neighbor Advertisement messages. The node that wants t o check a new address sends the Neighbor Solicitation message and waits for answer. Typically, three solicitation messages are sent. If no answer is received, the address can be assigned. In opposite case, t he node must not use this address. Because the tested address is not assigned to the interface during the test, replays must be sent to an all-nodes multicast address (ff02::1). 4.3 Router and Prefix Discovery Router Discovery is used by hosts to locate neighboring routers (routers residing on an attached link) as well as to learn prefixes and c onfiguration parameters related to stateless address autoconfiguration.
The router multicasts Router Advertisement packets out its interfaces. An interval bet ween sending a dvertisements is randomised to reduce the probability of the syn chronization with the advertisements from the other routers. Typically, the maximal value of the interval is 600 seconds and the minimal value is 0.33*600 = 200 seconds. A host receives Router Advertisement messages from all routers on the local link and builds a Default Router List (a list of routers to which packet may be sent). Router Advertisement can also contain Prefix Inform ation options which the host can u se for two logically distinct purposes: 1.
Prefix Discovery.
2.
Stateless Address Autoconfiguration (SLAAC).
Prefix Discovery is process allowing hosts to discover the set of the address ranges that define the destinations on the local link (on-link) to which the packets can be sent directly without using the router. Such Prefix Info rmation options must have set 1-bit on-link flag (L). Ho st should build and maintain a Prefix List (a list o f the prefixes that define a set of addresses that are on-link). The host uses the Prefix List to decide if it should send the packet directly to the host on-link or to use the router. Host can also learn link parameters (such as the link MTU) or Internet parameters (such as the hop limit value) from the Router Advertisement. The Router Advertisements (and per-prefix flags) allow th e routers to inform the hosts how to perform the Address Autoconfiguration. There are two 1-bit flags wh ich relate to configuration availability via DHCPv6:
M - "Managed address configuration" flag. When set, it indicates that addre sses are available via DHCPv6. If M bit is set, th e O bit is red undant because DHCPv6 will re turn all available configuration information. O - "Other configuration" flag. When set, it indicates that other configuration information (e.g., DNS setting) is available via DHCPv6.
Important note: Window Vista and Windows 7 do not behave correctly when both flags are set. When the interface becomes enabled, the host need not wait for Router Advertisement message, but it can send a Router Solicitation message requesting the routers to generate the Router Advertisement immediately. The host sends Router Solicitation message to multicast address ff02::2 (all ro uters on-link). The routers usually send a sol icited Router Advertisement on m ulticast address ff02:1 because starti ng host has not any configured unicast IPv6 address. 5. STATELESS ADDRESS AUTOCONFIGURATION Stateless Address Autoconfiguration (SLAAC, SLAC) allows the host to automatically generate its o wn addresses. The
addresses are created by combining locally provided interface identifiers with the prefixes advertised by the routers. To ensure that configured addresses are likely to be unique on a given link, host should run the DAD algorithm on ev ery newly created address before assigning it to the interface. SLAAC can be enabled or di sabled for the prefix by 1-bit autonomous address-configuration flag (A) in the Prefix Information option. The host interface can obtain unicast IPv6 addresse s and addresses of on-link routers by SLAAC but a recursive DNS server list an d a do main search list cann ot be obtained by SLAAC. The absence of the recursive DNS server list and the domain search list in SLAAC tries to solve RFC 6106. This document defines two new options for the Router Advertisement messages:
RDNSS (Recursive DNS Server) option contains one or m ore IPv6 addres ses of recursive DNS servers. All addresses share the same Lifetime value. If it is desirable to have different Lifetime values, multiple RDNSS options can be used.
DNSSL (DNS Search List) option contains one or more domain names of D NS suffixes. All domain names share the same Lifetime value. If it is desirable to have different Lifetime values, multiple DNSSL options can be used.
RFC 6106 is supported only by UNIX/Linux and MAC OS X since OS X 10.7 (Lion) today. Current Microsoft systems do not implement RFC 610 6 and nothing is kn own about its support by future Microsoft systems. I do not know a hardware box (router, routing switch) that implements RFC 6106 today. 6. DHCPv6 The first proposal of the IPv6 protocol did not expect to use DHCP at all. DHCPv6 was defined by RFC 3315 after long discussions in 2003. Two types of DHCPv6 are defined: stateful and st ateless. The stat eful DHCPv6 is designed to assign IPv6 address and other configuration parameters (the recursive DNS server list, the d omain search list an d time server lists). The stateless DHCPv6 is simplified version that does not assign IPv6 addresses but only sends other configuration parameters. A DHCPv4 client is identified by the IEEE 802 48-bit MAC identifier typically which is simple and practical. DHCPv6 uses a special ly created uni que identifier called a DUID (DHCP Unique Identifier). Standards (RFC 3315, RFC 6355) define four ways how to create the DUID. The producer of the DHCPv6 client can decide which tape of the DUID will use. This means that each s ystem creates the DUID in a different way. If the host has multiboot with more than one operating system, then each sy stem will have a di fferent DUID. Most likely, the DUID will also change after reinstallation of the operating system.
The stateful configuration based on DHCPv6 allows to assign non-temporary or temporary addresses and additional configuration parameters such as the rec ursive DNS server list and dom ain search list. On other side, DHCPv6 has a serious drawback because it cannot provide addresses of routers. The router sending Router Advertisements are a lso needed when the stateful configuration is used. Historically, there ware effort to integrate router list in to DHCPv6. Some drafts ware proposed but all expired. Now, the IETF i s working on draft”DHCPv6 Route Options” (draft-ietf-mif-dhcpv6-route-option04), which may be accepted as a standard in the future. 7. AUTOMATIC CONFIGURATION OF AN IPv6 HOST An automatic configuration of the IPv4 host is based on DHCP. The host obtains the IPv4 address, the default gateway, the recursive DNS server list and the domain search list from the DHCP server. A situation of IPv6 host is more complicated. The IPv6 protocol provides two methods of an automatic configuration:
only when the tight control over exact address assignments is required. SLAAC and stateful DHCPv6 together. (Configuration flags require the following setting: M= 1, O= 0, A= 1.) It is also possible to combine SLAAC and stateful DHCPv6 together. Host create addresses using both SLAAC and DHCPv6. However, it is n ot cleared which address the client will u se for establishing the communication. By my tests, W indows Vista and Windows 7 clients prefer the addresses assigned by SLAAC and do not use addresses assigned by DHCPv6 at all. 8. SECURITY ASPECTS OF A IPv6 DEPLOYMENT We can often find claim that IP v6 protocol is more secure than IPv4 protocol. This claim is based on two facts: a mandatory implementation of an IPSec mechanism in the base IPv6 implementation and a big address space. However, the grater security of t he IPv6 protocol based on the mandatory IPSec im plementation is i llusion for more reasons:
SLAAC.
IPSec is very small utilised.
Stateful address autoconfiguration based on stateful DHCPv6.
IPv6 with IPSec does not guard against XSS (Crosssite scripting).
SLAAC requires no m anual configuration of the hosts and minimal configuration of the routers. It is useful when a site is not particularly concerned with the exact addresses hosts use. DHCPv6 is useful when a si te requires tighter control over exact address assignments.
The mandatory ESP (Encapsulation Security Payload) IPSec header only crypts payload. The information from the IPv6 headers as source and destination address is not encrypted.
Because IP data is encrypted, fi rewalls, IDS’s (Intrusion Detection System), IDP (Intrusion Detection Prevention) systems and monitoring probes are “blinded”.
Unfortunately, as it was described above, both methods have drawbacks. The absence of the router list and problematical host identification make stateful DHCPv6 rather unattractive. On the other hand, SLAAC does not provide the recursive DNS server list and the domain search list. What type of configuration to use today? It is not possible to use the pure SLAAC or the pure stateful a utoconfiguration based on DHCPv6. There are three possible configuration scenarios: SLLAC and st ateless DHCPv6. (Configuration flags re quire the following setting: M=0, O=1, A=1.) The client creates the IPv6 addresses using SL AAC, the st ateless DHCPv6 provides the recursive DNS server list and domain search list. The stateless DHCPv6 is preferred by network administrators because a configuration file cont ains only the IPv6 addres ses of the recursive DNS servers and the search list. No DUIDs are needed. These confi guration parameters do not us ually change for years. We use automatic configuration based on the SLAAC and stateless DHCPv6 successfully in our faculty network for more than 3 years. Stateful DHCPv6 and Router Advertisements. (Configuration flags require the following setting: M= 1, O= 0, A= 0.) The DHCPv6 server provides IPv6 addresses and other configuration parameters. The client creates the list of on-link routers from Router Advertisements. This scenario is useful
Scanning the big IPv6 addre ss space is m ore complicated then scanning the small IPv4 a ddress space. Unfortunately, attackers can use some information (DNS records, reverse DNS records, Whois, server logs, Modified EUI 64 addresses derived from IEEE 802 48-b it MAC identifier) to m ake scanning easier. Some new mechanism s, which a re critical for t he IPv6 operation, bring new security risks. Neighbor Discovery mechanism seems to be the most vulnerable. We will briefly describe the most “popular” types of attacks. A neighbor cache spoofing is very similar to an I Pv4 ARP spoofing. An attacking node can cause packets for legitimate node, to be sent to some other Link-Layer address. This can be done by either sending a Neighb or Solicitation with a different source Link-Layer address option or by sending a Neighbor Advertisement with a diffe rent target Lin k-Layer address option. The binding between IPv6 address and spoofed Link-Layer address can be ke pt in the neighbor cache for relatively long time. DAD mechanism can be used for DoS attack. Attacking node answers to every DAD attempt. No host will be able to obtain an address.
Neighbor cache table overl oad. The attacker ove rloads the neighbor cache tab le with many records for non existing clients. The attacking node can also send fake Router Advertisements or functions as a fake DHCPv6 server. To prevent against such attacks, an unwanted traffic must be bl ock on access ports. Today, this can be si mply done by a n access control list. The new solution of the pre vention against the fake Router Advertisements brings a RA-Guard (IPv6 Router Advertisement Guard) that is described in RFC 6105. The RA Guard feature restricts th e ports that can accept Router Advertisements. For example, the RA-Guard function will be implemented in a next version of firmware K.15.07 for HP (Hewlett-Packard) routing switches. Additionally, this firmware will g ive possibility to block ICMPv6 Redirect messages on th e configured ports. Future complex solution solving rouge Router Advertisements, DHCPv4 and DHCPv6 can be S AVI (Source Address Validation Improvement). Today, SAVI is a group of drafts and it is not possible to buy any device supporting this type of the protection. 9. IDUSTRIAL IPv6 APPLICATIONS The IPv6 protocol makes possible to communicate without NAT in the whole Internet. Many embedded systems can provide server functions more simply. This is u seful for intelligent transportation systems, building environment managements, smart home security systems and many others. The big IPv6 addres sing space is i nteresting for sensor network technologies including wireless sensor networks. The IPv6 protocol can also provide autoconfiguration via the IPv6 neighbor discovery and SLAA C features and provides support for network mobility to large sensor networks. To create IPv6-enabled sensor network requires appropriate inter-working between the IPv6 layer and the link layer. The IPv6 operation must be specified for e very specific sensor link technology. RFC 4944 specifies IPv6 operation over IEEE 802.15.4 networks. R FC 6282, which updates RFC 4944, specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). Bluetooth devices can al so support the IPv6 protocol. The IPv6 packet is encapsulated by Bluetooth Network Encapsulation Protocol (BNEP) and pass on the Logical Link Control and Adaptation Protocol (L2CAP) layer of Bluetooth stack. 10. CONCLUSIONS The practice shows that the transition to the IPv6 protocol is more complicated and slower then was supposed. It is evident that Internet Transition Plan (RFC 5211) was unrealistic.
The state of global IPv6 deployment was app roximately the following in 2011: 39% of the Internet’s transit networks appear to be dual stack capable and about 50% of the Internet’s end devices have the installed IPv6 stack but only 0.4% of the Internet’s end devices have the native IPv6 connection. It is clear that th e main problem of sl ow IPv6 deployment is on the side of access providers of the end use r connection. This problem is mainly economical not technical. Small business pressure was on IPv6 deployment. The situation will probably move forward in 2012. Major Internet service provider, home networking equipment manufacturers and web companies around the world have announced at beginning 2012 that they are coming together to permanently enable IPv6 for their products and services by 6 June 2012. It can be supposed that a massive availability of IPv6 protocol will in crease the pressure to resolve live technical problems as security or the automatic configuration. REFERENCES Microsoft Corporation. (2008). Introduction to IP version 6. Microsoft Corporation. Satrapa, P., (2011). Internetový protokol verze 6. CESNET, z. s. p. o., Praha.
*Brno University of Technology, The Faculty of Electrical Engineering and Communication, Brno, Czech Republic (Tel: +420-541-141-163; e-mail: macho@ feec.vutbr.cz).
Abstract: The IPv6 protocol utilizes some principles and mechanisms that are d ifferent from the IPv4 protocol. This article describes an addressing architecture of the IPv6 protocol, new mechanisms such as a neighbor discovery, a stateless and stateful automatic configuration and a development of IPv6 protocol standards. Some security problems of t he IPv6 protocol are discussed and applications of the IPv6 protocol for embedded systems and sensor networks are briefly mentioned. Keywords: IPv6, neighbor discovery, address autoconfiguration, SLAAC, DHCPv6, sensor network.
1. INTRODUCTION Networks based on TCP/IP communication has utilised the IPv4 protocol for more than 30 years. During this period the IPv4 protocol went throw grate development. For example, the addressing mechanism transited from addresses based on classes to CIDR (Classless In ter-Domain Routing), multicast and anycast address types were added and many security mechanisms were developed.
December 1995 by RFC 1883 and the set of the related RFC specifications followed in 1996. However, the industry was not ready to accept the new protocol which was incompatible with currently used IPv4 protocol. The economic cost of the IPv6 deployment would ha ve been probably inacceptable in the end of 1990s . The IPv4 address s pace exhaustion was taken away by NAT (Network Address Translation) technology and CIDR by more than 10 years.
Unfortunately, the IPv4 protocol has serious drawback – small address space. The IANA’s central pool of available IPv4 addresses was exhausted on February 2011. The IPv6 protocol provides enough addresses to allow the Internet to continue to expand and the industry to innovate. However, IPv6 is no t directly compatible with the IPv4 protocol. This fact complicates and slows down the transition to the IPv6 protocol.
It was not meant that all works on the IPv6 development did not continue at all. A new revision of the IPv6 protocol (RFC 2460) was emitted in December 1998 and t he set of related RFCs was p ublished in 1999. The IPv6 protocol was implemented experimentally into many operating systems. For example, a CAME project (1998 - 2006) provided a free IPv6 stack that was i mplemented into most BSD fam ily of operating systems (NetBSD, OpenBSD, FreeBSD, BSD/OS). A mobility support (RFC 3775) was finished in 2004.
The IPv6 protocol brings some new m echanisms as a neighbor discovery or a state less address autoconfiguration. On the other side, same mechanisms widely used i n IPv4 world are implemented differently in IPv6.
The strong interest on the IPv6 development was renewed in 2007. At th is time it was cl ear that the IPv6 address space will be exhausted and there is no mechanism that would avoid it.
This article describ es main differences between IPv6 and IPv4, some new IPv6 features, development of IPv6 standards and security problems of IPv6 deployment. Benefit of the IPv6 protocol for embedded systems and se nsor networks are mentioned.
On October 2007 the RIPE 55 meeting gave up resolution on IPv4 depletion and deployment of IPv6. IPv6 addresses of six root DNS servers were put in Internet on February 2008. Transition Plan (RFC 5211) was published on July 2008.
2. IPv6 PROTOCOL DEVELOPMENT The IPv6 protocol is not so new protocol as som ebody can think. In beginning of 1990s Internet expanded in the commerce and in the indust ry. The IPv4 address space began rapidly diminish. Around 1992 the global shortage of IPv4 addresses was recognized as the serious limiting factor of the future Internet expansion. As the reaction on this problem, the Internet Engineering Task Force (IETF) in itiated the design and the development of a sui te of protocols and standards as early as in 1994. An IPv6 core was specified on
3. IPv6 ADDRESSESING ARCHITECTURE The main motivation for the IPv6 deployment is address space extension so as it will not be able to be exhausted in future. Therefore IPv6 addresses are 128-bits long which gives 3.4x1038 different addresses. The IPv6 addresses are expressed in a hexadecimal notation (for example, 2001:DB8:8::260:97ff:fe40:efab). The use of "::" indicates one or more groups of 16 bits of zeros. RFC 4291 and its update RFC 5952 describe rules for a t extual representation of the IPv6 addresses in more detail.
An IPv6 addressing architecture is defined by RFC 4291. The IPv6 protocol uses u nicast, multicast and anycast address types. There are no broadcast addresses in IPv6. The type o IPv6 address is identified by high-order bits of the address. The currently defined IPv6 a ddress types and t heir IPv4 equivalents are summarised in the Table1. Table 1. IPv6 addresses Prefix ::0 ::1/128 fe80::/10 fc00::/7
Address type Unspecified Loopback Link-Local Unique-Local
ff00::/8 Everything else
Multicast Global
IPv4 equivalent 0.0.0.0 127.0.0.1/8 none 10.0.0.0/8, 172.16.0.0/12, 168.0.0.0/16 224.0.0.0/4 Global IPv4
all Global Unicast addresses other than those that start with binary 000 have a 64-bits interface ID field. High 64-bits of the address remain for a prefix (address of network) which is subdivided further on a global routing prefix and a subnet ID. The global routing prefix is the value representing a cluster of subnets/links assigned to a site. It describes a global routing topology. The subnet ID identifies the link within the site and represents local routing topology. Long discussions have been held about the size of the global routing prefix. RFC 3177 recommended the length of 48-bits for the global routing prefix in the general case and 16-bits for the subnet ID. The most recent RFC 6177 (Ma rch 2011) moves away from the previous recommendation that a single default assignment size make sense for all end sites in t he general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate. Smaller sites c an receive t he 56-bits gl obal routing prefix for example. 3.4 Interface identifiers for unicast addresses
3.1 Link-Local IPv6 Unicast addresses Every interface must have just one Link-Local address which must be aut omatically configured during the interface initialization. This type of the address is new in IPv6. A scope of the Link-Local address is single link (for ex ample, one Ethernet segment). Most of si gnalization messages use Link-Local addresses (for example, neighbor discovery messages or routing protocols as OSPFv3 and RIP-NG). 3.2 Unique-Local IPv6 Unicast addresses Unique-Local IPv6 Unicast addresses (ULA) are de fined by RFC 4193. T hese addresses are globally unique and are intended for local communication. They must not be routed to the global Internet. One possible use of ULA is merging before separated private networks. However, the existence of ULA is infirmed by many authors because the IPv6 address space is extre mely large and every body can get gl obal addresses. 3.3 IPv6 Global Unicast addresses Every prefixes that are no t occupied by other types of addresses create global address space. Today, Global Unicast addresses begin with 2000::/3 but additional free parts of the IPv6 address space can be added in future. Global Unicast addresses are assigned hierarchically. There is an effort to aggregate routing information maximally as is possible because the a ggregation reduces the size of routing tables. The concept of the ag gregation was orig inally included in a structure of Global Unicast addresses (see RFC 2374). Such rigid format showed impractical and was obsoleted by RFC 3587 that introduced the simplified and flexible model. The general format of the IPv6 Global Unicast Addresses is defined by RFC 3587 and RFC 4291. RFC 4291 states that
Interface identifiers are used to identify the interfaces on the link. They are 64 bits long and constructed in a M odified EUI-64 format. (An exception can be addresses that start with the binary value 000). Modified EUI-64 format-base interface identifiers may have the universal scope when they are derived from universal tokens (e.g., IEEE 802 48-bit MAC or IEEE EUI-64) or may have the local scope when universal tokens are not used (e.g., temporary tokens, manually configured identifiers). More details about creating Modified EUI-64 format interface identifiers can be found for instance in RFC 4291, Microsoft Corporation (2008), Satrapa (2011). Interface identifiers that remain constant over tim e can generate a privacy problem. Because t he part of the address stays fixed even when the host move to other network, it is possible to trace the moving of the host and its owner by sniffing the communication at strategic places. This proble m concerns mainly mobile devices (e.g., notebooks, PDAs, etc.). To address this problem and provide a level of anonymity, an alternative IPv6 interface identifier that is randomly generated and changes over time can be generated as i t is described by RFC 4941. Resulting global scope addresses, based on the random interface id entifier that change d over time, are known as tem porary addresses. Another way to assign temporary addresses for clients i s to use stateful DHCPv6. The machine can use the temporary address to c onnect to another machine but the temporary address cannot be used for server applications because it cannot be registered in DNS. Many machines function simultaneously as t he client and the server. Such the machine needs multiple addresses. A “public” server address registered in DNS and a “temporary” address that must not be registered in DNS. The machine uses the temporary address to shield the identity when acting as
the client. The public address is used to accept the incoming connection requests from the other machines. Today, most of the UNIX/Linux systems create the interface identifiers based on the IEEE 8 02 48-bit MAC id entifier in the default configuration. Using the temporary addresses can be optionally enabled. Windows starting with XP SP2 and MAC OS X since OS X 10.7 (Lion) use the temporary addresses in the default configuration. Windows XP and MAC OS X derive the interface identifiers for th e public and Link-Local addresses from the IEEE 802 48-bit MACs. Windows Vista and Windows 7 use random value as the interface identifier for the public and Link-Local address. However, this identifier is different from the identifier for the temporary addresses and do not change over time. 4. NEIGHBOR DISCOVERY Neighbor Discovery (ND) process is set of messages and processes that determine relationships between neighboring nodes (nodes which are on the same link). The ND process is new in IPv6 and has no equivalent in IPv4. Full specification of ND is given by RFC 4861. ND is based on fi ve base IC MPv6 messages: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisement messages and a Redirect message. Two other messages were added for SEND (Secure Neighbor Discovery): Certification path solicitation and Certification path advertisement. These messages are used for the following processes:
Address resolution
Duplicate address detection (DAD)
Router and prefix discovery
Neighbor unreachability detection
Redirection function
IPv6 packet Neighbor Discovery Message Neighbor Discovery Message Header
An IPv6 node uses the address resolution process when it wants to send a uni cast packet to a nei ghbor, but does not know the neighbour’s link-layer address. The Address resolution process replaces ARP (Address Resolution Protocol) used by IPv4. The node stores results of the address resolution process into a neighbor cache. Every IPv6 interface m ust create solicited-node m ulticast addresses for each of their unicast addresses and listen on them. The solicited-node address is constructed by appending a last 24-bi ts of the unicast address to a prefix ff02::1ff00:0/104. An Address Resolution process consists of e xchanging Neighbor Solicitation and Neighbor Advertisement messages. The node searching the link-la yer address sends Neighbor Solicitation message to the solicited-node multicast address. The Neighbor Solicited message contains a targ et IPv6 address and also includes a Source Link-Layer Address option. A receiving node must check the target address contained in the Neighbor Solicitation message because the solicited-node multicast addresses need not be unique. If the target address is equal to any unicast address of the node, the node updates its neighbor cache (using Source Link-Layer Address option) and replays with the Neighbor Advertisement message. The replay is sent to the unicast address. After receiving the Neighbor Advertisement m essage, the node updates its neighbor cache for the target upon the information included in the Target Link-Layer option. Both nodes know their link–layer addresses and ca n exchange packets mutually. 4.2 Duplicated Address Detection
All ND messages have a single format (Fig. 1).
IPv6Header Next Header = 58 (ICMPv6)
4.1 Address resolution
Neighbor Discovery Message Options
Fig. 1. ND message format. Neighbor Discovery Message Options have the form of TLV (Type Length Value). Five options are defined: Source LinkLayer Address, Target Link-Layer Address, Prefix Information, Redirected Header and MTU (Maximum Transition Unit).
The Duplicate Address Detection (DAD) is used by node to verify uniqueness of the address before it can be assi gned to the interface. DAD also consists of exchanging Neighbor Solicitation and Neighbor Advertisement messages. The node that wants t o check a new address sends the Neighbor Solicitation message and waits for answer. Typically, three solicitation messages are sent. If no answer is received, the address can be assigned. In opposite case, t he node must not use this address. Because the tested address is not assigned to the interface during the test, replays must be sent to an all-nodes multicast address (ff02::1). 4.3 Router and Prefix Discovery Router Discovery is used by hosts to locate neighboring routers (routers residing on an attached link) as well as to learn prefixes and c onfiguration parameters related to stateless address autoconfiguration.
The router multicasts Router Advertisement packets out its interfaces. An interval bet ween sending a dvertisements is randomised to reduce the probability of the syn chronization with the advertisements from the other routers. Typically, the maximal value of the interval is 600 seconds and the minimal value is 0.33*600 = 200 seconds. A host receives Router Advertisement messages from all routers on the local link and builds a Default Router List (a list of routers to which packet may be sent). Router Advertisement can also contain Prefix Inform ation options which the host can u se for two logically distinct purposes: 1.
Prefix Discovery.
2.
Stateless Address Autoconfiguration (SLAAC).
Prefix Discovery is process allowing hosts to discover the set of the address ranges that define the destinations on the local link (on-link) to which the packets can be sent directly without using the router. Such Prefix Info rmation options must have set 1-bit on-link flag (L). Ho st should build and maintain a Prefix List (a list o f the prefixes that define a set of addresses that are on-link). The host uses the Prefix List to decide if it should send the packet directly to the host on-link or to use the router. Host can also learn link parameters (such as the link MTU) or Internet parameters (such as the hop limit value) from the Router Advertisement. The Router Advertisements (and per-prefix flags) allow th e routers to inform the hosts how to perform the Address Autoconfiguration. There are two 1-bit flags wh ich relate to configuration availability via DHCPv6:
M - "Managed address configuration" flag. When set, it indicates that addre sses are available via DHCPv6. If M bit is set, th e O bit is red undant because DHCPv6 will re turn all available configuration information. O - "Other configuration" flag. When set, it indicates that other configuration information (e.g., DNS setting) is available via DHCPv6.
Important note: Window Vista and Windows 7 do not behave correctly when both flags are set. When the interface becomes enabled, the host need not wait for Router Advertisement message, but it can send a Router Solicitation message requesting the routers to generate the Router Advertisement immediately. The host sends Router Solicitation message to multicast address ff02::2 (all ro uters on-link). The routers usually send a sol icited Router Advertisement on m ulticast address ff02:1 because starti ng host has not any configured unicast IPv6 address. 5. STATELESS ADDRESS AUTOCONFIGURATION Stateless Address Autoconfiguration (SLAAC, SLAC) allows the host to automatically generate its o wn addresses. The
addresses are created by combining locally provided interface identifiers with the prefixes advertised by the routers. To ensure that configured addresses are likely to be unique on a given link, host should run the DAD algorithm on ev ery newly created address before assigning it to the interface. SLAAC can be enabled or di sabled for the prefix by 1-bit autonomous address-configuration flag (A) in the Prefix Information option. The host interface can obtain unicast IPv6 addresse s and addresses of on-link routers by SLAAC but a recursive DNS server list an d a do main search list cann ot be obtained by SLAAC. The absence of the recursive DNS server list and the domain search list in SLAAC tries to solve RFC 6106. This document defines two new options for the Router Advertisement messages:
RDNSS (Recursive DNS Server) option contains one or m ore IPv6 addres ses of recursive DNS servers. All addresses share the same Lifetime value. If it is desirable to have different Lifetime values, multiple RDNSS options can be used.
DNSSL (DNS Search List) option contains one or more domain names of D NS suffixes. All domain names share the same Lifetime value. If it is desirable to have different Lifetime values, multiple DNSSL options can be used.
RFC 6106 is supported only by UNIX/Linux and MAC OS X since OS X 10.7 (Lion) today. Current Microsoft systems do not implement RFC 610 6 and nothing is kn own about its support by future Microsoft systems. I do not know a hardware box (router, routing switch) that implements RFC 6106 today. 6. DHCPv6 The first proposal of the IPv6 protocol did not expect to use DHCP at all. DHCPv6 was defined by RFC 3315 after long discussions in 2003. Two types of DHCPv6 are defined: stateful and st ateless. The stat eful DHCPv6 is designed to assign IPv6 address and other configuration parameters (the recursive DNS server list, the d omain search list an d time server lists). The stateless DHCPv6 is simplified version that does not assign IPv6 addresses but only sends other configuration parameters. A DHCPv4 client is identified by the IEEE 802 48-bit MAC identifier typically which is simple and practical. DHCPv6 uses a special ly created uni que identifier called a DUID (DHCP Unique Identifier). Standards (RFC 3315, RFC 6355) define four ways how to create the DUID. The producer of the DHCPv6 client can decide which tape of the DUID will use. This means that each s ystem creates the DUID in a different way. If the host has multiboot with more than one operating system, then each sy stem will have a di fferent DUID. Most likely, the DUID will also change after reinstallation of the operating system.
The stateful configuration based on DHCPv6 allows to assign non-temporary or temporary addresses and additional configuration parameters such as the rec ursive DNS server list and dom ain search list. On other side, DHCPv6 has a serious drawback because it cannot provide addresses of routers. The router sending Router Advertisements are a lso needed when the stateful configuration is used. Historically, there ware effort to integrate router list in to DHCPv6. Some drafts ware proposed but all expired. Now, the IETF i s working on draft”DHCPv6 Route Options” (draft-ietf-mif-dhcpv6-route-option04), which may be accepted as a standard in the future. 7. AUTOMATIC CONFIGURATION OF AN IPv6 HOST An automatic configuration of the IPv4 host is based on DHCP. The host obtains the IPv4 address, the default gateway, the recursive DNS server list and the domain search list from the DHCP server. A situation of IPv6 host is more complicated. The IPv6 protocol provides two methods of an automatic configuration:
only when the tight control over exact address assignments is required. SLAAC and stateful DHCPv6 together. (Configuration flags require the following setting: M= 1, O= 0, A= 1.) It is also possible to combine SLAAC and stateful DHCPv6 together. Host create addresses using both SLAAC and DHCPv6. However, it is n ot cleared which address the client will u se for establishing the communication. By my tests, W indows Vista and Windows 7 clients prefer the addresses assigned by SLAAC and do not use addresses assigned by DHCPv6 at all. 8. SECURITY ASPECTS OF A IPv6 DEPLOYMENT We can often find claim that IP v6 protocol is more secure than IPv4 protocol. This claim is based on two facts: a mandatory implementation of an IPSec mechanism in the base IPv6 implementation and a big address space. However, the grater security of t he IPv6 protocol based on the mandatory IPSec im plementation is i llusion for more reasons:
SLAAC.
IPSec is very small utilised.
Stateful address autoconfiguration based on stateful DHCPv6.
IPv6 with IPSec does not guard against XSS (Crosssite scripting).
SLAAC requires no m anual configuration of the hosts and minimal configuration of the routers. It is useful when a site is not particularly concerned with the exact addresses hosts use. DHCPv6 is useful when a si te requires tighter control over exact address assignments.
The mandatory ESP (Encapsulation Security Payload) IPSec header only crypts payload. The information from the IPv6 headers as source and destination address is not encrypted.
Because IP data is encrypted, fi rewalls, IDS’s (Intrusion Detection System), IDP (Intrusion Detection Prevention) systems and monitoring probes are “blinded”.
Unfortunately, as it was described above, both methods have drawbacks. The absence of the router list and problematical host identification make stateful DHCPv6 rather unattractive. On the other hand, SLAAC does not provide the recursive DNS server list and the domain search list. What type of configuration to use today? It is not possible to use the pure SLAAC or the pure stateful a utoconfiguration based on DHCPv6. There are three possible configuration scenarios: SLLAC and st ateless DHCPv6. (Configuration flags re quire the following setting: M=0, O=1, A=1.) The client creates the IPv6 addresses using SL AAC, the st ateless DHCPv6 provides the recursive DNS server list and domain search list. The stateless DHCPv6 is preferred by network administrators because a configuration file cont ains only the IPv6 addres ses of the recursive DNS servers and the search list. No DUIDs are needed. These confi guration parameters do not us ually change for years. We use automatic configuration based on the SLAAC and stateless DHCPv6 successfully in our faculty network for more than 3 years. Stateful DHCPv6 and Router Advertisements. (Configuration flags require the following setting: M= 1, O= 0, A= 0.) The DHCPv6 server provides IPv6 addresses and other configuration parameters. The client creates the list of on-link routers from Router Advertisements. This scenario is useful
Scanning the big IPv6 addre ss space is m ore complicated then scanning the small IPv4 a ddress space. Unfortunately, attackers can use some information (DNS records, reverse DNS records, Whois, server logs, Modified EUI 64 addresses derived from IEEE 802 48-b it MAC identifier) to m ake scanning easier. Some new mechanism s, which a re critical for t he IPv6 operation, bring new security risks. Neighbor Discovery mechanism seems to be the most vulnerable. We will briefly describe the most “popular” types of attacks. A neighbor cache spoofing is very similar to an I Pv4 ARP spoofing. An attacking node can cause packets for legitimate node, to be sent to some other Link-Layer address. This can be done by either sending a Neighb or Solicitation with a different source Link-Layer address option or by sending a Neighbor Advertisement with a diffe rent target Lin k-Layer address option. The binding between IPv6 address and spoofed Link-Layer address can be ke pt in the neighbor cache for relatively long time. DAD mechanism can be used for DoS attack. Attacking node answers to every DAD attempt. No host will be able to obtain an address.
Neighbor cache table overl oad. The attacker ove rloads the neighbor cache tab le with many records for non existing clients. The attacking node can also send fake Router Advertisements or functions as a fake DHCPv6 server. To prevent against such attacks, an unwanted traffic must be bl ock on access ports. Today, this can be si mply done by a n access control list. The new solution of the pre vention against the fake Router Advertisements brings a RA-Guard (IPv6 Router Advertisement Guard) that is described in RFC 6105. The RA Guard feature restricts th e ports that can accept Router Advertisements. For example, the RA-Guard function will be implemented in a next version of firmware K.15.07 for HP (Hewlett-Packard) routing switches. Additionally, this firmware will g ive possibility to block ICMPv6 Redirect messages on th e configured ports. Future complex solution solving rouge Router Advertisements, DHCPv4 and DHCPv6 can be S AVI (Source Address Validation Improvement). Today, SAVI is a group of drafts and it is not possible to buy any device supporting this type of the protection. 9. IDUSTRIAL IPv6 APPLICATIONS The IPv6 protocol makes possible to communicate without NAT in the whole Internet. Many embedded systems can provide server functions more simply. This is u seful for intelligent transportation systems, building environment managements, smart home security systems and many others. The big IPv6 addres sing space is i nteresting for sensor network technologies including wireless sensor networks. The IPv6 protocol can also provide autoconfiguration via the IPv6 neighbor discovery and SLAA C features and provides support for network mobility to large sensor networks. To create IPv6-enabled sensor network requires appropriate inter-working between the IPv6 layer and the link layer. The IPv6 operation must be specified for e very specific sensor link technology. RFC 4944 specifies IPv6 operation over IEEE 802.15.4 networks. R FC 6282, which updates RFC 4944, specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). Bluetooth devices can al so support the IPv6 protocol. The IPv6 packet is encapsulated by Bluetooth Network Encapsulation Protocol (BNEP) and pass on the Logical Link Control and Adaptation Protocol (L2CAP) layer of Bluetooth stack. 10. CONCLUSIONS The practice shows that the transition to the IPv6 protocol is more complicated and slower then was supposed. It is evident that Internet Transition Plan (RFC 5211) was unrealistic.
The state of global IPv6 deployment was app roximately the following in 2011: 39% of the Internet’s transit networks appear to be dual stack capable and about 50% of the Internet’s end devices have the installed IPv6 stack but only 0.4% of the Internet’s end devices have the native IPv6 connection. It is clear that th e main problem of sl ow IPv6 deployment is on the side of access providers of the end use r connection. This problem is mainly economical not technical. Small business pressure was on IPv6 deployment. The situation will probably move forward in 2012. Major Internet service provider, home networking equipment manufacturers and web companies around the world have announced at beginning 2012 that they are coming together to permanently enable IPv6 for their products and services by 6 June 2012. It can be supposed that a massive availability of IPv6 protocol will in crease the pressure to resolve live technical problems as security or the automatic configuration. REFERENCES Microsoft Corporation. (2008). Introduction to IP version 6. Microsoft Corporation. Satrapa, P., (2011). Internetový protokol verze 6. CESNET, z. s. p. o., Praha.