[AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce entire v6 block as single aggregate"

Wed May 15 07:58:24 UTC 2013

Hmm - ever since I received my IPv6 /32 block (Jan 2007), I have been
announcing the full block and a smaller "regionalised" block - so for
example in London and DE-CIX - I announce my /32 and a /40 of it.
The /40 'regional' block contains all IPv6 addresses I use in Europe.

I use different regional blocks in different regions.

If its filtered - tough - the /32 is still there.

So it seems I'm already following the suggested modification.
I guess I support the proposal.

On Wed, 2013-05-15 at 08:39 +0200, Andrew Alston wrote:
> Hi RPD List,
> 
> While I see the logic behind this proposal, I have to oppose it based on technical grounds.
> 
> If said multi-national applies for a large enough block to cover each country and is allocated space equivalent to a single /32 per country (so in this case, a /28, or 16 /32s), then this proposal would work since the multi-national could announce /32s from each location.  However, 
> allowing for announcements of /48s out of the LIR blocks would not work because of filtering.  There are many that still only accept /32s, other than when the /48 is assigned out of a known PI block.
> 
> To allow this would only result in partial reachability for the block and I'm not sure that's a good idea at all.
> 
> At the same time, huge allocations of /28s or whatever may not be practical though I think that’s another debate entirely.
> 
> I do acknowledge the problem the proposer has, and I do believe the economic problem stated needs to be rectified, I just don't agree with the proposed solution.
> 
> Andrew
> 
> 
> -----Original Message-----
> From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf Of Ernest
> Sent: Wednesday, May 15, 2013 8:25 AM
> To: AfriNIC Resource Policy Discussion List
> Subject: [AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce entire v6 block as single aggregate"
> 
> Colleagues,
> 
> The policy proposal below has just been submitted as detailed. We encourage the community to study and provide appropriate feedback on the proposal.
> 
> Regards,
> Ernest.
> 
> 
> __________________________________________________________________
> 
> Identifier:	    AFPUB-2013-V6-001-DRAFT01
> 
> Draft Policy Name:   Remove requirement to announce entire v6 block as
> single aggregate
> 
> Author(s)
>  :
>     Steven Wiesman,
>     steven.j.wiesman at accenture.com,
>     Accenture
> 
> 
>    Steven Tapper,
>    steven.tapper at accenture.com,
>    Accenture
> 	
>    Charles Hendrickson,
>    Charles.hendrickson at accenture.com,
>    Accenture
> 	
> 
> Submission Date:   2013-05-16
> 
> 
> 
> [1]  Summary of the Problem Being Addressed by this Policy Proposal
> 
> --------------------------------------------------------------------------------------------
> 
> The current AFRINIC allocation policy provides for and assigns IPv6 space to companies residing within the region’s countries.  This assignment policy aligns with the IPv6 hierarchy but does not allow for multinational companies’ efficient distribution of IPv6 address space. Under the existing policy, a multinational company has to apply for membership and IPv6 resources from every location in which it operates.  This is both costly and time consuming to the Registry and the Multinational Company applying for membership.
> The RIR has to maintain and organize multiple prefixes assigned to one company and provide services appropriate to the membership process.  The company applying for membership has to perform the same function of managing multiple IPv6 assigned ranges and technically operate and manage the disparate IPv6 ranges assigned to the locations.
> 
> For example under the existing policy,
> •	Multinational company A operates in 15 countries within the
> AFRINIC region.
> •	The Multinational Company needs to apply for membership from each
> of the 15 locations.
> •	The Multinational Company needs to apply for IPv6 resources from
> each of the 15 locations.
> •	The Multinational Company has 15 potentially different prefixes to
> manage and operate.
> •	The Multinational Company has 15 potentially different prefix
> lengths to manage and operate.
> •	The multinational company needs to pay yearly the renewal fees to
> lease the IPv6 address space awarded for each location.
> •	AFRINIC needs to review and award location based appropriate
> prefixes to each of the 15 locations.
> •	AFRINIC needs to assign IPv6 resources to 15 separate locations
> which may come from separate areas of the RIR managed IPv6 ranges.
> •	AFRINIC needs to process the paperwork for 1 company 15 times for
> membership.
> •	AFRINIC needs to process billing on a yearly basis for 1
> multinational company 15 different times.
> •	IPv6 address assignments are location based and must only be
> advertised as an aggregated prefix to the Internet in which the prefix was awarded.  Additional subnetting and advertisement of the awarded IPv6 address range is not permitted.  For example:
> -	One /32 aggregated from one location
> -	Smaller subnets, ie /48 from the same prefix, cannot be advertised
> out of another location
> 
> 
> [2] Summary of How this Proposal Addresses the Problem
> 
> -----------------------------------------------------------------------------
> This proposal allows for the Multinational Company to apply for and obtain a larger aggregated IPv6 block of addresses and allows the company to allocate, assign and advertise the IPv6 address range awarded according to its own internal IPv6 hierarchical policies.
> Additionally, AFRINIC will now only need to review and maintain membership records for one instance of the multinational company, and by prefix, immediately identifies the company.
> 
> For example under the proposed policy,
> •	Multinational Company A operates in 15 countries within the
> AFRINIC region.
> •	The Multinational Company needs to apply for membership one time.
> •	The Multinational Company needs to apply for IPv6 resources one
> time providing sufficient evidence of hierarchical design.
> •	The Multinational Company is awarded a prefix sufficent to cover
> the 15 offices and future growth and or expansion within the region.
> •	The Multinational Company has one prefix to manage, operate and
> break down according to its internal policy.
> •	The multinational company needs to pay yearly the renewal fees to
> lease the IPv6 address space awarded one time.
> •	AFRINIC needs to process the paperwork for 1 company.
> •	AFRINIC needs to review and award a prefix to the multinational
> company one time.
> •	AFRINIC needs to process billing on a yearly basis for 1
> multinational company one time.
> •	The IPv6 address assignment is company identifiable.
> •	Policy allows for multiple aggregated prefixes to the Internet.
> •	Additional subnetting and advertisement of the aggregated IPv6
> address range is permitted.  For example:
> -	One /32 aggregated from one location
> -	Smaller subnets, ie /48 from the same prefix, advertised out of
> another location.
> 
> 
> [3] Proposal
> ----------------
> We propose to delete the following sentence in section 6.1.1 (d) from the IPv6 policy “The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months.”
> 
> 
> [4] Revision History
> 
> None
> 
> [5] References
> 
> IPv6 Allocation Policy
> https://my.AFRINIC.net/help/policies/afpol-v6200407-000.htm
> 
> __________________________________________________________________
> 
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6147 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20130515/68377704/attachment.bin>