> In order to make 240/4 work, we would have had to update the code on virtually every system on the internet and most of the applications.
Seems to me the reasonable answer is for the IETF to declare that 240/4 should be implemented as Unicast space. Not release it to IANA for distribution. Not declare it additional RFC1918 space. Just tell stack implementors that they should handle 240/4 the same as they do for the rest of unicast space. Buyers will pressure vendors to implement it or they won't. If enough vendors implement it, the IETF will be pressured to move it out of the reserved pool to some reasonable use. Take step 1 (define the space as standard unicast) and see what happens. If IPv6 dominates, great! We spent less effort changing 240/4 than we do arguing about changing it. If IPv6 transition drags on another decade... well, we positioned ourselves to get a little more utility from IPv4. Which is smart. It might also be useful to take back the majority of 224/4. Time has made it crystal clear that multicast isn't as useful as we thought it would be. We don't need that many multicast addresses. Regards, Bill Herrin -- William Herrin [email protected] https://bill.herrin.us/
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
