[56805] in North American Network Operators' Group
Re: APNIC returning 223/8 to IANA
daemon@ATHENA.MIT.EDU (bmanning@karoshi.com)
Mon Mar 17 10:00:32 2003
From: bmanning@karoshi.com
To: jlewis@lewis.org
Date: Mon, 17 Mar 2003 07:01:32 -0800 (PST)
Cc: iana@iana.org, bicknell@ufp.org (Leo Bicknell), nanog@merit.edu
In-Reply-To: <Pine.LNX.4.44.0303170926350.12785-100000@redhat1.mmaero.com> from "jlewis@lewis.org" at Mar 17, 2003 09:42:03 AM
Errors-To: owner-nanog-outgoing@merit.edu
> 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
