April 2011 - ncc-services-wg - mailman.ripe.net

On RIPE Labs: Mobile Application to access RIPE DB
by Mirjam Kuehne 12 May '11

12 May '11

[apologies for duplicates] Dear colleagues, The RIPE NCC is working on a mobile application to allow users to access the RIPE Database from a mobile device. Please find more information on RIPE Labs: http://labs.ripe.net/Members/sandrasi/ripe-db-mobile-application Kind Regards, Mirjam Kuehne RIPE NCC

1 1

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

Draft Agenda - NCC Services WG RIPE 62
by Bijal Sanghani 26 Apr '11

26 Apr '11

Dear All, Please see below Draft Agenda for the RIPE NCC Services Working Group - RIPE 62 16:00 Wednesday, 4 May 2011 A: Administrative Matters * Welcome * Scribe * Chat monitor * Microphone etiquette * Agenda B. RIPE NCC Update - RIPE NCC Senior Management Team (40 mins) C. Update on the 2007-1 Project - Arne Kiessling (10 mins) D. Resource Certification Update - Alex Band (15 mins) E. Update on RIPE NCC Governance Documents, Transfer Document - Athina Fragkouli (15 minutes) Z. AOB The agenda can also be found online - http://ripe62.ripe.net/programme/meeting-plan/ncc-services Kind regards, Bijal Sanghani The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

1 0

Re: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region)
by Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 26 Apr '11

26 Apr '11

Dear colleagues, > Dear Colleagues, > > Following the feedback received, the draft document for the proposal > described in 2008-08 was edited and published. > > The new impact analysis that was conducted for this proposal has also > been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-08 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2008-08/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 26 April 2011. I agree to passing this policy in this (or the previous version 3.0 of 2011-02-09) form. My objection to excluding IPv6 has been taken care of (while I note that the undated NCC certification FAQ anyway tells "... certify their PA address allocations. This includes both IPv4 and IPv6 ...", and ripe-513 dated 2011-02-07 even in the title did know about PA space in IPv6 context). (my mail of Date: Thu, 24 Feb 2011 00:00:40 +0100) I'm not aware what concern or argument has been raised in order to include IPv4 "ALLOCATED UNSPECIFIED"; this inclusion seems to be opposite direction to quickly covering the most simple cases. I'd not be surprised if later on some complications with this hit. I'm NOT seeing this as a show stopper. Beyond these changes my arguments and concerns from the last revision (my mail from Date: Thu, 24 Feb 2011 00:00:40 +0100) essentially still apply - but I did NOT raise them as show stoppers then, and still regard them again as challenges for making required further progress. Looking forward to discuss required and planned activities at RIPE62. It is not easy to track what actually has changed, and a summary of changes actually would seem helpfull for discussing revised proposals; in particular I'm not sure about the 4 related documents. The only one I somewhat accidentally know that it has not changed is the CPS (that's still the one dated 2010-12-30 which is clearly different from the previous draft of 2010-11-01). Is ripe-517 (dated 2011-03-07) the same as the previously referenced draft? What about the two (undated!) terms and conditions documents? Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv(a)NIC.DTAG.DE

1 0

Analysis of the ‘Maximum Length’ Option in Certification ROAs
by Alex Band 20 Apr '11

20 Apr '11

[apologies for duplicates] Dear colleagues, We just published an article on RIPE Labs on the usage of the 'Maximum Length' option in ROAs. We compared all the prefixes in the Repository which are covered by a ROA to the prefixes seen by RIS. It gives a good indication how people are using this option, and what the effects are when people base routing decisions on validation results. You can read the article here: https://labs.ripe.net/Members/AlexBand/using-the-maximum-length-option-in-r… Kind regards, Alex Band Product Manager

2 2

Proposal to Introduce SHA2 Passwords in the RIPE Database
by Denis Walker 20 Apr '11

20 Apr '11

[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to introduce SHA2 passwords as an authentication method in MNTNER objects in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to Introduce SHA2 Passwords in the RIPE Database The RIPE NCC has looked at the possibility of introducing SHA2 as a password algorithm, as requested by AP61.2. >From a technical point of view this is certainly possible. There are C and Java libraries available for generating SHA2 algorithms. We can provide SHA2 as an additional password option alongside MD5. In addition we would also provide a web service to generate SHA2 passwords similar to the one provided for MD5. If the community requires MD5 to be deprecated we would suggest fixing a time period for users to update their MNTNER objects. From the start of that period no MD5 passwords can be added to a MNTNER, but existing ones will remain valid. At the end of that period the RIPE NCC can replace/remove all remaining MD5 passwords. As with the crypt-pw deprecation, we would provide an automated web service to reinstate access to a MNTNER object if you can validate against one of the original MD5 passwords. The time limits used for the crypt-pw deprecation were a 6 month period for users to update their MNTNER objects and a 3 year period to reinstate user access via the web service.

1 0

Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects
by Denis Walker 19 Apr '11

19 Apr '11

[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to change the process of creating and updating reverse DOMAIN objects in the RIPE Database. Because this is a proposed RIPE Database change, please direct any discussion to the RIPE Database Working Group mailing list to keep it focused in one place. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to change the dash ('-') notation in reverse DOMAIN objects Introduction ------------ Reverse delegation DOMAIN objects allow the use of a dash ('-') in the syntax. The current arrangement causes problems with DNSSEC. We propose to drop the current behaviour. We would also introduce a new syntax using the dash notation to avoid the need for manual intervention for classless delegations. Both the current and the new behaviour described in this document only apply to IPv4 delegations. Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database. This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By definition, this must be different for each DOMAIN object. These different hash values for multiple objects cannot be entered by submitting a single object with the dash notation. This issue was raised by members of the DNS community, and the RIPE NCC now proposes to deprecate this update feature. Feature to be added ------------------- Classless delegations, according to RFC2317 (http://www.ietf.org/rfc/rfc2317.txt), are currently handled manually by the DNS Department at the RIPE NCC. Although the objects can be created in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range. New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet. Modification and deletion can be performed on the single object in the database. Any change would be propagated into the zone file by the new delegation software.

6 10

APNIC Announces its IPv4 Address Pool Reaches Final /8
by Axel Pawlik 15 Apr '11

15 Apr '11

[Apologies for duplicate emails] Dear Colleagues, Today, Friday 15 April 2011, APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region, announced that it has distributed the final IPv4 address space from its reserves of IPv4. This means that APNIC is now supplying IPv4 address space to its members from the last /8 it holds according to the guidelines in section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region": http://www.apnic.net/policy/add-manage-policy This event does not affect the RIPE NCC's reserves of IPv4 address space and we will continue to distribute these resources to our members on the basis of need until we reach the last /8. According to RIPE Document ripe-509, section 5.6, once the RIPE NCC reaches the last /8 of IPv4 address space, each Local Internet Registry (LIR) can receive one /22 (1024 IPv4 addresses) upon application for IPv4 resources. In order to obtain this /22 allocation, the LIR must already have an IPv6 allocation and have a demonstrated need for address space. IPv6 - Act Now --------------- The RIPE NCC cannot predict how long its own supply of IPv4 address space will last and has worked for several years to inform all stakeholders of the urgent need to deploy IPv6. It is now imperative that all stakeholders deploy IPv6 on their networks to ensure the continuity of their online operations and the long-term growth of the Internet. For more information on IPv6 and its deployment, advice from experts and where to get training, please see: www.ipv6actnow.org Further Information -------------------- For more information on IPv4 exhaustion, please see: http://www.ripe.net/internet-coordination/ipv4-exhaustion For more information on how the RIPE NCC's last /8 will be distributed, please see: http://www.ripe.net/ripe/docs/ripe-509 For information about the amount of IPv4 address space left in the RIPE NCC's available pool of IPv4, please see the graph online at: http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Next RIPEstat live demo on 19 April 2011
by Mirjam Kuehne 14 Apr '11

14 Apr '11

[apologies for duplicates] Dear colleagues, The next RIPEstat Live Demo is scheduled for Tuesday, 19 April 2011 at 11:30 - 12:00 Amsterdam time (9:30 - 10:00 UTC). Please observe the change to summer time. I hope you will join us. Details on how to join the demo session can be found on RIPE Labs: http://labs.ripe.net/Members/markd/ripestat-live-demo-4 The minutes of the last sessions and some more information about RIPEstat can be found on RIPE Labs: http://labs.ripe.net/ripestat Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Resource Certification Web Validator Released
by Mirjam Kuehne 13 Apr '11

13 Apr '11

Dear colleagues, The RIPE NCC released a Resource Certification Web Validator. Read more on RIPE Labs: http://labs.ripe.net/Members/AlexBand/resource-certification-web-validator-… Kind Regards, Mirjam Kuehne RIPE NCC

1 0