[address-policy-wg] 2011-04 Last Call for Comments (Extension of the Minimum Size for IPv6 Initial Allocation)

Hello Richard,

On Wed, Apr 11, 2012 at 3:21 PM, Richard Hartmann <
richih.mailinglist at gmail.com> wrote:

> On Wed, Apr 11, 2012 at 14:02, Turchanyi Geza <turchanyi.geza at gmail.com>
> wrote:
>
> > It is bad to make looser the address allocation rules at the RIR level.
> > Address allocation rules MUST be the same for every regional Internet
> > registry.
>
> No one is stopping the other RIRs from following suit; if anything
> this will most likely speed up adaption. I agree that a similar policy
> across all RIRs is desirable, though.
>

There is a common rule, the HD ratio. It is in an RFC.

>
>
> > Therefore is is wise to create exceptional rules that could support 6RD,
> > however, these rules should be discussed at global level and MUST be
> valid
> > only for a limited period of time.
>
> So you want to have a goldrush period where LIR grab a /29 because
> they can and then exclude LIR which are created at a later date and/or
> LIRs which did not act quickly enough from gaining the same resources?
> Or should LIRs be required to return addresses assigned under this
> policy? Will they be required to use this for 6rd only to ensure
> simple returns? What about 6rdv2? Will this be covered under allowed
> use? What about 7rd? What about something else entirely?
>
> Definitely not. However, the current proposal might provoque a goldrush
period.

Even worse: LIRs tend to merge. In the IPv4 world DEC asked for a class A
space and got it. So did HP and Compaq Computers. Who owns these three
class A today? HP, because Compaq swallowed DEC, then HP swallowed Compaq.

The current proposal pave the road for similar stories, even by very small
LIRs. Goldrush belever will profit from this!

As I mentionned, even 6RD coukld fit in the old allocation framework and
some people might invent even more need for addresses, if you allow loosing
the rules.

Best,

Géza
.

> --
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20120411/bcb115e9/attachment.html>