Re: [sig-policy] draft-submission - draft-wilson-class-e-00.txt
> 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