[address-policy-wg] 'Administrative ease' (was IPv6 allocations for 6RD)

On 28 nov 2009, at 15:57, Remco van Mook wrote:

> Hi Remi,
>
> could you help me in understanding why an ISP with, say, a /14 and  
> 2 /16s of address space would need a /28 of space to do 6rd? In my  
> understanding, even using a /56 per customer would give you a  
> requirement for just 19 bits of ipv6 space (18 bits for the /14, 1  
> extra to also make the /16s fit) on top of the /56s, if you just use  
> 3 instances of 6rd and prefix compression. This gives a requirement  
> of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch  
> of /15s and /24s to the mix, it will only add a few bits to the  
> requirement, not 11.
>
> Not that I don't want to give out the space if needed, but I'm  
> trying to understand the reasoning behind it. I find 'too  
> complicated' a tough argument to swallow given that the current and  
> working IPv4 setup in an environment like this is already way more  
> complicated.


My I propose to add the following to section 3.5 of RIPE-481 (or  
similair wording) analogues to 6.5 of the v4 policy:

Current text:

3.5. Conservation
Although IPv6 provides an extremely large pool of address space,  
address policies should avoid unnecessarily wasteful practices.  
Requests for address space should be supported by appropriate  
documentation and stockpiling of unused addresses should be avoided.

Proposed new text:

3.5. Conservation and Administrative Ease
Although IPv6 provides an extremely large pool of address space,  
historical evidence shows that what now seems infinit might one day  
turn out to become a scarce resource, Address policies should avoid  
unnecessarily wasteful practices of such resources. Requests for  
address space should be supported by appropriate documentation and  
stockpiling of unused addresses should be avoided. Assignment of  
address space based on the sole argument of administrative ease is not  
permitted. Examples of this include, but are not limited to, ease of  
billing administration and network management.

Rationale:

Classfull addressing in IPv4 proofs a nice example, but one can also  
look at 16 bit ASN or the global supply of oil for proof that  
resources that once seemed infinite can become scarce. Especially in  
'greenfield' deployments such as 6rd, which is still in the process of  
being standardized, and IPv6 in general, circumstances which may be  
considered 'wastefull' can be easily avoided.

Arguments supporting the proposal:

We slowly become aware what the costs of deploying a new technique or  
protocol are, one of the prime arguments global addoption of 32 bit  
ASN and IPv6 is slow is cost. We should try and prevent future cost by  
doing the same exercise twice by all means.

We keep telling our selves and the rest of the world IPv6 is not  
different, "96 bits no difference", it seems logical to keep the  
policies as much the same as possible.

One might argue that with standardizing an ethernet subnet to 64 bits  
all was lost anyway, this is not the case and mistakes from the past  
should be used as an example to prevent further damage instead of a  
validation to make the same mistake twice.


Arguments against this proposal:

By addopting this change now we again create a difference between the  
early adopters and people who follow, this is similair to the  
assignment of /8 address blocks in the early days of IPv4.

By prohibiting assignment for administrative ease we will slow IPv6  
adoption even more


MarcoH