/48 for each and every endsite (Was: European ISP enables IPv6 for all?)

Wed Dec 19 20:35:27 UTC 2007

Christopher Morrow wrote:
> On Dec 19, 2007 5:03 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>> On Wed, 19 Dec 2007, Jeroen Massar wrote:
>>
>>> "new" as in "We already have one, but we actually didn't really know
>>> what we where requesting, now we need more"
>> We got our current block in 2000 (or earlier, I don't know for sure, but
>> 2000 at the latest). So yes, we didn't know what we were doing back then.
>> Then again, I'd say nobody knew back then.
>>
> 
> I'd say it's fair to bet that quite a few folks in all regions pursued
> ipv6 allocations more than 3-5 years ago when the policy was
> essentially '/32 per provider, simply show a business plan for
> providing services to 200+ customers in the next N years' (without
> much in the way of planning or proof-of-planning).

HD ratio and all related documentations have existed for quite some time
already. If they would have read the docs they would have understood
what it meant and also gotten the reason why they asked for the 200+
rule in the first place.

> [..] Some large providers are attempting to plan
> 5-10 years out for address policy if possible, not everyone has that
> luxury, but in the end we (internet routing community) want limited
> prefixes/org that means planning horizons have to be adjusted up from
> 2yrs to <something else>.

I can fully agree with this and it is definitely something that one
might want to push into the RIRs. I actually hope that most ISP's do
realize that they might become a bit larger in a few years, fortunately
there is the 7 adjacent /32's that can be used for sizing up quite a
bit. The only thing then is to hope that only the aggregate ends up in BGP.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20071219/8e677514/attachment.sig>