[56949] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: APNIC returning 223/8 to IANA

daemon@ATHENA.MIT.EDU (bdragon@gweep.net)
Sun Mar 23 19:21:51 2003

To: cw@f00f.org (Chris Wedgwood)
Date: Sun, 23 Mar 2003 19:21:13 -0500 (EST)
Cc: nanog@merit.edu
In-Reply-To: <20030321214141.GA28278@f00f.org> from "Chris Wedgwood" at Mar 21, 2003 01:41:41 PM
From: <bdragon@gweep.net>
Errors-To: owner-nanog-outgoing@merit.edu


> 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.



home help back first fref pref prev next nref lref last post