Hi All,
Useful statistics:
http://www.afrinic.net/statistics/ipv4_resources.htm
In particular:
http://www.afrinic.net/statistics/ipv4_resources.htm#03
http://www.afrinic.net/statistics/ipv4_resources.htm#05
http://www.afrinic.net/statistics/ipv4_resources.htm#08
-v
On Mar 14, 2007, at 12:17 PM, Andrew Alston wrote:
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/resource-policy
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
