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