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

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.
However, a mayor issue right now, where most ISPs are in the process 
to design and roll out IPv6 to their end-customers real soon, is that 
once they started to assign networks to very few customers some time 
ago, they cannot apply for an additional network without either lying 
to the NCC (about assignments to customers that have not been made 
yet) or create a crude design, then start rollout, stop rollout when 
addressspace is used, request additional addresses and then redesign 
the entire network (or be stuck with your crude design you came up 
with to work around the 'to few addresses to do a proper design' 
issue). So what we really need is to allow the NCC to make assignments
based on reasonable guesses if the resulting prefix size (of both,
the existing prefix(es) and the newly requested prefix) will be 
reasonable in HD-Ratio terms.

Best regards,

Immo Wehrenberg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </ripe/mail/archives/ipv6-wg/attachments/20110719/184f2b71/attachment.sig>