February 2010 - address-policy-wg

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

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

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