Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Fri Mar 16 09:12:01 UTC 2007

Hi Leo,

Well, I see your point, but somehow disagree ...

I think with the deployment of IPv6 we will see different ways of using
subnets. Basically, many more subnets in each end-site, compared to what we
typically see in IPv4.

We don't expect that all the possible interfaces provided by the 64 bits of
each subnet are going to be use in each subnet, and was never the intend
with the design of IPv6, because that allows autoconfiguration, privacy
addresses, CGAs, and many more things for sure to come.

I know about new technologies being developed that in fact use, in a
residential customer, hundreds of subnets. Probably /48 seems to much, but
for example, /56 (256 subnets) is too low for those cases. I'm sure that in
case of corporate customers the number of subnets will be closer to /48 than
in the case of a residential customer, as typically business have a higher
demand for addresses.

Anyway, I think, after many discussion in all the regions, is safe to have a
PI policy that starts with a /48 IF it allows the hostmaster to get a
justification for a shorter prefix in order to not limite any organization
that needs more.

I also expect some balance, in the sense of not giving each organization
exactly what they need, but allowing some grow. For example, if an
organization ask initially for a /48 and then come back for more, I think it
will be better to provide a /44 than a /46, if other regions are doing the
same, in order to simplify the filtering rules, etc. I'm sure and confident
that the RIRs operation already take care of those things and probably there
is no need to explicitly write down so many details in the policy.


> De: Leo Vegoda <leo.vegoda at>
> Responder a: AfriNIC Resource Policy Discussion List <rpd at>
> Fecha: Fri, 16 Mar 2007 09:25:24 +0100
> Para: AfriNIC Resource Policy Discussion List <rpd at>
> Asunto: Re: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy
> Proposal:IPv6ProviderIndependent (PI) Assignment for End-Sites
> Andrew,
> On Mar 15, 2007, at 5:26 PM, Andrew Alston wrote:
> [...]
>> b.) The idea of a /44 boundary levels the playing field, everyone is
>> entitled to the same initial, everyone is entitled to grow, let's
>> not allow
>> some who know how to work the system to end up with more than those
>> that
>> don't, because I see this as a real danger unless there are fixed
>> policies.
>> (look at the situation with v4 at the moment, and while I won't go
>> into what
>> I mean by working the system, a little analysis and some thought
>> should
>> clear up what I mean)
> I think the fairness argument is very important. However, I am not
> sure I understand what take-up you expect for the reserved space and
> that means I can't work out what proportion of the space you'd like
> reserved is ever likely to be used. What proportion is likely to be
> wastage?
> One /48 gives an end-site -- not an ISP which would qualify for a /32
> anyway -- 65536 /64 networks. The majority of those assignments will
> need to be used before the end-site needs to expand its prefix from
> a /48 to a /47. What I really don't have a feel for is how many
> organisations are likely to grow out of a /48 at a single site. I can
> easily understand a single organisation wanting a separate /48 for
> separate sites in separate cities or countries - but how many are
> going to require that level of growth in single locations? Further,
> how many sites are really likely to grow 16-fold at a single location?
> I think it's worth looking at the likely take-up of the reserved
> spacve before hardening the policy.
> Regards,
> -- 
> Leo Vegoda
> IANA Numbers Liaison
> _______________________________________________
> rpd mailing list
> rpd at

The IPv6 Portal:

Bye 6Bone. Hi, IPv6 !

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

More information about the RPD mailing list