- address-policy-wg - mailman.ripe.net

2006-06 Last Call for Comments (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 06 Feb '07

06 Feb '07

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues The proposal described in 2006-06 is now at its Concluding Phase. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-06.html and the draft RIPE Document at: http://ripe.net/ripe/draft-documents/2006-06-draft.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 6 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

RIPE NCC Announces New Membership Discussion List
by Paul Rendek 30 Jan '07

30 Jan '07

[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(a)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

1 0

(no subject)
by Mark Guz 30 Jan '07

30 Jan '07

[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: <ops(a)ripe.net>. 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

1 0

[Apnic-announce] New APNIC IPv4 address ranges
by Dominic Spratley 26 Jan '07

26 Jan '07

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(a)apnic.net Reply-To: apnic-talk(a)apnic.net To: apnic-announce(a)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(a)apnic.net Resources Services Manager sip: helpdesk(a)voip.apnic.net APNIC phone: +61 7 3858 3188 http://www.apnic.net/ fax: +61 7 3858 3199 ________________________________________________________________

1 0

RE: [address-policy-wg] 2006-07 New Draft Document Published (FirstRaise in IPv4 Assignment Window Size)
by Dominic Spratley 23 Jan '07

23 Jan '07

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

1 0

2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size)
by Erics 23 Jan '07

23 Jan '07

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

1 0

2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size)
by Filiz Yilmaz 23 Jan '07

23 Jan '07

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(a)ripe.net before 20 February 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2006-07 Draft Document will be produced (First Raise in IPv4 Assignment Window Size)
by Filiz Yilmaz 18 Jan '07

18 Jan '07

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

1 0

2006-02 Discussion Period extended until 14 February 2007 (IPv6 Address Allocation and Assignment Policy)
by Filiz Yilmaz 17 Jan '07

17 Jan '07

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 <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Routing policy for a costomer
by z.chy 17 Jan '07

17 Jan '07

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.

2 1

2005-08 New Draft Documents Published (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy)
by Filiz Yilmaz 11 Jan '07

11 Jan '07

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(a)ripe.net before 25 January 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2006-06 New Draft Document Published (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 04 Jan '07

04 Jan '07

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(a)ripe.net before 1 February 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size)
by Filiz Yilmaz 04 Jan '07

04 Jan '07

PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues The text of the policy proposal 2006-07 has changed. We have published the new version today, as a result the discussion period for this proposal will end on 17 January 2007. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

14 22

RE: [ipv6-wg] 2006 IPv4 Address Use Report
by Tanya Hinman 01 Jan '07

01 Jan '07

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(a)ripe.net; address-policy-wg(a)ripe.net> From: iljitsch(a)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=…

1 0

2006 IPv4 Address Use Report
by Iljitsch van Beijnum 01 Jan '07

01 Jan '07

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

1 0

32-bit AS Number Requests
by Dominic Spratley - Registration Services Manager 28 Dec '06

28 Dec '06

[Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce that from 1 January 2007 we will accept requests for 4-byte (32-bit) AS Numbers. The request form and supporting notes are available in the RIPE Document Store at: http://www.ripe.net/ripe/docs/asnrequestform.html http://www.ripe.net/ripe/docs/asnsupport.html Assignments will come from the following range: 3.0 - 3.1023 ASN32 objects will appear in the RIPE Database from 1 January 2007. Their format is different from the current 16-bit ASNs. The new format is described in these documents: http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representatio… http://www.ietf.org/internet-drafts/draft-uijterwaal-rpsl-4byteas-ext-01.txt The introduction of 32-bit AS Numbers may have an effect on tools that query the RIPE Database or those based on RPSL. Kind Regards, Dominic Spratley Registration Services Manager RIPE NCC

1 0

Re: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size)
by Erics 15 Dec '06

15 Dec '06

Hi, incentive and AW is a very bad combination. The AW should reflex the LIRs address requirement, and it must not be an incentive ! Hi Ingrid ;-) All in all I support the proposal to raise the AW automatically from 0 to /21 within six month. kind regards Eric Schmidt Deutsche Telekom AG T-Com Headquarters Network Information Center

1 0

Map of the Internet
by Shane Kerr 13 Dec '06

13 Dec '06

All, You've probably already seen it, but I thought it was cool enough to spam the list: http://xkcd.com/c195.html -- Shane

2 1

Re: [address-policy-wg] Allocation vs assignment question
by Makc The Great 04 Dec '06

04 Dec '06

So, overall consensus here is like this: On 12/4/06, Amar <amar(a)telia.net> wrote: > > Ergo: There has not to be any connection between > subnets for each assignment. It is done > based on the proven need and not on a > physical connection between the requesters > networks. > Could you please explain then what does "Sub-allocations are intended to aid the goal of routing aggregation" phrase means in english?

2 2

Allocation vs assignment question
by Makc The Great 04 Dec '06

04 Dec '06

Hello all, I have posted similar question at https://www.ripe.net/ripe/maillists/archives/db-help/2006/msg00040.html but I think that was not appropriate list, and I'm still not sure which is. My question is am I correct in assuming that all "assigned" IPs are on same physical network that all other IPs in their "sub-allocation" range? For example, here inetnum: 217.77.240.0 - 217.77.255.255 org: ORG-SW1-RIPE netname: DE-SAP-20001221 descr: SAP-AG Walldorf descr: ENTERPRISE country: DE status: ALLOCATED PA inetnum: 217.77.254.28 - 217.77.254.28 netname: SAP-JCrewGroupInc-US-i8 descr: J. Crew Group Inc. descr: US 770 Broadway, 14th Floor descr: Remote connection to SAP country: US status: ASSIGNED PA inetnum: 217.77.254.30 - 217.77.254.30 netname: SAP-AlumaFormDixieElectrical-US-i8 descr: Aluma-Form/Dixie Electrical descr: US 3625 Old Getwell Road descr: Remote connection to SAP country: US status: ASSIGNED PA are 217.77.254.28 and 217.77.254.30 still on german network, or are they physically located in US and connected to germany over some sort of intercontinental cable? Thanks, Max.

3 4

2006-06 Discussion Period extended until 27 December 2006 (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 30 Nov '06

30 Nov '06

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues, The Discussion Phase for the proposal 2006-06 has been extended until 27 December 2006. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html During RIPE 53, the RIPE NCC was asked to analyse the possible impact of this proposal on address consumption and fragmentation. This analysis has been done and can be found at the URL above. We encourage you to review this policy proposal and send your comments to address-policy-wg(a)ripe.net. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

RIPE 53 Meeting Report and Plenary Minutes available
by Paul Rendek 29 Nov '06

29 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE 53 Meeting Report is available at: http://www.ripe.net/ripe/meetings/ripe-53/report.html The RIPE 53 Plenary Minutes are available at: http://www.ripe.net/ripe/meetings/ripe-53/minutes/plenary.html Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

RIPE 53 AP WG minutes (draft)
by Gert Doering 23 Nov '06

23 Nov '06

Hi fellow Working Group members, below you'll find the draft working group minutes from the R53 meeting in Amsterdam. Please send in your comments, if you think something is not fully accurate... Thanks a lot to Rabia Gawish from the NCC for scribing. Gert Doering, AP WG Chair ----------------------------------------------------------------- Address Policy Working Group Minutes from RIPE 53 Version 1.0 WG Chair: Hans Petter Holen Scribe: Rabia Gawish Amsterdam, Thursday 5 October 2006 14:00 - 15:30 A: Administrative Matters =========================== - Welcome - Scribe - Agenda Finalised. - Minutes from RIPE 52 approved: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html - Point people to mailing list - address-policy-wg(a)ripe.net Action on attendees to subscribe to the mailing list. B. Elect a New Address Policy Working Group Chair and Co-Chair(s) ================================================================= Hans-Petter Holen (Visma IT) proposed to step down as Working Group Chair (and become a co-chair) due to high work load and too little spare time. Volunteers for these positions would be very welcome. No one came forward. Hans-Petter Holen asked Gert Doering if he was willing to step up as Working Group Chair? Gert Doering (SpaceNet AG) stated that he has been busy with RIPE for the last 7 to 8 years. Since he has been Co-Chair for the last year, he is willing to take over as Chair. He also thanked Hans-Petter for all the work he did for the working group over the last year. And if the WG is willing to have him as Chair then he will volunteer to be the Chair. Andrea Borgato, our Co-Chair, seems to have fallen off the net for a while. Andrea Borgato (Network Service Consulting) stated that he has indeed fallen off the net. He has changed jobs 3 times in the last five month. He has tried to spend some time on his commitment to the WG but has been having problems. Over the last two months he has been reloading himself and have exchanged some opinions with the Chair and Co-Chair. Andrea has decided to continue with his commitment as Co-Chair. Hans-Petter Holen concluded that Gert Doering is now the Chair and Andrea Borgato and himself will continue as co-Chair until the working group finds someone else to replace Hans-Petter Holen. C. Ongoing/Current Address Policy Proposals in the RIPE Region =========================================================== - Accepted Proposals: --------------------- 2005-02 - IP Assignments for anycasting DNS (Accepted) 2005-12 - 4-byte AS Number Policy (Accepted) - Open IPv6 proposals: ---------------------- 2005-08 - Amend IPv6 Assignment and Utilisation Requirement http://www.ripe.net/ripe/policies/proposals/2005-08.html 2006-02 - IPv6 Address Allocation and Assignment Policy http://www.ripe.net/ripe/policies/proposals/2006-02.html Hans-Petter Holen asked the group where they want to go with IPv6? Do they want to look at other regions and see what they have done? They also need to align the p roposal texts. Leo Vegoda (RIPE NCC) expressed concern regarding the policy proposal 2006-02 for point C and how the community wants RIPE NCC to implement what a "reasonable" number is. It has to be plural, so is it a minimum of 2 /48s? RIPE NCC will be delegated to choose the "reasonable" number, but how does the community want RIPE NCC to do that? Hans-Petter Holen thought that there would be a check box in the request form asking the requester if they were going to have a reasonable number of customers, and all that is needed is for this to be checked and the requester would qualify. Leo Vegoda expressed that this would make it very easy to implement for the RIPE NCC. Jordi Palet Martinez (Consulintel) stated that he was going to suggest something similar to what Hans-Petter just did, but would rather ask the other regions that have already taken out the 200 /48 requirement (AfriNIC or LACNIC) and ask them how they evaluate their requests? Iljitsch van Beijnum (RunningIPv6.net) suggested that if we set a rule then it should be a clear one. So either put a number in C (something measurable) or it should be removed all together. Ricardo Patara (LACNIC) stated that LACNIC changed their policy with no numbers, but they have restrictions on the time frame in which the prefix allocated is used which is 1 yea. They also have 2 years set for running services using the IPv6 space. Minimum allocation size is /32 and customers' request get minimum allocation. If they need more they need to provide plans to use this. ?What they also check is the number of services they have and the number of users they have. Ernest Byaruhanga (AfriNIC) stated that they evaluate it the same way as LACNIC. Bernard Tuy (RENATER) is not comfortable with point C. It seems to come to a matter of trusting LIRs or not. Because the LIRs are the ones that are going to request this, so what are is the WG trying to do? Hans-Petter Holen adds that what AfriNIC and LACNIC do is set a requirement for the LIR to announce the prefix in a certain period of time, and that they actually provide services using IPv6 and have enabled their DNS for IPv6 web services and thus within the first year they are already having some customers. Gert Doering states that the community trust the RIPE NCC, but the it needs to put up rules that reflect the consensus reached, which is what the community wants. The RIPE NCC then implement the policy that the community puts in place. As for the specific wording "reasonable number of customers" it is a tricky one indeed and the community needs to rethink it. Another issue is in the proposal for the removal of the 200 /48 assignments needs more discussion, because there has been no consensus reached on this one. Regarding the IPv6 policy change proposals, Gert noticed in the proposal from Geoff, which was to remove the fixed size /48 assignments, that the working group is not very careful in spotting the results, it doesn't matter the size of the assignments, because the LIR should decide how much he wants to give to the end sites. This is also another thing that the community needs to rewrite and express exactly what the community wants. Jordi Palet, understands the fear of removing the 200 limit because it could generate an explosion in demand, but to look at what happened in the other regions that have implemented this, they have had a decline in requesting IPv6 allocations. He doesn't believe that it will change the situation, but will provide access to prefix to small ISPs which can have a few big customers, and why are they not allowed to get IPv6 resources? Hans-Petter Holen clarifies that there is no objection is to the way we are changing the fixed number, but the objection is making the change in this particular way. Are the proposals in other regions more specific? Ricardo Patara states that the policies in their region, LACNIC, are not specific and it is up to the hostmaster's evaluation. Max Tulyev (NetAssist LLC) explained that in a real situation, Ukrainean small ISP (small) can not find any upstream provider (LIR) in Ukraine that will provide them with IPv6 because none of them will qualify under the current policy of 200 /48 as minimum requirement. So good practice, for this situation, is to remove it totally. If one client of the LIR needs IPv6, then give the LIR an IPv6 allocation. Hans-Petter Holen concludes that the text of this proposal has to be changed so we will discuss this further with Jordi Palet Martinez and then bring it back to the mailing lists. Geoff Huston (APNIC) stated that one thing they did strike, in APNIC, is precisely the issue of comparing the two proposals 2005-08 and 2006-02, down in slide 13, that they actually have now the idea that end-site are an LIR decision but also in the APNIC policy they have /48 in another place. ?Geoff believes that Jordi might want to consider what an end-site is, thus replacing /48 with end-site, so this would reflect whatever an end-site is, other than a /48. ?This way, the end-sites can be looked at as such and not as /48s. This will give freedom to LIR for the size of the end-site. Hans-Petter Holen finds this a very good point, as two proposals are attacking the same text. Wilfried Woeber (ACOnet, DB WG Chair and NRO NC) wanted to make the same comments and he believes that all three proposals need some serious reworking. These two policies end up mixing things that are not really related to each other. There is no real relationship between the HD ratio on one end and offering the freedom to justify a /48, there should be no aggreement to different aspects of the proposal. Geoff Huston stated that the intention of 2005-08 is to define what full is when and LIR comes for more space. HD094 is not enough, this is to say 094 of what? Gert Doering agrees that this is the part that is not yet clear Geoff Huston stated that in APNIC there was a different proposal, first proposal was to remove the /48 as a fixed point but then how do you figure out what full is, because we do not use consistent end-sites? If we say 80% of the /32 means 80% of the space. If you take away the fixed end-site, how will you count what full is? What is the HD ratio going to be applied to? We will apply it to a /56...what does a used allocation really means? How do you do the mathematics to say it is over the threshold? Hans-Petter Holen stated that the working group has spent quite a while discussing this proposal. ?Geoff Huston made a presentation, in 2005, before this was finalised, more than a year ago, where there was concern with the allocation requirement and additional allocation requirement. What we agreed then was that we had to change this quite fast before we burn this too quickly. He then also asked the room if anyone here was not in favour of changing the HD ratio in order to conserve IPv6? Only one against it. A lot in favour. Then for those who don't care, Hans-Petter asked why. Unidentified person feels that the WG has wasted so much time discussing this. There is plenty of IPv6 space so let's take this to the final call and move on with the other policy proposals. Hans-Petter Holen concluded that he will consult with those who sent in the proposals to change the text and then reach the last call. 2006-01 - Provider Independent (PI) IPv6 Assignments for End Users http://www.ripe.net/ripe/policies/proposals/2006-01.html Hans-Petter Holen asked "do we want PI IPv6?" Max Tulyev showed interest in PI IPv6 and that it must be implemented for a maximum of 3 years per assignment. It might also be cheaper or free for 1 - 2 years. As for experimental hosting, if they will only do internet content and there will be a reason to connect to IPv6 network then get IPv6 space. This way it is much cheaper and permanent. Jordi Palet Martinez clarified that the temporary assignment is not for the max of 3 years, but 3 years after the community has reached an agreement for using those assignments for alternative technical solutions. The second thing is that in all the other regions IPv4 PI customers are charged and have a contractual relationship with the RIR. This is failing in the RIPE region because we have almost 50% of the delegations being PI and there are no contractual relationships between the actual user and RIPE NCC and this will affect the billing category of the LIR (membership), so this needs to be corrected. Max Tulyev disagrees with the trial period of 3 years, because for the renumbering of 10000 of domains when changing providers. ?They need to do periodic charging for this space because people stop using it or they are out of business or the network changes and they forget about it and this space is not returned to RIPE NCC and there is yearly billing. Gert Doering agreed that having a contract between PI holder and RIPE NCC is a good thing, because RIPE is different from the other reasons, but this will be discussed further at the end of this WG in the PI for IPv4 slot. Something else to be aware of is assigning /32s to PI holders, why do other regions use /48 for PI holders, why would a PI holder get the same space as an LIR and not as an end-site? Unidentified speaker agrees with Gert, if we are to allocate resources to non LIRs, then we will be changing the RIPE NCC activities on the long term and this needs to be thought threw. Hans-Petter Holen then concluded continuing this discussion on the mailing list. 2005-08: clarification on text and move to next call: 2006-01: back mailing list 2006-02, will review with Jordi for changes. New IPv4 Proposals: ------------------- 2006-04 - Contact e-mail Address Requirements Hans-Petter Holen summarised this proposal that everybody should have email addresses (active ones) that they register in the RIPE DB as the contact for each object/resource registered. Max Tulvey agrees with this, but asks what should happen if people do not do this? Hans-Petter Holen asked if we require all customers to have their own abuse addresses or do we use the providers? Max Tulvey asks again what will happen if people do not do that? Hans-Petter Holen then suggests that they can then not make allocation because this field is mandatory. Max Tulvey then stats that it needs to be made clear that if they do not do that, then RIPE NCC will do that. Hans-Petter Holen asked if RIPE NCC should revoke assignments if the email address is not working? Gert Doering then stated that if you do not answer your email (mentioned in RIPE DB) then you should not have this address. Hans-Petter Holen asked RIPE NCC how they would implement this. Leo Vegoda (RIPE NCC) informed the WG that this is also being discussed on the anti spam WG, and that it is not a good thing to define a working contact email address. ?If RIPE NCC can send an email to this address then it is considered to be working. Because with the 4 thousand members it will require too much human power to check them manually, thus becoming more expensive for the members. Hans-Petter Holen explained that the next level would be to make the abuse attribute mandatory on the RIPE DB objects. The highest level would be for the RIPE NCC staff to chase those who do not reply to their emails, but this is not what we want to propose to the RIPE NCC. Rob Blokzijl (RIPE Chair) said that it is an example of good intentions and bad consequences, but if the proposer intends to facilitate fighting against vaguely defined abuse, if i were an ISP and confronted with this I would think "what a bunch of silly people:" I'll set up procmail and fill in this mandatory field, but it doesn't seem to be a proper way to do this. Again, this is a rule that can not be enforced on our poor RIPE NCC . Wilfried Woeber: Rob said it all, am I allowed to put president(a)ukraine.su? Hans-Petter Holen will feedback this to the one who proposed this and see where we go from there. 2006-05 - (IPv4) PI Assignment Size Hans-Petter Holen gave background is when you request pi now you only get the ones you asked for and are going to use, even if less than /24. Proposal here is that if there is a routing issue then it should be 2 /24s instead. Wilfried Woeber: has a very basic problem with installing a minimum assignment size on a particular policy and not having a minimum size for another policy, this creates an unbalanced situation where we have to bother our customers applying for /25 or /26. Routing problems or any interaction with routing should not have any impact on the minimum assignment for IP address blocks. Iljitsch van Beijnum stated that that would be insane as having the minimum physical requirements for routing that would cost more money interact with the nice game of giving out prefixes, we should be able to do that in any way we want and those that need buy bigger routers if they can't handle it. Lars-Johan Liman (NETNOD) to have an address allocation policy that refuses to involve itself with any degree in the current practises on the Internet is probably not a good idea. The world doesn't work like that. Ger Doering, wants to agree, but traditionally the point of view in the AP WG is that we get involved into what is routable and what is not, but it seems that this leads to people lying to the RIPE NCC when requesting PI space to get a /24 to get a routable block or do we want a policy that reflects people's needs. And this goes hand in hand with the generic PI restructuring. Lars-Johan Liman said that the obvious is true, the routing operational people can not instate operational practises that totally step away from the address allocation policies and that there must be a middle ground, so this is not a one-sided problem. Max Tulyev when somebody asks to lie to RIPE NCC and ask for more space for routing reasons, but there is a lot of space that is less than a /24 that can actually be used maybe we should not speak about minimum assignment size /24 but change that rule that we do not have to ask the RIPE NCC for more address space for routing reasons excluding this situation, but for globally routable PI. Sander Steffann (Computel Standby BV) feels that this is going in circles, ?you hand out assignments and people don't want to accept them so they do not to accept it so they start to filter at /24 level and then people ask for bigger assignments....and it goes on and on until they become LIR. Max Tuley believe it is technically impossible to filter /23 now because you will loose connectivity with a large part of the internet so some ISPs will come and beat you the /24 has no problems with the global routing table, but the ;/25 has problems, which is why lots of people go for requesting a /24 Hans-Petter Holen decided to take this back to the mailing list. 2006-06 - IPv4 Maximum Allocation Period (misleading title) Axel Pawlik (RIPE NCC) said that looking forward we see that on the afternoon of 18th of July 2012 we are going to run out of IPv4 addresses at RIR level, Geoff Huston says so. What will happen then? Axel doesn't believe that anybody will start a war but he would like all the ISPs, LIRs and RIRs to harmonise the time for which allocations are made to LIRs. There was a remark made regarding conservation of addresses, but this is not the intention of this proposal. The idea is to harmonise the policies where possible. Hans-Petter Holen stated that there are two issues raised here 1) Harmonisation of address policies across the regions, which is probably something that the working group should start looking into in a more systematic way, why are they working different? 2) We need to start planning for 2012, or whenever that is to prevent the war. We still have time to figure out what to do when we get there. Iljitsch van Beijnum asked if the idea behind that policy would be that we not have unnecessarily large numbers of prefix in the routing tables? Axel Pawlik explains that the idea behind this policy is that it would be really ugly if one region of the world is sitting on piles of address space and the others are run dry. Iljitsch van Beijnum but wouldn't that happen if you give them space for a long time. If you look at the big chunks of space they are with the telecom companies (with telecom in their n name), they should get smaller blocks and if they project that they are going to use those addresses then they can get more space. ?Also the impact of this on the routing table is zero. Rob Blokzijl made a remark that global harmonisation of policies is nice, but it is not a goal, we should realise that there are different regions in the world with different economies and their problems are solved with different rules, based on real regional needs. We should not do harmonisation for harmonisation's sake, where possible yes, but there is a reason why we now have 5 different RIRs. Hans-Petter Holen challenged Rob Blokzij's statement and asked why it is 3 months in LACNIC 6 in the US and one year in APNIC and 2 years in AFRICA and Europe? What is the similarity between Africa and Europe and what is the similarly between LACNIC and ARIN especially requiring LACNIC to have a much shorter planning period? Rob Blokzijl stated that they all came from the same source. Geoff Huston clarifies that they may have come from the same source but they certainly have variation in outcomes and certainly some studies on this are quite interesting. Currently in IPv4 over the last year and a half RIPE NCC allocates about 35% of the IPv4 space that is allocated from the system, APNIC allocates around 30% and ARIN allocates around 25%. This doesn't correlate precisely to those differing periods but Geoff has a suspicion that they are related and he is going to do some work going through the files to see if there is a correlation between the relative consumption rates and the LIR allocation expected life times. Hans-Petter Holen stated that when working for his second LIR he was asked to prepare a budget for a year and I was shocked as he couldn't see how he could plan for 12 months, as his planning horizon is 3 months or less. At the same time he went to RIPE NCC with the 2 year plan to get the IP addresses. His final question was to the crowd "can you trust those figures from me when i can't make my financial budget for more than 3 months?" Ricardo Patara gave an update that LACNIC has just approved a different time frame for the additional allocation of 12 months. Hans-Petter Holen concludes that the address policy working group needs a bit more time to discuss this. He also stated that there is a possibility that we need a study to see the reason behind those differences. He also stated that maybe we should change this for the sake of an experiment to it's effect on the consumption rate. Hans-Petter suggested that we try this out for a year Geoff Huston stated that you do not need to change the policy in order to understand what it's effects are. You actually have a rich enough database right now of what you've done so you can simulate this quite easily. Hans-Petter Holen suggests asking the RIPE NCC to simulate this as what would have happened last year if this policy had been in place. Geoff Huston agrees that this is a reasonable request. ACTION ON RIPE NCC: Using the information in the RIPE Database, simulate the scenario with this policy in place over the last year. 2006-07 - Minimum IPv4 Assignment Window Leo Vegoda (RIPE NCC) presentation: Minimum IPv4 Assignment Window http://www.ripe.net/ripe/meetings/ripe-53/presentations/ipv4_assign_size.pdf Gert Doering is not feeling very happy about this proposal, he is not opposing it, but as a member of the group he sees some problems, yes you have spent quite an enormous effort on training, those that have been interested in the policies they would have read up about them over the last 10 years, so having lots of good training doesn't help, can't be bothered to send someone on a training course, nor that an LIR has enough people/time to send people to those trainings. The other thing is that you say that they might not be able to get a new allocation; the question is who is hurt by that? In the end, this will hurt the end-site. New customers standing in queue to get address space but they can't get any because the LIR hasn't done the proper administration. ?This can hurt the customer-LIR relationship. Gert would aim for a compromise, like start with a /24 and then move the AW up, but starting with a /21 for someone that hasn't demonstrated to have an understanding of anything, it is not correct. Iljitsch van Beijnum asks what are the statistics for the 2nd opinion requests? Leo Vegoda refers them to printed handout on the handouts desk, there is a distribution chart for all the recent kinds of requests that we get. But two thirds of the requests that we get are 2nd opinion. Iljitsch van Beijnum explains that when you get a 2nd opinion request you get: - no way never - sure no problem - no, we need more information: He then asks Leo how many of those replies are "sure no problem, go ahead" Leo Vegoda informs that he can produce statistics on that to check. Iljitsch van Beijnum then suggested that if it is 99 % then it would be no problem for this proposal. Iljitsch van Beijnum also asked why we don?t keep the minimum at 0 and increase when needed. Because with this proposal if you have a repeating offender then you can not take away the AW, like you can now. Leo Vegoda explained that they do have a system for regularly looking at the AW's of all the LIRs that send in requests and raising their assignment windows. The key thing they wanted to do was to be upfront and honest, they can go and change our practice to dramatically increase the rate at which AWs are raised, but if they give the LIRs the AW standard. Leo would also be more concerned if they raised the AWs faster than if there was a default minimum. Because when saying that the AW is zero, /24,/22,/20...etc then they are giving positive reinforcement to someone and saying that they are doing something good. But if this is done to an LIR after just sending in two requests, then they are going to be shifted very fast and will be given a false confidence that they know what they are doing, whereas if you say" you have this responsibility, use it wisely" they would be more careful and more responsible. Iljitsch van Beijnum clarified that Leo would be doing just like Gert said, as in throwing them into the deep end and seeing if they can swim. This would be pushing out the problem to the LIRs. Leo Vegoda states that this is not driven by workload, I do think that you raised a good point that if you give someone the freedom to hang themselves and they made loads of assignments, and they have done it all wrong, then it would be painful for them and their customer base. However, RIPE does approve Axel's proposal, for 1 year allocations, then people would have less address space to damage themselves, thus the impact reduced. Iljitsch van Beijnum asked what would happen to the end-user if the LIR really screwed up and gave way too much space, would they have to give it back or would they be able to keep it? What would happen then? Hans-Petter Holen summarises that there are two opposite views, like we had with the Audits, and we introduced assignment windows for a reason. Now the situation has changed. We also need to look at what happens with the 0 AW, because with his colleagues in his previous job, they went and assigned space and didn't request it and had to do a huge clean up when they needed more space. The key here is that we need to find the right balance, so we need to take this to the mailing list. Action point on RIPE NCC is to get stats on the 2nd opinion requests for the "sure go ahead" advice. D. Update on Global IANA/ICANN Policies ======================================= IPv6 ICANN to RIR Distribution Policy Update E. Ongoing Policy Work in Other Regions Presentation in the Plenary Plus discussion time in the working group slot Two things where done: 1) When the policy was passed from the LIRs the address council reviewed whether the policies had been followed in all the regions 2) Upon request from the ICANN Board we gave them some advice on the aspects of this policy and based on that, and the advice of other supporting organisations, the ICANN Board then gratified this process. The other outcome that could have been of this was that if the ICANN Board hadn't gratified this then they would have send it back around through all the regions. which they didn't. With this Hans-Petter thanked the two Board Members that we have with us here for their contributions with this. The practical aspect here is that the /12 allocations have been requested and received by the RIRs, so it is now in operation. Z. AOB ====== -PI --- Hans-Petter Holen asked "Should there be a contractual relationship the end-user and RIPE NCC? And, should an end-user get pi via the LIR or should they get it directly from the RIPE NCC? If the later is agreed to then this is a matter for the RIPE NCC Board to device a fee structure for that. Gert Doering stated that the RIPE NCC is allocating more chunks of pi than they are of pa space, even though this doesn't have a big impact on the numbers that are being used, but there is a large impact on the routing system. PI seems to be easy and convenient to get while PA is costly and harder to get. Thus there is a big imbalance. The RIPE NCC is also working on the certification stuff and if they are to give a certificate that this address space is yours for the next two years, it is helpful to know who you are. Gert feels that it would be useful to have a relation between the pi holder and the RIPE NCC for the distribution part. Gert also stated that we as a WG do not decide the fees and the RIPE NCC general membership do not decide on the policies. The idea it to have two ways of getting PI space either via an LIR (LIR has to stand up for it and pay for it and pay yearly for it) and if the customer moves to another ISP the PI has to move with the customer. If there is no LIR standing up to make sure that the information of the customer is correct, the end-site holder can have a contract with the RIPE NCC and get an address certificate for the space and they will also pay RIPE NCC for that. The fee should not be a high amount, but some basic service fee, like Euro 200 is not a seriously big amount for someone who is doing networking. Leo Vegoda pointed out that the RIPE NCC has a stewardship responsibility with regards to the address space. At the moment RIPE NCC is currently assigning space directly to the end user but have absolutely no communication with the end-user, which is the business processed agreed to by the community. Max Tulyev stat that there is an established process, where LIR contacts and works with the end-user and the end-user continues to use the space, LIR makes sure that the end-customers are using the address space by contacting them by email and making sure they are paying their bills. Because there are too many different cultures and tax laws all over Europe, it would be more comfortable for the end-users to deal with local people and local ISPs. Gert Doering agrees, but what happens if the end-user leave you (as an LIR) and goes to another LIR? Gert doesn't want to deal with their PI business, and wants to have another method for the contacts. Max Tulyev stated that PI space issues are not related to the connectivity services they provide, there is no relation. Changing connectivity is not a reason to change the LIR responsible for this PI block. Gert Doering asks what would then happen in an extreme case like the LIR goes out of business. In this case there is no one in contact with the PI holder nor do we know if the address space is still in use. Max Tulyev suggests that we have another policy for when the PI block should change LIRs. For the end-user need to know what happens then and how it should happen. Rob Blokzijl sees that we need some form of established relationship between the holder of the pi space with RIPE NCC, whether direct or indirect, via a cooperating LIR. Secondly, if this whole the certification system comes into place and everyone is using it, then this might be a very attractive tool in formalising this relationship, including the moving of PI holder from one LIR to another and when loosing an LIR. Because the need for a certificate will still be there. This will also give us the incentive of keeping in touch with somebody. Hans-Petter Holen concludes that we will need a final policy proposal on the mailing list. We already have a volunteer. Announcement: -------------------- Filiz Yilmaz (RIPE NCC) stated that there have been requests and feedback on the impact of some of the policy proposals discussed here today, also during the plenary session. Filiz said that they have been thinking about this and now they are in the planning phase of this work, soon they will be putting some additional work for when a proposal comes in to let the community know if there is an impact at that moment. They are thinking of doing that on the review phase level when questions are a bit more mature. Hans-Petter Holen extended the Thank You to Filiz Yilmaz from the RIPE NCC, for preparing this presentation and supporting all the working group chairs with preparing different proposals. Filiz has also agreed to give a presentation in the plenary session on Thursday and join in discussions about individual proposals in the working group session. Filiz Yilmaz acknowledged the Communications Department's help with the proposals and they got an applause too. -------------------------------------------------------------------------

2 1

2006-04 New Draft Document Published (Contact e-mail Address Requirements)
by Erics 20 Nov '06

20 Nov '06

Hi Community, I´m a bit surprised to read a draft document for this proposal. If I recall the informations I got from RIPE-53 meeting - unfortunately I couldn´t be there myself - the discussion regarding the proposal 2006-04 endet with "not practicable". And this is exactly what I think about this. For bigger LIRs it is not possible to provide an e-mail address, unless this address could be the "notification-" or "changed-" address, which appears in each inetnum object anyway. If this is ment, this should appear clearer in the draft document. BTW: I´m missing the RIPE-53 address-policy-wg-minutes kind regards Eric Schmidt _________________________________________ Deutsche Telekom AG T-Com Headquarters Network Information Center Ammerlaender Heerstr. 138, D-26129 Oldenburg +49 441 234 - 4592 (phone) +49 441 234 - 4589 (fax) E-Mail: EricS(a)t-com.net <http://www.t-com.net/> http://www.t-com.net

1 0

SPAM filtering at RIPE NCC
by Brian Riddle 16 Nov '06

16 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, Today, we implemented measures to combat spam on our mail servers. The measures will apply to both e-mails sent to RIPE NCC mailboxes and the mailing lists hosted on ripe.net. These measures will lead to short delivery delays for some of your e-mails to us and to the mailing lists. Regards, Brian Riddle IT Manager RIPE NCC

1 0