[policy-wg] Global IPv6 PI policy proposal

[JORDI PALET MARTINEZ]

Hi Andrew,

See my response below in-line.

Regards,
Jordi




> De: Andrew Alston <aa at tenet.ac.za>
> Responder a: AfriNIC Policy Working Group List <policy-wg at afrinic.net>
> Fecha: Mon, 15 May 2006 07:02:59 +0200
> Para: AfriNIC Policy Working Group List <policy-wg at afrinic.net>
> Asunto: RE: [policy-wg] Global IPv6 PI policy proposal
> 
> Hi All,
> 
> I've given this policy a fair bit of thought.  I am a major proponent of PI v6

Let's start with something that may be shocking for some. I'm not in favor
of PI. I'm in favor of keeping the maximum aggregation and having a
contention in the routing tables (there are studies that show that we will
pass over the million of entries in a few years, which is not good at all).

However, I think is not good that a region has PI and not the rest, because
the global cost of routing is shared by all the regions. This will be very
unfair.

I also understand at the same time those companies that are in need for a
solution to PI (multihomed or not), and this is why I want to see this
proposal adopted, or alternatively a way for any company which needs IPv6
space, to become an LIR and receive addressing space. This is not possible
today because they not sub-assign the space to other entities, but only to
their own ones.

> space, however, I do not agree with the /32 allocation.  Yes, while there is a
> LOT of IPv6 space, the use of /32s in the PI arena violates the (widely
> accepted?) recommendations in RFC 3177 and quite frankly is unnecessarily
> large in my opinion.  It is also out of line with what I believe is ARIN's
> recently adopted stance when they approved the assignment of /48 P.I space.

My understanding is that the ARIN decision is still on the hands of the
Advisory Council, so the prefix length is not yet fixed as they can suggest
modifications to the policy proposal.

RFC3177 is not related at all to this case, in my opinion, as it clearly
states that is only addressing the issues of the boundary between the public
and private topology and the PI space is addressing the issue of making
public some private topologies which are on the need for it.

There is so much IPv6 space than if we agree with the HD-Ratio change which
is actually being approved in most of the regions (I guess it will become in
all of them), the expectative are for 480+ years of IPv6 addresses lifetime.
In my opinion, the impact of a PI policy allocating /32, will be minimum on
this and even if we only have IPv6 addresses for 100 years, I really think
is more than enough. Actually I doubt that we will keep using IPv4/IPv6 at
all in that time, even we may be still will call IP to the protocol that we
use by then. But of course, this is just predictions and we can be, all,
wrong.

In my opinion the important cost here is keeping the routing table low and
at the same time not putting the cost in human resources to configure
allow-/48 filters in each router, everytime there is a new PI allocation.
Comparing this with the cost of "investing" a few extra /32 is quite
positive on this balance.

> 
> I have heard many arguments regarding the pro's and con's of P.I space, but
> the primary one I hear time and again revolves around the size of the routing
> table should /48s start appearing in the table due to P.I assignments.  Quite
> frankly, to my knowledge, the routing table has *NEVER* kept up with moore's
> law, in v4 or v6, far far from it.  But beyond the moore's law argument, as
> again, many people would say that is irrelevant, there are other things we can
> consider here.

You need to see the latest presentations from Jason Schiller and Geoff
Houston ...

> 
> At current, if we look at the size of the routing table in the v4 world, yes,
> its large and its growing, but why is this the case?  Current assignment
> policies with regards to v4 dictate that a company gets their space in
> relatively small blocks, and as the companies grow and mature, they require
> more and more v4 space.  This means they apply for multiple blocks, and
> announce multiple blocks, which results in many companies announcing P.I space
> announcing multiple routes.  In the case of IPv6 and /48 blocks, this should
> not happen.  
> 
> The /48 block contains a vast number of addresses, and is easily subnettable
> due to its size to allow for decent aggregation within most companies.  I
> would say that in the case of very large organizations, there should be an
> option to apply for a bigger P.I block if the motivation exists, perhaps a /46
> or a /47, purely on the basis that some organizations may need large blocks
> for internal aggregation due to number of sites or other such reasons.
> 
> Other than that, I would support this policy and recommend it be passed,
> providing we can sort out the issues around the size of allocations.

Take also in consideration that I'm still believing that we will have in a
few years better technical solutions (and not just one) and considering
that, /32 will not be a trouble, specially because is a temporary allocation
and some of the entities needing it, may not need it forever.

Last, but not least, consider that the alternative is to allow those
entities to become an LIR, and in that case they will also get a /32. So
what makes the difference ?.

Also, note that I'm not proposing that those companies aren't charged for
this. Actually I didn't say anything about the charging scheme because I
understand that it falls in hands of the AfriNIC board. My view is that any
entity receiving resources must share the cost in a similar fair way as the
rest of the members. I will accept an exception for non-profit organizations
and services if that's acceptable for the rest of the community.

> 
> Many 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 JORDI PALET MARTINEZ
> Sent: 14 April 2006 17:01
> To: global-v6 at lists.apnic.net
> Subject: [policy-wg] Global IPv6 PI policy proposal
> 
> 
> Please, use global-v6 at lists.apnic.net for inputs to this draft policy
> proposal, in order to avoid threads being split across multiple mail
> exploders in different regions.
> 
> 
> 1.  Number: (The RIPE NCC will assign this)
>  
> 2. Policy Proposal Name:
>  
> Provider-Independent (PI) IPv6 Assignments for End-User-Organizations
>  
> Note: We can use ³Portable IPv6 Assignments for End-User-Organizations² if
> that helps some folks to buy-in the proposal.
>  
> 3. Author:
>       a. name:                        Jordi Palet Martinez
>       b. e-mail:                        jordi.palet at consulintel.es
>       c. organisation:            Consulintel
>  
> 4. Proposal Version:            1.1
>  
> 5. Submission Date:            17/4/2006
>  
> 6. Suggested RIPE Working Group for discussion and publication:
>  
> Address Policy
>  
> 7. Proposal type:
>       a. new, modify, or delete.
>  
>             NEW
>  
> 8. Policy term:
>       a. temporary, permanent, or renewable.
>  
>             TEMPORARY
>  
> 9. Summary of proposal:
>  
> This policy is intended to provide a solution for organizations that have a
> need for provider independent assignments in IPv6.
>  
> Typically those organizations will require the provider independent
> assignment in order to be able to become multihomed in a similar fashion as
> today is done for IPv4, but other reasons are also foreseen. For example
> some organizations aren¹t multihomed, but still require being globally
> routable with stable addressing (avoiding renumbering if they change the
> upstream provider) and in those cases (reasons behind may be administrative,
> policy, security, etc.) it seems that no other solution than provider
> independence is feasible, at least by now.
>  
> Considering the foreseen consequences in the medium/long-term of this policy
> in the routing tables, this policy proposes an expiry date of 3 years once a
> technically correct alternative valid and deployable solution becomes
> accepted by the community.  After that sunset period, the assignments done
> for multihoming purposes should be reclaimed and this policy should be
> modified to still allow assignments that could be required for purposes
> different than multhoming.
>  
> At the sunset, the organizations that want to avoid renumbering and qualify
> to become an LIR, will be able to opt for that solution and they will get
> allocated the same prefix.
>  
> 10. Policy text:
>       a. Current (if modify):
>       b. New:
>  
> Provider-Independent IPv6 assignment to End-User-Organizations
> Qualification for an IPv6 Provider-Independent assignment: To qualify for a
> direct assignment, the organization must not be an IPv6 LIR and must qualify
> for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4
> policy. This is valid regardless of actually having being assigned or
> allocated such an IPv4 block.
>  
> Provider-Independent IPv6 assignment size to End-User-Organizations: The
> minimum size of the assignment is /32. However a larger assignment can be
> provided if duly documented and justified.
>  
> Subsequent assignment size to End-User-Organizations: Whenever possible,
> further assignments will be made from adjacent address blocks, but only if
> duly documented and justified.
>  
> Assignment super-block: Those assignments shall be allocated from a separate
> super-block to allow for LIRs to filter them if required.
>  
> Expiry for those assignments: In the case of assignments done under this
> proposal in order to address the multihoming issue, they will need to return
> the block in a maximum period of 3 years after a technically correct
> alternative valid and deployable solution becomes accepted by the community.
> Alternatively, to avoid renumbering, some of the organizations affected by
> this, could become an LIR, if they qualify for it.
>  
> 11. Rationale:
>       a. Arguments supporting the proposal
>  
> In IPv4 there are organizations that qualify for an allocation for being PI,
> or could opt to be an LIR, either because they need to be multihomed or have
> other administrative or technical reasons to require a portable addressing
> block.
>  
> This is not the case today for IPv6 and it is perceived as a clear barrier
> for deployment of IPv6 in some organizations, and is being addressed by this
> proposal by means of providing a direct assignment from RIPE NCC.
>  
> These organizations are not allowed to make further assignments to other
> external organizations, but instead only to assign subnets internally within
> their own facilities.
>  
> Assigning /32 will make those blocks to behave as other regular
> LIR-allocated ones and follow the generally accepted routing filtering
> practices, but at the same time being identifiable belonging to a special
> super-block. Also, it allows becoming an LIR, if that¹s the case, without
> requiring a renumbering.
>  
> By setting up this policy, we avoid creating an unfairness situation among
> different regions and allow any organization that requires PI to access to
> it. All the organizations that opt for this PI, will be in the same fair
> situation once the technical solution is agreed and will have to either move
> to the new solution or become an LIR if they qualify. Newcomers will be in
> the same situation. Organizations that don¹t opt to PI with this policy is
> because they don¹t need it, so they aren¹t put in an unfair situation.
>  
> Those that don¹t believe in possible alternative solutions and agree in
> going for a permanent PI policy instead, don¹t have valid reasons to oppose
> to this proposal, as the sunset will only enter into effect once that
> solution is agreed, so this proposal is not against their view.
>  
> Some organizations my qualify to become an LIR now and avoid using this
> temporary assignment, but if their only reason to become an LIR is to get
> the PI block, then it seems better, looking in the long-term routing table
> size conservation, to go for this choice, which is more fair for the overall
> community.
>  
> The ³temporarily² of this assignment must be understood as a long-term one,
> as we may expect those alternative solutions to be available possible in 3-4
> years, which means that with the ³transition² period of 3 years, asking for
> a change in 6-7 years must not be considered as a pain.
>  
>       b. Arguments opposing the proposal
>  
> The possible effect of this proposal is the grow of the routing tables to
> figures which, together with the existing (and forecasted) IPv4 routing
> entries, could create an important trouble to operators before vendors
> provide products with implement technical solutions, or even if those
> technical solutions exists, have an important impact in the cost or/and
> depreciation period for the infrastructure investments.
>  
> This is the reason why the proposal provides already a fix sunset, but
> relative to the date where an alternative and technically correct solution
> is available and accepted as deployable by the community.
>  
> Regarding the size of the assignment (/32), being a temporal one, should not
> be considered as a space waste, and instead be seen as an advantage in the
> sense of not requiring new special filters.
>  
>  
>  
> Acknowledgments: I will like to acknowledge the inputs received for the
> first version of this proposal from Marcelo Bagnulo and Lea Roberts.
>  
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> 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.
> 
> 
> 
> 
> _______________________________________________
> policy-wg mailing list
> policy-wg at afrinic.net
> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
> 
> 
> _______________________________________________
> policy-wg mailing list
> policy-wg at afrinic.net
> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.