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@xxxxxxx> 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@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf