CGN, IPv6 and fighting online crime…

By on 30 Mar 2018

Category: Tech matters

Tags: , , , ,

1 Comment

Blog home

Carrier Grade NAT (CGN) is commonly used by network operators as a way of eeking out the limited supply of public IPv4 addresses. This is where private IPv4 addresses are allocated to end customers, who in turn also use private IPv4 address ranges on their own Local Area Networks, which means there can be multiple layers of Network Address Translation (NAT) before traffic reaches the publicly addressed Internet.

While CGN offers something of a technical solution to the shortage of public IPv4 addresses, it presents a number of problems for investigating and solving online crime. A CGN environment means that many hundreds of users can be sharing a single public IPv4 address, so that when a crime is committed, tracing the perpetrator is very difficult. Furthermore, sometimes action needs to be taken against a public IPv4 address that’s the origin of particular problems, but this then penalizes many hundreds or even thousands of innocent users who may also be sharing that IP address.

Europol, the European Union Agency for Law Enforcement Cooperation, has identified that CGN is an impediment to investigating online crime, and is, therefore, consulting the Internet community on how network operators can be encouraged to deploy IPv6.

To facilitate this, a meeting of the European Cybercrime Centre (EC3) Advisory Group on Communication Providers was held on 19 February 2018 in Den Haag, The Netherlands. This involved some of the biggest European ISPs, the European Telecommunications Network Operators Association (ETNO), representatives of the European Commission, and several external experts from the community including Eric Vyncke (Cisco), Marco Hogewoning (RIPE NCC) and myself from the Internet Society.

I’d remotely attended a previous meeting of this group and presented on the issues around CGN. At this meeting, I introduced three IPv6 Best Current Operational Practices (BCOP) documents, why they were produced, and how they were developed with the consensus of a wide group of network operators.

The first document was RIPE-554 ‘Requirements of IPv6 in ICT equipment’ that can be used during equipment evaluation and in RFP creation to ensure IPv6 support in hardware and software. It provides a list of IPv6 requirements that vendors must meet in order for you to purchase their equipment.

The second document was RIPE-631 ‘IPv6 Troubleshooting for Residential ISP Helpdesks’ that offers guidance to helpdesks which have to deal with Internet connectivity problems. It’s a simple set of detecting/understanding/solving instructions for helpdesk staff when users report IPv6 issues.

The last of the documents was RIPE-690 ‘IPv6 prefix assignment for end-users: persistent versus non-persistent, and what size to choose’. This offers operational guidance on how to assign IPv6 prefixes to end customers and the consequences of making wrong choices when designing an IPv6 network.

Some of the wider discussion at the meeting focused on how to deal with the issues around CGN that concern law enforcement, and tracing attackers by searching sessions logs in network operator firewalls. However, while this is feasible in a smaller setup, a CGN can create millions of sessions every second and logging to the extent necessary becomes extremely expensive in an industry where profit margins are quite low.

The meeting concluded that an IPv4-based Internet with layers of CGNs will be unscalable and unaffordable as the Internet grows further, but from a law enforcement perspective also limits the effectiveness of solving online crime. It was therefore agreed that IPv6 deployment needs to be supported and accelerated on the Internet.

IPv6, of course, offers an almost unlimited supply of addresses, which could allow every end user device to have a public IPv6 address without the need for complex translation and logging systems. This may make it easier for law enforcement to identify the source of suspicious or criminal behaviour and who might be behind it. However, there are a number of privacy considerations associated with IPv6 (see RFC7721), and in 2007 the IETF published RFC4941 that defined IPv6 privacy extensions, which is explained in more detail in a blog written by my colleague Dan York.

Further Information

The Internet Society also encourages IPv6 deployment, so please see the Start Here page to understand how you can get started with IPv6.

Original post appeared on the Internet Society Blog.

Jan Žorž works for the Internet Society (ISOC) and is an IPv6 specialist.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

One Comment

  1. Jordi Palet Martinez

    I will say this Europol publication explains it very well as well, so worth to mention:


Leave a Reply

Your email address will not be published. Required fields are marked *