From iljitsch at muada.com Mon Jan 1 17:27:08 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 1 Jan 2007 17:27:08 +0100 Subject: [address-policy-wg] 2006 IPv4 Address Use Report Message-ID: <14F842D7-BEF9-4668-B5DF-12600F596CCE@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 emmiesan at msn.com Mon Jan 1 23:53:42 2007 From: emmiesan at msn.com (Tanya Hinman) Date: Mon, 1 Jan 2007 17:53:42 -0500 Subject: [address-policy-wg] RE: [ipv6-wg] 2006 IPv4 Address Use Report Message-ID: Hello all, I have been out of the IP field for a few years so forgive me if my question is about old news, but here it is: Is the decrease in the percentage of used IPv4 space in the United States of America due to other countries increasing their usage and/or the return of unused IPv4 space in the United States of America? Just looking at upcoming usage statistics globally. Thanks, Tanya Hinman, RN +1 919 272 1835 > To: ipv6-wg at ripe.net; address-policy-wg at ripe.net> From: iljitsch at muada.com> Subject: [ipv6-wg] 2006 IPv4 Address Use Report> Date: Mon, 1 Jan 2007 17:27:08 +0100> > 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> _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=wlmemailtaglinenov06 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Thu Jan 4 15:07:32 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 4 Jan 2007 15:07:32 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <995C8425-6E0F-411D-BFE9-CC0D756338B7@icann.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <20061219111827.GB1101@f17.dmitry.net> <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> <20061219124421.GC1101@f17.dmitry.net> <995C8425-6E0F-411D-BFE9-CC0D756338B7@icann.org> Message-ID: <5E8E8C23-F96B-4079-84C8-D6CCE4D30B4F@icann.org> On Dec 20, 2006, at 8:11 PM, Leo Vegoda wrote: [...] >> In my opinion AW can be auto-rised to almost match most "popular" >> assignments sizes. All further risings(lowers) can be done upon LIR >> request. If stats does not show clear peak - AW size can be aligned >> to nearest bigest value. > > I am not sure I understand what you are proposing. Are you > suggesting that all assignment approvals should trigger an AW > raise? That is, if my LIR has an AW of /23 and I receive approval > to make a /22 assignment I should automatically have my AW set at /22. I've not seen a response, but I'd like to outline why I think that a rapid series of raises is a bad idea. My concern is that AW raises should not be seen as a reward but as an extra responsibility. A rapid series of raises is likely to appear like an evidence based reward. However, a time-based change from 0 to /21 is clearly not an evidence based change and is much more likely to be viewed as a new responsibility. Emphasizing the LIR's ongoing responsibilities rather than their previous wise decisions is likely to lead to better results for everyone, I think. Regards, -- Leo Vegoda IANA Numbers Liaison From filiz at ripe.net Thu Jan 4 15:43:36 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 04 Jan 2007 15:43:36 +0100 Subject: [address-policy-wg] 2006-06 New Draft Document Published (IPv4 Maximum Allocation Period) Message-ID: <20070104144336.D4FBE2F583@herring.ripe.net> PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues, We have published a draft document for the proposal described in 2006-06. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-06.html and the draft document at: http://ripe.net/ripe/draft-documents/2006-06-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 1 February 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Thu Jan 11 15:05:34 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 11 Jan 2007 15:05:34 +0100 Subject: [address-policy-wg] 2005-08 New Draft Documents Published (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy) Message-ID: <20070111140534.333B52F583@herring.ripe.net> PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues Following the feedback received, the draft documents for the proposal described in 2005-08 are edited and published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html and the draft documents at: http://www.ripe.net/ripe/draft-documents/2005-08-56s-2.html http://www.ripe.net/ripe/draft-documents/2005-08-hd-ratio-2.html We encourage you to read the draft documents and send any comments to address-policy-wg at ripe.net before 25 January 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From Z1_zch at irost.com Tue Jan 16 14:06:48 2007 From: Z1_zch at irost.com (z.chy) Date: Tue, 16 Jan 2007 16:36:48 +0330 Subject: [address-policy-wg] Routing policy for a costomer Message-ID: <6.0.1.1.0.20070116155932.01d855d0@mail.irost.com> Dear Address working Group IN RIPE NCC Congratulation to you for new year. there are important questions about PA assignment addresses to a customer. If a customer have a black PA IPV4 addresses (f.e: /22) from one lir with specified ASN which has been routed though it,and decide to reroute it from another ASs is it possible?IN fact there are 2 situation: 1.this customer have a block of PA IPV4 from LIR1 with ASn1 and route it.Simultaneously the customer decide to reroute it from another internet provider (ASn2).Is it possible?what policies are considered to RIPE and LIR1?weather the customer need to get agreement with LIR1?HOW? 2.The customer decide to disconnect internet link from LIR1 and connect through another ASN but have preferred to hold PA addresses from LIR1 and route it from another provider and new provider has accepted to route LIR1 PA addresses.Is it possible reroute it without renumbering?and weather RIPE NCC agree to this matter ?if it need to agreement with LIR1 ,what policie are considered by LIR1 and their customer? Many thanks to explain clarify this matter. The best regards. From leo.vegoda at icann.org Wed Jan 17 11:21:30 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 17 Jan 2007 11:21:30 +0100 Subject: [address-policy-wg] Routing policy for a costomer In-Reply-To: <6.0.1.1.0.20070116155932.01d855d0@mail.irost.com> References: <6.0.1.1.0.20070116155932.01d855d0@mail.irost.com> Message-ID: <9D805EDF-07F3-4FC0-A39F-D10AD50E2014@icann.org> Hi, On Jan 16, 2007, at 2:06 PM, z.chy wrote: [...] > 1.this customer have a block of PA IPV4 from LIR1 with ASn1 and > route it.Simultaneously the customer decide to reroute it from > another internet provider (ASn2).Is it possible?what policies are > considered to RIPE and LIR1?weather the customer need to get > agreement with LIR1?HOW? > > 2.The customer decide to disconnect internet link from LIR1 and > connect through another ASN but have preferred to hold PA > addresses from LIR1 and route it from another provider and new > provider has accepted to route LIR1 PA addresses.Is it possible > reroute it without renumbering?and weather RIPE NCC agree to this > matter ?if it need to agreement with LIR1 ,what policie are > considered by LIR1 and their customer? Section nine of the IPv4 policy states that "clear contractual arrangements are recommended and are mandatory for PA space." It even gives a sample contract clause explaining that PA space needs to be renumbered if moving away from the ISP that supplied the address space. See: http://www.ripe.net/ripe/docs/ipv4-policies.html#9 Regards, -- Leo Vegoda IANA Numbers Liaison From filiz at ripe.net Wed Jan 17 12:31:47 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 17 Jan 2007 12:31:47 +0100 Subject: [address-policy-wg] 2006-02 Discussion Period extended until 14 February 2007 (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070117113147.8C7D72F583@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The text of the policy proposal 2006-02 has changed. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". We have published the new version today, as a result the discussion period for this proposal will end on 14 February 2007. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Thu Jan 18 13:44:25 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 18 Jan 2007 13:44:25 +0100 Subject: [address-policy-wg] 2006-07 Draft Document will be produced (First Raise in IPv4 Assignment Window Size) Message-ID: <20070118124425.248C32F583@herring.ripe.net> PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues The discussion period for the proposal described in 2006-07 has ended. This proposal suggests the Assignment Window (AW) available to new LIRs should automatically be raised from zero (0) to /21 (2,048 IPv4 addresses) six months after they receive their first allocation. Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4,096 IPv4 addresses). A draft document will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Tue Jan 23 11:51:57 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 23 Jan 2007 11:51:57 +0100 Subject: [address-policy-wg] 2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size) Message-ID: <20070123105157.958742F583@herring.ripe.net> PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues We have published a draft document for the proposal described in 2006-07. This proposal suggests the Assignment Window (AW) available to new LIRs should automatically be raised from zero (0) to /21 (2,048 IPv4 addresses) six months after they receive their first allocation. Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4,096 IPv4 addresses). You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-07.html and the draft document at: http://ripe.net/ripe/draft-documents/2006-07-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 20 February 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From EricS at t-com.net Tue Jan 23 13:48:25 2007 From: EricS at t-com.net (Erics) Date: Tue, 23 Jan 2007 13:48:25 +0100 Subject: [address-policy-wg] 2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size) Message-ID: <6E6739BC95294242979BDAA042E4871B01C8E443@S4DE9JSAAHY.nord.t-com.de> Hi, in general I support this proposal and this document as well, but I think we should consider one point: Due to the proposal the AW will raise automaticaly six months after the new LIR received their first allocation. This means a LIR could become a LIR, wait six month without assigning anything, and then they have the /21 AW without proving they could handel their job. I think there must be at least some RIPE-NCC approved requests before automaticaly raising the AW. My proposal is to update the draft text in chapter 7.0 like this > All new LIRs start with an AW of zero (0). > Their AW will automatically be set to a /21 (2048 addresses) six months after receiving their first allocation AND having at least five > smoothly approved requests within this six month period. > This means that all new LIRs need to request approval before making each assignment until their AW has been raised. kind regards Eric Schmidt LIR de.telekom -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at ripe.net Tue Jan 23 18:03:37 2007 From: dominic at ripe.net (Dominic Spratley) Date: Tue, 23 Jan 2007 18:03:37 +0100 Subject: [address-policy-wg] 2006-07 New Draft Document Published (FirstRaise in IPv4 Assignment Window Size) In-Reply-To: <000001c73f0f$02311960$230200c1@TEST2> References: <6E6739BC95294242979BDAA042E4871B01C8E443@S4DE9JSAAHY.nord.t-com.de> <000001c73f0f$02311960$230200c1@TEST2> Message-ID: <000101c73f10$6c8f5d70$230200c1@TEST2> Hi Eric, Just to clarify the procedure for requesting an IPv4 1st allocation: > > Hi, > > in general I support this proposal and this document as well, but I think > we > should consider one point: > > Due to the proposal the AW will raise automaticaly six months after the > new > LIR?received their first?allocation. > This means a LIR could become a LIR, wait six month without assigning > anything, and then they have the /21 AW > without proving they could handel their job. > A member must have sent in at least one PA (assignment) request before they are able to receive their first IPv4 allocation. This is usually for their own infra structure requirements. In addition, they may send a number of PA requests depending on their provisioning needs. Hope this helps Dominic Spratley Registration Services Manager RIPE NCC From jordi.palet at consulintel.es Thu Jan 25 16:41:24 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 25 Jan 2007 16:41:24 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 Message-ID: Hi all, Preparing some text for another policy proposal, I just have the chance to review again 2005-08 and I will like to raise my concerns. To make it easier to follow, I'm looking at the comparison among existing policy and the proposal at http://ripe.net/ripe/draft-documents/2005-08-56s-2.html. Section 1.1. I think is wrong to take out the reference to RFC3177. This is the current recommendation and should not be ignored and keep as guidelines and is helpful for ISPs to know about it, regardless they want to follow it or not. I also don't agree with the text "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.", but I don't agree either in the one proposed by 2005-08. The complete paragraph should be simply removed (as I suggested in a previous policy proposal and a revised one being submitted), because otherwise, we should be fair and have something similar in all the policies. All them are subject to future review if there is more (or different) experience in the future, is the principle of the PDP process. Having such text can be taken as a negative thing for new people considering deploying IPv6. 2.7. If we suggest that the minimum assignment is /64 (as I understand in other parts of the proposal), there is no point in measuring the utilization in terms of /56. Either we measure the utilization in terms of /64, or we suggest that the minimum assignment is /56. My view in any case is that it should be kept as /48. 5.2.1. Same comment as for 2.7 5.4.1. I think is a mistake to change the existing text, but if we decide to go for it, I will never suggest a minimum value of /64. End-users need to have at least a prefix that allow to have several subnets. My view is still that /48 is the right size, but definitively I will accept in the *worst* case something such as /56, but never /64 should be suggested as a minimum value. I think if we go into this direction, definitively there is a need to clearly state that the end-users have the right to request extra size if needed, without any additional justification, otherwise we are creating a big barrier for deploying IPv6 and innovation, and this in turn is a barrier for making profitable services. I know this is not our "business" but we are pushing the creation of IPv6 with NAT at this way, and this is simply stupid and in that case is better that we just stop considering IPv6 at all. 5.4.2. I've already proposed to delete this section in a previous proposal and a revised one is being submitted. Regards, Jordi ********************************************** 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 10:01:30 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 26 Jan 2007 10:01:30 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: References: Message-ID: <515CE9EC-76C0-4AF0-837B-1455492D4C3F@icann.org> Jordi, On Jan 25, 2007, at 4:41 PM, JORDI PALET MARTINEZ wrote: [...] > 5.4.1. I think is a mistake to change the existing text, but if we > decide to > go for it, I will never suggest a minimum value of /64. End-users > need to > have at least a prefix that allow to have several subnets. My view > is still > that /48 is the right size, but definitively I will accept in the > *worst* > case something such as /56, but never /64 should be suggested as a > minimum > value. I think if we go into this direction, definitively there is > a need to > clearly state that the end-users have the right to request extra > size if > needed, without any additional justification, When you say that end users should have the right to "request" extra space if needed "without any additional justification", do you actually mean that end users should have the right to *receive* extra space without any additional justification? Regards, -- Leo Vegoda IANA Numbers Liaison From jordi.palet at consulintel.es Fri Jan 26 10:04:49 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 10:04:49 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: <515CE9EC-76C0-4AF0-837B-1455492D4C3F@icann.org> Message-ID: Hi Leo, Yes, good point, that's the idea. Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Fri, 26 Jan 2007 10:01:30 +0100 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Concerns on policy proposal 2005-08 > > Jordi, > > On Jan 25, 2007, at 4:41 PM, JORDI PALET MARTINEZ wrote: > > [...] > >> 5.4.1. I think is a mistake to change the existing text, but if we >> decide to >> go for it, I will never suggest a minimum value of /64. End-users >> need to >> have at least a prefix that allow to have several subnets. My view >> is still >> that /48 is the right size, but definitively I will accept in the >> *worst* >> case something such as /56, but never /64 should be suggested as a >> minimum >> value. I think if we go into this direction, definitively there is >> a need to >> clearly state that the end-users have the right to request extra >> size if >> needed, without any additional justification, > > When you say that end users should have the right to "request" extra > space if needed "without any additional justification", do you > actually mean that end users should have the right to *receive* extra > space without any additional justification? > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > ********************************************** 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 10:29:27 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 26 Jan 2007 10:29:27 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: References: Message-ID: Hi Jordi, On Jan 26, 2007, at 10:04 AM, JORDI PALET MARTINEZ wrote: > Hi Leo, > > Yes, good point, that's the idea. Are you trying to limit the commercial freedom of ISPs to offer a range of products based around different sized networks? I remember this issue being discussed in the context of IPv4 when ripe-152, the 'Charging by Local Internet Registries' document was reviewed a couple of years ago. I seem to remember several strong statements against RIR policy regulating business models during that discussion. Is this a discussion you want to re-visit? http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html (Section F) Regards, -- Leo Vegoda IANA Numbers Liaison From dominic at ripe.net Fri Jan 26 10:55:30 2007 From: dominic at ripe.net (Dominic Spratley) Date: Fri, 26 Jan 2007 10:55:30 +0100 Subject: [address-policy-wg] [Apnic-announce] New APNIC IPv4 address ranges Message-ID: <001401c74130$1d5e6670$230200c1@TEST2> For our communities information: -------- Original Message -------- Subject: [Apnic-announce] New APNIC IPv4 address ranges Date: Thu, 18 Jan 2007 16:00:03 +1000 From: helpdesk at apnic.net Reply-To: apnic-talk at apnic.net To: apnic-announce at apnic.net Dear colleagues APNIC received the following IPv4 address blocks from IANA in Jan 2007 and will be making allocations from these ranges in the near future: 116/8 APNIC 117/8 APNIC 118/8 APNIC 119/8 APNIC 120/8 APNIC APNIC has made this announcement to enable the Internet community to update network configurations, such as routing filters, where required. Routability testing of new prefixes will commence on Friday January 19 2007. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon/debogon.html For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards Guangliang ________________________________________________________________ Guangliang Pan email: helpdesk at apnic.net Resources Services Manager sip: helpdesk at voip.apnic.net APNIC phone: +61 7 3858 3188 http://www.apnic.net/ fax: +61 7 3858 3199 ________________________________________________________________ From Woeber at CC.UniVie.ac.at Fri Jan 26 11:51:16 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 26 Jan 2007 10:51:16 +0000 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: References: Message-ID: <45B9DD24.3060707@CC.UniVie.ac.at> Leo Vegoda wrote: > Hi Jordi, > > On Jan 26, 2007, at 10:04 AM, JORDI PALET MARTINEZ wrote: > >> Hi Leo, >> >> Yes, good point, that's the idea. > > > Are you trying to limit the commercial freedom of ISPs to offer a range > of products based around different sized networks? Well, I think it is inevitabale to revisit that issue and to reopen that case. For 2 reasons: - address space was never to be "sold" to end users by "volume", it was always to be provided on an as needed basis. Address space is not an ISPs "property" to be resold for profit. There are many other (better) ways to implement commercial freedom and product differentiation. In the IPv4 world, the (marketing departments of) ISPs got away with (mis)using the scarcity argument for wiring the size of address blocks into the packages they are offering. My personal view on that: the users got used to it and the community, including the RIRs were/are tolerating this approach. - for IPv6, one of the explicit goals (architectural assumptions) was that the community should do away with the bickering, the mechanisms that support or allow IPv4-like ISP lock-in mechanisms, by *assigning* equally sized blocks (/48) to end sites because IPv6 addresses are plenty. Other than trying to limit the attractiveness of "selling" addresses, there are more reasons why a homogenous address distribution seems favourable: When moving site networks around (ISP a -> ISP b) the site would not have to re-design the subnet layout, just the LHS bits in the addresses would have to be changed. (Anyone still remembering A6 RRs to make that easy? ;-) ) Now if/when we encourage the situation that different ISPs offer different "packages", it is easy to end up in a situation where a site would be holding a say /48, but another ISP would (by default) only assign /56. Then, either the site would have to re-structure its subnet landscape or *and that's the point here* should have the right to request *and* to receive an equally sized and *contiguous* assignment from ISP b, up to the originally proposed /48. Anythig else is (again, and through the same backdoor of "conservation") just a motivation again to "sell" address space again. And to promote address translation mechanisms and products... > I remember this > issue being discussed in the context of IPv4 when ripe-152, the > 'Charging by Local Internet Registries' document was reviewed a couple > of years ago. I seem to remember several strong statements against RIR > policy regulating business models during that discussion. Is this a > discussion you want to re-visit? In the context of this proposal, I think we need to do that, otherwise we are pulling the carpet away from underneath the original architectural assumptions and recommendations for IPv6. > http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html (Section F) > > Regards, The problem(?) that I'm seeing here is that the RIPE community is made up of more ISPs than end-users and customers. So there may well be a bias to preserve the IPv4 business models for the IPv6 world. So, when you are asking "Are you trying to limit the commercial freedom of ISPs", from a communities point of view and my personal one: yes, *in this particular respect* because there are plenty of other and more appropriate mechanisms to use for product differentiation. Wilfried From jordi.palet at consulintel.es Fri Jan 26 12:39:56 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 12:39:56 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: Message-ID: Hi Leo, See below, in-line. Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Fri, 26 Jan 2007 10:29:27 +0100 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Concerns on policy proposal 2005-08 > > Hi Jordi, > > On Jan 26, 2007, at 10:04 AM, JORDI PALET MARTINEZ wrote: > >> Hi Leo, >> >> Yes, good point, that's the idea. > > Are you trying to limit the commercial freedom of ISPs to offer a Not at all > range of products based around different sized networks? I remember What I recall is that address space is not a good to be sold by the LIRs, and they don't own it. Only the real cost for the "management" should be charged, and I can tell you for sure that this is not in the order of 12 Euros per month per IPv4 address as it is being charged in Spain (I guess about the same in other countries). So the real situation with IPv4 is that this is not the case. Many ISPs actually "sell" the addresses. We need to understand that if we do the same with IPv6, we in fact kill IPv6 and there is no advantage to deploy it. The possible business with IPv6 is the fact that new services and applications can be generated and make profit from them BECAUSE: 1) there are enough IPv6 addresses 2) its provision is easier (specially if all the end-users get the same prefix, so network become "flat", such as /48 right now). 3) there is no NAT (which will be better avoid if we have 1 and 2 above) Probably we can add other things to the list, but the important point is to make sure that the addresses are there for end-users applications and services at no cost (and I'm not talking just about money, but "justification" cost). > this issue being discussed in the context of IPv4 when ripe-152, the > 'Charging by Local Internet Registries' document was reviewed a > couple of years ago. I seem to remember several strong statements > against RIR policy regulating business models during that discussion. > Is this a discussion you want to re-visit? > > http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html (Section F) > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > ********************************************** 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 12:51:02 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Jan 2007 12:51:02 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: <45B9DD24.3060707@CC.UniVie.ac.at> Message-ID: Hi Wilfried, See below, in-line. Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Fri, 26 Jan 2007 10:51:16 +0000 > Para: Leo Vegoda > CC: , "address-policy-wg at ripe.net" > > Asunto: Re: [address-policy-wg] Concerns on policy proposal 2005-08 > > Leo Vegoda wrote: > >> Hi Jordi, >> >> On Jan 26, 2007, at 10:04 AM, JORDI PALET MARTINEZ wrote: >> >>> Hi Leo, >>> >>> Yes, good point, that's the idea. >> >> >> Are you trying to limit the commercial freedom of ISPs to offer a range >> of products based around different sized networks? > > Well, I think it is inevitabale to revisit that issue and to reopen that > case. For 2 reasons: > > - address space was never to be "sold" to end users by "volume", it was > always to be provided on an as needed basis. Address space is not an > ISPs "property" to be resold for profit. There are many other (better) > ways to implement commercial freedom and product differentiation. Totally agree, see my previous email. > > In the IPv4 world, the (marketing departments of) ISPs got away with > (mis)using the scarcity argument for wiring the size of address blocks > into the packages they are offering. > > My personal view on that: the users got used to it and the community, > including the RIRs were/are tolerating this approach. And if we keep doing so, sooner or later, regulators may realize the need to take care of this and I don't think is good they come into our process. Our process work, we can always improve it, and this is one of the issues that should immediately been considered. Otherwise, we are just offering the control to the regulators/governments, sooner or later. Please, let's be smart and avoid it ! We can have much better business not based on "address selling" marketing actions and everyone will be much more happy. > > - for IPv6, one of the explicit goals (architectural assumptions) was that > the community should do away with the bickering, the mechanisms that > support or allow IPv4-like ISP lock-in mechanisms, by *assigning* equally > sized blocks (/48) to end sites because IPv6 addresses are plenty. > Other than trying to limit the attractiveness of "selling" addresses, there > are more reasons why a homogenous address distribution seems favourable: > > When moving site networks around (ISP a -> ISP b) the site would not have > to re-design the subnet layout, just the LHS bits in the addresses would > have to be changed. > (Anyone still remembering A6 RRs to make that easy? ;-) ) > Now if/when we encourage the situation that different ISPs offer different > "packages", it is easy to end up in a situation where a site would be > holding > a say /48, but another ISP would (by default) only assign /56. Then, either > the > site would have to re-structure its subnet landscape or *and that's the > point > here* should have the right to request *and* to receive an equally sized and > *contiguous* assignment from ISP b, up to the originally proposed /48. Agree ! > > Anythig else is (again, and through the same backdoor of "conservation") > just a motivation again to "sell" address space again. And to promote > address translation mechanisms and products... I agree with conservation, but definitively not with ultra-conservation, and this seems to me what we are trying to do. Not sure if is also a way to have a backdoor for selling addresses, but may be you're right ! > >> I remember this >> issue being discussed in the context of IPv4 when ripe-152, the >> 'Charging by Local Internet Registries' document was reviewed a couple >> of years ago. I seem to remember several strong statements against RIR >> policy regulating business models during that discussion. Is this a >> discussion you want to re-visit? > > In the context of this proposal, I think we need to do that, otherwise we > are pulling the carpet away from underneath the original architectural > assumptions and recommendations for IPv6. > >> http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html (Section F) >> >> Regards, > > The problem(?) that I'm seeing here is that the RIPE community is made up > of more ISPs than end-users and customers. So there may well be a bias to > preserve the IPv4 business models for the IPv6 world. How we could involve users in the process ? This will be a good point. But may be is not needed if the actual participants in the process see the point and realize that there are other business possibilities, much better than based on address selling as said before. Are we smart enough to see that and at the same time avoid intervention of regulators/governments ? > > So, when you are asking "Are you trying to limit the commercial freedom of > ISPs", from a communities point of view and my personal one: yes, *in this > particular respect* because there are plenty of other and more appropriate > mechanisms to use for product differentiation. Yes ! > > Wilfried > ********************************************** 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 14:44:46 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 26 Jan 2007 14:44:46 +0100 Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: <45B9DD24.3060707@CC.UniVie.ac.at> References: <45B9DD24.3060707@CC.UniVie.ac.at> Message-ID: On Jan 26, 2007, at 11:51 AM, Wilfried Woeber, UniVie/ACOnet wrote: [...] >> Are you trying to limit the commercial freedom of ISPs to offer a >> range >> of products based around different sized networks? > > Well, I think it is inevitabale to revisit that issue and to reopen > that > case. For 2 reasons: > > - address space was never to be "sold" to end users by "volume", it > was > always to be provided on an as needed basis. Address space is not an > ISPs "property" to be resold for profit. There are many other > (better) > ways to implement commercial freedom and product differentiation. > > In the IPv4 world, the (marketing departments of) ISPs got away with > (mis)using the scarcity argument for wiring the size of address > blocks > into the packages they are offering. > > My personal view on that: the users got used to it and the > community, > including the RIRs were/are tolerating this approach. There are more points to consider. If you have a policy that requires an LIR to always assign a /48 on any product at the request of the end user you take away the ability of the LIR to plan their utilisation rate for any network segment or their allocation overall. We need to be careful not to set up a situation where an LIR has to achieve a particular assignment density to qualify for a new allocation but cannot do this because customers are always entitled to a /48 rather than a /56. Just as importantly though, you create a policy without an enforceable appeal process or enforcement mechanism. That puts RIPE NCC staff in an untenable position where they have to implement a policy that is designed to see LIRs come back for address space very infrequently (see: 3.7) but does not give them the tools to enforce this right to always receive a /48. Regards, -- Leo Vegoda IANA Numbers Liaison From markguz at ripe.net Tue Jan 30 11:27:16 2007 From: markguz at ripe.net (Mark Guz) Date: Tue, 30 Jan 2007 11:27:16 +0100 Subject: [address-policy-wg] (no subject) Message-ID: <001e01c74459$368bacd0$3a0200c1@singel.ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, On Tuesday 6 February, between 21:00 and 23:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to BGP load balancing issues between our NikHef and Telecity peering points. If you have any questions about this, please send an e-mail to: . Regards -- Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445 http://www.ripe.net From ncc at ripe.net Tue Jan 30 15:43:02 2007 From: ncc at ripe.net (Paul Rendek) Date: Tue, 30 Jan 2007 15:43:02 +0100 Subject: [address-policy-wg] RIPE NCC Announces New Membership Discussion List Message-ID: <45BF5976.9070808@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, In response to requests from the membership, the RIPE NCC has created a members-only opt-in list where RIPE NCC members can discuss membership related issues. The new RIPE NCC Membership Discussion List (members-discuss at ripe.net) provides a useful, publicly archived way for members to discuss important membership issues. The RIPE NCC Membership Discussion List is one of several mailing lists for RIPE NCC members. For more information about these lists, including a description of the topics they cover and subscription details, go to: http://www.ripe.net/membership/lists.html RIPE NCC members can subscribe to this list through the RIPE NCC LIR Portal. Please note that an LIR login will be required. More information about setting up an LIR Portal account is available at: https://lirportal.ripe.net/lirportal/getting_started.html Regards, Paul Rendek Head of Communications RIPE NCC From ncc at ripe.net Tue Jan 30 15:43:02 2007 From: ncc at ripe.net (Paul Rendek) Date: Tue, 30 Jan 2007 15:43:02 +0100 Subject: [address-policy-wg] [ncc-announce] RIPE NCC Announces New Membership Discussion List Message-ID: <45BF5976.9070808@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, In response to requests from the membership, the RIPE NCC has created a members-only opt-in list where RIPE NCC members can discuss membership related issues. The new RIPE NCC Membership Discussion List (members-discuss at ripe.net) provides a useful, publicly archived way for members to discuss important membership issues. The RIPE NCC Membership Discussion List is one of several mailing lists for RIPE NCC members. For more information about these lists, including a description of the topics they cover and subscription details, go to: http://www.ripe.net/membership/lists.html RIPE NCC members can subscribe to this list through the RIPE NCC LIR Portal. Please note that an LIR login will be required. More information about setting up an LIR Portal account is available at: https://lirportal.ripe.net/lirportal/getting_started.html Regards, Paul Rendek Head of Communications RIPE NCC