[policy-wg] IPV6 PI space

[Vincent Ngundi]

How about we assign a _minumum of a /48 (those who need more will have to 
justify that to AfriNIC) to end users and critical infrastructure providers 
and reserve a /32 for each assigned /48?

Regards,

-Vincent

On Thu December 14 2006 16:34, Andrew Alston wrote:
> Hi There,
>
> Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due
> to other commitments, however, having been involved in the P.I debate for a
> while and having kept a close watch on the developments in this regard
> around the world, I tend to take a different view on this.
>
> I firmly believe that with regards P.I space, a /48 allocation is enough.
> Firstly, for IXP space, there is a trend to move towards /126 networks on
> point to point allocations (do not use /127's, there are a variety of
> reasons for this), therefore, IXP's could operate off a single /48,
> utilizing /64's per IXP, and utilizing /126 networks for the actual peering
> requirements.
>
> Secondly, with regards to end user networks, for AfriNIC to allocate /32's
> in P.I space would again run contrary to what the global trends are, ARIN
> has agreed to /48 P.I space, and (someone correct me if I 'm wrong here),
> APNIC is about to ratify their /48 P.I policy.
>
> Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an
> end point network, a /48 should be more than sufficient for P.I allocations
> to individual companies.  ISP's should qualify for /32s and become LIR's if
> they want the /32s and are allocating onwards.
>
> I would prefer therefore that as per global trends, AfriNIC allocates a set
> block out of which to assign /48 P.I prefix's (possibly a /30 or a /31),
> and assigns the /48s outta that prefix for all P.I space.  That block can
> then be made public, so that those of us that update filters to filter /48
> deaggregated announcements can add exceptions for the specified prefix.
>
> I would say that where companies have more than one physical location there
> could potentially be an exception to this policy, so that a company that
> has multiple physically diverse branches, might for example qualify for
> multiple /48s, purely for the purpose of better routing aggregation, but
> again, these /48s out of the same block referred to earlier.
>
> The above would be more in line with what is done globally, and would avoid
> the complications of BGP filters that were different for different regions!
>
> Thanks
>
> Andrew Alston
> TENET - Chief Technology Officer
>
> -----Original Message-----
> From: policy-wg-bounces at afrinic.net [mailto:policy-wg-bounces at afrinic.net]
> On Behalf Of Mark J Elkins
> Sent: Thursday, December 14, 2006 2:41 PM
> To: AfriNIC Policy Working Group List
> Subject: [policy-wg] IPV6 PI space
>
> Firstly - the training and knowledge received in Mauritius was great
> with respect to IPV6. This has allowed me to better understand the needs
> and concerns of others. However - I am by no means the expert and
> expected to be corrected when incorrect.
>
> I believe there needs to be some sort of PI policy. I do not believe
> that is is very healthy for Exchange Points (IXP's) to use the address
> space of a particular ISP. I also believe that its unhealthy for some
> organisations (eg - CCTLD's) that currently have IPV4 PI space and who
> are Multi-Homed to also have space from any particular ISP.
>
> I believe that AfriNIC needs two different PI allocation policies for
> these two different areas:
>
> For Exchange Points
> ---------------------------
>
> These need a small, non-wasteful, low maintenance allocation - for
> example, an allocation of a /44 would allow for 16 "networks" (each of
> /48) to be established. A /48 is more than suitable for a single (even
> geographically dispersed) IXP, thus a /44 should be sufficient for a
> country or a countries ISPA. (By this - I'm thinking of South Africa
> with currently only one active peering point, but with potential
> expansion to a total of three points - but all managed by a single ISPA
> type organisation).
> I'd like to see AfriNIC allocate these /44's out of a single /32, which
> means there are 4096 of these allocations available. These should be
> only used for IXP's and should (I'd like to suggest) have no
> re-occurring charge associated with them.
> The allocation could be made to the ISPA type organisation - so that
> there is no need for ongoing maintenance of the allocation (or at least
> greatly reduce the maintenance burden on AfriNIC).
> I see this as promoting the use of IPV6 and also of IXP's (and ISPA's)
> within the AfriNIC region.
> By allocating a /44, the Reverse DNS responsibilities (and hence - usage
> of AfriNIC resources) is minimalised and filtering could also be done on
> /44's. The allocations should be made on /40 boundaries so when there is
> a need to allocate a particular country (or ISPA) with additional space,
> to do so from the same /40. This allows for 256 different "countries".
> Technically - IXP allocations do not need to be globally route-able - so
> this type of allocation should be fine.
> The other assumption here is that the IXP (or ISPA - whatever) is a
> non-commercial (non-profit) organisation - in order to be exempt from
> re-occurring fees.
> (By extension, maybe even allocate a /32 to AfrISPA - and let them
> delegate onwards? - but I'm trying to not have options)
>
> For other existing holders of IPV4 PI Space
> ---------------------------------------------------------
>
> For all organisations that currently have IPV4 PI space within the
> AfriNIC region, they should be allowed to obtain full /32's of IPV6
> space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an
> AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or
> proof that it has been requested and is impending.
> (kiss - Keeping It Simple)
>
>
>
> No policy is exempt from changes in the future. The above policy
> suggestions are to tackle todays requirements whilst keeping them
> flexible enough that they may serve the AfriNIC regions needs for the
> next few years.

-- 
$ whois -h whois.afrinic.net VIN1-AfriNIC