ipv6 test

Domein Checker

Check of uw domein IPv6 ready is.

Domeinnaam:





 

IPv6 and privacy

Dutch IPv6 Task Force
Author: Erik Huizer 
Date: 18-10-2010 (updated 15-02-2012)

Many thanks to the members of the NL IPv6 Task Force for their contributions

Introduction
Since the standardization of IPv6 in the 1990’s, there have been many
discussions about IPv6 and privacy. This document aims to address the
concerns with regard to IPv6 and privacy and points out some solutions.

The privacy concern
The main concern with regard to IPv6 and privacy is that some users will use the same IPv6 address every time they go online, which makes it easier for ISP’s and service providers to track their online behavior. The IPv6 address can then easily be linked to a single person and becomes a piece of personal information. 
  
This is a justified concern that has also been recognized by the IPv6
community. There are solutions to this concern, which will be presented later in this document. First however, we’ll have a look at the context.

Context
De current IPv4 Internet has an address shortage. Because of this shortage, a mechanism of dynamic address assignment has come into existence, in which a home user is assigned a temporary Internet address for the time he or she is online (this can however be a fairly long time, for ADSL/cable connections the same address may be assigned for years). The assigned address originates from an address pool with a limited number of addresses that belongs to the user’s ISP. The assigned address is shared by all systems (computers, laptops, tablets etc) used by the household. This means a single IP address cannot be unambiguously linked to a user (but it can be linked to a household). Service providers on the Internet who like to build customer profiles and therefore want to track the user’s online behavior, will have to put some more effort in to successfully achieve user profiling. For this purpose they use (a combination of) the following methods:
-Cookies; By leaving behind a cookie at the end user’s device his/her surfing behavior can easily be resolved to a single person. (http://en.wikipedia.org/wiki/HTTP_cookie)
- Characterization of behavior; in particular the company Doubleclick (taken over by Google) is specialized in analyzing and storing the surfing behavior of users. This analysis enables them to quickly“recognize” a user and link the user to a unique customer profile.
- Javascript. By running small pieces of code it is possible to retrieve the MAC address of a computer or mobile phone, which can be used to access a network.

Other methods exist, but these are most commonly used. The first two of these methods are more specific than the use of a unique IP address. They
actually do resolve to a user, while the third method or the use of an IP address resolves to a system that may be shared by multiple users.

By the way, users in an organization (company, school etc.) that go online use either a fixed IP address or an IP address from a very small pool of
addresses. For them there already exists a privacy concern in IPv4, that is exactly the same as the privacy concern for IPv6 discussed in this memo.

When using mobile Internet a user usually receives a temporary IPv4 address every time he/she goes online. However, with increased use of mobile Internet a single device (smart phone), that is usually ‘always on’, is uniquely linked to a single user. This results (regardless of which IP version is used) in privacy concerns. (for a good analysis for these privacy concerns and how to prevent them, take a look at: http://tools.ietf.org/html/draft-brim-mobility-andprivacy-
00).

Finally, most European ISP’s are compelled by law to apply eavesdropping methods to assist security forces in tracing people. From that point of view there is no difference between IPv4 and IPv6.

This context does not justify ignoring privacy issues when using and
configuring IPv6 addresses. It does however clearly provide the context that if we solve the problem of unique IPv6 addresses (which is relatively easy as will be described in the next section), this does not take away the other privacy concerns described in this paragraph. That is, the concerns about privacy described in this paragraph are independent of the used IP protocol (IPv4 and IPv6).

IPv6 and the privacy concern
When handing out addresses in IPv6, auto configuration is often used. In that case a computer or mobile phone that wants to connect to the Internet gets the first part of the IP address assigned to it and the second part has to be generated by computer itself. One of the possibilities to generate this second part is by using the MAC address of the computer. It is clear that when using the unique MAC address in an IPv6 address, a situation occurs where the IPv6 address can be resolved to a device, and therefore often to a person. This is exactly the situation that caused the IPv6 privacy concern in the first place.

However, in the IPv6 standard there are several other ways to assign an address to a system (computer, laptop, mobile etc.). Organizations can use mechanisms that are comparable to what is currently available in IPv4. Practice proves that organizations usually use address auto configuration.

Usually auto configuration is also used for home and mobile users. In IPv6 there is the possibility to use a randomly generated number for the second part of the address (RFC4941). This number will be different every time the system appears online, which makes traceability of the system, based on the IPv6 address alone, impossible.

This last method creates a situation that goes a long way to meet the objections in the area of privacy around IPv6. Moreover, the IPv6 address pool from which the random number can be selected is much larger than the IPv4 address pool that is available for dynamic addresses.

Application
Does is clear up the IPv6 privacy concern? Not quite. Most operating systems that are currently available and support IPv6 (MacOS, Linux, Windows etc.) can handle auto configuration. They support both the option of using the MAC address for the second part of the IPv6 address (=privacy sensitive) and the option of using a randomly generated number (= not privacy sensitive).

Therefore it is essential what the default behavior of the operating system is with regard to this issue. The fact that a user can choose is nice, but not really relevant since most users (hopefully) don’t know what IPv6 is and are (fortunately) unaware of this choice.

Windows and the latest versions of MacOS, Ubuntu etc. use the default setting that the second part of the IPv6 address is randomly generated. Older versions use the MAC address by default. These older operating systems thus require an action from the user to better protect their privacy. In mobile operating systems most commonly a randomly generated address is used, however in some cases this is still under development.

So, the problem is not in IPv6, it is in the default settings of some operating systems.

Additionally firewalls need to be carefully configured to avoid snooping of the so called IPv6 EUI-64 address that is required for identification in any Internet connection. However this protection against snooping is no different from similar effects we currently have with IPv4.

Consequences of a randomly generated address
‘For every advantage there is a disadvantage’ (Famous quote by Dutch football player Johan Cruijff). Generating a random number as the second part of the IPv6 address makes that surfing behavior cannot be resolved to a single user or system, at least by using the IPv6 address. However, it also comes with some drawbacks.

On the Internet, every IP address is linked to a domain name. This is true for services (website), like www.cbpweb.nl which is linked to the IP address: 62.250.16.82. For home users this is also case. A home user’s assigned IPaddress is also linked to a domain name by the ISP. For example: Home user appears online and gets the IPv4 address 191.12.31.7. The ISP then links this to a domain name: 7.31.adsl-arnhem.isp.nl.

Including this registration in the Domain Name System is necessary, since many websites and mail systems check this domain name in their efforts to block spammers and Bots.
 
In IPv4 the address pool is limited and the ISP just includes all the IP addresses in the Domain Name System to make such a link.

In IPv6, there is a virtually unlimited number of addresses and with the huge amount of possible randomly generated addresses for the second part of the IPv6 address, it is impossible to include all IPv6 addresses in the Domain Name System. This means that when a randomly generated IPv6 address assigned, a registration should be included immediately in the Domain Name System. (and even more difficult: the registration should be removed at the time the system goes offline and the IPv6-address is no longer used).

This is a technological challenge that will require a huge investment from ISP’s that will not remain without consequences for the users with regard to the price of their subscriptions and performance of their connections.

Conclusions
The uninformed use of IPv6 auto configuration can lead to a situation in which a system uses a unique IPv6 address that enables service providers to resolve surfing behavior to that system (computer, laptop, mobile, etc.). Therefore it is highly recommended to point out this danger to developers of operating systems and to request to make the use of randomly generated IPv6 addresses the default configuration of their operating system.

Fortunately we see more and more operating systems with a default configuration that generates random IPv6-addresses. However, while this helps to alleviate any concerns around privacy and the usage of IPv6, this is by no means a solution for the problem that privacy is put under pressure by parties that record surfing behavior of users. There are numerous other methods to resolve surfing behavior to a single system or even to a single person (as described in the paragraph ‘Context’). IPv6 does not add to nor detracts from this fact.
 

References
RFC 4941: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6, http://tools.ietf.org/html/rfc4941

Geen reacties

TMA, IMG100.000+ en VIAG onderschrijven belang IPv6

Leidschendam/Woerden – 13 januari 2012 – TMA (Telecom Management Association), IMG100.000+ (de vereniging van automatiseringsmanagers van de grote gemeenten) en VIAG (Vereniging van coördinatoren I&A van Gemeenten) ondertekenen het IPv6 Manifest van de Nederlandse IPv6 Task Force. Zij onderstrepen hiermee het belang dat zij hechten aan tijdige voorbereiding door decentrale overheden op en integratie van IPv6 in alle onderdelen van de ICT-architectuur. Zij roepen andere partijen op het Manifest ook te ondertekenen. De ondertekening vond plaats in aanwezigheid van onder anderen Erik Huizer, voorzitter van de IPv6 Task Force.

 

De ondertekenaars van het Manifest André de Kok (voorzitter TMA), Anton Dekkers (voorzitter IMG100.000+) en Roel Bakker (lid dagelijks bestuur VIAG) roepen decentrale overheden op samen te werken, zodat zij in staat zijn IPv6 tijdig en kosteneffectief te introduceren. Er is veel winst te behalen bij het gezamenlijk in kaart brengen van de IPv6-geschiktheid van aanbieders en hun diensten en producten en het uitwisselen van kennis en ervaring bij de integratie van IPv6 in de ICT-omgeving van decentrale overheden. De subgroep ‘decentrale overheden‘ van de IPv6 Task Force zal bij voldoende steun de coördinatie hiervan op zich nemen.

 

Alle overheden zijn sinds november 2010 verplicht bij aanbestedingen te vragen om IPv6-geschiktheid volgens de specificaties van het College Standaardisatie. Decentrale overheden zelf geven momenteel te weinig prioriteit aan dit onderwerp. Zowel de IPv6 Task Force als de Vereniging van Nederlandse Gemeenten (VNG) en het Interprovinciaal Overleg (IPO ) vinden het belangrijk dat te veranderen. Als IPv6 niet tijdig wordt opgepakt dreigen beperkingen in de groei van de digitale dienstverlening en onnodig hoge kosten bij implementatie.

 

De ‘Subgroep decentrale overheden’ van de Task Force IPv6, met name TNO en Tholhuijsen Consultancy, hebben in het afgelopen jaar, in overleg met VNG, IPO, Forum Standaardisatie en vertegenwoordigers van gebruikersverenigingen over mogelijke maatregelen, het Manifest voorbereid. De gekozen aanpak wordt nu dus ook gedragen door TMA en IMG100.000+ en zal bij voldoende steun in gemeente- en provincieland leiden tot een platform voor het uitwisselen van ervaringen met IPv6-implementaties. Op de website van de IPv6 Task Force zal een overzicht komen van de IPv6-geschiktheid van ICT-aanbieders aan de decentrale overheden.

Geen reacties

IPv6 op ‘pas toe of leg uit’-lijst van College Standaardisatie

Sinds 25 november 2010 staat IPv6 in combinatie met IPv4 op de ‘pas toe of leg uit’-lijst van het College Standaardisatie (zie: https://lijsten.forumstandaardisatie.nl/open-standaard/ipv6-en-ipv4). Om interoperabiliteit met zowel de nieuwe IPv6-praktijk als de bestaande IPv4-praktijk te borgen, heeft het College Standaardisatie beide versies van de standaard op de ‘pas toe of leg uit’-lijst opgenomen.

De opname betekent dat iedere overheidsorganisatie bij aanschaf van een ICT-dienst of -product moet kiezen voor zowel IPv4 als IPv6 (‘pas toe’). Als er een gewichtige reden is, dan mag een organisatie een afwijkende keuze maken. Daar staat tegenover dat in het jaarverslag verantwoord moet worden waarom deze afwijkende keuze is gemaakt (‘leg uit’). Daarnaast beogen College-leden met de opname zichzelf te binden tot het gebruik van IPv4/IPv6 en doen zij een oproep tot gebruik aan alle (semi-)overheden.

Voor de Rijksoverheid is ‘pas toe of leg uit’ vastgelegd in de Rijksinstructie (zie: https://zoek.officielebekendmakingen.nl/stcrt-2008-837.html ). Voor andere overheidsorganisaties is dit vastgelegd in bestuursakkoorden en convenanten (zie: http://www.forumstandaardisatie.nl/open-standaarden/over-open-standaarden/het-pas-toe-of-leg-uit-principe/).

In 2006 richtte het kabinet met een instellingsbesluit het College en Forum Standaardisatie op. In het College zitten topbestuurders van verschillende overheden. Het College maakt afspraken voor de overheid over te gebruiken standaarden en bevordert interoperabiliteit tussen overheden onderling en tussen overheid, bedrijven en burgers. Het Forum bestaat uit experts uit het bedrijfsleven, de wetenschap en de overheid. Het Forum adviseert het College. Het mandaat van Forum en College Standaardisatie is onlangs verlengd tot 2015 (zie: https://zoek.officielebekendmakingen.nl/stcrt-2011-23581.html ).

Geen reacties