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
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
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.
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.
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
I suppose IANA *could* refund 1/2**16'th of the price paid by APNIC.
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.
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.
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.