RFC3330 issued in September 2002 does indicate that this address block is subject to future allocations. But I think people were expecting something from the IAB/IETF before IANA actually allocated previous special use reserved address blocks. My understanding was RFC3330 was written by IANA and published by IANA to document existing practices, not to change previous practices. Eventually we'll use it. The simpliest solution is for IANA to inform APNIC that it was an oversight. The 223.255.255.0/24 network block within the 223/8 CIDR block assigned to APNIC is still IANA-RESERVED per RFC3330 and previous practice; and not allocated for APNIC's use at this time. Its probably easier for APNIC to flag the 223.255.255.0/24 network within the CIDR block 223/8 as IANA-RESERVED in the APNIC database just like ARIN does with the other IANA-RESERVED blocks in ARIN's database; rather than do the ugly CIDR block breaking of 223.0.0.0-223.255.254.255 and 223.255.255.0-223-255.255.255. But that is a decision for APNIC. On Mon, 24 Feb 2003, Geoff Huston wrote:
My interpretation of this is that the IETF, by publishing an RFC with an "IANA Considerations" section can nominate that an address block declared allocatable under certain criteria, or they can "reserve" the prefix.
"reserving" in my mind constrains IANA from undertaking any activity on this block, and this is the state until the IETF elects to produce a successor document with an IANA Considerations section that nominates some other status to the block.
"Reserved" blocks in my opinion cannot be passed to RIRs, or anyone else - the IANA cannot do anything with the block other than register its reserved status, and this can only be undone by an action of the IETF.
Hence, my reading of the IANA registry: http://www.iana.org/assignments/ipv4-address-space is that this is a flawed implementation of the instructions in RFC 3330, and that the 233.255.255.0/24 should be listed IDENTICALLY to 128.0.0.0/16
i.e. its status is actually: 223.255.255/25 IANA - Reserved - RFC 3330
if the IANA is to consistently act upon RFC 3330 (as indeed it should)
Perhaps the IETF folk on this message should review the RFC and the IANA registry and see if they agree with this interpretation, and make their conclusion as to the accuracy of the registry as it is currently published:
("223/8 Feb 03 APNIC (whois.apnic.net)")
My view is that this block as properly "Reserved", and that the "subject to allocation" is an addendum that indicates a forward intention of the IETF, but not a capability for any IANA action.
As my only humble suggestion, perhaps the best thing right now is for the APNIC folk to refrain from any assignment actions regarding this prefix until the IETF folk and the IANA sort out this inconsistency in the interpretation of RFC 3330.
Geoff
Date: Mon, 24 Feb 2003 00:32:47 -0500 (EST) From: Sean Donelan <> To: Cc: Subject: Re: 223.255.255.0/24
On Sun, 23 Feb 2003 bmanning@karoshi.com wrote:
why would an APNIC/AP region specific issue need to be discussed on the NANOG list and not the RIPE/AFNOG/et.al. regional ops lists? This is a prefix delegated to the APregion and so they should be the ones who set the policies for the prefixes they are responsible for. I appreciate their willingness to share the outcome of their deliberations, but why NAites have any special say in AP policies is a bit beyond me.
The question is really whether IANA properly implemented the relevant RFC's by delagating a block containing a reserved special use address to a registry without maintaining the previous reservations on those addresses.
Its not up to APNIC how to handle the reserved special use addresses, just like the other special use addresses in ARIN's space are really outside of ARIN's scope. ARIN can't re-assign special use addresses in "its" space for other purposes. Nor should APNIC or RIPE or LANIC or any other registry which is assigned a /8 block containing special use addresses.
Its not APNIC bashing. If the ARIN board got to gether and decided to assign 128.0.0.0/16 I think folks would be raising questions about ARIN.
IANA should have properly excluded the IANA reserved special use block from the delegation to APNIC, just like the other reserved special use blocks are reserved from ARIN's use.