- ipv6-wg - mailman.ripe.net

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

Announcement: RIPE NCC Training Courses
by Olivia Mijnals-Ruimwijk 16 Feb '10

16 Feb '10

[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

Discussion period for co-chair selection until 20100208
by David Kessens 12 Feb '10

12 Feb '10

All, The call for candidates for co-chairs of the IPv6 working group has resulted in two candidates. See below for their names and a link to the mailing list with their motivations and plans for the working group: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html This brings us to the next step in our process: 1) The nominees are given a chance to determine whether they want to be considered or withdraw as they decided that there are other good candidates already available 2) The community may express opinions that could help the candidates to come to a decision on whether they want to be continued to be considered as a candidate - the community may consider appointing more than one co-chair in case of several good candidates Let's take until the end of Mon Feb 8, 2010 in a timezone of your choice to determine an outcome for both 1) and 2). I already have seen some discussion regarding point 2) and it leads me to believe that there is at least some support to appoint both candidates as co-chairs. Before making such a determination though, I would like to see a bit more discussion/comments, especially from people who have not taken a position yet on this topic. Basically, knowing our candidates, I would like to hear from you whether you prefer to appoint one or two co-chairs, and whether you have any preference for either candidate in case you believe one co-chair is enough. Note that this period is for open discussion and that it is perfectly fine to do alternate proposals. Our objective is to see if we can come to a consensus which allows us to avoid more complex ways of making a selection such as a vote. After our discussion period is over, I will determine if there is enough basis to do a Last Call to confirm a selection decision as determined from our discussion phase, or whether we perhaps need a bit more time for discussion or that we will have to resort to organizing a vote. I hope this helps, David Kessens ---

10 12

Re: [ipv6-wg] Youtube over IPv6!
by Peter van Eijk 12 Feb '10

12 Feb '10

A couple of days ago Martin Milnert wrote <qoute> The time when it began is clearly visible in our own IPv6 graphs, http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html , and you can see similar correlated data at for example http://www.de-cix.net/content/network.html . </quote> What puzzles me is that we see none of this at the AMS-IX, have a look at http://www.ams-ix.net/sflow-stats/ipv6/ Does anybody have a clue as to why that is? Peter van Eijk (dutch IPv6 taskforce)

6 9