ip6 Peer Flood Mitigations, and some possible fixes

[aspadistra]

Here are some IP6 Peer Flood Mitigations that are doable by most uTorrent Clients immediately

 

 

This posting referrs to this URL for the source information

-- http://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-flood-150619/

 

The "Feature Request" section here also applies to Mac and Android versions, but Mac primarily. 

 

 

uTorrent MITIGATIONS AVAILABLE NOW

 

1. Preferences : BitTorrent : Protocol Encryption

-- CHANGE MODE TO "Forced" 

-- SET TO "Disallow Incoming Legacy Connections" 

 

2. Preferences : Advanced : // Filter "ip" //

-- SET net.dissallow_incoming_ip6 TO True

-- SET ipfilter.enable TO True

 

3. BitTorrent's BT communications kernel may possess similar features, so nearly the same mitigation may work for BitTorrent. For other BT clients, similar options may exist too. 

 

 

A POSSIBLE FIX

 

 

This possible fix could be programmed in 15 to 21 days with open source components and systems. If I knew what systems to recommend, I would recommend them. 

 

THE FIX

 

USE AN IP4 + IP6 Routability Database to verify IP address routability.

 

The routability database is not an absolute requirement for IP4 addresses, but must be a requirement for IP6 addresses if the IP6 unroutable address flood problem is to be fixed. 

 

The BT client needs to look at the database at least 50% of the time to verify if an address is rotatable or not.

 

The IP routability database feature should be ON by default, but one should be able to turn it OFF for debugging. 

 

The database should be accessed at least 20% of the time (the default being 50%, step granularity 5%).

 

There should be a user setting to adjust the "probability of access" from 20% to 90%. 

 

 

NOTE

 

 

1. 99.9% of IP4 addresses ARE "ROUTABLE" (conservative estimate). Therefore it is only worthwhile storing the individual IP4 addresses that cannot be routed. 

 

The routability database should store individual IP4 addresses that are not rotatable.

 

The database should be capable of supporting blocks of unroutable IP4 addresses.

 

 

2. 99.996% of IP6 addresses ARE NOT ROUTABLE. Therefore it is only worthwhile to store blocks of IP6 addresses that cannot be routed. 

 

The routability database should store blocks of IP6 addresses that are not rotatable. 

 

The routability database should be capable of storing individual IP6 addresses that are not routable, as there may be reasons that make it impossible to store some of these addresses in blocks.  

 

 

3. The client should collect "UNROUTABLE" IP4 and IP6 addresses.

 

If the BT client encounters more than 500 unroutable addresses, the uploading of the unroutable addresses must be turned on.

 

This feature should be set up so that it can be turned ON or OFF.

 

-- The trigger should allow the trigger point to be settable from 100 to 1000. 

 

-- The unroutable addresses should be uploaded at least once every 3 hours (after being subjected to zip compression and address block merging when the database is frozen some 30 seconds before uploading). 

 

4. The IP unroutabiliy feature needs to be added to the DHT Database. This is essentially an anti-spoofing feature -- and every "real time" IP database should have the feature. 

 

 

ANNEX

 

The addresses or address blocks of the IP routability database should initially expire after 168 hours, but after the filtering system is stable this should be moved back to 36 hours.