October 2003 - address-policy-wg

FORMAL PROPOSAL: change of initial PA allocation size
by Gert Doering 23 Dec '03

23 Dec '03

Hi, this was discussed on the list before the last RIPE meeting, and we had it on the address policy working group meeting (presented by me). I think we mostly have consensus on this issue, but I want to present it as a formal proposal, before it's incorporated into the policy. PROPOSAL: * the minimum initial allocation size (for new LIRs) is reduced from a /20, as of today, to a /21. (If a new LIR can demonstrate need for a bigger initial allocation, they can get a larger address block. This will not be changed). * the requirement to show an immediate need for 25% of the allocated address space is removed for the "minimum initial allocation" The motivation for that is that under the current policy, startup LIRs that do not already hold address space cannot get an initial PA allocation (which would be a /20 as of today, or bigger), because in many cases, they cannot demonstrate immediate need, or prior utilization of sufficient address space. To work around this, many startup LIRs use PI address space as a start, and when they have filled enough of this, apply for their own PA again. The problem with this is that in the end, it's very likely that more than one route will end up in the global BGP table (where one PA route would be sufficient), and also it encourages lying to the RIRs (PI space must not be distributed to third parties, i.e., LIR customers). The drawback of the changes are that it's potentially wasting address space for "very small LIRs" (that would be happy with a /23 PI space and will now get a "huge" /21). The wastage would only happen for very small LIRs that will never grow to fill the initial /21. A rough calculation shows that "1000 new LIR /21 allocations" would need a /11, which is not an unbearable strain on the conservation side, judging from the total number of LIRs in RIPE land today. A second drawback of this is that people may need to adapt their BGP filters to permit /21s from the network block(s) where these allocations are made from. So the RIPE NCC needs to document this accordingly, and ideally, well in advance. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57785 (56883) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

4 6

IANA Policies for Allocation of IPv4 Blocks to RIRs
by Axel Pawlik 15 Dec '03

15 Dec '03

Dear Colleagues, The Regional Internet Registries (RIRs) have been working together with the Internet Assigned Numbers Authority (IANA) on a policy for the allocation of IPv4 address space to the RIRs. The proposed policy was presented to the RIPE Address Policy Working Group at RIPE 46 in September. The presentation can be found at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-ap-iana-rir/ Following discussion in all four RIR regions, this policy proposal and discussion results will be forwarded to the ICANN ASO Address Council for review and submission to the ICANN Board. It is considered a global policy proposal. Please review the document "Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries". The document can be found at: http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html Comments on this proposal should be sent to this list. The review period is six weeks and will end on 16 November. A webcast recording of the entire RIPE Address Policy Working Group session can be found at: mms://webcast.ripe.net/ripe46/ap-1a.wmv mms://webcast.ripe.net/ripe46/ap-2a.wmv Kind regards, Axel

2 1

RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA all ocation size
by Titley, Nigel 17 Nov '03

17 Nov '03

Gert Doering wrote: > Hi, > > this was discussed on the list before the last RIPE meeting, and we > had it on the address policy working group meeting (presented by me). > > I think we mostly have consensus on this issue, but I want to present > it as a formal proposal, before it's incorporated into the policy. I am strongly in favour of this, it helps to solve the bootstrapping problem that many small LIRs suffer from, and which many have to lie about to get around. > > PROPOSAL: > > * the minimum initial allocation size (for new LIRs) is reduced from > a /20, as of today, to a /21. > (If a new LIR can demonstrate need for a bigger initial > allocation, they can get a larger address block. This will not > be changed). > > * the requirement to show an immediate need for 25% of the allocated > address space is removed for the "minimum initial allocation" > > > The motivation for that is that under the current policy, startup LIRs > that do not already hold address space cannot get an initial > PA allocation > (which would be a /20 as of today, or bigger), because in > many cases, they > cannot demonstrate immediate need, or prior utilization of sufficient > address space. > > To work around this, many startup LIRs use PI address space > as a start, > and when they have filled enough of this, apply for their own > PA again. > The problem with this is that in the end, it's very likely that more > than one route will end up in the global BGP table (where one PA route > would be sufficient), and also it encourages lying to the > RIRs (PI space > must not be distributed to third parties, i.e., LIR customers). > > > The drawback of the changes are that it's potentially wasting address > space for "very small LIRs" (that would be happy with a /23 PI space > and will now get a "huge" /21). The wastage would only happen for > very small LIRs that will never grow to fill the initial /21. > A rough calculation shows that "1000 new LIR /21 allocations" would > need a /11, which is not an unbearable strain on the conservation > side, judging from the total number of LIRs in RIPE land today. > > A second drawback of this is that people may need to adapt their BGP > filters to permit /21s from the network block(s) where these > allocations are made from. So the RIPE NCC needs to document this > accordingly, and ideally, well in advance. > > Gert Doering > -- NetMaster ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. **********************************************************************

2 1

Is the time for conservation over?
by Michael.Dillon＠radianz.com 04 Nov '03

04 Nov '03

One area of address policy that is fairly consistent world-wide is the view that IPv4 address space is scarce and that the policy must be conservative, i.e. the policy must make conservation of IPv4 addresses a high priority. I don't think that's true anymore. On the one hand, we have IPv6 deployed commercially in 3 of the 4 policy regions (Europe, AsiaPac, America) which indicates a continuing trend toward a future time where IPv6 service will be almost as easy to find as IPv4 service. On the other hand, the worst possible outcomes discussed when CIDR was first deployed are not going to happen. For instance there was a fear that the People's Republic of China might want 1/4 of the IPv4 space because they have 1/4 of the planet's population. This has not happened and is now quite unlikely to happen. Therefore, I believe that all the RIRs should jointly do some research to establish a prudent date at which IPv6 will be considered to have reached critical mass so that there will be a significant migration of users from IPv4 to IPv6. Once we set our sights on this date we should set aside a certain amount of buffer in the IPv4 space, and then design our policy to consume the rest of the IPv4 space, not to preserve it. At the same time, this policy shift should be presented as part of a global IPv6 migration strategy because that is what it is. In addition, I don't see any good reason to wait until LIRs come and ask for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will be deploying IPv6 sometime. So why don't we just give every single one of them an IPv6 /32 today. Instead of creating barriers to the adoption of dual v4/v6 networks as we are today, we should be facilitating the operation of dual v4/v6 networks. We need to create an environment in which the end user can choose whether to use v4 or v6 rather than constraining the end users with our v4-centric regulatory bureaucracy. --Michael Dillon

9 14

Re: [address-policy-wg] re: Is the time for conservation over?
by Michael.Dillon＠radianz.com 04 Nov '03

04 Nov '03

>>In addition, I don't see any good reason to wait until LIRs come and ask >>for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will >>be deploying IPv6 sometime. So why don't we just give every single >>one of them an IPv6 /32 today. Instead of creating barriers to the >>adoption >This was the opinion in the first days op IPv4, please don't make the same mistakes again with IPv6.. We can't look into the future, but we can look at the past!! I don't want to make the same mistakes as IPv4. That is why I want to give an IPv6 /32 to every IPv4 LIR. With IPv4 we made a mistake by trying to be too careful with class C address blocks and again with small CIDR blocks. Instead of giving out large blocks of class C space, we created the swamp. When CIDR came along we continued to give out blocks for one year or less of growth and we bloated the global routing table. With IPv6 we do not have to worry about waste. Every LIR gets a /32 from a reserved /29. When addresses are issued to customers, everybody gets a /48 except in special circumstances where a /64 or a /128 would be assigned. I don't think there will be very many special situation that justify a /64 assignment today. This means that we have a very simple straightforward system that allows LIRs to grow 8 times before we even begin to create anything that is similar to past history. The key to avoiding the mistakes of history is to forget about conserving address space. It is not a scarce resource; we have lots of it. --Michael Dillon

2 1

RE: [address-policy-wg] Re: Is the time for conservation over?
by Michel Py 29 Oct '03

29 Oct '03

> Stephane Bortzmeyer wrote: > For those who do not (yet) know him, be assured you can safely > ignore all messages coming from Jeff Williams, known troll in > the Internet governance issues. Indeed. I have heard some rumors that Jeff Williams and Jim Fleming are the same person. Or maybe there is a brotherhood of trolls. > (And, as we know, IPv8 does not exist.) I actually read it a while ago. I will not go as far as recommending reading it, but I found it both hilarious and a somehow extensive list of exactly what not to do :-) Michel.

1 0

IPv4 Address Space
by Paul Rendek 29 Oct '03

29 Oct '03

[Apologies for duplicate mailings] Dear Colleagues, There have been press articles posted over the past year that make statements about the remaining pool of IPv4 address space. A recent article states there is a shortage and that Internet Protocol Numbers will run out some time in the year 2005. The Regional Internet Registries (RIRs) do not themselves make predictions about when the remaining IPv4 address space will be depleted. They do, however, report on the rates of RIR allocation of IPv4 address space and on the state of the remaining pool of IPv4 address space. The information provided in these RIR reports makes it apparent that many of the recent claims regarding IPv4 address space shortage are speculative and are not based on authoritative, publicly available statistics. IPv4 Address Space: Current Statistics ============================ The global pool of IPv4 addresses is administered by the Internet Assigned Numbers Authority (IANA), which allocates address blocks to Regional Internet Registries (RIRs) as they are required. The IPv4 allocation unit in this case is the "/8 block", equivalent to approximately 16 million addresses. It should be noted that as of 30 June 2003 the global pool of IPv4 address space contained 91 of these blocks for this purpose. The RIRs report on statistics regarding IPv4 allocation on their respective web sites and present a "Joint Statistics" report at each of the RIR meetings and at other Internet industry meetings several times yearly. This information is publicly available and provides the most up-to-date statistics on rates of IPv4 allocation. The most recent presentation on this subject can be found at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf This report states that the RIRs have collectively allocated 19.59 /8 equivalents in the four and a half years between January 1999 and June 2003. It also identifies that there are 91 /8 equivalents held by the IANA in reserve for future allocation by the RIRs. Based on today's total global allocation rate of approximately 4.25 blocks per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91 blocks held by IANA, it is unrealistic to assume that there is an imminent shortage in the IPv4 address space. Even allowing for a dramatic increase in address consumption rates, it is highly probable that IPv4 address space will last well beyond the two years predicted by some. IPv4 Address Space: Allocated Globally According to Regional Needs ================================================== The RIRs are not-for-profit membership organisations dedicated to providing neutral and fair Internet resource distribution to their members, while ensuring the conservation and aggregation of IPv4 address space. The IANA policies for allocation of IPv4 address blocks to the RIRs are applied fairly and are based purely on the documented need for address space. When IPv4 address space finally "runs out" this will occur at the global level, leaving each region with a relatively small pool of addresses remaining to be allocated. It has been suggested that Asia will experience an IPv4 address shortage before other regions. This is simply not true. This is because addresses are distributed in a co-ordinated fashion from a single global pool, and there is no system whereby that pool is exclusively divided among, or pre-allocated to, different countries or regions. Through the current system of address administration, IP addresses are allocated according to immediate need wherever that need is demonstrated and it is simply not possible for isolated "shortages" to exist. As has been done in the past, the RIRs will continue to report regularly on the registration and allocation rates of Internet Protocol Numbers, and will work closely with the IANA to ensure the efficient management of the remaining IPv4 address space. RIR Statistics: ========== APNIC http://www.apnic.net/info/reports/index.html ARIN http://www.arin.net/statistics/index.html LACNIC http://www.lacnic.net/en/est.html RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/ Raw Data/Historical RIR Allocations: ========================== http://www.aso.icann.org/stats/index.html http://www.iana.org/assignments/ipv4-address-space The Internet Number Resource Status Report, prepared jointly by the four RIRs, provides up-to-date statistics on rates of IPv4 allocation. This presentation is available at: http://www.ripe.net/rs/statistics/resource-status-200310.pdf Cheers, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

RIPE NCC Dubai Meeting, Dec. 2003 - Updated Agenda
by Membership Liason Officer 29 Oct '03

29 Oct '03

[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. UPDATED AGENDA The agenda has been updated with more information about speakers and presentations. The preliminary list of speakers includes: - Rob Blokzijl (RIPE Chair) - Tim Mertens (CENTR) - Keith Mitchell (XchangePoint) - Axel Pawlik (RIPE NCC) - Phillip Smith (Cisco Systems) The Director General of APNIC, Paul Wilson, will also give a presentation on IPv4 address lifetime expectancy. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net>. ATTENDEE LIST The attendee list is regularly updated with new registrations and is now available online at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/attendees.html HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.… REGISTRATION To register for the RIPE NCC Regional Meeting, Middle East, please see: http://www.ripe.net/cgi-bin/dubai-reg Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Re: [address-policy-wg] Is the time for conservation over?
by Michael.Dillon＠radianz.com 28 Oct '03

28 Oct '03

>It sounds a little bit contradictory to give away IPv4 addresses when >you want people to migrate to IPv6, doesn't it? One of the supposed >advantage of IPv6 is the as-much-as-you-can-eat approach to addresses >So I think your proposal is seriously flawed and contradicts your >desired goal. You forgot this next bit. Think it through... >> In addition, I don't see any good reason to wait until LIRs come and ask >> for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will >> be deploying IPv6 sometime. So why don't we just give every single >> one of them an IPv6 /32 today. Instead of creating barriers to the >> adoption We give out free IPv6 addresses to everyone using IPv4. And we make it easier for new organizations to receive blocks of globally unique registered IPv4 addresses, i.e. not hijacked addresses and not RFC 1918 addresses. In any case, this is just lowering a barrier. It doesn't solve every IPv6 issue but it does remove an unecessary barrier. --Michael Dillon

3 2

RIPE-288, Publishing date correction
by RIPE NCC WebMaster 28 Oct '03

28 Oct '03

Dear colleagues, The correct publishing date for the new "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-288) is 28 October 2003, not 14 June 2002 as previously stated. Apologies for the inconvenience, Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

New Document available: RIPE-288
by RIPE NCC Document Announcement Service 28 Oct '03

28 Oct '03

[Apologies for duplicate mails] New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-288 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: Mirjam Kuehne, Paul Rendek, Sabrina Wilmot, Leo Vegoda Date: 14 June 2002 Format: PDF=90203 TXT=34659 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185, ripe-234 Obsoleted by: Updates: Updated by: Short content description ------------------------- The RIPE NCC is pleased to announce the publication of the updated RIPE IPv4 policy document, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region (ripe-288). The revised document includes the following major updates: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" (ripe-253) was published in September 2002. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). - The document now specifies database registration requirements. Following comments from the community, the wording of the document has also been improved to clarify the policy. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv4-policies.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-288.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-288.txt plain text version

1 0

re: Is the time for conservation over?
by Bart.Jan.Menkveld＠pqr.nl 28 Oct '03

28 Oct '03

1 0

RE: [address-policy-wg] Is the time for conservation over?
by Michel Py 27 Oct '03

27 Oct '03

> Andre Oppermann wrote: > The problem with IPv6 is that it doesn't fix any problems. When > IPv6 was engineered it was done with (from today's perspective) > wrong assumptions about the goals to achieve. Think about > multihoming for IPv6 which is currently not possible (except > for ISPs). And much more stuff on the operational side. Much agree with this. Michel.

1 0

RE: [address-policy-wg] IPv4 Exhaustion
by Mark Hands 27 Oct '03

27 Oct '03

Magic :-) Thanks everyone..... Mark Hands ntl: Hook Senior Data Planning Engineer t: 01256 752624 m: 07866 572314 e: mark.hands(a)ntl.com -----Original Message----- From: Michael.Dillon(a)radianz.com [mailto:Michael.Dillon@radianz.com] Sent: 27 October 2003 13:35 To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] IPv4 Exhaustion >I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. Check the latest ARIN newsletter here http://www.arin.net/announcements/20031008.html available in PDF format. The article on exhaustion is by Geoff Huston who periodically posts article on the topic here http://www.potaroo.net/ispcolumn/ and here http://www.potaroo.net/papers.html Note the reference to RIPE 46 at that last URL. In general RIPE, ARIN and APNIC meetings are a good way to keep up to date on this and other addressing issues. In the ARIN region the trend of IP address consumption continues its slow downward slide and the policy trend continues towards making it easier for smaller entities to receive blocks of IP addresses direct from the RIR. In general, I think RIPE members on this list would find it useful to keep track of the ARIN meetings and their outcomes. There was a meeting last week in Chicago http://www.arin.net/ARIN-XII/index.html and the agenda page has links to most of the presentations. The minutes should be up on the site in a week or so. Policy outcomes take a while to be announced because of the need for Board of Trustees ratification. Note that I am *NOT* suggesting that RIPE policy should be synchronised in any way with ARIN policy. I believe that regions need to make policy that works in their own political, economic and social climates. However, it is useful to be aware of the context in other regions when making policy because sometimes good ideas pop up elsewhere first. --Michael Dillon located in London but getting addresses from ARIN The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited

1 0

Re: [address-policy-wg] IPv4 Exhaustion
by Michael.Dillon＠radianz.com 27 Oct '03

27 Oct '03

>I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. Check the latest ARIN newsletter here http://www.arin.net/announcements/20031008.html available in PDF format. The article on exhaustion is by Geoff Huston who periodically posts article on the topic here http://www.potaroo.net/ispcolumn/ and here http://www.potaroo.net/papers.html Note the reference to RIPE 46 at that last URL. In general RIPE, ARIN and APNIC meetings are a good way to keep up to date on this and other addressing issues. In the ARIN region the trend of IP address consumption continues its slow downward slide and the policy trend continues towards making it easier for smaller entities to receive blocks of IP addresses direct from the RIR. In general, I think RIPE members on this list would find it useful to keep track of the ARIN meetings and their outcomes. There was a meeting last week in Chicago http://www.arin.net/ARIN-XII/index.html and the agenda page has links to most of the presentations. The minutes should be up on the site in a week or so. Policy outcomes take a while to be announced because of the need for Board of Trustees ratification. Note that I am *NOT* suggesting that RIPE policy should be synchronised in any way with ARIN policy. I believe that regions need to make policy that works in their own political, economic and social climates. However, it is useful to be aware of the context in other regions when making policy because sometimes good ideas pop up elsewhere first. --Michael Dillon located in London but getting addresses from ARIN

1 0

Re: [address-policy-wg] IPv4 Exhaustion
by Axel Pawlik 27 Oct '03

27 Oct '03

At 27/10/2003 15:09 +0200, Hank Nussbacher wrote: >Geoff Huston gave an excellent plenary presentation at RIPE46: >http://www.ripe.net/ripe/meetings/ripe-46/plenary.html >but unfortunately the presentation is not available on the RIPE meeting site. A good article by Geoff has appeared in ARIN today, see http://www.arin.net/newsletter/2003_Third_Qtr.pdf regards, Axel

1 0

Re: [address-policy-wg] IPv4 Exhaustion
by Hank Nussbacher 27 Oct '03

27 Oct '03

At 01:07 PM 27-10-03 +0000, Mark Hands wrote: Geoff Huston gave an excellent plenary presentation at RIPE46: http://www.ripe.net/ripe/meetings/ripe-46/plenary.html but unfortunately the presentation is not available on the RIPE meeting site. -Hank >Hello all, > >I am trying to get hold of accurate, up-top-date figures showing me how much >IPv4 space there is left, and how long that is predicted to last. >I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, >ICANN or IANA. >Perhaps I am looking in the wrong place....can someone help me please. > >Thanks very much, >Mark Hands >ntl: >Senior Data Planning Engineer > > >The contents of this email and any attachments are sent for the personal >attention >of the addressee(s) only and may be confidential. If you are not the intended >addressee, any use, disclosure or copying of this email and any attachments is >unauthorised - please notify the sender by return and delete the message. Any >representations or commitments expressed in this email are subject to >contract. > >ntl Group Limited

2 1

IPv4 Exhaustion
by Mark Hands 27 Oct '03

27 Oct '03

Hello all, I am trying to get hold of accurate, up-top-date figures showing me how much IPv4 space there is left, and how long that is predicted to last. I cannot find any up-to-date presentations, charts or reports on RIPE, ARIN, ICANN or IANA. Perhaps I am looking in the wrong place....can someone help me please. Thanks very much, Mark Hands ntl: Senior Data Planning Engineer The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited

1 0

NRO MoU document revised and signed 24 Oct 2003
by Axel Pawlik 27 Oct '03

27 Oct '03

Dear Colleagues, After considering all comments received, the RIR Boards have developed a further revision of the proposed NRO MoU, as attached here. This document has been signed by the RIR CEOs during the ARIN members meeting in Chicago, USA, at 0900 24 October 2003 (local time). "The Number Resource Organization" document can be found on the RIPE NCC at: http://www.ripe.net/ripencc/about/regional/nro-2003-09-241-1.html The RIR Boards would like to stress that they will continue working together with the community to refine the NRO's functioning. I would like to thank the community for their support in this process. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RIPE NCC Dubai Meeting, Dec. 2003 - Reminder: Hotel Reservations
by Membership Liason Officer 20 Oct '03

20 Oct '03

Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues specific to the Middle East. HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.… In addition to your hotel accommodation please remember to register for the RIPE NCC Regional Meeting, Middle East, at: http://www.ripe.net/cgi-bin/dubai-reg Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Re: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Janos Zsako 19 Oct '03

19 Oct '03

> From leo(a)ripe.net Sat Oct 18 21:41:55 2003 Dear Leo, > >>> "An AW can be applied to an End User network once per 12-month period. > >>> This means an LIR can make more than one assignment to an End User > >>> _in_any_such_12_months'_period, but the total amount of address space > >> I think this should be added to improve clarity but... > >> > >>> cannot be larger than the LIR's AW. An LIR's AW is considered unused > >>>on > >>> the anniversary of the first (?!? I would think _last_) assignment to > >>> the End User._After_the_exhaustion_of_the_AW, the LIR may only assign > >>> additional addresses to the same End User after approval from the RIPE > >>> NCC. > >>> > >>> (In one of the sentences above I have the impression that first should > >>> be changed to last - did I misunderstood something?) > >> ... I think the ambiguity in the wording here reflects the > >>ambiguity in the policy. We could update the wording to use the word > >>"last" but that would make the policy more strict than it is at the > >>moment. At some point it would be useful to review and rationalise > >>the current AW policy. It is fairly complicated to document and so > >>fairly documented to use. It would be good (after publishing this > >>updated document, I hope) to take a new look at this part of the policy. > > > >I quote below the relevant part of RIPE-234: > > > >" > >5.2.5.2 Assignment Window for End User Assignments > > > >An LIR can apply their Assignment Window to an End User network only once in > >any 12-month period. This means that if an LIR makes more than one assignment > >to an organisation, the total amount of address space assigned with their AW > >in any twelve month period may not exceed the LIR's AW size. The LIR may only > >assign additional addresses to the same organisation after approval from the > >RIPE NCC. > >" > > > >In my view, this means that I may for example assign an AW worth of > >address space to the End User on 1 January of every year (assuming > >that I make no further assignments during the year). > > > >I also understand that the AW is unused at a moment in time, if at that > >moment I am allowed to assign an AW worth of address space (to that > >particular End User). > > > >In the above example, let's assume that I started assigning address space > >to the End User on 1 January 2000. The last time I have therefore assigned > >to them was 1 January 2003. If I read the text of the Draft, this > >means that my AW (with respect to that End User) is UNUSED, as it has > >to be considered unused starting 1 January 2001 (the anniversary of > >the FIRST assignement). My undertsanding is that it should read "LAST", > >therefore the AW would have to be considered unused starting 1 January > >2004. > > > >Did I misunderstand something? > > I think we may have been saying the same thing in different ways. Correct. This is what happened. > The AW > is refreshed on the anniversary of the first assignment. However, the > way we look at it is that assignments following the first assignment are > subtracted from the 'refreshing' and they have their own anniversaries. > > For example, if I had a /21 AW and made a /23 assignment to a customer > on 1 January 2003 I would have a /22 and a /23 left from my AW for that > customer for the rest of the year. If I assigned the same customer > another /23 on 1 April, 1 July and 1 October my AW (for that > organisation) would return to /23 on 1 January 2004. It would not return > to /21 because there were three subsequent assignments each of which has > an anniversary. > > If there's agreement that this is correct then we can update the text > for the policy document to something clearer. I agree with what you detailed in your reply. Yes, please do make the document more clear, as I for one misunderstood it. Thanks and regards, Janos

1 0

Re: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Janos Zsako 18 Oct '03

18 Oct '03

> From address-policy-wg-admin(a)ripe.net Sun Oct 5 22:15:17 2003 Dear all, > As indicated at the last working group meeting, I would very much like to > se POSITIVE feedback from the WG before we make final policy: > > > Feedback on this document should be sent to the address-policy-wg@localhost > > mailing list for a period of two weeks. > > > > This review period will end on TWO WEEKS FROM ANNOUNCEMENT. > > Who can committ to read and send their comments within this timeline ? At RIPE 46 I was one of those who raised their hands when Hans Petter asked whether anybody volunteers to comment the document if it is circulated again on the list. Please find below my comments. First of all I would like to congratulate those who made the effort of re-writing the policies document. I think they did a very good job. The restructuring seems good to me. I have some specific comments, questions, and sugestions respectively: 1. In paragraph 2.0 I suggest mentioning RFC3330 too. (It gives further details about the address space usage than RFC1918 and RFC1112.) 2. Also in paragraph 2.0, point 2 I suggest adding a new sentence, which in my view makes it easier to understand the reference to RFC2993 (I included in the quoted text my sentence using underscores instead of spaces for easier identification): "...Hosts using these addresses cannot directly be reached from the Internet. _Such_connectivity_is_enabled_by_using_the_technique_known_as_ Network_Address_Translation_(NAT)_. Private addresses restrict a network so that its hosts only have partial Internet connectivity..." (of course, the exact wording itself can be changed). 3. In paragraph 4.0, at the end of second paragraph I suggest adding: "...Registration data (range, contact information, status etc.) must be correct _at_all_times_(i.e._they_have_to_be_maintained)." 4. In paragraph 6.1. I have a question and a suggestion related to the statement: "If a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the request form found at:" It is clear that in case of a new request that needs to be approved, information must be submitted on the current form. The question I have is related to the audit of a prior assignment: does the LIR have to produce the documentation in the _current_ version of the form? I would think that producing the documentation on the form used _at_the_time_of the assignment would be acceptable. If so, it may be good to slightly rephrase the above to reflect this. 5. I have the impression that the AW applied to an End User network (paragraph 7.0) is not clear enough, so I suggest adding a couple of new words: "An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC. (In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?) 6. In the first paragraph of 9.0 I suggest repeating "or sub-allocated" in order to avoid any possible mis-interpretation (i.e. that sub-allocations do not necessarily have to be returned): "LIRs are allocated PA address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned _or_sub-allocated_ by the previous service provider will have to be returned and the network renumbered." 7. I have a question regarding the value "NOT-SET" of the status attribute (paragraph 9.0). The document states that _new_ objects cannot be created with this attribute. I would expect the database to also reject updates that have such an attribute. Is this the way the database behaves? If yes, it may be useful to mention this here ( I suggest something like: "Objects cannot be created or updated with this value".) That is all for now. I hope you will find these useful. Best regards, Janos

3 4

Questions on Provider Independent IPv4 addresses,
by Thomas.Levy＠alcatel.fr 17 Oct '03

17 Oct '03

Hello, I read with interest the ripe-234 document on IPv4 address allocation. It raised me the following questions on PI addresses: 1) Usage of PI addresses is not recommended by RIPE. I don't want to raise a debate on this point. However, I would be interested in knowing the reasons for this. Is it for routing purpose? 2) How could I find statistics on PI allocated addresses (by RIPE or globally)? Please apologise, if it is not the best appropriate place, where to ask such questions. I looked for the answer on the RIPE web site. But, I couldn't find the information. Regards, Thomas Levy

3 2

[Nro-comments] Revised FAQ (fwd)
by Hans Petter Holen 16 Oct '03

16 Oct '03

---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 04:42:10 -0400 From: Ray Plzak <plzak(a)arin.net> To: nro-comments(a)apnic.net Subject: [Nro-comments] Revised FAQ Below is a revised list of FAQ concerning the NRO MoU and the ASO MoU. Thwy will be posted on the RIR websites. Ray ************************************************************ Frequently Asked Questions about the NRO MoU and ASO MoU 1. Why can't the RIRs and ICANN sit down and discuss their differences? The RIRs and ICANN have been very actively engaged in discussions and both parties have taken every opportunity to keep the dialogue open and continuous. These discussions have been constructive and productive and have included face-to-face meetings as well as teleconferences. 2. Why are the RIRs trying to replace ICANN? The RIRs are firmly committed to ICANN and to its viability. Within the ICANN framework, the RIRs have two objectives which they see as of paramount importance to the addressing community. a. Protection of the unallocated number resource pool (IPv4, IPv6, and ASN). Access to the unallocated number resources pool by the RIRs is controlled by global policy. b. Protection of the policy development process so that policies cannot be imposed top down on the community. Neither the ICANN Board nor any of the RIR Boards can impose policy. 3. Does the NRO replace ICANN? No. One of the functions that the NRO is intended to provide is to undertake if necessary those IANA functions that pertain to the management of number resources. The NRO is not being structured as a potential 'complete' ICANN replacement in the event of failure of ICANN. The consideration here was that in such an event it was considered probable that the various IANA functions would be undertaken by those with a direct interest in each particular functional area. 4. Does the NRO replace the ASO? No. The NRO is a stand alone body that will negotiate the ASO MoU with ICANN. Upon implementation certain aspects of the NRO will become part of the ASO. For example, the NRO Numbers Council will become the ASO Address Council. Other aspects, such as the Executive Council will not become part of the ASO but will continue to represent the RIRs acting in concert. 5. Why do we need another layer of bureaucracy? We don't! The NRO is not another layer of bureaucracy. Within this proposed framework the essential elements of interaction between the RIRs and ICANN remain unaltered. ICANN continues to operate the unallocated Internet number resource registries. The Board of ICANN has the continued ability to ratify proposed global number resource policies. An Address Council continues to undertake a role as a source of advice to the Board of ICANN on Number Resource matters, as well as shepherding proposed global address policies through ICANN for ratification. 6. If the NRO doesn't replace ICANN or the ASO or change anything in the current structure, what does it do? How does it change the relationship between ICANN and the RIRs? The NRO is an interface for organizations outside of the RIRs to interface directly with them at a single point instead of dealing with each RIR separately. For example this allows ICANN to interact directly on non policy items such as the ICANN budget and service contracts. Currently, ICANN must deal with each individual RIR on such matters. The NRO provides a similar single interface to the RIRs for other organizations, such as the IETF, on Internet number resource administration issues. The NRO also provides a visible framework for existing cooperative joint activities in which the RIRs are already engaged. Such activities include the administration of upper level reverse DNS domains. Future activities of this nature will also be undertaken within the framework of the NRO, such as a common whois interface to RIR data. 7. Are open and accessible processes being used in the development of the NRO MoU and the ASO MoU? In both cases an open and accessible policy process is being used. The RIR Boards, exercising their policy process and fiduciary responsibilities, have drafted two documents and have placed them in the public domain for comment. The RIRs are undertaking to organize the NRO for the purpose of providing an organizational structure to support the various inter-RIR cooperative arrangements that have evolved over the last three years as the RIRs have worked in concert in both technical and policy areas. The comment period is to elicit any comments that the regional communities may have in regard to this formalization of already existing practices. It is currently proposed that the NRO MoU will be signed at the end of the comment period, with this proposed action being dependant on an assessment of comments received in this period. In the case of the ASO MoU, after the regional community comment period it will be presented to ICANN as a draft document for their consideration. It is expected that there will be some negotiation between ICANN and the NRO after which time the negotiated draft will again be placed in the public domain. Of course anytime during this period any one is more than welcome to comment. 8. Will this proposal dramatically change the relationship between ICANN and the RIRs? Neither the NRO MoU nor the ASO MoU will dramatically change the relationship between ICANN and the RIRs. In the case of the NRO, it is intended to improve the relationship, as ICANN will have a single consistent point of contact for such matters as budget and service contracts. In the case of the ASO MoU the biggest change is additional protections for the bottom up policy process, as the proposed policy development process will prevent the ICANN board from exercising a veto by direct action or by non-action on any policy proposal. It further protects the process by preventing the ICANN board from making policy and directing it down to the addressing community. 9. Will the NRO MoU and the ASO MoU have any wide-ranging impacts on technical coordination, planning, and administration of addressing and numbering policy? The NRO MoU and the ASO MoU will have impact in some areas, but it will be only to strengthen the protection of the unallocated number resource pool and the bottom up policy process. Areas not changed: a. The bottom up policy process from the addressing community to the RIR fora will not change. b. The bottom up policy process for global policy from the addressing community to the ASO AC will not change. c. The administration of policy between the RIRs and the community in their respective service regions will not change. d. The administration of addressing policy between the IANA and the RIRs will not change. Areas that will change under these proposals: a. The ICANN board will not be able to make and direct top down addressing policy. b. The ICANN board will not be able to veto a global policy proposal by direct or indirect means. c. Activities where the RIRs act in concert will be strengthened by the formalizing of an already existing relationship. This will occur in such areas as policy harmonization, technical coordination, and planning. d. Activities such as technical coordination and administration of policy where the IANA must interact jointly with the RIRs will be simplified as the IANA will now have a single interface point. 10. How transparent are the activities of the NRO Executive Council going to be? Every meeting of the NRO Executive Council will be transparent as the agenda and minutes of each meeting will be published. 11. How will the appeals process work? The appeals process is an advisory process., designed to provide advice in regards to the operation of policy process. It is not designed to decide the merits of a policy, but rather, to examine the policy process in regards to any global policy for which a constituency of the addressing community is aggrieved. The Advisory Appeals Panel (AAP) may hear complaints regarding the activities of any or several RIRs, the NRO or and NRO sub-organization such as the Numbers Council. The AAP may dismiss frivolous, repetitive or nuisance complaints with without further review. The AAP decision is intended to serve as a persuasive advisory opinion and therefore it will not provide any basis for legal action in any jurisdiction. The appeals process does not alter the appeals process in any way within the responsibility of any RIR, and no appeals prerogatives or options are being ceded by the RIRs to the NRO under this proposal. 12. How is the Advisory Appeals Panel formed? The Advisory Appeals Panel (AAP) will consist on one (1) member from each RIR service region. They will be selected by the NRO Executive Council. Members of the AAP cannot be an employee of an RIR nor a member of any RIR Board. They will be selected based upon their knowledge of the Internet community in general and the addressing community in particular. The AAP will adopt such policies and procedures that are necessary to make it an accessible, open, transparent, and documented. These policies and procedures will include such things as voluntary or requested recusal of panel members, procedures for reporting to the NRO Executive Council, and procedures to address any allegation of fraudulent or dishonest conduct by panel members. 13. Can the Advisory Appeals Panel be effective? Yes. It is intended that the members of the Advisory Appeals Panel (AAP) will be well known and respected members of the Internet community. Although their decisions will carry no basis for legal action, it is anticipated that their advice will be the product of a thorough and stringent process of investigation and review and that any advice that the panel may provide will be well grounded. 14. These documents will have long-lasting effects. It is hoped that this is indeed the case. It is the intent of these documents to put into place provisions that will protect the unallocated number resource pool and the bottom up policy process thus contributing directly to the security and stability of the Internet for years to come. It is expected that as the Internet environment changes over time that these documents may have to be revised, thus it is expected that they will be reviewed from time to time. _______________________________________________ Nro-comments mailing list Nro-comments(a)apnic.net http://mailman.apnic.net/mailman/listinfo/nro-comments

1 0

Re: [Nro-comments] Some comments on the text (fwd)
by Hans Petter Holen 16 Oct '03

16 Oct '03

FYI: Some further clearifications on the NRO proposal -hph ---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 22:59:51 +0200 From: Frode Greisen <frode(a)greisen.net> To: sabine jaume <jaume(a)renater.fr>, nro-comments(a)apnic.net Cc: Hans Petter Holen <hpholen(a)tiscali.no>, "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> Subject: Re: [Nro-comments] Some comments on the text Dear Sabine, > On 14/10/03 8:39, "sabine jaume" <jaume(a)renater.fr> wrote: > Dear all, > > After reading the NRO proposal and the ASO MoU, here are some comments > on the text, which to my opinion need clarification for better > understanding and/or to avoid misunderstanding. > > > NRO Proposal > > Chapter 1 : > The creation of the NRO doesn't need ICANN's acceptance : as far as RIR > sign the agreement it is considered in force. Did I understand it correctly? yes, this is correct. > > The signature includes RIRs who are signatories : what about any new > possible RIR? I would add here a reference to chapter 3 in case a new > RIR wants to sign the agreement later on. As you say, the intention is that new RIRs can join with equal rights. As the text stands, Chapter 3 provides for the inclusion of new RIRs. Just as the situation exists today, the new RIR must meet objective criteria and must sign the MoU. > > Chapter 2 : > This description is fully in line with the operationnal business of RIRs. > > Chapter 4 : > Here I find an inconsistency with chapter 2 : indeed if the NRO has an > operationnal role, how can it also intervene in policy making processes. > This is how I interpret the fact that the NRO Number Council is under > the responsability of the NRO Exec Council (see chapter 6). see comment below. > > Incorporation : under which law? We felt no need to define law and location before a decision to incorporate. This will be agreed by the RIR signatories at that time. > > Chapter 6 : > Here is where policy-making process- and day to day busines of > RIRs are mixed. > What happens if the Number Council makes proposals > following bottom up process which are rejected by the NRO (see comment > on ASO MoU text)? The Executive Council is responsible for external communication but in the (probably most likely) scenario policy ratification is done by ICANN as defined in the ASO MoU and the Executive Council will not make policy. It is only in the stand-alond scenario after and ICANN failure that the Executive council would in reality ratify or reject. The sense of the document is that the Executive council would then act in the role of the ICANN board as far as address policy ratification is concerned and would only base its decision on whether due processes were followed or not. In order to avoid duplication, all the relevant procedures defined in the ASO MoU and its attachment are not also spelled out in the NRO document. In the case of rejection, any dissatisfied party could resort to the appeals process. > > Chapter 7 : > Here the bottom up process should be described. > You may be right. In the scenario where the global policy process is defined in an ASO MoU with ICANN that MoU defines the bottom up process. > > Aren't the ICANN board directors election the Number Council's duties > any more? The Address Council will select ICANN Board members as provided for in the ICANN by-laws and the ASO MoU. When the ASO MoU is agreed to between the RIRs and ICANN, the Numbers Council will become the ASO Address Council and will function under the provisions of the ASO MoU. > > What are the lenghts of each person's term? Can they be renewed? > Can the 2 selected persons be RIR staffed persons? > Good questions. Since there would probably be a transition from the present Address Council to the Numbers Council a staggering would need to be defined but we felt it would be better to have a basic agreement with ICANN and also seeking advice from the present Address Council before getting into defining a system for this. A reasonable assumption would be to get to three year terms like now. RIR staff members may not be elected to either of the two elected seats. An RIR staff member may be appointed by theappropriate RIR Board to the one RIR appointed positon from each region. > > Chapter 9 : > How long will people seat on the Appeals Panel? > Experience from the RIPE NCC arbitration panel shows that the arbiters have not been very busy. My personal preference would be to let the NRO ping the selected representatives about annually, and keep them as long as they are willing and and able and have the desired knowledge. > > Chapter 10 : > In case of an abitration that takes long time : what will happen? Is > there a kind of provision that says that during the time there is no > decision, policies will be applied as they were before the dispute started? > Good point. As usual, the appeals process is institued to seek agreement before a part resorts to a lawsuit. The pressure to avoid suits should be an incentive for the appeals panel to act quickly, however, the circumstances of each situation will dictate deadlines. Therefore, a one size fits all time is not suitable. It may be worth considering, but perhaps difficult to decide in advance for all cases, whether initiation of appeal should have holding effect on the process in question. > > Chapter 11 : > How is an RIR member defined? This is an RIR signatory. Should probably be clarified in the text. > > What is the clause 12b? > Thanks for spotting this! This should say 1.2. > > Chapter 12 : > What are those technical activities : could be a lots of things... > Yes, and as such they must be agreed by the Executive Council. Examples could be mutual data-base backup between RIRs or global whois services. > > Chapter 13 : > Will the RIR members (again to be defined) pay a fee directly to the > NRO, or will this be done via the RIRs existing fundings? > Like above, RIR member in this chapter means NRO signatory. Since the NRO will not have a budget there will be no fees paid to the NRO. All expenditures will be agreed to by the Executive Council. The Secretariat will track the costs and invoice each RIR as appropriate. Just as is the situation today with regards to funds for the ICANN budget and funds to support ASO and ASO AC activities, the RIRs include these expenditures in their individual budgets. In regard to the NRO and the new ASO and and ASO AC we expect the same method of operation. It is expected that these expenditures will be similar to today's situation. > > What is paragraph "a" refering to? > Thanks! As above, letters were changed to numbers in bullet points, so this should be paragraph 13.1. > > ASO MoU > > From the NRO document statements, the Address Council is under the > responsablity of the NRO Exec council, and has RIR appointed members. So > what does "in conjunction with the RIRs" means? > > Again the split between policy making process and operations is > confused, because of the ASO AC being under the responsibility of the > NRO. Indeed point 4 stresses that the RIRs Board do have a policy making > role. > "In conjunction with the RIRs" means that both the Address Council and the RIRs will work together. While it is anticipated that most questions and concerns of the RIRs can be dealt with by the RIR appointed members of the Adress Council, there always exits the possibiliy that additional information may have to be gathered by RIR staffs or the RIR Boards may need to comment. Thanks for your thoughtful questions and comments. For further discussion you may also want to check http://www.ripe.net/ripencc/about/regional/nro-faq.html Frode Greisen RIPE NCC Executive Board Member > > Looking forward to any clarification you can provide, > > Thanks! > > Best regards,

1 0

RIPE NCC allocations to African LIRs
by leo vegoda 15 Oct '03

15 Oct '03

Dear Colleagues, The RIPE NCC received the IPv4 address range 196.200.0.0/13 from ARIN in October 2003. This range will be used to make allocations and assignments to organisations based in African countries served by the RIPE NCC. This block is part of a /8 also used by ARIN. In order to reduce confusion the RIPE NCC will not assign prefixes longer than a /24 from it. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Some questions regarding the NRO proposal
by Hans Petter Holen 15 Oct '03

15 Oct '03

Dear all, First of all I would like to congratulate the RIRs with a constructive and solid proposal to move forward. I think the formalization of an organization to help the RIRs act in a coordinated manner is lomg overdue. As a general comment I think the detailed specification of the global policy making process is a step forward. Under the current MOU this is not well defined and clarification of the process should be much welcomed to all involved. In reading the proposal I have some questions, first to the NRO Agreement: 6. NRO Executive council Is there a clear enough division between legislative and executive roles? One of its roles is to ratify and reject global IP number policies. (Legislative), at the same time the Executive council is empowered to sign documents and contracts (executive). Maybe it needs some clarification in the language to make it clearer that the EC simply ratifies that polices has been formed according to process. 7 NRO Number Council ii Composition What is the reason for the proposed composition? The Board of the RIRs are elected by the members of the RIR and the current procedures for electing ASO AC members are that mostly the members elect the council members. The proposal is in reality a combination between a direct and indirect election. What is the advantage of this? Why not revert to just one approach direct or indirect election? a) Election by RIR members b) Election by RIR boards The Council shall under the agreement elect a chair. It may also be necessary to elect co-chairs and a secretary for the Council to maximize its ability to conduct its tasks. Regarding the composition of the two councils: what conflicts of interests exists between the two and the bodies of the RIRs? Are there global conflicts of interests or should this be left to the individual RIRs to decide? Then to the ASO MOU Attachment A: Global Policy Development Process: 4. For some RIRs (RIPE NCC) this introduces a new role to the Board in ratif ying policy proposals. While this may be a good idea - it does require some changes to the regional policy process to be aligned. Best Regards, Hans Petter Holen

2 1

Draft minutes: RIPE 46 Address Policy WG session
by leo vegoda 14 Oct '03

14 Oct '03

Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 46 can be found at: http://www.ripe.net/ripe/wg/address-policy/r46-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, draft minutes from the LIR Working Group at RIPE 45 are can be found at: http://www.ripe.net/ripe/wg/lir/r45-minutes.html These have not yet been approved and can still be corrected if appropriate. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Call for volunteers: editorial group to revise "Charging by Local Internet Registries" document
by leo vegoda 13 Oct '03

13 Oct '03

Dear Colleagues, Last month at RIPE 46 the RIPE Address Policy Working Group (AP WG) discussed the RIPE document "Charging by Local Internet Registries" (ripe-152). The document was published in 1996 and describes "charging for services by Internet registries and indicates acceptable practice for such charging". It can be found at: <http://www.ripe.net/ripe/docs/chargingbylirs.html> Particular attention was given to the statement that "registries may charge for their administrative and technical services, they may not charge for name space or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private." It was agreed that an editorial group of volunteers from the community should be formed discuss the document and suggest changes to its text and content. A mailing list has been created for this discussion. The list is open to anyone wishing to participate. If you want to subscribe to the list you can do so via the web interface at: <http://www.ripe.net/mailman/listinfo/ripe-152bis> Additionally, a web archive of the discussion can be found at: <http://www.ripe.net/ripe/mail-archives/ripe-152bis> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Proposed Open Letter to ICANN and Related Documents
by Axel Pawlik 13 Oct '03

13 Oct '03

Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments(a)apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments(a)apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC

2 1

RIPE NCC Regional Meeting, Middle East, Dubai, 7-9 December 2003
by Membership Liason Officer 08 Oct '03

08 Oct '03

Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Middle East, to be held 7-9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. Registration for the Regional Meeting opens 8 October 2003. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. To register, please see: http://www.ripe.net/cgi-bin/dubai-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - How to participate in and influence IP address management policy-making; - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - Are we running out of IPv4 address space? - Root name server operations: who is involved? - Domain Name management on the Internet; - The internationalisation of Domain Names. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the Middle East region. The current meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net> The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Any further questions about the RIPE NCC Regional Meeting, Middle East can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Dominic Spratley 05 Oct '03

05 Oct '03

Dear Colleagues, The RIPE NCC is pleased to announce an updated draft of the revised RIPE IPv4 policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (currently ripe-234). The major change from the draft published on 21st July is that the existing "status:" attribute values are kept for inetnum objects with the addition of a new value for sub-allocations. The updated draft can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the current policy text in this draft IPv4 policy document are: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). Feedback on this document should be sent to the address-policy-wg@localhost mailing list for a period of two weeks. This review period will end on TWO WEEKS FROM ANNOUNCEMENT. Dominic Spratley Registration Services Manager RIPE NCC

2 1

RIPE 46 Meeting Report
by Nick Hyrka 02 Oct '03

02 Oct '03

(Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at <meet-greet(a)ripe.net>. RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>. END

1 0

Re: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal
by Kinder, Klaus 02 Oct '03

02 Oct '03

Hi, Ludger Bornhorst is on vacation but we have discussed this matter before he send this mail. Here two notes from my point of view: you wrote: The RIR->LIR level has the AW to express a given level of trust. I quite agree with you: You could use policies in a narrow interpretation or in a scope of interpretation in addition with your know how in cases of ip-address management, both is possible and essential. But you couldn't find this scope in ripe-283 e.g. #[EQUIPMENT DESCRIPTION]#, I think that's the problem. Or is this scope in addition to your AW an unwritten policy? you wrote: please don't feed the buerocracy. I can assure you that's not our target. From our point of view policies should give all parties, here the LIR's, a general Framework and not a straitjacket. mit freundlichen Grüßen/with best regards Klaus Kinder _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Local Internet Registry Ammerländer Heerstr. 138, D-26129 Oldenburg +49 441 234 - 4530 (phone) +49 441 234 - 4589 (fax) E-Mail: Klaus.Kinder(a)telekom.de

1 0