[ppml] 240/4

> In a network like ours, you are talking about a multi year effort.

In a network like yours you simply filter any 240/4 announcements and
block any 240/4 traffic. 

If the RFC tells people that there MAY be problems routing 240/4
addresses on the open Internet, and that there MAY be technical problems
with software or embedded hardware, then that is sufficient. Any RFC
that wants to go beyond that and define specific limitations for 240/4,
such as Greenfield deployments, needs to justify those limitations and
that is hard right now. We simply don't know what will work and what
won't. We also don't know what is easy to fix and what is hard. Better
to just warn people and instruct the RIRs to pass on the warning and not
misrepresent 240/4 space as problem free. Let the end users decide how
they will use it, and if some future ISPs decide there are no router
issues and let it run on the open Internet, then that is fine. The RFC
writer should not limit these possibilities.

> Yes, from a coding perspective, this is much less than implementing a
new
> stack from scratch. However, from a deployment perspective, it is
still
> less effort than deploying IPv6, but not significantly less. And all
this
> to delay exhaustion by a year 1/2 at best... Not worth it IMHO.

We don't know the level of effort and we don't know the cost/benefit
ratio because these vary too much from organization to organization. Our
job is not to be big brother and engineer the runout date, but to act as
stewards and do all that a reasonable person can do to stave off
exhaustion. Releasing 240/4 for general use is something a reasonable
person would do. Warning people that there MAY be problems is also
something a reasonable person would do. But a reasonable person would
not make an executive decision for everyone in the world that 240/4 is
more trouble than it is worth.

--Michael Dillon