Magic Banana asserted:
" ... I believe groups of four hexadecimal digits chosen by local network
administrators ..."
Waitaminnit. The IPv6 addresses start at 1 and then climb one-by-one to an
astronomical number like
the 79,228,162,514,264,337,593,543,950,336 addresses in 2a02:2788::/32 which
are boiled down to the
more workable hexadecimal notation 2a02:2788:ffff:ffff:ffff:ffff:ffff:ffff.
Zeroes are just part of
the originating consecutively realized decimal number, but they come less
often than every 10th count
as in
...7,8,9,a,b,c,d,e,f,10,11,12,13,14,15,16,17,18,19,1a,1b,1c,1d,1e,1f,20,
i.e., every 16th count.
In a dynamically addressed addressing scheme, the local network administrator
might just be creating
the appearance of that astronomical number. Just patch together an array of
four-digit hexadecimal
numbers with scripts like the ones with which we have been experimenting.
That could be a large
but not astronomical number of arbitrary addresses. One of your scripts
generates these arbitrary
addresses immeasurably quickly. Those addresses need only conform to the
astronomical address space
which he owns (rents ? ...bought at an ill-advertised public auction ? ...
got for free ?).
A script can be written that would call up a series of text-file addresses,
create new addresses,
populate each one with .html code or a script, upload the data to the new
addresses on the appropriate
server, delete the former addresses' code, store the new addresses on the
local HDD, delete the
replaced addresses, and move on without ever closing the cover of his laptop
or running out of storage.
Magic Banana's efficient script:
prefix=2a02.2788; od -A n -N 12582912 -xw12 /dev/urandom | tr ' ' : | sed
s/^/$prefix/ > SS.IPv6-NLU-MB4520A.txt
produces 1,048,576 IPv6 addresses in three (a thousand one, a thousand two, a
thousand three ...) seconds real time.
Grep does the :0, :00 & :000 counting for us:
grep -c :0 SS.IPv6-NLU-MB4520A.txt = 336,443
grep -c :00 SS.IPv6-NLU-MB4520A.txt = 24,358
grep -c :000 SS.IPv6-NLU-MB4520A.txt = 1,500
grep -c :0000 SS.IPv6-NLU-MB4520A.txt = 93
which seems rather realistic, despite the original script's neglecting
actually to count from the beginning.
Evaluating our progress ...
nmap -6 -sn -T4 -sL -iL SS.IPv6-NLU-MB4520A.txt | grep "Nmap scan report for
" - | tr -d '()' | sort -k5 | awk 'NR >= 1 { print $5, $6 }' | awk 'NR >= 1 {
print $2, $1 }' | uniq -Df 1 | sed '/^\s\s*/d' | awk '{ print $2 "\t" $1 }'
>> Multi-SS.IPv6-NLU-MB4520A.txt
Alas, 2a02.2788::/32 is gome; WhoIs returns "no one found at this address"...
"Failed to resolve ..." is all that nmap gets.
Try mobile.tre.se's 2a02:aa1::/32 instead:
prefix=2a02:aa1; od -A n -N 12582912 -xw12 /dev/urandom | tr ' ' : | sed
s/^/$prefix/ > SS.IPv6-NLU-January2020-mobile.tre.se.txt
Forgot to count ... I thought something was wrong ... but there it was: 41MB
with 1,048,576 addresses.
nmap -6 -sn -T4 -sL -iL SS.IPv6-NLU-January2020-mobile.tre.se.txt | grep
"Nmap scan report for " - | tr -d '()' | sort -k5 | awk 'NR >= 1 { print $5,
$6 }' | awk 'NR >= 1 { print $2, $1 }' | uniq -Df 1 | sed '/^\s\s*/d' | awk
'{ print $2 "\t" $1 }' >> Multi-SS.IPv6-NLU-January2020-mobile.tre.se.txt
Network initially running ten times as fast as for the first nmap script ...
took 63 minutes (55.2MB) ==> 1,048,534 mobile.tre.se's.
Enumerating:
awk '{print $2,$1}' 'Multi-SS.IPv6-NLU-January2020-mobile.tre.se.txt' | sort
-k 2 | uniq -cdf 1 | awk '{print $3"\t"$1}' '-' >
Multi-SS.IPv6-NLU-January2020-mobile.tre.se.Tally.txt
Result: mobile.tre.se 1048534
Apply grep again:
grep -c :0 SS.IPv6-NLU-January2020-mobile.tre.se.txt = 336,811
grep -c :00 SS.IPv6-NLU-January2020-mobile.tre.se.txt = 24,452
grep -c :000 SS.IPv6-NLU-January2020-mobile.tre.se.txt = 1,553
grep -c :0000 SS.IPv6-NLU-January2020-mobile.tre.se.txt = 84
A million makes a pretty good sample size, and grep's actual counts have the
1:16:256:4093 (i.e, ~16 times per step).
Those randomly generated four-character fields appear not to exclude the
normal numbers of zeros as I first thought.
In graduate school, I was at first trying to attain my Sc.D. in Materials
Engineering, but my advisor wanted me to take
one more course: Statistical Mechanics, which does thermodynamics from the
beginning. I contacted the department's
registration officer, and he said that I had spent enough time in graduate
school (six years) and I had sufficient
course credits for a degree in Metallurgy. That's how I escaped mathematical
statistics. I got though my metallurgical
consulting career with plain old experimentally based thermodynamics, which
is what the elements do when left to their
own devices. Never missed those statistical calculations until now.
George Langford
