Re: [GLOBAL-V6] Any consensus?
- To: Takashi Arano <arano at gblx dot ad dot jp>, global-v6 at lists dot apnic dot net
- Subject: Re: [GLOBAL-V6] Any consensus?
- From: Christian Schild <ipng at uni-muenster dot de>
- Date: Fri, 15 Feb 2002 13:52:39 +0100
- In-reply-to: <4.3.2-J.20020215013614.04162ce8 at mail.gblx dot ad dot jp>
- Organization: Westfaelische Wilhelms-Universitaet
- References: <4.3.2-J.firstname.lastname@example.org>
- Reply-to: email@example.com
- Sender: firstname.lastname@example.org
Am Donnerstag, 14. Februar 2002 17:43 schrieb Takashi Arano: > All, > > APNIC address policy SIG will be held just in a few weeks > as Anne introduced. > > As the chair of SIG, I would really like to bring any consensus, > in this mailing list, or anything more concrete if there is no consensus, > to the meeting.... Otherwise, we would not make progress.... > Thank you for your constructive comments and your cooperation. I think we have to decide between two different approaches now. Both have their pros and cons. The first one is to follow the way it is done in the 'IPv6 Address Allocation and Assignment Global Policy' draft. The advantage here is, that we actually _have_ a very good draft, which is useful for all RIRs. A main concern is, that the criteria to get IPv6 address space as decribed in 5.2.1 is too strict. Only if one shows a 'need' for 776 /48 address blocks, one will get IPv6 address space, and that will hinder a lot of organziations to start IPv6 deployment. What we would have to do here, is to fine tune this criteria to meet everyones desires. I believe this will be very difficult, because we will end up with too many exceptions from this rule. We have to define a good 'number' for research networks, small or large ISPs, DSL providers, global providers, large scale companies and maybe many more. The second way is to cut out that criteria entirely and give every LIR a /32-prefix if they ask for it. This was concensus on the RIPE meeting and discussed here a lot. The advantage would be, that everyone who wants IPv6 adress space could get it easy and it would fasten the deployment of IPv6. The disadvantage is, that now it is far _too_ easy to obtain address space. Also LIR is not applicable to every region. While it is more difficult to become a LIR in the RIPE region due to heavy paperwork, in other regions one simply has to pay a fee to become a RIR-member. The idea on the RIPE meeting was, that the heavy paperwork is hindering people to 'just buy' a /32-prefix. This may not work in other regions. Here we also would have to find a more specific restriction to cut out all the very small entities and 'end sites', who should not be able to get a /32. Takashi Arano already started doing so, proposing to replace LIR with 'organizations who assign /48 to organizations other than itself'. Sorry for this becoming kind of a longer summary, but it helped me to make up my mind (and maybe yours too). So, im my opinion every enterprise who wants to offer any kind of IPv6 services should be able to get IPv6 address space quick and easy, no matter how big or small it is and especially no matter how much customer it has. If we follow the first approach, the '776'-rule simply will fail. When we want to give IPv6 address space to everyone who has a need for it, we have to define an exception from this rule for every kind of organization and for every kind of service. I believe this is not possible. Considering the second approach, in fact it will be quick and easy for everyone to get IPv6 address space. I think that wiping out the disadvantage of approach two (by finding a better definition for 'LIR') is much easier than making rule exceptions for approach one. Regards, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join at uni-muenster dot de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild at uni-muenster dot de,phone: +49 251 83 31638, fax: +49 251 83 31653 - - This list (global-v6) is handled by majordomo at lists dot apnic dot net