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 --------------- Steve Conte - IANA conte@iana.org PGP KeyID: 0x0972C473
On Fri, 16 Jan 2004 Valdis.Kletnieks@vt.edu wrote:
On Thu, 15 Jan 2004 15:31:37 PST, Steve Conte <conte@iana.org> said:
This is to inform you that the IANA has allocated 70/8 to ARIN.
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. http://69box.atlantic.net/cgi-bin/bogon ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Fri, 16 Jan 2004 11:34:18 EST, jlewis@lewis.org said:
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? :)
On Fri, 16 Jan 2004 Valdis.Kletnieks@vt.edu wrote:
On Fri, 16 Jan 2004 11:34:18 EST, jlewis@lewis.org said:
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. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Fri, 16 Jan 2004 Valdis.Kletnieks@vt.edu wrote:
On Fri, 16 Jan 2004 11:34:18 EST, jlewis@lewis.org said:
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. ... Or, perhaps IANA could even do this before assigning an IP block to an RIR.
Of course, if they tried to run the test *before* assigning the block, it should fail, because it should still be in everyone's bogon filters. ^_^ So, the test has to happen *after* the assignment has been made and announced, so that people have time to update their bogon filters. It would also require that the RIR to whom the block has been assigned arrange with their upstream to have the test block routed; perhaps they could use the top block from the new assignment for the test subnet, and then begin assigning from the bottom; hopefully by the time any substantial portion of the space has been allocated, the need for the test subnet will have passed, and the block can be used as part of the normal allocation and assigned as appropriate (would kinda suck to be given the last assignment from the block, only to be told that "sorry, your last /24 is actually routed by the RIR, so you come up 1 /24 short of what you expected. ;-) Just some random thoughts on the matter--but it *does* sound like a good idea. Matt
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.
---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Fri, 16 Jan 2004 11:29:16 PST, matt@petach.org said:
and the block can be used as part of the normal allocation and assigned as appropriate (would kinda suck to be given the last assignment from the block, only to be told that "sorry, your last /24 is actually routed by the RIR, so you come up 1 /24 short of what you expected. ;-)
Been there, done that. APNIC gave 223/8 back because there was an issue with 223.255.255.0/24 being listed as IANA-Reserved.
On Fri, 16 Jan 2004 matt@petach.org wrote:
Of course, if they tried to run the test *before* assigning the block, it should fail, because it should still be in everyone's bogon filters. ^_^
So before assigning a block, mark it as "Pending assignment" or "Assigned to IANA".
their bogon filters. It would also require that the RIR to whom the block has been assigned arrange with their upstream to have the test block routed;
That's trivial.
perhaps they could use the top block from the new assignment for the test subnet, and then begin assigning from the bottom; hopefully by the time any substantial portion of the space has been allocated, the need for the test subnet will have passed, and the block can be used as part
Unfortunately, I doubt that. ARIN's been assigning from 69/8 for a year or more and there are still lots of networks filtering it. If RIR's were to setup such testing sites, it'd probably make sense to simply reserve the minimum allocation size block from each IANA assigned block and assume it will be used for reachability testing pretty much indefinitely. Maybe they could be recycled after a number of years. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
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. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
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. On Mon, 19 Jan 2004, Daniel Karrenberg wrote:
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too.
Daniel
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. On Mon, 19 Jan 2004 william@elan.net wrote:
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.
On Mon, 19 Jan 2004, Daniel Karrenberg wrote:
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too.
Daniel
On Mon, Jan 19, 2004 at 10:22:08AM -0800, william@elan.net wrote:
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.
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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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 --On Monday, January 19, 2004 9:27 -0800 william@elan.net wrote:
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.
On Mon, 19 Jan 2004, Daniel Karrenberg wrote:
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too.
Daniel
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
I don't know for certain and I'm guessing based on existing pattern (although for 70/8 ARIN did mention at one point it will be allocated to them I think). The pattern is that IANA tries to allocate blocks consequently to RIRs (don't know why, its not like like RIRs would be announcing blocks as /7 :) and right now this looks as as follows: ARIN: 64/8 -> ... -> 79/8 (so next one is 71/8, then 72/8, etc) RIPE: 80/8 -> .... ???? (so next one 85/8) APNIC: 218/8 -> 223/8 (note: 223/8 had reserved /24 and APNIC turned down this allocation, so it remains in reserve) 61/8 -> 58/8 (so next one I'll guess to be 59/8, then 58/8) Also I'm going to make a prediction that after 58/8, the next block maybe 126/8 counting backwards again towards RIPE blocks LACNIC: 200/8 -> 201/8 (I'm not certain which will be next, if I have to guess, it might be 49/8 and 50/8) AFRINIC: 196/8 -> 197/8 (too far away to guess any other ones) We'll see how correct these predictions are, lets come back to this in say year 2010 and then you can get me for being so very wrong :) On Mon, 19 Jan 2004, Owen DeLong wrote:
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
--On Monday, January 19, 2004 9:27 -0800 william@elan.net wrote:
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.
On Mon, 19 Jan 2004, Daniel Karrenberg wrote:
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too.
Daniel
What about 1/8 and 2/8? Are those being reserved for something special ----- Original Message ----- From: <william@elan.net> To: "Owen DeLong" <owen@delong.com> Cc: <nanog@merit.edu> Sent: Monday, January 19, 2004 16:55 Subject: Re: New IPv4 Allocation to ARIN
I don't know for certain and I'm guessing based on existing pattern (although for 70/8 ARIN did mention at one point it will be allocated to them I think). The pattern is that IANA tries to allocate blocks consequently to RIRs (don't know why, its not like like RIRs would be announcing blocks as /7 :) and right now this looks as as follows: ARIN: 64/8 -> ... -> 79/8 (so next one is 71/8, then 72/8, etc) RIPE: 80/8 -> .... ???? (so next one 85/8) APNIC: 218/8 -> 223/8 (note: 223/8 had reserved /24 and APNIC turned down this allocation, so it remains in reserve) 61/8 -> 58/8 (so next one I'll guess to be 59/8, then 58/8) Also I'm going to make a prediction that after 58/8, the next block maybe 126/8 counting backwards again towards RIPE blocks LACNIC: 200/8 -> 201/8 (I'm not certain which will be next, if I have to guess, it might be 49/8 and 50/8) AFRINIC: 196/8 -> 197/8 (too far away to guess any other ones)
We'll see how correct these predictions are, lets come back to this in say year 2010 and then you can get me for being so very wrong :)
On Mon, 19 Jan 2004, Owen DeLong wrote:
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
--On Monday, January 19, 2004 9:27 -0800 william@elan.net wrote:
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.
On Mon, 19 Jan 2004, Daniel Karrenberg wrote:
On 16.01 13:13, jlewis@lewis.org wrote:
... 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.
Personally I agree with you and I will argue accordingly in the relevant places. Cooperation with the bogon project seems logical too.
Daniel
On Fri, Jan 16, 2004 at 10:56:24AM -0500, Valdis.Kletnieks@vt.edu wrote:
All you early adopters of 69/8 now have somebody to share your pain with....
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 FUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Matthew S. Hallacy wrote:
On Fri, Jan 16, 2004 at 10:56:24AM -0500, Valdis.Kletnieks@vt.edu wrote:
All you early adopters of 69/8 now have somebody to share your pain with....
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.
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? Pete
On Fri, 16 Jan 2004, Petri Helenius 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. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Jan 16, 2004, at 3:31 PM, 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.
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.
On Fri, 16 Jan 2004 jlewis@lewis.org wrote:
On Fri, 16 Jan 2004, Petri Helenius 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.
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. -- William Leibzon Elan Networks william@elan.net
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:
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.
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
On Sun, 18 Jan 2004, 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.
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. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
participants (14)
-
Daniel Karrenberg -
jlewis＠lewis.org -
John Palmer -
matt＠petach.org -
Matthew S. Hallacy -
Michael Lewinski -
Owen DeLong -
Pete Templin -
Petri Helenius -
Richard A Steenbergen -
Rob Thomas -
Steve Conte -
Valdis.Kletnieks＠vt.edu -
william＠elan.net