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

RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by Tim Streater 03 Nov '07

03 Nov '07

At 15:14 29/10/2007, Mark Pace Balzan wrote: > > > > IPv6 Internet is working even now, but completely useless. Because of > > there is no resources at all. > > > > In my opinion, the concrete goal is make 51% of _resources_ > > (not users) > > to be reachable through IPv6 before we run out of IPv4. If it > > succeeds, > > other 49% will go with "the majority", if not - IPv6 migration > > completely fails and something other (NAT, secondary market of IPv4, > > higher level proxies over non-IP protocols, ...) will be implemented > > instead. > > > >my 2c worth: > >v4 and v6 will co-exist for a while, whether we like it or not, and >therefore v4 and v6 stuff will need a way to get to each other depending >on the service at hand. They will co-exist for a long while due to lack of pressure from the users. If v4 really runs out, there will start to be some parts of the Internet that are not accessible to some users. Then they will complain to their ISP and something starts to happen. Then it gets in the mainstream press, at which point you may see a more rapid transition. Plenty of people will however say, why should I bother to get a new xxx box when I can reach all sites I care about. Unless the govts get involved, of course. -- Tim

7 10

Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
by Tony Hain 31 Oct '07

31 Oct '07

Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool. Author name: Tony Hain email: alh-ietf(a)tndh.net telephone: +1-425-468-1061 organization: Cisco Systems Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009

5 4

RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by Niall Murphy 31 Oct '07

31 Oct '07

Michael, all, > > The address space in question is already allocated, hence > > unavailable. The question is how to incent folks to put > > their "allocated but unused" address space back into play. > > Stamping your foot and declaring "markets are bad" > > isn't likely to be too helpful. > And thinking that you can influence address-holders decision making > without pricing an IPv4 at several hundred thousand dollars, is also not > likely to be too helpful. I don't think that anyone knows how the pricing is going to work yet, so I'm going to leave aside discussion of your specific figure. Similarly, "an IPv4" (an IPv4 what?) probably needs clarification, but it's not the substantive issue. Notwithstanding the detail of the numbers, which is obviously a crucial detail, I have to take issue with your assertion is that we cannot influence address-holder decision making without setting a price, and setting it high. The fact is, after IPv4 exhaustion we will still need IPv4 addresses. Address holders who have more IPv4 addresses than they will ever use will have a strong incentive to exchange those addresses for money, and IPv4-dependent organisations will have a strong incentive to purchase them. That's going to happen, make no mistake, because as an industry, we are *nowhere near* where we need to be in order to have an IPv6 world by 2010. So, there's already no question of address holders being uninfluenced. They certainly will be by 2010, if they're not already, and such pricing as emerges in a back-door market does not have to be high in order to provoke the release of addresses in an ad-hoc fashion. It's entirely plausible that a steady drip-feed of low-priced prefixes would suit many organisations better than holding on for higher prices (think cashflow, for example). For these and other reasons, there'll be no question of, for example, the RIR system being frustrated in its attempt to influence address-holders because of too low a price. The danger is not the RIR system and is not the market; the danger is the unregulated market, and the chaos of the current post-exhaustion scenario. > Any organization who contemplates selling a block of IPv4 addresses has > to conside the reality that it would be an extremely constrained market > where the supply is going down and they are not making any new IPv4 > addresses. Indeed - that's exactly right, and that's one of the reasons why it's such a powerful incentive to move to IPv6, which is, IIUYC, where we both want to be. But you must also consider that such a market as we proposed is not intended to be *the* solution: it is explicitly not for continually recycling existing prefixes. It is to provide liquidity to the participants for an undefined period until IPv6 is a workable day-to-day alternative to IPv4. So the fact that the market is constrained *doesn't matter* in the long term - we're inventing our way out of scarcity elsewhere. > This means that if you do sell, and then discover that you > needed those addresses after all, the price to buy them back could be > substantially higher than your sale price. In the face of continually > rising prices, it is risky to sell any addresses at all, unless you are > absolutely certain, at the CEO/board level, that the addresses are not > needed, or if the price that you would receive is at least several > hundred thousand dollars. (Again, I'm not going to talk about the figures here, but that's not a central point in your argument.) If I parse what you're saying correctly, you posit that the danger of accidentally selling addresses that it turns out that you'll need will motivate people to stay away from the market, and therefore cause rising prices and liquidity problems. Well, my argument would be that from an economic point of view, organisations are incentivized to only sell what they explicitly don't need. We all know of organisations that have much more spare than they could possibly use, so it's unclear where the original 'dump everything' motivation could come from. Furthermore, the meta-assertion that "a market might have problems" reinforces the fact that the community *must keep transfers where it can see them*. If they are happening out of sight, we have no direction observation or control of the same set of problems. > This is a recipe for a gold-rush style market followed by liquidity > collapse which will have additional knock-on effects in the real > markets, i.e. share prices. If you watch our talk webcast (when RIPE gets around to putting them up) you'll see more details of our argument here, but in brief the dangers of *not* having a realistic plan in place will cause as much damage to stock prices etc as much as leaving things alone will. I'm in sympathy with you on the topic of avoiding gold-rush markets and liquidity collapses, but I think with a bit of careful planning, we'll be able to avoid both. (If only we'd had that careful planning years ago, then we could have saved ourselves a lot of trouble. But now we're in the position of having no wholly good choices, it's only a question of choosing which set of bad effects we want.) Niall

1 0

Re: [address-policy-wg] Commercial IPv6 firewall support
by jwkckid1＠ix.netcom.com 29 Oct '07

29 Oct '07

Nick and all, Chiming in here as a kinda unusual occurance. I agree with Nicks assessment here unfortunately. Seems across a broad business spectrum a disinterest in IPv6 remains or presists. Given, what I believe to be an accurate essesment by Nick below, it would seem that a more concerted effort to make IPv6 more palatable in very short order is advisable. As to how to accomplish that, I do not know. -----Original Message----- >From: Nick Hilliard <nick(a)inex.ie> >Sent: Oct 27, 2007 9:25 AM >To: michael.dillon(a)bt.com >Cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net >Subject: Re: [address-policy-wg] Commercial IPv6 firewall support > >> Some people have claimed that they cannot yet sell >> IPv6 Internet access because there is no IPv6 firewall >> support. According to this ICANN study: >> http://www.icann.org/committees/security/sac021.pdf >> this is not quite true. At least 30% of the 42 vendors >> surveyed, had IPv6 support. > >There is, of course, "support" and support when talking about any feature, >whether ipv6 related or not. > >As a useful example of what "support" implies, the "support" from one of my >firewall vendors includes basic support for ipv6 packet forwarding and >filtering, but no support for configuring this from the GUI. And no support >for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or >v6 support for VPNs. And so on - you get the idea. There are piles more >features which just aren't there if you use v6. In fact, I would suggest >that there is such a large functionality gap between their ipv4 and ipv6 >support right now, that even if they invested heavily between now and the >current expected dates for ipv4 exhaustion, I seriously doubt that they >would achieve feature parity, not to mind stability parity for these >features. > >I have talked to them about this, and their opinion is that there is no >commercial demand for ipv6, and therefore ipv6 feature parity is on the >feature roadmap. And indeed, it is difficult for the organisation I work >for to demand ipv6 support, when other companies can talk to their vendors >with a EUR100m firewall / networking contract going a-begging. I have >little doubt that this is the reason that MOP got re-enabled by default on a >certain router vendor's products. > > >Them: "We have EUR200m to spend and we want MOP enabled by default". >Vendor: "Three bags full, sir". > >Me: "I want to you spend $50m in development costs to support ipv6, and > then i'll buy some low end kit from you" >Vendor: <laughs hysterically> > >Open source solutions tend to fare better in this regard. Lots of people >may end up using them in a future ipv6 world, but you're not going to end up >seeing F500 companies stampeding to replace their current high-end solutions >with m0n0wall installations, just because they have more-or-less parity >support for ipv4 and ipv6. > >There's a more interesting discussion of this of this linked from: > >http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html > >See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave >Piscitello. > >Nick > >-- >Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 >3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >Dublin 2, Ireland | Exchange Association | Email: nick(a)inex.ie > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

1 0

ASO AC Elections: Hans Petter Holen Elected - Correction
by Axel Pawlik 25 Oct '07

25 Oct '07

Dear Colleagues, Hans Petter Holen will serve on the Address Supporting Organization (ASO) Address Council (AC) for three years and not two years as stated in the previous e-mail that you received. We apologise for any confusion. Kind regards, Axel Pawlik Managing Director RIPE NCC

1 0

RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
by JORDI PALET MARTINEZ 25 Oct '07

25 Oct '07

I don't think my comment was well understood today in the session, so I drafted how I think the community resolution should look. See below. English nits should be reviewed, but the main idea is that we start with a short kind of intro of the situation (those points from the original 5 that are generic), staying focus, keeping it short, but at the same time help each "kind of reader" to identify what is the paragraph that is *more* relevant to him. I also added a specific action for policy makers/regulators and one for users. I hope that, as very few people (in the list and session) has provided input on this, we are allowed to participate in the final drafting of the document. Not being a big group is possible to do it, as otherwise, will not really be a community resolution. Regards, Jordi At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point, this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. In addition to that, other sectors must take their own measures in order to success on this mission: 1) Network operators and Internet Service Providers (ISPs) are called to the urgent deployment of IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 2) Vendors (hardware and software) are called to the urgent support of IPv6 support in their products, to make it possible for network operators and Internet Service Providers to provide these services. 3) Regulators and policy makers are called to make sure the relevance of the IPv6 support is considered in all their decisions, including as an immediate condition for public procurements. 4) Users must ensure, when acquiring new services, hardware or software, that it supports IPv6 (natively or by means of transition mechanisms). ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

3 3

ASO AC Elections: Hans Petter Holen Elected
by Axel Pawlik 25 Oct '07

25 Oct '07

[Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce that Hans Petter Holen has been selected by the RIPE community to take the vacant seat on the Address Supporting Organization (ASO) Address Council (AC). He will serve a two-year term. Selection took place during the Plenary session on Wednesday, 24 October 2007, at the RIPE 55 Meeting in Amsterdam. More information about the ASO AC and the selection process can be found at: http://www.ripe.net/info/resource-admin/aso2007/index.html Kind Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Question about IP block Misusage
by Ali Dinçkan 22 Oct '07

22 Oct '07

Hello, I have a question. I am searhing now what happens if an ISP use IP address space that is assigned to another ISP. Is there any technical control eleminate this condition? And what is the legal sanction of this misuse? This might be intentional or unintentional. But ISP that use another ISP's IP address space damage the Internet nature. Thank you for your answer in advance Best regards, Ali Dinçkan <address-policy-wg(a)ripe.net>

3 2

DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
by Gert Doering 21 Oct '07

21 Oct '07

Hello Address Policy Working Group, IPv6 Working Group, as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6". The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing. Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon). ----------------------- snip ----------------------- DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007 The RIPE community resolves as follows: 1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. 2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. 4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. ----- End forwarded message ----- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

12 29

1st DRAFT agenda for RIPE 55 APWG meeting
by Gert Doering 16 Oct '07

16 Oct '07

Dear RIPE address policy WG members, here's a proposal for the APWG meeting agenda for the upcoming RIPE meeting (in October in Amsterdam). This time we're early, so there is time to shuffle things around, etc... - please send your suggestions. ----------------------------- snip -------------------------------- Wednesday, October 24, 11:00-12:30: - formal stuff - overview of concluded proposals (whatever those are, in October) - enough time for generic discussion on PI (IPv4, IPv6, contracts, maybe also covering AS numbers) - Leo Vegoda: a proposal for restructuring of the IPv6 policy Thursday, October 25, 09:00-10:30: - discussion of all other currently-open proposals - new proposals that are not yet in the PDP - AOB ----------------------------- snip -------------------------------- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 2

2007-03 Policy Proposal Withdrawn (IPv4 Countdown Policy)
by Filiz Yilmaz 15 Oct '07

15 Oct '07

PDP Number: 2007-03 IPv4 Countdown Policy Dear Colleagues The proposal 2007-03, IPv4 Countdown Policy has been withdrawn. Authors decided that they want to make a new proposal (see 2007-07, End Policy for IANA IPv4 Allocations to RIRs). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-03.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2007-07 New Policy Proposal (End Policy for IANA IPv4 Allocations to RIRs)
by Filiz Yilmaz 15 Oct '07

15 Oct '07

PDP Number: 2007-07 End Policy for IANA IPv4 Allocations to RIRs Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal seeks to provide the solutions to the problems in terms of address management which may arise if no measures are taken for IPv4 address exhaustion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-07.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 12 November 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Closing: ASO AC Elections Nomination Period
by Paul Rendek 15 Oct '07

15 Oct '07

[Apologies for duplicate e-mails.] Dear Colleagues, The Address Supporting Organization Address Council (ASO AC) nomination period closes today, 15 October 2007, at 23:00 UTC. One individual from the RIPE community will be selected to serve on the ASO AC for a term of three years. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry (RIR). Self-nominations are permitted. Please note that the date of the elections has been moved. Elections will take place at the RIPE 55 Meeting during the 09:00 Plenary session on *Wednesday, 24 October*. Nominations ----------------- There is still time to nominate candidates and send expressions of support. Please see full details on how to nominate at: http://www.ripe.net/info/resource-admin/aso2007/index.html ASO AC ----------- More details about the ASO AC can be found at: http://aso.icann.org/ RIPE 55 ----------- For details about the RIPE Meeting, please see: http://www.ripe.net/ripe/meetings/ripe-55/index.html If you have any questions about this, please contact nominations(a)ripe.net. Kind regards, Paul Rendek Head of External Relations & Communication RIPE NCC

1 0

Reminder: ASO Address Council Nominations
by Paul Rendek 15 Oct '07

15 Oct '07

[Apologies for duplicate e-mails.] Dear Colleagues, The 2007 nominations for representatives to the ASO Address Council (RIPE NCC service region) period is now open. The term of Hans Petter Holen, who has served as an Address Council (AC) member for the past three years, will expire on 31 December 2007. One individual from the RIPE NCC service region will be selected to serve on the ASO AC for a term of three years. The elections will take place during the the RIPE Address Policy Working Group session at the RIPE 55 Meeting, held in Amsterdam on 22 - 26 October. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry (RIR). Self-nominations are permitted. How to Nominate ------------------------ For information on how to nominate a candidate, how to send expressions of support and the election process, please see: http://www.ripe.net/info/resource-admin/aso2007/index.html The list of nominated candidates can be found at: http://www.ripe.net/info/resource-admin/aso2007/nominations.html Important Dates -------------------- 19 September: Nomination period opens 15 October: Nomination period closes 15 October: Complete nominations list posted 25 October: Elections take place during the RIPE Address Policy Working Group session at RIPE 55 More Information ----------------------- Information about the RIPE 55 Meeting can be found at: http://www.ripe.net/ripe/meetings/ripe-55/index.html Regards, Paul Rendek Head of External Relations & Communications RIPE NCC

2 1

Proposal for the creation of a working group.
by Raul Echeberria 09 Oct '07

09 Oct '07

Dear all: I would like to share with all of you this proposal. Since it is not a policy proposal, I don't know really how to proceed, but I guess that it is enough to send it to the list. I have submitted this proposal to the ARIN Policy list and I will do the same with the other RIRs' poilicy lists. I would appreciate suggestions about how to deal with this idea if it sound interesting. Raúl ========================================== Proposal for the creation of a cross-regions working group Some proposals have been submitted through some RIRs policy development process, which focus on the gradual modification of the requirements for receiving IPv4 addresses as the pool of unallocated IPv4 addresses diminishes. Most or all proposals which have been made appear to be incomplete and ineffective if approved in only one region. Therefore, it is proposed the creation of a working group made up by two appropriate respected individuals active in the policy process within each regions community. These ten individuals would work on one or more joint proposals that could then be processed in every region according to their corresponding policy development processes. The objective of the working group would not be to produce proposals for global policies, but proposals to be sumbitted to every RIRs. The conclusion could be, of course, that the proposals should be different in each region. Since the proposal (if there are any) should go later through each Policy Development Process, there will not be any impact of this proposal in the independence of each region to adopt the poclicies that are considered more convenients. Naturally, the proposals that have already been presented in relation to this issue would be important input for this working group, one possible conclusion being that these proposals contain the best possible policies and should be presented. Without this level of coordination, it will be difficult to obtain proposals to be submitted for discussion in all regions with reasonable chances of success. One member of each RIRs staff would also participate in this working group, in the capacity of observers, so as to provide all the support, advice and information that the group deems necessary. IANA will also be invited to appoint up to two persons to the working group in the same condition of observers. The working schedule would be defined by the group itself, but it should be anticipated that the proposals, in case it is decided they are needed, be presented for their discussion as soon as possible. The following are some of the ideas that have already been presented either formally or informally and that will be available for the consideration of this working group (but not limited to) : · Increasing the requirements for receiving additional allocations as IANAs central pool of addresses diminishes. · Adding to the current requirements the requirement to develop the availability of IPv6 infrastructure. · Reducing the sizes of the blocks that are allocated as IANAs central pool of addresses diminishes. · Including within the gradual increase of restrictions the requirement that when one RIR runs out of addresses the others will automatically be moved to a more conservative phase in order to minimize RIR shopping. ===============

1 0

ASO AC: RIPE NCC Call for Nominations for ASO AC Seat
by Paul Rendek 19 Sep '07

19 Sep '07

[Apologies for duplicate e-mails] Dear Colleagues, This is a call for the RIPE community to nominate individuals from the RIPE NCC service region to serve on the Address Supporting Organization (ASO) Address Council (AC). Hans Petter Holen (Visma IT AS) vacates his seat on 31 December, ending his three-year term. Important ---------- The ASO Memorandum of Understanding (MoU) states that the public nomination period should open 90 days in advance of the next open policy meeting (RIPE 55) and close 30 days before the start of this meeting. Due to an oversight in the RIPE NCC's administrative procedure, this public nomination period was not announced to the RIPE community at the scheduled time. We apologise for any inconvenience this may have caused. If there are no objections from the community, we would like to proceed with the nomination process as follows: - 19 September: Nomination period opens - 15 October: Nomination period closes - 15 October: Complete Nomination list posted at: www.ripe.net/info/resource-admin/aso2007/nominations.html - 25 October: Elections take place during the RIPE Address Policy Working Group session at RIPE 55 How to Nominate Candidates ----------------------- Please send your nominations to nominations(a)ripe.net by 23:00 UTC on 15 October 2007. For details of the information that must be included with your nomination please see: www.ripe.net/info/resource-admin/aso2007/index.html More Information ---------------- Information about the ASO AC and the nomination procedure can be found at: http://aso.icann.org/ac/ Information about the election procedure during RIPE 55 can be found at: www.ripe.net/info/resource-admin/aso2007/selection-procedure.html More information about RIPE 55 can be found at: http://www.ripe.net/ripe/meetings/ripe-55/index.html Kind regards, Paul Rendek Head of External Relations & Communications RIPE NCC

1 0

New AS Number Block allocated to the RIPE NCC
by Alex Le Heux 18 Sep '07

18 Sep '07

Dear Colleagues, The RIPE NCC received the AS Number Block 44032 - 45055 from the IANA in September 2007. You may want to update your records accordingly. Best regards, Alex Le Heux RIPE NCC

1 0

Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE:
by BabyMatthew253 13 Sep '07

13 Sep '07

To whoever may read these: I Matthew Brown, would like to request that there be some sort of action, to allow the ripe database managers to contact ISP(s) when someone reports incorrect or outdated information. This would be very helpful in the process of fighting spam and abuse, and when you rely on the whois servers around the world to get the correct email address(es) so you may forward the abuse/spam to the correct department, but only to have if fail because of outdated data, is not useful in the process of reporting it. As an internet user myself, it is a pain to get so much spam and abusive emails. I'm tired of opening my mailbox on a daily basis, to see I've gotten not one, or two, but on average 75 spam messages a day. And simply telling my email provider, in this case it is Yahoo, that an email is spam/abuse, is not enough to stop it from coming into my mailbox. I now take the time to report it to the proper ISP that holds the IP address where the spam/abuse comes from, or sometimes its a potential virus that comes in the form of a URL/Web pages to visit. So, I rely on having correct data. Please look into developing a policy that will allow the ripe database managers the resources to contact ISP(s) when someone reports incorrect information, so that those of us, like me, who are tired of the amount of spam they get can have correct information when they go to look for it, instead of having to make phone contact with each individual ISP who happens to be international for me. I know that the whois database at www.arin.net has the resources to make contact when someone reports incorrect data, so why not follow suit and have the same resources to do the same thing. Sincerely, Matthew Brown RIPE Database Manager <ripe-dbm(a)ripe.net> wrote: To: BabyMatthew253 <babymattb253(a)yahoo.com> Subject: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: From: RIPE Database Manager <ripe-dbm(a)ripe.net> Date: Fri, 24 Aug 2007 10:25:14 +0200 Dear BabyMatthew253, Thank you for your email regarding out of date contact data in the RIPE database. There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity. If you feel this should have a higher priority then you may raise the issue on the Database Working Group or Antispam Working Group or Address Policy Working Group mailing lists. You can find information about the mailing lists here http://www.ripe.net/ripe/wg/index.html These are open working groups and views are welcomed from anyone who wishes to discuss relevant issues. Regards, Milena Rakin ____________________________ RIPE Database Administration. --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.

4 3

New Document available: ripe-416
by Filiz Yilmaz 12 Sep '07

12 Sep '07

Dear Colleagues, We previously announced that the policy proposal 2007-04, "IANA Policy for Allocation of ASN Blocks to RIRs" had been accepted by the RIPE community. This policy has now been published as a RIPE Document: ripe-416, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries" You can find this document at: http://www.ripe.net/ripe/docs/ripe-416.html Please note that this is a global policy and will therefore come into effect only after it has been accepted as a policy in all other RIR regions and then ratified by ICANN. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2007-04 Proposal Accepted (IANA Policy for Allocation of ASN Blocks to RIRs)
by Filiz Yilmaz 05 Sep '07

05 Sep '07

PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues Consensus has been reached, and the proposal described in 2007-04 has been accepted by the RIPE community. This proposal is to have a global policy for the Regional Internet Registries (RIRs) to receive blocks of Autonomous System Numbers (ASNs) from the Internet Assigned Numbers Authority (IANA). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html Thank you for your input. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Re: IPv6 addresses really are scarce after all
by Iljitsch van Beijnum 01 Sep '07

01 Sep '07

[CCing this to ARIN PPML and RIPE address-policy, but Reply-To: ietf(a)ietf.org, when replying, please pick just one list. Also, please read Thomas' entire original message at http://www1.ietf.org/mail- archive/web/ietf/current/msg47431.html ] [You may want to skip ahead to my point about the HD ratio at the end.] On 24-aug-2007, at 23:34, Thomas Narten wrote: > The fact is, the /48 boundary is _NOT_ architectural, True. However, this doesn't mean that /48 is completely arbitrary, either. /64 for subnets is based on the availability of 64-bit unique numbers in the form of MAC addresses that make it possible to have stateless autoconfiguration where a system always has the same address without the need for explicit coordination or configuration. People often attribute the fact that IPv4 addresses didn't run out in 2005 as predicted in the early 1990s to NAT, but there is another technique that is even more popular than NAT that also played in important rule: ethernet switching. Back when IPv6 was designed, it was common to have a substantial number of different subnets for different purposes to avoid having unnecessary large "collision domains". These days, you can easily throw hundreds, if not thousands of systems in a single subnet without performance penalties so most networks don't need all that many subnets. So the original goal of providing something a number of subnets that is large enough for 99.9% of all IPv6 users arguably required a /48 (65536 subnets). With 2000::/3 given out for global unicast purposes, that allows 2^45 / 48s, which should be more than enough to give all inhabitants of the planet their own /48 with a few to spare. So a /48 is both big enough for pretty much everyone, and small enough that we can give one to pretty much everyone. Last but not least, it's very useful to have a standard size, because then, if you go from one ISP to another, you're never in the situation where you need to renumber into a smaller block of address space, which is much, much harder than just replacing the first X bits of the address (where X is presumably 48). This was especially true in the presence of DNAME and bitlabels in the DNS. For those of you that don't know about this, it's rather complex and now obsolete, but around the turn of the century, this was a hot new mechanism to support easy renumbering in the DNS. (Read about it here http://www.apress.com/ book/supplementDownload.html?bID=10026&sID=3120 but don't say I didn't warn you.) So /48 was certainly "a good idea at the time". If we were doing all of this today, we could probably go a bit lower than 65536 subnets, such as 4096, but not THAT much lower. For instance, 256 subnets (/ 56) is still a very large number, so it assumes that people will be subnetting, but I'm not confident that it's enough for 99.9% of all future IPv6 users. Another issue is what we give to people who aren't going to build a network with subnets. The old recommendation was a /64 (= 1 subnet) for users who don't need to subnet. But unlike with IPv4, where end- users often get a single IP address and turn that into a subnet with NAT, with IPv6 you pretty much always need TWO subnets, although one of them can be shared. For instance, if I want to connect a bunch of computers in my home to my DSL line with IPv6, I need a /64 on my wifi network at home, but it's not really possible to use addresses from that same /64 between my ADSL modem and the DSL concentrator at the central office. As an ISP, I could set up one /64 to talk to all the DSL modems connected to a central office and then delegate a /64 to each user, but this is problematic for technical reasons (broadcasts/mulsticast vs NBMA) and control issues (which user does traffic from an address in that shared /64 come from). So if I were designing an ISP network, I would want to give at least two /64s or a /63 to every customer. In practice, it's much easier to go up a few bits and make it a /60, where I use one /64 for the SIP- customer link and the customer gets to use the other 15 subnets however they want. This way, I avoid getting support calls from people who want to have an extra DMZ subnet or different subnets for their wired and wireless networks. Again, as an ISP, I wouldn't want to think about how many subnets customers are going to use when they need more than that /60. Much easier to simply sell them a business account and give them a /48. Remember, every time a simple residential customer calls the support number, that costs an ISP the entire profit for that customer for a year. Avoiding support calls is one of the highest priorities for ISPs. > What the appropriate size of an assignment for an end site should be > is really more of an operational issue than architectural one. If a > site gets too little, and needs to get more later (maybe at the cost > of renumbering) that is an operational issue. And the idea that we can > give out "enough" address space to a site so that it doesn't have to > renumber (ever) is pretty silly. That doesn't mean it's impossible to pick sizes that are worse than others. And even though we have reverted back to simple use of the DNS with IPv6 where having the same address block size when going from ISP to ISP is less important, it's still beneficial to have as few block sizes as possible to that people don't have to go from big to small. > The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 > policy back in 2002. Even at that time, there was much screaming and > gnashing of teeth from the operator community saying "wasteful", > "excessive", "really stupid", etc. The wastefulness occurred when the IPv6 address size was set to 128 bits. This means that every IPv6 packet has to carry 32 bytes of address information. Now that we've eaten that cost, there is little use in trying to _use_ fewer of those bits that we're paying for with every packet. I can see how "/48 for everyone" could be considered too much (although 35184 billion of those aren't going to be used up any time soon) but can we at least retain "/48 for everyone who asks for one"? > If I assign 4M /48's of IPv6 (one to each cable modem on my > network), according to the HD-ratio I am justified to obtain > something around a /20 of IPv6 addresses. In other words, I am > justified in getting 268M /48's even though I am only using > 4M of > them. That would be enough for me to assign at least two for > every household in the US (not just the 19M on my network). Yes, this is a problem that the current policies, including the unofficial ones (for instance that ARIN reserves a /29 when an ISP gets a /32) don't address. Suppose a large ISP that operates across the US or Europe gets that / 20. So how are they going to announce that, as a single /20? I don't think so. They're going to deaggregate. And they can easily do that, because their block is much larger than the minimum /32 block that people are presumably going to be filtering on. In the degenerative case, which we can already see in IPv4, ISPs simply announce whatever they have as the smallest possible announcement. So that ISP that needs 4 million /48s = 64 /32s but gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs thought they would need to aggregate, while if the RIRs assumed that they wouldn't aggregate, they would have gotten the space in the form of a number of much smaller blocks and they would only have been able to announce 100 or so /32s. A much more appropriate policy would be to start with a certain minimum allocation, and then whenever someone comes back for more, give them a new block that is 2, 4 or 8 times as big as the previous block until a certain maximum block size is reached. For aggregation purposes, there is no benefit in having blocks larger than a /24, because by the time that a significant portion of the the IPv6 space ends up in the routing tables, having 2^24 routes won't be a problem. > The > community feedback was that LIRs were smart enough to make reasonable > assignments based on actual customer need. The trouble is that even more so than at the IETF, the RIR community as seen from the policy development process is whoever happens to show up. This means only a small part of all stakeholders provide input. > Surely, everyone will agree that > giving a /56 to home sites is more than enough space for the foresable > future! If /48 is too much for home sites then /56 is too much as well.

6 6

New E-Learning Module: The RIPE Policy Development Process
by Rumy Kanis 28 Aug '07

28 Aug '07

Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - The RIPE Policy Development Process This module explains how the process works and how you can take part in it. Once you have completed the module you will know how to: - Propose a new policy - Propose a change to an existing policy - Monitor policy discussions - Participate in policy discussions The RIPE NCC E-Learning Centre is a free-of-charge service available to everyone, and it can be found at: https://e-learning.ripe.net If you have any questions, please feel free to contact us at <e-learning(a)ripe.net>. Happy Learning, Rumy Kanis Training Services Manager RIPE NCC

1 1

RE: IPv6 addresses really are scarce after all
by jnc＠mercury.lcs.mit.edu 27 Aug '07

27 Aug '07

> From: "Hallam-Baker, Phillip" <pbaker(a)verisign.com> > Perhaps you could define the term subnet? "IP subnet", or "subnet" in the more general networking (outside-the-IP-community - the null set these days, I know) sense? For the first, originally, back in the days of class A/B/C "network numbers", it was a chunk of address space smaller than the "network" it was assigned from; it was used to provide addresses for a particular physical network. Now that we have CIDR, it seems to basically just means a chunk of address space assigned to a particular hardware network (the second meaning of "subnet"). For the second, it meant a particular physical network, i.e. the collection of end-stations which could send packets directly to each other without going through a router. This was before bridges, hubs, etc. Goodness knows what it means now! I'd suggest "multicast broadcast domain" as a good modern functional definition. Noel

1 0

2007-02 Policy Proposal Withdrawn (Change in IP Assignments for Anycasting DNS Policy)
by Filiz Yilmaz 27 Aug '07

27 Aug '07

PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy Dear Colleagues, Policy proposal 2007-02, "Change in IP Assignments for Anycasting DNS Policy" has been withdrawn. The proposer decided that there was insufficient support for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

RE: [address-policy-wg] PI for Not-DNS Anycast.
by Greg L. 13 Aug '07

13 Aug '07

I think that the PI /24 block should be assigned only to UDP related services as RFC suggests, however, I have yet to see the successful implementation of TCP data, state... replication in case one router withdraws BGP announcement of the /24 prefix. IPv4 anycast is a perfect way to distribute load and hopefully with lowest latency (not always true) for the following UDP related services: -syslog -dns -ddos mitigation The PI /24 anycast block should be assigned only when the applicant can demonstrate: at least 5 physically disperse locations (verification done by traceroute and checking the hop before the last hop in the traceroute). Traceroute's can be performed from open traceroute gateways (over the web etc - there are hundreds) or public ISP BGP route servers. to manage the server you will need a non anycast address(es), however, customers may keep this info secret if they do not want it to be public.... all anycast nodes must speak BGP to the upstream and in case the server goes down, the BGP router withdraws the BGP anycast /24 route Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;) My $0.02 cents... Greg http://www.LinuxAdmin.org

12 22