IESG,
IMHO the allocation of such space would be extremely valuable to the
Internet Community by allowing operators to minimize the impact of
introducing CGN if required (which can be accomplished quite successfully
in a Dual Stack deployment while introducing IPv6).
The allocation of this space does not hasten or slow the deployment of
IPv6 since those factors are controlled by a wide range of influences
including the one most uncontrollable element - the home user and their
ecosystem.
The allocation would solve real technical problems and would provide a
much more deterministic and controllable environment then the potential
rampant use of more random squat space. Allocation of
such space would also be much more efficient then use of multiple
allocations
of RIR space for the same use. The technical challenges can be overcome
as the
use of squat space (by some operators) has shown the viability of using
non-RFC1918
for endpoint addressing by which a NAT is northbound.
On 11-11-29 10:37 PM, "Randy Bush" <randy(_at_)psg(_dot_)com> wrote:
you allocate more what is essentially 1918 space and it will be used all
over the place,
And yet it's not RFC1918 space by definition. If a provider uses squat
space for private functions, it's also not RFC1918.
We may not be able to prevent some from doing the wrong thing, but this
should not stop us from providing the tools for many to follow the
guidance to do the right thing.
from your hack to enterprises to $diety knows what. and
it will leak into the global table just as current 1918 space does.
This is why a well known block is better. Operators can filter and
control this from both sides as oppose to dealing with random blocks.
Randy
Regards,
Victor K
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf