APNIC returning 223/8 to IANA

Mon Mar 17 15:28:10 UTC 2003

In a message written on Mon, Mar 17, 2003 at 07:01:32AM -0800, bmanning at 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 at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20030317/fb91983f/attachment.sig>