From iljitsch at muada.com Mon Jan 1 11:27:43 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 1 Jan 2007 17:27:43 +0100 Subject: [ppml] 2006 IPv4 Address Use Report Message-ID: <508375B1-4B80-482B-998E-585E9444CF44@muada.com> 2006 was another busy year for the five Regional Internet Registries: together, they gave out 161.48 million IPv4 addresses, just shy of the 165.45 million given out in 2005 as measured on january first 2006. The current (jan 1st, 2007) figure for 2005 is 175.52 million addresses. Together with adjustments for earlier years, this brings the total addresses available to almost exactly 1.3 billion, down from 1468.61 million a year ago. This is out of 3706.65 million usable IPv4 addresses, so 2407.11 million addresses are currently given out to either end-users or Internet Service Providers. Breakdown by Regional Internet Registry over the past few years as seen on 2007-01-01: 2000 2001 2002 2003 2004 2005 2006 AfriNIC 0.56 0.39 0.26 0.22 0.51 1.03 2.72 APNIC 20.94 28.83 27.03 33.05 42.89 53.86 51.78 ARIN 30.83 28.55 21.08 22.32 34.26 47.57 38.94 LACNIC 0.88 1.61 0.65 2.62 3.77 10.97 11.50 RIPE NCC 24.79 25.36 19.84 29.61 47.49 62.09 56.53 Total 78.00 84.73 68.87 87.82 128.92 175.52 161.48 Compare this to the totals as seen on 2006-01-01: Total 78.35 88.95 68.93 87.77 128.45 165.45 (See last year's report for more details at http://www.bgpexpert.com/ addrspace2005.php ) The main reason for the discrepancy is that the RIRs publish on their respective FTP servers lists of which address block was given out when. When a block of address space is given back by the holder, it's removed from the list. This is the reason why the numbers for earlier years keep going down. The 10 million extra addresses in 2005 and 4 million in 2001 are the responsibility of ARIN, which went from 36.30 million addresses for 2005 in their 2006-01-01 records to 47.56 in their 2007-01-01 records. The reason for the retroactive growth is unknown. AfriNIC gives out address space in Africa, APNIC in the Asia-Pacific region, ARIN in North America, LACNIC in Latin American and the Caribbean and the RIPE NCC in Europe, the former Soviet Union and the Middle East. The Internet Assigned Numbers Authority (IANA, part of ICANN) keeps an overview of the IPv4 address space at http://www.iana.org/ assignments/ipv4-address-space. The list consists of 256 blocks of 16.78 million addresses. Breakdown: Delegated to Blocks +/- 2006 Addresses (millions) AfriNIC 1 16.78 APNIC 19 +3 318.77 ARIN 27 +4 452.98 LACNIC 4 67.11 RIPE NCC 22 +3 369.10 Various 50 838.86 End-user 43 721.42 Available 55 -10 922.74 Of the 2063.60 million addresses delegated to the five Regional Internet Registries, 1685.69 million have been delegated to end-users or ISPs by the RIRs, and 377.91 million are still available, which is almost identical to last year's 378.09 number. Along with the 922.74 million addresses still available in the IANA global pool this makes the total number of available addresses 1300.65 million, down 167.96 million from a year earlier. The size of address blocks given has been increasing steadily. The table below shows the number of requests for a certain range of block sizes (equal or higher than the first, lower than the second value). (2005 and earlier values from 2006-01-01 data, 2006 values from 2007-01-01 data.) 2000 2001 2002 2003 2004 2005 2006 < 1000 326 474 547 745 1022 1309 1526 1000 - 8000 652 1176 897 1009 1516 1891 2338 8000 - 64k 1440 868 822 1014 1100 1039 1133 64k - 500k 354 262 163 215 404 309 409 500k - 2M 19 39 29 46 61 60 56 > 2M 3 5 5 6 7 18 13 The number of blocks in the two smallest categories have increased rapidly, but not as fast as the number of blocks in the largest category, in relative numbers at least. However, the increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 2000 2001 2002 2003 2004 2005 2006 < 1000 0.10 0.16 0.18 0.25 0.35 0.44 0.52 1000 - 8000 2.42 4.47 3.23 3.45 4.49 5.07 6.10 8000 - 64k 18.79 12.81 11.35 14.00 15.99 15.46 17.17 64k - 500k 35.98 32.19 20.28 25.51 42.01 34.23 49.64 500k - 2M 12.68 24.64 21.30 31.98 44.63 41.63 46.64 > 2M 8.39 14.68 12.58 12.58 20.97 68.62 41.42 The increase in the 2M+ blocks was solely responsible for the high number of addresses given out in 2005. In 2006, there was growth in all categories except the 2M+ one (even the 500k - 2M category increased in number of addresses if not in number of blocks). When the 2M+ blocks are taken out of the equation, 2005 had a total of 96.83 million addresses (2006-01-01) and 2006 119.06 million given out. Another way to look at the same data: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5475 161.48 29494 The 2407.11 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: Country Addresses 2007-01-01 Addr 2006-01-01 US 1366.53 M 1324.93 M United States JP 151.27 M 143.00 M Japan EU 115.83 M 113.87 M Multi-country in Europe CN 98.02 M 74.39 M China GB 93.91 M 73.81 M United Kingdom CA 71.32 M 67.43 M Canada DE 61.59 M 51.13 M Germany FR 58.23 M 45.16 M France KR 51.13 M 41.91 M Korea AU 30.64 M 26.87 M Australia BR 19.27 M 17.17 M Brazil IT 19.14 M 18.39 M Italy ES 18.69 M 16.29 M Spain TW 18.16 M 16.28 M Taiwan NL 18.08 M 16.40 M Netherlands The US holds 57% (down from 60% a year ago) of the IPv4 address space in use. The other countries in the list together hold another 34% (up from 32%). The rest of the world has 9% (up from 8%). A copy of this information and a tool to perform queries on up to date data is available at http://www.bgpexpert.com/addrspace2006.php From martin.hannigan at batelnet.bs Mon Jan 1 14:56:34 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 01 Jan 2007 14:56:34 -0500 Subject: [ppml] 2006 IPv4 Address Use Report Message-ID: <45996772.c0.4f52.10276@batelnet.bs> > AfriNIC gives out address space in Africa, APNIC in the > Asia-Pacific region, ARIN in North America, ...and the Caribbean. > > The US holds 57% (down from 60% a year ago) of the IPv4 Semantics, but is that the IANA to ARIN allocation or the in use percentage? -M< From iljitsch at muada.com Mon Jan 1 15:23:41 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 1 Jan 2007 21:23:41 +0100 Subject: [ppml] 2006 IPv4 Address Use Report In-Reply-To: <45996772.c0.4f52.10276@batelnet.bs> References: <45996772.c0.4f52.10276@batelnet.bs> Message-ID: On 1-jan-2007, at 20:56, Martin Hannigan wrote: >> AfriNIC gives out address space in Africa, APNIC in the >> Asia-Pacific region, ARIN in North America, > ...and the Caribbean. Isn't that the first "C" in LACNIC? >> The US holds 57% (down from 60% a year ago) of the IPv4 > Semantics, but is that the IANA to ARIN allocation or the in > use percentage? Allocations where country = "US". Apart from the expected ARIN allocations, this includes direct allocations by IANA, which are now registered in the ARIN database, and also: +-------+---------+---------------+-------+ | rir | country | descr | num | +-------+---------+---------------+-------+ | apnic | US | 60.254.128.0 | 16384 | | apnic | US | 163.60.0.0 | 65536 | | apnic | US | 192.103.43.0 | 256 | | apnic | US | 202.72.96.0 | 4096 | | apnic | US | 202.76.240.0 | 2048 | | apnic | US | 203.77.184.0 | 2048 | | apnic | US | 203.144.48.0 | 4096 | | apnic | US | 203.187.128.0 | 8192 | +-------+---------+---------------+-------+ From martin.hannigan at batelnet.bs Mon Jan 1 15:36:25 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Mon, 01 Jan 2007 15:36:25 -0500 Subject: [ppml] 2006 IPv4 Address Use Report Message-ID: <459970c9.2a4.4fee.1236@batelnet.bs> ----- Original Message ----- From: Iljitsch van Beijnum To: Martin Hannigan Cc: ppml at arin.net Subject: Re: [ppml] 2006 IPv4 Address Use Report Date: Mon, 1 Jan 2007 21:23:41 +0100 > On 1-jan-2007, at 20:56, Martin Hannigan wrote: > > >> AfriNIC gives out address space in Africa, APNIC in the > >> Asia-Pacific region, ARIN in North America, > > > ...and the Caribbean. > > Isn't that the first "C" in LACNIC? I believe that this is the consensus of RIR regional definition by the NRO. ARIN http://www.arin.net/community/ARINcountries.html LACNIC http://www.arin.net/community/LACNICcountries.html Martin Hannigan ASO AC From ppml at rs.seastrom.com Mon Jan 1 15:54:02 2007 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 01 Jan 2007 15:54:02 -0500 Subject: [ppml] 2006 IPv4 Address Use Report In-Reply-To: (Iljitsch van Beijnum's message of "Mon, 1 Jan 2007 21:23:41 +0100") References: <45996772.c0.4f52.10276@batelnet.bs> Message-ID: <86bqlimpsl.fsf@seastrom.com> Iljitsch van Beijnum writes: > On 1-jan-2007, at 20:56, Martin Hannigan wrote: > >>> AfriNIC gives out address space in Africa, APNIC in the >>> Asia-Pacific region, ARIN in North America, > >> ...and the Caribbean. > > Isn't that the first "C" in LACNIC? Roughly speaking, Spanish-speaking Caribbean is LACNIC, whilst French and English speaking Caribbean is ARIN. http://www.arin.net/community/ARINcountries.html ---Rob From gih at apnic.net Mon Jan 1 16:23:18 2007 From: gih at apnic.net (Geoff Huston) Date: Tue, 02 Jan 2007 08:23:18 +1100 Subject: [ppml] 2006 IPv4 Address Use Report In-Reply-To: <45996772.c0.4f52.10276@batelnet.bs> References: <45996772.c0.4f52.10276@batelnet.bs> Message-ID: <7.0.0.16.2.20070102081956.04128528@apnic.net> At 06:56 AM 2/01/2007, Martin Hannigan wrote: > > AfriNIC gives out address space in Africa, APNIC in the > > Asia-Pacific region, ARIN in North America, > >...and the Caribbean. > > > > > > The US holds 57% (down from 60% a year ago) of the IPv4 > >Semantics, but is that the IANA to ARIN allocation or the in >use percentage? Hi You might find the following useful in terms of a breakdown by country code for IPv4 distribution: http://resources.potaroo.net/iso3166/v4cc.html (This uses the country code as provided in the RIR's statistics files reports which does not always correlate to the actual country of end use of these addresses.) Regards, Geoff From iljitsch at muada.com Mon Jan 1 16:34:34 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 1 Jan 2007 22:34:34 +0100 Subject: [ppml] 2006 IPv4 Address Use Report In-Reply-To: <459970c9.2a4.4fee.1236@batelnet.bs> References: <459970c9.2a4.4fee.1236@batelnet.bs> Message-ID: While you are of course correct that there are some corner cases in the RIR regionality, I don't think pointing that out is useful in a place where the RIRs are introduced for the benefit of people who don't really know what they are. From woody at pch.net Sat Jan 20 05:49:09 2007 From: woody at pch.net (Bill Woodcock) Date: Sat, 20 Jan 2007 02:49:09 -0800 (PST) Subject: [ppml] Version 2 of the PGP-auth reinstatement policy just submitted to policy@arin.net In-Reply-To: <45996772.c0.4f52.10276@batelnet.bs> References: <45996772.c0.4f52.10276@batelnet.bs> Message-ID: Just an FYI, at Leo's suggestion... In response to suggestions and feedback from the intial submission, we've made some relatively minor revisions, and just submitted what we believe to be the final versions of the proposals, which I presume will be posted here next week, after they've been processed by staff. There was some historical context which got fine-tuned as people remembered more of the pre-ARIN history, and some disambiguation about what was policy, and what was implementation suggestions. Nothing which substantially changed the character of the documents. -Bill From info at arin.net Tue Jan 23 11:11:52 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:11:52 -0500 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method - revised text Message-ID: <45B633C8.3030608@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Reinstatement of PGP Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Reinstatement of PGP Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods ARIN supports three authentication methods for communication with resource recipients. 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall include a field in templates as necessary to identify and distinguish between cryptographic and mail-from authentication methods, generally following the practices of the other RIRs. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate, to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate the signature, compare it to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail which they originate with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications, except by explicit mutual prior agreement with the recipient. NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: It is recommended that ARIN utilize normal POC-verification processes as necessary to accommodate users who lose the private key or passphrase associated with the POCs for their crypt-auth protected resources. It is recommended that ARIN exercise reasonable caution in preventing the proliferation of copies of the hostmaster private key and passphrase. It is recommended that ARIN print out a copy of the private key and passphrase, and secure them in a safe-deposit box outside of ARIN's physical premises, which any two ARIN officers might access in the event that the operating copy of the key is lost or compromised. It is recommended that ARIN publish the hostmaster public key on the ARIN web site, in a manner similar to that of the other RIRs: http://lacnic.net/hostmaster-pub-key.txt https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY It is recommended that ARIN publish the hostmaster public key by submitting it to common PGP keyservers which, among others, might include: pgp.mit.edu www.pgp.net It is recommended that ARIN attempt to cross-sign the hostmaster PGP keys of the other four RIRs and ICANN. It is recommended that ARIN's hostmaster public key be signed by members of the ARIN board of trustees. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and it was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Tue Jan 23 11:12:16 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:12:16 -0500 Subject: [ppml] Policy Proposal: Documentation of the Mail-From Authentication Method - revised text Message-ID: <45B633E0.3050707@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Documentation of the Mail-From Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the Mail-From Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Tue Jan 23 11:12:31 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:12:31 -0500 Subject: [ppml] Policy Proposal: Documentation of the X.509 Authentication Method - revised text Message-ID: <45B633EF.70703@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Documentation of the X.509 Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the X.509 Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 8. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From marla.azinger at frontiercorp.com Tue Jan 23 11:52:17 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 23 Jan 2007 11:52:17 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes- InputRequested Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04347@nyrofcs2ke2k01.corp.pvt> Hello- The deadline for proposal submissions is getting close (Feb 22nd). In order to help Jordi decide just how he will modify his previously proposed policy 2006-7 IPV6 Initial Allocation, I am asking for one more round of feedback. Below is the same email that went out back in November. Within it are the modifications currently being considered. A few people responded back in November, and Thank you to those who did. Now we are looking for more input from anyone who hasnt yet voiced their opinion. Thank you for your time Marla Azinger -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Azinger, Marla Sent: Monday, November 13, 2006 11:00 AM To: ppml at arin.net Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- InputRequested Hello- In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email. We would like the communities input on three separate suggested revisions. What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other? I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins. When reviewing the three suggested changes please note the following assumptions: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - Organization in this is defined as a Corporation, ISP, LLC et al. Suggested Change #1 (deletes and replaces current text of item d and requires ASN) Replace line item d. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPV6 address space, an organization must': d. be an existing, known ISP in the ARIN region OR be an organization which can justify intent to announce the requested IPv6 address space within one year and have/obtain and AS Number. Rationale for ASN: Someone providing this kind of service needs to run BGP. Suggested Change #2 (deletes and replaces current text of item d but does not require ASN) Replace line item d. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPv6 address space, an organization must': d. be an existing, known ISP in the ARIN region OR be an organization which can justify intent to announce the requested IPv6 address space within one year. Rationale for no asn: We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN) Insert line item e. to 6.5.1.1 with the following: 'To qualify for an initial allocation of IPV6 address space, an organization must': e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale for no asn: We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. Thank you for your time Marla (ARIN AC) and Jordi (Proposal Author) _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From info at arin.net Tue Jan 23 15:36:31 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 15:36:31 -0500 Subject: [ppml] Deadline for Policy Proposals - 22 February 2007 Message-ID: <45B671CF.4050307@arin.net> The ARIN XIX Public Policy Meeting will take place 23-24 April 2007 in San Juan, Puerto Rico. New policy proposals must be submitted by 23:59 EST, 22 February 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XIX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From michael.dillon at bt.com Wed Jan 24 06:25:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 24 Jan 2007 11:25:16 -0000 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C185356E@i2km07-ukbr.domain1.systemhost.net> > - New organizations who do not want to use IPv4 at all and > start off using IPv6 addresses only, need a policy that gives > them permission to do so. Yes! > 'To qualify for an initial allocation of IPV6 address space, > an organization must': > d. be an existing, known ISP in the ARIN region OR be an > organization which can justify intent to announce the > requested IPv6 address space within one year and have/obtain > and AS Number. I am concerned that this type of wording, which is typical of the existing policy as well, places too much emphasis on the use of IPv6 addresses on the Internet. IPv6 addresses are not intended for use on the Internet! They are intended for use on Internet Protocol (IP) networks. This subtle yet important distinction is embedded in RFC 2050, section 3(a) and is consistent with RFC 1918, section 2, category 3. Given the huge address space associated with IPv6 addresses, it is likely that many non-Internet applications will want to use Internet Protocol version 6. Since these applications will not be directly connected to the public Internet and will not make BGP announcements to the public Internet for normal operational purposes, it seems to me that the example language above is overly restrictive. There are two ways that could fix this. One is to recognize a separate category of application for IP version 6 networks that are not interconnected with the Internet. Then the language in section d. above would be matched by another section which explicitly does not require such BGP announcements. The other way to fix it is to avoid such restrictive language entirely. If so-called ISP allocations are for networks which intend to experience steady growth, year-on-year, then we can say that explicitly rather than restricting it only to organizations whose business model is that of an ISP. In fact, the business model which defines an ISP is considerably less clear in this day and age than it was 10 years ago. Some though experiments that might be useful: 1. According to http://www.census.gov/hhes/www/housing/ahs/ahsfaq.html there are about 120 million housing units in the USA, presumably every one with its own power meter. If you wanted to use IP over powerlines to manage these, then IPv4 doesn't have enough address space but IPv6 can easily handle it. 2. Supply-chain networks (extranets) are becoming more and more common. This means that enterprises interconnect their networks using IP seperate from their connections to the public Internet. As a result a single enterprise may need multiple assignments of globally unique IP addresses to accomodate connection to multiple internets. 3. Cellphones. The traditional telephone model is nearing the end of its life as cellphones become multi-purpose personal devices. In my part of the world it seems like a Nokia mobile phone is the most popular MP3 player. Apple has recently announced a cellphone with a non-traditional interface. Sometime soon there will be demand for a personal network address that doesn't change throughout a person's lifetime. IPv6 seems ready-made to handle this role since there is a surplus of IPv6 addresses. 4. Define your own non-ISP non public Internet scenario. --Michael Dillon From jordi.palet at consulintel.es Wed Jan 24 07:19:55 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 24 Jan 2007 13:19:55 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <2DA00C5A2146FB41ABDB3E9FCEBC74C185356E@i2km07-ukbr.domain1.systemhost.net> Message-ID: Hi Michael, I would agree with your point about the wording if there is not an alternative space for those type of address space needs. I think we should use ULA or ULA-central in those cases, and that will mean no need to modify this text (or similar one in other policies, in all the RIRs regions). I think the community should make an effort for getting the RIRs involved in agreeing to advance ULA-central in a convenient way for this usage. I tried already, but got no answer up to now :-( Regards, Jordi > De: > Responder a: > Fecha: Wed, 24 Jan 2007 11:25:16 -0000 > Para: > Conversaci?n: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > >> - New organizations who do not want to use IPv4 at all and >> start off using IPv6 addresses only, need a policy that gives >> them permission to do so. > > Yes! > >> 'To qualify for an initial allocation of IPV6 address space, >> an organization must': >> d. be an existing, known ISP in the ARIN region OR be an >> organization which can justify intent to announce the >> requested IPv6 address space within one year and have/obtain >> and AS Number. > > I am concerned that this type of wording, which is typical of > the existing policy as well, places too much emphasis on the use > of IPv6 addresses on the Internet. IPv6 addresses are not intended > for use on the Internet! They are intended for use on Internet > Protocol (IP) networks. This subtle yet important distinction is > embedded in RFC 2050, section 3(a) and is consistent with RFC > 1918, section 2, category 3. > > Given the huge address space associated with IPv6 addresses, it > is likely that many non-Internet applications will want to use > Internet Protocol version 6. Since these applications will not > be directly connected to the public Internet and will not make > BGP announcements to the public Internet for normal operational > purposes, it seems to me that the example language above is > overly restrictive. > > There are two ways that could fix this. One is to recognize a > separate category of application for IP version 6 networks that > are not interconnected with the Internet. Then the language in > section d. above would be matched by another section which > explicitly does not require such BGP announcements. The other > way to fix it is to avoid such restrictive language entirely. > If so-called ISP allocations are for networks which intend to > experience steady growth, year-on-year, then we can say that > explicitly rather than restricting it only to organizations whose > business model is that of an ISP. In fact, the business model which > defines an ISP is considerably less clear in this day and age > than it was 10 years ago. > > Some though experiments that might be useful: > > 1. According to http://www.census.gov/hhes/www/housing/ahs/ahsfaq.html > there are about 120 million housing units in the USA, presumably > every one with its own power meter. If you wanted to use IP over > powerlines to manage these, then IPv4 doesn't have enough address > space but IPv6 can easily handle it. > > 2. Supply-chain networks (extranets) are becoming more and more common. > This means that enterprises interconnect their networks using IP > seperate from their connections to the public Internet. As a result > a single enterprise may need multiple assignments of globally unique > IP addresses to accomodate connection to multiple internets. > > 3. Cellphones. The traditional telephone model is nearing the end of > its life as cellphones become multi-purpose personal devices. In my > part of the world it seems like a Nokia mobile phone is the most popular > MP3 player. Apple has recently announced a cellphone with a > non-traditional > interface. Sometime soon there will be demand for a personal network > address > that doesn't change throughout a person's lifetime. IPv6 seems > ready-made > to handle this role since there is a surplus of IPv6 addresses. > > 4. Define your own non-ISP non public Internet scenario. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From info at arin.net Wed Jan 24 10:04:58 2007 From: info at arin.net (Member Services) Date: Wed, 24 Jan 2007 10:04:58 -0500 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration Message-ID: <45B7759A.2050902@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 policy - removal of "interim" consideration Author: Jordi Palet Martinez Proposal Version: 1 Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1. of NRMP: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Jan 24 10:05:09 2007 From: info at arin.net (Member Services) Date: Wed, 24 Jan 2007 10:05:09 -0500 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification Message-ID: <45B775A5.6020603@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" justification Author: Jordi Palet Martinez Proposal Version: 1 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2. of NRMP. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From ipgoddess at gmail.com Wed Jan 24 18:05:29 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Wed, 24 Jan 2007 15:05:29 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes- InputRequested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01D04347@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A01D04347@nyrofcs2ke2k01.corp.pvt> Message-ID: <1c16a4870701241505o6801e9b7qc87bb7d544b331db@mail.gmail.com> Hi Everyone, I don't think it should have the ASN requirement. ARIN does not concern itself with routing, and requiring an AS would strongarm organizations into announcing to the Global Internet, and/or cause the issuance of superfluous ASNs. Cheers, Stacy On 1/23/07, Azinger, Marla wrote: > Hello- The deadline for proposal submissions is getting close (Feb 22nd). > > In order to help Jordi decide just how he will modify his previously proposed policy 2006-7 IPV6 Initial Allocation, I am asking for one more round of feedback. Below is the same email that went out back in November. Within it are the modifications currently being considered. A few people responded back in November, and Thank you to those who did. Now we are looking for more input from anyone who hasnt yet voiced their opinion. > > Thank you for your time > Marla Azinger > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Azinger, Marla > Sent: Monday, November 13, 2006 11:00 AM > To: ppml at arin.net > Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- > InputRequested > > > Hello- In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email. We would like the communities input on three separate suggested revisions. What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other? I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins. When reviewing the three suggested changes please note the following assumptions: > > - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. > - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. > -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. > - Organization in this is defined as a Corporation, ISP, LLC et al. > > > Suggested Change #1 (deletes and replaces current text of item d and requires ASN) > Replace line item d. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPV6 address space, an organization must': > d. be an existing, known ISP in the ARIN region OR be an organization which > can justify intent to announce the requested IPv6 address space within one > year and have/obtain and AS Number. > > Rationale for ASN: > Someone providing this kind of service needs to run BGP. > > > Suggested Change #2 (deletes and replaces current text of item d but does not require ASN) > Replace line item d. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPv6 address space, an organization > must': > d. be an existing, known ISP in the ARIN region OR be an organization which > can justify intent to announce the requested IPv6 address space within one > year. > > Rationale for no asn: > We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > > > Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN) > Insert line item e. to 6.5.1.1 with the following: > 'To qualify for an initial allocation of IPV6 address space, an organization must': > e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. > > Rationale for no asn: > We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > > Thank you for your time > Marla (ARIN AC) and Jordi (Proposal Author) > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From ipgoddess at gmail.com Wed Jan 24 18:09:35 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Wed, 24 Jan 2007 15:09:35 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration In-Reply-To: <45B7759A.2050902@arin.net> References: <45B7759A.2050902@arin.net> Message-ID: <1c16a4870701241509v2d6e2b71ia912a9ec90a02a31@mail.gmail.com> Hi Everyone, I support this policy as it contributes to the concision of the NRPM. :) Stacy On 1/24/07, Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The AC will review this proposal and may decide to: > > 1. Accept the proposal as a formal policy proposal as it is presented; > > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > > 3. Not accept the proposal as a formal policy proposal. > > The AC will review this proposal at their next meeting. If the AC > accepts the proposal, then it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. If the AC > does not accept the proposal, then the AC will explain that decision; > and at that time the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Changes to IPv6 policy - removal of "interim" > consideration > > Author: Jordi Palet Martinez > > Proposal Version: 1 > > Proposal type: delete > > Policy term: permanent > > Policy statement: > > Delete following text at section 6.1.1. of NRMP: > > "This policy is considered to be an interim policy. It will be reviewed > in the future, subject to greater experience in the administration of IPv6." > > > Rationale: > > The actual text suggest that it is an interim policy, however it is not > longer the case. It is clear that any policy is always subjected to > changes, however other policies don't have such text. > > It may be even considered as a negative "message" for IPv6 deployment, > especially because the possible "reading" as "not enough experience and > this is going to be changed, better wait", which is not a real situation. > > No financial/liability implications for the community and ARIN are foreseen. > > No special conditions, fees, exceptions, etc. seem to be required. > > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From randy at psg.com Wed Jan 24 18:15:54 2007 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jan 2007 15:15:54 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration In-Reply-To: <1c16a4870701241509v2d6e2b71ia912a9ec90a02a31@mail.gmail.com> References: <45B7759A.2050902@arin.net> <1c16a4870701241509v2d6e2b71ia912a9ec90a02a31@mail.gmail.com> Message-ID: <45B7E8AA.9070802@psg.com> > I support this policy as it contributes to the concision of the NRPM. >> Delete following text at section 6.1.1. of NRMP: >> "This policy is considered to be an interim policy. It will be reviewed >> in the future, subject to greater experience in the administration of IPv6." it is an interim policy, so maybe you do not wish to exchange concision for correctness. this is just one more "if we are profligate with ipv6 address space, maybe someone will use it despite the serious other impediments." to date this theory has yet to be demonstrated. randy From andrew.dul at quark.net Thu Jan 25 17:38:51 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 25 Jan 2007 14:38:51 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <45B775A5.6020603@arin.net> Message-ID: <20070125222021.DA15714445C@smtp2.arin.net> > >Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" >justification > >Author: Jordi Palet Martinez >Proposal Version: 1 >Proposal type: delete >Policy term: permanent >Policy statement: > >Delete section 6.5.4.2. of NRMP. > When you delete section 6.5.4.2 of the NRPM you are left with only the following phrase as a guideline in determining the assignment of multiple /48s. "...except in cases of extra large end sites where a larger assignment can be justified.", section 6.5.2.1. If the goal of this policy change is to remove the requirement for the RIR to check a multiple /48 assignment to an endsite, then this policy should define the criteria for an LIR to determine if a larger than /48 assignment is needed. Without a criteria in policy an LIR could choose to assign any size block to an endsite. Under the wording of section 6.5.2.1 only the word "justified" can be labeled as a criteria for determining the assignment size. How is "justified" defined for an endsite in this context? While most LIRs are usually reasonable, to me it seems important to include defined and somewhat rigorous criteria for the assignment of multiple /48s and a requirement for the LIR to record this justification for later auditing by the RIR when an LIR returns to the RIR for an additional allocation. >Rationale: > >The current text requires the LIR to justify to the RIR/NIR when >assigning multiple /48s to a single end site. It seems that the reason >for this requirement is the lack of experience, which seems unreasonable >after a few years this policy has been implemented, even if may not have >been specific cases which used this policy section. > I think the section was reasonably written as a throttle to excessive IPv6 assignments to endsites by LIRs. >It seems useless, now that there is already deployment experience, to >require a justification from the LIR to ARIN for assigning multiple /48s >(or a shorter prefix, such as for example a /47). It is up to the LIR to >require the justification to its own customers and decide according to >it. The LIR will be already responsible to justify to ARIN the usage of >any allocated >block(s) when requesting for more, and this will already implicate an >implicit justification of this kind of assignments. That is not the way I read section 6.5.4.1 "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document." I read section 6.5.4.1 to allow an LIR to keep no records about the justification for assignments to endsites. > >With this policy change, both ARIN and LIR staff will save resources in >a justification, which seems unnecessary and should be completely on the >hands of the LIR itself. > How many times have ARIN staff had to evaluate the assignment of multiple /48s to endsites so far? Is this really an issue? From andrew.dul at quark.net Thu Jan 25 17:56:53 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 25 Jan 2007 14:56:53 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01D04347@nyrofcs2ke2k01.co rp.pvt> Message-ID: <20070125223826.0261E14445C@smtp2.arin.net> First I don't necessarily see the need to change the existing policy. I'd don't see the 200 /48s plan as a real hinderance to a legitimate LIR. I generally only support change #1 Change #2 would allow almost any organization to qualify as a LIR, Change #3 while having a good intent seems oddly worded. I'm not sure if the intent is for requirements a-c to still apply and for there to be an OR between d/e? If that is the intent I would make it clear that a-c are still required and then you can choose either d/e to qualify. I also worry #3 opens the option for non-LIR entities (endsites) to claim to be LIRs to qualify under these LIR rules. At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote: >Hello- The deadline for proposal submissions is getting close (Feb 22nd). > >In order to help Jordi decide just how he will modify his previously proposed policy 2006-7 IPV6 Initial Allocation, I am asking for one more round of feedback. Below is the same email that went out back in November. Within it are the modifications currently being considered. A few people responded back in November, and Thank you to those who did. Now we are looking for more input from anyone who hasnt yet voiced their opinion. > >Thank you for your time >Marla Azinger > >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Azinger, Marla >Sent: Monday, November 13, 2006 11:00 AM >To: ppml at arin.net >Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- >InputRequested > > >Hello- In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email. We would like the communities input on three separate suggested revisions. What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other? I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins. When reviewing the three suggested changes please note the following assumptions: > >- New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. >- One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. >-Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. >- Organization in this is defined as a Corporation, ISP, LLC et al. > > >Suggested Change #1 (deletes and replaces current text of item d and requires ASN) >Replace line item d. to 6.5.1.1 with the following: >'To qualify for an initial allocation of IPV6 address space, an organization must': >d. be an existing, known ISP in the ARIN region OR be an organization which >can justify intent to announce the requested IPv6 address space within one >year and have/obtain and AS Number. > >Rationale for ASN: >Someone providing this kind of service needs to run BGP. > > >Suggested Change #2 (deletes and replaces current text of item d but does not require ASN) >Replace line item d. to 6.5.1.1 with the following: >'To qualify for an initial allocation of IPv6 address space, an organization >must': >d. be an existing, known ISP in the ARIN region OR be an organization which >can justify intent to announce the requested IPv6 address space within one >year. > >Rationale for no asn: >We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > > >Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN) >Insert line item e. to 6.5.1.1 with the following: >'To qualify for an initial allocation of IPV6 address space, an organization must': >e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. > >Rationale for no asn: >We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. > >Thank you for your time >Marla (ARIN AC) and Jordi (Proposal Author) > >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml > From jordi.palet at consulintel.es Fri Jan 26 07:08:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 13:08:43 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: Hi Andrew, See below in-line. Regards, Jordi > De: Andrew Dul > Responder a: > Fecha: Thu, 25 Jan 2007 14:38:51 -0800 > Para: > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > >> >> Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" >> justification >> >> Author: Jordi Palet Martinez >> Proposal Version: 1 >> Proposal type: delete >> Policy term: permanent >> Policy statement: >> >> Delete section 6.5.4.2. of NRMP. >> > > When you delete section 6.5.4.2 of the NRPM you are left with only the > following phrase as a guideline in determining the assignment of multiple > /48s. > > "...except in cases of extra large end sites where a larger assignment can > be justified.", section 6.5.2.1. > > If the goal of this policy change is to remove the requirement for the RIR > to check a multiple /48 assignment to an endsite, then this policy should > define the criteria for an LIR to determine if a larger than /48 assignment > is needed. Without a criteria in policy an LIR could choose to assign any > size block to an endsite. Under the wording of section 6.5.2.1 only the > word "justified" can be labeled as a criteria for determining the > assignment size. How is "justified" defined for an endsite in this context? The question is the same right now for ARIN. How is "justified" defined for hotsmasters to authorize that assignment ? > > While most LIRs are usually reasonable, to me it seems important to include > defined and somewhat rigorous criteria for the assignment of multiple /48s > and a requirement for the LIR to record this justification for later > auditing by the RIR when an LIR returns to the RIR for an additional > allocation. I believe the the LIR is reasonable also, and that's why I will much prefer to have them taking this decision. I'm not saying that the ARIN hostmasters criteria is not reasonable, but if we don't have a concrete definition for "justified", and think is fair enough to keep trusting the LIR. Otherwise, agree with you, let's work on a possible definition for "justified". Do you think we can find an agreement about that ? > >> Rationale: >> >> The current text requires the LIR to justify to the RIR/NIR when >> assigning multiple /48s to a single end site. It seems that the reason >> for this requirement is the lack of experience, which seems unreasonable >> after a few years this policy has been implemented, even if may not have >> been specific cases which used this policy section. >> > > I think the section was reasonably written as a throttle to excessive IPv6 > assignments to endsites by LIRs. > >> It seems useless, now that there is already deployment experience, to >> require a justification from the LIR to ARIN for assigning multiple /48s >> (or a shorter prefix, such as for example a /47). It is up to the LIR to >> require the justification to its own customers and decide according to >> it. The LIR will be already responsible to justify to ARIN the usage of >> any allocated >> block(s) when requesting for more, and this will already implicate an >> implicit justification of this kind of assignments. > > That is not the way I read section 6.5.4.1 > > "RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the detailed > information on IPv6 user networks as they did in IPv4, except for the cases > described in Section 6.4.4 and for the purposes of measuring utilization as > defined in this document." > > I read section 6.5.4.1 to allow an LIR to keep no records about the > justification for assignments to endsites. > > >> >> With this policy change, both ARIN and LIR staff will save resources in >> a justification, which seems unnecessary and should be completely on the >> hands of the LIR itself. >> > > How many times have ARIN staff had to evaluate the assignment of multiple > /48s to endsites so far? Is this really an issue? > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Fri Jan 26 07:50:04 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 13:50:04 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <20070125223826.0261E14445C@smtp2.arin.net> Message-ID: Hi Andrew, See below, in-line. Regards, Jordi > De: Andrew Dul > Responder a: > Fecha: Thu, 25 Jan 2007 14:56:53 -0800 > Para: > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > First I don't necessarily see the need to change the existing policy. I'd > don't see the 200 /48s plan as a real hinderance to a legitimate LIR. So do you think is not possible an ISP to have a few customer and make profitable business ? Do you think is reasonable to stop people that are willing or already doing business this way ? In fact, when I introduced my idea about this possible policy proposal at the last meeting, I recall at least a couple of people in the room being in this situation, so is something real. > > I generally only support change #1 The only trouble I see with this is that may be to obtain an ASN is mandated that the ISP is multihomed ? Is this the case in ARIN ? My view is that there may be small ISPs that aren't multihomed, but still need PA space in order to avoid depending on its upstream addressing space (avoid renumbering all customer networks, etc.). > > Change #2 would allow almost any organization to qualify as a LIR, Only if they plan to provide service to others, and I read that as perfectly valid for an ISP, not "any organization". > Change #3 while having a good intent seems oddly worded. I'm not sure if > the intent is for requirements a-c to still apply and for there to be an OR > between d/e? If that is the intent I would make it clear that a-c are > still required and then you can choose either d/e to qualify. I also worry > #3 opens the option for non-LIR entities (endsites) to claim to be LIRs to > qualify under these LIR rules. The idea is to keep existing policy and add as OR in between d/e. Same comment regarding is intended for ISPs (providing service to other organizations). > > > At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote: >> Hello- The deadline for proposal submissions is getting close (Feb 22nd). >> >> In order to help Jordi decide just how he will modify his previously > proposed policy 2006-7 IPV6 Initial Allocation, I am asking for one more > round of feedback. Below is the same email that went out back in November. > Within it are the modifications currently being considered. A few people > responded back in November, and Thank you to those who did. Now we are > looking for more input from anyone who hasnt yet voiced their opinion. >> >> Thank you for your time >> Marla Azinger >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Azinger, Marla >> Sent: Monday, November 13, 2006 11:00 AM >> To: ppml at arin.net >> Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- >> InputRequested >> >> >> Hello- In an effort to work with the community on changes to Policy > Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three > different suggested revisions are in this email. We would like the > communities input on three separate suggested revisions. What do you like > about them, or what do you not like about them? Do you prefer one > suggestion over the other? I have given each suggestion a different color > to make it easier to tell when one suggestion ands and another begins. > When reviewing the three suggested changes please note the following > assumptions: >> >> - New organizations who do not want to use IPv4 at all and start off using > IPv6 addresses only, need a policy that gives them permission to do so. > This is also valid for existing companies that may or may not have assigned > IPv4 addresses and now want to start offering IPv6 services. These > organizations may also wish to request IPv4 at the same time. >> - One year is given as the sufficient time frame to actually implement > usage of the IPv6 address space and reveal if the 'said organization' is > truly using the IPv6 space granted. >> -Every means of documentation that can reveal 'true intent of use' is not > listed as this can be a very long list and should be left to the discretion > of the RIR staff. >> - Organization in this is defined as a Corporation, ISP, LLC et al. >> >> >> Suggested Change #1 (deletes and replaces current text of item d and > requires ASN) >> Replace line item d. to 6.5.1.1 with the following: >> 'To qualify for an initial allocation of IPV6 address space, an > organization must': >> d. be an existing, known ISP in the ARIN region OR be an organization which >> can justify intent to announce the requested IPv6 address space within one >> year and have/obtain and AS Number. >> >> Rationale for ASN: >> Someone providing this kind of service needs to run BGP. >> >> >> Suggested Change #2 (deletes and replaces current text of item d but does > not require ASN) >> Replace line item d. to 6.5.1.1 with the following: >> 'To qualify for an initial allocation of IPv6 address space, an organization >> must': >> d. be an existing, known ISP in the ARIN region OR be an organization which >> can justify intent to announce the requested IPv6 address space within one >> year. >> >> Rationale for no asn: >> We should not require an ASN if they really don't need one? As long as > they are statically routed to an upstream and don't want to run > bgp/announce directly to the Internet, they don't need an ASN, therefore we > shouldn't create policy that would contribute to ASN bloat. >> >> >> Suggested Change #3 (leaves item d in place with the 200 /48 text and adds > a new item e but does not require ASN) >> Insert line item e. to 6.5.1.1 with the following: >> 'To qualify for an initial allocation of IPV6 address space, an > organization must': >> e. OR be an organization new to providing internet services, and can > justify intent to announce the requested IPV6 address space within one > year, through records such as contracts, inventory and/or other applicable > documentation. >> >> Rationale for no asn: >> We should not require an ASN if they really don't need one? As long as > they are statically routed to an upstream and don't want to run > bgp/announce directly to the Internet, they don't need an ASN, therefore we > shouldn't create policy that would contribute to ASN bloat. >> >> Thank you for your time >> Marla (ARIN AC) and Jordi (Proposal Author) >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From leo.vegoda at icann.org Fri Jan 26 09:27:56 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 26 Jan 2007 15:27:56 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <20070125222021.DA15714445C@smtp2.arin.net> References: <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: On Jan 25, 2007, at 11:38 PM, Andrew Dul wrote: [on deleting 6.5.4.2] > While most LIRs are usually reasonable, to me it seems important to > include > defined and somewhat rigorous criteria for the assignment of > multiple /48s > and a requirement for the LIR to record this justification for later > auditing by the RIR when an LIR returns to the RIR for an additional > allocation. > >> Rationale: >> >> The current text requires the LIR to justify to the RIR/NIR when >> assigning multiple /48s to a single end site. It seems that the >> reason >> for this requirement is the lack of experience, which seems >> unreasonable >> after a few years this policy has been implemented, even if may >> not have >> been specific cases which used this policy section. >> > > I think the section was reasonably written as a throttle to > excessive IPv6 > assignments to endsites by LIRs. While I appreciate the explanation that 6.5.4.2 was intended to throttle excessive IPv6 assignments to end sites, it has always been possible to work around it using section (6.5.3 LIR-to-ISP allocation). It specifically states that there "is no specific policy for an organization (LIR) to allocate address space to subordinate ISPs. Each LIR organization may develop its own policy for subordinate ISPs to encourage optimum utilization of the total address block allocated to the LIR." This has always allowed any ISP with an IPv6 allocation to define any downstream customer as an ISP and sub-allocate rather than assign space. As things stand, deleting 6.5.4.2 is unlikely to have a significant impact on address space consumption unless there is also a change to the policy on sub-allocations. Regards, -- Leo Vegoda IANA Numbers Liaison From tme at multicasttech.com Fri Jan 26 11:21:14 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 26 Jan 2007 11:21:14 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <2853565F-B57A-4E5A-81DB-38FA2EAB45F3@multicasttech.com> Hello; On Jan 26, 2007, at 7:50 AM, JORDI PALET MARTINEZ wrote: > Hi Andrew, > > See below, in-line. > > Regards, > Jordi > > > > >> De: Andrew Dul >> Responder a: >> Fecha: Thu, 25 Jan 2007 14:56:53 -0800 >> Para: >> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested >> changes-InputRequested >> >> First I don't necessarily see the need to change the existing >> policy. I'd >> don't see the 200 /48s plan as a real hinderance to a legitimate LIR. > > So do you think is not possible an ISP to have a few customer and make > profitable business ? > > Do you think is reasonable to stop people that are willing or > already doing > business this way ? > > In fact, when I introduced my idea about this possible policy > proposal at > the last meeting, I recall at least a couple of people in the room > being in > this situation, so is something real. > >> >> I generally only support change #1 > > The only trouble I see with this is that may be to obtain an ASN is > mandated > that the ISP is multihomed ? Is this the case in ARIN ? Not every entity which is multi-homed is an ISP. (My company is and isn't, respectively.) Look at 4.3, 4.4 and 4.5 in http://www.arin.net/policy/nrpm.html#two7 Clearly, being multi-homed is one way. But there are others : 4.5.2 The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: Regulatory restrictions for data transmission, Geographic distance and diversity between networks, Autonomous multihomed discrete networks. > > My view is that there may be small ISPs that aren't multihomed, but > still > need PA space in order to avoid depending on its upstream > addressing space Do you mean PI ? > (avoid renumbering all customer networks, etc.). > I think (and more importantly, there is clearly consensus that) there should be some filter for these assignments; the current mix seems reasonable to me. Regards Marshall >> >> Change #2 would allow almost any organization to qualify as a LIR, > > Only if they plan to provide service to others, and I read that as > perfectly > valid for an ISP, not "any organization". > >> Change #3 while having a good intent seems oddly worded. I'm not >> sure if >> the intent is for requirements a-c to still apply and for there to >> be an OR >> between d/e? If that is the intent I would make it clear that a-c >> are >> still required and then you can choose either d/e to qualify. I >> also worry >> #3 opens the option for non-LIR entities (endsites) to claim to be >> LIRs to >> qualify under these LIR rules. > > The idea is to keep existing policy and add as OR in between d/e. Same > comment regarding is intended for ISPs (providing service to other > organizations). > >> >> >> At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote: >>> Hello- The deadline for proposal submissions is getting close >>> (Feb 22nd). >>> >>> In order to help Jordi decide just how he will modify his previously >> proposed policy 2006-7 IPV6 Initial Allocation, I am asking for >> one more >> round of feedback. Below is the same email that went out back in >> November. >> Within it are the modifications currently being considered. A >> few people >> responded back in November, and Thank you to those who did. Now >> we are >> looking for more input from anyone who hasnt yet voiced their >> opinion. >>> >>> Thank you for your time >>> Marla Azinger >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>> Behalf Of >>> Azinger, Marla >>> Sent: Monday, November 13, 2006 11:00 AM >>> To: ppml at arin.net >>> Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- >>> InputRequested >>> >>> >>> Hello- In an effort to work with the community on changes to Policy >> Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three >> different suggested revisions are in this email. We would like the >> communities input on three separate suggested revisions. What do >> you like >> about them, or what do you not like about them? Do you prefer one >> suggestion over the other? I have given each suggestion a >> different color >> to make it easier to tell when one suggestion ands and another >> begins. >> When reviewing the three suggested changes please note the following >> assumptions: >>> >>> - New organizations who do not want to use IPv4 at all and start >>> off using >> IPv6 addresses only, need a policy that gives them permission to >> do so. >> This is also valid for existing companies that may or may not have >> assigned >> IPv4 addresses and now want to start offering IPv6 services. These >> organizations may also wish to request IPv4 at the same time. >>> - One year is given as the sufficient time frame to actually >>> implement >> usage of the IPv6 address space and reveal if the 'said >> organization' is >> truly using the IPv6 space granted. >>> -Every means of documentation that can reveal 'true intent of >>> use' is not >> listed as this can be a very long list and should be left to the >> discretion >> of the RIR staff. >>> - Organization in this is defined as a Corporation, ISP, LLC et al. >>> >>> >>> Suggested Change #1 (deletes and replaces current text of item d and >> requires ASN) >>> Replace line item d. to 6.5.1.1 with the following: >>> 'To qualify for an initial allocation of IPV6 address space, an >> organization must': >>> d. be an existing, known ISP in the ARIN region OR be an >>> organization which >>> can justify intent to announce the requested IPv6 address space >>> within one >>> year and have/obtain and AS Number. >>> >>> Rationale for ASN: >>> Someone providing this kind of service needs to run BGP. >>> >>> >>> Suggested Change #2 (deletes and replaces current text of item d >>> but does >> not require ASN) >>> Replace line item d. to 6.5.1.1 with the following: >>> 'To qualify for an initial allocation of IPv6 address space, an >>> organization >>> must': >>> d. be an existing, known ISP in the ARIN region OR be an >>> organization which >>> can justify intent to announce the requested IPv6 address space >>> within one >>> year. >>> >>> Rationale for no asn: >>> We should not require an ASN if they really don't need one? As >>> long as >> they are statically routed to an upstream and don't want to run >> bgp/announce directly to the Internet, they don't need an ASN, >> therefore we >> shouldn't create policy that would contribute to ASN bloat. >>> >>> >>> Suggested Change #3 (leaves item d in place with the 200 /48 text >>> and adds >> a new item e but does not require ASN) >>> Insert line item e. to 6.5.1.1 with the following: >>> 'To qualify for an initial allocation of IPV6 address space, an >> organization must': >>> e. OR be an organization new to providing internet services, and >>> can >> justify intent to announce the requested IPV6 address space within >> one >> year, through records such as contracts, inventory and/or other >> applicable >> documentation. >>> >>> Rationale for no asn: >>> We should not require an ASN if they really don't need one? As >>> long as >> they are statically routed to an upstream and don't want to run >> bgp/announce directly to the Internet, they don't need an ASN, >> therefore we >> shouldn't create policy that would contribute to ASN bloat. >>> >>> Thank you for your time >>> Marla (ARIN AC) and Jordi (Proposal Author) >>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >>> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > 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. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Jan 26 14:03:19 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 26 Jan 2007 13:03:19 -0600 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification References: Message-ID: <00d901c74187$d2bc61a0$333816ac@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" >> De: Andrew Dul >> >> While most LIRs are usually reasonable, to me it seems important >> to include defined and somewhat rigorous criteria for the assignment >> of multiple /48s and a requirement for the LIR to record this >> justification for later auditing by the RIR when an LIR returns to >> the >> RIR for an additional allocation. > > I believe the the LIR is reasonable also, and that's why I will much > prefer to have them taking this decision. I'm not saying that the ARIN > hostmasters criteria is not reasonable, but if we don't have a > concrete > definition for "justified", and think is fair enough to keep trusting > the LIR. If we provide no guidance to the LIR on what "justifies" a larger assignment, how can we expect them to be reasonable? We haven't told them what we're trusting them to do! > Otherwise, agree with you, let's work on a possible definition for > "justified". Do you think we can find an agreement about that ? I'd like that, just like I'd like a real definition for "site" (i.e. the location vs. organization debate). I also think that the criteria for a larger assignment by an LIR should match the criteria for a larger direct assignment by ARIN; we don't have that either. However, it's unclear that there is actually a problem here to be solved. Absent a comment from the ARIN Staff that a non-trivial number of larger-than-/48 assingments have been referred to them, I propose that we not solve this "problem" until it actually exists and we have the data to show what exactly needs solving. Along those lines, I also object to the removal of the "interim" designation from the IPv6 policies. We don't know what the policies should be at this point, we still haven't fully defined what we think they should be, and we don't have enough experience to progress past an interim status. Hopefully that will change in a few years, but it's reality today. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Fri Jan 26 14:52:55 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 26 Jan 2007 13:52:55 -0600 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested References: Message-ID: <00da01c74187$d390a190$333816ac@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" >> De: Andrew Dul >> >> First I don't necessarily see the need to change the existing policy. >> I'd >> don't see the 200 /48s plan as a real hinderance to a legitimate LIR. > > So do you think is not possible an ISP to have a few customer and make > profitable business ? Being a profitable ISP and being a legitimate LIR are different things. > Do you think is reasonable to stop people that are willing or already > doing > business this way ? If they're already doing business this way, they don't have a problem. > In fact, when I introduced my idea about this possible policy proposal > at > the last meeting, I recall at least a couple of people in the room > being in > this situation, so is something real. The existing policy states that for an ISP to become a v6 LIR, it needs "to be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years" Any existing, known ISP is exempt from the assignment requirement, so that leaves only new and/or unknown ISPs. They're only required to have a _plan_ for making 200 assignments within _five years_, and there is no penalty for failing to achieve the plan. That's a pretty darn low bar to meet. If one plans on starting a new ISP that cannot meet that bar, then the price is that one must make do with PA space from an upstream ISP. One might argue about the placement of the bar (i.e. the number of assignments), but it's hard to argue with the need for _some_ bar. We're talking about consuming global routing table slots here (even if ARIN doesn't explicitly acknowledge that). We can't just give them out to anyone who asks without _some_ justification showing they have a bona fide need for such. Before we make any changes to these rules, I'd like to see actual statements by people who have tried to get an allocation and have been denied. That way the community can look at the circumstances surrounding the denial, decide whether that's what we intended to happen, and change the rules if not. We're already getting enough flak from the larger ISPs that we've made getting a routing slot too easy; claims from the other side that we've made it too hard need evidence, IMHO. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From andrew.dul at quark.net Fri Jan 26 12:15:42 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 26 Jan 2007 09:15:42 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: References: <20070125222021.DA15714445C@smtp2.arin.net> <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: <20070126203615.3136314444D@smtp2.arin.net> At 03:27 PM 1/26/2007 +0100, Leo Vegoda wrote: >On Jan 25, 2007, at 11:38 PM, Andrew Dul wrote: > >[on deleting 6.5.4.2] > >> While most LIRs are usually reasonable, to me it seems important to >> include >> defined and somewhat rigorous criteria for the assignment of >> multiple /48s >> and a requirement for the LIR to record this justification for later >> auditing by the RIR when an LIR returns to the RIR for an additional >> allocation. >> >>> Rationale: >>> >>> The current text requires the LIR to justify to the RIR/NIR when >>> assigning multiple /48s to a single end site. It seems that the >>> reason >>> for this requirement is the lack of experience, which seems >>> unreasonable >>> after a few years this policy has been implemented, even if may >>> not have >>> been specific cases which used this policy section. >>> >> >> I think the section was reasonably written as a throttle to >> excessive IPv6 >> assignments to endsites by LIRs. > >While I appreciate the explanation that 6.5.4.2 was intended to >throttle excessive IPv6 assignments to end sites, it has always been >possible to work around it using section (6.5.3 LIR-to-ISP >allocation). It specifically states that there "is no specific policy >for an organization (LIR) to allocate address space to subordinate >ISPs. Each LIR organization may develop its own policy for >subordinate ISPs to encourage optimum utilization of the total >address block allocated to the LIR." > >This has always allowed any ISP with an IPv6 allocation to define any >downstream customer as an ISP and sub-allocate rather than assign space. > Sounds like we need to work on section 6.2 and try to define an ISP and also define some guidelines for LIR-to-ISP allocations. I know that is hard, but if we don't we leave open the option for LIRs to allocate huge blocks to "ISPs" From andrew.dul at quark.net Fri Jan 26 12:25:42 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 26 Jan 2007 09:25:42 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: References: <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: <20070126203615.CC1B214444D@smtp2.arin.net> Hello all... At 01:08 PM 1/26/2007 +0100, JORDI PALET MARTINEZ wrote: >> De: Andrew Dul >> >>> >>> >>> Delete section 6.5.4.2. of NRMP. >>> >> >> If the goal of this policy change is to remove the requirement for the RIR >> to check a multiple /48 assignment to an endsite, then this policy should >> define the criteria for an LIR to determine if a larger than /48 assignment >> is needed. Without a criteria in policy an LIR could choose to assign any >> size block to an endsite. Under the wording of section 6.5.2.1 only the >> word "justified" can be labeled as a criteria for determining the >> assignment size. How is "justified" defined for an endsite in this context? > >The question is the same right now for ARIN. How is "justified" defined for >hotsmasters to authorize that assignment ? > At least, when ARIN is used as a filter for these assignments we have staff which are familiar with IP allocation/assignment policies and can use their best judgement based upon their experience to apply a consistent method of "justification" across the entire region. While the "justification" may not be codified in the policy it can be created as a ARIN working practice which could be moved into the policy at a later time. >> >> While most LIRs are usually reasonable, to me it seems important to include >> defined and somewhat rigorous criteria for the assignment of multiple /48s >> and a requirement for the LIR to record this justification for later >> auditing by the RIR when an LIR returns to the RIR for an additional >> allocation. > >I believe the the LIR is reasonable also, and that's why I will much prefer >to have them taking this decision. I'm not saying that the ARIN hostmasters >criteria is not reasonable, but if we don't have a concrete definition for >"justified", and think is fair enough to keep trusting the LIR. > >Otherwise, agree with you, let's work on a possible definition for >"justified". Do you think we can find an agreement about that ? > Lets try... How can show immediate need for at least 50% of the /64 subnets (e.g. have the need for at least 32,768 subnets to receive a /47 assignment) Andrew From info at arin.net Fri Jan 26 15:55:26 2007 From: info at arin.net (Member Services) Date: Fri, 26 Jan 2007 15:55:26 -0500 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <20070125222021.DA15714445C@smtp2.arin.net> References: <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: <45BA6ABE.9000702@arin.net> Hi Andrew- ARIN has not registered a large number of IPv6 reassignments. However, of those that we have registered, many of them are for initial reassignments of multiple /48s to the same organization. In fact, out of a total of 115 reassignment registrations, 56 of them are larger than a /48. To date, we have not seen requests for additional reassignments of /48s to the same organization. Our registration software however, is programmed to flag additional reassignments of this type. Currently, ARIN is not asking for justification for these larger initial reassignments. The policy text as written is unclear and contains no criteria for the RIR to use to assess justification. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers Andrew Dul wrote: >>Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" >>justification >> >>Author: Jordi Palet Martinez >>Proposal Version: 1 >>Proposal type: delete >>Policy term: permanent >>Policy statement: >> >>Delete section 6.5.4.2. of NRMP. >> > > > When you delete section 6.5.4.2 of the NRPM you are left with only the > following phrase as a guideline in determining the assignment of multiple > /48s. > > "...except in cases of extra large end sites where a larger assignment can > be justified.", section 6.5.2.1. > > If the goal of this policy change is to remove the requirement for the RIR > to check a multiple /48 assignment to an endsite, then this policy should > define the criteria for an LIR to determine if a larger than /48 assignment > is needed. Without a criteria in policy an LIR could choose to assign any > size block to an endsite. Under the wording of section 6.5.2.1 only the > word "justified" can be labeled as a criteria for determining the > assignment size. How is "justified" defined for an endsite in this context? > > While most LIRs are usually reasonable, to me it seems important to include > defined and somewhat rigorous criteria for the assignment of multiple /48s > and a requirement for the LIR to record this justification for later > auditing by the RIR when an LIR returns to the RIR for an additional > allocation. > > >>Rationale: >> >>The current text requires the LIR to justify to the RIR/NIR when >>assigning multiple /48s to a single end site. It seems that the reason >>for this requirement is the lack of experience, which seems unreasonable >>after a few years this policy has been implemented, even if may not have >>been specific cases which used this policy section. >> > > > I think the section was reasonably written as a throttle to excessive IPv6 > assignments to endsites by LIRs. > > >>It seems useless, now that there is already deployment experience, to >>require a justification from the LIR to ARIN for assigning multiple /48s >>(or a shorter prefix, such as for example a /47). It is up to the LIR to >>require the justification to its own customers and decide according to >>it. The LIR will be already responsible to justify to ARIN the usage of >>any allocated >>block(s) when requesting for more, and this will already implicate an >>implicit justification of this kind of assignments. > > > That is not the way I read section 6.5.4.1 > > "RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the detailed > information on IPv6 user networks as they did in IPv4, except for the cases > described in Section 6.4.4 and for the purposes of measuring utilization as > defined in this document." > > I read section 6.5.4.1 to allow an LIR to keep no records about the > justification for assignments to endsites. > > > >>With this policy change, both ARIN and LIR staff will save resources in >>a justification, which seems unnecessary and should be completely on the >>hands of the LIR itself. >> > > > How many times have ARIN staff had to evaluate the assignment of multiple > /48s to endsites so far? Is this really an issue? > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From andrew.dul at quark.net Fri Jan 26 16:00:46 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 26 Jan 2007 13:00:46 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: <20070125223826.0261E14445C@smtp2.arin.net> Message-ID: <20070126204352.796C214445C@smtp2.arin.net> At 01:50 PM 1/26/2007 +0100, JORDI PALET MARTINEZ wrote: >> De: Andrew Dul >> >> First I don't necessarily see the need to change the existing policy. I'd >> don't see the 200 /48s plan as a real hinderance to a legitimate LIR. > >So do you think is not possible an ISP to have a few customer and make >profitable business ? I certainly think it is very possible to have a business and only a few customers and be a profitable. That isn't the question we should be considering in defining the policy. We also need to be considering how these changes will impact the routing infrastructure. Like it or not the policies we set have a very real impact of the routing infrastructure. While ARIN doesn't set routing policy it can heavily influence how routing economics (or lack thereof) effect the network architecture and infrastructure. How about this case... I have a home business and want to defray the costs of my internet service so I want to assign a /48 to my neighbors who will receive service via wireless. I'm now an LIR and eligible for a /32. That doesn't seem like the type of organization who is an LIR/ISP as was envisioned by others when defining the IPv6 routing infrastructure. > >Do you think is reasonable to stop people that are willing or already doing >business this way ? > >In fact, when I introduced my idea about this possible policy proposal at >the last meeting, I recall at least a couple of people in the room being in >this situation, so is something real. I'm more than happy to entertain how we can get IPv6 address space to legitimate ISPs who need address space. However, I think we need guidelines that define who is elgible and not just open the gates for any entity to receive IPv6 /32s. Andrew From jordi.palet at consulintel.es Fri Jan 26 17:52:38 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 23:52:38 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <2853565F-B57A-4E5A-81DB-38FA2EAB45F3@multicasttech.com> Message-ID: Hi Marshall, See below, in-line. Regards, Jordi > De: Marshall Eubanks > Responder a: > Fecha: Fri, 26 Jan 2007 11:21:14 -0500 > Para: > CC: > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > Hello; > > On Jan 26, 2007, at 7:50 AM, JORDI PALET MARTINEZ wrote: > >> Hi Andrew, >> >> See below, in-line. >> >> Regards, >> Jordi >> >> >> >> >>> De: Andrew Dul >>> Responder a: >>> Fecha: Thu, 25 Jan 2007 14:56:53 -0800 >>> Para: >>> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested >>> changes-InputRequested >>> >>> First I don't necessarily see the need to change the existing >>> policy. I'd >>> don't see the 200 /48s plan as a real hinderance to a legitimate LIR. >> >> So do you think is not possible an ISP to have a few customer and make >> profitable business ? >> >> Do you think is reasonable to stop people that are willing or >> already doing >> business this way ? >> >> In fact, when I introduced my idea about this possible policy >> proposal at >> the last meeting, I recall at least a couple of people in the room >> being in >> this situation, so is something real. >> >>> >>> I generally only support change #1 >> >> The only trouble I see with this is that may be to obtain an ASN is >> mandated >> that the ISP is multihomed ? Is this the case in ARIN ? > > Not every entity which is multi-homed is an ISP. (My company is and > isn't, respectively.) No, I'm not trying to mean that ... Sorry not having been clear enough. What I want to say is that there are ISPs which aren't multihomed (they have a single upstream provider). Those ISPs also have the right to receive an IPv6 allocation. In some regions, to receive an ASN you need to be multihomed. So if that's the case, then we are creating an artificial restriction for those single-homed ISPs. I'm not sure if this is the case of ARIN according to section 5 of the NRPM (I was traveling and off-line before, so couldn't check it before sending my previous email). My reading of this section is that to be assigned an ASN the organization must either have a unique routing policy or be multihomed. That's seems clear, but then it says that "an organization should request an ASN only when it is already multihomed or will become immediately". Is this meaning that the previous text (having a unique routing policy) is not enough ? > > Look at 4.3, 4.4 and 4.5 in > > http://www.arin.net/policy/nrpm.html#two7 > > Clearly, being multi-homed is one way. But there are others : > > 4.5.2 > The organization must have compelling criteria for creating discrete > networks. Examples of a discrete network might include: > Regulatory restrictions for data transmission, > Geographic distance and diversity between networks, > Autonomous multihomed discrete networks. > > >> >> My view is that there may be small ISPs that aren't multihomed, but >> still >> need PA space in order to avoid depending on its upstream >> addressing space > > Do you mean PI ? No, my view is that they need Provider space, because they are ISP providing service to other organizations. It is not a PI case. > >> (avoid renumbering all customer networks, etc.). >> > > I think (and more importantly, there is clearly consensus that) there > should be some filter for > these assignments; the current mix seems reasonable to me. > > Regards > Marshall > >>> >>> Change #2 would allow almost any organization to qualify as a LIR, >> >> Only if they plan to provide service to others, and I read that as >> perfectly >> valid for an ISP, not "any organization". > >> >>> Change #3 while having a good intent seems oddly worded. I'm not >>> sure if >>> the intent is for requirements a-c to still apply and for there to >>> be an OR >>> between d/e? If that is the intent I would make it clear that a-c >>> are >>> still required and then you can choose either d/e to qualify. I >>> also worry >>> #3 opens the option for non-LIR entities (endsites) to claim to be >>> LIRs to >>> qualify under these LIR rules. >> >> The idea is to keep existing policy and add as OR in between d/e. Same >> comment regarding is intended for ISPs (providing service to other >> organizations). >> >>> >>> >>> At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote: >>>> Hello- The deadline for proposal submissions is getting close >>>> (Feb 22nd). >>>> >>>> In order to help Jordi decide just how he will modify his previously >>> proposed policy 2006-7 IPV6 Initial Allocation, I am asking for >>> one more >>> round of feedback. Below is the same email that went out back in >>> November. >>> Within it are the modifications currently being considered. A >>> few people >>> responded back in November, and Thank you to those who did. Now >>> we are >>> looking for more input from anyone who hasnt yet voiced their >>> opinion. >>>> >>>> Thank you for your time >>>> Marla Azinger >>>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >>>> Behalf Of >>>> Azinger, Marla >>>> Sent: Monday, November 13, 2006 11:00 AM >>>> To: ppml at arin.net >>>> Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes- >>>> InputRequested >>>> >>>> >>>> Hello- In an effort to work with the community on changes to Policy >>> Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three >>> different suggested revisions are in this email. We would like the >>> communities input on three separate suggested revisions. What do >>> you like >>> about them, or what do you not like about them? Do you prefer one >>> suggestion over the other? I have given each suggestion a >>> different color >>> to make it easier to tell when one suggestion ands and another >>> begins. >>> When reviewing the three suggested changes please note the following >>> assumptions: >>>> >>>> - New organizations who do not want to use IPv4 at all and start >>>> off using >>> IPv6 addresses only, need a policy that gives them permission to >>> do so. >>> This is also valid for existing companies that may or may not have >>> assigned >>> IPv4 addresses and now want to start offering IPv6 services. These >>> organizations may also wish to request IPv4 at the same time. >>>> - One year is given as the sufficient time frame to actually >>>> implement >>> usage of the IPv6 address space and reveal if the 'said >>> organization' is >>> truly using the IPv6 space granted. >>>> -Every means of documentation that can reveal 'true intent of >>>> use' is not >>> listed as this can be a very long list and should be left to the >>> discretion >>> of the RIR staff. >>>> - Organization in this is defined as a Corporation, ISP, LLC et al. >>>> >>>> >>>> Suggested Change #1 (deletes and replaces current text of item d and >>> requires ASN) >>>> Replace line item d. to 6.5.1.1 with the following: >>>> 'To qualify for an initial allocation of IPV6 address space, an >>> organization must': >>>> d. be an existing, known ISP in the ARIN region OR be an >>>> organization which >>>> can justify intent to announce the requested IPv6 address space >>>> within one >>>> year and have/obtain and AS Number. >>>> >>>> Rationale for ASN: >>>> Someone providing this kind of service needs to run BGP. >>>> >>>> >>>> Suggested Change #2 (deletes and replaces current text of item d >>>> but does >>> not require ASN) >>>> Replace line item d. to 6.5.1.1 with the following: >>>> 'To qualify for an initial allocation of IPv6 address space, an >>>> organization >>>> must': >>>> d. be an existing, known ISP in the ARIN region OR be an >>>> organization which >>>> can justify intent to announce the requested IPv6 address space >>>> within one >>>> year. >>>> >>>> Rationale for no asn: >>>> We should not require an ASN if they really don't need one? As >>>> long as >>> they are statically routed to an upstream and don't want to run >>> bgp/announce directly to the Internet, they don't need an ASN, >>> therefore we >>> shouldn't create policy that would contribute to ASN bloat. >>>> >>>> >>>> Suggested Change #3 (leaves item d in place with the 200 /48 text >>>> and adds >>> a new item e but does not require ASN) >>>> Insert line item e. to 6.5.1.1 with the following: >>>> 'To qualify for an initial allocation of IPV6 address space, an >>> organization must': >>>> e. OR be an organization new to providing internet services, and >>>> can >>> justify intent to announce the requested IPV6 address space within >>> one >>> year, through records such as contracts, inventory and/or other >>> applicable >>> documentation. >>>> >>>> Rationale for no asn: >>>> We should not require an ASN if they really don't need one? As >>>> long as >>> they are statically routed to an upstream and don't want to run >>> bgp/announce directly to the Internet, they don't need an ASN, >>> therefore we >>> shouldn't create policy that would contribute to ASN bloat. >>>> >>>> Thank you for your time >>>> Marla (ARIN AC) and Jordi (Proposal Author) >>>> >>>> _______________________________________________ >>>> PPML mailing list >>>> PPML at arin.net >>>> http://lists.arin.net/mailman/listinfo/ppml >>>> _______________________________________________ >>>> PPML mailing list >>>> PPML at arin.net >>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> 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. >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Fri Jan 26 18:01:48 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 00:01:48 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <00d901c74187$d2bc61a0$333816ac@atlanta.polycom.com> Message-ID: See below, in-line. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Fri, 26 Jan 2007 13:03:19 -0600 > Para: ARIN PPML > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > > Thus spake "JORDI PALET MARTINEZ" >>> De: Andrew Dul >>> >>> While most LIRs are usually reasonable, to me it seems important >>> to include defined and somewhat rigorous criteria for the assignment >>> of multiple /48s and a requirement for the LIR to record this >>> justification for later auditing by the RIR when an LIR returns to >>> the >>> RIR for an additional allocation. >> >> I believe the the LIR is reasonable also, and that's why I will much >> prefer to have them taking this decision. I'm not saying that the ARIN >> hostmasters criteria is not reasonable, but if we don't have a >> concrete >> definition for "justified", and think is fair enough to keep trusting >> the LIR. > > If we provide no guidance to the LIR on what "justifies" a larger > assignment, how can we expect them to be reasonable? We haven't told > them what we're trusting them to do! Right, but the same guidance is required by ARIN staff to be objective ... > >> Otherwise, agree with you, let's work on a possible definition for >> "justified". Do you think we can find an agreement about that ? > > I'd like that, just like I'd like a real definition for "site" (i.e. the > location vs. organization debate). I also think that the criteria for a > larger assignment by an LIR should match the criteria for a larger > direct assignment by ARIN; we don't have that either. > > However, it's unclear that there is actually a problem here to be > solved. Absent a comment from the ARIN Staff that a non-trivial number > of larger-than-/48 assingments have been referred to them, I propose > that we not solve this "problem" until it actually exists and we have > the data to show what exactly needs solving. The problem is no having an objective criteria. In absence of that, this text on the policy is useless and it should be removed. > > Along those lines, I also object to the removal of the "interim" > designation from the IPv6 policies. We don't know what the policies > should be at this point, we still haven't fully defined what we think > they should be, and we don't have enough experience to progress past an > interim status. Hopefully that will change in a few years, but it's > reality today. By definition any policy is subjected to changes if there is new experience, needs, or whatever. Having such text in the IPv6 one and not in others make it a strange and unfair situation. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Fri Jan 26 18:11:21 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 00:11:21 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <00da01c74187$d390a190$333816ac@atlanta.polycom.com> Message-ID: See below, in-line. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Fri, 26 Jan 2007 13:52:55 -0600 > Para: ARIN PPML > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > Thus spake "JORDI PALET MARTINEZ" >>> De: Andrew Dul >>> >>> First I don't necessarily see the need to change the existing policy. >>> I'd >>> don't see the 200 /48s plan as a real hinderance to a legitimate LIR. >> >> So do you think is not possible an ISP to have a few customer and make >> profitable business ? > > Being a profitable ISP and being a legitimate LIR are different things. Agree, but is not the point. I'm assuming that the ISP becomes a LIR. Right now, if he has only a few customers, can't get allocated an IPv6 block. He needs to go first for an IPv4 one. It is an artificial situation. > >> Do you think is reasonable to stop people that are willing or already >> doing >> business this way ? > > If they're already doing business this way, they don't have a problem. I mean is unreasonable to avoid them doing business just because they are starting a new business based only in IPv6 services (or mainly). > >> In fact, when I introduced my idea about this possible policy proposal >> at >> the last meeting, I recall at least a couple of people in the room >> being in >> this situation, so is something real. > > The existing policy states that for an ISP to become a v6 LIR, it needs > "to be an existing, known ISP in the ARIN region or have a plan for > making at least 200 /48 assignments to other organizations within five > years" > > Any existing, known ISP is exempt from the assignment requirement, so > that leaves only new and/or unknown ISPs. They're only required to have > a _plan_ for making 200 assignments within _five years_, and there is no > penalty for failing to achieve the plan. That's a pretty darn low bar > to meet. If the ISP has a plan for making business with only a few customers, he needs to invent a false plan to get allocated IPv6. This is irrational. We don't want to force the members to lie. It is an artificial barrier, and there is no any real need for that barrier. > > If one plans on starting a new ISP that cannot meet that bar, then the > price is that one must make do with PA space from an upstream ISP. One This only works if that ISP has a single upstream. It may not be the case. Again, an artificial barrier. > might argue about the placement of the bar (i.e. the number of > assignments), but it's hard to argue with the need for _some_ bar. > We're talking about consuming global routing table slots here (even if > ARIN doesn't explicitly acknowledge that). We can't just give them out > to anyone who asks without _some_ justification showing they have a bona > fide need for such. Agree, routing table slots are important, but we can't go beyond "ultra-conservation" artificially and against freedom of business establishment. Can it be a case for a court ? I don't think we should even risk for that possibility. > > Before we make any changes to these rules, I'd like to see actual > statements by people who have tried to get an allocation and have been > denied. That way the community can look at the circumstances > surrounding the denial, decide whether that's what we intended to > happen, and change the rules if not. We're already getting enough flak > from the larger ISPs that we've made getting a routing slot too easy; > claims from the other side that we've made it too hard need evidence, > IMHO. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Fri Jan 26 18:18:37 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 00:18:37 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <45BA6ABE.9000702@arin.net> Message-ID: So if ARIN is not asking for a justification, that part of the policy is of NO USE and should go. The alternative is to agree on an objective justification criteria. Regards, Jordi > De: Member Services > Responder a: > Fecha: Fri, 26 Jan 2007 15:55:26 -0500 > Para: > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > > Hi Andrew- > > ARIN has not registered a large number of IPv6 reassignments. However, > of those that we have registered, many of them are for initial > reassignments of multiple /48s to the same organization. In fact, out > of a total of 115 reassignment registrations, 56 of them are larger than > a /48. > > To date, we have not seen requests for additional reassignments of /48s > to the same organization. Our registration software however, is > programmed to flag additional reassignments of this type. > > Currently, ARIN is not asking for justification for these larger initial > reassignments. The policy text as written is unclear and contains no > criteria for the RIR to use to assess justification. > > Regards, > Leslie Nobile > Director, Registration Services > American Registry for Internet Numbers > > > > Andrew Dul wrote: >>> Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" >>> justification >>> >>> Author: Jordi Palet Martinez >>> Proposal Version: 1 >>> Proposal type: delete >>> Policy term: permanent >>> Policy statement: >>> >>> Delete section 6.5.4.2. of NRMP. >>> >> >> >> When you delete section 6.5.4.2 of the NRPM you are left with only the >> following phrase as a guideline in determining the assignment of multiple >> /48s. >> >> "...except in cases of extra large end sites where a larger assignment can >> be justified.", section 6.5.2.1. >> >> If the goal of this policy change is to remove the requirement for the RIR >> to check a multiple /48 assignment to an endsite, then this policy should >> define the criteria for an LIR to determine if a larger than /48 assignment >> is needed. Without a criteria in policy an LIR could choose to assign any >> size block to an endsite. Under the wording of section 6.5.2.1 only the >> word "justified" can be labeled as a criteria for determining the >> assignment size. How is "justified" defined for an endsite in this context? >> >> While most LIRs are usually reasonable, to me it seems important to include >> defined and somewhat rigorous criteria for the assignment of multiple /48s >> and a requirement for the LIR to record this justification for later >> auditing by the RIR when an LIR returns to the RIR for an additional >> allocation. >> >> >>> Rationale: >>> >>> The current text requires the LIR to justify to the RIR/NIR when >>> assigning multiple /48s to a single end site. It seems that the reason >>> for this requirement is the lack of experience, which seems unreasonable >>> after a few years this policy has been implemented, even if may not have >>> been specific cases which used this policy section. >>> >> >> >> I think the section was reasonably written as a throttle to excessive IPv6 >> assignments to endsites by LIRs. >> >> >>> It seems useless, now that there is already deployment experience, to >>> require a justification from the LIR to ARIN for assigning multiple /48s >>> (or a shorter prefix, such as for example a /47). It is up to the LIR to >>> require the justification to its own customers and decide according to >>> it. The LIR will be already responsible to justify to ARIN the usage of >>> any allocated >>> block(s) when requesting for more, and this will already implicate an >>> implicit justification of this kind of assignments. >> >> >> That is not the way I read section 6.5.4.1 >> >> "RIRs/NIRs are not concerned about which address size an LIR/ISP >> actually assigns. Accordingly, RIRs/NIRs will not request the detailed >> information on IPv6 user networks as they did in IPv4, except for the cases >> described in Section 6.4.4 and for the purposes of measuring utilization as >> defined in this document." >> >> I read section 6.5.4.1 to allow an LIR to keep no records about the >> justification for assignments to endsites. >> >> >> >>> With this policy change, both ARIN and LIR staff will save resources in >>> a justification, which seems unnecessary and should be completely on the >>> hands of the LIR itself. >>> >> >> >> How many times have ARIN staff had to evaluate the assignment of multiple >> /48s to endsites so far? Is this really an issue? >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From drc at virtualized.org Fri Jan 26 18:24:32 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 26 Jan 2007 15:24:32 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <2DD3BC8A-68D4-476C-ACE7-FD2F98D492FE@virtualized.org> > Right now, if he has only a few customers, can't get allocated an > IPv6 block. He needs to go first for an IPv4 one. It is an > artificial situation. Are you suggesting that someone in the ARIN region is trying to start up an ISP that will provide _only_ IPv6 service and that ARIN's policies should be modified to facilitate this? Thanks, -drc From plzak at arin.net Fri Jan 26 19:30:19 2007 From: plzak at arin.net (Ray Plzak) Date: Fri, 26 Jan 2007 19:30:19 -0500 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: References: <45BA6ABE.9000702@arin.net> Message-ID: ARIN is not asking for a justification because as Leslie pointed out, there is no criteria to measure the justification. That doesn't mean that the community can't decide to establish criteria which would give ARIN a reason to ask for the justification and which would help to manage consumption. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > JORDI PALET MARTINEZ > Sent: Friday, January 26, 2007 6:19 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal > of "multiple /48" justification > > So if ARIN is not asking for a justification, that part of the policy > is of > NO USE and should go. The alternative is to agree on an objective > justification criteria. > > Regards, > Jordi > > > > > > De: Member Services > > Responder a: > > Fecha: Fri, 26 Jan 2007 15:55:26 -0500 > > Para: > > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal > of > > "multiple /48" justification > > > > Hi Andrew- > > > > ARIN has not registered a large number of IPv6 reassignments. > However, > > of those that we have registered, many of them are for initial > > reassignments of multiple /48s to the same organization. In fact, > out > > of a total of 115 reassignment registrations, 56 of them are larger > than > > a /48. > > > > To date, we have not seen requests for additional reassignments of > /48s > > to the same organization. Our registration software however, is > > programmed to flag additional reassignments of this type. > > > > Currently, ARIN is not asking for justification for these larger > initial > > reassignments. The policy text as written is unclear and contains no > > criteria for the RIR to use to assess justification. > > > > Regards, > > Leslie Nobile > > Director, Registration Services > > American Registry for Internet Numbers > > > > > > > > Andrew Dul wrote: > >>> Policy Proposal Name: Changes to IPv6 policy - removal of "multiple > /48" > >>> justification > >>> > >>> Author: Jordi Palet Martinez > >>> Proposal Version: 1 > >>> Proposal type: delete > >>> Policy term: permanent > >>> Policy statement: > >>> > >>> Delete section 6.5.4.2. of NRMP. > >>> > >> > >> > >> When you delete section 6.5.4.2 of the NRPM you are left with only > the > >> following phrase as a guideline in determining the assignment of > multiple > >> /48s. > >> > >> "...except in cases of extra large end sites where a larger > assignment can > >> be justified.", section 6.5.2.1. > >> > >> If the goal of this policy change is to remove the requirement for > the RIR > >> to check a multiple /48 assignment to an endsite, then this policy > should > >> define the criteria for an LIR to determine if a larger than /48 > assignment > >> is needed. Without a criteria in policy an LIR could choose to > assign any > >> size block to an endsite. Under the wording of section 6.5.2.1 only > the > >> word "justified" can be labeled as a criteria for determining the > >> assignment size. How is "justified" defined for an endsite in this > context? > >> > >> While most LIRs are usually reasonable, to me it seems important to > include > >> defined and somewhat rigorous criteria for the assignment of > multiple /48s > >> and a requirement for the LIR to record this justification for later > >> auditing by the RIR when an LIR returns to the RIR for an additional > >> allocation. > >> > >> > >>> Rationale: > >>> > >>> The current text requires the LIR to justify to the RIR/NIR when > >>> assigning multiple /48s to a single end site. It seems that the > reason > >>> for this requirement is the lack of experience, which seems > unreasonable > >>> after a few years this policy has been implemented, even if may not > have > >>> been specific cases which used this policy section. > >>> > >> > >> > >> I think the section was reasonably written as a throttle to > excessive IPv6 > >> assignments to endsites by LIRs. > >> > >> > >>> It seems useless, now that there is already deployment experience, > to > >>> require a justification from the LIR to ARIN for assigning multiple > /48s > >>> (or a shorter prefix, such as for example a /47). It is up to the > LIR to > >>> require the justification to its own customers and decide according > to > >>> it. The LIR will be already responsible to justify to ARIN the > usage of > >>> any allocated > >>> block(s) when requesting for more, and this will already implicate > an > >>> implicit justification of this kind of assignments. > >> > >> > >> That is not the way I read section 6.5.4.1 > >> > >> "RIRs/NIRs are not concerned about which address size an LIR/ISP > >> actually assigns. Accordingly, RIRs/NIRs will not request the > detailed > >> information on IPv6 user networks as they did in IPv4, except for > the cases > >> described in Section 6.4.4 and for the purposes of measuring > utilization as > >> defined in this document." > >> > >> I read section 6.5.4.1 to allow an LIR to keep no records about the > >> justification for assignments to endsites. > >> > >> > >> > >>> With this policy change, both ARIN and LIR staff will save > resources in > >>> a justification, which seems unnecessary and should be completely > on the > >>> hands of the LIR itself. > >>> > >> > >> > >> How many times have ARIN staff had to evaluate the assignment of > multiple > >> /48s to endsites so far? Is this really an issue? > >> > >> > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > >> > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > 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. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Jan 26 20:38:10 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 26 Jan 2007 19:38:10 -0600 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification References: <20070125222021.DA15714445C@smtp2.arin.net> <45BA6ABE.9000702@arin.net> Message-ID: <016c01c741b5$554a09b0$333816ac@atlanta.polycom.com> Thus spake "Member Services" > ARIN has not registered a large number of IPv6 reassignments. > However, of those that we have registered, many of them are for > initial > reassignments of multiple /48s to the same organization. In fact, out > of a total of 115 reassignment registrations, 56 of them are larger > than > a /48. ... > Currently, ARIN is not asking for justification for these larger > initial > reassignments. The policy text as written is unclear and contains no > criteria for the RIR to use to assess justification. I'd caution readers here that "multiple /48s to the same organization" might not mean that the LIR is attempting to allocate "larger than a /48." It could be that those organizations have multiple service locations with the same billing address, e.g. a corporation using the Internet for inter-office connectivity. This comes back to the "site" definition problem I just referenced in another message. ( This assumes ARIN's software provides a way to reassign a /47 in a single operation; all bets are off if that's incorrect. Since I'm merely a member of the general public and not an LIR, I don't know. ) > To date, we have not seen requests for additional reassignments of > /48s to the same organization. Our registration software however, is > programmed to flag additional reassignments of this type. If the number is "zero to date", then IMHO this proposal is a solution in search of a problem. Until someone's request gets denied, we _cannot_ have a problem with the rules being too strict, only with them being too loose. I'm not thrilled with the "not asking for justification" above, though I understand that's a logical result of the interim policy (as would not accepting _any_ justification). I'd prefer that ARIN ask why, even if you're going to rubber-stamp the approvals for lack of criteria. That may sound pointless for your purposes, but it'd help us figure out what kind of direction you need from us in future policy. Once you've gotten a few real cases, you can present a "here's what we did and why, so change the policy if you don't like it" at the next meeting. Still, thanks for the data, Leslie. It's good to see what the impact (or not) our policies have on ARIN's operations. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From kloch at kl.net Sat Jan 27 02:09:11 2007 From: kloch at kl.net (Kevin Loch) Date: Sat, 27 Jan 2007 02:09:11 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <2DD3BC8A-68D4-476C-ACE7-FD2F98D492FE@virtualized.org> References: <2DD3BC8A-68D4-476C-ACE7-FD2F98D492FE@virtualized.org> Message-ID: <45BAFA97.9040807@kl.net> David Conrad wrote: >> Right now, if he has only a few customers, can't get allocated an >> IPv6 block. He needs to go first for an IPv4 one. It is an >> artificial situation. > > Are you suggesting that someone in the ARIN region is trying to start > up an ISP that will provide _only_ IPv6 service and that ARIN's > policies should be modified to facilitate this? The policies seem to allow for IPv6 only ISP already, if they have a plan for a minimum number of IPv6 customers (currently 200 over 5 years). - Kevin From kloch at kl.net Sat Jan 27 02:24:04 2007 From: kloch at kl.net (Kevin Loch) Date: Sat, 27 Jan 2007 02:24:04 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <20070126204352.796C214445C@smtp2.arin.net> References: <20070125223826.0261E14445C@smtp2.arin.net> <20070126204352.796C214445C@smtp2.arin.net> Message-ID: <45BAFE14.3060200@kl.net> Andrew Dul wrote: > I certainly think it is very possible to have a business and only a few > customers and be a profitable. That isn't the question we should be > considering in defining the policy. > > We also need to be considering how these changes will impact the routing > infrastructure. Like it or not the policies we set have a very real impact > of the routing infrastructure. While ARIN doesn't set routing policy it > can heavily influence how routing economics (or lack thereof) effect the > network architecture and infrastructure. > > How about this case... > > I have a home business and want to defray the costs of my internet service > so I want to assign a /48 to my neighbors who will receive service via > wireless. I'm now an LIR and eligible for a /32. > > That doesn't seem like the type of organization who is an LIR/ISP as was > envisioned by others when defining the IPv6 routing infrastructure. The folks that originally defined the IPv6 address policy only allowed for a handfull of super-isp's that would each get a /16. That was impractical (to put it mildly) in the conservative direction. The other extreme is that anyone who would be assign space to others would get a LIR minimum of /32. That of course is not practical with the current routing system either. While the current threshold of 200 over 5 years seems like just a wild guess it doesn't seem to be stopping anyone from actually deploying IPv6 if they want to. I don't see any reason to change the ISP requirements part of the policy right now. - Kevin From jordi.palet at consulintel.es Sat Jan 27 04:04:11 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 10:04:11 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: Message-ID: Hi Ray, Yes, I understood that. That's why I'm suggesting that this can either be a supporting point for my proposal or alternatively, we need to establish an objective criteria. My position, obviously is that it will be better to just remove this section, as I don't think the situation will change drastically in terms of consumption. Regards, Jordi > De: Ray Plzak > Responder a: > Fecha: Fri, 26 Jan 2007 19:30:19 -0500 > Para: "jordi.palet at consulintel.es" , > "ppml at arin.net" > Conversaci?n: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > Asunto: RE: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > > ARIN is not asking for a justification because as Leslie pointed out, there is > no criteria to measure the justification. That doesn't mean that the community > can't decide to establish criteria which would give ARIN a reason to ask for > the justification and which would help to manage consumption. > > Ray > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> JORDI PALET MARTINEZ >> Sent: Friday, January 26, 2007 6:19 PM >> To: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal >> of "multiple /48" justification >> >> So if ARIN is not asking for a justification, that part of the policy >> is of >> NO USE and should go. The alternative is to agree on an objective >> justification criteria. >> >> Regards, >> Jordi >> >> >> >> >>> De: Member Services >>> Responder a: >>> Fecha: Fri, 26 Jan 2007 15:55:26 -0500 >>> Para: >>> Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal >> of >>> "multiple /48" justification >>> >>> Hi Andrew- >>> >>> ARIN has not registered a large number of IPv6 reassignments. >> However, >>> of those that we have registered, many of them are for initial >>> reassignments of multiple /48s to the same organization. In fact, >> out >>> of a total of 115 reassignment registrations, 56 of them are larger >> than >>> a /48. >>> >>> To date, we have not seen requests for additional reassignments of >> /48s >>> to the same organization. Our registration software however, is >>> programmed to flag additional reassignments of this type. >>> >>> Currently, ARIN is not asking for justification for these larger >> initial >>> reassignments. The policy text as written is unclear and contains no >>> criteria for the RIR to use to assess justification. >>> >>> Regards, >>> Leslie Nobile >>> Director, Registration Services >>> American Registry for Internet Numbers >>> >>> >>> >>> Andrew Dul wrote: >>>>> Policy Proposal Name: Changes to IPv6 policy - removal of "multiple >> /48" >>>>> justification >>>>> >>>>> Author: Jordi Palet Martinez >>>>> Proposal Version: 1 >>>>> Proposal type: delete >>>>> Policy term: permanent >>>>> Policy statement: >>>>> >>>>> Delete section 6.5.4.2. of NRMP. >>>>> >>>> >>>> >>>> When you delete section 6.5.4.2 of the NRPM you are left with only >> the >>>> following phrase as a guideline in determining the assignment of >> multiple >>>> /48s. >>>> >>>> "...except in cases of extra large end sites where a larger >> assignment can >>>> be justified.", section 6.5.2.1. >>>> >>>> If the goal of this policy change is to remove the requirement for >> the RIR >>>> to check a multiple /48 assignment to an endsite, then this policy >> should >>>> define the criteria for an LIR to determine if a larger than /48 >> assignment >>>> is needed. Without a criteria in policy an LIR could choose to >> assign any >>>> size block to an endsite. Under the wording of section 6.5.2.1 only >> the >>>> word "justified" can be labeled as a criteria for determining the >>>> assignment size. How is "justified" defined for an endsite in this >> context? >>>> >>>> While most LIRs are usually reasonable, to me it seems important to >> include >>>> defined and somewhat rigorous criteria for the assignment of >> multiple /48s >>>> and a requirement for the LIR to record this justification for later >>>> auditing by the RIR when an LIR returns to the RIR for an additional >>>> allocation. >>>> >>>> >>>>> Rationale: >>>>> >>>>> The current text requires the LIR to justify to the RIR/NIR when >>>>> assigning multiple /48s to a single end site. It seems that the >> reason >>>>> for this requirement is the lack of experience, which seems >> unreasonable >>>>> after a few years this policy has been implemented, even if may not >> have >>>>> been specific cases which used this policy section. >>>>> >>>> >>>> >>>> I think the section was reasonably written as a throttle to >> excessive IPv6 >>>> assignments to endsites by LIRs. >>>> >>>> >>>>> It seems useless, now that there is already deployment experience, >> to >>>>> require a justification from the LIR to ARIN for assigning multiple >> /48s >>>>> (or a shorter prefix, such as for example a /47). It is up to the >> LIR to >>>>> require the justification to its own customers and decide according >> to >>>>> it. The LIR will be already responsible to justify to ARIN the >> usage of >>>>> any allocated >>>>> block(s) when requesting for more, and this will already implicate >> an >>>>> implicit justification of this kind of assignments. >>>> >>>> >>>> That is not the way I read section 6.5.4.1 >>>> >>>> "RIRs/NIRs are not concerned about which address size an LIR/ISP >>>> actually assigns. Accordingly, RIRs/NIRs will not request the >> detailed >>>> information on IPv6 user networks as they did in IPv4, except for >> the cases >>>> described in Section 6.4.4 and for the purposes of measuring >> utilization as >>>> defined in this document." >>>> >>>> I read section 6.5.4.1 to allow an LIR to keep no records about the >>>> justification for assignments to endsites. >>>> >>>> >>>> >>>>> With this policy change, both ARIN and LIR staff will save >> resources in >>>>> a justification, which seems unnecessary and should be completely >> on the >>>>> hands of the LIR itself. >>>>> >>>> >>>> >>>> How many times have ARIN staff had to evaluate the assignment of >> multiple >>>> /48s to endsites so far? Is this really an issue? >>>> >>>> >>>> _______________________________________________ >>>> PPML mailing list >>>> PPML at arin.net >>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> 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. >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Sat Jan 27 04:08:06 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 10:08:06 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <2DD3BC8A-68D4-476C-ACE7-FD2F98D492FE@virtualized.org> Message-ID: Hi David, Yes, it is a perfect valid case, but we can make a more simple one: A new ISP want to provide dual stack services. Under the current policy, it seems that he will need to have a plan for at least 200 /48. If the ISP doesn't plan to have that number of customers, he is being forced to lie, otherwise it will not get the IPv6 block allocated. I think this is not good. As said, it is an arbitrary barrier. Regards, Jordi > De: David Conrad > Responder a: > Fecha: Fri, 26 Jan 2007 15:24:32 -0800 > Para: > CC: Public Policy Mailing List > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > >> Right now, if he has only a few customers, can't get allocated an >> IPv6 block. He needs to go first for an IPv4 one. It is an >> artificial situation. > > Are you suggesting that someone in the ARIN region is trying to start > up an ISP that will provide _only_ IPv6 service and that ARIN's > policies should be modified to facilitate this? > > Thanks, > -drc > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Sat Jan 27 04:13:42 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 10:13:42 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <016c01c741b5$554a09b0$333816ac@atlanta.polycom.com> Message-ID: Stephen, In my opinion, policies are not made to be a show stopper, but to regulate the situation. If the policy is broken (incomplete, because can't be applied due to the lack of an objective criteria), there is a problem. The solution is not to ignore it until someone suffer the problem. That's not fair. A business can't wait for 1 year (my guess about minimum time required to succeed with a policy proposal) or even have the risk that there is never an agreement in the definition of an objective criteria and wait forever. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Fri, 26 Jan 2007 19:38:10 -0600 > Para: ARIN PPML > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "multiple /48" justification > > Thus spake "Member Services" >> ARIN has not registered a large number of IPv6 reassignments. >> However, of those that we have registered, many of them are for >> initial >> reassignments of multiple /48s to the same organization. In fact, out >> of a total of 115 reassignment registrations, 56 of them are larger >> than >> a /48. > ... >> Currently, ARIN is not asking for justification for these larger >> initial >> reassignments. The policy text as written is unclear and contains no >> criteria for the RIR to use to assess justification. > > I'd caution readers here that "multiple /48s to the same organization" > might not mean that the LIR is attempting to allocate "larger than a > /48." It could be that those organizations have multiple service > locations with the same billing address, e.g. a corporation using the > Internet for inter-office connectivity. This comes back to the "site" > definition problem I just referenced in another message. > > ( This assumes ARIN's software provides a way to reassign a /47 in a > single operation; all bets are off if that's incorrect. Since I'm > merely a member of the general public and not an LIR, I don't know. ) > >> To date, we have not seen requests for additional reassignments of >> /48s to the same organization. Our registration software however, is >> programmed to flag additional reassignments of this type. > > If the number is "zero to date", then IMHO this proposal is a solution > in search of a problem. Until someone's request gets denied, we > _cannot_ have a problem with the rules being too strict, only with them > being too loose. > > I'm not thrilled with the "not asking for justification" above, though I > understand that's a logical result of the interim policy (as would not > accepting _any_ justification). I'd prefer that ARIN ask why, even if > you're going to rubber-stamp the approvals for lack of criteria. That > may sound pointless for your purposes, but it'd help us figure out what > kind of direction you need from us in future policy. Once you've gotten > a few real cases, you can present a "here's what we did and why, so > change the policy if you don't like it" at the next meeting. > > > Still, thanks for the data, Leslie. It's good to see what the impact > (or not) our policies have on ARIN's operations. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Sat Jan 27 04:20:21 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 10:20:21 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <45BAFA97.9040807@kl.net> Message-ID: Hi Kevin, Yes, the policy facilitate to create a lie to allow those cases (even dual stack cases for new ISPs which also need to lie if they don't have a plan, or start business with IPv4, wait and then get allocated the IPv6 block). It will be good to know how many ISPs got allocated an IPv6 block more than 5 years ago, and still don't have announced the prefix, neither assigned just 20 or 30% of the 200 /48. Should then get the block claimed back ? It is fair towards people that don't want to lie ? We are living in a lie. Not good. Not serious neither honest with the policy process. Regards, Jordi > De: Kevin Loch > Responder a: > Fecha: Sat, 27 Jan 2007 02:09:11 -0500 > Para: Public Policy Mailing List > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > David Conrad wrote: >>> Right now, if he has only a few customers, can't get allocated an >>> IPv6 block. He needs to go first for an IPv4 one. It is an >>> artificial situation. >> >> Are you suggesting that someone in the ARIN region is trying to start >> up an ISP that will provide _only_ IPv6 service and that ARIN's >> policies should be modified to facilitate this? > > > The policies seem to allow for IPv6 only ISP already, if they have a > plan for a minimum number of IPv6 customers (currently 200 over 5 > years). > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Sat Jan 27 04:23:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Jan 2007 10:23:10 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <45BAFE14.3060200@kl.net> Message-ID: I guess Leslie can tell us how many request have been rejected on the basis of the lack of a plan for 200 /48, however, as said in my previous message, it seems to me that many of those "plans" are just made up to get the prefix. If we have a single policy with helps to lie, are we accepting the same way the people to lie in all the other policies ? Regards, Jordi > De: Kevin Loch > Responder a: > Fecha: Sat, 27 Jan 2007 02:24:04 -0500 > Para: > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > Andrew Dul wrote: > >> I certainly think it is very possible to have a business and only a few >> customers and be a profitable. That isn't the question we should be >> considering in defining the policy. >> >> We also need to be considering how these changes will impact the routing >> infrastructure. Like it or not the policies we set have a very real impact >> of the routing infrastructure. While ARIN doesn't set routing policy it >> can heavily influence how routing economics (or lack thereof) effect the >> network architecture and infrastructure. >> >> How about this case... >> >> I have a home business and want to defray the costs of my internet service >> so I want to assign a /48 to my neighbors who will receive service via >> wireless. I'm now an LIR and eligible for a /32. >> >> That doesn't seem like the type of organization who is an LIR/ISP as was >> envisioned by others when defining the IPv6 routing infrastructure. > > The folks that originally defined the IPv6 address policy > only allowed for a handfull of super-isp's that would each get a /16. > That was impractical (to put it mildly) in the conservative direction. > > The other extreme is that anyone who would be assign space > to others would get a LIR minimum of /32. That of course is not > practical with the current routing system either. > > While the current threshold of 200 over 5 years seems like just a wild > guess it doesn't seem to be stopping anyone from actually deploying > IPv6 if they want to. > > I don't see any reason to change the ISP requirements part of the > policy right now. > > - Kevin > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From andrew.dul at quark.net Sat Jan 27 14:16:03 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Sat, 27 Jan 2007 11:16:03 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification Message-ID: <20070127185711.8FD4414443C@smtp2.arin.net> At 12:01 AM 1/27/2007 +0100, JORDI PALET MARTINEZ wrote: >> De: Stephen Sprunk >> However, it's unclear that there is actually a problem here to be >> solved. Absent a comment from the ARIN Staff that a non-trivial number >> of larger-than-/48 assingments have been referred to them, I propose >> that we not solve this "problem" until it actually exists and we have >> the data to show what exactly needs solving. That seems reasonable to me too. > >The problem is no having an objective criteria. In absence of that, this >text on the policy is useless and it should be removed. > Or we should add objective criteria to the policy so that ARIN staff can make a determination if multiple /48 assignments should be permitted. How about the following... Remove the "Note:" paragraph from 6.5.4.2 and replace with the following. The RIR/NIR shall use the following criteria to evalulate multiple /48 assignments: New IPv6 end-user assignments: If the end user can show immediate need for at least 16,384 (25% of /48) /64 subnets they can be assigned additional /48 subnets such that their initial assignment usage is below 25% of initial /64 subnets. Existing IPv6 end-user assignments: If the end-user is currently using at least 32,768 (50% of a /48) /64 subnets they shall be permitted additional /48s such that their assignment usage is below 25% of /64 subnets for a two-year growth projection. Thoughts? To high? To low? From kloch at kl.net Sat Jan 27 14:26:00 2007 From: kloch at kl.net (Kevin Loch) Date: Sat, 27 Jan 2007 14:26:00 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <45BBA748.7060801@kl.net> JORDI PALET MARTINEZ wrote: > Hi Kevin, > > Yes, the policy facilitate to create a lie to allow those cases (even dual > stack cases for new ISPs which also need to lie if they don't have a plan, > or start business with IPv4, wait and then get allocated the IPv6 block). My main concern is that the policy allow for an orderly migration to IPv6 when the perception of IPv4 address scarcity catches up with the reality. The current isp/pi policies do that very well. For the v6 only case, the only requirement is that you dream big, which most entrepreneurs do to begin with. I mean this seriously, i'm not using 'dream' as a euphemism for 'lie'. The only reason for this is to prevent unconstrained and impractical routing table bloat. Yet still you can do v6 only and dream small by getting space from an upstream provider. Compare this to the current v4 policy which essentially doesn't allow startups to dream big but requires them to start small with space from an upstream provider in most cases. It is very likely that a more restrictive policy similar to the way v4 is done will be required in the future (if/when v6 is adopted on a wide scale) to constrain route bloat. - Kevin From ppml at rs.seastrom.com Sat Jan 27 17:19:54 2007 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sat, 27 Jan 2007 17:19:54 -0500 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <016c01c741b5$554a09b0$333816ac@atlanta.polycom.com> (Stephen Sprunk's message of "Fri, 26 Jan 2007 19:38:10 -0600") References: <20070125222021.DA15714445C@smtp2.arin.net> <45BA6ABE.9000702@arin.net> <016c01c741b5$554a09b0$333816ac@atlanta.polycom.com> Message-ID: <86tzycqfhx.fsf@seastrom.com> "Stephen Sprunk" writes: > I'm not thrilled with the "not asking for justification" above, though I > understand that's a logical result of the interim policy (as would not > accepting _any_ justification). I'd prefer that ARIN ask why, even if > you're going to rubber-stamp the approvals for lack of criteria. That > may sound pointless for your purposes, but it'd help us figure out what > kind of direction you need from us in future policy. Once you've gotten > a few real cases, you can present a "here's what we did and why, so > change the policy if you don't like it" at the next meeting. Exactly so. I'm in favor of having the policies serve the public good rather than acting as an impediment to it (as could end up being the case if we make up some numbers that sound plausible and make a policy based upon them). It would be highly constructive if ARIN staff could start gathering and documenting justifications that organizations are offering. Anonymized (of course) they would provide fine grist for the public process mill. > Still, thanks for the data, Leslie. It's good to see what the impact > (or not) our policies have on ARIN's operations. What Stephen said. Thanks, ARIN staff. :-) ---Rob From stephen at sprunk.org Sat Jan 27 22:37:29 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 27 Jan 2007 21:37:29 -0600 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification References: Message-ID: <00b501c7428d$ee7893d0$6701a8c0@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > In my opinion, policies are not made to be a show stopper, but to > regulate the situation. If the policy is broken (incomplete, because > can't be applied due to the lack of an objective criteria), there is a > problem. > > The solution is not to ignore it until someone suffer the problem. > That's > not fair. ARIN's implementation of the intentionally-vague policy is to approve _all_ requests. Unless that changes, there is no chance that _anyone_ will suffer from this policy by being denied what they need. The only possible suffering is by the community as a whole because we're giving out _too many_ addresses without cause, but based on the trivial number of reassignments to date, that's not happening yet. When it does, we can come back and look at making things tougher -- not easier. > A business can't wait for 1 year (my guess about minimum > time required to succeed with a policy proposal) or even have the risk > that there is never an agreement in the definition of an objective > criteria and wait forever. "Never" and "forever" are strong words. If there's a problem, we'll fix it within a year or two. In the meantime we're erring on the side of being too permissive, and the BOT has the authority to take emergency action if we're proven wrong in a way that doesn't allow the normal policy process to fix things in time. I still have not seen any substantive claims that the current policy is broken in a way that merits fixing, nor any proposals to "fix" the policy that are backed up by real data. Nobody has even presented a case where there's a problem, other than your own hypothetical (as far as we know) example of a new ISP that in five years only intends to serve <200 v6 customers who are not large enough to get PI space yet large enough PA space is not technically feasible. I'm sorry, but that's such a strange example that I have to think you've deliberately fashioned it to show a "weakness" in our policies, not that you are imagining anyone would actually fit it. The simple matter is that it's far, far easier to get IPv6 space -- many would say too easy -- than IPv4 space under existing policy and people still don't want IPv6 yet. Our efforts should be spent on stimulating demand, not spinning our wheels making policy changes to lower the bar even further. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From randy at psg.com Sun Jan 28 00:50:27 2007 From: randy at psg.com (Randy Bush) Date: Sat, 27 Jan 2007 19:50:27 -1000 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <00b501c7428d$ee7893d0$6701a8c0@atlanta.polycom.com> References: <00b501c7428d$ee7893d0$6701a8c0@atlanta.polycom.com> Message-ID: <5523-SnapperMsgDF20CFBFC1E1EA2F@[10.178.114.147]> At this point it' beginning to feel as if Jordi is abusing the RIRs' open policy processes by inundating us all with dozens of policy proposals to meet his vision of ipv6 marketing. randy ___ sent from a handheld, so even more terse than usual :-) From drc at virtualized.org Sun Jan 28 14:08:09 2007 From: drc at virtualized.org (David Conrad) Date: Sun, 28 Jan 2007 11:08:09 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <1458E15F-2E14-47E5-9E46-7E4623A18CFF@virtualized.org> Jordi, On Jan 27, 2007, at 1:08 AM, JORDI PALET MARTINEZ wrote: > A new ISP want to provide dual stack services. Under the current > policy, it > seems that he will need to have a plan for at least 200 /48. That's 200 /48 over _five_ years, right? > If the ISP > doesn't plan to have that number of customers, he is being forced > to lie, > otherwise it will not get the IPv6 block allocated. If an ISP isn't going to have 200 customers within 5 years, the theory goes it should obtain its address space from its upstream service provider. This is the same as with IPv4 and since IPv6 uses the same routing tecnology as IPv4, this would appear to make sense. > I think this is not good. As said, it is an arbitrary barrier. Given limited resources (in this case, it is the routing system), there will always be arbitrary barriers. Rgds, -drc From michael.dillon at bt.com Mon Jan 29 04:21:36 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Jan 2007 09:21:36 -0000 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C197C962@i2km07-ukbr.domain1.systemhost.net> See below, in-line. --Michael Dillon > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of JORDI PALET MARTINEZ > Sent: 26 January 2007 23:11 > To: ppml at arin.net > Subject: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation > suggested changes-InputRequested > > See below, in-line. > > Regards, > Jordi > > > > > > De: Stephen Sprunk > > Responder a: > > Fecha: Fri, 26 Jan 2007 13:52:55 -0600 > > Para: ARIN PPML > > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > > changes-InputRequested > > > > Thus spake "JORDI PALET MARTINEZ" > >>> De: Andrew Dul > >>> > >>> First I don't necessarily see the need to change the > existing policy. > >>> I'd > >>> don't see the 200 /48s plan as a real hinderance to a > legitimate LIR. > >> > >> So do you think is not possible an ISP to have a few > customer and make > >> profitable business ? > > > > Being a profitable ISP and being a legitimate LIR are > different things. > > Agree, but is not the point. I'm assuming that the ISP > becomes a LIR. Right > now, if he has only a few customers, can't get allocated an > IPv6 block. He > needs to go first for an IPv4 one. It is an artificial situation. > > > > >> Do you think is reasonable to stop people that are willing > or already > >> doing > >> business this way ? > > > > If they're already doing business this way, they don't have > a problem. > > I mean is unreasonable to avoid them doing business just > because they are > starting a new business based only in IPv6 services (or mainly). > > > > >> In fact, when I introduced my idea about this possible > policy proposal > >> at > >> the last meeting, I recall at least a couple of people in the room > >> being in > >> this situation, so is something real. > > > > The existing policy states that for an ISP to become a v6 > LIR, it needs > > "to be an existing, known ISP in the ARIN region or have a plan for > > making at least 200 /48 assignments to other organizations > within five > > years" > > > > Any existing, known ISP is exempt from the assignment > requirement, so > > that leaves only new and/or unknown ISPs. They're only > required to have > > a _plan_ for making 200 assignments within _five years_, > and there is no > > penalty for failing to achieve the plan. That's a pretty > darn low bar > > to meet. > > If the ISP has a plan for making business with only a few > customers, he > needs to invent a false plan to get allocated IPv6. This is > irrational. We > don't want to force the members to lie. It is an artificial > barrier, and > there is no any real need for that barrier. > > > > > If one plans on starting a new ISP that cannot meet that > bar, then the > > price is that one must make do with PA space from an > upstream ISP. One > > This only works if that ISP has a single upstream. It may not > be the case. > Again, an artificial barrier. > > > might argue about the placement of the bar (i.e. the number of > > assignments), but it's hard to argue with the need for _some_ bar. > > We're talking about consuming global routing table slots > here (even if > > ARIN doesn't explicitly acknowledge that). We can't just > give them out > > to anyone who asks without _some_ justification showing > they have a bona > > fide need for such. > > Agree, routing table slots are important, but we can't go beyond > "ultra-conservation" artificially and against freedom of business > establishment. Can it be a case for a court ? I don't think > we should even > risk for that possibility. > > > > > Before we make any changes to these rules, I'd like to see actual > > statements by people who have tried to get an allocation > and have been > > denied. That way the community can look at the circumstances > > surrounding the denial, decide whether that's what we intended to > > happen, and change the rules if not. We're already getting > enough flak > > from the larger ISPs that we've made getting a routing slot > too easy; > > claims from the other side that we've made it too hard need > evidence, > > IMHO. > > > > S > > > > Stephen Sprunk "God does not play dice." --Albert Einstein > > CCIE #3723 "God is an inveterate gambler, and He throws the > > K5SSS dice at every possible opportunity." --Stephen Hawking > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > 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. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml Jordi, It is annoying to pick through these long quoted messages and try to figure out what you are trying to say. If you can't take the time to extract the relevant bits of the quoted material then perhaps you could just post all your comments at the top of the message. You will find that a lot more people read your words that way. From leo.vegoda at icann.org Mon Jan 29 12:49:02 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 29 Jan 2007 09:49:02 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration In-Reply-To: <45B7759A.2050902@arin.net> References: <45B7759A.2050902@arin.net> Message-ID: <339262E7-136E-47D0-BA39-1425873EDA4A@icann.org> On Jan 24, 2007, at 4:04 PM, Member Services wrote: [...] > Delete following text at section 6.1.1. of NRMP: > > "This policy is considered to be an interim policy. It will be > reviewed > in the future, subject to greater experience in the administration > of IPv6." The strangest thing about this proposal is that it seeks to remove a statement about the interim nature of the IPv6 policy but has been submitted alongside other proposals to modify that same policy. If the policy is being actively revised it is strange to remove the statement that it "will be reviewed in the future, subject to greater experience in the administration of IPv6." I suspect that people considering an IPv6 deployment are unlikely to be dissuaded by the statement but there's probably no harm in re- phrasing it a bit and putting it near the start of the NRPM so that it applies to IPv4 and ASN policy, too. Regards, -- Leo Vegoda IANA Numbers Liaison From christopher.morrow at gmail.com Mon Jan 29 12:57:03 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 29 Jan 2007 12:57:03 -0500 Subject: [ppml] Fwd: FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <75cb24520701290956s1caad0f6k7edbb40166ed4045@mail.gmail.com> References: <45BAFA97.9040807@kl.net> <75cb24520701290956s1caad0f6k7edbb40166ed4045@mail.gmail.com> Message-ID: <75cb24520701290957x3033cab3j4cafdd19e41c5763@mail.gmail.com> (ugh, gmail bit me... I meant to reply to the list not jordi) ---------- Forwarded message ---------- From: Christopher Morrow Date: Jan 29, 2007 12:56 PM Subject: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested To: jordi.palet at consulintel.es On 1/27/07, JORDI PALET MARTINEZ wrote: > It will be good to know how many ISPs got allocated an IPv6 block more than > 5 years ago, and still don't have announced the prefix, neither assigned > just 20 or 30% of the 200 /48. Should then get the block claimed back ? It > is fair towards people that don't want to lie ? private network use, which doesn't require public network routability. managment use (comcast/alaine) which doesn't require (or want) public reachability/routability. looking for a public route is a 'poor' method to show usage. From christopher.morrow at gmail.com Mon Jan 29 13:04:25 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 29 Jan 2007 13:04:25 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: <2DD3BC8A-68D4-476C-ACE7-FD2F98D492FE@virtualized.org> Message-ID: <75cb24520701291004qf47d14dp3532f71dd2317e24@mail.gmail.com> On 1/27/07, JORDI PALET MARTINEZ wrote: > Hi David, > > Yes, it is a perfect valid case, but we can make a more simple one: > > A new ISP want to provide dual stack services. Under the current policy, it > seems that he will need to have a plan for at least 200 /48. If the ISP > doesn't plan to have that number of customers, he is being forced to lie, > otherwise it will not get the IPv6 block allocated. here's the problem. There is a very real cost to each slot in the global table, some limits must be set (should be set). 200 seems sort of arbitrary, but it's a start, and it requires some sensitivity to this issue. Willy-nilly pushing ip space around seems very negligent. From Lee.Howard at stanleyassociates.com Mon Jan 29 14:11:57 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 29 Jan 2007 14:11:57 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB404A9AEFD@CL-S-EX-1.stanleyassociates.com> > Jordi > > De: Stephen Sprunk Responder a: > > might argue about the placement of the bar (i.e. the number of > > assignments), but it's hard to argue with the need for _some_ bar. > > We're talking about consuming global routing table slots > here (even if > > ARIN doesn't explicitly acknowledge that). We can't just give them > > out to anyone who asks without _some_ justification showing > they have > > a bona fide need for such. > > Agree, routing table slots are important, but we can't go > beyond "ultra-conservation" artificially and against freedom > of business establishment. Can it be a case for a court ? I > don't think we should even risk for that possibility. What does "freedom of business establishment" mean? Just so I can properly prepare, in what way do you imagine this going to court? What would be the case made against ARIN? Thanks, Lee From jordi.palet at consulintel.es Mon Jan 29 15:02:44 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 29 Jan 2007 21:02:44 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <1458E15F-2E14-47E5-9E46-7E4623A18CFF@virtualized.org> Message-ID: Hi David, No, using address space from the upstream is not a solution. Example 1, this ISP has 2 or more upstream providers. Example 2, it has only a dozen of big customers with big networks, can't risk depending on the addressing space of the actual upstream (he may decide to change it later and will need to renumber all the customers). Regards, Jordi > De: David Conrad > Responder a: > Fecha: Sun, 28 Jan 2007 11:08:09 -0800 > Para: > CC: > Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > Jordi, > > On Jan 27, 2007, at 1:08 AM, JORDI PALET MARTINEZ wrote: >> A new ISP want to provide dual stack services. Under the current >> policy, it >> seems that he will need to have a plan for at least 200 /48. > > That's 200 /48 over _five_ years, right? > >> If the ISP >> doesn't plan to have that number of customers, he is being forced >> to lie, >> otherwise it will not get the IPv6 block allocated. > > If an ISP isn't going to have 200 customers within 5 years, the > theory goes it should obtain its address space from its upstream > service provider. This is the same as with IPv4 and since IPv6 uses > the same routing tecnology as IPv4, this would appear to make sense. > >> I think this is not good. As said, it is an arbitrary barrier. > > Given limited resources (in this case, it is the routing system), > there will always be arbitrary barriers. > > Rgds, > -drc > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Mon Jan 29 15:04:25 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 29 Jan 2007 21:04:25 +0100 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration In-Reply-To: <339262E7-136E-47D0-BA39-1425873EDA4A@icann.org> Message-ID: Hi Leo, All the policies are subjected to changes and that doesn't mean they are interim. In fact, as you said, if we keep interim in this one, we should use interim in all the others also, right ? Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Mon, 29 Jan 2007 09:49:02 -0800 > Para: > Asunto: Re: [ppml] Policy Proposal: Changes to IPv6 policy - removal of > "interim" consideration > > On Jan 24, 2007, at 4:04 PM, Member Services wrote: > > [...] > >> Delete following text at section 6.1.1. of NRMP: >> >> "This policy is considered to be an interim policy. It will be >> reviewed >> in the future, subject to greater experience in the administration >> of IPv6." > > The strangest thing about this proposal is that it seeks to remove a > statement about the interim nature of the IPv6 policy but has been > submitted alongside other proposals to modify that same policy. If > the policy is being actively revised it is strange to remove the > statement that it "will be reviewed in the future, subject to greater > experience in the administration of IPv6." > > I suspect that people considering an IPv6 deployment are unlikely to > be dissuaded by the statement but there's probably no harm in re- > phrasing it a bit and putting it near the start of the NRPM so that > it applies to IPv4 and ASN policy, too. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From jordi.palet at consulintel.es Mon Jan 29 15:10:49 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 29 Jan 2007 21:10:49 +0100 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB404A9AEFD@CL-S-EX-1.stanleyassociates.com> Message-ID: I'm not a lawyer, but yesterday talking to one, told me that an arbitrary restriction (not based in any technical reasons, or something similar) to access a resource, such as the 200 /48 will be against Spanish laws to protect discrimination among different company size, anti-trust, etc. My guess is that this regulation is a transposition of EU laws, so it will apply to many European countries. In general, membership organizations can setup their own rules (our policies), but those can't go beyond law or restrict it. Of course, law in US may be different. My view is that this should be double-checked in each region. Regards, Jordi > De: "Howard, W. Lee" > Responder a: > Fecha: Mon, 29 Jan 2007 14:11:57 -0500 > Para: , > Conversaci?n: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > Asunto: RE: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > changes-InputRequested > > >> Jordi >>> De: Stephen Sprunk Responder a: > >>> might argue about the placement of the bar (i.e. the number of >>> assignments), but it's hard to argue with the need for _some_ bar. >>> We're talking about consuming global routing table slots >> here (even if >>> ARIN doesn't explicitly acknowledge that). We can't just give them >>> out to anyone who asks without _some_ justification showing >> they have >>> a bona fide need for such. >> >> Agree, routing table slots are important, but we can't go >> beyond "ultra-conservation" artificially and against freedom >> of business establishment. Can it be a case for a court ? I >> don't think we should even risk for that possibility. > > What does "freedom of business establishment" mean? > > Just so I can properly prepare, in what way do you imagine this > going to court? What would be the case made against ARIN? > > Thanks, > > Lee ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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. From randy at psg.com Mon Jan 29 15:22:11 2007 From: randy at psg.com (Randy Bush) Date: Mon, 29 Jan 2007 12:22:11 -0800 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <45BE5773.7000908@psg.com> > No, using address space from the upstream is not a solution. Example 1, this > ISP has 2 or more upstream providers. Example 2, it has only a dozen of big > customers with big networks, can't risk depending on the addressing space of > the actual upstream (he may decide to change it later and will need to > renumber all the customers). as this is how it is done in ipv4, and as far as routing resources and technology, ipv6 is no different than ipv4 orhter than tyhe potential to make a bigger mess, why should this be any different for ipv6? randy From leo.vegoda at icann.org Mon Jan 29 15:22:50 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 29 Jan 2007 12:22:50 -0800 Subject: [ppml] Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration In-Reply-To: References: Message-ID: <874E826C-48B2-4ABA-A9F6-83E97FB17DE0@icann.org> Hi Jordi, On Jan 29, 2007, at 12:04 PM, JORDI PALET MARTINEZ wrote: > > All the policies are subjected to changes and that doesn't mean > they are > interim. > > In fact, as you said, if we keep interim in this one, we should use > interim > in all the others also, right ? Like I said, it is very strange to try and take away a statement about how the policy is under active revision while it is being revised. If I was going to tidy things up then I'd re-phrase the text and move it up to the top so it applies for the whole document. I suspect it would make more sense to wait for a time when the IPv6 policy had been stable for 18 month or more before making this change. Regards, -- Leo Vegoda IANA Numbers Liaison From kloch at kl.net Mon Jan 29 14:47:33 2007 From: kloch at kl.net (Kevin Loch) Date: Mon, 29 Jan 2007 14:47:33 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: Message-ID: <45BE4F55.9020100@kl.net> JORDI PALET MARTINEZ wrote: > Hi David, > > No, using address space from the upstream is not a solution. Example 1, this > ISP has 2 or more upstream providers. Example 2, it has only a dozen of big > customers with big networks, can't risk depending on the addressing space of > the actual upstream (he may decide to change it later and will need to > renumber all the customers). > One interpretation of "known isp" is having space reallocated (not reassigned) to them via SWIP by an upstream. Indeed this is usually what startup isp's do today under v4 before they get an direct assignment. Wouldn't this work for the cases above? If you are really that serious about having no v4 in this hypothetical startup, what are you using for root dns glue? - Kevin From bmanning at karoshi.com Mon Jan 29 16:40:09 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 29 Jan 2007 21:40:09 +0000 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB404A9AEFD@CL-S-EX-1.stanleyassociates.com> Message-ID: <20070129214009.GA10856@vacation.karoshi.com.> last i checked, the ARIN service region did not include any EU countries, including Spain. One attribute of the RIR system is that it allows each region to set/specify policies that meet regional criteria. in the clear absence of a "global routing table" - i might suggest that allocation polcies might better be tuned to reflect regional need. After all, the RIR's primary responsibility is prudent stewardship of the addressing resources and routing table slots aren't them. YMMV of course. --bill On Mon, Jan 29, 2007 at 09:10:49PM +0100, JORDI PALET MARTINEZ wrote: > I'm not a lawyer, but yesterday talking to one, told me that an arbitrary > restriction (not based in any technical reasons, or something similar) to > access a resource, such as the 200 /48 will be against Spanish laws to > protect discrimination among different company size, anti-trust, etc. > > My guess is that this regulation is a transposition of EU laws, so it will > apply to many European countries. > > In general, membership organizations can setup their own rules (our > policies), but those can't go beyond law or restrict it. > > Of course, law in US may be different. My view is that this should be > double-checked in each region. > > Regards, > Jordi > > > > > > De: "Howard, W. Lee" > > Responder a: > > Fecha: Mon, 29 Jan 2007 14:11:57 -0500 > > Para: , > > Conversaci?n: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > > changes-InputRequested > > Asunto: RE: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > > changes-InputRequested > > > > > >> Jordi > >>> De: Stephen Sprunk Responder a: > > > >>> might argue about the placement of the bar (i.e. the number of > >>> assignments), but it's hard to argue with the need for _some_ bar. > >>> We're talking about consuming global routing table slots > >> here (even if > >>> ARIN doesn't explicitly acknowledge that). We can't just give them > >>> out to anyone who asks without _some_ justification showing > >> they have > >>> a bona fide need for such. > >> > >> Agree, routing table slots are important, but we can't go > >> beyond "ultra-conservation" artificially and against freedom > >> of business establishment. Can it be a case for a court ? I > >> don't think we should even risk for that possibility. > > > > What does "freedom of business establishment" mean? > > > > Just so I can properly prepare, in what way do you imagine this > > going to court? What would be the case made against ARIN? > > > > Thanks, > > > > Lee > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > 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. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From christopher.morrow at gmail.com Mon Jan 29 20:49:47 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 29 Jan 2007 20:49:47 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested In-Reply-To: References: <1458E15F-2E14-47E5-9E46-7E4623A18CFF@virtualized.org> Message-ID: <75cb24520701291749j5981d08dn7e5dd29ff278ebee@mail.gmail.com> On 1/29/07, JORDI PALET MARTINEZ wrote: > Hi David, > > No, using address space from the upstream is not a solution. Example 1, this > ISP has 2 or more upstream providers. Example 2, it has only a dozen of big the solution you describe is not a problem with PA nor PI space, but with multihoming in v6. So, provided there was a multihoming solution that worked for PA addressed sites this doesn't seem to be a problem. Good thing there is a solution for PA addressed sites, eh? > customers with big networks, can't risk depending on the addressing space of > the actual upstream (he may decide to change it later and will need to > renumber all the customers). 'dozens of big networks customers' so, like over 200 sites and they should/could get a direct ipv6 allocation. Or off the sites are 'big' who cares? each is getting a /48 which is 65,535 subnets per site, so bigger than that? 1 prefix per site inside their routing domain seems well within reason. As to re-numbering, isn't that 'free' with ipv6? couldn't they re-number as time allowed once they were large enough to justify a direct v6 allocation from ARIN ? These arguements seem specious.... From Lee.Howard at stanleyassociates.com Tue Jan 30 15:14:25 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 30 Jan 2007 15:14:25 -0500 Subject: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB404B398B2@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of JORDI PALET MARTINEZ > Sent: Monday, January 29, 2007 3:11 PM > To: ppml at arin.net > Subject: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation > suggested changes-InputRequested > > I'm not a lawyer, but yesterday talking to one, told me that > an arbitrary restriction (not based in any technical reasons, > or something similar) to access a resource, such as the 200 > /48 will be against Spanish laws to protect discrimination > among different company size, anti-trust, etc. This would be the forum for the technical experts to determine whether such restrictions are necessary. If there is consensus among the technical community, then it would be surprising for a court to find a policy to be lacking in technical merit. > In general, membership organizations can setup their own > rules (our policies), but those can't go beyond law or restrict it. > > Of course, law in US may be different. My view is that this > should be double-checked in each region. Yes, that's part of the process. ARIN's superlative General Counsel will advise, and a summary is presented at the public policy meeting. The Advisory Council also has counsel available, as does the Board. Lee > > Regards, > Jordi > > > > > > De: "Howard, W. Lee" > > Responder a: > > Fecha: Mon, 29 Jan 2007 14:11:57 -0500 > > Para: , > > Conversaci?n: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > > changes-InputRequested > > Asunto: RE: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested > > changes-InputRequested > > > > > >> Jordi > >>> De: Stephen Sprunk Responder a: > > > >>> might argue about the placement of the bar (i.e. the number of > >>> assignments), but it's hard to argue with the need for _some_ bar. > >>> We're talking about consuming global routing table slots > >> here (even if > >>> ARIN doesn't explicitly acknowledge that). We can't just > give them > >>> out to anyone who asks without _some_ justification showing > >> they have > >>> a bona fide need for such. > >> > >> Agree, routing table slots are important, but we can't go beyond > >> "ultra-conservation" artificially and against freedom of business > >> establishment. Can it be a case for a court ? I don't > think we should > >> even risk for that possibility. > > > > What does "freedom of business establishment" mean? > > > > Just so I can properly prepare, in what way do you imagine > this going > > to court? What would be the case made against ARIN? > > > > Thanks, > > > > Lee > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > 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. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml >