[ppml] 240/4

[bmanning at karoshi.com]

On Fri, May 04, 2007 at 10:16:08AM +0100, michael.dillon at bt.com wrote:
> 
> 
> > 	again, if you think this is useful idea, TRY IT OUT.
> > 	then document the effects and what needs to be changed
> > 	before writing a wellmeaning but worthless document.
> 
> Trying it out, only results in documenting the current state of affairs.

	you have to start someplace.

> It is more important to set the stage for future work than to document
> current technical details. We already know that current software
> cripples 240/4 addresses. That is not an issue. The purpose of the RFC
> is to get 240/4 addresses *OUT* of reserved status and back into play.

	i never said it was an issue, i simply stated that it would
	be nice to know the magnitude of the problem space.

> 
> > 	i suggest that you attempt to use 240.240.240.0/24
> > 	on a subnet in your local infrastructure and then tell us
> > 	the results.
> 
> This is useless info. The people who should be trying 240/4 will be
> those who have access to system source code so that they can identify
> what needs to be patched to enable 240/4 to work. Obviously, they don't
> need an RFC to get permission to do the work, but if an RFC *DID*
> release 240/4 from purgatory, I have no doubt that many such people will
> do the work.

	your faith in coders and thier manaagers is a joy to behold.
	the reason i posted my Linux example is that I HAVE the source
	code.  I don't have the code  for  cisco, linksys, airport, or
	macOS, or (fill in the blanks)...

	my original take on this problem is that it could (and should)
	be treated like the original CIDR problem.  at that time, certain
	netblocks were considered "reserved" and hardcoded as not usable.
	The net 39 experiment was to shake out the scope of the problem
	space, what needed to be changed in the protocol processing stacks
	to ensure the address space would be useful...  BEFORE releasing
	the address space into use.

	to be fair, i want a "punch-list" of things that don't work w/
	these addresses - then there are concrete steps that can be taken 
	to try and sell the idea to these folks that it is useful/prudent
	to spend the money to change their code in future.

	otherwise, i think this is wishful thinking.

> 
> > # ifconfig eth1 240.240.42.14
> > SIOCSIFADDR: Invalid argument
> > 
> > on a couple of Linux 2.4.x kernels.  (old i know)
> 
> Useless info. What code did you patch to fix this? What variable did you
> create in the /proc filesystem to enable/disable use of 240/4 addresses?

	i've not patched it yet.  this is stock RedHat/Debian base.
	when/if I do, i'll share w/ the developers and see if they wish
	to make the changes.

> 
> --Michael Dillon
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml