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

2009-03 Proposal Accepted (Run Out Fairly)
by Ingrid Wijte 07 Dec '09

07 Dec '09

PDP Number: 2009-03 Run Out Fairly Dear Colleagues Consensus has been reached, and the proposal described in 2009-03, "Run Out Fairly" has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-484.html You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html The RIPE NCC will implement this new policy within one month. Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

Re: Ha: [address-policy-wg] RE: an arithmetic lesson
by Remco van Mook 03 Dec '09

03 Dec '09

To upset some more sentiments; compare v4 /24s with the available v4 unicast; do the same with v6 /24s and current v6 unicast space. Rough arithmetic shows then that in that line of reasoning, a v6 /24 is more comparable to a v4 /20. Remco ----- Original Message ----- From: address-policy-wg-admin(a)ripe.net <address-policy-wg-admin(a)ripe.net> To: Dmitriy V Menzulskiy <DMenzulskiy(a)beeline.ru> Cc: michael.dillon(a)bt.com <michael.dillon(a)bt.com>; address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Sent: Thu Dec 03 14:20:22 2009 Subject: Re: Ha: [address-policy-wg] RE: an arithmetic lesson On Dec 3, 2009, at 7:55 AM, Dmitriy V Menzulskiy wrote: > > > > > > On 3 Dec 2009, at 10:00, <michael.dillon(a)bt.com> wrote: > > > > > > > an IPv6 /24 and an IPv4 /24 use up the same percentage of the > total > > > > address space. > > > > > > How do you work that out? Please enlighten me. 2^24/2^128 x > > > 100 is many orders of magnitude smaller than 2^24/2^32 x 100: > > > gromit% bc > > > scale=50 > > > 2^24/2^128*100 > > > .00000000000000000000000000000493038065763132378300 > > > 2^24/2^32*100 > > > .39062500000000000000000000000000000000000000000000 > > > > > > There are of course the same number of IPv4 and IPv6 /24s. > > > > Percentage is calculated by dividing the number of things > > under consideration by the total number of things. When > > I used the word "an", I meant one thing. > > > > Assuming that the number of IPv4 and IPv6 /24s is 10 > > > > 1/10 = 1/10 > > > > Assuming that the number of IPv4 and IPv6 /24s is 8192 > > > > 1/8192 = 1/8192 > > > > Assuming that the number of IPv4 and IPv6 /24s is 2882873787 > > > > 1/2882873787 = 1/2882873787 > > > > Do you see a pattern forming? > > > > --Michael Dillon > > > > As I understand: > > IPv4 /24 is (Total IPv4)/(2^24) > IPv6 /24 is (Total IPv6)/(2^24) > > Or not ? > Not. The ratio you want, using your formalism, is (2^(size of address space - 24)) / (Total IPvX) which is 2^(N - 24) / 2^N = 1 / 2^24 (where N is the number of bits in the address space). Regards Marshall > > WBR, > > Dmitry Menzulskiy, DM3740-RIPE > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.

3 4

Re: [address-policy-wg] IPv6 allocations for 6RD
by Rémi Després 03 Dec '09

03 Dec '09

Le 27 nov. 2009 à 17:16, Rémi Després a écrit : > Mikael Abrahamsson wrote: > > I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28. The objective of 6rd has been to make native IPv6 connectivity quickly available to millions of residential customers. For this, it was important to relieve the first concerned ISP of fear, uncertainty, and doubt, concerning expenses to be incurred. This objective has been brilliantly achieved when Free, after only 5 weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 is available to our customers who wish to activate it with a click". If promoting IPv6, not only with words but also in reality, is considered a legitimate objective, then it is fair to view 6rd as a "good design" for what it was set to achieve. Similarly, what Free did should be seen as a "remarkably fast and effective implementation". No hard feelings, but I felt this needed to be said. Regards, RD (Inventor of 6rd, no professional link with Free.)

22 80

Allocated net 109.48/14 having problems accessing aome web sites
by Luis Cunha 02 Dec '09

02 Dec '09

Hello, ZON is a major ISP in Portugal, and the complains from customers with an IP address within 109.48/14 trying to access some web sites is increasing daily. Anybody with a solution different from sending a mail to each webmaster? Regards, Luis Cunha

1 0

RE: [address-policy-wg] IPv6 allocations for 6RD
by Mark Townsley 30 Nov '09

30 Nov '09

All, My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging. At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of them want to go this route, but some do, and I’m thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever. The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases. Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time. As for the status of 6rd in the IETF, draft-townsley… is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt. Many Thanks, - Mark

13 20

Securing Routing Information
by John Schnizlein 17 Nov '09

17 Nov '09

FYI, here's a report from a group of operators who got together and discussed the issues. http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf John

1 0

(draft) Minutes from RIPE 59 are now online
by Gert Doering 16 Nov '09

16 Nov '09

Dear APWG participants, the (draft) minutes of the APWG meeting at the RIPE meeting in Lisbon are now online: http://www.ripe.net/ripe/wg/address-policy/r59-minutes.html If you have been at the meeting, please check that everything is as you remember (so we can declare the minutes final at RIPE60), and let us know if something needs changing. If you have NOT been at the meeting, please feel free to read up what we have discussed. We have made a few decisions at the meeting, how to deal with ongoing issues, and I will announce these individually over the next weeks. A big thanks goes to the minute takers from the RIPE NCC! 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

Andrea Borgato
by Manfredo Miserocchi 05 Nov '09

05 Nov '09

Dear all, I've just received a phone call saying that Andrea isn't with us any more. For those who didn't know him, he was a real RIPE Community man for a long time, co-chairing this WG too. Friends can contact me directly (mis(a)wari.net). Thanks Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.

1 0

Andrea Borgato
by Manfredo Miserocchi 05 Nov '09

05 Nov '09

Dear all, I've just received a phone call saying that Andrea isn't with us any more. For those who didn't know him, he was a real RIPE Community man for a long time, co-chairing this WG too. Friends can contact me directly. Thanks Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.

1 0

2009-03 Last Call for Comments (Run Out Fairly)
by Ingrid Wijte 29 Oct '09

29 Oct '09

PDP Number: 2009-03 Run Out Fairly Dear Colleagues, The proposal described in 2009-03 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html Please note that we have also updated the proposal to version two. This new version has some minor textual changes, clarifying the intent of paragraph 6.3. Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 26 November 2009. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

Details regarding the progress of 2007-01 Phase 2 implementation?
by David Monosov 27 Oct '09

27 Oct '09

Dear address-policy-wg, As phase 2 of the implementation of 2007-01 is well underway and gradually approaching its conclusion, it might be both interesting and beneficial to see some details about the success of this effort so far. Could RIPE NCC furnish the following data at their earliest convenience for the benefit of this work group, and if workload permits, provide monthly updates until phase 2 is complete? - Number and % of direct assignments marked by LIRs as "My End User". - Number and % of direct assignments marked by LIRs as "Not My End User". - Number and % of direct assignments marked by LIRs as "My Infrastructure". - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided but are not yet processed. - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided and subsequently approved by RIPE NCC. - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided and subsequently rejected by RIPE NCC. - Number and % of direct assignments which fall under the scope of 2007-01 phase 2 which remain completely untreated. This data should provide some insight about the challenges that further implementation phases will entail, and create an opportunity for the community to address such challenges on the policy level in a timely manner if required. -- Respectfully yours, David Monosov

4 6

Allocations/assignements statistics ?
by Bernard Dugas 24 Oct '09

24 Oct '09

Dear Colleagues, To analyse the use of IPV4 currently, i need to have the number and size of IPV4 prefixes, PA allocated and PI assigned, and ASN, linked to the 5 membership categories. It should be consistent with other data avalaible, meaning that snapshot of 20090930 would be optimal. Thanks a lot, Best regards, -- __Bernard DUGAS ______________________________________________________

2 2

RIPE staff vs Court
by Max Tulyev 24 Oct '09

24 Oct '09

Hello! Today I just got a strange letter from RIPE staff. I didn't saw anything like that before. They told me about a ten of networks registered through our LIR. All these networks have changed admin-c and tech-c to other country, and routed through one server on that country. Based on this, RIPE man sent the notification about reclamation of that networks, as "that seems to don't be valid anymore." Of course, I immediately contacted my client and asked what's happened. He said they work as usual, but one certain offshore IT company is used to manage their networks. So they changed contact details to that company, as that company is correct contact point in any network questions. And traffic flows through the offshore company site as they manage and control it, hosts data, etc. >From one point of view, situation seems very strange. From second - nothing to be not real in practice. So we (first time?) faced with IP reclamation dispute. I don't really know did our clients something bad - perhaps no, as none from these nets listed at Spamhouse ;). I think it is 50/50. May be they told me (and RIPE) truth, may be lied. I can't 100% check it by tools/rights/possibilities I have. But about ten of businesses are on decision of one person that "seems to ...". My strong position is THERE SHOULD BE A COURT DECISION OR OUR COMMUNITY COURT-LIKE STRUCTURE, and only that structure based on court-like controversy process (if not a real court) can make a decision about reclaim any address space. NO WAYS LIKE "IT SEEMS TO...". So now we have: http://www.ripe.net/ripe/docs/ripe-475.html#42 My proposal is to change: "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User" to "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User, SUPPORTED BY..." By what? By Dutch Court? By some independent court-like staff? Any ideas? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

6 12

Re: [address-policy-wg] Inet6num requirements in the db
by Arkley, Patrick 13 Oct '09

13 Oct '09

I'm fine with that. Thanks. / Patrick Arkley ** sent from mobile device ** ----- Original Message ----- From: Gert Doering <gert(a)space.net> To: Arkley, Patrick Cc: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Sent: Tue Oct 13 09:29:31 2009 Subject: Re: [address-policy-wg] Inet6num requirements in the db Hi, there's two parallel "inet6num registration" discussions going on at the same time - let me respond to this one first, because it's a bit easier. On Fri, Oct 09, 2009 at 01:52:07PM +0200, Arkley, Patrick wrote: > I seem to recall from the RIPE meeting that Axel talked about the RIPE > database as a valuable source of information. Also other organisations > thinks it is a valuable and trustworthy source. It is also a very easy > way of finding out the most likely users (at least one step down stream > from the LIR) of a specific IP-range. > > But how come there is no requirement to add end-user objects for IPv6? > Only the LIR's allocations are required. If we want to continue the work > that has been done for IPv4 I think we need end-user objects for IPv6 as > well. Regarding end-user registrations in the RIPE DB, there are a few conflicting interests to balance: - finding someone "who can make it stop" in case of net-abuse - knowing the end user - protection of personal data for private users - documenting that the network resources are properly used The crucial one is balancing the first one vs. the third one. For private users, there really is no point in having the contact data of the end customer in the database - because if they get some angry e-mails or phone calls from someone who is just now being attacked from their PC, the chance is very high that this end user has no idea whatsoever to do about it. So the best point of contact in that case might be the ISP, who knows the customer, knows whom to call, and how to bring the message "your 0wn3d" across. Now, if there is not much sense in having that data around (because it won't help), EU data protection requires that we don't store it in the first place... Now, for enterprise customers, or multi-level ISP re-seller structures, the question of "whom to contact" and responsibility for abuse handling is different again - so for these, registering the inet6num: objects makes very much sense, and is perfectly fine according to data protection laws (because there is an operational purpose of storing the data). There has been long discussions about this whole topic, mostly taking place in the database working group, and this is the resulting compromise: - you *can* store the end user objects in the RIPE DB, if it makes sense - you don't *have* to store them (in a publically visible database), if it does not make sense - the data needs to be made available to the RIPE NCC, so that for additional allocations, the usage ratio of your allocation can be verified - but that can be in a private DB only accessible to the NCC. So - basically this means "the contact of last resort is the LIR, and if they are not publishing end-user contact data, they (need to!) take responsibility for handling all issues relating to that network block". I assume that this answer is not exactly what you have hoped for, but I think that this should at least clarify the reasoning a bit. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 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 Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009– huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige

1 0

Inet6num requirements in the db
by Arkley, Patrick 13 Oct '09

13 Oct '09

Hi. I seem to recall from the RIPE meeting that Axel talked about the RIPE database as a valuable source of information. Also other organisations thinks it is a valuable and trustworthy source. It is also a very easy way of finding out the most likely users (at least one step down stream from the LIR) of a specific IP-range. But how come there is no requirement to add end-user objects for IPv6? Only the LIR's allocations are required. If we want to continue the work that has been done for IPv4 I think we need end-user objects for IPv6 as well. Maybe there is good reasoning behind this but the explanation I got from the RIPE NCC crew was not satisfactory. Best regards Patrick Arkley Verizon Europe Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009- huvudkontorets adress: Armegatan 38, Box 4127, 171 04 Solna, Sverige

2 1

Registration of IPv6 DHCPv6-PD pools
by Daniel Roesen 10 Oct '09

10 Oct '09

Hi, the current IPv6 Address Allocation and Assignment Policy (RIPE-481) states: http://www.ripe.net/ripe/docs/ripe-481.html#registration_assignment ======================================================================= 5.5. Registration When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate. (Information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered at the granularity of End Site assignments. [...] ======================================================================= Let's assume a residential eyeball network with $BIGNUM customers provides a dynamic /56 via DHCPv6-PD to each customer by default, from a large pool of /56s. I'm not sure what the implications of above policy is, especially in regards to the last sentence, "Information is registered at the granularity of End Site assignments.". Given that the End Site identity changes dynamically in a relatively high frequency, and considering $BIGNUM in the 6 to 7 figure range, it certainly won't be sensible pumping a $BIGNUM count of /56 inet6nums into the RIPE DB, all with "descr: dynamic end site network". Unfortunately it seems that this is actually required ny the policy though, wether in the RIPE DB or a DB operated by the LIR in question, accessible to the NCC. Providing dynamic networks to end sites instead of only single addresses is something new to the community. I'm looking for clarification on how we're going to handle those kind of deployments in regard of assignment registration. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 3

2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries
by Filiz Yilmaz 09 Oct '09

09 Oct '09

Dear Colleagues, 2009-01, "Global Policy for the allocation of IPv4 blocks to Regional Internet Registries" is a global policy proposal. You may remember discussions on it started in all regions around the beginning of 2009. The full text of the proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-01.html AfriNIC, APNIC and LACNIC have reached consensus on the proposal so far. In ARIN, however, a revised text, different to the one in submitted to the RIPE Policy Development Process (PDP) and in other regions, was introduced by the ARIN Advisory Council (ARIN AC). Following community discussion at the ARIN Public Policy Meeting in April 2009, the ARIN AC was tasked with further editing the text. This situation was reported to the RIPE community at RIPE 58. The RIPE community's feedback at that time was that the ARIN version of the proposal should be considered. Today, the ARIN AC has submitted a revised text for discussion in the ARIN community. You can find the current ARIN version of the proposal at: https://www.arin.net/policy/proposals/2009_3.html For your convenience, the major differences between the original ARIN text, the new ARIN version and the current RIPE version have been summarised below. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC -------------------------------------------- Old ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. At quarterly intervals, each RIR shall return to the IANA any legacy address space recovered, and may return to the IANA any non-legacy address space recovered, in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. New ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. RIPE "3.1 Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. --------------------------------------------

9 16

Re: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries
by John Curran 09 Oct '09

09 Oct '09

> it's the tragedy of the americas, a few hudred years of colonialism, > and it goes on. To understand concerns in the ARIN region, I'd recommend that folks read the actual policy text and staff assessment at <https://www.arin.net/policy/proposals/2009_3.html >. Because this global policy results in significant departure from RFC2050 need-based allocation (with one equal allocation unit per RIR each 6 month period even if less than regional demand), there are challenges of equity that result from mandating the return to the IANA. The reality is that returned address space has been going back to IANA and will continue to do under current practices; see <http://blog.icann.org/2008/02/recovering-ipv4-address-space/ > for more information. Thanks! /John John Curran President and CEO ARIN

5 6

Proposal to Remove Routing Requirements from the IPv6 Address Allocation Policy Implemented
by Nathalie Trenaman 08 Oct '09

08 Oct '09

Dear Colleagues, We are pleased to announce that policy proposal 2000-06,"Removing Routing Requirements from the IPv6 Address Allocation Policy", 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-06.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-481.html The following FAQ has also been updated to reflect this policy implementation: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Nathalie Trenaman Registration Services RIPE NCC

1 0

Legal advice on final /8 policies
by Nigel Titley 06 Oct '09

06 Oct '09

Folks, The RIPE NCC has taken legal advice on the various final /8 policies viz-a-viz EU competition policy. I attach a copy of the advice for your delight and edification. Executive summary: don't panic! Nigel

1 0

RIPE-471 and suballocations
by Hank Nussbacher 06 Oct '09

06 Oct '09

I have been looking over RIPE-471 section 9: http://www.ripe.net/docs/ipv4-policies.html#9 and noticed that only some "status" categories are listed as "Sub-allocations cannot be made from this type of address space". Therefore I would have assumed that any status not listed as "Sub-allocations cannot be made from this type of address space" would allow sub-allocations. That is incorrect - for example - ASSIGNED PI does not allow sub-allocations. Can the doc please updated so it reflects correctly the s/w? Thanks, Hank

2 1

how to change ASN
by Kamil Semavi 06 Oct '09

06 Oct '09

Hello guys, I want to change ASN of my whole subnet. How can I do it ? Thanks K.

1 0

AW: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries
by Marcus.Gerdon 05 Oct '09

05 Oct '09

I don't think the situation's that different. I case ARIN's going to adopt the '*may* return to IANA' version I definitely see no sense in any other RIR implementing a *must*. Quite to the contrary. In this part I've to somewhat agree with Randy and unfortunately have to raise the question why we should return any addresses to IANA if ARIN decides to keep everything for themselves (with quite a bunch of legacy /8's being handled there). Marcus > Exactly. And that part of the policy is still common. So even if ARIN > changes the conditions under which they decide to return addresses to > the pool for the common good, the policy can still go forward for > adoption as a global policy. Of course the other RIRs might > decide that > ARIN's stance changes their minds on whether to adopt this > policy, but > that is a different situation. > > Nigel > > ---------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon(a)versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Geschäftsführer: Marc Lützenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ----------------------------------------------------------------------------------------

1 0

Implementation details 2009-06 and 2009-08
by Ingrid Wijte 30 Sep '09

30 Sep '09

Dear Colleagues, In my previous emails regarding the two accepted policy proposals (2009-06 and 2009-08) I overlooked to add information regarding approximate implementation timelines. We expect to be able to implement 2009-06 (Removing Routing Requirements from the IPv6 Address Allocation Policy) within one month and 2009-08 (IPv6 Provider Independent (PI) Assignments for LIRs) within three months. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

2009-08 Proposal Accepted (IPv6 Provider Independent (PI) Assignments for LIRs)
by Ingrid Wijte 30 Sep '09

30 Sep '09

PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs Dear Colleagues Consensus has been reached, and the proposal described in 2009-08 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-481.html Note: This document also incorporates the changes coming from the proposal described in 2009-06, Removing Routing Requirements from the IPv6 Address Allocation Policy, for which consensus was also reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-08.html Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0