- ipv6-wg - mailman.ripe.net

RIPE NCC Measurements for World IPv6 Day
by Mirjam Kuehne 11 May '11

11 May '11

[apologies for duplicates] Dear colleagues, Please find on RIPE Labs a description of the measurements the RIPE NCC is doing prior to and on World IPv6 Day: http://labs.ripe.net/Members/emileaben/ripe-ncc-measurements-for-world-ipv6… This is an extended version of the presentation Emile Aben gave in the MAT-WG at RIPE62. Feedback received at the meeting, has been incorporated. Please also note the call for participation for each of the measurements described in the article. If you have any other feedback or questions, please do not hesitate to contact us at labs(a)ripe.net. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 RIPEness - One Year later
by Mirjam Kuehne 04 May '11

04 May '11

[apologies for duplicates] Dear colleagues, A year ago we introduced IPv6 RIPEness - a system that rates IPv6 deployment of Local Internet Registries based on certain criteria. Now, one year later, we were curious to see how the numbers have changed. Please read the update on RIPE Labs: http://labs.ripe.net/Members/becha/ipv6-ripeness-one-year-later Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 theme day on RIPE 62
by Marco Hogewoning 03 May '11

03 May '11

Dear colleagues, For those of you who missed out on the original announcement and who are wondering why we haven't published an agenda yet. The upcoming RIPE Meeting does not have a formal seating of the IPv6 Working Group. Given the amount of content and the current state of affairs, the collective chairs decided to dedicate a full day to the topic. So Tuesday's plenary session will be all about IPv6, covering a broad range of topics. We have talks about the state of the world, overviews of the available transitioning techniques and various presentations from people who already deployed IPv6 in their network. We are still busy with the final details of the agenda and the time schedule, but this is what we already have scheduled: Dynamic IPv4 Address Release - Olaf Bonness Transition Technologies Overview - Marco Hogewoning IPv6 Mobility in Emergency Teams - Jan Žorž RIPE 501 bis - Jan Žorž et al IPv6 Routing Table Update - Gert Döring IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) IPv6 Issues on AMS-IX Peering LAN - Arien Vijn Deploying IPv6 Without Huge Costs – Case Study IPv6 Geolocation - TBD IPv6 Pending Badge Initiative - INEX IPv6 CPE survey: Initial results - Mirjam Kuehne As stated we are still busy with the final details and some speakers, for the latest updates please refer to the meeting plan at http://ripe62.ripe.net/programme/meeting-plan/plenary For those who can't make it to Amsterdam, all the sessions will be broadcasted on the Internet and available for remote participation. Details for the webcast will be posted on http://ripe62.ripe.net, session will start at 09:00 CEST. For those coming to the meeting, save travels and see you next week, The IPv6 Working Group co-chairs. Marco, Shane and David Grtx, MarcoH

3 4

Announcement: New IPv6 information videos available now
by Nathalie Trenaman 28 Apr '11

28 Apr '11

Dear Colleagues, The RIPE NCC is pleased to announce the launch of four new information videos on real-life IPv6 deployment experiences. The following videos are now available in the RIPE NCC's E-Learning Centre at: http://www.ripe.net/lir-services/training/e-learning/ipv6 - Jan Žorž talks about "Mobile IPv6" - Tore Anderson gives an overview on "IPv6 and Content Providers" - Nuno Viera talks about "IPv6 in Hosting Environments" - Teun Vink is interviewed about "IPv6 and ISPs" The RIPE NCC E-Learning Centre is free and available to everyone. If you have any questions about this, please contact us at <e-learning(a)ripe.net>. Regards, Nathalie Trenaman Trainer RIPE NCC

1 0

New IPv6 survey released on labs.ripe.net
by Marco Hogewoning 27 Apr '11

27 Apr '11

Hi There, We just released a new version of the IPv6 CPE survey. After lots of feedback on the previous editions, we are now doing a "proper" survey. Based on the responses we receive in this survey we will be able to compile a new edition of our matrix and provide some more statistical background on what is happening in the market. Remember we are totally depending on your feedback to continue this work. The more responses we receive, the easier it gets for us to provide regular updates on which CPE are available on the market and how good they are. So if you have an IPv6 capable router or modem in your house, or you are busy testing them. Please take the time to fill out the survey and help other people to find the device that fits their need. Please see https://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate for further details and a link to the survey. Thanks, MarcoH

1 0

Request: IPv6 day preparations
by David Kessens 21 Apr '11

21 Apr '11

Hi, I was wondering whether there is anybody on this list who might be willing and/or knows somebody who can speak at the next RIPE meeting regarding ongoing preparations for the IPv6 day in June: http://isoc.org/wp/worldipv6day/ Specifically, are there any people who are for example preparing their customer service department and other parts of the company as opposed to just moving the main website to ipv6. Are there any problems you expect ? Or, other things that deserve attention ? Please respond to: ipv6-wg-chairs(a)ripe.net Thanks, David Kessens ---

1 0

New article on RIPE Labs: Testing Teredo
by Mirjam Kuehne 20 Apr '11

20 Apr '11

Dear colleagues, Please see a new interesting article on RIPE Labs: Testing Teredo by Geoff Huston: http://labs.ripe.net/Members/gih/testing-teredo Kind Regards, Mirjam Kuehne RIPE NCC

1 0

FYI: APNIC has activated their final /8 policy
by Marco Hogewoning 18 Apr '11

18 Apr '11

Dear Colleagues, As you may have already seen on other mailing lists, APNIC, the Regional Internet Registry for the Asian Pacific region, has reached the end of their pool of available IPv4 addresses. As of Friday April 15, they have activated their "final /8" policy, which was decided upon by the APNIC community [1]. This event in itself does not have any effect on the amount of IPv4 addresses which are still available within the RIPE NCC service region. But we would like to remind you that eventually the RIPE community will have to deal with the same situation. We would like to point out that he RIPE community has decided that an LIR must already have IPv6 addresses before they become eligible for their final allocation under the final /8 policy. This requirement is in addition to having a demonstrated need for address space. For more information about this, please refer to section 5.6 of the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region [2]. We would like to urge the community to start deploying IPv6 as soon as possible if they haven't done so already. This is the only way to support the long-term growth of the Internet and ensure the continuity of their operations. And if you have already deployed IPv6 in your network, please share your experiences for others to learn from. Greetings, The IPv6 working group chairs, Marco, David & Shane [1] http://www.apnic.net/publications/news/2011/final-8 [2] http://www.ripe.net/ripe/docs/ripe-509

1 0

RIPE IPv4 Pool Graph
by Ahmed Abu-Abed 06 Apr '11

06 Apr '11

Greetings, RIPE NCC is now publishing an IPv4 pool graph with weekly updates, and the latest data show five /8 blocks are remaining. More at http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, -Ahmed

1 0

Is there a recommended list for sharing IPv6 deployment experience/woes/etc?
by Niall O'Reilly 29 Mar '11

29 Mar '11

A colleague in the Irish IPv6 TF was asking, and I couldn't think of just the right list. The kind of sharing of operational experience he's looking for doesn't seem to me to fall quite within the scope of the RIPE IPv6 WG list, and certanly not within the IETF v6ops list. I'll be glad to find I'm mistaken, or else to have suggestions ... Thanks in advance. Niall Begin forwarded message: > From: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > Date: 29 March 2011 12:02:46 GMT+01:00 > To: Irish IPv6 Task Force <ipv6tf(a)listserv.tssg.org> > Subject: [Ipv6tf] spoofed router advertisements > Reply-To: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > > > Hi folks, > > I realise this isn't a list for practical details of running IPv6, but is > there a list people do recommend? > > For some time now, on and off, we've been noticing bogus IPv6 router > advertisements, presumably from student laptops. [...]

6 6

New on RIPE Labs: 6to4 - Why is it so Bad?
by Mirjam Kuehne 21 Mar '11

21 Mar '11

[apologies for duplicates] Dear colleagues, In an earlier article on RIPE Labs, we showed that a large percentage of 6to4 connections fail. In this new article by Emile Aben, we look at why these connections fail and what can be done about this: http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: ipv6-wg -- confirmation of subscription -- request 440625
by Henk Uijterwaal 15 Mar '11

15 Mar '11

confirm 440625

1 0

"Preparing an IPv6 Addressing Plan" - New Manual Published on www.ripe.net
by Nathalie Trenaman 15 Mar '11

15 Mar '11

Dear colleagues, The RIPE NCC has just published "Preparing an IPv6 Addressing Plan", an easy-to-read manual to help End Users effectively distribute large blocks of IPv6 address space over their networks. The document is available for download here: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_ad… The manual was written by Sander Steffann and Surfnet. It has been translated from Dutch to English by the RIPE NCC. If you have any feedback about the manual, please send it to: <nathalie(a)ripe.net> Kind Regards, Nathalie Trenaman RIPE NCC Trainer

1 0

Re: [address-policy-wg] IPv6 allocations for 6RD
by Ahmed Abu-Abed 28 Feb '11

28 Feb '11

Greetings, Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg(a)ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP. However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options: 1) Implement 6rd only 2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd) I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms. I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all... My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible. Regards, -Kurt

2 1

Benefits of IPv4 exhaustion
by Shane Kerr 25 Feb '11

25 Feb '11

All, As seen in today's xkcd: http://xkcd.com/865/ Happy Friday everyone! -- Shane

1 0

Fwd: [routing-wg] IPv6 Routing Recommendations.
by Rob Evans 24 Feb '11

24 Feb '11

Good people of the IPv6 Working Group, It was suggested to me that for some strange reason you may also be interested in this document and discussion... Best regards, Rob -------- Original Message -------- Subject: [routing-wg] IPv6 Routing Recommendations. Date: Wed, 23 Feb 2011 14:39:18 +0800 From: Rob Evans <rhe(a)nosc.ja.net> To: routing-wg(a)ripe.net All, You may remember that back in the mists of time (about a year ago) we had a document that updated RIPE-399 with some IPv6 routing recommendations. After the meeting last May, the authors were to go away and take out mention of any specific suggestions on filtering (e.g. /36). Over the past 12 months, Philip and I have been hard at work constantly refining this document to reflect the changing nature of the IPv6 routing table. Well, kind-of. Anyway, my laziness aside, appended is the document as it stands at the moment. Comments and discussion please! Rob RIPE Routing Working Group Recommendations on IPv6 Route Aggregation ==================================================================== Rob Evans Philip Smith Introduction ============ Recent discussion has shown there is a limited requirement to be able to advertise more specific prefixes from an IPv6 Provider Aggregatable (PA) allocation where a Local Internet Registry (LIR) contains several networks which are not interconnected, or for traffic engineering purposes. This document recommends such advertisements are limited in both length and scope. It is intended to supplement the working group's Recommendations on Route Aggregation [RIPE-399]. Background ========== The IPv6 address allocation and assignment policy for the RIPE region [V6-ALLOC] only allows LIRs to obtain more than the minimum PA allocation if they can demonstrate address utilisation that requires it. This fits with the address space management principle of conservation. However, as understood in the RIPE Routing Working Group's Recommendations on Route Aggregation [RIPE-399], there are occasionally requirements for the advertisement of more specific routes from within an allocation. With a few ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause significant difficulties for some networks wishing to deploy IPv6. Some reasons for wanting to advertise multiple prefixes from a PA allocation could be: - The LIR has several networks that are not interconnected. - Traffic engineering: A single prefix that covers an LIR's entire customer base may attract too much traffic over a single peering link This document is only concerned with IPv6 Provider Aggregatable (PA) allocations, and does not discuss Provider Independent (PI) prefixes. Recommendation ============== It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. The operator community will ultimately decide what degree of subdivision is supportable, but the majority of ISPs accept prefixes up to a length of /48 within PA space. Advertisement of more specific prefixes should not be used unless absolutely necessary and, where sensible, a covering aggregate should also be advertised. Further, LIRs should use BGP methods such as NO_EXPORT [RFC-1997], [AS-PATHLIMIT], or provider-specific communities, as described in [RIPE-399] to limit the propagation of more specific prefixes in the routing table. Discussion ========== There is a valid need for some LIRs to advertise more than one IPv6 PA prefix. As either obtaining more address space and advertising more /32 prefixes, or advertising more specific prefixes within an already allocated /32 have the same impact on the routing table, it is suggested that the latter approach is taken to prevent address space wastage. It is understood that this may not cover all possibilities. There may be circumstances where sites will have to consider the suitability of Provider Independent addresses, or LIRs may have to consider mechanisms of obtaining more than a /32 of Provider Aggregatable space. References ========== [V6-ALLOC] http://www.ripe.net/ripe/docs/ipv6policy.html [RIPE-399] http://www.ripe.net/ripe/docs/ripe-399 [RFC-1997] http://www.rfc-editor.org/rfc/rfc1997.txt [AS-PATHLIMIT] http://tools.ietf.org/html/draft-ietf-idr-as-pathlimit-03 Work in Progress.

1 0

Announcement: RIPE NCC Training Courses
by Training Mailbox 22 Feb '11

22 Feb '11

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/lir-services/training/courses/lir/outline/ - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/lir-services/training/courses/rr/ - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

RIPE 62 working group session
by Marco Hogewoning 22 Feb '11

22 Feb '11

Dear Colleagues, Registration for the RIPE 62 meeting, which takes place from 2 till 6 May in Amsterdam (NL). As you may have noticed the IPv6 working group is missing from the meeting plan. This is not an error, but an intentional change to the agenda. After some discussion with the working group chairs collective and other stakeholders, we concluded that the IPv4 run out and the associated need to deploy IPv6 will most likely be a very hot topic on this upcoming meeting. It has therefor been decided that the time originally allocated for our working group would be added to the plenary program. Any interesting IPv6 topics, and I'm sure there are many, will be placed in the plenary schedule. At the same time, the closing plenary on Friday morning will host a "IPv6 roundup". In this session we will discuss the outcome of the meeting, based on input received from the working groups and presentations or comments during the plenary sessions. In other words, no need to panic. The IPv6 working group will be present, although not in a formal setting this time. If you have any interesting information on IPv6 deployment, interactions between IPv4 and IPv6 and deployment of transitioning techniques. Please consider presenting about it on this meeting and send a short description of what you like to present together with your contact details to ipv6-wg-chairs at ripe dot net. See you in Amsterdam, The IPv6 working group chairs, Marco, Shane and David.

1 0

Registering IPv6 Assignments in the RIPE Database
by Denis Walker 15 Feb '11

15 Feb '11

[Apologies for duplicate emails] Dear Colleagues The RIPE community recently approved RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments". The proposal is available at: [http://www.ripe.net/ripe/policies/proposals/2010-06] This has now been implemented in the RIPE Database and other RIPE NCC processes, where necessary. Details of how to use the new aggregation feature of the RIPE Database can be found at: http://www.ripe.net/data-tools/support/documentation/documenting-ipv6-assig… For those who have already made some IPv6 assignments, you will need to document them in the RIPE Database according to the policy if you have not already done so. All new IPv6 assignments must be registered in the RIPE Database in accordance with this policy. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

2010-06 Proposal Accepted (Registration Requirements for IPv6 End User Assignments)
by emadaio＠ripe.net 10 Feb '11

10 Feb '11

Dear Colleagues, Consensus has been reached, and the proposal described in 2010-06 has been accepted by the RIPE community. The updated policy "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-512 The new policy "Value of the "status:" and "assignment-size:" attributes in inet6num objects for sub-assigned PA space" is available at: http://www.ripe.net/ripe/docs/ripe-513 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-06 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

FWD: IANA Allocates Two /8s of IPv4 Space to APNIC
by David Kessens 02 Feb '11

02 Feb '11

----- Forwarded message from Axel Pawlik <no-reply(a)ripe.net> ----- Date: Tue, 01 Feb 2011 05:27:16 +0100 From: Axel Pawlik <no-reply(a)ripe.net> To: ripe-list(a)ripe.net, ncc-announce(a)ripe.net, ncc-services-wg(a)ripe.net Subject: IANA Allocates Two /8s of IPv4 Space to APNIC Reply-To: no-reply(a)ripe.net [Apologies for duplicate emails] Dear colleagues, On 1 February 2011, the IANA allocated two /8s of IPv4 address space to APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region. This means that only five /8s of IPv4 address space are left in the IANA free pool and the "Global Policy for the Allocation of the Remaining IPv4 Address Space" will be triggered. This policy can be found online at: http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm When this policy comes into effect, the five RIRs will each receive one of the five remaining /8s and the global IPv4 pool will be exhausted. We expect IANA to allocate these final /8s within the next few days. For further information please see: http://www.ripe.net/v4exhaustion/ Regards, Axel Pawlik Managing Director RIPE NCC ----- End forwarded message -----

1 0

[sunny@apnic.net: [apops] Two /8s allocated to APNIC from IANA (39/8 and 106/8)]
by David Kessens 01 Feb '11

01 Feb '11

----- Forwarded message from Srinivas Chendi <sunny(a)apnic.net> ----- Date: Tue, 01 Feb 2011 09:20:41 +1000 From: Srinivas Chendi <sunny(a)apnic.net> To: apops(a)apops.net Subject: [apops] Two /8s allocated to APNIC from IANA (39/8 and 106/8) _______________________________________________________________________ Two /8s allocated to APNIC from IANA (39/8 and 106/8) _______________________________________________________________________ Dear Colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in February 2011 and will be making allocations from these ranges in the near future: 39/8 106/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon Please be aware, this will be the final allocation made by IANA under the current framework and will trigger the final distribution of five /8 blocks, one to each RIR under the agreed "Global policy for the allocation of the remaining IPv4 address space". http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm After these final allocations, each RIR will continue to make allocations according to their own established policies. APNIC expects normal allocations to continue for a further three to six months. After this time, APNIC will continue to make small allocations from the last /8 block, guided by section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region". This policy ensures that IPv4 address space is available for IPv6 transition. http://www.apnic.net/policy/add-manage-policy It is expected that these allocations will continue for at least another five years. APNIC reiterates that IPv6 is the only means available for the sustained ongoing growth of the Internet, and urges all members of the Internet industry to move quickly towards its deployment. Kind regards, _______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net _______________________________________________________________________ * Sent by email to save paper. Print only if necessary. _______________________________________________ apops mailing list apops(a)apops.net http://mailman.apnic.net/mailman/listinfo/apops Website: www.apops.net ----- End forwarded message -----

1 0

Re: [ipv6-wg] 2010-06 is going to Last Call
by David Kessens 28 Jan '11

28 Jan '11

[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > Hello, > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > The Review Phase for the RIPE policy proposal 2010-06 ended on > 2010-12-27 (Monday, 27 December 2010). > > You can see the policy proposal here: > > http://ripe.net/ripe/policies/proposals/2010-06.html > > There were some clarifications during the Review Phase, but nothing > indicating changes needed. > > David and I have decided that the proposal is ready for a Last Call. (As > co-author of the proposal, Marco has recused himself from any consensus > judgments.) > > The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 > February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net > before then. > > Thanks, > > -- > Shane

26 35

Proposed Implementation Plan for Policy Proposal 2010-06 in the RIPE Database
by Denis Walker 26 Jan '11

26 Jan '11

[Apologies for duplicate emails] Dear Colleagues, To prepare for the possible acceptance of RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments", the Database Group at the RIPE NCC proposes the following implementation plan. We will implement a new attribute ("assignment-size:") in INET6NUM objects, add some business logic for its use and add a new value (AGGREGATED-BY-LIR) for the "status:" attribute of an INET6NUM object. Schema and syntax changes in INET6NUM objects: - New attribute "assignment-size:" - Syntax is numeric value > 0 - INET6NUM object will include "assignment-size:" as an optional, single attribute - "assignment-size:" will not be an inverse searchable attribute - New value for the "status:" attribute of an INET6NUM object will be AGGREGATED-BY-LIR Business rules: - "assignment-size:" is optional in INET6NUM objects but required if "status:" is AGGREGATED-BY-LIR - The value of "assignment-size:" must be greater than the prefix size of the INET6NUM object containing the attribute - Parent status of INET6NUM object with status AGGREGATED-BY-LIR can be: ALLOCATED-BY-RIR ALLOCATED-BY-LIR AGGREGATED-BY-LIR - If parent status is AGGREGATED-BY-LIR, grandparent status cannot be AGGREGATED-BY-LIR - If an object has the status AGGREGATED-BY-LIR, a more specific object can only have the status AGGREGATED-BY-LIR (subject to the aforementioned constraints) We will prepare implementation of this plan during the week commencing 31 January 2011. It will be deployed during the week commencing 7 February 2011 should RIPE Policy Proposal 2010-06 be formally approved. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Future of the IPv6 CPE survey - Your Input Needed
by Mirjam Kuehne 24 Jan '11

24 Jan '11

[apologies for duplicates] Dear colleagues, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask you for help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input… Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC

1 0