- ipv6-wg - mailman.ripe.net

test-ipv6.com
by Jason Fesler 14 May '10

14 May '10

Shane Kerr suggested I post this here; that some of you may find it useful. http://test-ipv6.com or http://aaaa.test-ipv6.com The intent of this site is to help the user what it will mean when publishers start publishing dual-stack. When it makes sense, the test will be updated to indicate what the future looks like when publishers are IPv6 only. The dual stack publishing case is an open question that has been discussed between content and access providers. Measurements published by Google indicate a number of users with IPv6 enabled, routes installed, but the connectivity fails. In this situation, from the user's perspective, the site is down, and the user will go to the competitor's site (Still "up", IPv4 only). Followup measurements by other parties (Tore Anderson published some data; I've seen private data by other organizations) confirm the scale of the numbers Google has seen. While content providers will continue to do their own measurements (whether publicly or privately), they won't likely be indicating to the "broken" users what fate they are facing or how to fix it. This is where I hope something like my site can help, in a brand-neutral way. Please review the FAQ; and if you have comments feel free to send them to me. The site will automatically show a survey form if you have results I don't fully understand; if you see it pop up, please fill it out with contact details in case I need to ask more questions. I've seen lots of crazy things so far! Note: This is a side project of mine, not an employer's. As such, resources are limited. Please don't post this to slashdot - I'm not appropriately resourced for it (both for hardware and finances). -- Jason Fesler, email/jabber <jfesler(a)gigo.com> resume: http://jfesler.com "Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life."

4 3

IPv6 CPEs
by Dez 12 May '10

12 May '10

Following up on Marco's very informative presentation about IPv6 CPEs I was wondering if any of the CPEs mentioned, were tested with 2 ppp sessions (a v4 and a v6 one) at the same time. I know we've tried this setup with the ciscos (87x,88x) and I was curious to find out if other CPEs support that (and how easy it is to configure) and if anyone has tried this setup regards, Yannis

2 1

internal additional IPv4 assignment policy
by Lubos Pinkava 12 May '10

12 May '10

Hello, I've raised an idea concerning additional IPv4 assignments for our customers during RIPE60 beering with quite positive responses, so I would like to share it here and maybe get some additional feedback. We are a company running ISP/collocation business, promoting IPv6 since 2003 and already having substantial amount of IPv6 enabled customers. In our point of view, it's still pretty slow growth. What I indend to propose for our operations - active imediately - is this: - all customers requesting additional /25 (variable) shall have IPv6 assigned and asked for trying it (if not already done before) - all customers requesting additional /24 (variable) must already have active v6 services running (eg. NS/MX/web site for the beginning) There were several other ISP's interested, each of course with own specifics - but in general, we have agreed, that this can speed up IPv6 adoption especially in collocation / infastructure area and can still go through company processes. If there are more people interested, we can create some best practice document backing up our work. Any thoughts on this subject? Lubos Pinkava Casablanca INT s.r.o.

3 4

Re: [ipv6-wg] internal additional IPv4 assignment policy
by Geoffroy RIVAT 06 May '10

06 May '10

Hi, In-Reply-To: <4BE2BAAD.1040906(a)casablanca.cz> Lubos Pinkava wrote: > Hello, > > I've raised an idea concerning additional IPv4 assignments for our > customers during RIPE60 beering with quite positive responses, so I > would like to share it here and maybe get some additional feedback. > > We are a company running ISP/collocation business, promoting IPv6 > since 2003 and already having substantial amount of IPv6 enabled > customers. In our point of view, it's still pretty slow growth. > > What I indend to propose for our operations - active imediately - is this: > > - all customers requesting additional /25 (variable) shall have IPv6 > assigned and asked for trying it (if not already done before) > - all customers requesting additional /24 (variable) must already > have active v6 services running (eg. NS/MX/web site for the > beginning) This is a really good idea, on our network for each customers we have configured IPv6 and try to help them to use it. Our last procedure says to add firewall rules in both v4 and v6 when they ask using the last 2 bytes of the v4 address to map to their v6 address -- Geoffroy Rivat

1 0

Agenda for IPv6-wg @ RIPE 60 (v1)
by Shane Kerr 28 Apr '10

28 Apr '10

Hello, The IPv6 working group is scheduled for the same time at RIPE 60 in Prague as it was in RIPE 59 - immediately following the plenary on Tuesday. Here is a proposed agenda: A. Administrative stuff - Introduction - New charter - New chairs - Agenda bashing B. Javascript-based HTTP client measurements by Emile Aben C. IETF v6ops activity by Kurt Lindqvist D. CPE Overview by Marco Hogewoning E. IPv6 global policy review by Filiz Yilmaz F. IPv6-wg brainstorming . . . Y. Input for the RIPE NCC Activity Plan Z. AOB & wrap-up The "brainstorming" session is an attempt to have some discussion about concrete ideas that we can use to reach the goals of the new charter. Marco will lead the session, but hopefully everyone will come with new ideas ready and join in. -- Shane

4 4

IPv6 client loss measurements, now on the web
by Tore Anderson 28 Apr '10

28 Apr '10

Hi list, I've finally gotten around to creating a web page dedicated to the measurements I've posted about here earlier. You'll find it at <http://fud.no/ipv6/>. It will be automatically updated every night, and it even has graphs. I think it'll be a much better home for the information than an IPv6 mailing list archive, so this means I won't be posting monthly reports any longer. Feel free to have a look! Any feedback is of course very welcome. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27

1 0

Agenda for IPv6-wg @ RIPE 60 (v2)
by Shane Kerr 27 Apr '10

27 Apr '10

All, An updated version of the agenda. ------------------------------------------------------------------- The IPv6 working group is scheduled for the same time at RIPE 60 in Prague as it was in RIPE 59 - immediately following the plenary on Tuesday. Here is a proposed agenda: A. Administrative stuff - Introduction - New charter - New chairs - Agenda bashing B. IPv6 at Web Clients and Caching Resolvers by Emile Aben, RIPE NCC C. IETF v6ops activity by Kurt Lindqvist, Netnod D. CPE Overview by Marco Hogewoning, XS4ALL E. IPv6 WorldWide Policy Review by Filiz Yilmaz, RIPE NCC F. Mobile broadband and IPv6 in Slovenia by Jan Zorz, go6.si G. Update on Recent RIPE NCC IPv6 Activity by Christ Buckridge, RIPE NCC H. IPv6-wg brainstorming . . . Y. Input for the RIPE NCC Activity Plan Z. AOB & wrap-up The "brainstorming" session is an attempt to have some discussion about concrete ideas that we can use to reach the goals of the new charter. Marco will lead the session, but hopefully everyone will come with new ideas ready and join in. -- Shane

1 0

Major additions to Team Cymru's Bogon Feed - includes IPv6 prefixes
by Steve Santorelli 19 Apr '10

19 Apr '10

Team Cymru is pleased to announce a significant addition to our bogon reference project which might be of interest to this list as it relates to IPv6 matters. The new portions of the project are offered at no cost to the community, and the original bogon lists and feeds are not being changed or canceled, just augmented. The new "fullbogon" feed includes prefixes allocated to RIRs, but not assigned by the RIRs to end-users, ISPs, etc, providing a more complete view of the unassigned space that should not be seen on the Internet. This new service is therefore more granular than the original feed, including a wide variety of non-routable prefixes as well as unassigned prefixes and it also includes IPv6 prefixes. Simply email bogonrs(a)cymru.com with your ASN, peering IP addresses and whether you use MD5 authentication. See an overview in the 46th episode of Team Cymru's 'The Who and Why Show' at www.youtube.com/teamcymru, as well as a more basic overview in episode 12. For a more detailed explanation, see <http://www.team-cymru.org/Services/Bogons/>. Even more so than the original feed, there are significant changes to the list every day and the feed automatically recalculates the prefixes as they are allocated from the regional registries, so make sure you are able to regularly update your lists. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. We look forward to continuing to help our community to secure the edge. Why is this important? Bogons are defined as Martians (private and reserved addresses defined by RFC 1918 and RFC 5735) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A bogon prefix is a route that should never appear in the Internet routing table on a Router. A packet routed over the public Internet (obviously, not including over VPNs or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks and our research has previously shown that, in some cases, up to 60% of DDoS packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). This new service comprises a larger set which also includes IP space that has been allocated to an RIR, but not by that RIR to an actual ISP or other end-user. While not all DDoS attacks use bogons, every little bit helps. Note additionally that bogon filtering is a component of anti-spoofing filtering, which is also very important. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. We look forward to continuing to help our community to secure the edge. warm regards, Steve. -- Steve Santorelli,Team Cymru, Inc.|www.team-cymru.org steve(a)cymru.com|[moderated] Also, please note that there are many way to keep up with what Team Cymru are doing, see the lower part of: http://www.team-cymru.org/About/contact.html plus: * join our announce list via cymru-announce-subscribe(a)cymru.com * see what we see, www.team-cymru.org/Monitoring/Graphs * probably the best news feed in the world, www.team-cymru.org/News * cool stuff you can use, www.team-cymru.org/Services/ * see our Twitter feed at http://twitter.com/teamcymru

1 0

The end of IPv4 and the arrival of IPv6 in spanish newspaper
by García Fernández, Fernando 10 Apr '10

10 Apr '10

It seems that it's finally getting to the mass media. A spanish newspaper (Publico, one of the top ten if you can say clasify them), publish an article called "Internet runs out of address" with the subtitle "The OCDE tells that we must speed up the deployment of the new protocol IPv6". I think this is a good start. For those who understand spanish (or who dare to believe to Google translation) here is the URL: http://www.publico.es/ciencias/305214/internet/quedasin/direcciones Regards, Fernando -- Tecnocom Fernando García Fernández D.G. Integración de Redes y Sistemas Josefa Valcarcel, 26 Edificio Merrimack III Madrid - 28027 Tel. Fijo: 901900900 ext 40383 Fax: (+34) 914313240 Tel. Móvil: (+34) 649428591 E-mail: fernando.garcia(a)tecnocom.es http://www.tecnocom.es

1 0

Question on Challenges of IPv6 deployment
by Edu Abume 05 Apr '10

05 Apr '10

Hi, This site has been very educative and helpful to me. Can anyone tell me: The challenges organizations face with IPv6 deployment, The organizational settings (types) that really needs to deploy quickly and Probably the deployment methodologies they prefer to use. Thanks. Edu

1 0

IPv6 brokenness in Norway, March 2010 (fwd)
by Tore Anderson 01 Apr '10

01 Apr '10

Hi, I've been posting these reports to the ipv6-ops list for some time now. Shane Kerr asked if I could post them here too, something which I don't mind doing at all, so here comes the one for March: -------- Opprinnelig melding -------- Emne: IPv6 brokenness in Norway, March 2010 Dato: Thu, 01 Apr 2010 01:35:01 +0200 Fra: Tore Anderson <tore.anderson(a)redpill-linpro.com> Organisasjon: Redpill Linpro AS Til: ipv6-ops(a)lists.cluenet.de Hi list, I'm happy to announce that the client loss is at an all-time low: 0.074% over the whole month, and it's been steadily decreasing. Buggy versions of Opera as well as Mac OS X appears to be responsible for about 95% of all measured client loss. Some noteworthy dates and events: 20100302: Opera 10.50 released, using getaddrinfo() on Windows. Gets an initial boost thanks to the Microsoft browser ballot. 20100322: Opera pushes 10.51 to their auto-update function. 20100324: A-Pressen Interaktiv re-joins the experiment. 20100327: First day of (extended) Easter holiday for many Norwegians. 20100331: The Gathering, a large data-party, kicks off. Provides native IPv6 connectivity to all participants. The numbers show that the release of Opera has helped quite a lot. Before the release of 10.50, the overall client loss was above 0.090%, but already right before Easter holiday it's below 0.065%. Easter holiday shows an interesting effect - both the measured amount of native IPv6 _and_ client loss drop sharply. The reason for this is that there's one particular network here in Norway that is the by far largest deployment of native IPv6 (about 80-85% of all requests over native IPv6 comes from it), but it is at the same time one of the largest causes of client loss, because it aggravates the Mac OS X/Opera problems significantly by filtering 6to4 traffic on ingress for a large number of end users (that have no native IPv6 service). The typical user on this network is also much more likely to take an extended Easter holiday than the the rest of Norway's population, I believe. I've been measuring the uptake of Opera 10.50+ on Windows Vista/7 in the whole period, and it has been steadily increasing even during the extended Easter holiday. About 72.5% of the Win Vista/7 Opera users were using 10.50+ at the end of the month. So while I do expect the client loss number to rebound somewhat when Easter holiday is over (on the 6th of April), I will be very surprised if it stabilises higher than 0.06-0.07%. The Mac OS X problem appears to occur when a client station has internet service using NAT/RFC 1918 numbering for IPv4, and 6to4 for IPv6. The Apple Airport Extreme SOHO router can operate in this way, and did so by default up until recently. In this case, OS X, or more precisely its getaddinfo() implementation, will prioritise 6to4 over IPv4. In addition, GNU libc (therefore all major Linux distributions) behave in the same way, but I'm not able to measure any impact, probably because there's so few Linux users to begin with. The issue is not actually a bug, but a shortcoming of RFC 3484. I've elaborated on it in reports to Apple and the glibc developers here: http://lists.apple.com/archives/Ipv6-dev/2010/Mar/msg00003.html http://sourceware.org/bugzilla/show_bug.cgi?id=11438 As an aside it's a bit fun to see how a relatively small deployment of IPv6 eyeballs like the data party (around 5000 participants I think) can dramatically change the amount of hits coming in from hosts with native IPv6. It more than doubled overnight. There's two reports attached, one generated from the readers of VG Multimedia - the online edition of Norways largest newspaper, and also Norway's largest web site, and the other from the readers of A-Pressen Interaktiv - an umbrella organisation that publishes the online editions of about 70 regional newspapers. When put together, they constitute Norway's fourth largest web site. In addition to the overall calculation, I've done five other calculations so you can see the individual impact of the different problems I've identified: - One that excludes hits from buggy versions of Opera on Windows Vista/7 (which auto-configures 6to4 and Teredo by default) excluded, - one that excludes hits from buggy versions of Opera on other versions of Windows (where a user must explicitly enable 6to4/Teredo), - one that excludes all hits from Mac OS X, - one that excludes all of the above, and - one that excludes all hits from the two significant end-user networks in Norway that filter 6to4 ingress traffic (one of them is the one I discussed above). This calculation does _not_ exclude Opera/OS X; when Opera and OS X are excluded, the two networks have about the same levels of client loss as rest of the internet. The seventh column shows approximately how much of the total client loss would have been avoided (in percentage points and percent), if the software in question didn't prefer 6to4 over IPv4, or, in the last case, if the two end-user networks mentioned didn't filter 6to4 on ingress. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27

1 0

ipv6 multicast
by Kristoff Bonne 01 Apr '10

01 Apr '10

Hi, As multicast is part of standard ipv6-stack, I was wondering how many ISPs who have ipv6 enabled have (or plan to have) ipv6 enabled on their backbone. Are there any statistics on this? Cheerio! Kr. Bonne.

1 0

IPv6 Pilot in NL: seeking customers
by Marco Hogewoning 30 Mar '10

30 Mar '10

(wearing my XS4ALL hat) We just announced to the media we are expanding our current trials to support native IPv6 over DSL to 1000 lines. These 1000 places are given away on a first come first serve basis. To give everybody a fair chance people can subscribe to this pilot starting Friday April 2nd, 12:00 CEST. In this pilot we ask for people to supply their own DSL cpe which is IPv6 capable or even hack around with linux images where possible. This pilot will serve 3 main goals: - Test interoperability between our gear and setup and the solitions currently on the market - Test those CPE solutions in the wild, we tested some of them in our own lab but it's hardly the same as everyday use in a random residential environement. - Fine tune our support procedures and figure out what training is needed. Next to that We'd love to see what problems will arise when IPv6 is switched on in a regular residential networking environment. Now obviously, since this is a DSL pilot there are some geographical boundaries on who can enter. If you happen to live in the Netherlands and are an XS4ALL customer please do subscribe. We already posted a list with some of the CPE we have tested and are known to work, these include some AVM FRITZ!Box models, some cisco SOHO boxes (8xx serie) and the latest release of Draytek Vigor. If you happen to know some others or happen to built DSL modems yourself, please contact me of list. Basic requirements are ADSL2+ with PPPoA, IPCP and IPv6CP using DHCPv6-PD to get the addresses. As a first result, the press release was picked up by a lot of media and the comments are mostly positive. Hopefully in a few weeks time we have some more data to report on. The original annoucement (in Dutch): http://www.xs4all.nl/klant/ipv6/ MarcoH

1 0

Internet Society IPv6 Workshop
by Phil Roberts 30 Mar '10

30 Mar '10

The Internet Society is hosting an IPv6 Deployment Day on April 22 in Seattle, Washington. The meeting is intended for operators who have deployed, are deploying, or are planning to deploy IPv6 in their networks. The proposed topics include business related issues for IPv6 deployment, discussion of pitfalls in IPv6 deployment, and specific technical issues due to IPv6 deployment that potentially affect the whole Internet. This is an open meeting and all are welcome, but space is limited so you will need to register: https://www.isoc.org/isoc/conferences/registration/?id=7ce20e4c88b7e328. If you have any questions please feel free to contact me, Phil Roberts (roberts(a)isoc.org), or Mat Ford (ford(a)isoc.org).

1 0

Spam sent over IPv6 - See results on RIPE Labs
by Mirjam Kuehne 30 Mar '10

30 Mar '10

[apologies for duplicates] Dear colleagues, We were curious to see how much spam is sent over IPv6 these days. Find the results on RIPE Labs: http://labs.ripe.net/content/spam-over-ipv6 We will continue to measure this. If you have any comments or suggestions, please let us know. Kind Regards, Mirjam Kühne

1 0

Measuring IPv6 at Web Clients and Caching Resolvers
by Mirjam Kuehne 25 Mar '10

25 Mar '10

[apologies for duplicates] Dear colleagues, As the remaining IPv4 space continues to shrink, it’s important to keep an eye on how the IPv6 Internet develops. We prototyped a method to measure the IPv6 capabilities of caching DNS resolvers that end-users use when browsing the web. The results of these measurements are now published on RIPE Labs: 1. A summary of the measurements and results can be found here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… 2. Some more detailed analysis (including a breakdown of IPv6 usage per country and city) are here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… 3. The methodology we use for these measurements are described here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… All articles can be accessed from the RIPE Labs home page at http://labs.ripe.net If you have any comments or suggestions, please do not hesitate to submit them to the RIPE Labs forum or send them directly to me. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Call for agenda items for RIPE in Prague
by Shane Kerr 19 Mar '10

19 Mar '10

Hello all, The next RIPE meeting in Prague is coming up. We would like your input on the agenda for the meeting. We are hoping to have a brainstorming session at the beginning of the IPv6 working group, to try to come up with some ideas about how we can achieve the goals in our new charter. We would also like other items. Our intention is to look at each topic and try to get ones of interest to the larger RIPE community in the EOF portion of the meeting, and have the IPv6 working group focus on things interesting to people working in the IPv6 world. All items that are IPv6-related are of interest. Please send your proposals to David, Marco, or myself - all reasonable offers considered. Your friendly co-chair, -- Shane

1 0

IANA depletion in less than 1 year?
by Shane Kerr 17 Mar '10

17 Mar '10

Hey all, I noticed this site in someone's signature: http://ipv4depletion.com/ It uses a different prediction than the well-known one by Geoff Huston, although the results are not too different (which I guess is good): http://ipv4depletion.com/?page_id=4 Interesting. :) -- Shane

5 4

Re: Expected time frame for IPv6 deployment
by Edu Abume 14 Mar '10

14 Mar '10

________________________________ From: Edu Abume <eduabume(a)yahoo.com> To: ipv6-wg(a)ripe.net Sent: Sat, March 13, 2010 1:24:35 PM Subject: Expected time frame for IPv6 deployment Hi Does anyone know the average period for IPv6 deployment. What is the estimate for small and large sized organization? Are the transition mechanisms the same for these organizations? Thanks and awaiting reply. Edu

4 3

Expected time frame for IPv6 deployment
by Edu Abume 13 Mar '10

13 Mar '10

Hi Does anyone know the average period for IPv6 deployment. What is the estimate for small and large sized organization? Are the transition mechanisms the same for these organizations? Thanks and awaiting reply. Edu

1 0

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

12 27

fyi: dutch special issue coming up.
by Peter van Eijk 11 Mar '10

11 Mar '10

Hi everybody, For those of you who read Dutch and are not a member of the dutch IPv6 taskforce list, I have just posted an announcement for the special issue of a dutch IT management magazine on ipv6-tf(a)ams-ix.net Regards Peter van Eijk, +31 6 2268 4939, peter @ digitalinfrastructures.nl

1 0

/127 for point to point links
by Vegard Svanberg 25 Feb '10

25 Feb '10

Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers. RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me. So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there. -- Vegard Svanberg <vegard(a)svanberg.no> [*Takapa@IRC (EFnet)]

14 16

Confirmation of Marco Hogewoning and Shane Kerr as co-chairs
by David Kessens 22 Feb '10

22 Feb '10

All, Our last call to confirm: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html and Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html as additional co-chairs for the ipv6 working group has ended. I have not received a single objection. I did receive a large number of positive responses before and after the Last Call started. If you like, all responses were posted to the mailing list and can be viewed by checking the working group mailing list archives. I believe we have now reached consensus to appoint Marco Hogewoning and Shane Kerr as co-chairs for the ipv6 working group. I would like to thank everybody for your participation in the discussion and I would like to welcome Shane and Marco as my co-chairs. Thanks! David Kessens ---

3 2

Re: [ipv6-wg] Publication of default assignment sizes for end-user network ?
by Denis Walker 17 Feb '10

17 Feb '10

>>> 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. > > This may as well be another solution, but it still needs some way of > signalling where the actual boundary between customers is as I see > no way to delegate it down to the customer level unless there is > some way to incoorperate it into the CPE. > > And that's I think my main argument opposing to this path, it takes a > lot of time to and develop that model ad get it implemented across > all the LIR's. The big benefit of solving it at the RIR level is that it's > only a handfull of systems that need to be changed and the basic way > to retrieve that information is already there in the form of the whois > protocol. > > I'm not syaing I don't like your solution, I'm just afraid that > deployment will be just to late. > > Grtx, > > Marco Hi Marco Sorry for the late response. I missed the original posting on this list, then saw your follow up on the IETF list. The RIPE NCC also has the same problem with the RIPE DB. Currently we implement some rate limiting on individual IP addresses. As you have explained here, this does not scale for IPv6. The Database Group at the RIPE NCC has already done a lot of thinking internally on this and other issues on moving the RIPE Database into an IPv6 world. We would welcome ideas and thoughts from the community about use cases, issues and problems you can foresee with the RIPE DB in an IPv6 world, even if people don't have the solutions. Of course suggested solutions are also welcome. Let me throw some pointers at you from our thinking. Firstly don't let your thoughts be constrained by the current RIPE DB. This was designed in an IPv4 world with IPv6 bolted on later. Think out of the box. Don't worry too much about the data model, interfaces, APIs, tools we have now. Focus on what the RIPE DB needs to do for you in an IPv6 world. For example you discuss the problem of not knowing what the block size is that any IPv6 address belongs to. This is because the current thinking is to not store all assignments in the RIPE DB. Suppose we re-assess what data needs to be stored, who needs access to it and for what purpose. Suppose we design a new data model and provide new APIs and new tools built on those APIs. Then one possibility may be for each LIR to upload a daily dump of assignment changes and leave it up to the RIPE NCC to process the data. We can do batch processing over night and sync the RIPE DB with LIR's databases. This will not have the serious impact you referred to on your day to day operations. We don't need to store the same information we do now for an IP address. We can store different information about addresses used for different purposes. Maybe not all the stored information needs to be accessible by all people who query the RIPE DB. So we can build in data protection safeguards. With new query interfaces, we can provide access to this data more easily and in many different formats. So perhaps you can widen your thinking now about possible solutions to new problems in an IPv6 world. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0