Hello, I propose the following iRule as an alternative in that it specifically matches the MS15-034 issue, matches evasion techniques, has a nominal CPU load, and produces no false positives.

# 2015-04-15 Nathan Fowler
# Similar to CVE-2011-3192, handle MS15-034
# RFC 2616 Section 14.35
#
# Changelog: Not an overflow issue, 2^64 is unique
#            Minor PCRE tweak to avoid unlikely but possible false positives, oops.
#            RFC 2616 BNF adjustments, thanks Didier Stevens
#            Corrected error with bad matching RegEx, needed full match.
#            I am an idiot.  \x20 spacing in the RegEx was being treated literally, as it should.  PEBKAC issue.  Tested and confirmed working.

when HTTP_REQUEST {
   if { ( [HTTP::header exists "Range"] && [HTTP::header "Range"] contains "18446744073709551615") } {
     if { [HTTP::header "Range"] matches_regex {[^\n]+-[^0-9]*0*18446744073709551615.*} } {
       if { ! ([HTTP::header "Range"] matches_regex {[^\n]+18446744073709551615[0-9].*}) } {
         log local0. "LOG DoS/RCE MS15-034 0xFFFFFFFFFFFFFFFF attack structure to [HTTP::host] from [IP::client_addr]"
         TCP::close
         event disable
       }
     }
   }
}

As you can see by the content and PCRE matches I really don't care too much about the initial byte values since the literal appearance of "18446744073709551615" in an RFC 2616 14.35 Range request is for all practical reasons highly abnormal and five-nines likely to be an attempt against MS15-034.  The "anchor" is really '18446744073709551615' since 0xFFFFFFFFFFFFFFFF is unique which is why it is present on the outer-most conditional.

     18446744073709551614 = 0xFFFFFFFFFFFFFFFE = No Crash
     18446744073709551615 = 0xFFFFFFFFFFFFFFFF = Crash
     18446744073709551616 = No Crash

With respect to MS15-034 my stuff should match on all attempts and isn't dependent on the initial byte range value and is more fixated on 0xFFFFFFFFFFFFFFFF (MS15-034) itself.  I went with TCP::close and event disable to send an egress TCP RST to tear down L3/L4 state for the on-premise gear to avoid state table saturation if this ended up a "Lets crash all the boxes from a diverse network".  A less "aggressive" stance is the one you've chosen which is simply remove the Range HTTP Request Header but at this point the iRule matches attacker traffic and not passing the request to the back-end makes the most sense.

Evasion testing was done with:

#!/bin/bash
echo "Checking $1 for TCP::close"
curl -I -k "$1" --header "Range: bytes=2-18446744073709551615"
curl -I -k "$1" --header "Range: bytes=2-018446744073709551615"
curl -I -k "$1" --header "Range: bytes=2-0018446744073709551615"
curl -I -k "$1" --header "Range: bytes=2 - 18446744073709551615"
curl -I -k "$1" --header "Range: bytes = 2-18446744073709551615"
curl -I -k "$1" --header "Range: bytes=2-184467440737095516150"
echo "This should produce HTTP 400 or a valid response"
curl -I -k "$1" --header "Range: bytes=0-184467440737095516150"
echo "Done"

Cheers,
Nathan Fowler
bmF0aGFuQHBhY2tldG1haWwubmV0Cg==