APNIC returning 223/8 to IANA
Hi all, APNIC is in the process of handling back the 223/8 which we received from IANA in February 2003. Please see the email below for more information. Regards son ____________________________________________________________________ Resources Services Manager <Son@apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk@apnic.net Please send Internet Resource Requests to <hostmaster@apnic.net> _____________________________________________________________________ ---------- Forwarded message ---------- Date: Fri, 14 Mar 2003 10:55:25 +1000 (EST) From: John Tran <john@apnic.net> To: iana@iana.org Cc: pwilson@apnic.net, Anne Lord <anne@apnic.net> Subject: handback of 223/8 Dear Michelle, APNIC was allocated 223.255.255.0/8 by IANA on 12 February 2003. RFC3330.txt states that 223.255.255.0/24 is RESERVED. At this point in time, the reservation means that the network cannot be further assigned or allocated. The reservation of this network impacts the sparse allocation system used by APNIC for managing allocations, limiting the amount of potential aggregation. Furthermore, the status of RESERVED is potentially confusing for APNIC members, the majority of whom do not have English as a first language. APNIC therefore is returning this block to IANA and cordially requests that IANA delegate a block with no such reservation. APNIC regards the status of this address block as a matter for resolution by the IETF and IANA. Once the status has been finally resolved however, APNIC would be willing to receive this block in a future IANA allocation. Regards Son ____________________________________________________________________ Resources Services Manager <Son@apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk@apnic.net Please send Internet Resource Requests to <hostmaster@apnic.net> _____________________________________________________________________
On Mon, 17 Mar 2003, John Tran wrote:
Hi all,
APNIC is in the process of handling back the 223/8 which we received from IANA in February 2003. Please see the email below for more information.
Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of "RESERVED"? Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED. Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Mon, Mar 17, 2003 at 01:11:06AM -0500, Andy Dills wrote:
Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of "RESERVED"?
Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED.
Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems.
If APNIC doesn't want it, I'm sure I could find someone who does. :) Yes this is remarkably silly. What could possibly be broken by a reserved /24 out of a /8. -- 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)
On Mon, Mar 17, 2003 at 01:24:52AM -0500, Richard A Steenbergen wrote:
On Mon, Mar 17, 2003 at 01:11:06AM -0500, Andy Dills wrote:
Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of "RESERVED"?
Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED.
Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems.
If APNIC doesn't want it, I'm sure I could find someone who does. :)
Yes this is remarkably silly. What could possibly be broken by a reserved /24 out of a /8.
You're missing the issue that when you are assigned space, if part of it is already reserved that should be clearly spelled out. When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Mon, 17 Mar 2003 01:31:08 EST, Jared Mauch said:
When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me.
I suppose IANA *could* refund 1/2**16'th of the price paid by APNIC.
At 01:31 17/03/2003 -0500, Jared Mauch wrote:
You're missing the issue that when you are assigned space, if part of it is already reserved that should be clearly spelled out.
When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me.
Jared, you hit the nail on the head. Anyone who was at the APNIC Policy SIG meeting during APRICOT 2003 last month will have heard the fairly lengthy discussion around 223/8. While I don't agree that the block should be handed back as it makes a fairly substantial mountain out of what is a tiny molehill, several pointed out the above issue, that 223/8 is not fully usable, and that there is no documentation stating that 223.255.255.0/24 is actually usable. Or not usable. RFC3330 (informational) states what it used to be for, but the actual paragraph discussing 223.255.255.0/24 contradicts itself, and is of no help. My disappointment was that everyone who could solve, or at least take ownership of the problem was in the room at the time. That they chose not to was sad, much to the bewilderment of the attendees I spoke to afterwards. Had the problem been solved there and then, it would have demonstrated clear progress in improving RIR/IETF cooperation. And so the address space has been returned. :-( philip --
In a message written on Mon, Mar 17, 2003 at 01:31:08AM -0500, Jared Mauch wrote:
When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me.
Just like the people who get 69/8 blocks should expect them to be fully usable as well, right? Surely if one reserved /24 means you can return space and get new space assigned then the inability to reach some percentage of the internet is an even bigger, and more immediate concern that should warrant the same treatment. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Mon, 17 Mar 2003, Leo Bicknell wrote:
Just like the people who get 69/8 blocks should expect them to be fully usable as well, right? Surely if one reserved /24 means you can return space and get new space assigned then the inability to reach some percentage of the internet is an even bigger, and more immediate concern that should warrant the same treatment.
I think all that really needs to happen here is an RFC update that unreserves 223.255.255.0/24. RFC3330 already mentioned that the basis for this reservation was no longer applicable. Someone at IANA just screwed up the order of events, as the block should have been explicitly unreserved before it was assigned. On the same note, if you do a few google/groups.google.com searches, you'll find that LOTS of people treat the networks marked as IANA-Reserved in http://www.iana.org/assignments/ipv4-address-space in much the same way as RFC1918 space, some even call them quasi-RFC1918 space. A groups.google.com search for 69.0.0.0/8 will turn up 5 pages of hits, nearly all of which are firewall/ipf/ipchains/etc. config examples recommending and demonstrating how to block, among other reserved nets, 69.0.0.0/8. I'd like to strongly encourage IANA to reexamine all current IANA-Reserved blocks, decide which ones will remain Reserved for the forseeable future, and which are likely candidates for assignment to RIRs at any future date, and update these to a more suggestive status such as Future-RIR-Assignment. Otherwise, we're going to repeat the 69/8 exercise (signifigant parts of the net ignoring the space months after assignment...some parts ignoring it likely for years) every time a net goes from being IANA-Reserved to assigned to some RIR. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Mon, 17 Mar 2003, Leo Bicknell wrote:
Just like the people who get 69/8 blocks should expect them to be fully usable as well, right?
I think all that really needs to happen here is an RFC update that unreserves 223.255.255.0/24. RFC3330 already mentioned that the basis for this reservation was no longer applicable. Someone at IANA just screwed up the order of events, as the block should have been explicitly unreserved before it was assigned. ...
Its not quite that simple folks. The reason this particular block is reserved has some real technical merit, while the 69/8 muddle is strictly due to ISP negligence. RFC 3330 got it wrong. Anyone remember the "Martian List" from the 1970-1990's? Trying to use the all-ones or all-zeros network for real traffic is not possible. Pre CIDR it was not possible to use 192.0.0.0/24 or 192.0.255.0/24. (the same was true on -every- network boundary) With CIDR, those boundaries moved to 1.0.0.0/24 and 223.255.255.0/24 e.g. only two reservered blocks instead of hundreds. Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue. --bill
In a message written on Mon, Mar 17, 2003 at 07:01:32AM -0800, bmanning@karoshi.com wrote:
Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue.
s/silicon/filter/ s/APNIC/Joe ISP/ s/IANA/ARIN/ Note, I don't think either case represents "damaged goods", so I'm not supportive of either effort. That said, look at the fixes: Case 1: IANA properly updates RFC's to indiate that 223.255.255.0/24 is not allocatable, and makes APNIC's allocation properly 223/8 minus 223.255.255.0/24. Case 2: ISP's all across the US must handle user complaints, probe, test and then e-mail, call, and plead with hundreds, or even thousands of people to fix their broken filters I don't see any case where an ISP was in danger of receiving IP's that "didn't work" from 223/8, unless of course APNIC was actually thinking about giving out 223.255.255.0/24. That said, it can be demonstrated that the IP's given out in in 69/8 don't work for a measurable percentage of the Internet. My only claim is that if one questionable /24 our of a /8 means the entire /8 can be returned then clearly someone who receives a block out of 69/8 should be able to return their space as well because their entire block is impared. APNIC has a legitimate complaint, and it needs to be solved. That said it's a very minor complaint, and returning the allocation is simply grandstanding on their part, and is going to give fuel to all the people in other blocks who have what are generally much more serious operational problems. Maybe it would be better for APNIC to give up 223/8 for 70/8, since I suspect 70/8 will have the same filtering problems as 69/8. If they want to make life worse for their users, more power to them. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Its not quite that simple folks. The reason this particular block is reserved has some real technical merit, while the 69/8 muddle is strictly due to ISP negligence.
RFC 3330 got it wrong. Anyone remember the "Martian List" from the 1970-1990's? Trying to use the all-ones or all-zeros network for real traffic is not possible. Pre CIDR it was not possible to use 192.0.0.0/24 or 192.0.255.0/24. (the same was true on -every- network boundary) With CIDR, those boundaries moved to 1.0.0.0/24 and 223.255.255.0/24 e.g. only two reservered blocks instead of hundreds.
Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue.
--bill
Unless I'm mistaken, there is no technical issue with using the All-0's or All-1's classful networks. In fact, several of those networks are in use. 0.0.0.0/8 "this" network (all-zeros A) 127.0.0.0/8 loopback network (all-ones A) 128.0.0.0/16 reserved but unused (all-zeros B) 191.255.0.0/16 reserved but unused (all-ones B) 192.0.0.0/24 reserved but unused (all-zeros C) 223.255.255.0/24 reserved but unused (all-ones C) As with 0/8 and 127/8, the other 4 networks could certainly be designated for some use, including "normal" end-users. This type of end-user usage would even continue to work with old classful gear.
I think your getting confused? The restriction is on subnets using classful addresses, you shouldnt use all zeros and all ones subnet for a given subnetted classful network. In the examples below, 192.0.0.0 and 192.0.255.0 are valid Class C networks.. however if you then go classless and presumably enable ip subnet-zero on your cisco routers as well then no such restrictions exist including on 1.0.0.0/24 or 223.255.255.255.0/24. On Thu, 20 Mar 2003 bdragon@gweep.net wrote:
Its not quite that simple folks. The reason this particular block is reserved has some real technical merit, while the 69/8 muddle is strictly due to ISP negligence.
RFC 3330 got it wrong. Anyone remember the "Martian List" from the 1970-1990's? Trying to use the all-ones or all-zeros network for real traffic is not possible. Pre CIDR it was not possible to use 192.0.0.0/24 or 192.0.255.0/24. (the same was true on -every- network boundary) With CIDR, those boundaries moved to 1.0.0.0/24 and 223.255.255.0/24 e.g. only two reservered blocks instead of hundreds.
Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue.
--bill
Unless I'm mistaken, there is no technical issue with using the All-0's or All-1's classful networks. In fact, several of those networks are in use.
0.0.0.0/8 "this" network (all-zeros A) 127.0.0.0/8 loopback network (all-ones A) 128.0.0.0/16 reserved but unused (all-zeros B) 191.255.0.0/16 reserved but unused (all-ones B) 192.0.0.0/24 reserved but unused (all-zeros C) 223.255.255.0/24 reserved but unused (all-ones C)
As with 0/8 and 127/8, the other 4 networks could certainly be designated for some use, including "normal" end-users. This type of end-user usage would even continue to work with old classful gear.
I think your getting confused?
The restriction is on subnets using classful addresses, you shouldnt use all zeros and all ones subnet for a given subnetted classful network.
In the examples below, 192.0.0.0 and 192.0.255.0 are valid Class C networks.. however if you then go classless and presumably enable ip subnet-zero on your cisco routers as well then no such restrictions exist including on 1.0.0.0/24 or 223.255.255.255.0/24.
On Thu, 20 Mar 2003 bdragon@gweep.net wrote:
Its not quite that simple folks. The reason this particular block is reserved has some real technical merit, while the 69/8 muddle is strictly due to ISP negligence.
RFC 3330 got it wrong. Anyone remember the "Martian List" from the 1970-1990's? Trying to use the all-ones or all-zeros network for real traffic is not possible. Pre CIDR it was not possible to use 192.0.0.0/24 or 192.0.255.0/24. (the same was true on -every- network boundary) With CIDR, those boundaries moved to 1.0.0.0/24 and 223.255.255.0/24 e.g. only two reservered blocks instead of hundreds.
Simply having someonechange a DB entry or create an RFC will not affect the installed silicon base. Won't work. APNIC is on the moral highground here. They received damaged goods without notification. IANA needs better technical clue.
--bill
Unless I'm mistaken, there is no technical issue with using the All-0's or All-1's classful networks. In fact, several of those networks are in use.
0.0.0.0/8 "this" network (all-zeros A) 127.0.0.0/8 loopback network (all-ones A) 128.0.0.0/16 reserved but unused (all-zeros B) 191.255.0.0/16 reserved but unused (all-ones B) 192.0.0.0/24 reserved but unused (all-zeros C) 223.255.255.0/24 reserved but unused (all-ones C)
As with 0/8 and 127/8, the other 4 networks could certainly be designated for some use, including "normal" end-users. This type of end-user usage would even continue to work with old classful gear.
Nope, we weren't talking about subnets, but the classful networks themselves. Would you agree, as I've suggested, that there is no inherent technical limitation to using 223.255.255.0/24?
On Fri, Mar 21, 2003 at 12:11:47PM -0500, bdragon@gweep.net wrote:
Would you agree, as I've suggested, that there is no inherent technical limitation to using 223.255.255.0/24?
FWIW, I still see 'classful behavior' with WindowsXP (all recent service packs and such like) and also Solaris 2.7 (not sure about later releases, I'm guessing it's still there though). My point here is that many years after CIDR we still get weird anomalies in IP stacks --- so I wouldn't bet on anything being safe unless well tested. --cw
On Fri, Mar 21, 2003 at 12:11:47PM -0500, bdragon@gweep.net wrote:
Would you agree, as I've suggested, that there is no inherent technical limitation to using 223.255.255.0/24?
FWIW, I still see 'classful behavior' with WindowsXP (all recent service packs and such like) and also Solaris 2.7 (not sure about later releases, I'm guessing it's still there though).
My point here is that many years after CIDR we still get weird anomalies in IP stacks --- so I wouldn't bet on anything being safe unless well tested.
--cw
I don't doubt that there are OS's with bugs. However, my assertion is that 223.255.255.0/24 would continue to work under even Pre-CIDR gear. Therefore, even if an OS exhibited classful behaviour, that would be unrelated to the usefulness of 223.255.255.0/24. Are you saying that Class-based routers can not use 223.255.255.0/24? Aside from real design errors or unintended Features, 223.255.255.0/24 (and 192.0.0.0/24, 128.0.0.0/16, and 191.255.0.0/16) should be able to be assigned, should the IANA no longer need to maintain the reservations. That being that they are/were reserved to be assigned to some purpose, and not because they couldn't ever be used.
On Sun, 23 Mar 2003 bdragon@gweep.net wrote:
On Fri, Mar 21, 2003 at 12:11:47PM -0500, bdragon@gweep.net wrote:
Would you agree, as I've suggested, that there is no inherent technical limitation to using 223.255.255.0/24?
FWIW, I still see 'classful behavior' with WindowsXP (all recent service packs and such like) and also Solaris 2.7 (not sure about later releases, I'm guessing it's still there though).
My point here is that many years after CIDR we still get weird anomalies in IP stacks --- so I wouldn't bet on anything being safe unless well tested.
I don't doubt that there are OS's with bugs. However, my assertion is that 223.255.255.0/24 would continue to work under even Pre-CIDR gear. Therefore, even if an OS exhibited classful behaviour, that would be unrelated to the usefulness of 223.255.255.0/24.
Are you saying that Class-based routers can not use 223.255.255.0/24?
Thats a valid network, should be fine.
Aside from real design errors or unintended Features, 223.255.255.0/24 (and 192.0.0.0/24, 128.0.0.0/16, and 191.255.0.0/16) should be able to
But 191.255.255.255/24 or 191.255.0.0/24 are not usable for that Class B network. (Also 128.0.0.0/24 , 128.0.255.255/24 for that one) Which is where I am confused... if routing is classless, and RIR allocation is also classless (That is I can get 200.10.20.0/24 rather than 200.10.20.0 Class C or 200.10.0.0/16 rather than 200.10.(0-255).0/24's) why are we bothered about this at all. In fact, if you dont want to risk upsetting possible classful routers then you shouldnt assign any classless networks.. And on the subject of "broken" classful routers out there surely this is only a problem if the awkward network is assigned to that router as an external route should still be fine (this is an issue to do with subnet calculation within a network - right?) So just un-reserve all these blocks and hand them out, if anyone complains that they are running classful routers and it wont work give them another block or tell them to upgrade! Long thread this.. cant see why! Steve
be assigned, should the IANA no longer need to maintain the reservations. That being that they are/were reserved to be assigned to some purpose, and not because they couldn't ever be used.
-----Original Message----- On Mon, 17 Mar 2003, jlewis@lewis.org wrote:
I'd like to strongly encourage IANA to reexamine all current IANA-Reserved blocks, decide which ones will remain Reserved for the forseeable future, and which are likely candidates for assignment to RIRs at any future date, and update these to a more suggestive status such as Future-RIR-Assignment. Otherwise, we're going to repeat the 69/8 exercise (signifigant parts of the net ignoring the space months after assignment...some parts ignoring it likely for years) every time a net goes from being IANA-Reserved to assigned to some RIR.
That's probably a good idea from a practical standpoint. It's just hard to swallow the idea of IANA having to make policy a certain way just to accomodate the operators who aren't paying attention. Sorry for prolonging an endless debate.
On Mon, 17 Mar 2003, Andy Dills wrote:
Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems.
ARIN has dealt with the issue of RESERVED blocks within /8 allocations for years (and InterNIC, SRI-NIC, etc for a decade?). I guess 223/8 could be allocated to ARIN instead, if APNIC can't fix their database software to handle special use allocations. Or IETF could reserve the entire 223/8 for future special use allocations instead of the current practice of using whatever space was next in the queue when a new special use request is made. Otherwise, some RIR will have to deal with future RESERVATIONS within a /8 eventually. It seems a bit wasteful to reserve an entire /8 just because RIR's can't deal with RESERVED allocations, but I don't run an RIR so I don't know the capabilities of the database tracking systems.
participants (14)
-
Andy Dills -
bdragon＠gweep.net -
bmanning＠karoshi.com -
Chris Wedgwood -
Jared Mauch -
jlewis＠lewis.org -
John Tran -
Leo Bicknell -
Mark Borchers -
Philip Smith -
Richard A Steenbergen -
Sean Donelan -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu