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

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

Removal of Forward DOMAIN data from the RIPE Database
by Denis Walker 23 Nov '09

23 Nov '09

[Apologies for duplicates] Dear Colleagues, The RIPE NCC has published an implementation plan for the removal of forward DOMAIN objects from the RIPE Database. It can be found at: http://www.ripe.net/db/support/forward-domain-objects-removal.html Please focus the discussion, if possible, on one working group mailing list. Because it is a data clean-up process, we suggest the Database Working Group. Regards Denis Walker Business Analyst Database Group RIPE NCC

1 0

NCC Services WG Minutes - RIPE 59
by Sanghani, Bijal 18 Nov '09

18 Nov '09

The minutes for the NCC Services WG are published and available at - http://www.ripe.net/ripe/wg/ncc-services/r59-minutes.html Please let us know if you have any questions or comments. 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

Announcement: RIPE NCC Training Courses
by Training Mailbox 10 Nov '09

10 Nov '09

[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/training/lir/outline.html - 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/training/rr/outline.html - 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

IP geolocation services
by Vegard Svanberg 03 Nov '09

03 Nov '09

We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services. A quick web search reveals that this is a pretty common problem. While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs. I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations. Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this). Apologies in advance if this has been discussed before -- I searched the archive, but got no hits. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801

10 17

Re: [ncc-services-wg] IP geolocation services
by Arkley, Patrick 28 Oct '09

28 Oct '09

Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin(a)ripe.net <ncc-services-wg-admin(a)ripe.net> To: Vegard Svanberg <vegard(a)monsternett.no> Cc: ncc-services-wg(a)ripe.net <ncc-services-wg(a)ripe.net> Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote: > We've recently experienced a storm of customer complaints after starting > to use IP addresses from a new allocation/assignment. The IP block was > earlier in use by a German company. The result is that services like > Google and Yahoo assume users are from Germany and presents content > accordingly. Some users have also reported that they are excluded from > certain services. > > A quick web search reveals that this is a pretty common problem. > > While not blaming RIPE or the other RIRs, we believe this problem should > be addressed, and that the initiative has to come from the RIRs. > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > > Also, one should probably consider if it's a need for a (distributed?) > database with more fine-grained location data than the whois database > currently provides (also, I've been told that licensing issues prohibits > geolocation providers from using the RIR DBs directly, but I've not been > able to verify this). > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009– huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige

7 13

FW: [ipv6-wg] Publication of default assignment sizes for end-user network ?
by michael.dillon＠bt.com 28 Oct '09

28 Oct '09

You might want to have a look at this idea as a way to kill two birds with one stone. -----Original Message----- From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of michael.dillon(a)bt.com Sent: 28 October 2009 13:38 To: ipv6-wg(a)ripe.net Subject: RE: [ipv6-wg] Publication of default assignment sizes for end-user network ? > Now this does not forbid you to register individual assignments into > the public database, but doing so poses various problems. Not only the > sheer number of assignments can be a problem, but also keeping that > registration up-to-date will have serious impact on your day to day > operations and especially with residential users there might be > privacy issues as well. If we would have a distributed database protocol to extend the RIPE database into the LIRs, then this would not be an issue. I'm thinking of something like DNS. For instance, if I need to look up data on three /48s in fdb8:e914::/32 I would first send a lookup request to RIPE. The RIPE db would tell me that all data for fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would cache that information, and send my first lookup request to the distributed server. After getting my reply, I would prepare to send the second request for fdb8:e914:c20f::/48, notice that the /32 is already in my cache, and use the cached server instead. This is roughly the way DNS lookups work with the result that the detailed data does not have to be kept in one central location. I would like to see the RIPE db move in the same direction. At the same time, I would like to see the spec opened up a bit so that the distributed server operators would be free to add additional attributes to existing objects, and additional objects so that there is the possibility of using the same distributed lookup mechanism for geographic or language identifications as well. --Michael Dillon

1 0

New rules for reverse domain object creation in the RIPE Database
by Denis Walker 22 Oct '09

22 Oct '09

Dear Colleagues, [Apologies for duplicate emails] A proposal has just been sent to the DNS Working Group (DNS WG) mailing list about additional checks on creating reverse delegation DOMAIN objects. If you wish to comment, please do so on the DNS WG mailing list. This will keep any discussion concentrated in a single thread. Regards, Denis Walker Business Analyst, Database Group RIPE NCC

1 0

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

RE: RIPE NCC Services Working Group - Draft Agenda - Updated
by Sanghani, Bijal 06 Oct '09

06 Oct '09

Please see below Updated Draft Agenda for the NCC Services Working Group - A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 58 * Finalise agenda B. RIPE NCC Update - Axel Pawlik, RIPE NCC C. Contractual Relationship Requirement for End Users - Andrea Cima, RIPE NCC D. Certification Update, Alex Band, RIPE NCC E. Discussion about inet(6)num and aut-num objects to reference sponsoring LIR - Piotr Strzyzewski F. 2007-01 implementation survey. Discussion - Piotr Strzyzewski G. Recovering resources assigned to non-existing entities - Uwe Manuel Rasmussen I. Registration Data Quality Update - Robert Kisteleki H. Open Microphone Session Z. A.O.B. Regards, Bijal 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. 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. 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