[ppml] 240/4

[Tony Hain]

michael.dillon wrote:
> > 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.

You seriously underestimate the problem space by making it sound like simply
a routing problem. That space was undefined at the time of testing so every
Windows system will not even initiate traffic to that block through the
default route because it was not clear if there should have been some other
path that was special for that block. Again, don't call MSFT stupid over
this, because if they had treated it as just unicast and you wanted to do
something else now you would be calling them stupid for ignoring the RFC
that said the block was different.

It is not a matter of fixing the code, it is about the reality of getting
the old systems weeded out of deployment. Joe-sixpack will not spend money
on a new system just to appease some obscure policy body. There would have
to be a clear value return, and getting those apps deployed will require
extensive effort. There is very little reason for a vendor to expend that
effort for a short-term hack of using 240/4, when it is clear they will have
to turn around and do it all over again to get to IPv6. 

> 
> > 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.

I agree that defining it as unicast is a reasonable thing to do. At the same
time, doing so requires a serious health warning, calling out the simplest
known failure modes at the time. It does not have to be an exhaustive list,
but it should be made clear that use of that space has to be for a
completely self-contained collection of new end systems with no expectation
of it every working to interact with the rest of the IPv4 address space
(including 1918).

Tony