Today's ARIN estimated depletion date:

Archive for January, 2009

RIPE NCC gets new space from IANA


Posted by admin  |  No Comments »

Two days ago, IANA assigned the and to RIPE. This brings the IANA pool down to 32 free /8. This new infusion of about 32 million addresses brings the RIPE pool to about 40 million addresses. This is still not sufficient to cover the 9 months demand that the IANA policy stipulates. I expect RIPE to allocate more space this summer.

RIPE below 50% of a /8


Posted by admin  |  No Comments »

I have been writing about the low RIPE NCC pool for a while now. I don’t know why RIPE NCC is waiting this long before they request more space from IANA. The RIRs are suppose to request new space when they can’t cover 9 months demand or when their pool is below 50% of a /8 (about 8 million addresses). RIPE has not been able to cover 9 months demand for a while now. Interestingly enough, the RIPE free pool is now below 50% of a /8 so they have two reasons to request more space from IANA.

Italy gets 2 Million Ipv4 from RIPE


Posted by admin  |  No Comments »

Yesterday, RIPE NCC assigned a /11 or about 2 Million addresses to Telecom Italia Wireline Services. After this allocation, RIPE NCC has only about 11 Million unallocated addresses in its pool.


pMTU discovery, covert channel in v6?


Posted by admin  |  2 Comments »


The Internet is a packet switching network that uses IPv4 and/or IPv6 as its network communication protocol. Data that is being sent over the Internet is divided into smaller chunks that are individually sent in the form of packets. Sometimes the packets that are being sent are too big to be handled by the intermediate routers. The intermediate router needs to tell the sender to decrease his packet size. The way of telling the sender to decrease his packet size is via an ICMP error message.

This blog post will discuss the security implications of such communication from both an IPv4 and IPv6 standpoint.

The PMTU discovery process

The path between a sender and receiver can be built up from several different link technologies, each one of them capable of carrying a different amount of data in each packet. The maximum amount of data each link can carry is considered that links’ Maximum Transfer unit or MTU. The PMTU is determined by the MTU of the link that has the lowest MTU in the path, just like the strength of a chain is determined by the strength of its weakest link. For efficiency purposes it is of course good if the sender can use as high transfer unit as possible. Therefore a process is defined in both IPv4 and IPv6 to find out the maximum packet size that can be used. This process is called Path MTU discovery.

The PMTU discovery process works almost the same in IPv4 and IPv6. When a sender sends a packet towards the destination it will traverse several intermediate routers. If an intermediate router can’t handle the packet because it exceeds the MTU of the link, it will send an ICMP “packet too big” message back to the sender. When the sender receives the “packet too big” error message, it decreases the size and resends the packets. The new size is then used for all forthcoming packets to that destination. This behavior is about the same for both IPv4 and IPv6.

Security issues

There are some security problems with the communication that is needed for PMTU to work:

First of all, the ICMP “packet too big” error message that the router is sending back has the source IP-address of the intermediate router. This is typically an IP-address somewhere inside of an operator’s network in the path between the source and destination. There is no way for the sending organization to keep track of all potential intermediate router IP-addresses for all possible paths to all possible destinations. Instead, this needs to be handled in firewalls as a wildcard rule that accept ICMP “packets too big” messages to ANY destination from ANY source. Obviously big holes in the firewalls need to be opened.

Secondly, this type of communication is different from most other communications as you typically only expect responses from the one you are communicating with and not with intermediate routers. Firewalls and other filtering products usually keep track of ongoing connections and only allow incoming packets that correspond to an already established connection.

Third, if Network Address Translation (NAT) is used somewhere in the path, there is no way for that NAT device/firewall to know to whom to forward the error message to. There is no translation state in the NAT device/firewall that has any data as this packet was created outside of any ongoing communication.


Looking at the above issues, it is obvious that it is very difficult to make the PMTU process work in a secure manner. This is why most IPv4 networks network administrators just block all incoming ICMP packets. The side effect is that the PMTU process stops working. However, there is a feature in IPv4 that saves the day. This feature is called fragmentation. In IPv4 an intermediate router can in most cases fragment a packet into two or more smaller ones. This can be done instead of sending an ICMP “packet too big” error message, thus avoiding the issues discussed above.

Fragmentation introduces a whole lot of other issues. The receiver must reassemble all the fragmented packages and deal with issues such as fragments arriving in different order, etc. Fragmentation can also be used by bad guys to trick security devices such as Intrusion Detection Systems to not detect attack patterns.

When IPv6 was designed it was decided to remove fragmentation as a possibility. Instead the PMTU process described above is mandatory and you can no longer blocks ICMP “packet too big” messages in the firewall without breaking things.

Potential attacks

To open up your firewall for ICMP “packet too big” messages in IPv6 networks might seem harmless at first glance but once you examine the details you will find that there are some security issues. Let me first point out that ICMP packets, just like UDP, are trivial to spoof. There is no three way handshake like in TCP to prevent spoofed packets. So with ICMP it is possible for the sender to be anonymous.

A simple attack would be to send unsolicited ICMP “packet too big” messages to make the victim use a lower PMTU than possible. This would affect the performance of the victim but would in most cases not be considered a severe attack.

Another and more severe issue with the ICMP “packet too big” message is that it can carry payload. The RFC states that payload should be a copy of as much of the original packet as possible, but this is really hard for a firewall to check. It is possible for a bad guy to sneak in arbitrary messages in the payload, for example, to communicate and send commands or code to a Bot on a client inside of the firewall. This can, as I pointed out, be done anonymously.

This is very different from IPv4. In IPv4, a Bot inside a network would need to communicate outbound to be able to check if there is any new command or code to execute. This traffic is first of all detectable with firewalls and tools like webproxies (if you see a lot of traffic from your clients to an IP address in Bangladesh, you might want to investigate what is going on). Secondly, it reveals the IP-address of the bad guy’s update server. That piece of information is useful for law enforcers to track the bad guys down.


IPv6 has several advantages over IPv4. The most significant change introduced by IPv6 is that the address space increased from 32 bits to 128 bits. This is usually the only change people know about. There are many more changes IPv6 and some of them introduce new ways of handling traffic.

Vendors of IPv6 equipment must have a deep understanding of the underlying protocol to be able to secure the communication. To just retrofit IPv4 products to handle IPv6 packets doesn’t work. Firewalls and other equipment need to be able to filter packets in a completely new way.

When implementing IPv6 organizations must make a thorough analysis of the security impact. This along with other challenges make migrating to IPv6 a huge undertaking that will take several months, if not years for an average organization.

As we are running out of IPv4 addresses quickly I urge everybody to start addressing these challenges as soon as possible.

ARIN sets aside a /10


Posted by admin  |  No Comments »

ARIN, the RIR for North America today announced a new policy where a dedicated dedicated IPv4 block to facilitate IPv6 deployment. Allocations from this block will be very restricted. This puts the IPv4 depletion date about a month early in the region (unless you can justify your needs). Future versions of the Depletion tool will take this into account.

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.

RIPE NCC pool at record low


Posted by admin  |  No Comments »

The unallocated pool for RIPE NCC has been at a record low level for quite some time. A recent allocation to Russia of 250,000 addresses pushed the pool further down. Currently the pool size is only 0.75 of a /8 or about 12 million addresses. The pool has not been this low since the 1990’s.

RIRs are expected to allocate new space when their current pool can’t cover 9 months demand. This has obviously been ignored in this case as a pool of 0.75 of a /8 will hardly last longer than 3 months.

Expect to see a request from RIPE to get more address space soon.