Presentation: Download presentation (ppt)

URL: https://events.nordu.net/display/ndn2012web/Security+challenges+in+IPv6+from+the+campus+perspective

Videos used in presentation:

• IPv6 RA flood DoS attack in Windows 8
• The Man-in-the-middle Attack Using IPv6

IPv6, security, campus network, transition

1. Introduction

The idea of IPv6 deployment proposed by RFC 5211 [1] expected that the Internet would be fully migrated to IPv6 in these days. Unfortunately, it seems that all deployment strategies defined in either political [2],[3] or technical documents were too optimistic. IANA IPv4 address pool is already depleted, more than 10% autonomous systems (AS) announces IPv6 prefix in global BGP table [4] and most of operating systems support IPv6. However, the content providers still indicate that less than 0.5% [5] of clients is being able to use IPv6 connectivity. What is worse, there are statistics showing that IPv6 connectivity in some networks might be broken or less stable comparing to IPv4 [6]. As the result, most of content providers are afraid to announce IPv6 for their services in fear of losing customers.

Observing the global IPv6 infrastructure and deployment, we believe there are no significant problems to have a good IPv6 connectivity for servers in data centers. Many transport networks can deliver IPv6 traffic today as well. We believe that the key problem of the low IPv6 penetration is on the side of ISPs providing last mile to customers. ISP must ensure a positive user experience, thus if the IPv6 is deployed, it is important that the deployment is secure and a service quality is the same as in IPv4 network. Unfortunately, there are not many devices able to implement IPv6 first hop security that is equivalent to IPv4 security. Ordinary user does not care about protocol used for connection, but does care if the connection is broken or unstable, which is sometimes a problem with IPv6 connection.

This article comprises experience with deploying IPv6 at the campus network at the Brno University of Technology (BUT) which is one of the biggest universities in the Czech Republic. Currently, the core of the network has fully enabled support for the dual-stack and the IPv6 network completely follows topology of IPv4 network. University also has own provider independent (PI) IPv6 address space to be able to use multihomed IPv6 connections in future. The university campus network connects more than 2,500 staff users and more than 23,000 students. The top utilization is present at student dormitories where more than 6,000 students are connected via 100 Mb/s and l Gb/s links.

In the following sections we will describe the most significant issues that we have been faced with during the deployment of IPv6 protocol in the campus network. The deployment started at the university in 2002. At the beginning, the experimental network on dedicated devices and links was created. Currently, the IPv6 and IPv4 share the same infrastructure that is operated as a dualstack network. Most of the network services support both protocols. However, the process of transition to IPv6 at the university has not been finished yet, and it would take a lot of time and effort to move all services to IPv6 with the equivalent stability and reliability as we have in IPv4.

2. Addressing issues

One of the main issues is address assignment for clients. The mixture of various OSs in a network requires automatic address assignment that is supported by most of the systems. Assigning addresses with a DHCP server became de-facto standard for IPv4. However, DHCPv6 protocol is different.

DHCPv6 features two basic modes. In practice, the first mode, stateless DHCPv6, is a layer on top of the autoconfiguration mechanism (SLAAC) and is used to provide recursive DNS server addresses. Two special flags are used for this purpose in the Router advertisement (RA) message: M – managed, O – other. These flags tell the client that it should ask a DHCPv6 server for more information related to the connection parameters. If the M flag is set, statefull DHCPv6 is used. If the O flag is set, SLAAC will be combined with stateless DHCPv6. The strong binding between SLAAC and DHCPv6 brings several problems.

• It is not possible to pass all necessary configuration options (e.g. option for default route) via DHCPv6 server. Authors of DHCPv6 protocol stated that because SLAAC has to be used anyway, default route is not necessary – client learns a default route from RA message. However, this forces to use both autoconfiguration mechanisms together and increases the complexity.
• When a client sees an RA with M flag on, a client sends a DHCPv6 Solicit message looking for a DHCPv6 server. A DHCPv6 server responds with appropriate configuration for the client. However, if the client has a DHCPv6 derived address, and receives an RA with M flag off, the client will release that DHCPv6 derived address. Unfortunately, RA messages can be easily spoofed so the attacker can force all clients in a local network to release their IPv6 addresses just with one packet. This can be solved by proper filtering on access layer; however this is sometimes a problem. The filtering possibilities are discussed later in the paper.

Using DHCPv6, we do not get the same results as with DHCPv4 server (MAC to IPv6 address binding).
DHCPv6 does not use a MAC address to identify the client; instead, it uses a specially created unique identifier called a DUID (DHCP Unique Identifier). The main idea behind this identifier is to release the clients from dependence on hardware and on a specific network interface. The advantage is that a change of a network adapter or a connection through another interface (such as WiFi instead of Ethernet) would mean that the user always obtain same IPv6 address. Unfortunately, there are several issues connected with the DUID identifier.

• DUID is controlled by software, thus it is not as stable as it should. E.g., if the client has dual boot, every OS will have different DUID.
• DUID is changed, after OS is reinstalled.
• If the administrator clones an OS image and copy it to another computer, two computers will have the same DUID.
• It is impossible to tie DUID with the host identification that is used in DHCP(v4) – host’s MAC address which complicates assigning address especially in a dualstack environment. Solution is either to extend existing systems for address management to support DUIDs or to use workarounds like MAC address option specified in RFC 6221. Unfortunately, vendors have not included the support for the RFC 6221 yet.

Moreover, statefull autoconfiguration using DHCPv6 is very difficult to be used today because of lack of support on many platforms including Windows XP, which is still very widespread OS. Most of mobile devices has not implemented support for DHCPv6 yet and some OSs (e.g. MAC OSX) must be updated to the latest version, which is a problem if the devices are not managed by an ISP.

The operational experience shows that according to these issues, the DHCPv6 protocol and its implementations are still not mature enough to be used in a production network and moreover, it is not feasible to use it for address assignment in networks where the hosts’ identification is required.

Another choice for address assignment available in IPv6 is to use the stateless utoconfiguration (SLAAC). Unfortunately, the stateless autoconfiguration in some OSs turns on privacy extensions. This means that devices generate a random end user identifier (EUI) – temporary IPv6 Address. This is a brand new IPv6 feature that allows a node to automatically generate a random IPv6 address on its own without the control of a network administrator.

However, this contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This prevents logging and tracking users based on IPv6 address. However, the knowledge of relation between an address and a device (or user) that has been used is necessary for solving security incidents and is required by law in several countries.
The Table 1 summarizes the autoconfiguration techniques in IPv6 protocol.

If a security policy requires better control, either fixed IPv6 addresses must be centrally assigned and logged, which is not a feasible option for a large network, or statefull configuration using DHCPv6 has to be deployed. Before the deployment of IPv6 in a local network, a network administrator must decide whether:

• Addresses will be assigned by DHCPv6 – the advantage is better control over hosts with, but many devices will not be able to use IPv6.
• Hosts will create own address based on SLAAC – all hosts will be able to use IPv6, but an administrator either gives up to have control over user identification in the network or a new mechanism must be deployed to identify the users [21]. Example of our implementation is described later on.

The Table 2 summarizes the IPv6 autoconfiguration support among the OSs.

First hop security in IPv4

IP address autoconfiguration process might be perceived as a honey pot for a hacker. If the hacker is able to interfere the configuration process, the whole user’s traffic can be rerouted to the attacker’s PC. In many cases it does not need to be a targeted attack, but simply an accident, where a user connects a Wi-Fi router with a preconfigured DHCP server to the network and causes a network malfunction for other users. This problem, as the other problems with first hop security, is known in IPv4 world for quite long time. For this reason some mechanisms were created in the IPv4 world which would prevent or at least complicate some of these attacks. The best place to implement protection for end users is on the end-user switch access port that the user is connected to. Different vendors use slightly different terminology for individual types of protection but generally we can meet the following ones:

DHCP Snooping: Some ports are explicitly defined in the switch configuration so port is able to receive DHCP responses from DHCP (so called trusted port). It is assumed that somewhere behind the trusted port is a DHCP server. If a reply from a DHCP server arrives to a port not defined as trusted, the response is discarded. Any DHCP server running on the client system (whether intentionally or by accident) does not threaten other clients on the network because the answers will not reach further than the access port for which this protection has been activated. DHCP snooping is usually prerequisite for other protection mechanisms such as IP lockdown or ARP protection as described below.

Dynamic ARP protection, ARP inspection: DHCP snooping database contains MAC address – IP address – switch port combination. This database is then used on untrusted ports to inspect ARP packets. Other MAC addresses not recorded in the database are discarded. This eliminates attacks focused on creating fake records in the ARP table (poisoned ARP cache). Another often-appreciated feature of this mechanism is the fact that the client cannot communicate over the network unless an IP address from the DHCP server is obtained. That forces
user to use DHCP instead of configuring static address.

Dynamic IP Lockdown, IP source guard: Another degree of protection is achieved by inspecting source MAC and IPv4 address on untrusted ports for all packets entering the port. This eliminates spoofing a source IPv4 or MAC address.

The Table 3 describes different attacks and techniques available for mitigating the attacks in IPv4 network.

3. First hop security in IPv6

The above described solutions for mitigating attacks in IPv4 networks are implemented in various access switches on the market. As we wrote previously, the autoconfiguration techniques are different in IPv6 so new solutions are necessary. Security mitigation techniques in IPv6 networks are described below.

Source Address Validation Improvements (SAVI): The set of techniques that complement ingress filtering with finer-grained, standardized IP source address validation [11]. Framework has option for DHCP servers and tries to solve a mechanism similar to the one we described with DHCP snooping for IPv4. It is limited to DHCPv4 and DHCPv6 and does not deal with the problems of rogue Router Advertisement messages. SAVI is mainly supported in devices produced by Hewlett Packard – A series. Very similar technique called ND
inspection is implemented in Cisco devices.

Secure Network Discovery (SEND): This method tries to deal with autoconfiguration problem in a totally different way. SEND is based on signing packets with cryptographic methods [15]. Apart from a router it does not require support on the access switches. The validity verification itself through message certificate takes place at the end-user system. IPv6 address of the end-user system is a result of a cryptographic function (see, we have another auto configuration method). Using SEND directly excludes using static, EUI 64 and Privacy Extensions Address. However SEND provides great advantage – it not only solves the autoconfiguration problem but also other safety problems of the Network Discovery protocol (RFC 2461). Another advantage is independent infrastructure; hence it can also be used in the same way in the either wired or Wi-Fi networks.

The main shortcoming of SEND is the requirement for public key infrastructure according to X.509. To make the SEND works properly, a certificate of the certification authority have to be installed on each client that wants to use SEND. The certificate has to be issued for each router as well. So it grows the costs of the management of the network – certificates have to be reissued or replaced before they expire.

SEND is a patented Cisco technology (US patent number 20080307), therefore no one would be surprised that it is implemented especially on some devices of this company. Presence of the patent raised several discussions especially with SEND and RA Guard integration. According to Cisco statement, Cisco will however not assert any patents against any party that implements the standard [17].

Considering the SEND deployment, a network administrator will face the problem that the protocol is not supported on any operation system yet. There are only some basic Linux and Windows implementations; however thay cannot be used in a production environment. Windows OS, as the most widespread system, nor Mac OS do not support the SEND protocol even in the most recent versions. SEND protocol could potentially solve security problems of NDP protocol; however, it cannot be deployed and there are no indications that this should change in the near future.

Router Advertisement Guard (RA Guard): Another alternative, which unfortunately deals only with the issue of fake router advertisements, is IPv6 Router Advertisement Guard [9]. It is similar technique as DHCP snooping, but determined for Router Advertisement packets. It tries to block fake router advertisements on an access user port. Apart from tools that should ease the initial switch configuration (learning mode), it opens the
path to integration with SEND. In this mode the switch works as a so called node-in-the-middle, where the switch with activated RA Guard uses information from SEND to verify packet validity and for the connected end-user system it appears as normal Router Advertisement packet. As you could guess from the title RA Guard does not solve DHCP or DHCPv6 issues in any way. We can already find an implementation in some Cisco devices.

Access Lists on the switch (ACL/PACL): If a network device supports ACL or PACL (Port access list) it is possible to configure an ACL blocking the malevolent traffic. A network administrator can configure ACL that will block all ICMPv6 messages type 134 (RA messages) and also block traffic to the UDP target port 546 (dhcpv6-c1ient). The rules are subsequently applied to the inputs of ports to which the c1ients are connected. This can eliminate instances of rogue routers and DHCPv6 servers. A required condition to use this mechanism is IPv6 ACL support on the relevant switch. The problem of this solution is that very few access switches
supports creation of IPv6 access-lists today. Also price of that switches is usually two or three times higher comparing to the switches where IPv6 PACL and other IPv6 security features are not implemented.

The solution with RA-Guard and ACL/PACL has however big disadvantage. It works very well for accidently announced RA messages but can be easily avoided using combination of fragmented packets and extension header in the RA message [18]. Existing protection for the targeted IPv6 attack does not exist today. There are some proposed solutions how to solve the problem [19],[20], but all of them are only drafts and it will take a long time before support will be added to operating systems and network devices.

The most undesired option is blocking or disabling whole IPv6 traffic. It is obvious that this step protect a host against all attack related to IPv6, however it is against the idea of deploying IPv6. That solution can be used only as a short-term solution when the other possibilities are not available. IPv6 protocol can be suppressed on the client by disabling o uninstalling IPv6 protocol or blocking the whole IPv6 traffic on the access port by filtering out all Ethernet packets identified with Ether Type 0x86DD (Ether type for IPv6 protocol).

The Table 4 summarizes first hop security threads and protection in IPv6 network.

4. First hop security in IPv6 – current situation

Thinking about IPv6 deployment and security, network administrators will face the fact, that all of the above mentioned techniques can be used rather theoretically today. Either they are not implemented on client’s side or device support is missing. Another issue is that if the protective devices are to be truly purposeful they must be placed as close to the end-user system as possible. This could often mean a complete replacement of network infrastructure that is a job that few will want afford just to implement IPv6.

To summarize our experience, after two years of operating the IPv6 network in production environment and several more years of testing the IPv6 protocol, we did not observe a targeted attack to our IPv6 network. The main problems, we have to solve are above described problems with autoconfiguration, bogus router advertisements together with missing monitoring tools for IPv6 network.

Many rogue advertises are generated by Windows computers. This is a serious issue because computers propagate their own interface as a default gateway. Unfortunately this behaviour can be in some conditions caused by properly used Internet connection sharing service. The Figure 1 shows the number of rogue advertises on the network with approximately 2000 of connected hosts.

As we mentioned earlier, because of missing implementation of mitigation techniques on switches, more affordable solution that would at least alleviate efforts to paralyze the IPv6 autoconfiguration mechanism is detection of fake Router Advertisements. This will not protect the network from a well-crafted and targeted attack but it can at least detect incorrectly configured c1ients. For many networks it would be the only usable solutions for a long time. All tools for detection of rogue Router Advertisements work based on the same principle. They connect to the FF02::1 multicast group where the router advertises messages are sent and thus are
able to monitor all RA messages appearing on the network. The monitoring tool can then inform the
administrator about the undesirable status, call an automated action (Ndpmon [22], Ramond [23]), or even send a message cancelling the validity of fake Router Advertisements (rafixd [24]).

5. User tracking, monitoring and accounting

Long-term network monitoring, accounting and backtracking of security incidents is often achieved in IPv4 networks using NetFlow probes and collectors. This can be a problem if IPv6 is deployed and privacy extensions are allowed in the network. The same user can than communicate with different addresses. That means that address cannot be used as a unique identifier anymore. As the part of deploying IPv6 we tried to develop extension to existing monitoring systems to allow easier tracking users in an IPv6 network.

The main idea of the extension is collecting and putting together data obtained from differed parts of the network. A neighbour cache database on routers and forwarding databases on switches can provide information about relation between an IPv6 address port on a switch and a MAC address used by a user. In the next step the MAC address can be used for identifying a user in a database provided by radius server.

These pieces of information, together, provide a complex view of the network and can help to identify a host. A tuple (lPv6 address, MAC address, Login name) is sufficient to identify a host/user. In practice, an extended tuple is built: (Timestamp, IPv6 address, MAC address, Switch port, Login) as depicted in the following Figure 2.

Timestamp is added to provide a history of communication. Switch port is necessary if the user is blocked or if an unregistered MAC address is used on a port. In addition to these values, the VLAN number and interface statistics are stored; however, these data are not necessary for host identification.

It is important to note that this data structure is not created at once, but it is filled in when data are available. For instance, NetFlow data are taken from the NetFlow probe when they are sent to the collector. However, there is no information about MAC addresses yet. The address is downloaded later from the switch’s ND cache. Login data from RADIUS can also be added. However, RADIUS data are not available for every user – only for those who are connected using 802.1x authentication. For other users, only the IPv6 address and the switch port number and MAC address are used for identification.

Data are collected using the SNMP protocol and stored in the central database where the network administrator can search data using the IPv6, IPv4 or MAC addresses as keys. Useful tool for polling and storing information from switches and routers is Network Administration Visualized (NAV) [12]. SNMP polls the data from switches every fifteen minutes. The mapping between the IPv6 address and its corresponding MAC address is downloaded from the router’s neighbour cache. Port, VLAN number and other information comes from the switch’s FDB (Forwarding Database) table. Traffic statistics are obtained from NetFlow. NetFflow records alone
are not sufficient for user surveillance and activity tracking because of the temporary IPv6 addresses as described in previous sections.

The time dependency of gathering different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system. Typical timeouts for collecting
SNMP and RADIUS data are fifteen minutes. The ND Cache expiration timeout is usually set to more than one hour.

6. Conclusion

This paper presents security and addressing issues in IPv4 and IPv6 protocol environment and solutions how to solve them. Nowadays, the IPv6 traffic volume is low, but this is caused by the lack of IPv6 sources (web pages, servers) on the Internet. Also widespread operation systems such as Windows XP support IPv6 but IPv6 is not enabled by default.

Next generation Windows systems together with Linux, Mac OS and Unix systems have however IPv6 protocol enabled by default and penetration of these systems is growing every day. Security and addressing issues discussed in this paper present the overview of problems we encountered when we deployed IPv6 protocol in BUT campus network. Addressing issues and problems with user tracking in IPv6 protocol introduce the necessity for a new monitoring system that is able to overcome the specific problems in IPv6 address assignment. Solutions, how to solve these issues, are proposed. We discussed possibilities, how we are able to limit the impact of security problems in IPv6 network together with monitoring and tracking system that is able to identify and track a host in IPv4 and IPv6 network.

References

[1] J. Curran: An Internet Transition Plan, [online], url: http://tools.ietf.org/html/rfc5211

[2] Commission of the European Communities: Action Plan for the deployment of Internet Protocol version
6 (IPv6) in Europe, [online], url: http://ec.europa.eu/information_society/policy/ipv6/action_plan/

[3] Transition Planning for Internet Protocol Version 6 (IPv6), [online],
url: http://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2005/m05-22.pdf

[4] IPv6 CIDR REPORT, [online],
url: http://www.cidr-report.org/v6/as2.0/, http://bgp.potaroo.net/index-bgp.html

[5] Lorenzo Colitti, Steinar H. Gunderson, Erik Kline, Tiziana Refice, Evaluating IPv6 Adoption in the
Internet, [online], url: http://www.google.com/intl/en/ipv6/statistics/

[6] Geoff Huston: Flailing IPv6, [online], url: http://www.potaroo.net/ispcol/2010-12/6to4fail.html

[7] S.Thomson, T.Narten, and T.Jinmei. IPv6 Stateless Address Autoconfiguration. RFC 4862, September
2007, [online], url: http://tools.ietf.org/html/rfc4862

[8] J. Curran: An Internet Transition Pian, RFC 5211, July 2008, url: http://tools.ietf.org/html/rfc5211

[9] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi: IPv6 Router Advertisement Guard, RFC
6105, February 2011, [online], url: http://tools.ietf.org/html/rfc6105

[10] S. Frankel, R. Graveman, and J. Pearce. Guidelines for the Secure Deployment of IPv6. Technical
Report 800-119, National Institute of Standards and Technology, 2010, [online],
url: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

[11] J. Bi, J. Wu, G. Yao, F. Baker: SAVI Solution for DHCP (work in progress) July 2011, [online], url: http://tools.ietf.org/html/draft-ietf-savidhcp-10

[12] UNINETT and Norwegian University of Science and Technology: NAV, [online], 2011-03-15,
[online], url: http://metanav.uninett.no/

[13] J. Bi, G. Yao, J. Wu, F. Baker.: Savi solution for Stateless Address – work in progress, April 2010,
[online], url: http://tools.ietf.org/html/draft-bi-savi-stateless-00

[14] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi.: IPv6 Router Advertisement Guard.
RFC 6105, February 2011. [online], url: http://tools.ietf.org/html/rfc6105

[15] J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander: SEcure Neighbor Discovery (SEND). RFC 3971,
Febuary 2011, [online], url: http://tools.ietf.org/html/rfc3971

[16] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogl: Source Address Validation Improvement
Framework”, draft-ietf-saviframework-04 (work in progress), March 2011.

[17] R. Albright, Cisco System’s Statement of IPR related to draft-ietf-v60ps-ra-guard-02, April 2009,
[online], url: http://www.ietf.org/ietfftpIlPR/cisco-ipr-draft-ietf-v60ps-ra-guard-02.txt

[18] F. Gont, IPv6 Router Advertisement Guard (RA-Guard) Evasion, December 2011, [online], url: http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-evasion-01

[19] F. Gont, Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard), Febuary 2012,
[online], url: http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation-01

[20] F. Gont, Security Implications of the Use of IPv6 Extension Headers with IPv6, January 2012,
[online], url: http://tools.ietf.org/html/draft-gont-6man-nd-extension-headers-02

[21] Grégr, M., Podermański, T., Šoltés, M., Žádník, M.: Design of Data Retention System in IPv6 network,
December 2011, [online],http://www.fit.vutbr.cz/~igregr/pubs.php?id=9840

[22] Frederic Beck, Ndpmon, August 2009, [online], url: http://ndpmon.sourceforge.net/

[23] Ramond, [online], url: http://ramond.sourceforge.net/

[24] Rafixd, [online], url: https://github.com/strattg/rafixd

[25] Tony Cheneau, Ndprotector, March 2012, [online], http://amnesiak.org/NDprotector/

[26] Meinel Ch.: Winsend, March 2012, [online],
url: http://www.hpi.uni-potsdam.de/meinel/forschung/security_engineering/ipv6_security/winsend.html

IPv4 address configuration is mainly based on two methods. Manual address configuration or dynamical configuration via DHCPv4 server. Dynamic configuration via DHCPv4 became the de-facto standard for IPv4 address assignement. Network administrator usually bounds user’s MAC address (network-card link-address) to user’s IPv4 address in DHCPv4 server configuration. The IPv4 address is than assigned by DHCPv4 server to the user with corresponding MAC address. This allows to the administrator to track malevolent users because there is knowledge which IP address belongs to which MAC address and thus the user. This basically means, that the IPv4 address uniquely identify a user.

IPv6 (Internet Protocol version 6) is a new version of the fundamental Internet Protocol. IPv6 support is available for all operating systems such as Unix, Mac OS, Windows and usually enabled by default. However, address assignement in IPv6 networks is different. New concepts – autoconfiguration, multiple IPv6 addresses per interface or temporary IPv6 addresses introduce new challenges for users’ identification. In IPv6 networks, IPv6 address no longer identifies a user.

The following sections describe the address configuration process in IPv6 networks and problems connected with user identification.

2. Autoconfiguration and temporary addresses

The original idea of autoconfiguration was based on the notion of an IPv6 device connecting to a network and autoconfiguring everything automatically, without requiring any interaction from the user. Similar idea exists also in IPv4 network [1], however was not widely deployed.

Stateless Address Autoconfiguration (SLAAC) [2] can be described in simple terms. The network router tells all the connected nodes in a network segment what network they appear in, and what router they should use for packets travelling to the Internet (message RA – Router Advertisement). Of course, announcing alone would not be flexible enough. Hence, a newly connected device may send a request to the network (message RS – Router Solicitation) asking for information about what network it is in, and what is the way out. The whole autoconfiguration mechanism is a part of Neighbor Discovery for IPv6 [4], and all communication takes place using the ICMPv6 protocol. End nodes now have information, which network prefix should they used and how to route packets. However, this information is insufficient. The host still needs to know, how to create a host part (end user identifier) of his IPv6 address. The host part of the IPv6 address can be derived from information that the host already has, such as, a network-card link-address. This creates a mechanism to define the host part of the network address via a modified EUI 64 algorithm.

Because of user privacy, IPv6 addresses with randomly generated 64-bits interface identifiers are preferred instead of IEEE EUI-64. The RFC 4941 standard [3] defines a way to generate and change temporary addresses. The important requirement is that the sequence of temporarily generated addresses on the interface must be totally unpredictable. However, this requirement contradicts the need to identify a malevolent user in local networks. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This affects logging and prevents administrators from effectively tracking which users are accessing what services. Figure 1 shows addresses used by one computer during one week. The computer communicates usually by more than one IP address at the same time.

Another problem connected with IPv6 address autoconfiguration is lack of necessary information providing to clients. In order to have complete communication in the network, other details are required, such as, the IPv6 addresses of recursive DNS servers. However, this information is not in the Router Advertisement. In practice, the efforts to resolve this problem have taken three different routes.

Figure 1: Addresses used by one computer during one week

Adding recursive DNS server information to the information transmitted within SLAAC. The standard suggests the addition of two items to Router Advertisement messages, namely recursive DNS server addresses and Domain Search List. So far, this support has been implemented in the RA daemon tool for Linux/UNIX (radvd), but it is not supported in other current systems – both routers and client systems. At the moment, it is very difficult to estimate how willing manufacturers would be to implement this extension to their systems. SLAAC is usually processed at the OS kernel level, and expansion to other items would necessarily mean changing it directly. We probably cannot expect support for this addition during a normal update.

Using anycast addresses for recursive DNS servers. The client would send the translation request to this anycast address and the nearest Recursive DNS Server would provide an answer. Because the specification used Site-Local addresses, which were deprecated by RFC 3879 in 2004, this proposal was abandoned. An implementation can be found on Microsoft systems.

Using different protocol. A third proposed solution was the transmission of Recursive DNS Server addresses, and perhaps other parameters, with a different protocol, independent of the SLAAC mechanism. Quite logically, there is an opportunity to use something already known, and that is DHCP.

3. DHCPv6

Assigning addresses with a DHCP server became the de-facto standard for IPv4. There has been an effort to re-use this mechanism in the IPv6 world. However, contrary to what one might expect, DHCPv6 is not merely DHCP that has been adapted to IPv6, with mostly the same functions.

DHCPv6 features two basic modes. In practice, the first mode, Stateless DHCPv6, is only a layer on top of the autoconfiguration mechanism described above (SLAAC) and is used to provide only recursive DNS server addresses. Two special flags are used for this purpose in the router advertisement: M – managed, O – other. These tell the client that it should ask in the relevant network for more information related to the connection parameters, through DHCPv6. If the M flag is set, stateful DHCPv6 is used. If the O flag is set, SLAAC will most likely be combined with stateless DHCPv6. If both flags are reset, the end-user stations know that there is no DHCPv6 server available in the network.

The behaviour of stateful DHCPv6 is more like the behaviour of DHCP that is known from IPv4. The server assigns an address to the client for a definite period, and the assignment is confirmed. It would seem that the SLAAC mechanism could be completely de-activated, and everything would depend on DHCPv6 alone. This idea is certainly right – except for one detail. All of the required parameters can be transferred through DHCPv6 except the most important one, which is the default gateway. The client expects to receive this information only via the Router Advertisement. This means that the client can create “uncontrolled” addresses, either with EUI 64 or Privacy Extensions. This behaviour could be suppressed by setting (or resetting) the Autonomous option in the Router Advertisements.

If an administrator decides to assign addresses through DHCPv6 and would like to use same functionality as with DHCPv4 server (MAC to IPv6 address binding) he faces to a problem. DHCPv6 does not use a MAC address to identify the client; instead, it uses a specially created unique identifier called a DUID (DHCP Unique Identifier) [5]. The main idea behind creating such an identifier is to free the clients from dependence on hardware and on a specific network interface. The advantage is that a change of network adapter or a connection through another interface (such as WiFi instead of Ethernet) would not mean that the end-user station would start to behave as “someone else”. The standard defines three ways to obtain a DUID. The creator of the DHCPv6 client decides which one he chooses to use. In practice, this means that each system creates a DUID in a different way. If a PC has multiboot, with more than one operating system, then each system will have a different DUID. Most likely, the DUID will also change after reinstallation of the operating system. To use DHCPv6 in a network, while retaining a sufficient overview of who has which address, there is no other solution than to create completely different mechanisms and methods to register clients and end-user stations.

4. User identification and long term monitoring

Long-term network monitoring, accounting and backtracking of security incidents is often achieved in IPv4 networks using NetFlow probes and collectors. This can be a problem if IPv6 is deployed and privacy extensions are allowed in the network. Same user can than communicate with different addresses. That means that address cannot be used as a unique identifier anymore. As the part of deploying IPv6 we tried to develop extension to existing monitoring systems to allow easier tracking users in an IPv6 network.

The main idea of the extension is collecting and putting together data obtained from differed parts of the network. A neighbor cache database on routers and forwarding databases on switches can provide to us information about relation between IPv6 address port on switch and a MAC address used by user. In the next step a MAC address can be used for identifying user in the database provided by radius server. All of these pieces of information, together, provide a complex view of the network and can help to identify a host. A tuple (IPv6 address, MAC address, Login name) is sufficient to identify a host/user. In practice, an extended tuple is built: (Timestamp, IPv6 address, MAC address, Switch port, Login) Timestamp is added to provide a history of communication. Switch port is necessary if the user is blocked or if an unregistered MAC address is used on some port. In addition to these values, the VLAN number and interface statistics are stored; however, these data are not necessary for host identification. Data are collected using the SNMP protocol and stored in the central database where the network administrator can search data using the IPv6, IPv4 or MAC addresses as keys.

The time dependency of the gathering of different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system.

5. Conclusion

The IPv6 autoconfiguration options are not straightforward. There are two different sets of mechanisms and protocols, and one cannot work effectively without the other. Currently, it is not possible to configure Recursive DNS Servers addresses with SLAAC, but with DHCPv6 it is not possible to configure the default gateway address. As a result, the only working method is to use both protocols. Failure of either mechanism, whether through faulty configuration, poorly debugged software or targeted attacks, leads to denial of the communication for the end-node, and thus, for the user. Moreover, diagnostics are fairly complicated in this situation and require a good understanding of the way both mechanisms work. These problems, together with lack of security mechanism are probably also the reason, why the IPv6 is still not widely deployed. ISP will not deploy a new protocol which allows to an attacker to restrict the connectivity to the ISP‘s customers. Even though that IPv4 and IPv6 protocols are incompatible, when both protocols are deployed, inproper functionality of IPv6 would have also an impact to IPv4 connections – e.g. long delay when a user is accessing a website. Unfortunately, considering the standartization process in IETF, it does not look like, there will be any changes in the near future.

6. Acknowledgement

This work is part of the project VG20102015022 supported by Ministry of the Interior of the Czech Republic and was partially supported by the research plan MSM0021630528.

Bibliography

[1] Deering, S. ICMP Router Discovery Messages. 1991. http://tools.ietf.org/html/rfc1256

[2] Thomson S., Narten T., Jinmei T. IPv6 Stateless Address Autoconfiguration. 2007. [online] url: http://tools.ietf.org/html/rfc4862

[3] Narten, T., Draves, R. and Krishnan, S. RFC 4941 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6. [online] 2007. url: http://tools.ietf.org/html/rfc4941

[4] Narten, T., Nordmark E., Simpson W., and Soliman H. Neighbor Discovery for IP version 6 (IPv6). RFC 4861, September 2007. url: http://tools.ietf.org/html/rfc4861

[5] R.Droms, J.Bound, B.Volz, T.Lemon, and C.Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . RFC 3315, July 2003. url: http://tools.ietf.org/html/rfc3315

Data retention system generally allows a network operator or law enforcement agencies to track malevolent users or security incidents. The network data retention system, especially in large networks, has to be able to handle a significant volume of data. Storing the network traffic itself is not a feasible option due to limited storage capacity and speed. Therefore the system is usually based on some form of flow monitoring – e.g. NetFlow. NetFlow data provides necessary information for data retention – source, destination, duration and type of communication together with amount of transferred data. However, are NetFlow data sufficient for the data retention system, if IPv6 protocol is deployed in the network?

The IPv6 protocol creates new challenges. Unlike IPv4, an IPv6 address no longer identifies a user or PC uniquely, because an IPv6 address can be randomly generated and keeps changing. This document discusses general specification of data retention system according to ETSI TS 102 657 [2] document and address the major monitoring issues of IPv6 connectivity. A practical solution for monitoring both IPv4 and IPv6 traffic is proposed. The proposed data retention system is able to monitor and identify a user in both IPv4 and IPv6 traffic. The solution requires an extension of the monitoring data collected from network devices. A new data structure based on extension of NetFlow records is presented. Data retention system is deployed at the Brno University of Technology (BUT) campus network. The document discusses the results of data retention traffic monitoring and future challenges.

2 IPv6 and user identification

Many internal resources require the ability to track the end user’s use of services. IPv6 address tracking (or data retention) is also a legal obligation of ISPs required by governments. If a local security policy requires better control, either fixed IPv6 addresses must be centrally assigned and logged, or stateless configuration using DHCPv6 has to be deployed. If stateless auto-configuration is deployed, a new monitoring system is required.

Temporary IPv6 Addresses: Auto-configuration is a new IPv6 feature that allows a node to automatically generate an IPv6 address on its own. This behavior is different from IPv4 address configuration, in which the IP address is configured either manually or using DHCP. An IPv6 node can be configured through either stateless or stateful auto-configuration. The basic stateless configuration combines a network prefix obtained from the router with the IEEE EUI-64 identifier based on the MAC address. This allows keeping the link between an address and user/host, but the host part of the address can easily be tracked all over the Internet.

Because of user privacy, IPv6 addresses with randomly generated 64-bits interface identifiers are preferred instead of IEEE EUI-64. The RFC 4941 standard defines a way to generate and change temporary addresses. The important requirement is that the sequence of temporarily generated addresses on the interface must be totally unpredictable.

However, this requirement contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This affects logging and prevents administrators from effectively tracking which users are accessing what services.

Stateful IPv6 configuration: The DHCP Unique Identifier (DUID) can be used to identify a user in an IPv6 network. However, DUID has several disadvantages. Its value is not easily searchable, since every client stores its values at different places on the local disk. The value is changed whenever the operating system is reinstalled. Experience at BUT shows that using stateful configuration for address assignment is extremely difficult. First of all, even if an IPv6 address is assigned to a host with Windows 7 or Vista using DHCPv6, the host will not use this address for communication but will use a temporary address instead. Secondly, the DHCPv6-client is not supported in Windows XP, which is still widely in use.

Stateless IPv6 configuration: The first part of the IPv6 address – the network prefix – is assigned using RA messages as described in the previous chapter. RA messages do not provide any type of unique identifiers that could be used to identify the host. The second part of the IPv6 address – the interface ID – is generated using EUI-64 or privacy extensions. EUI-64 could be used for host identification since its value is derived from the MAC address. However, Windows 7 and Vista use randomly generated interface ID’s instead, by default. Thus, neither stateful nor stateless configuration provides the unique ID needed for user identification. More information has to be obtained, as discussed in the following section.

3 Proposed architecture

The proposed architecture follows the standard defined in ETSI document TS 102 657 [2]. Although the architecture of data retention system is only briefly described it provides high level overview of the whole system as well as it defines several basic building blocks.

At the top level ETSI defines two communicating entities, Communication Service Provides (CSP) and Authorized Organization (AO). ETSI suggests to establish two communication channels between AO and CSP as a Handover Interface (HI). The first channel (HI-A) delivers administrative request/response information whereas the second channel (HI-B) transfers only Retained Data (RD). Figure 1 displays this model.

Fig. 1. Model of CSP and AO Handover Interface (taken from [2])

The architecture and processes of AO are rather out of the scope of this document. We focus on breaking down the CSP block. Based on ETSI, three functional blocks can be identified within the CSP.

An administrative function (AF) implements both channels of HI and internal interface to acquire retained data from Data Store Management Function (DSMF). The task of AF is then to receive and acknowledge requests for RD, transform and issue these requests in a syntax of DSMF, report on the state of on-going queries and finally deliver the result of the queries as RD over HI-B.

A Data Collection Function collects data from the various internal network elements and prepare the data for retention. This includes both synchronous and asynchronous communication with probes, switches, routers, servers such as DHCP, DNS, RADIUS and user database.

Fig. 2. Break down of CSP function (taken from [2])

At last ETSI defines a data store management function. This process handles indexing and storing the data, executing queries and managing the maximum retention period.
Please note that the ETSI TS 102 657 states that the the decomposition of internal architecture is only informative and may vary according to specifics of the CSP. Moreover, it also allows for outsourcing some functions to a third party depending on the national agreement.

We propose a monitoring system that fits the needs of data retention in IPv6 network. It considers the various sources of collected data, their processing and storage as well as presentation interface. The architecture of the system is depicted in Figure 3.

The Figure displays a mapping of ETSI blocks on implementation primitives that are relevant for IPv4 and IPv6 network. Let’s start with description of DCF. There are three data sources of different type at the input of the system. The first data source constitutes NetFlow generated by probes and routers in the network. The NetFlow data are collected and stored. The second data source constitutes of SNMP which allows to transfer data from switches and routers. SNMP poll reads accessible variables in each device based on its MIB tree and stores this data in the database. The third source of data are event messages and logs of management servers such as RADIUS, DHCP. These data are parsed and extracted information is stored in database as well. The DSMF function joins the data in database with stored NetFlow data. A configuration interface allows to setup and control DCF and DSMF processes. A data interface handles queries on stored data generated by various applications among which belongs an AF function.

We propose to assemble several various tools to implement whole monitoring system according to the proposed architecture. In the following sections, we discuss the specifics of each data retention block and we describe how each block is implemented.

Fig. 3. Proposed architecture of monitoring system

3.1 Data Collection Function

A Data Collection Function collects data from the various internal network elements and prepare the data for retention. ETSI breaks down Collected data into following categories (for each category we list some data examples and their possible source within the scope of IP network).

1. Subscriber data: information relating to a subscription to a particular service (Data: Name, Address, Identifier; Source: User Database).
2. Usage data Information relating to usage of a particular service (Data: Flow Records, SIP records; Source: NetFlow, IPFIX, SIP proxy, …).
3. Equipment data: information relating to an end-user device or handset (Data: MAC address, OS; Source: Neighbor Cache/Forwarding table in switch, DHCP server, RADIUS server).
4. Network element data: information relating to a component in the underlying network infrastructure (Data: location and identifier of an access point, statistics from interfaces; Data: Network elements via SNMP).
5. Additional service usage: information relating to additional services used (Data: SMTP, IMAP; Source: Application servers).

DCF must be able to collect data via various interfaces and protocols such as syslog, SNMP, NetFlow/IPFIX, file logs and database interface. Some elements work asynchronously, i.e., transmit data on its own upon an event such as value exceeding a threshold, timer expiration and others. Some elements work synchronously, that is, they must be actively queried for data. The output of DCF is data ready for retention.

The variability of communication as well as the variability of devices manufactured by various vendors renders the DCF very complex. We propose to adopt and customize existing solutions for network administration and monitoring which already cover this complexity.

From a wide variety of network tools Network Administration Visualized (NAV) [4] suite (a collection of libraries put together with output to database and handy GUI) seems to be good solution for collecting data from network elements. NAV has been developed since 1999 and nowadays it is maintained by UNINETT. NAV is freely distributed under the GNU GPLv2 license and supports both IPv4 and IPv6 deployment. NAV is able to poll or receive SNMP messages and events from over 80 network devices (most commonly switches and routers) from 11 different vendors. Moreover, it is able to store logs and messages from Radius server as well.

Fig. 4. Part of NAV architecture

Figure 4 displays subset of the whole NAV architecture. It consists of several backend processes that runs as either daemons or cron jobs. These processes fills up the NAV database (PostgreSQL). Although NAV consists of many processes this report focuses only on those that are relevant for data retention.

The crucial part for DR is to collect information about an association of a user, user’s IP address, MAC address and switch port the user is connected to. This allows to answer typical queries such as who is behind given IP address, what is the user’s location, what addresses does the user use. SNMP is used to obtain data from switches every fifteen minutes. The mapping between the IPv6 address and its corresponding MAC address is downloaded from the router’s neighbor cache. Port, VLAN number and other information comes from the switch’s FDB (Forwarding Database) table.

First of all, the administrator must seed the NAV database with IP addresses of monitored network elements. The ipdevpoll polls each device for inventory information (includes interfaces, serial numbers, modules, VLANs and prefixes), for load information and for logging information such as ARP tables or Neighbor Discovery cache. The obtained information is regularly stored in the database. NAV defines following ARP table schema:

The mactrace process collects mac addresses, port, vlan and other information from Forwarding Database table for all switches and stores the information into CAM table. Its schema is described in Table 3.1. The process also checks for spanning tree blocked ports.

NAV also supports collection of RADIUS data from a FreeRadius server. The FreeRadius server can be configured to push data about authentication requests directly into NAV database. In addition to this interface, there is a NAV radius process which regularly parses the FreeRadius log file. It extracts important messages and pushes them in the database as well. The most important columns of NAV table are described in table 3.1.

We have added a support of another Radius server Radiator [?]. Radiator provides event-hooks which we utilize to parse on-going authentication requests.

Parsed requests are temporarily stored in a file. Another process picks up these stored requests, transforms them into a schema of NAV radius table in NAV database and performs an insert operation. The separation of Radiator and parsing process allows to store messages when the NAV database is temporarily unreachable. It also allows to select and store only those items which fit the current Radius table schema. Probably the most important fields are username and callingstationid. In case of IP network we store a MAC address of a user as a callingstationid.

timestamp           username          callingstationid  result
---------------------------------------------------------------
2011-11-21 12:58:46 xsejno00@vutbr.cz 00:Id:e0:0a:d0:7d	accept
2011-11-23 09:21:49 hazmuk@vutbr.cz   00:21:5c:81:61:91	accept
2011-11-23 07:32:11 xkisli01@vutbr.cz 00:13:02:51:eO:fd accept
2011-11-22 21:31:58 2763@vutbr.cz     00:26:82:lb:cO:cd accept
2011-11-22 16:02:30 xkisli01@vutbr.cz 00:13:02:51:eO:fd reject
2011-11-21 20:45:03 tpoder@vutbr.cz   58:If:aa:82:39:6c accept
2011-11-21 20:23:54 xgregr01@fit.vutb 00:26:82:e5:6b:Of accept

We have further extended the schema of radius table with unique user-ID. A database trigger is implemented to check if a username in the incoming message already exists in the table. If so, then its unique user-ID is used if not then a new ID is generated for this user. The unique user-ID enables to join collected information with other external data such as NetFlow records (this will be discussed in further sections).

The collected ARP entries (MAC-IP pair) and CAM entries (MAC-port pair) and Radius entries (username-MAC or username-IP address) enable to keep relation among users, IP addresses, MAC addresses and switch ports. This is especially important in IPv6 deployment where a user typically generates its own IP addresses and changes them regularly. Moreover, all records contain start time and end time of their validity. This is important for handling history-oriented queries which are typical for data retention system.

NAV does not collect any information regarding the network traffic itself. Therefore it must be complemented with other tool capable of collecting these data (as depicted on Figure 5). Based on our previous experience, we select to gather traffic metadata via NetFlow. Collecting NetFlow records is typically supported by routers or dedicated probes.

Fig. 5. The Central Monitoring System for IPv4 and IPv6 at BUT

NetFlow protocol transfers these records about passing IP flows from probes to a collector. The NetFlow records contain flow ID and statistics. The flow ID consists of source and destination IP addresses, ports and protocol. The statistics include packet count, byte count, timestamps of first and last packets and others.

The large amount of traffic on current networks turns into a large number of NetFlow records transferred to the collector. Approximate volumes of received NetFlow data are around 300 MB per hour for a loaded 100 Mbps network and 600 MB per hour for a 1 Gbps moderately utilized network. But it always depends on the specific composition and type of traffic. In any case, the crucial part of the collector is its storage and in particular, its capabilities such as capacity, write and read speeds. Since most of the collectors run on the similar hardware (commodity PC with extended storage capacity) the capabilities varies by utilized underlying storage format – either database or raw files.

A database server provides a comfort of SQL interface and automatic data indexing. But this comes with a prize. Database systems have not been optimized for NetFlow data processing. The NetFlow data require fast storage, fast retrieval of large amount of data but no update of the data at all. Therefore the indexing structures of the database might not fit these requirements. The collectors using proprietary raw files to store NetFlow data must process the queries at the application level which limits flexibility of the queries. Also there is no indexing involved hence the retrieval of selected data may take longer than in case of DB systems.

Currently, the widely-spread collector called nfcapd is based on storage of records into raw files. The nfdump tool is then used to access and filter these flowrecords. We briefly compared its performance with some well known DB systems such as SQLite, MySQL, CouchDB. The nfcapd outperforms these systems when receiving flow records quite dramatically while the time to answer queries on the stored data do not differ that much.

We are aware of possible DB optimization that might improve the performance of some DB systems. But it would require a significant effort with uncertain outcome. Therefore we select current nfcapd and nfdump tool to serve as NetFlow collector. As mentioned previously, such collectors are less flexible than DB collectors. Therefore some implementation effort is necessary to modify nfdump in order to suit data retention requirements. In particular, to extend NetFlow data with data collected by NAV (IP-MAC, MAC-user assignments).

3.2 Data store management function

The data store management function constitutes of some background processes which handle collected data and provides interface for Administrative function.
As mentioned before, we use nfcapd to capture NetFlow data which are generated by probes in our network, and nfdump tool to process and access this data. The goal is to extend this data with source and destination MAC addresses and source and destination user-IDs. We store the corresponding usernames-user-ID pairs in a separate file for later reference. As a result it is possible track activities of a particular machine or user. This requires to modify nfdump file format and patch nfdump itself to understand the modified format. It also requires a tool that would allow to extract data of interest from NAV DB running in parallel and continuously update stored NetFlow data in nfdump files.

The main issue with adding user-IDs to nfdump files is that there is no defined field for this IDs. There are two possibilities how to solve this issue. Either to store these values into other unused fields that are already available, such as MPLS 1 and MPLS 2 fields, or to change the structure by extending the existing format with new fields. We implemented both options and each has its pros and cons. While the former MPLS solution is backward-compatible with nfsen (GUI for nfdump) since it does not require any patch of nfdump the latter solution does not allow a nfsen to display user-ID unless patched to understand it.

Figure 6 shows the print out of nfdump when MPLS 1 and 2 are used to store user-ID. A typical point of NetFlow observation is an Internet gateway. Therefore it is possible to observe only communication of a local user and a host which is outside of the administered network. As a result one of the MPLS tags is zero which means no association with user identity.

Fig. 6. User-ID stored in MPLS labels (nfdump print out)

It is important to note that all the identification data are not available at the time of arrival of NetFlow data. For instance, NetFlow data are available when they are sent to the collector. However, there is no information available in the NAV database about IP, MAC and user yet. Such information is downloaded later from the switch’s ND cache. The same holds for Radius data but RADIUS data are not available for every user – only for those who are connected using 802.lx authentication. For other users, only the IPv6 address and the switch port number and MAC address are used for identification.

An additional tool (nftool), a helper script and helper DB are used to extract (MAC, user-IDs) and (MAC, IP) pairs from NAV DB and store them into nfdump files. The architecture is depicted in the Figure 7.

Fig. 7. Framework for fusion of NetFlow and user identification

The helper script is written in Perl and runs every hour (as a cron job) to import data regarding the user-ID, MAC, IP addresses into helper DB (Berkeley DB). This is done to alleviate NAV DB from intensive queries which are caused by nftool when it figures out which MAC address and user-ID belongs to each flow record in the processed nfdump file. The script assembles two helper DB tables (files), user-ID table and MAC table. The user-ID table consists of user-ID, MAC address, start timestamp and end timestamp. The MAC table consists of MAC address, IP address, start timestamp and end timestamp. The timestamps determine the interval during which the assignment is valid.

The nftool is written in C due to a large amount of data and operations it must execute to match nfdump flow records with their corresponding user-IDs and MAC addresses. The nftool runs every hour after the helper script finishes importing data into helper DB. The nftool reads all nfdump files stored in previous hour and parses record by record. It tries to associate each record with its source and destination MAC address based on a match of IP addresses in MAC table. Based on the associated MAC address, the nftool tries to assign a corresponding user-ID from User table.

The deployment in a production network revealed several issues. The associated start timestamps in MAC table may be up to 15 minutes late in relation to the real appearance of the assignment in the network. This delay is caused by NAV setup which by default scans neighbor caches every fifteen minutes. The address may appear right after the scan of the cache and stays unregistered till the next scan. Therefore the nftool considers a each MAC record valid 15 minutes prior to its timestamp. There are also records in which the end timestamps are missing. This might be due to records that has not yet expired from the neighbor cache or due to events such as switch reboot, etc. There might also be situations when one IP address matches multiple MAC records. It is up to nftool to handle these corner cases correctly, e.g., to match the most probable MAC record based on timestamps.

The time dependency of the gathering of different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system. Typical timeouts for collecting SNMP and RADIUS data are fifteen minutes. The ND Cache expiration timeout is usually set to more than one hour.

3.3 Administrative function

The main task of Administrative function is to implement handover interface of retained data (RDHI). The ETSI specifies a model for RDHI. It constitutes of several layers, each providing specific functionality.

The message flow layer deals with communication establishment and control. It defines two operational modes: General and Authorized-Organization-initiated. In the case of General mode, both entities are able of full-two way transport of messages whereas in the case of Authorized-Organization-initiated situation, AO must query CSP every time AO wants to receive any data. Next layer specifies contents of each message that is what information must be included in transferred data (identifiers, timestamps, etc.). The encoding and delivery layer defines techniques to handle transparent data exchange. It defines several options such as Direct TCP data exchange, or exchange over HTTP.

In order to hand over retained data collected by NAV and nfdump, we choose to implement a single HTTP client/server communication operated in a Authorized-Organization-initiated mode, i.e., CSP runs an HTTP server and web interface serves to answer AO requests. The administration function is written in PHP and is interpreted by the server. The script receives a request via a POST parameters filled out in the web form. The query typically contains constraints on time interval, IP address, username or MAC in question. Based on the constraints, a nfdump query is constructed and executed. The processing of retained data may take a while since nfdump must filter out records that do not match the constraints. When the result is returned the script assembles a web page which is sent to an AO. We recommend to use HTTPS in order to assure secure delivery as well as authenticity.

Fig. 8. RDHI model (taken from [2])

Please note, that the above described handover interface does not strictly conform to ETSI standard yet. The message flow such as request-acknowledge must be embedded into application level of communication as it is not sufficient to return HTTP status codes as control messages. Further, multiple parallel requests generated in a single session must be addressed.

4 Practical experience

4.1 Network @ Brno University of Technology

This chapter describes how the issues of IPv4 and IPv6 monitoring discussed above are solved at the BUT campus network. The BUT campus network includes 134 active routing devices on the backbone and thousands of connected users (especially students). The chapter presents the data and data sources required for monitoring and how they are obtained. Some results and statistics about IPv4 and IPv6 traffic are given at the end of this chapter.

The campus network at Brno University of Technology (BUT) was built up as a result of cooperation among other universities placed in Brno and Czech Academy. The campus network connects together several institutions (University faculties, research Institutions, Czech Academy, high schools) placed on over 20 locations in different parts of Brno. Each location is connected at least with two optical cables from two independent directions to achieve maximum reliability of the network. The total length of the optical cables is over 100 km. The core architecture is depicted on Figure 9.

The core of the network is based on 10 Gbps Ethernet technology using HP ProCurve and Extreme Networks devices. OSPF and OSPFv3 routing protocols are used as the interior routing protocol. External connection to the National Research and Education Network (NREN) that is run by CESNET is provided over two 10 Gbps lines with BGP and BGP+ routing. The topology of the core of the network is shown in the Figure 9. From the user perspective, the BUT university campus network connects more than 2,500 staff users and more than 23,000 students. The top utilization is at student dormitories where more than 6,000 students are connected via 100 Mb/s and 1 Gbps links. The IPv6 campus connectivity is implemented according to the Internet Transition Plan [1]. Most of the parts of the university already provide native IPv6 connectivity and significant part of devices connected to the campus network can fully use IPv6.

4.2 Practical Configuration of IPv6 at BUT

At the university environment, the best practice is to identify hosts based on the hosts’ IPv4 addresses. Usually, it is done by central system for user registration with the users’ MAC addresses. The user registers his MAC address in the system. The MAC address is then used in the DHCP configuration to assign a corresponding IPv4 address. Registered MAC addresses, together with system logs of DHCPv4 servers and data from RADIUS servers, are sufficient to uniquely identify the user, based on the IPv4 address. For a long-term history, NetFlow data are gathered using special NetFlow probes, working on 10 Gbps links. DHCP logs, RADIUS logs and NetFlow records are stored at the central monitoring system, where the users’ activity can be looked up as required by the Data Retention Act.

User monitoring of IPv6 traffic is more complicated. The IPv6 address is no longer a unique identifier, as in the case of an IPv4 address. This is mainly because of temporary addresses, as described above. There are two ways to assign IPv6 addresses. Practical experience at BUT indicates that stateful configuration using DHCPv6 does not work properly, so only stateless configuration can be deployed.

One of the basic problems is address assignment to the client systems. The mixture of various OSs requires a solution of automatic address assignment that is supported by most systems. The stateful autoconfiguration using DHCPv6 is very difficult to use today because the lack of support in Windows XP which is still very widespread OS, and older version of MAC OS. DHCPv6 does not support all configuration options (e.g. option for default route), so the stateless autoconfiguration (SLAAC) [3] has to be used as well. Unfortunately, the stateless autoconfiguration in some operating systems turns on privacy extensions.

Fig. 9. Topology of VUT network

As a result, the devices use a random end user identifier (EUI) named Temporary IPv6 Addresses. This is a brand new IPv6 feature that allows a node to automatically generate a random IPv6 address on its own. However, this feature contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This affects logging and prevents administrators from effectively tracking which users are accessing IPv6 services. Many internal resources require the ability to track the end user’s use of services.

IPv6 auto configuration options also increase complexity. There are two fundamentally different mechanisms and protocols where one cannot fully work without the other. Configuration of Recursive DNS servers is nowadays not possible using SLAAC and with DHCPv6 it is not possible to configure the default gateway address (default route). As a result, the only working method is to use both protocols simultaneously. Failure of either mechanism whether through faulty configuration, bugged software or targeted attack, leads to denial of IPv6 connection to the user. Moreover diagnostics are fairly complicated and it requires good knowledge of both mechanisms.

There are two scenarios used for assigning IPv6 addresses. Both Stateless IPv6 configuration and Stateful IPv6 configuration is used.

4.3 Installed DR components

In order to feed our data retention system with information about IP and MAC addresses of connected users we collect ARP tables and FDB tables from all routing switches located in different buildings of BUT campus. Each of these switches serves as a gateway for a given building. We setup NAV to poll these switches regularly every 15 minutes and if a change occurs it is logged in the NAV database. The NAV system runs on a dedicated machine.

The basic NetFlow data are obtained from three monitoring probes that had been installed in the different part of the campus network. Two of them on the upstream lines to collect complete data exchanged between the campus network and rest of the Internet. The third probe was installed at the student’s dormitory where most traffic of the network is concentrated. In cooperation with the company INVEA-TECH the probes were ported to HP Procurve ONE service module. That allowed to process data directly from the backplain on the switch. Data obtained from the probes are collected on the single NetFlow collector. The collector pulls out data from NAV machine and merge these data with NetFlow.

4.4 Obtained results

Many interesting statistics were obtained as the side result of implementation of data retention system. The Figure 10 displays visibility of a single machine under various IP addresses. The first IP address starting with fe80 is link local address which remains constant for the whole period of observation. The same holds for IPv4 address. The machine has multiple self-generated IPv6 addresses which are used in ad-hoc mode.

Fig. 10. Visibility of a computer under various IPv6 addresses

Since the deployment of the system we have been able to observe differences between IPv4 and IPv6. In total, we have observed 41032 unique MAC addresses. There have been 18480 MAC addresses which have been visible under any IPv6 address. Nearly all these MAC addresses (except 100) have been associated with link local IPv6 address. There have been 26277 unique IPv6 link local addresses. But more importantly there have been 13733 MAC addresses with nearly a million of global IPv6 addresses. This means that on average each IPv6 capable machine changed its global IPv6 address more than 60 times. On the other hand, we have seen only 43786 unique IPv4 addresses in total. The observation period has been approximately 10 months.

We have also observed evolution of the traffic during a shorter period (a week, gray background marks weekends) with timescale resolution of one hour. Some of the findings are plotted in Figures 11, 12, 13.

The Figure 11 shows the number of hosts with assigned IPv4 or IPv6 address. We consider a host to be uniquely identified by the MAC address. We can see that the number of hosts follows the daily pattern with a significant decrease during Friday till Sunday afternoon when students return to dormitories. The amount of IPv6 hosts is close to the number of IPv4 hosts. In comparison to the total statistics presented above the ratio of IPv6 and IPv4 host has increased significantly. This increase is most likely caused by migration of users to a newer operation systems during this year.

We have also focused on the IPv6-capable hosts that actively utilize IPv6 during communication. The graph on Figure 12 displays the number of internal and external hosts involved in active communication. The term internal host means a host which belongs to the BUT network whereas external host is located outside of the BUT network. We can observe that the number of internal IPv6 hosts is smaller than the number of external IPv6 hosts, i.e., an internal host communicates on average with more than two external IPv6 hosts.

Fig. 11. Number of clients using IPv4 or IPv6

Fig. 12. Number of internal and external IPv6 hosts

Finally, the graph on Figure 13 displays the amount of traffic with respect to the IP protocol used. We introduce a third category which account for the tunneled traffic such as Teredo. The amount of traffic strongly follows the daily and weekly period. The amount of ingress traffic is significantly larger than the amount of egress traffic for both IP protocols. On average, the amount of IPv4 traffic is ten times higher than IPv6 which is ten times higher than the amount of traffic utilizing tunneling mechanisms. The large difference between the amount of IPv4 traffic and IPv6 traffic is in contrast with the small difference of IPv4 and IPv6 capable hosts. Nevertheless this discrepancy is expected as a result of small support of IPv6 by network applications.

Please bare in mind that the presented statistics are valid for a campus network which might be specific due to its users and strong effort to keep up with the IPv6 transition plan. A commercial provider might observe a different statistics. We would expect to see even a larger difference in the amount of IPv4 and IPv6 traffic. The main cause could be older OS of users and missing native support of IPv6. In such a case, tunneling mechanisms come into play and there might be tunneled IPv6 or IPv4 traffic only.

Fig. 13. Breakdown of the traffic mix based on IP protocol

5 Conclusions

This technical report was focused on the design and implementation of data retention system in IP network. The stress was given on addressing issues related to the deployment of IPv6 in terms of recovering user identity.
The designed system consists of several monitoring tools. The results of these tools are combined together to obtain data about the past and on-going traffic enriched with the information about a user identity. The system has been successfully deployed in BUT network. Since its deployment it has been used to manage violations of network usage policy and to observe IPv6 network behavior and its trends.

References

1. Curran, J.: RFC 5211 An Internet Transition Plan. 07 2008. URL http://tools.ietf.org/html/rfc5211
2. European Telecommunications Standards Institute: ETSI TS 102 657: Lawful Interception (LI);Retained data handling;Handover interface for the request and delivery of retained data. 12 2009, version 1.4.1.
3. Thomson, S.; et al.: RFC 4862 IPv6 Stateless Address Autoconfiguration. 09 2007. URL http://tools.ietf.org/html/rfc4862
4. UNINETT and Norwegian University of Science and Technology: NAV. 3 2011, version 3.9.
   URL http://metanav.uninett.no

Figure 12

It is now a few months since IANA has run out of IPv4 addresses. Large ISPs have usually reserved some address pool for the future, but requesting new IPv4 addresses from LIRs will be much more difficult and probably impossible. Unfortunately there are more and more devices, which require an Internet connection – smart phones, PDAs, netbooks etc. One solution for the ISP to meet their requirements is to use NAT. This works well for basic connectivity, but causes difficulties to many applications. There are also scenarios where large ISPs will trade with their unallocated IPv4 addresses. However both of them can be considered as only short term solutions.

Figure 1 – Topology of Campus BUT network

The only perspective solution is deploying IPv6. IPv6 is not compatible with IPv4 so the networks will have to run both protocols, until all services are available on IPv6. Deploying IPv6 brings many new issues. Techniques for IPv6 address assignment implemented differently in various operating systems (OS) can be one of the examples. Missing implementations of security tools (RA Guard, SEND etc.) is also a serious issue. The new feature – privacy extensions [1], makes user’s identification more difficult. This behavior is desired to ensure user privacy, however it is in contradiction with a unique user identification in a local network which is necessary for a network administrator. New ways to deal with this feature needs to be developed. Transition techniques raise security problems [7]. Improperly configured operation systems sending rogue Router Advertisement can cause network malfunctioning [2]. These are other examples of problems that network administrators are facing. New ways to manage IPv6 network needs to be found.

This article assembles experience with deploying IPv6 at the campus network at Brno University of Technology (BUT) that is one of biggest universities in the Czech Republic. The network was built up as the result of cooperation amongst other universities placed in Brno and Czech Academy. The campus network connects together several institutions (University faculties, research Institutions, Czech Academy, high schools) placed on over 20 locations in different parts of Brno. Each location is connected at least with two optical cables from two independent directions to achieve maximum reliability of the network. The total length of the optical cables is over 100km.

The core of the network is based on 10 Gb/s Ethernet technology using HP ProCurve and Extreme Networks devices. OSPF and OSPFv3 routing protocols are used as the interior routing protocol. External connection to the National Research and Education
Network (NREN) that is run by CESNET is provided over two 10Gb/s lines with BGP and BGP+ routing. The topology of the core of the network is shown in the Figure 1.

The IPv6 campus connectivity is implemented according to the Internet Transition Plan [4]. Most of the parts of the university already provide native IPv6 connectivity and significant part of devices connected to the campus network can fully use IPv6.
From the user perspective the BUT university campus network connects more than 2,500 staff users and more than 23,000 students. The top utilization is at student dormitories where more than 6,000 students are connected via 100 Mb/s and 1Gb/s links. It is a really big challenge to provide functional and stable IPv6 connectivity to that amount of users.

2 Current status of IPv6 deployment at Brno University of Technology

IPv6 related activities started at university several years ago. In that time a temporary IPv6 network was created especially for testing purposes. Routing was performed on the PC based routers with routing software XORP and outside connectivity to NREN was encapsulated inside tunnels. The IPv6 infrastructure was completely separated in order to minimize impact of IPv6 infrastructure to running IPv4 services. That means the IPv6 network was run on dedicated routers and cable/fiber infrastructure. There were not any critical services running on IPv6 in that phase.

The significant change became in 2010 when university started participating on HP ProCurve beta testing program. That was mainly focused on IPv6 features in the HP ProCurve devices that are widely used on the BUT network. Thanks to pretty good results from beta testing program the decision to move the core of the network to dualstack was made in the middle of 2010. IPv6 was enabled on all devices in the core network. At the end of 2010 the topology and the IPv6 network started completely following the topology of the IPv4 network. In the same time university decided to get own provider independent (PI) IPv6 address space to be able to use multihomed IPv6 connections. Today, the IPv6 and IPv4 network provide almost same services on wire speed.

During the process of moving to IPv6 we have encountered with several problematic issues. Some of them are very essential and nowadays there are still not proper solutions for them. In the following lines we will try to point out some of them.

3 IPv6 problems to solve and possible solutions.

3.1 Addressing issues

One of the basic problems is address assignment for the client systems. The mixture of various OSs requires a solution of automatic address assignment that is supported by most systems. The stateful autoconfiguration using DHCPv6 is very difficult to use today because the lack of support in Windows XP, which is still very widespread OS, and older version of MAC OS. DHCPv6 does not support all configuration options (e.g. option for default route), so the stateless autoconfiguration (SLAAC) [3] has to be used as well. Unfortunately, the stateless autoconfiguration in some operating systems turns on privacy extensions which mean that the devices use a random end user identifier (EUI) named Temporary IPv6 Addresses. This is a brand new IPv6 feature that allows a node to automatically generate a random IPv6 address on its own.

However, this requirement contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This affects logging and prevents administrators from effectively tracking which users are accessing IPv6 services. Many internal resources require the ability to track the end user’s use of services.

If a local security policy requires better control, either fixed IPv6 addresses must be centrally assigned and logged, which is not a feasible option for a large network, or stateful configuration using DHCPv6 has to be deployed. However, in that case, same operating systems (Windows XP, older versions of MAC OS, some Linux and BSD systems) will not have access to IPv6 network.

IPv6 auto configuration options also increase complexity. There are two fundamentally different mechanisms and protocols where one cannot fully work without the other. Configuration of Recursive DNS servers is nowadays not possible using SLAAC and with DHCPv6 it is not possible to configure the default gateway address (default route). As a result, the only working method is to use both protocols simultaneously. Failure of either mechanism whether through faulty configuration, bugged software or targeted attack, leads to denial of IPv6 connection to the user. Moreover diagnostics are fairly complicated and it requires good knowledge of both mechanisms.

3.2 First hop security

IP address autoconfiguration process might be perceived as a honey pot for a hacker. If the hacker is able to interfere the configuration process, the whole user’s traffic can be rerouted to the attacker PC. In many cases it does not need to be a targeted attack, but simply an accident, where a user connects a Wi-Fi router with a preconfigured DHCP server to the network and cause a network malfunction for other users.

This problem, as the other problems with first hop security, is known in IPv4 world for quite long time. For this reason some mechanisms were created in the IPv4 world which would prevent or at least complicate some of these attacks. The best place to implement protection for end users is on the end-user switch access port to which the user is connected. Different vendors use slightly different terminology for individual types of protection but generally we can meet the following ones:

• DHCP Snooping: Some ports are explicitly defined in the switch configuration so port is able to receive DHCP responses from DHCP (so called trusted port). It is assumed that somewhere behind the trusted port is a DHCP server. If a reply from a DHCP server arrives to a port not defined as trusted the response is discarded. Any DHCP server running on the client system (whether intentionally or by accident) does not threaten other clients on the network because the answers will not reach further than the access port for which this protection has been activated. DHCP snooping is usually prerequisite for other protection mechanisms such as IP lockdown or ARP protection as described below.
• Dynamic ARP protection, ARP inspection: DHCP snooping database contains MAC address – IP address – switch port combination. This database is then used on untrusted ports to inspect ARP packets. Other MAC addresses not recorded in the database are discarded. This eliminates attacks focused on creating fake records in the ARP table (poisoned ARP cache).
• Dynamic IP Lockdown, IP source guard: Another degree of protection is achieved by inspecting source MAC and IPv4 address on untrusted ports for all packets entering the port. This eliminates spoofing a source IPv4 or MAC address. Another often appreciated feature of this mechanism is the fact that the client cannot communicate over the network unless an IP address from the DHCP server is obtained.J

The IPv6 autoconfiguration and neighbor discovery can be vulnerable to similar attacks as autoconfiguration in IPv4 networks [7]. Nowadays, network administrators of IPv6 networks are facing mainly to problem with rogue router advertisements, which is similar to the problem of fake DHCP server in IPv4 networks. Many rogue advertises are generated by Windows computers. This is a serious issue because computers propagate their own interface as a default gateway. Unfortunately this behavior can be in some conditions caused by properly used Internet connection sharing service. The Figure 2 shows the number of rogue advertises on the network with approximately 2000 active devices connected to.

Figure 2 – Number of Rogue’s routers

Described solutions for mitigating attacks in IPv4 networks are implemented in most of access switches on the market. IPv6 techniques for autoconfiguration are different so new solutions are necessary. Security mitigation techniques in IPv6 networks are described below.

• Source Address Validation Improvements (SAVI): The Source Address Validation Improvement method was developed to complement ingress filtering with finer-grained, standardized IP source address validation [13]. Framework has option for DHCP servers [8] and tries to solve a mechanism similar to the one we described with DHCP snooping for IPv4. It is limited to DHCPv4 and DHCPv6 and does not deal with the problems of rogue Router Advertisement messages. SAVI is
  mainly supported in devices produced by Hewlett Packard – A series.
• SEND – Secure Network Discovery: This method tries to deal with autoconfiguration problem in a totally different way. SEND is based on signing packets with cryptographic methods [12]. Apart from a router it does not require support on the active network devices level. The validity verification itself through message certificate takes place at the end-user system. IPv6 address of the end-user system is a result of a cryptographic function (see, we have another auto configuration method). Using SEND directly excludes using EUI 64 addresses and Privacy Extensions. SEND has one big advantage – it not only solves the auto configuration problem but also other safety problems of the Network Discovery protocol (RFC 2461). Another advantage is independent infrastructure; hence it can also be used in Wi-Fi networks for instance.

The main shortcoming of SEND is the fact that it requires the support of public key infrastructure according to X 509. To make it work properly you need to install a certificate of the authority which issues router certificates. There are other than security risks associated with SEND. SEND is a patented Cisco technology (US patent number 20080307), therefore no-one would be surprised that it is implemented especially on devices of this company. Presence of patent raised several discussion especially with SEND and RA Guard integration. According to Cisco statement, Cisco will not assert any patents against any party that implements the standard [14].

SEND protocol is not supported on any operation systems. There are some basic Linux implementation and kernel patches, however that cannot be used in production environment. Windows OS, as the most widespread OS, nor Mac OS do not support the SEND protocol even in the most recent versions. SEND protocol could potentially solve security problems of NDP protocol, however it cannot be deployed and there are no indications, that this should change in the future.

• RA Guard: Another alternative which however deals only with the issue of fake router advertisements is IPv6 Router Advertisement Guard [5]. It is similar technique as DHCP snooping, but for Router Advertisement packets. It tries to block fake router advertisements on the access user port. Apart from tools which should ease the initial switch configuration (learning mode), it opens the path to integration with SEND. In this mode the switch works as so called node-in-the-middle, where switch with activated RA Guard uses information from SEND to verify packet validity and for the connected end-user system it appears as normal Router Advertisement packet. As you could guess from the title RA Guard does not solve DHCP or DHCPv6 issues in any way. We can already find an implementation in some Cisco devices.

All of the above possibilities can be used rather theoretically today. Either they are not implemented on clients or the device support is missing. Another issue is that if the protective devices are to be truly purposeful they must be placed as close to the end-user system as possible. This could often mean a complete replacement of network infrastructure which is a job that few will want to undergo just to implement IPv6. More affordable solutions which would at least alleviate efforts to paralyze the IPv6 auto configuration mechanism are following.

• Access Lists on the switch: This solutions was published by Petr Lampa within the CESNET working group. It assumes that we can configure IPv6 access lists on the active device.

The aforementioned access list will block all ICMPv6 messages type 134 (RA messages line no. 2) and it will block traffic to the 546 target port (dhcpv6-client, line no. 3). The rules are subsequently applied to the inputs of ports to which the clients are connected (line no. 7). This can eliminate instances of rogue routers and DHCPv6 servers. The aforementioned example can be used for some HP switches and can be an inspiration for other platforms as well. A required condition to use this mechanism is IPv6 ACL support on the relevant switch. The problem of that solution is that very few access switches supports creation if IPv6 access-lists today. Also price of that switches is usually two or three times higher comparing to the switches where those IPv6 are not implemented.

Passive monitoring

Another option is detection of fake Router Advertisements. This will not protect us much from a well-crafted and targeted attack but it can at least detect incorrectly configured clients. We will need to use this solution if none of the options above can be used. For many networks it would be the only usable solutions for a long time. All tools for detection of rogue Router Advertisements work based on the same principle. They connect to the ff02::1 multicast group where the aforementioned messages spread and thus will be able to monitor all messages appearing on the network. They can then tell the administrator about the undesirable status, call an automated action (Ndpmon, Ramond), or even send a message canceling the validity of fake Router Advertisements (rafixd) back to the network.

3.3 User tracking, monitoring and accounting

Long-term network monitoring, accounting and backtracking of security incidents is often achieved in IPv4 networks using NetFlow probes and collectors. This can be a problem if IPv6 is deployed and privacy extensions are allowed in the network. Same user can than communicate with different addresses. That means that address cannot be used as a unique identifier anymore. As the part of deploying IPv6 we tried to develop extension to existing monitoring systems to allow easier tracking users in an IPv6 network.

The main idea of the extension is collecting and putting together data obtained from differed parts of the network. A neighbor cache database [6] on routers and forwarding databases on switches can provide to us information about relation between IPv6 address port on switch and a MAC address used by user. In the next step a MAC address can be used for identifying user in the database provided by radius server.

All of these pieces of information, together, provide a complex view of the network and can help to identify a host. A tuple (IPv6 address, MAC address, Login name) is sufficient to identify a host/user. In practice, an extended tuple is built: (Timestamp, IPv6 address, MAC address, Switch port, Login) as described in the Figure 3.

Figure 3: Extended NetFlow record

Timestamp is added to provide a history of communication. Switch port is necessary if the user is blocked or if an unregistered MAC address is used on some port. In addition to these values, the VLAN number and interface statistics are stored; however, these data are not necessary for host identification.

It is important to note that this data structure is not created at once, but it is filled in when data are available. For instance, NetFlow data are taken from the NetFlow probe when they are sent to the collector. However, there is no information about MAC addresses yet. The address is downloaded later from the switch’s ND cache. Login data from RADIUS can also be added. However, RADIUS data are not available for every user – only for those who are connected using 802.1x authentication. For other users, only the IPv6 address and the switch port number and MAC address are used for identification.

Collecting Monitoring Data

Data are collected using the SNMP protocol and stored in the central database where the network administrator can search data using the IPv6, IPv4 or MAC addresses as keys. Useful tool for pooling and storing information from switches and routers is Network Administration Visualized (NAV) [9]. SNMP pools the data from switches every fifteen minutes. The mapping between the IPv6 address and its corresponding MAC address is downloaded from the router’s neighbor cache. Port, VLAN number and other information comes from the switch’s FDB (Forwarding Database) table. Traffic statistics are obtained from NetFlow. NetFflow records alone are not sufficient for user surveillance and activity tracking because of the temporary IPv6 addresses as described in previous sections.

Figure 4: The Central Monitoring System for IPv4 and IPv6 at BUT

Therefore, NetFlow records are extended by additional information called flow tags. The flow tag is added to a flow record after its creation, usually when the information is received and stored at the main database. The tag is a unique identifier of the user, because NetFlow records are generated for every single connection of the user, even with different IPv6 addresses. Flow tags can be used as keys to identify the activities of any user stored in the system. This is necessary because not all data are available immediately in the central monitoring system, for example, due to a delay caused by SNMP pooling. When flow tags are added, more complex statistics based on the flow data are created, for example, top-N users.

The time dependency of the gathering of different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system. Typical timeouts for collecting SNMP and RADIUS data are fifteen minutes. The ND Cache expiration timeout is usually set to more than one hour.

4 Conclusion

This paper presents security and addressing issues in IPv4 and IPv6 protocol and solutions how to solve them. Nowadays, the IPv6 traffic volume is low, but this is caused by the lack of IPv6 sources (web pages, servers) on the Internet. Also widespread operation systems such as Windows XP supports IPv6 but IPv6 is not enabled by default.

Next generation Windows systems together with Linux, Mac OS and Unix systems have however IPv6 protocol enabled by default and penetration of these systems is growing. Security and addressing issues discussed in this paper present overview problems we encountered when deploying IPv6 protocol on BUT campus network. Addressing issues and problems with user tracking in IPv6 protocol introduce the necessity for the new monitoring system which is able to overcome the specific problems in IPv6 address assignment. Solutions, how to solve these issues, are proposed. We discussed possibilities, how we are able to limit the impact of security problems in IPv6 network together with monitoring and tracking system which is able to identify and track a host in IPv4 and IPv6 network.

5 Bibliography

The original idea of autoconfiguration was based on the notion of an IPv6 device connecting to a network and autoconfiguring everything automatically, without requiring any interaction from the user. Even though DHCP was widely used at the time of the first IPv6 proposals, the creators of the IPv6 protocol decided to use a different mechanism.

The very large address space offered by IPv6 suggests an interesting solution. Why dictate IPv6 addresses to end-user stations manually, or through some central authority (a DHCP server, for instance) if each end-user station can set the address it wants to use to communicate by itself? This address can be derived from information that it already has, such as, a network-card link-address. This creates a mechanism to define the host part of the network address via a modified EUI 64 algorithm, or through Privacy Extensions. Thus, the host part of the address has been determined, and only the rest of the address needs to be established, i.e., the network part or global network prefix. The only device with information about the network prefix is the router to which the end-user station is connected. Passing this router is usually the only path that packets may take from (and to) the Internet. Hence, there is nothing simpler than to give the router a mechanism to announce to enduser devices what network they are on (network prefix) and what is the way out (default gateway). From these simple thoughts arose the idea of a stateless client configuration, which is called SLAAC (Stateless Address Autoconfiguration, RFC 2462).

SLAAC can be described in simple terms. The network router tells all the connected nodes in a network segment what network they appear in, and what router they should use for packets travelling to the Internet (RA – Router Advertisement). Of course, announcing alone would not be flexible enough. Hence, a newly connected device may send a request to the network (RS – Router Solicitation) asking for information about what network it is in, and what is the way out. The whole autoconfiguration mechanism is a part of Neighbour Discovery for IPv6 (RFC 2461), and all communication takes place using the ICMPv6 protocol. Therefore, it appears that the autoconfiguration issues have been solved. Instead of DHCP, which is familiar from the IPv4 world, SLAAC can be used for IPv6. It is not necessary to look after the DHCP server configuration, define DHCP pools and set DHCP relay; only a global prefix needs to be set on the router interface and everything else will happen almost all by itself. That sounds too good to be true, and indeed there is a catch. Actually, there are several catches.

1.1 DNS servers

A study of the specifications of the information transferred in a Router Advertisement reveals that apart from definitions of types, options and validity times, there is only a definition of the prefixes for the network that the user is currently in. In order to have complete communication in the network, other details are required, such as, the IPv6 addresses of recursive DNS servers. However, this information is not in the Router Advertisement. The problem of the absence information about recursive DNS servers in SLAAC has been known for quite some time. In practice, the efforts to resolve this problem have taken three different routes.

Adding recursive DNS server information to the information transmitted within SLAAC. The standard suggests the addition of two items to Router Advertisement messages, namely recursive DNS server addresses and a list of the domains that should be searched during address translation (Domain Search List). This effort was made a standard only in 2010 as RFC 6106. It now depends on whether the creators of operating systems decide to implement this standard. So far, this support has been implemented in the RA daemon tool for Linux/UNIX (radvd), but it is not supported in other current systems – both routers and client systems. At the moment, it is very difficult to estimate how willing manufacturers would be to implement this extension to their systems. SLAAC is usually processed at the OS core level, and expansion to other items would necessarily mean changing it directly. We probably cannot expect support for this addition during a normal update.

Another proposed route was to define specific anycast addresses for recursive DNS servers. The client would send the translation request to this unicast address and the nearest Recursive DNS Server would provide an answer. A list of domains to search (Doman Search List) definitely did not solve this problem. The specification never went further than draft-ietf-ipv6-dns-discovery-07. Because it used Site-Local addresses, which were abolished by RFC 3879 in 2004, this proposal was abandoned. An implementation can be found on Microsoft systems.

A third proposed solution was the transmission of Recursive DNS Server addresses, and perhaps other parameters, with a very different protocol, independent of the SLAAC mechanism. Quite logically, there is an opportunity to use something already known, and that is DHCP .

2 DHCPv6

Assigning addresses with a DHCP server became the de-facto standard for IPv4. Reacting to this positive experience, there has been an effort to re-use this mechanism in the IPv6 world. However, contrary to what one might expect, DHCPv6 is not merely DHCP that has been adapted to IPv6, with mostly the same functions.

DHCPv6 features two basic modes. In practice, the first mode, Stateless DHCPv6, is only a layer on top of the autoconfiguration mechanism described above ( LAAC). Two special flags are used for this purpose in the router advertisement: M – managed, O – other. These tell the client that it should ask in the relevant network for more information related to the connection parameters, through DHCPv6. If the M flag is set, stateful DHCPv6 is used. If the O flag is set, SLAAC will most likely be combined with stateless DHCPv6. If both flags are reset, the end-user stations know that there is no DHCPv6 server available in the network.

In practice, communication after connecting the device to the network takes place in the following way:

• the client sends an RS (Router Solicitation, i.e., a request to send a Router Advertisement) to the network;
• it receives an answer from a router (a Router Advertisement);
• the client configures the interface parameters based on this answer, i.e., on the IPv6 address according to EUI 64, or Privacy Extensions;
• if the M or O flags were set in the RA, it continues by sending a DHCPv6 request, setting the parameters according to answers from the DHCPv6 server (such as, recursive DNS server addresses, search domains, or NTP servers).

The behaviour of stateful DHCPv6 is more like the behaviour of DHCP that is known from IPv4. The client learns from the Router Advertisement that it should get the network address with DHCPv6 (flag M set). The client asks the DHCPv6 server by multicast to have an address assigned. The server assigns an address to the client for a definite period, and the assignment is confirmed. However, this does not stop the client from also configuring addresses that it obtained based on the Router Advertisement. As a result, the client has an IPv6 address configured through SLAAC, and also an address obtained from the DHCPv6 server.

It would seem that the SLAAC mechanism could be completely de-activated, and everything would depend on DHCPv6 alone. This idea is certainly right – except for one detail. All of the required parameters can be transferred through DHCPv6 except the most important one, which is the default gateway. The client expects to receive this information only via the Router Advertisement. This means that the client can create “uncontrolled” addresses, either with EUI 64 or Privacy Extensions. This behaviour could be suppressed by setting (or resetting) the Autonomous option in the Router Advertisements. One practical problem remains: not on all devices, this option cannot be configured or changed.

2.1 DHCPv6 and the default router

Historically, there were efforts to integrate the default gateway (default router) into DHCPv6 as the draft-dromsdhc-dhcpv6-default-router-00, but the proposal was evaluated as unsatisfactory at the very beginning, and was not processed further. Those interested may study the related correspondence of the IETF group dhcpwg, which took place in 2009. There was another attempt to solve that problem in a more complex way, as described in draft-dec-dhcpv6-route-option-05, but that expired in April 2011. Now, the IETF is working on the third draft, draft-ietf-mif-dhcpv6-route-option02, which may be accepted as a standard in the future.

If an administrator decides to assign addresses through DHCPv6 and makes an effort not to let the terminal station get another address assigned by the DHCPv6 server, he faces another problem. Quite naturally, there is an opportunity to derive IPv6 addresses from an existing database of MAC addresses, which is run to assign IPv4 addresses, and this would create a similar environment for both protocols. However, there is a trap.

2.2 DHCP Unique Identifier

DHCPv6 does not use a MAC address to identify the client; instead, it uses a specially created unique identifier called a DUID (DHCP Unique Identifier, RFC 3315). The main idea behind creating such an identifier is to free the clients from dependence on hardware and on a specific network interface. The advantage is that a change of network adapter or a connection through another interface (such as WiFi instead of Ethernet) would not mean that the end-user station would start to behave as “someone else”. The standard defines three ways to obtain a DUID. The creator of the DHCPv6 client decides which one he chooses to use. In practice, this means that each system creates a DUID in a different way. If a PC has multiboot, with more than one operating system, then each system will have a different DUID. Most likely, the DUID will also change after reinstallation of the operating system. To use DHCPv6 in a network, while retaining a sufficient overview of who has which address, there is no other solution than to create completely different mechanisms and methods to register clients and end-user stations.

Thus, the IPv6 autoconfiguration options are not straightforward. There are two different sets of mechanisms and protocols, and one cannot work effectively without the other. Currently, it is not possible to configure Recursive DNS Servers addresses with SLAAC, but with DHCPv6 it is not possible to configure the default gateway address (default router). As a result, the only working method is to use both protocols and these are processed in different parts of the operating system – SLAAC as part of the kernel and DHCPv6 as a userspace process. Failure of either mechanism, whether through faulty configuration, poorly debugged software or targeted attacks, leads to denial of the communication for the end-node, and thus, for the user. Moreover, diagnostics are fairly complicated in this situation and require a good understanding of the way both mechanisms work.

3 Support for autoconfiguration in specific systems

The autoconfiguration situation is further complicated by the different support options for autoconfiguration in specific systems.

3.1 Microsoft systems, i.e., Windows 7, Vista 2008

These systems support all of the above-mentioned autoconfiguration options. In their default setting, they first attempt configuration through SLAAC. If they manage to get at least one answer through a Router Advertisement during three Router Solicitations, they configure their addresses according to the Privacy Extensions (RFC 4941). This behaviour can be suppressed by resetting the Autonomous flag in Router Advertisements for the relevant prefix. If the answer has the M (managed) or O (other) flag set, they will try to obtain more parameters through stateful or stateless DHCPv6.

If the system fails to obtain a Router Advertisement with three Router Solicitations, it will start to send requests to a stateful DHCPv6 server. If the network has a DHCPv6 server configured, it will give the client a network prefix, a global IPv6 address (normally just one, unless the configuration says otherwise) and other parameters managed by the stateful DHCPv6 server. As described above, this mode has no way of informing the client of the default gateway for outgoing packets.

3.2 Microsoft Windows XP

IPv6 is not active in the default settings. After installing the IPv6 support, it is only possible to configure the address through SLAAC. If there is a router present in the network that announces its existence through a Router Advertisement, the system will configure its IPv6 address using Privacy Extensions according to the older RFC 3041. The obsolete Site-Local addresses or anycast addresses are used for Recursive DNS Server addresses.

3.3 Apple systems, i.e., Mac OS X (PCs and laptops), iOS (iPhone, iPod, iPad)

These systems support autoconfiguration through SLAAC, and the latest software release, from July 2011 (MAC OS Lion, IOS 5), also supports DHCPv6. The system address is created by the EUI 64 algorithm, by default. With Mac OS X, it is possible to activate Privacy Extensions according to RFC 4941. The addresses of IPv6 Recursive DNS Servers can only be configured in the latest releases, which support DHCPv6.

3.4 Linux, FreeBSD and others

Generally, one can say that most UNIX-like systems support SLAAC, with addresses according to EUI 64. The DHCPv6 client is either part of the base installation, or it can usually be added from standard system packages. For instance, RedHat-based systems (Centos, Fedora) ask for the autoconfiguration method (SLAAC or DHCPv6) during installation. Privacy Extensions-based address support can usually be activated without difficulty (see Linux, FreeBSD).

4 Which autoconfiguration method to choose

The choice of a suitable autoconfiguration method is presently quite problematic. From a management viewpoint, stateful DHCPv6 with de-activated support for autoconfiguration is the best choice. The clients on the network can be relatively well controlled. This method is not supported by all systems and that remains its biggest disadvantage.

From the client viewpoint, SLAAC is a good choice and is supported by almost all systems. Consideration should be given to the addition of stateless DHCPv6 configuration. The addresses of Recursive DNS Servers can best be left to DHCP(v4) until one type of autoconfiguration prevails. The type that will eventually be favoured depends mostly on whether Microsoft and Apple will accept the addition of Recursive DNS Servers to Router Advertisement (RFC 6106), or support for DHCPv6 becomes widely implemented. Most likely, other manufacturers will then adapt to these key players. The IETF dhcpw working group might eventually succumb to the pressure of the manufacturers and include default route-support in DHCPv6. The results of that effort are currently being processed in draft-ietf-mif-dhcpv6-route-option-02 and await acceptance. The current situation, in which several protocols must be supported that are based on different principles, cannot be maintained for long and thwarts the whole idea of ‘simple’ autoconfiguration.

5 Conclusion

IPv6 autoconfiguration represents perhaps the saddest and most painful story in the whole IPv6 standardisation process. Ambiguities and delays in the inclusion of Recursive DNS Servers into mechanisms of stateless configuration has led to a host of alternative solutions. These solutions complicate the securing of the end-user nodes significantly, while at the same time permit fairly simple attacks. So far, it is not clear what form of autoconfiguration will eventually dominate. This creates complications for hardware and software manufacturers, who do not know what they should implement in their devices and products and in what way. The autoconfiguration tools do not bring any practical improvement compared to IPv4; on the contrary, the whole process is quite complicated, poorly arranged and much more vulnerable.

Today, most end-user systems that declare IPv6 support (older MAC OS systems, Win XP, mobile telephones and other devices) cannot function autonomously, without support for the IPv4 protocol. This is not a serious issue for the time being, because pure IPv6 networks (IPv6-only) are rare. However, this situation prolongs the period during which both the IPv6 and the IPv4 infrastructure will need to be operated, even in situations where it is otherwise not necessary. This is a matter for the future; yet the process of replacing all end-user devices is usually a long one, and it is a great pity that the issue of autoconfiguring devices has not yet been resolved satisfactorily.

The primary motivation for creating a new generation of the Internet Protocol was expansion of the addressspace. IPv6 offers a significantly longer length of addresses. Compared to IPv4, which, in theory, can provideaddresses for around four billion devices, the IPv6 protocol features an address length of 128 bits. This meansthat up to 3.4 x 1038 devices can be connected to the Internet. Such a number is hard to imagine. Several trillion addresses could be assigned to each person on the earth.

Another attempt to imagine the total address space would be as follows. If one were to assign one network witha length of 40 bits every second, this stockpile would last for 35 thousand years (it would last for 136 years witha prefix length of 32 bits). Hence, the total number of addresses can be considered to be truly unlimited.

An IPv6 address is written as 32 hexadecimal numbers, divided into quadruplets, separated with a colon. Thefollowing simplifications can be used when writing the address. Variants are shown, using as an example theaddress 2001:067c:1220:0004:0000:0000:93e5:0394.

All of the above formatting can be used to express the same address. There is also a format that uses numberpairs,separated with colons, i.e., 20:01:06:7c:12:20:00:04:00:00:00:00:93:e5:03:94, but this format is fairly rare,and is only used, for example, in Management Information Base (MIB) tree definitions.

The prefix length is another typical parameter that is specified in an IPv6 address. The equivalent of the prefixin an IPv4 network is a network mask. In an IPv6 network, the bit field format, which defines the part of theaddress that belongs to the network and host part, is not used; only the notation that defines the network masklength is used. This is recorded behind the ‘/’ symbol by specifying the number of bits in the network part of theaddress. The resulting address looks like this:Omit the introductory zeroes in each quadruplet 2001:67c:1220:4:0:0:93e5:394Omit the longest sequence of 0 and replace it with athe symbol ::2001:067c:1220:4::93e5:394Record the last 32 bits using the IPv4 notation 2001:067c:1220:4::147.229.3.14862001:718:802:4:250:56ff:feba:4a85/642001:718:802:4:250:56ff:feba:4a85/542001:718:802:4:250:56ff:feba:4a85/128fe80::c62c:3ff:fe36:4f4d/647

2 Address types

Like IPv4, IPv6 defines several address types1. The following table summarises the basic types of IPv6addresses currently in use, together with their equivalents from IPv4.

Some IPv4 address types were cancelled without replacement, while other new types have appeared.

2.1 Link-Local

Link-Local addresses are a revolutionary innovation. This is a special address type, which is in theconfiguration of each IPv6 device as soon as the interface comes up. Link-Local address cannot be cancelledor changed on some devices. Packets that use the Link-Local address can only spread within one networksegment, i.e., up to the first router.

Link-Local addresses can easily be recognised by their unique combination fe80::. A full Link-Local address appears as:

fe80::20c:29ff:fec9:92df/64

A special feature of these addresses is that an address on one device often has the same value on variousinterfaces. Usually one must add a name or some interface identifier right after the % symbol to identify theinterface that one wants to communicate with.

The existence of Link-Local addresses enables moving a large part of the communication to this level,especially in the signalling field. For example:

• All signalisation at the local level: neighbour discovery (ND), router advertisement (RA), detectionof duplicate addresses etc. For example, IPv6 does not use the Address Resolution Protocol (ARP). Allfunctions of this protocol were moved to ICMPv6 (Internet Control Message Protocol version 6) signallingmessages, which use only the Link-Local address.
• Routing protocols such as IPv6 Dynamic Routing and Redistribution (OSPFv3/RIP-NG). A positiveresult is the disappearance of the need to configure the connecting network between individual router interfaces. It is only necessary to assign the relevant router interface to the OSPFv3 or RIP-NG processand that completes the configuration of the connecting network between routers.

However, Link-Local addresses can sometimes be used for communication between nodes. Because Link-Local addresses can only reach the local network, no special security measures would seem to be required.However, it is possible to communicate in any network through Link-Local addresses; hence it would be amistake to enter the following record into /etc/host.allow:

ALL : [FE80::]/64 : allow


If this occurs, the user’s services would inadvertently be offered to all neighbours, in all of the networks wherethe user appears, e.g., to all the ‘bad guys’ connected to the same WiFi network. Communication on Link-Localaddresses should also be blocked at the corporate-firewall level. No one could communicate through theseaddresses, but an attacker could use a good, counterfeit Link-Local address, entered as a source address in apacket. In addition, the end system should automatically discard all packets that have the Link-Local address inits source and that have the destination address set as global.

2.2 Broadcast

There are no broadcast addresses in IPv6. All communication that used broadcast in IPv4 has been moved tomulticast, without exception.

2.3 Unique-Local, Site-Local

Another group of addresses are the IPv6 addresses that can be compared to the private addresses in IPv4. In IPv6, the equivalent addresses are Unique Local IPv6 Unicast Addresses(ULA)2, defined in RFC 4193. Like private IPv4 addresses, they can only be used within a limited location and must not be routed to the global Internet. They have one key advantage, compared to private IPv4 addresses. The algorithm to create anetwork prefix is designed to be unique. A prefix is created through an algorithm, into which a date and the MAC address of a device are entered. This should ensure that the prefix created is unique. Those who stilldoubt the uniqueness of their ULA addresses can use a registration obtained from a database managed within theSixXS3 website.
On some systems, and even in recent literature, one can still find Site-Local addresses. In contrast to ULA, theyare not unique, and resemble the private addresses of the IPv4 protocol. Using these addresses proved to be a dead-end, and Site-Local addresses were abolished byRFC 38794 in 2004. The address block ec0::/10 assigned to these addresses should no longer be used.

2.4 Multicast, Anycast

Group (multicast) and selection (anycast) addresses will be described, in detail, in a separate document, andonly their existence is mentioned in this report.

2.5 Global

The one remaining address type are Global addresses. These are the most important addresses and globalInternet nodes communicate through them.

3 The network part of global addresses andnetwork structure

There was an effort to divide addresses in the global Internet, so that, if read from left to right, they would reflectthe physical structure of the network. The highest level has address blocks managed by IANA5. It assignsblocks to individual regional registries (RIR), i.e., RIPE NCC, ARIN, APNIC, AFRINIC, and LACNIC. Regional registries then assign these blocks to local registries (LIR), which connect the end-user networks. Each of these networks then receives its own prefix, which can be divided further. It was assumed that each end customer(user) would get an assigned network with a prefix length of 48 bits, leaving sixteen bits for internal addressing.In practice, with a prefix length of 64 bits the customer can create 65,535 end networks. There is still an ongoing discussion about whether the assignment of a prefix of 48 bits to normal users is a waste, and hence, the current
draft6 sets this length to 56 bits. As a result, 256 subnets can be created in this way and 264 devices could be addressed in each subnet, which should be a sufficient number for end customers.

Figure 1: The structure of the IPv6 address

3.1 Home networks

The assignment of addresses to smaller or home networks is still open to discussion. Currently, a single IPv4address is assigned to a network and an end device is connected directly to this address, or it can beconnected to private addresses through Network Address Translation (NAT). The existence of NAT isunacceptable for IPv6. Therefore, the question remains how to assign addresses to home networks. A box athome might be seen as an L2 switch, L3 switch or even some form of IPv6 NAT.

The fairly simple solution that is used in IPv4 networks, becomes significantly more complicated in the IPv6world. Providers who have decided to implement IPv6 for customers connected in this way face a significantproblem. They could choose one of the following solutions, but none of these is trouble-free. The issue isfurther complicated by the fact that during the transition period, which will be quite long, the current IPv4 infrastructure with its NAT mechanism will operate in parallel. This problem can be resolved in three ways.

IPv6-NAT: NAT should be completely eliminated in IPv6 networks. There are efforts to introduce NAT to the IPv6 paradigm, but so far, these are only proposals. A working and usable implementation is probablyimpossible to find. One compromise solution could be the stateless mapping of ULA addresses to publicaddresses as proposed in an Internet
draft7Draft7. There is an implementation of this solution is available, in anexperimental form, as Linux
netfilter8. Some modifications would have to be made in order to make it usable in this mode. This solution is the least popular.A device in the L3 router mode: In this solution, a home router would provide address translation throughNAT for IPv4, and it would provide a complete L3 router for IPv6 operation. This raises the questions of how a home router could be informed of the internal network prefix and vice versa, and how the routing record on the Internet Service Provider (ISP) side that would point to networks behind the home router can be created. A special DHCPv6 option with prefix delegation name (RFC 3633) is used for this purpose, and it tells the home device about networks which it should use for internal addressing. The requirements are detailed in an Internet
Draft9, but so far, it is unclear whether manufacturers of home routers and ISPs will accept it. Relying on theISP to create the routing records also remains an issue. With thousands of users (customers), this may not be a negligible issue, and the mechanism must somehow be automated. The solution suggested in another Internet Draft10 assumes that the provider’s router (PE) will create these records, based on the contents of the communication between a DHCPv6 server and DHCPv6 agent. However, there do not appear to be any devices that would support this option. This is the most complicated form of connecting home networks, but so far, the prevailing opinion is that this is the ‘clean’ and ‘correct’ solution.

A device in the L2 router mode: This solution is based on connecting the provider’s port and the local network at the link level, which involves a bridge or switch. At first glance, this is a simple solution and would not require more standards, but it is not without problems. Since IPv6 will need to coexist with IPv4 for quite some time, this solution is almost out of the question. A variant worth considering is L2 bridging/switching only of those packets that belong to the IPv6 protocol. This variant is easy to use in theory, but so far, there is no device on the market that would provide this functionality. Another significant disadvantage of this solution is that all of the user’s devices are in the same subnet as a neighbouring laptop, coffee machine, or washing machine. This creates new security problems in the network, which are not insolvable. However, at present, there is not much attention given to home devices that would work in this way.

There do not appear to be any significant variants to the options presented. Unfortunately, there is nostandardised and generally usable method to connect home networks at the present time. Even if themanufacturers of home routers want to implement support for IPv6 into their devices today, they are faced withthe problem that they do not know how to accomplish this. At this time, it would be quite hard to tell what theIPv6 support declared on the package of this type of equipment actually means, and whether such a devicewould be obsolete in a year or two. More documentation on some devices is available on the
SixXS11 pages. It is evident that IPv6 support has a different meaning for each producer. Certification with a silver or golden ‘IPv6 Ready’ logo will not be of much help, because the criteria for IPv6 support for this type of device are not part ofthe certification. A DHCPv6 certification is required. In current practice, the support for home devices focuseson static IPv6 routing and it may also feature support for migration mechanisms. Only a few devices offersupport for the delegation of the DHCPv6 prefix, and this is usually at a very experimental level.

3.2 Multihoming

Another complication with the assignment of network addresses is related to the opposite end of the range ofclients of IPv6 networks – large corporations. The original idea to divide addresses hierarchically, according tonetwork topology, is certainly very good. It significantly reduces the number of records in the routing tables dueto aggregation of individual prefixes. Multihoming, i.e., connecting the network to multiple providers, breaks thisconcept. In the IPv4 protocol, full-featured multihoming is almost entirely solved by the assignment of adedicated autonomous system (AS) and the allocation of a special address space (PI – provider independent
address12). Routers that connect the network to multiple providers through the Border Gateway Protocol (BGP)then provide connection to the routing of the global Internet.

Creators of the IPv6 protocol tried to solve the multihoming problem with a totally different concept, in order tomaintain the hierarchical network structure. The Shim6 protocol (Site Multihoming by IPv6 Intermediation)provides some hope, but it is only a proposal at this stage and has only one, mostly experimental,implementation13.

It will certainly be a long time before this protocol can be used in practice.

Since no acceptable and working solutions have been found so far, it was inevitable to try out an already testedmechanism in the form of allocation of provider-independent (PI) addresses. However, each PI networkgenerates a separate routing record on the level of the global routing table in BGP, and this breaks the originalconcept of optimised routing. The multihoming question will be addressed in a separate document.

4 End-user networks

The remaining part of the address is designed to identify individual devices in end-user networks. Usually, andalmost without exception, networks with a prefix of 64 bits are assigned. This divides the IPv6 address into twoparts: the network part in the most significant 64 bits and the host part (Host ID or Interface ID) in the leastsignificant 64 bits. Some may consider such division as quite wasteful. To have 64 bits for addressing within asingle network segment is certainly an indulgence, but this division has already become ingrained and anyattempts to use terminal network prefixes, other than 64 bit, would face a whole host of practical complications.Unless there is an extremely good reason, prefixes longer than 64 bits should not be used, even if there areonly two or three devices in the network.

4.1 The host part of the address – Host ID, Interface ID

In the past, at the time of Internetwork IPX/SPX networks, it was not necessary to burden oneself with theaddressing mechanism of terminal stations. A card was inserted into a PC and the PC was connected to thenetwork. This was the entire configuration. The network layer address was derived from the network-card linkaddressand that was all that had to be done. Of course, this simple solution was impossible for IPv4 networks,because of the relatively small space for addressing the devices in the end-user networks. The possibilities arecompletely different with the IPv6 protocol. The space reserved for the host part is 64 bits. Such abundantaddress space enables things not seen before.

4.2 IPv6 addresses EUI-64

The first proposals assumed that the host part of the address would be derived from ‘something’ that alreadyhad an address. Using the existing link-layer address, i.e., the MAC address was the obvious thing to do.Mapping 48 bits (the MAC address length) to 64 bits was no problem. The IPv6 EUI-64 algorithm to create thehost part of the address was made through a small modification of the IEEE EUI-64
algorithm14.

4.3 Mapping the IPv6 EUI-64 addresses

As illustrated in Figure 2, moving forward and backward can be done simply and effortlessly, and the relationbetween both addresses is obvious at first glance. This very simple and practical way of creating IPv6addresses began to meet serious problems because of privacy protection. Since the host part of the addressdoes not change if a laptop or cell phone is moved anywhere, it is very easy to discover which specific devicehas accessed the relevant service and also from which network. This kind of address creation is implementedand activated by default in most operating systems (MAC OS, Linux, and FreeBSD) and devices.

Figure 2: Mapping the IPv6 EUI-64 addresses

4.4 Privacy Extensions

The issue of privacy led to consideration of how it can be avoided that end-user devices are simply identified. Asolution called „Privacy Extensions“ (Privacy Extensions for Stateless Address Auto configuration in IPv6) wascreated, initially as
RFC 304115 and later replaced by RFC 494116. The Privacy Extension concept is based onrandom generation of the host part of the IPv6 address. Addresses created in this way change at regularintervals. Typically, a new address is created each day or each week and is maintained in the system for tendays. The IPv6 address of the end-equipment is created randomly, cannot be predicted, and changescontinuously – thus, each of these features is a nightmare for network administrators. It is obviouslyunacceptable for them to have devices in the network that they cannot identify. Privacy Extensions are, bydefault, activated in all Microsoft end-user systems (Windows 7, Vista, XP). Privacy Extensions can beactivated for most other systems (Mac OS, Linux, FreeBSD) in their configuration. Figure 3 shows some IPv6addresses in Windows XP after a week of non-stop operation.

Figure 3: Random IPv6 addresses in Windows XP

Since the identification of terminal devices in the network is fairly critical for administrators to maintain order, itis a problem that must be solved. One possibility is to deactivate Privacy Extensions on client systems directly,but this abridges the users of their privacy, and reconfiguration of all devices that appear in the network issimply not feasible. With time, this extension will probably be activated by default in most systems, following theMicrosoft example.
One solution would be to collect the content of Neighbour Cache tables on the router. This is similar to the ARPtable from IPv4. Just like the ARP, the Neighbour Cache contains the link address (MAC address) and its IPv6address or addresses. If the IPv6 – MAC address is known, some conclusions can be derived from theirrelation. For instance, if the network supports authentication through IEEE 802.1X, this data can be connectedwith the authentication data of the RADIUS server. The following chart shows the content of Neighbour Cachereceived in this way, and illustrates how the PC communicates with different IPv6 addresses in specific timeperiods during one week.

Figure 4: Temporary IPv6 addresses in the system within one week

So far, there are not many tools that can deal with this problem. One tool that can be used is MetaNAV17. It reads the contents of router Neighbour Caches regularly with the Simple Network Management Protocol(SNMP) and saves the data in a database. This database can subsequently be connected with another internalsystem. The web interface offered by MetaNAV can also be used.

Figure 5: A look at IPv6 addresses in MetaNAV

Another option is to use a tool that can analyse the contents of signalling protocols. Since all signalling takesplace at the multicast level, it is easy to acquire this information through any device connected to the localnetwork. The tool favoured by many in the IPv4 world is arpwatch18. One alternative for use in IPv6 is NDPMon19. However, the development of this project has been stagnating since 2009, and the system isburdened with a large number of errors. Nonetheless, it is usable with some effort.Network monitoring is another issue in IPv6. Some practical ideas to perform IPv6 network monitoring aredescribed in a separate best practice document, CBPD 132 “Practical IPv6 Monitoring on Campus”20.

4.5 Manual IPv6 configuration and other options

The options for IPv6 address configuration described above are mainly suitable for client stations. The option touse manual configuration remains the same as with IPv4. This option is used, in particular, for servers. Forthese, a simplified definition of the IPv6 address can be used by writing the last 32 bits in the form of an IPv4address. This also empowers creative administrators. They can embed a useful note, message, or alert in thehost part of the IPv6 address of their favourite colleague or boss for others to see. Below are a few inspiringexamples showing that the IPv6 system is entertaining and fe80::c00l:
2001:0fa:fff0:fe00:dead:face:c156:7b93
2001:15c0:6603:add:bad:dad:c0b0:1
2001:15c0:6603:0:fade:b00b:babe:1
2001:968::c0f:fee
So far, the options of address configuration through DHCPv6 or using a cryptographic method via SeND havenot been mentioned. These options will be addressed in a separate report, focused on the autoconfiguration ofterminal equipment and safety.

5 Conclusion

The initial motivation to create the IPv6 protocol was the need to extend the address space. At this moment, itcan be said that this requirement has been fulfilled. The hierarchisation of addresses has the potential toenable much more effective management of routing information at a global level. This concept has beensomewhat broken by the concept of PI address allocation. Sadly, the mechanism of address allocation to homenetworks remains unstable. This is not so much an issue of the address space itself; rather, it is an issue of thegradual stabilisation of standards and technologies.
At the level of the end-user network, IPv6 offers some completely new possibilities for creating addresses inend-user systems. The creation of IPv6 addresses in client systems with Privacy Extensions is the mostsignificant change. It can be expected that, following the Microsoft example, this extension will be used by mostclient systems. This innovation has complicated the management of local networks, and it will probably changethe way we look at network management and network-management habits significantly.

6 List of Figures

Figure 1: The structure of the IPv6 address
Figure 2: Mapping the IPv6 EUI-64 addresses
Figure 3: Random IPv6 addresses in Windows XP
Figure 4: Temporary IPv6 addresses in the system within one week
Figure 5: A look at IPv6 addresses in MetaNAV

[1] http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
[2] http://www.ietf.org/rfc/rfc4193.txt
[3] http://www.sixxs.net/tools/grh/ula/
[4] http://www.ietf.org/rfc/rfc3879.txt
[5] http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml
[6] http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites-01
[7] https://tools.ietf.org/html/draft-mrw-nat66-07
[8] http://sourceforge.net/projects/map66/
[9] http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09
[10] http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt-02
[11] http://www.sixxs.net/wiki/Routers
[12] http://www.ripe.net/ripe/docs/ripe-509#9
[13] http://www.openhip.org/
[14] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[15] http://tools.ietf.org/html/rfc3041
[16] http://tools.ietf.org/html/rfc4941
[17] http://metanav.uninett.no/
[18] http://ee.lbl.gov/
[19] http://ndpmon.sourceforge.net/
[20] http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd132.pdf