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

Wed Mar 14 09:17:04 UTC 2007

Vincent, 

I see your point possibly about the waste of IPv6 space, and while I
*DO* agree that we should not be over enthusiastic about the allocation
of V6 space which could cause us to run out, we need to think of this as
a balance, a balance between the size of allocations and the effect on
the routing table.

Yes, potentially there is a waste of space allocating /48s on /44
boundaries out of a /28 block, however, considering the size of the V6
space and the fact that Deutsche Telecomms managed to get their own /19
worth of IPv6 space, I really do NOT believe this is a problem
considering the effect it has on stopping the growth in the routing
table.

The entire reason that the IPv4 routing table is sitting at over 200
thousand routes today and growing so fast is in my opinion about the
size of allocations and the boundaries on which they are done.  

At the moment (in IPv4)

Company A starts, they want to multihome, and they go and get some P.I
space, a /24

Tomorrow they grow, they go and get another /24, maybe a /23 this time

A few months from now, they grow some more, they ask for ANOTHER
allocation, now they are advertising 3 prefix's because there was no
boundary to expand to stop this happening.

The future I envisage:

Company A starts, and gets a /48 prefix

Tomorrow they grow, open a new office, they contact afrinic and go "We
need more space", AfriNIC replies "Sure, take your /48 and make it a
/47"

Company A goes into their router, replaces the mask on the BGP
announcement, routing table doesn't grow, problem solved.

The reason for doing it out of a /28 or a /26 is purely so that there
can be filtering of the smaller segments, in line with what ARIN is
doing.

To do /48s out of a /32 block is to repeat a chronic mistake made in the
past that will lead to the very growth in the routing table that people
are so scared of with regards P.I IPv6 Space.  What I'm proposing I
believe is the middle ground between space preservation and routing
table growth.  It's also almost identical to what ARIN has done and
keeps up in line with the other regions.  

I think we'd be foolish to assume as well that 65536 /48s will ever be
enough, it might be today, it might be next year, and the year after,
but there are more than 800 million people on the African continent,
that makes for a LOT of companies, and today, in Africa internet access
is expensive, technology is expensive, technical know-how is limited,
however, we cannot use that as a reason to not plan for tomorrow.  I
strongly believe that Africa needs to move forward with a vision of what
we can be tomorrow, where Internet penetration rates are the same as
they are in Europe and the States, where the technology is the same and
the pricing is the same.  In that future, multi-homing and P.I is a
necessity, and 65k /48s will not cut it.  Lets avoid yet ANOTHER mistake
I so often see, and not underestimate the capacity for growth on the
African continent!

Thanks

Andrew 

From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf
Of Vincent Ngundi
Sent: Wednesday, March 14, 2007 10:24 AM
To: AfriNIC Resource Policy Discussion List
Subject: Re: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy
Proposal:IPv6ProviderIndependent (PI) Assignment for End-Sites

Hi Andrew,

Thanks for your comments/input.

On Mar 13, 2007, at 8:31 PM, Andrew Alston wrote:

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)

I agree with you.

	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!

If we take this approach, we may end up with a lot of wasted
(unallocatable) space. For instance, how many organisations may expand
such that they require an additional /48 (I'm being realistic here, not
pessimistic)

IMHO, I think a /48 = ( 2^16 (65536) /64's) from a reserved /32 will do
unless we intend to silently get rid of the IPv6 Allocation Policy.

-v

	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

	_______________________________________________

	rpd mailing list

	rpd at afrinic.net

	https://lists.afrinic.net/mailman/listinfo.cgi/rpd

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