Greetings,
This is to inform you that the IANA has allocated 70/8 to ARIN.
For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space>.
Thanks,
Steve
All you early adopters of 69/8 now have somebody to share your pain with....
There are still numerous networks blocking 69/8. Probably more blocking
70/8 as most of the people who were behind the times with their filters
blocking 69/8 fixed that /8 but still don't keep their filters up to date.
Can an early adopter of 70/8 please give Jon an address? 
I was actually going to suggest that, but I've been pretty busy lately and
can't guarantee how fast I'd get it setup and testing. If someone did
want to lend me a small chunk of 70/8 (whatever minimum size might make it
through most prefix length filters) I would have no problem with making a
"70box" interface on 69box and testing reachability to the hosts checked
when 69box was setup.
Alternatively, the RIRs might consider doing this sort of thing before
allocating IPs from new blocks. I know it's not their job to make sure
IPs are routable (especially not on every remote network), but as holders
of all the IPs, they are in the best position to setup such test sites
that would expose problems before they're dumped on members. The only
slightly tricky part is coming up with a large population of remote IPs to
test for reachability.
Or, perhaps IANA could even do this before assigning an IP block to an
RIR.
If either type of the above orgs wants to do this, I'm sure people from
the community would be willing to help out if they don't have or don't
want to dedicate staff to this type of project. It could be left to the
community (or those who have been allocated or expect to be allocated
IPs from these blocks) to try to notify broken networks about their
outdated filters. I know from my own experience with it, that it's a pain
to do since it's not always clear who to contact, and even when you get
the right contact, they may not understand/care about the problem.
I wouldn't be surprised if more people are filtering 69/8 now than before,
roughly 40% of the spam hitting my servers is from there.
Matthew S. Hallacy wrote:
>I wouldn't be surprised if more people are filtering 69/8 now than before,
>roughly 40% of the spam hitting my servers is from there.
That's likely going to be true of each newly allocated block as spammers
move around, move into them, or even scam the RIRs into allocating IPs
directly to them.
It also seems that 69box.atlantic.net (or someone nearby) is filtering
one specific size of ICMP packets.Is certain packet size also considered a "bogon" or is this something
that will eventually be removed
from the filters?
It's those dang Nachi-sized ICMP echo/echo-replies. We block those at all
our transit points and dial-up ports. Nachi was killing our cisco
access-servers until we did this to stop the spread.
Unfortunately, this breaks Windows tracert as it uses 92-byte echo
requests. Use a "real" traceroute, and you won't see this problem.
FYI, Nachi is basically dead now from what I can tell. It was timed to expire in January of this year, and our flowscan graphs bear this out. Prior to it's self-destruction, Nachi traffic comprised about half of all our incoming flows. ICMP is back to pre-Nachi levels here now, and I have heard similiar reports elsewhere.
As spamming operations became more cetralized and necessary harware to
actually get any results increased (send 100,000,000 instead of 100,000
emails to get the same result) and at the same time the requirements for
direct allocations decreased from RIRs (was /19, now /21 used is generally
enough to get /20), the spamming operations can now qualify for ip blocks
and ARIN and other RIRs are neutral as far as what ips are used for and
have to assign them.
At the same time all large spammers operate with multiple companies,
setup legally they do it:
1. To try to get new lines & contracts from ISPs
2. To avoid being found and traced by antispam activists
3. To avoid responsibility when they get into legal problem and to avoid
paying penalty fees when ISPs cancel contract
Legally I doubt RIRs have much of a choice as all these spam fronts are
setup as separate companies and contracts are moved from one company to
another to qualify them for ip block. But if you look more closely, the
hardware is also often moved (but not always), however that is probably
not enough for RIRs to deny the transfer on grounds that its existing
company, plus RIRs really don't ever get into such specifics.
jlewis@lewis.org wrote:
It's those dang Nachi-sized ICMP echo/echo-replies. We block those at all our transit points and dial-up ports. Nachi was killing our cisco access-servers until we did this to stop the spread.
Unfortunately, this breaks Windows tracert as it uses 92-byte echo requests. Use a "real" traceroute, and you won't see this problem.
I know what they are and how to get around them. I just look down on people
dropping my packets in their backbones without reason.
Pete
Petri Helenius wrote:
It's those dang Nachi-sized ICMP echo/echo-replies. We block those at all our transit points and dial-up ports. Nachi was killing our cisco access-servers until we did this to stop the spread.
I know what they are and how to get around them. I just look down on people
dropping my packets in their backbones without reason.
He has a reason: that virus was melting down his network (and was melting down lots of networks).
If viruses came with instructions, documentation, and source code, we could all rest assured that it did completely self-destruct this month. Instead, we're all watching in wait, and leaving filters handy or in place.
(I'd mention the Nachi filtering I had to do and the implications of how I had to do it based on the platform I'm using, but my flamesuit is all tattered just trying to find a safe tool to read my mail.)
pt
Pete Templin wrote:
He has a reason: that virus was melting down his network (and was melting down lots of networks).
I point to the word "backbone". If your dial servers melt, block the packets at dial
servers, don�t launch weapon of mass packet destruction to all traffic. Filtering
should be more targeted so it does not kill or hamper what it�s supposed to protect
in the first place.
Pete
>It's those dang Nachi-sized ICMP echo/echo-replies. We block those at all
>our transit points and dial-up ports. Nachi was killing our cisco
^^^^^^^^^^^^^^^^^^^^^^^^^^^
>access-servers until we did this to stop the spread.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I know what they are and how to get around them. I just look down on people
dropping my packets in their backbones without reason.
I wasn't joking or kidding about the above. Many others who run dialup
services saw similar problems (both with cisco and other vendor's gear).
Blocking these size/type packets, as per suggestions from cisco's web site
was the easiest way to keep our network up, and prevent additional
infections both into and out from our customers.
Have others who implemented them dropped their echo/echo-reply 92-byte
filters?
If tracert defaulted to udp like just about every "unix" traceroute or
allowed you to vary the packet size or protocol, this wouldn't be as much
of an issue.
Personally I agree with you and I will argue accordingly in the relevant places.
Cooperation with the bogon project seems logical too.
Daniel
Hi, NANOGers.
] Cooperation with the bogon project seems logical too.
We at Team Cymru are happy to help in any way we can!
Thanks,
Rob.
It has been known for quite some time that next block to be allocated to
ARIN is 70/8 (and next one will be 71/8). It might have been nice if ARIN
were to run projections and inform community that by its projections it
will be requesting new /8 ip block in say 2 month time.
Also as you know I have been running statistics at
http://www.completewhois.com/statistics/
(note: dont believe about "green" for 70/8, I still have not fixed collection
to ignore occasional single wrong announcements from routeviews)
Its interesting that 69/8 block is currently only 39% allocated. To be
honest I was not expecting ARIN to request another block under such
condition, I was expecting when its either almost full (say 75%) or when
it reaches previously agreed upon mark of 50% (see my other post).
The only thing I could think of is that ARIN is allocating smaller block
leaving some portion of the block "in reserve" for future allocation to
the same entity and as a result it reached "critical point" of beyond 50
percent point of the block. So I checked and found that 69.128.0.0/18 was
actually allocated on 2003-03-25. Checking again, it turns out the last
(in terms of beginning) allocation they have is 69.178.0.0/17 made on
2004-01-13. Ok so 0-178 makes it 70% used for that class-a as far as
point they reached for allocations.
Now if I only knew for certain if this was indeed the formula they used
deciding when to request new ip block, we could easily predict when
next block would be requested and based on rate of growth for existing
block even predict this several months ahead of time.
Yes, ARIN typically leaves at least 100% (or more depending on growth
patterns) of the initial allocation as unallocated space, left in reserve
for future growth. If the user comes back for more IP space, they just
expand into that unallocated space, without the need to create
non-connected allocations which can't be aggregated. Eventually if you
don't come back and claim your space, it is given away to someone else
(btw I'd love to know the timelines for that).
The 39% number makes a lot of sense given the 70% usage measured "in
sequential order". I'm sure that the number of people who have come back
for space is slightly higher than 4%, and is offset by some larger
reservations (ex: the people who are on their 2nd or 3rd allocation, who
have already been through a /19 or /18, and who are reserved a /16 even
though they only eat new blocks a /19 at a time), but it's a good rough
estimate.
One point I would make is that ARIN certainly gives itself a luxury that
its users do not have when it comes to reserving IP space for the future
growth of its customers. The only option providers have to reserve space
for their customers and still continue to get new IP space under the 80%
utilization rules is to SWIP their customers a larger block than they
need, and then explain it to ARIN when they ask how that customer
justified said block (and there are still plenty of hostmasters who will
argue with you about it :P). This is easier to do for end users because of
their lower utilization requirements, but more of a pain for reallocations
to people who will reallocate themselves. Also, it doesn't have quite the
same effect for keeping customers in line when you hand them a SWIP for 2x
what they asked for and say "try to use this efficiently, and keep the 2nd
half reserved for your future growth" instead of being able to portion it
out to them. I would rank this problem as one of the larger contributors
to the /24 announcements on the global routing table, as customers with a
steady growth pattern who don't want to pay ARIN a few thousand dollars
for direct IP space keep coming back for space which their providers can't
hold in reserve and still keep ARIN happy.
Not to rain on your parade, but, how do you know 71 will go to ARIN and
not to RIPE, APNIC, or LACNIC or AfriNIC?
Owen