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

Wed May 15 09:03:37 UTC 2013

Hi RPD List

I am fresh from an AfriNIC IPv6 training session last week and signed up to this list last week.  Please excuse any protocols I might be missing, but this is the first real post that is of importance to me (I was informed that here we speak for ourselves and not the companies we work for.)

There is a fairly large allocation request in planning for a multi-national in Africa.  I can understand the reluctance of advertising anything smaller than a /48, and agree with that.  In our situation it will make things much easier if we could advertise portions of the allocation out of various countries.  Maybe advertise the big block out of one central place and the smaller blocks per country/region?

Can we drop the /48 portion from the proposal and add the ability to advertise smaller blocks out of the allocation?

Thanks and Regards

Fred

________________________________________
From: rpd-bounces at afrinic.net [rpd-bounces at afrinic.net] on behalf of Andrew Alston [alston.networks at gmail.com]
Sent: 15 May 2013 08:39 AM
To: 'Ernest'; 'AfriNIC Resource Policy Discussion List'
Subject: RE: [AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce   entire v6 block as single aggregate"

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.http://www.apricot2013.net/program/network-management-workshop
•       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
This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.
“This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link https://webmail.vodacom.co.za/tc/default.html " 