Hi David,
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.
Do you have some sense as to what those systems are, code versions, and
how many? I know it is on the list of Juniper martians for instance.
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.
I see this as a similar challenge to what we have today, with an added
systems component. Certain entities with newly allocated prefixes have
already experienced reachability issues with their allocations due to
stale or outdated filters. This was largely overcome with a bit of
operational planning and foresight.
At some level I could envision something similar for 240/4 whereby it
could be allocated and de-classified as a bogon, and then tested for
reachability using pilot/anchor prefixes after "sufficient" time has been
given for vendors and operators to implement the change. Ongoing
reachability testing (active and passive) could be performed from the
newly debogonized ranges to see how reachability compares to previously
allocated /8s in recent past. Granted, it would take some time, testing,
and planning but is it not conceivable that reachability could be
attained to similar levels as that of a normal newly allocated,
de-bogonized /8?
It seems worth considering if possible systems issues can be overcome with
enough time given for planning if it extends the life of IPv4 by a
reasonable amount. It would also be useful to put those considerations
into the draft whatever the final concensus ends up being.
-- steve
