The reason I ask is that I was perusing RFC 3330 and noted that it specifically stated that the basis for the reservation of 223.255.255.0/24 no longer applied and that the block was subject to future allocation to a RIR. Yet there was an argument about it.
The argument was because it wasn't clear what the original basis was for the reservation nor was it clear how things had changed. Imagine you have a device that uses lots of addresses but considers them to be sequential numbers rather than bit patterns. For instance, this device could be configured with a starting number and then dole out sequential numbers to connections based on that starting number. This is how a lot of terminal servers work. Imagine that you give the terminal server a number like 223.255.255.200 as the starting number to assign to dialup connections and that terminal server has a 32 port card installed. Then one day an engineer installs a second 32 port card. The terminal server continues to function just fine until one day when it tries to assign 223.255.255.255 to an incoming call followed by assigning 224.0.0.0 to the next call. Suddenly you have all kinds of wierdness breaking out with mysterious broadcast traffic and multicast traffic coming from the device. But it only happens for short bursts during the busiest times of the day. What the heck is going on!? Could you debug that? Would you want to debug that? Maybe that's why 223.255.255/24 should be forever reserved. --Michael Dillon
On Tue, 29 Apr 2003 Michael.Dillon@radianz.com wrote:
Imagine you have a device that uses lots of addresses but considers them to be sequential numbers rather than bit patterns. For instance, this device could be configured with a starting number and then dole out sequential numbers to connections based on that starting number. This is how a lot of terminal servers work.
Have you configured any terminal/access servers recently?
Imagine that you give the terminal server a number like 223.255.255.200 as the starting number to assign to dialup connections and that terminal server has a 32 port card installed. Then one day an engineer installs a second 32 port card. The terminal server continues to function just fine until one day when it tries to assign 223.255.255.255 to an incoming call followed by assigning 224.0.0.0 to the next call. Suddenly you have all kinds of wierdness breaking out with mysterious broadcast traffic and multicast traffic coming from the device. But it only happens for short bursts during the busiest times of the day. What the heck is going on!?
I'd call that incompetence. A starting number of 200 + 64 ports = too small an IP pool. The cisco gear I use is a bit smarter and when configuring IP pools, both the starting address and ending address are specified (and you can specify multiple non-contiguous ranges). I generally omit /24 network/broadcast addresses from IP pools because too much software assumes everything's a /24 and if you assign someone a /24 broadcast IP, they're going to receive some (maybe alot of) junk traffic depending on what's in the other subnets of the /24 they're in.
Maybe that's why 223.255.255/24 should be forever reserved.
That's way too stupid a reason. That better not be it. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
<insert commentary about fictional technical reason for reservation of 223.255.255.0/24>
Maybe that's why 223.255.255/24 should be forever reserved.
Thankfully, there is no technical reason for a reservation of 223.255.255.0/24. Idiotic people and equipment will crop up all over the address space, and we don't reserve that either.
--Michael Dillon
As the one who originally brought this up in nanog, the sole reason why the conversation came up was documentation. The last known RFC on the matter stated that 223.255.255.0/24 was reserved but that it MAY be allocated in the future. The part that was ambiguous to APNIC and the network community was what status 223.255.255.0/24 was in. It could be inferred by IANA's allocation, that it was no longer reserved (in which case the RFC should be updated to reflect that it USED to be reserved), or equally could be inferred that APNIC was provided 223/8 - 223.255.255.0/24, since the last known statement on the matter still said it is presently reserved. Let's not confuse people with made up technical reasons for the reservation. The issue is solely a documentation/ambiguity problem.
participants (3)
-
bdragon＠gweep.net -
jlewis＠lewis.org -
Michael.Dillon＠radianz.com