[AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy Proposal: IPv6ProviderIndependent (PI) Assignment for End-Sites

Tue Mar 13 17:31:43 UTC 2007

As I've stated in previous emails, I still believe that we should probably
stay in line with what the other regions are doing here in order to avoid
complications and different filtering systems globally to make the P.I space
work.

That is, a single block out of which allocations of /48 are made as a
minimum.  That way, a single prefix list could be applied on an ISP's bgp
peers that basically says (cisco syntax here, though its simply an
illustration of principle)

Permit aaaa:aaaa::/yy le 48

permit xxxx:xxxx::/yy le 48 

permit zzzz:zzzz::/yy le 48

permit ::/0 le 32

Where A X and Z are the pre-defined P.I blocks from the various regions,
everything else that's in the tables that smaller in size than a /32 gets
dumped.  

If we then decide to allocate these /48s on /44 boundaries so that
organizations can grow (/44 being what I would consider a reasonable
boundary for growth of individual companies) it would allow for companies to
grow and add more /48s without growing the routing table because the blocks
would be contiguous. If AfriNIC were to allocate a /28 for this purpose it
allows for 2^16 (65536) P.I /44 blocks, which should last a fairly long
time, and if it becomes necessary to grow this, its just a matter of adding
another /28 prefix to the prefix list to expand the P.I space.  We could
even allocate that /28 on a /26 boundary for safety!

This at the end of the day covers most of the aspects,

A.)   It provides P.I space (which there seems to be consensus on from what
I'm reading)

B.)    It provides enough space that the blocks can be expanded for
institutions who have P.I space up to a /44, which, providing institutions
are using a /48 per physical site would give them up to 16 physical sites
(as an example, they could break /48s across multiple physical sites as
well)

C.)    It provides enough space for the allocations of these P.I blocks
without needing extensive filter lists on routers for the P.I prefix blocks
and allows for the differentiation of P.I blocks versus P.A blocks by simply
looking at the block the space was assigned out of. (This becomes even more
obvious an advantage if the P.I allocation block is initially published on a
/28 boundary but with a /26 reserved by AfriNIC incase of need)

D.)   In the case of point B.) due to the fact that sites can grow their
blocks on a contiguous basis, it prevents massive growth in the routing
table

Just my thoughts, curious to hear what the disagreements with this are.

Thanks

Andrew Alston

TENET - Chief Technology Officer

From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf Of
Hytham EL Nakhal
Sent: Tuesday, March 13, 2007 6:55 PM
To: AfriNIC Resource Policy Discussion List
Subject: RE: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy Proposal:
IPv6ProviderIndependent (PI) Assignment for End-Sites

Dear Vincent,

I'd like to discuss something may be get benefits of all suggestions
regarding PI assignment, What about dedicating a /32 for PI assignments, and
each PI is /48 , so we have 2 to the power 16 PI assignments (i.e. 65536 /48
PI blocks). AfriNIC provide services for Africa Continent which contains
about 55 countries. So if we divide PI blocks equally over countries we find
that each country will have more than 1190 PI blocks, "Is it enough for each
country" ? to know the answer we can have a look on the number of IPv4 PI
assignments for each country in database (keeping in mind that /48 IPv6
block has addresses more more than /24 IPv4). 

Then we can make all /48 PI assignments from a dedicated /32 block and in
same time we can arrange for a serial /48 blocks for each country and inside
each country we can keep a guard band for each PI assignment in case of
future growth. 

Thanks,

Haitham..

  _____  

From: rpd-bounces at afrinic.net on behalf of Vincent Ngundi
Sent: Tue 3/13/2007 3:51 PM
To: Resource Policy Discussion List
Cc: AfriNIC Policy Working Group List
Subject: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy Proposal:
IPv6ProviderIndependent (PI) Assignment for End-Sites

Hi All, 

Below is a summary of the above policy as per the discussions we have had so
far.

So far, we have the following arguments:

(a) Andrew Levin  (30.01.2007)

proposed that we should not assign prefixes < /48 due to concerns about the
global routing table

(b) Frank Habitcht  (30.01.2007)

was in agreement that there was need for PI assignments < /48 especially in
the case of IXP's since the prefix would not appear in the global routing
table.

(c) Mark Elkins (01.02.2007)

Suggested that each /48 assignment should be made from a unique /32 (which
should be preserved to accommodate  growth)

>From the above points:

(b) above seems to have outweighed (a) above and as such we should allow for
the assignment prefixes < /48 as per the draft.

as for (c) above, organisations which require >= /32 should become an LIR.

In conclusion, it seems that the draft policy should remain as it is.

Currently statistics:

* Yea (those in support of the policy) : 6

* Nay (those _not in support of the policy) : 1

Finally, I wish to encourage more members of the community to give their
views on this policy, or at least indicate whether they are in favour of it
or not.

Abuja is only 5 weeks away!

-v

On Jan 30, 2007, at 11:22 AM, Andrew Alston wrote:

Hi Vincent,

I'm ok with all of this except for the following:

* The intial provider independent assignment size to an end-site should be a
/48, or a shorter/longer prefix if the end-site can justify it.

I'm happy with /48s, I'm even happier with bigger blocks, but there should
*NEVER* be a situation where the block is smaller than this in the global
routing tables.  If the blocks can ever be smaller than /48 in size it is
going to create major BGP filtering headaches.

Can this wording be clarified?

Many Thanks

Andrew Alston

TENET - Chief Technology Officer

_______________________________________________

resource-policy mailing list

resource-policy at afrinic.net

https://lists.afrinic.net/mailman/listinfo.cgi/resource-policy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20070313/dd06f212/attachment.html>