[arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria
Joe Maimon wrote:
> cja at daydream.com wrote:
>> Hi everyone...
>> I have seen virtually no comments regarding this policy. I can't
>> imagine there is a lack of opinion out there...
>> Happy Holidays!
> I support this proposal, even as I suspect its a no-op, and even as I
> have the following reservations, since now is not the time to keep a
> tight rein nor is it the time to let them drag on the ground.
> At 16 /48's with potentially one /48 per customer, thats a significantly
> lower bar than with IPv4 multihoming requirements, where a /24 per
> customer raises some eyebrows.
> I believe that efficiency and allocation guidelines need to be
> reconciled with a less ipv4-centric viewpoint.
> Judging efficiency by the # of assigned /48 basically penalizes
> organizations who choose to not follow allocation recommendations of /48
> per site/customer and rewards those who disregard the /56 and any other
> bit-points in between /64 and /48.
Why not just drop the 'efficient use' part of the multi-homed part of
the policy, and put the effort into ensuring the requesting site *is*
multi-homed, and not just planning on it?
Perhaps I'm off base here, but this may also lower the barrier to entry
for some, and free up resources for ISPs.
a) the requester won't have to request and implement space (to meet the
efficient use criteria) from their provider just to get a PI block, just
to have the provider un-provision the space a little while later so
their client can get their own space
b) entrants who are already multi-homed with IPv4 who have never
implemented IPv6 don't ever have to worry about renumbering from PA
space into PI