[address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)

Hi WG,

Op 19 jul 2011, om 00:04 heeft Immo 'FaUl' Wehrenberg het volgende geschreven:
> Daniel wrote:
>> [no, I'm not advocating senseless waste - but what's "wasting" and
>> "making use of a technology to realize improvements in operational cost"
>> is probably very much in the eye of the beholder]
> 
> I must agree here. If you do the math, you come up with "we do have 
> enough addresses, even if we give any human on earth hundreds of /48"
> (and I hope nobody really wants to do). But as we are at the luxury 
> point where saving address space isn't really that big issue, why 
> shoud we make network design more difficult by introducing artificial 
> obstacles that possible saves some addresse? From my point of view 
> IPv6 address policy should focus on:
> a) making IPv6 easy deployable
> b) keeping the dfz table as small as possible without restrains to 
>   IPv6 deployment
> c) allowing clean network design even if that comes with the cost 
>   of a reasonable amount of additional address space usage
> 
> Obviously, we also should keep in mind that the IPv6 space is huge
> but finite so we should make sure that we will not run low on 
> address space at some point. 
> 
> To sum things up, I think the HD-Ratio of .94 is not what we want as
> it makes future deployment more difficult without any real reason.

I think Immo has given a good summary of what I heard on this list and from some people at the last RIPE meeting. Scott also brought this to our attention:

> FYI, a number of folks had this same issue in the ARIN region, and as a result policy ARIN-2010-12 (https://www.arin.net/policy/proposals/2010_12.html) was proposed, adopted, and implemented to address the problem.

Considering the amount of messages here related to this subject I think we should start working towards a formal policy proposal. Jan Žorž has already started working on a related proposal (see his message a few minutes ago on this list) so I think it might be a good idea to start from there.

Thanks,
Sander