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

Fwd: Re: [address-policy-wg] Policy proposal 2009-01
by Axel Pawlik 14 Apr '10

14 Apr '10

On 14/04/2010 09:48, bmanning(a)vacation.karoshi.com wrote: > I believe you are correct Carlos. (1.) would potentially move > legacy IPv4 resource into the ARIN region from everywhere else > in the world. (*) Just a clarification... As this is a global policy proposal, all RIR regions would have to be in agreement for it to be implemented. In that case, yes, resources returned to IANA would later be re-allocated, possibly to other regions than they came from. As things stand today, with the ARIN community having agreed on a different text than the other RIRs' communities, this proposal fails as a global policy; which means that it will not be implemented. cheers, Axel > > * Except some places which have their own legal restrictions on > movement of IP space outside thier politicial boundaries. When > I was on the ARIN BoT, I seem to remember a few countries which > placed such laws on their respective books. It was generally > considered to be a bad idea ... and yet ARIN seems to have > followed suit. > > --bill > > > On Wed, Apr 14, 2010 at 08:18:33AM +0100, Carlos Friacas wrote: >> >> Hello, >> >> Going forward with (1.) means that potentially recovered space within >> RIPE-land can end up in the hands of someone inside ARIN-land ??? >> >> Imho, those who wish not to contribute should not have access to the >> recovered resources. Solidarity (even if it's about a legacy resource...) >> sounds like a positive thing, however, if it's possible for >> non-contributors to benefit, another word comes to mind. And in that case >> i would be in favour of (3.) or (4.). >> >> >> Regards, >> Carlos >> >> >> On Tue, 13 Apr 2010, Nigel Titley wrote: >> >>> Folks, >>> >>> As one of the authors of this proposal I'd like to get some sort of >>> consensus together in the RIPE region so that we can move forward. >>> >>> All other regions have reached consensus and we are the last to do so. >>> >>> All other regions with the exception of Arin have adopted the policy in >>> it's original form. Arin has modified the policy to remove the mandatory >>> return of recovered address space to IANA, which effectively makes it a >>> different policy. 2009-01 is a global policy which means that the same >>> policy has to be agreed in all regions, so to all practical purposes it >>> is doomed already. However, we still need to decide what to do with it >>> in the RIPE region. To my mind there are four possibilities: >>> >>> 1. We adopt it in its original form thus demonstrating solidarity with >>> the other regions, apart from Arin. >>> >>> 2. We adopt the Arin form of the proposal, thus demonstrating solidarity >>> with Arin, but with no one else >>> >>> 3. We reject the proposal outright, thus demonstrating that we can't >>> make up our minds or that we think it will never work, or something... >>> >>> 4. We ask the regional authors (in this case myself and Axel) to >>> withdraw the proposal in this region. >>> >>> Some background may be helpful here. No one seriously expected that any >>> address space would actually be returned as a result of this policy. It >>> was intended as a statement that should IPv4 address space become >>> available then it would be used for the greater good of all the >>> registries rather than those who had already had the majority of the >>> space already. I realise that this was a rather pious hope, but we felt >>> that it was worth making a statement about. >>> >>> The Arin region's position has made it impossible to make this statement >>> globally, but we still have the opportunity to make it here. I would >>> like to solicit the opinions of this working group in order to try and >>> put the matter to bed once and for all. >>> >>> I realise I'm making rather contentious statements here, but I'm hoping >>> to provoke a bit of discussion. Please can the working group indicate >>> how they would like to move this forward. >>> >>> All the best >>> >>> Nigel >>> >>> > >

4 4

2008-06 (Use of final /8) and 2009-04 (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) Policy Proposals Withdrawn
by Ingrid Wijte 13 Apr '10

13 Apr '10

PDP Number: 2008-06 Use of final /8 PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment Dear Colleagues These proposals have been withdrawn. They are now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2008-06.html http://www.ripe.net/ripe/policies/proposals/2009-04.html The authors decided that they want to make a new proposal (see proposal 2010-02). Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

80% rule, based on feedback from the NCC RS department
by Gert Doering 07 Apr '10

07 Apr '10

Hi APWG, one of the issues pointed out by Alex le Heugh from the RIPE NCC RS department at the last RIPE meeting was the "80% rule" for additional IPv4 allocations, which has multiple, contradictory definitions in the current address policy documents. See here: http://www.ripe.net/ripe/meetings/ripe-59/presentations/leheux-rough-edges-… on page 17-21 and http://www.ripe.net/ripe/docs/ripe-484.html, section 5.3 and 5.4 The different sections of the policy text both describe the rule slightly differently. This makes it unclear how the 80% rule should be applied. Let me explain by example: - a LIR has a /16, which is at 95% utilization, and a /19 that is at 40% utilization. Over all their address space, the utilization would be 88%. - interpretation 1: "if a LIR holds multiple allocations, every *single* of them needs to be filled by 80%" would result in "the LIR will not get a new allocation, because the /19 is only at 40%" - interpretation 2: "if a LIR holds multiple allocations, the grand total of them needs to be filled by 80%" would result in "the LIR *will* get another allocation, because they have used 88%". Personally, I think that the interpretation according to 5.3 of the IPv4 address policy document ("interpretation 2") is the intention of the policy. 5.4 (sub-allocations) was added later, and has language about the 80% criteria that is misleading - this section is only concerned about sub-allocations, and "the 80% sentence" was put in there to emphasize the existing rule, not to change it (I know that from the proposer of this policy change...). Now, "just changing the text according to what the WG chair thinks" would not be the right thing - so what I think is the way forward now is to get feedback from *you*, and if there is clear guidance from the working group on resolving this ambiguity, we run a formal proposal to change the wording of the document in one way or the other. (Please don't get into sidetrack discussions on whether "80%" or "IPv4" is useful, but focus on this specific question.) thanks, and regards, Gert Doering, APWG Chair -- Total number of prefixes smaller than registry allocations: 144438 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

6 5

Re: Easy to remember IP-address
by Sergey Gotsulyak 07 Apr '10

07 Apr '10

Jim Reid wrote: > I'm not sure Shane that an allocation of vanity addresses would fit > with these goals. If it does, then fine. Though I'm doubtful. If > there were "too many" vanity assignments, that may well fragment the > unused space in a way that prevents another LIR getting a contiguous > allocation that's big enough for their genuine technical needs. It > might also encourage a land-grab by people gobbling up vanity space > that they don't actually need in the hope that they could sell it on > later. Jim, I fully understand this concern. An overly large number of assignments might fragment the address space and lead to people trying take advantage of an opportunity to resell addresses. Something like Cybersquatting that is practiced with domain names. However I think that the RIPE community is capable of stopping that. That would require formal and very serious requirements for requesting vanity addresses for certain projects that will benefit the people. Honestly, I'm not even sure that there will be so many people interested in getting such ip-addresses if the process is a formal and not a simple one. Besides, we would very much like for our request to be reviewed by the committee from RIPE NCC in a speacial manner. Because we're requesting these addresses not for resale or direct monetary benefit and think that if we're given them all parties are going to win. We're trying to make the internet a safer place for millions of people and improve the present technical infrastructure at the same time by creating a distributed network of available and effective DNS-servers in Russia and Europe. I can't speak for Europe but in Russia and its neighboring countries the existing DNS-structure has a lot of problems such as slow channels and outdated equipment, lack of DNSSEC support and protection from attacks. All this we want to change. -- Kind regards, Sergey Gotsulyak

3 2

Re: Easy to remember IP-address
by Sergey Gotsulyak 06 Apr '10

06 Apr '10

Shane Kerr wrote: > To be clear, we're not talking about anyone getting more or less address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? > The RIPE NCC does not have any restrictions on which particular > resources it allocates or assigns. In fact, I am pretty sure that any > sensible person would argue that the RIPE NCC should have as much > freedom as possible to do things in the most efficient way. So I think > the RIPE NCC already has the power to issue "vanity addresses" in the > rare case where someone asks for these. As far as we're concerned we're going to follow all the necessary requirements and formalities needed for assignment of a block of IP-addreesses. We're ready to apply throught a standard procedure from the name of our company, or through one of the present LIRs. We could even get a status of a LIR for our company if needed and pay the initial fee and yearly fees. We hope that an assignment of the minimal IP block of addresses 2.2.2.0/24 (or 2.2.2.0/21) will not cause any routing problems, because the availability of this address from any part of the world will be achieved throught BGP Anycast. > Mostly I find it a pity that the NCC wasn't more accommodating and that > we're having this discussion at all. Maybe the software used for this > process does not have a manual override or something? Oh well, compared > to the horror stories I hear about the bad old days, I guess we have no > complaints.... We're trying to figure out if there are any reasons that make an assignment of the requested range technically challenged, but apparently there are any restrictions. According to this experiment of APNIC, described in the RIPE blog: http://labs.ripe.net/content/pollution-18, engineers from the APNIC or RIPE NCC have a certain freemdom in experimenting with undistributed addresses like 1.1.1.1 (2.2.2.2) ? That means that theoretically it is possible to manually enter data in the RIPE database and manually distribute address 2.2.2.2 for it to find a really beneficial application for the internet community, and not just go away to another company that sets up something like DSL-connection pool, because for them vanity addresses are totally irrelevant. I'd like to point it out one more time that we're talking about a very useful and free DNS service for the end-users, that will allow millions of people from Russia and Europe to speed up DNS-requests and filter out untrustful websites like with malware and phishing content... Besides, we hope to provide services for parents preventing children from accessing forbidden websites. This alone will benefit millions of internet users too. -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz(a)idecogateway.com Web: www.idecogateway.com

6 6

Re: [address-policy-wg] Easy to remember IP-address
by Sergey Gotsulyak 05 Apr '10

05 Apr '10

Shane Kerr wrote: > To be clear, we're not talking about anyone getting more or less address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? > The RIPE NCC does not have any restrictions on which particular > resources it allocates or assigns. In fact, I am pretty sure that any > sensible person would argue that the RIPE NCC should have as much > freedom as possible to do things in the most efficient way. So I think > the RIPE NCC already has the power to issue "vanity addresses" in the > rare case where someone asks for these. As far as we're concerned we're going to follow all the necessary requirements and formalities needed for assignment of a block of IP-addreesses. We're ready to apply throught a standard procedure from the name of our company, or through one of the present LIRs. We could even get a status of a LIR for our company if needed and pay the initial fee and yearly fees. We hope that an assignment of the minimal IP block of addresses 2.2.2.0/24 (or 2.2.2.0/21) will not cause any routing problems, because the availability of this address from any part of the world will be achieved throught BGP Anycast. > Mostly I find it a pity that the NCC wasn't more accommodating and that > we're having this discussion at all. Maybe the software used for this > process does not have a manual override or something? Oh well, compared > to the horror stories I hear about the bad old days, I guess we have no > complaints.... > In the end I suppose we can just let the addresses fall wherever and let > "the market" sort it out, now that there is a "trading" policy. While > the desire for vanity addresses might accelerate the process of IP > addresses becoming property, that is probably inevitable, so it won't > change the big picture too much. -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz(a)idecogateway.com Web: www.idecogateway.com

1 0

Re: Easy to remember IP-address
by Sergey Gotsulyak 05 Apr '10

05 Apr '10

Shane Kerr wrote: > As for actually getting the RIPE NCC to issue a resource based on a > request... I think there are two ways to go about this. One is making it > a POLICY matter, and going through the PDP and updating the relevant > documents. The other is solving it PROCEDURALLY, which basically means > convincing the RIPE NCC to accept special requests and handle them when > possible. Very interesting idea. If there is a way to solve our issue PROCEDURALLY, that means there's no need to alter the present POLICY. > In summary: > * I support allowing people to request specific unused resources > * I hope that can be done without a policy change In fact we originally hoped to solve our issue in this manner, when we addressed RIPE directly. Do you know of any similar requests in the past? How were they solved? Who can we refer to in RIPE NCC with this request? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz(a)idecogateway.com Web: www.idecogateway.com

1 0

2010-02 New Policy Proposal (Revoke and Re-assign Fairly)
by Nick Hilliard 02 Apr '10

02 Apr '10

Number: 2010-01 Policy Proposal Name: Revoke and Re-assign Fairly Author: Nick Hilliard, INEX Proposal Version: 1.0 Submission Date: 1 April 2010 Current Phase: Discussion - Open for Discussion Phase ends/ended: 1 April 2010 Latest Status: Initial Community Discussion Suggested WG for Discussion and Publication: Address Policy Proposal Type: New Policy Term: Indefinite Policy Documents to be Affected: * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC Service Region (ripe-492) Summary of Proposal: This proposal revokes all previous IPv4 LIR allocations and direct / LIR assignments, returning all ERX and RIPE NCC-assigned IPv4 address space back to the RIPE NCC, where it can be re-assigned fairly, using new policies and guidelines. The RIPE NCC has been acting as RIR in the European / Middle-East geographical areas since 1989. Due to egregiously lenient policies and gross end-user address wastage, in combination with a more recent tendency to horde IPv4 addresses in anticipation of a future shortage, recent research has suggested that approximately 97% of IPv4 address assigned and allocated through the RIPE NCC aren't actually used at all, and never were. Furthermore, this research suggests that if all this address space were returned to the RIR for re-assignment, this would create enough slack space in the IPv4 address pool to service all future requests in the RIPE NCC service region for approximately 100-150 years, based on current actual run-rate, rather than the current fantasy figures published by the RIPE NCC. Also included as part of this policy is a future restriction to limit all future direct assignments to 640 IPv4 address, because that should be enough for anyone. Policy Text: a. Old text Remove sections 5, 6 and 7 in RIPE 492. b. New policy text Insert new section 5 in RIPE 492: -- 5.0 Policies and Guidelines for Allocations and Assignments An allocation is a block of IPv4 addresses from which assignments are taken. All allocations and assignments made prior to April 1, 2010 are hereby revoked, cancelled, and made null and void. LOL!!11!!!1! The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that that should be more than enough for anyone. PI assignments requests will be greeted with even more giggles than they currently are. -- a. Arguments supporting the proposal Every LIR and PI holder is hoarding address space like there's no tomorrow. By forcing a reboot of the entire registry system, every holder will be equally wrong-footed, and will realise that there's no need to hoarde address space after all. This policy will have the side effect of ensuring that this insane rush to IPv6 is entirely unnecessary, proving beyond all doubt that the ITU seriously has no clue when it comes to Internet resource assignment. b. Arguments Opposing the Proposal It is likely that nay-sayers and other party-poopers will come out of the wood-work to bleat about how this proposal is unfair. The author advises that they get a life and stop hoarding numbers. After all, they're only numbers. And if they really need more, they can contact me directly (see contact details above). Some companies will attempt to claim that they have more than 640 customers. Clearly, this can't be true because any company with more than 640 customers would be making a profit, which everyone knows to be a ridiculous claim.

13 14

Re: [address-policy-wg] Easy to remember IP-address
by Sergey Gotsulyak 01 Apr '10

01 Apr '10

Gennady, are you trying to say that Google doensn't know the best marketing techniques? P.S: Google has chosen for their DNS-service an easy to remember 8.8.8.8 address ;-) > Remembering domain names and IP addressess are absolutely different > things. Domain names are on the user level, IP addressess are not. > Let's not make such "dirty hacks" to multi-level networking model :) > (I avoid "7-level OSI model" phrase here). > So, it's bad idea to build PR/marketing campaign based on "beautifull" > IP-address. It's something like beautifull (from user, not engineer > view) design of motherboards, gearboxes, etc.. It may be fine, but not > more, there is a lot of more important things user should consider > about. > I completely can't understand, why you so need "easy-to-remember" > addressess and don't you have a better way to make your services more > user-friendly and PRable.

2 1

Easy to remember IP-address
by Sergey Gotsulyak 01 Apr '10

01 Apr '10

Gentlemen, Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 address space for our DNS-service and he advice me to contact this workgroup. Our company Ideco is located in Russia and is in the business of developing and selling Internet gateways for small and middle businesses in Russia as well as billing software for ISPs. We’re now starting a new project for Russia and Eastern Europe that will provide secure Internet access for educational institutions, commercial and non-profit organizations. We’re planning to set up a number of DNS-centers that will block malware, adult websites and phishing links. For this project we’ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8) We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range. Is it possible to modify current Address Policy? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz(a)idecogateway.com Web: www.idecogateway.com

13 21

2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies)
by Ingrid Wijte 18 Mar '10

18 Mar '10

PDP Number: 2010-01 Temporary Internet Number Assignment Policies Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-01.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 April 2010. Regards Ingrid Wijte Policy Development Officer RIPE NCC

5 9

IPv6 allocations for 6RD
by Jan Boogman 11 Mar '10

11 Mar '10

Hi, we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD. (see <http://tools.ietf.org/html/draft-townsley-ipv6-6rd-01> or for a working implementation Free's presentation at RIPE-58: <http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.p…>). We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet). The IPRA now isn't sure how to proceed and after consultation with the Policy Development Manager asked me to pose the question to the community at large. What do you think, should RIPE NCC allocate larger than /32 blocks to LIRs for cases like this and not only based on the number of end-customers? Cheers Jan Swisscom IP-Plus - AS3303

13 34

Re: [ncc-services-wg] Status Update - Independent Resource Assignments (Policy Proposal 2007-01)
by David Monosov 09 Mar '10

09 Mar '10

Dear Andrew, ncc-services-wg, address-policy-wg, Thank you kindly for this update, it is encouraging to see the success of this initiative. I can't help but notice that the number of marked resources you provide in this report appears to be significantly lower than that in a similar report Andrea Cima provided to address-policy-wg on 26/10/2009 (the previous report states 23,790 resources are marked, while only 22,958 are reported as marked in this update). Could you please elaborate on the nature of this adjustment? Additionally, it has been previously mentioned that a procedural document detailing Phase 3 of the implementation of this proposal will be made available before implementation begins. Seeing that the final deadline is less than two months and a fortnight away, how soon can we expect this document to be available, and are there any operational specifics you can already share with us? -- Respectfully yours, David Monosov Andrew de la Haye wrote: > Dear Colleagues, > > In March 2009, the RIPE NCC began Phase 1 of the policy implementation > "Contractual Requirements for Provider Independent Resource Holders in > the RIPE NCC Service Region". This phase focused on new assignments of > independent Internet number resources only (PI assignments, AS Numbers, > IPv6 Internet Exchange Point (IXP) assignments and Anycasting > assignments). The implementation was carried out successfully and the > majority of RIPE NCC members are aware of the policy and contractual > requirements and are able to provide the necessary documentation when > requesting independent resources on behalf of their End Users. > > Phase 2 of the policy implementation began at the end of May 2009. This > phase focuses on existing assignments (almost 27,000). In the first step > of this phase, the RIPE NCC approached LIRs and asked them to specify > whether: > - The resources were used for the LIR's network infrastructure > - The resources were used by one of the LIR's End Users > - The End User was no longer the LIR's customer > > LIRs must provide documentation for the resources marked as "My End > User" by the end of Phase 2. This documentation should be the "End User > Assignment Agreement" between the LIR and the End User regarding the > registration of the independent Internet resources the End User holds > and the official company registration documents of the End User > organisation. > > Initially, Phase 2 was scheduled to end on 31 December 2009. However, > due to the lower-than-expected number of documents received, the > deadline was first extended until 1 March 2010 and then until 17 May > 2010, which will be the final deadline. > > > The figures showing the progress of Phase 2, as of 1 March 2010, are > presented below. > > > LIRs Participating > ----------------------- > Total LIRs to participate in Phase 2: 4,903 > Number of LIRs participated at 1 March: 4,178 > Percentage of participating LIRs: 85.2% > > > Total Resources Marked > ------------------------------ > Total amount of resources to be marked in Phase 2: 26,940 > Total amount of resources marked at 1 March: 22,958 > Percentage of resources marked: 85.2% > > > Status of 22,958 Resources Marked > ------------------------------------------ > - 5,373 are marked "My Infrastructure" (23.4%) by 3,956 LIRs > - 6,025 are marked "Not My End User" (26.25%) by 712 LIRs > - 11,560 are marked "My End User" (50.35%) by 996 LIRs > > > Status of 11,560 Resources Marked "My End User" > ------------------------------------------------------------- > - 4,849 have missing documents (42%) > - 4,522 have submitted documents (39%) > - 2,189 have approved documents (19%) > > > Regards, > Andrew de la Haye

2 1

followup on RIPE 59: feedback from the RS department
by Gert Doering 26 Feb '10

26 Feb '10

Hi APWG, at the last RIPE meeting in Amsterdam, I asked the RIPE NCC RS department to provide feedback to us regarding the day-to-day working with our policies. We make the policies, but we don't really know how well they work (especially for the great mass of LIRs that don't participate in the policy-making process) unless we get feedback. Alex Le Heux from the RIPE NCC volunteered, and reported the top three issues that cause the most questions and discussion between RS and the LIRs requesting resources. See here for the details: http://www.ripe.net/ripe/meetings/ripe-59/presentations/leheux-rough-edges-… The three issues were: - differences between IPv4 and IPv6 policy - interpretation of the AS number policy - interpretation and wording of the 80% rule At the meeting, we discussed only one of these (the interpretation of the AS number policy, see page 10-16 in the PDF), because we ran out of time - and instead of rushing all three items, the WG chairs decided to focus on one, and bring up the other two on the list. Regarding the interpretation of the AS number policy, feedback from the audience in the room (plus comments in the hallways) was quite clear - everybody who voiced their opinion argued that a LIR that can document multiple distinct routing policies is entitled to multiple AS numbers, even if it's the same organization running all of the network(s). So the Registration Services department was asked to accept multiple AS requests for the same organization if an individual unique routing policy can be documented. For details of this discussion, please see the APWG R59 minutes: http://www.ripe.net/ripe/wg/address-policy/r59-minutes.html Next steps: the WG chairs will bring up the other two items to the AWPG mailing list in the next days. We need to get feedback from the community on the intent and interpretation of the current policy, and if the result is that the current policy is not really what the community wants, get the necessary changes under way. regards, Gert Doering, APWG Chair -- Total number of prefixes smaller than registry allocations: 144438 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 0

New Draft Document: Autonomous System (AS) Number Assignment Policies
by Filiz Yilmaz 16 Feb '10

16 Feb '10

Dear Colleagues, At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced that it would undertake a project to improve the language of various RIPE policy documents, without changing their substance or meaning. This project is aimed at improving the clarity and readability of RIPE Documents. For more information, see: http://www.ripe.net/ripe/updated-documents/ A draft of the first RIPE Document to be revised is now available: "Autonomous System (AS) Number Assignment Policies and Procedures". We have published the draft document in two layouts. The first layout contains only the proposed text, in full, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v1.html The second layout contains both the current text and the proposed text side by side, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v2.html At the top of both draft documents there is a summary of the proposed changes. There are two changes we would like to highlight because they constitute a slightly larger change. Paragraph 4.0 - Returning AS Numbers Excerpt from current version: "If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers..." Excerpt from proposed draft: "If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers." The main difference is that the current version says the AS Number "can" be returned, while the draft version says the AS Number "must" be returned. The change was made to better reflect the intention of the policy and to be consistent. In other policy documents, for other Internet resources, the wording of the policy states "must". The other larger change is the addition of the following paragraph: Paragraph 5.0 - Validity of an Assignment This paragraph is copied from the IPv4 policy document ("IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"). As this seems to be a shared policy principle, applicable to all Internet resources, we feel it is appropriate to add this text to the AS policy document, both for clarity and consistency. Other smaller changes are listed at the top of document. Please review the text and send your feedback to the Address Policy Working Group mailing list. The period for review is four weeks and lasts until 26 February 2010. After the review period, the Address Policy WG chairs will conclude whether or not there is consensus on the draft document. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC

5 5

ripe-484 Republished as ripe-492
by Filiz Yilmaz 16 Feb '10

16 Feb '10

Dear Colleagues, During the last update of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-484), some text was overlooked. The missing text, which comes from the accepted proposal "Run Out Fairly" (2009-03), has been restored and an updated document has been published as ripe-492. You can find this document at: http://www.ripe.net/ripe/docs/ipv4-policies.html We apologise for any inconvenience. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC

1 0

نشره تراتيل حليم الادبيه
by منتديات تراتيل حلم الادبيه 16 Feb '10

16 Feb '10

<http://www.tr-7lm.com/vb/> [image: بسم الله الرحمن الرحيم 30] مختارات من اجمل مواضيع منتديات تراتيل حلم الادبيه هديه لآعضاء التراتيل بالداخل ..حصريه http://www.tr-7lm.com/vb/t7137.html تصميم حصري لتراتيل حلم http://www.tr-7lm.com/vb/t7296.html تصميم أصعب سؤال؟حصري http://www.tr-7lm.com/vb/t6757.html جيتك وانا كلي ندم .. ياربي منك التووبه .. http://www.tr-7lm.com/vb/t6354.html شات مع البخاري ومسلم !! http://www.tr-7lm.com/vb/t3929.html مسابقه اجمل قلم http://www.tr-7lm.com/vb/t5926.html إلىـا حَضرِة سُموِ {ِ الحِ‘ـَزِنْ }ِ ..}~ http://www.tr-7lm.com/vb/t5751.html توبيكات تراتيل حلم http://www.tr-7lm.com/topic/ مسابقة التحدي الكبرى مسابقة الدعوات لأعضاء مجموعة ومنتديات تراتيل حلم لا تفوتك فرص الربح ‏( جوائز قيمه ) http://www.tr-7lm.com/vb/t3195.html#post18396 <http://www.tr-7lm.com/vb/> -- لإلغاء الاشتراك في هذه المجموعة، ابعث برسالة إلكترونية إلى almhmad+unsubscribe(a)googlegroups.com

1 0

How polluted is 1/8?
by Mirjam Kuehne 03 Feb '10

03 Feb '10

[Apologies for duplicates] Dear colleagues, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne

1 0

32-bit AS Number status?
by Shane Kerr 01 Feb '10

01 Feb '10

All, I noticed that the proposed updated AS Number policy was sent to the address-policy-wg recently. There is a timeline for 32-bit AS Number in both the old and new versions, which says: "From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool." I'm not sure exactly what this means, but I think it is supposed to mean that people get 32-bit AS Numbers now. Did this happen? If it didn't, why not? Do we need to change "2010" to "2011"? Is it ever going to happen? If it did, was there any effect? I mean both from humans (angry LIRs, peasants marching on the castle with torches, riots in the streets), or on the Intertubes (ugly routing artifacts, mass reboots of boxes with old firmware, monitoring systems gone wild)? Just wondering. :) -- Shane

5 5

2009-03 "Run-out fairly" implemented
by Xavier Le Bris 21 Jan '10

21 Jan '10

[Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce that the policy described in proposal 2009-03,"Run Out Fairly", has been implemented. Requests for IPv4 address space received on or after Friday, 22 January will be evaluated by the RIPE NCC Registration Services Department under the new policy. Full text of the policy proposal can be found at: http://ripe.net/ripe/policies/proposals/2009-03.html The following RIPE documents have been updated to reflect this policy implementation: http://www.ripe.net/ripe/docs/ripe-488.html http://www.ripe.net/ripe/docs/ripe-489.html http://www.ripe.net/ripe/docs/ripe-490.html http://www.ripe.net/ripe/docs/ripe-491.html Regards, Xavier Le Bris Registration Services

1 0

IPv6 PI for HOSTING
by Max Tulyev 05 Jan '10

05 Jan '10

Hi All, I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;) The main problem in IPv6 implementation in the real life is a lack of resources. A lot of ISPs (including our company) providing broadband and corporate access to IPv6 Internet. And now it is running globally, pings are pinging, traces are tracing... and so what? The main question users ask us "and so, what we can do with that new IPv6 Internet?". The answer is NOTHING! There is almost NO RESOURCES in IPv6 net! No sites, no pages, no freemails - NOTHING! This makes IPv6 Internet absolutely USELESS for users. Really, unlike us, they do not become happy running bgpd and traceroute6. They need web resources. So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out? Let's go forward. Yes, a few hosters I know are big companies, LIRs, trade their traffic and so on. But majority are small companines have from one server to one-two racks of hosting servers. They will never become a LIR only for [useless now] IPv6 address space. But they host a huge piece of resources need by a lot of regular users. Yes, IPv6 can provide hosting users a lot of good things, such as unique IP for every site, FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on - this sure will stimulate them to move to IPv6. Yes, some of hosters are ready to obtain IPv6 network and play with it right now. And NO, most of them don't want to use upstream's networks, as there is almost impossible to change it after hundred of thousands of domains are linked with this network. So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

9 20

List of IPv6 measurements published on RIPE Labs
by Mirjam Kuehne 10 Dec '09

10 Dec '09

[I am sorry if you receive this more than once.] Dear colleagues, Please see two articles related to IPv6 Measurements recently published on RIPE Labs: 1. A list of IPv6 measurements various people and organisations are doing with a short description and pointers to the actual results of the measurements http://labs.ripe.net/content/ipv6-measurement-compilation 2. An interview with Alain Durand about the IPv6 measurements he is doing at Comcast together with the University of Pennsylvania http://labs.ripe.net/content/ipv6-monitor We would like to get feedback from you about the measurements presented. How would you chose to measure the growing deployment of IPv6? Have you set criteria for when you will deploy IPv6? Let us know what information and analysis would be helpful to assist you in the deployment of IPv6. And would measurements influence your decision to deploy IPv6 or not? Please go to the forum at http://labs.ripe.net/node/ipv6-measurements or contact me directly at labs(a)ripe.net. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

2009-08 Implementation: IPv6 PI Assignments for LIRs
by Nathalie Trenaman 10 Dec '09

10 Dec '09

[Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2009-08,"IPv6 Provider Independent (PI) Assignments for LIRs", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-08.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ipv6-policies.html The following document has also been updated to reflect this policy implementation: http://ripe.net/ripe/docs/ipv6-pi-support.html Regards, Nathalie Trenaman Registration Services RIPE NCC

1 0

2006-01 IPv6 PI implementation
by Sergey Myasoedov 09 Dec '09

09 Dec '09

Hello, can anyone explain me is there a restriction in policy for assigning /48 PI IPv6 to ISP which will use /64-/128 prefixes to connect broadband customers? -- Sergey

3 2

RE: IPv6 allocations for 6RD
by Milton L Mueller 07 Dec '09

07 Dec '09

> 3.5. Conservation and Administrative Ease > Although IPv6 provides an extremely large pool of address space, > historical evidence shows that what now seems infinit might one day > turn out to become a scarce resource, Address policies should avoid > unnecessarily wasteful practices of such resources. Requests for > address space should be supported by appropriate documentation and > stockpiling of unused addresses should be avoided. Assignment of > address space based on the sole argument of administrative > ease is not permitted. Examples of this include, but are not limited > to, ease of billing administration and network management. I strongly agree with the concern that v6 addresses could be depleted quickly. This problem will never be solved appropriately until you impose fees for addresses that increase with the size of the block being requested. What you seem to be learning, the hard way, is that charging nothing for addresses requires you to ration the address space using highly subjective and purely verbal, unquantifiable criteria. Such as, the term "unnecessarily wasteful" which manages to be both tautological and unprecise. Or the term "administrative ease"; ok, after that becomes a policy no one will admit that they are requesting addresses for administrative ease but will that actually alter their request? Appropriately graduated annual fees enforce conservation AND reclamation while relieving the allocator of engaging in these verbal and categorical games Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org

7 7