Stephen,In order to take advantage of 240/4, new code will have to be deployed and there are systems that cannot/will not be upgraded. While an organization receiving a block out of 240/4 could conceivably guarantee none of their systems dropped 240/4 on the floor, it is a bit unlikely that the rest of the Internet could be trusted to behave similarly. As such, people who received 240/4 blocks would likely be quite unhappy.
If people are going to use 240/4, it'll have be done "among consenting adults".
Rgds, -drc On Aug 7, 2007, at 11:43 AM, Stephen Gill wrote:
Hi Folks, I just got through reviewing your Internet Draft on 240/4 and we hadconsidered a different path in mind for this prefix with a draft prepared togive it a slightly different meaning ;).We were curious what you thought of allocating 240/4 to public duty for IANA assignment and future public global use. Why do you feel this should beRFC1918 address space instead of allocating it for wider Internet use? Clearly there would be operational hurdles and challenges to considertowards updating filters, code, and possible other nooks and crannies butthe net result and added lifetime for v4 might be worth the effort. Looking at the recent allocation history we've seen: 2007 8 /8's (9 minus 1 re-listed as reserved) 2006 10 /8's 2005 13 /8's 2004 9 /8'sSo this could possibly give us an additional 1-2 years of IPv4 lifetime (hopefully more as the end nears). This would bring the current aggregate number of /8's from roughly 44 to 60 available, an increase of approximately36% allocatable /8's.Does the need for more private addressing outweigh the need for more public addressing? At a minimum it would be great to add a paragraph addressingthis important question. Thoughts? -- Stephen Gill, Research Fellow, Team Cymru http://www.cymru.com | +1 312 924 4023 | gillsr at cymru dot com* sig-policy: APNIC SIG on resource management policy *_______________________________________________ sig-policy mailing list sig-policy at lists dot apnic dot net http://mailman.apnic.net/mailman/listinfo/sig-policy