CGN, IPv6 and fighting online crime… Thumbnail
‹ Back
Improving Technical Security 10 March 2018

CGN, IPv6 and fighting online crime…

Jan Žorž
By Jan ŽoržFormer Operational Engagement Programme Manager
Carrier Grade NAT (CGN) is commonly used by network operators as a way of ekeing 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.
Whilst 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 penalises 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 (Jan Žorž) 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 help desks who have to deal with Internet connectivity problems. It’s a simple set of detect/understand/solve 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 deal with the issues around CGN that concern law enforcement, and tracing attackers by searching sessions logs in network operator firewalls. However, whilst 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 RFC 7721), and in 2007 the IETF published RFC 4941 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 Start Here page to understand how you can get started with IPv6.
4 / 5
‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Hello IPv6, Goodbye CGNs – Recent Discussions at a EU/Europol Meeting
Hello IPv6, Goodbye CGNs – Recent Discussions at a EU/Europol Meeting
Deploy36024 October 2017

Hello IPv6, Goodbye CGNs – Recent Discussions at a EU/Europol Meeting

Jan Zorz was recently invited to speak at a workshop held by the Estonian Presidency of the Council of the...

The Network Forensics problem of IPv4
Deploy36010 March 2017

The Network Forensics problem of IPv4

Although not directly on the subject IPv6, we absolutely need to draw your attention to a great presentation from Geoff Huston (APNIC)...

The Business Case for IPv6 in Pakistan
Deploy36021 February 2017

The Business Case for IPv6 in Pakistan

We had a very successful ION conference in Islamabad on 25 January 2017, and amongst the interesting topics presented at the...

Join the conversation with Internet Society members around the world