- 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

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

Re: [ipv6-wg] Youtube over IPv6!
by Mirjam Kuehne 12 Feb '10

12 Feb '10

Dear all, Martin Millnert wrote: > > There are plenty previous work done in following/measuring several of > > these points. Would be nice with some potaroo.net type, stable, place to > > follow it, though. > I am not sure this is exactly what you were looking for: On RIPE Labs we published a list of IPv6 measurements various people are doing: http://labs.ripe.net/content/ipv6-measurements-compilation It also lists to potaroo, RIS, CAIDA and a lot more. We are currently working on a follow-up article listing data and statistics we found in the meantime. If you are aware of other measurements related to IPv6, we'd be happy to include them. Kind Regards, Mirjam Kühne RIPE NCC

1 0

Re: [ipv6-wg] /127 for point to point links
by Vegard Svanberg 12 Feb '10

12 Feb '10

* Chris Buckridge <chrisb(a)ripe.net> [2010-02-12 11:36]: > Thanks for your email. I would suggest that you send your question > to the RIPE IPv6 Working Group mailing list - you can subscribe > here: Uh, I did, didn't I? -- Vegard Svanberg <vegard(a)svanberg.no> [*Takapa@IRC (EFnet)]

1 0

IPv6 Act Now: News Update
by Chris Buckridge 11 Feb '10

11 Feb '10

Hi all, A couple of news items from the IPv6 Act Now newsfeed over the last week that might be of interest: First accreditation issued for testing to US IPv6 product specs (9 Feb 2010) Amid all the discussion of government leading the way on IPv6 through procurement, news from the US that the University of New Hampshire's test lab is among the first wave of labs to be accredited to test networking products for compliance with government IPv6 specifications. <http://www.ipv6actnow.org/2010/02/ipv6-and-its-future-prospect-in-developin… > AfriNIC embraces Internet challenges in Africa (8 Feb 2010) An extensive interview with AfriNIC CEO Adiel Akplogan, discussing the challenges facing the region's Internet community and some of the new roles AfriNIC is taking on, including working with law enforcement agencies and participating in the Africa Union heads of state summit. <http://www.ipv6actnow.org/2010/02/afrinic-embraces-internet-challenges-in-a… > Pakistan needs to shift to Internet Protocol Version 6 (9 Feb 2010) IPv6 makes it into the Pakistani press, with the IPv6 Monitory Group of Pakistan Telecommunication Authority (PTA) making a number of recommendations for the widespread adoption of IPv6 in the country (including establishing a National Internet Registry). <http://www.ipv6actnow.org/2010/02/pakistan-needs-to-shift-to-internet-proto… > Regards, Chris Buckridge, RIPE NCC

1 0

Request for approval of the minutes for wg session RIPE 59 (20100207)
by David Kessens 10 Feb '10

10 Feb '10

Please find below the minutes from the IPv6 WG session at RIPE 59. The minutes will be declared final if no objections, except for minor editorial corrections that will be fixed before publication, will be received by the end of Sunday February 7, 2010 in a timezone of your choice. Finally, I would like to thank Alex Band for the excellent minutes! Thanks, David Kessens --- RIPE Meeting: 59 Working Group: IPv6 Chair: David Kessens Date: Tuesday October 6, 2009, 16:00-18:00 David welcomed the attendees and opened the session. A. Administrative Matters o Welcome o Select scribe: Alex Band o Select Jabber Monitor: Rumy Kanis o Finalize agenda o Approval of minutes from previous working group meeting B. RIPE NCC IPv6 Update James Aldridge, RIPE NCC http://www.ripe.net/ripe/meetings/ripe-59/presentations/aldridge-ncc-update… There were no questions. C. Future of the Working Group: Charter Discussion Shane Kerr, David Kessens. Input from the audience http://www.ripe.net/ripe/meetings/ripe-59/presentations/kessens-v6-wg-futur… Shane mentioned that the initial idea for an IPv6 Working Group came from looking at the statistics Geoff Huston publishes. "Make IPv6 Happen", was the summary of the charter of the WG. Most of the discussion on IPv6 is actually in the Address Policy WG, so he proposed to shut down the WG and move on to a bigger and better thing. David asked the audience for input. Olaf Kolkman (NLNetlabs) asked how the activities of the WG tied into the IPv6ActNow website. Shane said that there is not really any tie in, and that he thought that is was a shame that something like IPv6ActNow is necessary at all. Rob Blokzijl (RIPE Chair) mentioned that the message that is coming out of the WG is heard by the community at large, however, it doesn't seem to be received and digested by the industry on a wide scale. He proposed that the WG is not shut down, because there is important work to be done, especially in the coming two years and when IPv4 has run out. Gert Doering (Spacenet) commented that the WG is not the place where people go nowadays to learn about IPv6. At the RIPE Meeting, those kinds of discussions are held in the Plenary. Rob gave an example: there were two presentations about the general implementations of IPv6 at customer premises. In one case, the CPE worked fine, in the other it didn't. He would have liked to have seen a technical presentation in the IPv6 WG session on why that is. Shane responded there are definitely opportunities for the WG in that capacity, and even other topics related to IPv6, like Multi-layer NAT. Denesh Babutha (Aexiomus//Cyberstrider) agreed that the WG had reached the end of its useful life as originally envisaged. He said that, as such, the WG needs to evolve, and he thought that this needed to happen through the the charter. Denesh added that the WG needed to move away from repeating the IPv6 situation in every single meeting and move onto more useful discussions. The new charter should be inclusive of other industry areas too. David said that there were many topics covered by the WG that were not originally in the charter. Bernard Tuy said that there is an enormous need for technical training and that kind of knowledge can come from the WG. David asked the audience how to move forward with the WG and whether it should continue in it's current form? Ruediger Volk (Deutsche Telekom) commented that the current form seems to be "quasi-plenary". Rob commented that the WG should be modest in its aims and not try to reach the end goal without some intermediate steps. He said that the WG should focus on real world implementations. Shane commented that the WG did not need to come up with a new charter here and now. Rob proposed that a new draft charter is written. David summarized the feedback for a new charter as more focus on education and outreach activities. Maarten Botterman said that not all of those activities have to be within the WG. David asked the audience if preparing for a hybrid IPv4/IPv6 world should be part of the charter. Rob commented that outreach should lie with the RIPE NCC efforts, such as the IPv6ActNow initiative. He said that training is a sensitive issue because the RIPE NCC does not want to compete with its members. Rumy Kanis (RIPE NCC Training Services Manager) commented that the RIPE NCC offers IPv6 training, but careful steps were taken to ensure the RIPE NCC does not compete with the membership. Marco Wertejuk (Binconsult) said that he believes the focus for the new charter should be "how to encourage conservation of IPv4 and deployment of IPv6". David said that he assessed from the audience feedback that there isn't much support for the WG to focus on non-technical outreach activities. David asked Rob for a time line. Rob said that the WG should take things slowly, and propose a new charter at the next RIPE Meeting and that further discussions should continue on the mailing list. D. Future RIPE Network Experiments - David Kessens. Input from the audience David asked the audience if there was further interest in IPv6 network experiments during a RIPE Meeting. Gert said that forcing IPv6 on people is actually a good idea. He said we should even go as far as making the RIPE Meeting network IPv6 only for the whole week. He added that we should do the experiment without NAT-PT. David said that he would like to see a completely new experiment. Marco Hogewoning (XS4all) said that although IPv6 connectivity in general is good, tunneling is needed in some places in order to get full connectivity. David Wilson (HEAnet) said that the IPv6 hour should be repeated, and that the WG should get new experiences because things have changed since the last time it was done. Izumi from JPNIC that for their experiments, they created different testbeds for different kinds of implementations. David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be. E. IPv6 Deployment: What are the Remaining Issues and Bottlenecks? - A panel discussion with interactive input from the audience. Moderator: Maarten Botterman, GNKS Consult http://www.ripe.net/ripe/meetings/ripe-59/presentations/botterman-towards-v… Gert Doering introduced himself and asked the question "What kind of Internet do we want to have in five years?". Geoff Huston introduced himself and in a slide set proposed the question "Is the IPv6 transition an example of market failure?" http://www.ripe.net/ripe/meetings/ripe-59/presentations/huston-ipv6-transit… Kurtis Lindqvist introduced himself and explained his own experiences with IPv6 deployment. He said that doing a slow and gradual implementation has been very beneficial. Maarten Botterman did a live survey, with the question "What would you gain by postponing, and what would you gain by stepping up to the plate, earlier rather than later?". 40 votes were cast, most go to: o By stepping up to the plate I have time and space to do the transition, which will allow me to do it gradually and well thought through o By stepping up to the plate I confirm my brand's image as 'state-of-the-art' or 'top-of-the-wave' Geoff commented that the respondents are most likely non-representative. Gert said that he is not surprised with the numbers. Kurtis said that looking at the responses, he is optimistic. Maarten said that some people responded with 'none of the above'. He asked three of those people to comment: Ruediger said that for all of the relevant players there is still enough time for doing a proper job. Bernard said that there was no vendor support, so ISPs will never start until that happens. Jan Hugo Prins said that there will never be end user demand. Deployment is not picking up because of security issues. Geoff reiterated that he thought that the situation we are finding ourselves in right now is no accident. It is in many companies' interests to delay IPv6 adoption. Shane agreed with Geoff. Gabriella Paolini (GARR) said that the biggest issue is that middleware doesn't support IPv6 and that changes very slowly. Maarten did another live survey with the following question: "There is perception and experience of/with a number of hurdles that seem to be difficult to overcome. Which are important to you?". o As there is very little customer demand, I cannot justify the investment to my management, even if I would like to move o I have the experience that my vendors cannot deliver what I need o None of the above (highest score) Ruediger said that the options are very extreme. Slow and gradual deployment is a real option. Geoff commented that in his days at a telco, the biggest cost turned out to be customer support. IPv6 could become expensive in that respect with end users calling in because of issues. Maarten asked people to comment: - Wilfried Woeber (Vienna University) commented that he would have to select 'none of the above' for all questions. His issue is that the questions are too black or white. The biggest problem from his point of view is in layer 7 or 8: infrastructure, applications etc. The backbone has been done for years. - Marco said that he agreed with Geoff, the cost is not in the hardware. IPv6 is not a product, don't pay extra for it. - An attendee said that in a lot of cases, even though the product spec sheet says that IPv6 is supported, there is no feature parity with IPv4. Gert said he agreed with most of the comments. Geoff said that any vendor is willing to give you what you want, as long as you put down the money. Kurtis added that there was also a big push from vendors for MPLS. Marco added that some IPv6 functionality used to be free, but after vendors realized that there was a market for it, they started charging for a license. Maarten did another live survey, the results with the most votes were: o The deployment of IPv6 is unavoidable for my organization in due time o Technically, everything is in place to deploy IPv6 Geoff commented that openness is the key in the end. IPv6 is the only way to guarantee that. Kurtis added that he was surprised that so many people responded "I will deploy in due time", because that is pretty close. Geoff re-stated that the market is well informed, and that this situation is intentional in order to maximize shareholder profits at large corporations. Ruediger agreed that the industry is flooded with information. But he asked how enlightened are people? Geoff responded that it's all about vendor lock in. Brian Nisbet (HEAnet) said that the WG keeps having the same discussion meeting after meeting. He said that he could not believe that people are not well informed. Kurtis said that CFO's cannot be convinced of the urgency of something that will happen two years from now. An attendee said that for mobile operators, the vendors of mobile terminals are the blockers. Maarten showed the results of the last survey. The panel shared some closing thoughts. The general thought was that the community should stop distributing messaging, and start moving packets. Maarten closed the discussion. F. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Input from the audience No input was given. Y. Input for the RIPE NCC Activity Plan - Input from the audience No input was given. Z. AOB None. David closed the session. ---------

2 5

Last Call: Confirmation of co-chairs (20100217)
by David Kessens 10 Feb '10

10 Feb '10

The discussion phase regarding new co-chair positions has now ended. It seems that there is strong support to appoint: 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 as additional co-chairs for the ipv6 working group. Please let us know if you have objections to such a solution by the end of Wed Feb 17, 2010 in a time zone of your choice. There is no need to restate your supportive position again as there was already a significant number of people that expressed support for this approach. Thanks, David Kessens ---

1 0

announcing DNS64-NAT64 opensource implementations
by Marc Blanchet 08 Feb '10

08 Feb '10

<sorry for cross-posting/> This is to announce the availability of two NAT64-DNS64 open-source implementations by Viagenie, as follows: ====== NAT64 ====== BSD PF: this implementation of NAT64 is made by modifying the PF packet filter available on BSD systems. A new 'nat64' statement is created in the pf.conf file to enable the nat64 functionality. Linux Netfilter: The implementation of NAT64 for linux is available as a kernel module. It uses Netfilter's facilities for packet interception. The configuration is done with parameters provided at module insertion. ====== DNS64 ====== As announced in july 2009 during IETF Stockholm, the companion DNS64 functionality is also available in two implementations, as follows: BIND: this implementation of DNS64 is made by modifying the BIND DNS server. A new "dns64-prefix" statement in options is created in the named.conf file to enable DNS64 functionality. Unbound: this implementation of DNS64 is made by adding a module to the Unbound DNS server. To enable the DNS64 functionality, the module should be declared and the dns64-prefix statement should be added in the unbound.conf file. The two functionalities (NAT64 and DNS64) make a complete system for translating IPv6-IPv4 packets. The source code, some pre-compiled packages and project description are available at: http://ecdysis.viagenie.ca. This project was funded by NLNet foundation and Viagenie. We are looking for feedback, patches, suggestions from the community. http://ecdysis.viagenie.ca Regards, Marc Blanchet, Simon Perreault, Jean-Philippe Dionne Viagenie

1 0

IPv6 experiments at future RIPE Meetings
by James Aldridge 08 Feb '10

08 Feb '10

Reading the minutes of the IPv6 WG at RIPE 59 I read: > David asked the audience if the IPv6 Hour should be rerun at future > meetings.. There is consensus that it should be. Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour". What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour. One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet? Any feedback would be appreciated. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC RIPE Meeting technical team

17 24

Re: [ipv6-wg] Discussion period for co-chair selection until 20100208
by Ralph Smit 08 Feb '10

08 Feb '10

Marco Hogewoning wrote: > On 3 feb 2010, at 23:44, David Kessens wrote: > >> 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. > > > Hi All, > > I had a short chat with Shane this afternoon and we would like you to > know we as candidated would prefer the option to appoint two co-chairs. > Shane and I have known eachother for quite some time and our goals and > objectives for the future of the IPv6 working group are the same, we > both are looking forward working with David and the community to live up > to the new charter en make IPv6 a succes. > > Thanks for all the support so far, > > MarcoH and Shane > > > I support both candidates and agree with many who replied before me (and the candidates themselves) that 2 co-chairs would be a good idea. Regards, Ralph Smit.

2 1

Re: RFC 1918 in "production networks"
by Geert Jan de Groot 06 Feb '10

06 Feb '10

> If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network > at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able > to build a working connection. Try it. > Given the number of attendees, the chances for address collisions with > at least one participant's home network can be assumed to be near 100%. One workaround would be to have two (vastly different) 1918 prefixes and giving people the possibility to switch (so, 2 SSID's, 2 prefixes, say 192.168.224.0/20 and 10.210.32.0/20). Chances that someone will conflict with both, are small. For better or worse, we will need to learn how to deal with this - denying these issues doesn't fix the fact that these situations will happen, without the escape of availability of public IPv4 addresses, in the near future. And, of course, if nobody puts pressure on the VPN-sellers, these issues will stick around for *years*. Geert Jan

7 8

IPv6 Act Now update
by Chris Buckridge 04 Feb '10

04 Feb '10

Hi all, A couple of items from the IPv6 Act Now newsfeed over the last week that may be of interest: YouTube Turns On IPv6 support, Net Traffic Spikes (2 Feb 2010) Martin Millnert has already posted some useful information to the list on this subject. Google has quietly turned on IPv6 support for its YouTube video streaming Web site, which sent a spike of IPv6 traffic across the Internet. <http://www.ipv6actnow.org/2010/02/youtube-turns-on-ipv6-support-net-traffic… > IPv6: the new platform (3 Feb 2010) Some perspectives on IPv6 deployment from India, the second largest telecom market in the world. The article includes discussion of the IPv6 survey done in the Asia Pacific recently by TNO/GNKS, who worked with the European Commission and the RIPE NCC on an IPv6 Deployment Monitoring Survey last year: <http://www.ipv6actnow.org/2010/02/ipv6-the-new-platform/> Separate to IPv6 Act Now, the IPv6 adoption issue continues to gain exposure in the mainstream press. Dutch news site nu.nl ran an article this week based on the recent announcement from the NRO and ICANN that the pool of available IPv4 address space has reached 10%: <http://www.nu.nl/internet/2175537/internetadressen-raken.html> [in Dutch] Regards, Chris Buckridge, RIPE NCC

1 0

How polluted is 1/8?
by Mirjam Kuehne 03 Feb '10

03 Feb '10

[Apologies for duplicates] Dear colleagues, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne

1 0

Youtube over IPv6!
by Martin Millnert 03 Feb '10

03 Feb '10

Hello fellow IPv6 admirers, (I'm sending this here on behalf of Shane. :) ) As you might know already, Google has been so *tremendously* kind to, as of ~22 hours ago, initiate the enabling of their Youtube site over IPv6. It is currently available to participants in their Google over IPv6 program, http://www.google.com/intl/en/ipv6/ . The www.youtube.com user interface so far does *not* have any AAAA published, but the *much* more important (traffic wise) image and video servers do. Use tcpdump to verify. Eg., anticimex@hsa:~$ host s.ytimg.com s.ytimg.com is an alias for static.cache.l.google.com. static.cache.l.google.com has address 74.125.13.213 static.cache.l.google.com has IPv6 address 2001:4860:4001:402::15 anticimex@hsa:~$ host v1.lscache1.c.youtube.com v1.lscache1.c.youtube.com is an alias for v1.lscache1.l.google.com. v1.lscache1.l.google.com has address 74.125.97.80 v1.lscache1.l.google.com has IPv6 address 2001:4860:4001:402::10 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 . To figure out all the mappings they give you, if you want to trace etc, something similar to: "for i in `seq 1 24 `; do for y in `seq 1 8 `; do host v$i.lscache$y.c.youtube.com ; done ; done | grep 'IPv6 address' | cut -d' ' -f 1,5 | sort -uk2" could be used - at least from where I sit. Adjust for correctness. I'm sure that as this matures and bugs are wiped out, there will no longer be any need for the Google over IPv6 program and everybody will be able to access this. Until then, join! :) I bow to the Google IPv6 team, their netops and everybody there that is working so hard to give the Internet true CONTENT on IPv6. Yippie! From 48514, much of love! Thank you guys (and gals)! Regards, -- Martin Millnert <millnert(a)csbnet.se>

1 1

IPv6 Act Now news update
by Chris Buckridge 28 Jan '10

28 Jan '10

Hi all, In what I hope will be a regular addition to the IPv6 WG mailing list, I wanted to provide a quick round-up of some of the items we've featured in the IPv6 Act Now newsfeed over the past week. These are provided for your information, but also, we hope, to provoke some discussion. You're obviously welcome to discuss on this list, or you can leave comments on the new pages themselves at www.ipv6actnow.org. I'd also be keen to hear feedback on whether the WG feels that this is a useful activity! Regards, Chris Buckridge, RIPE NCC IPv6 interview: Maria Häll, Swedish Government (28 Jan 2010) Maria Häll, Deputy Director for the Ministry of Enterprise, Energy and Communications in Sweden, and Co-chair of the RIPE Cooperation Working Group, talks about the role governments can play in encouraging IPv6 deployment in the latest IPv6 Act Now video interview. <http://www.ipv6actnow.org/2010/01/maria-hall-interview/> Comcast to start a series of public IPv6 trials using 3 transition mechanisms (28 Jan 2010) Comcast announced plans to conduct production-network trials of IPv6 technology in the coming year. The trials are aimed at helping identify and solve any areas of difficulty involved in the transition to IPv6, and determining what approach will be the easiest and most seamless for Comcast's customers. <http://www.ipv6actnow.org/2010/01/comcast-to-start-a-series-of-public-ipv6-… > Blue Coat introduces industry’s first IPv6 secure Web gateway solution (25 Jan 2010) Blue Coat Systems announced that it has introduced the industry’s first IPv6 secure web gateway solution to enable the secure and seamless migration of applications, services and content between IPv4 and IPv6 environments. <http://www.ipv6actnow.org/2010/01/blue-coat-introduces-industrys-first-ipv6… > 2009, the year before IPv6 took off? (22 Jan 2010) Emile Aben, of the RIPE NCC Science Department, talks about some of the signs of IPv6 adoption seen from the RIPE NCC, in terms of traffic to RIPE NCC websites and services. [links to the RIPE Labs website] <http://www.ipv6actnow.org/2010/01/2009-year-ipv6-took/> BT Diamond IP awarded U.S. patent for integrated management of IPv4 and IPv6 (21 Jan 2010) Shane Kerr mentioned this briefly on the list earlier in the week: BT Diamond IP announced the awarding of U.S. Patent 7,623,547 for "Internet Protocol Address Management System and Method", an IP Address Management (IPAM) system which supports both IPv4 and IPv6 address space using a unique hierarchical container structure and block allocation techniques. <http://www.ipv6actnow.org/2010/01/bt-diamond-ip-awarded-u-s-patent-for-inte… >

1 0

Comcast IPv6 trials
by Sander Steffann 27 Jan '10

27 Jan '10

FYI: Jaap Akkerhuis just brought this to the attention of the Dutch IPv6 task force list: <john_brzozowski(a)cable.comcast.com> wrote: > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. =A0For more informatio= n > please visit the following web site: > > http://www.comcast6.net > > We have also made available a partial, dual-stack version of our portal > which can be found at: > > http://ipv6.comcast.net

1 0

[Fwd: IPv6 deployment scenarios]
by Brian E Carpenter 26 Jan '10

26 Jan '10

Please excuse the interruption if you've already seen this. -------- Original Message -------- Subject: IPv6 deployment scenarios Date: Fri, 22 Jan 2010 10:37:08 +1300 From: Brian E Carpenter <brian.e.carpenter(a)gmail.com> Organization: University of Auckland To: nanog(a)nanog.org Hi, Sheng Jiang (Huawei) and Brian Carpenter (University of Auckland, research consultant to Huawei) are currently running a questionnaire on IPv6 deployment, addressed to every ISP. The purpose is to provide facts for a document about deployment scenarios that we are drafting for discussion in the IETF. We will keep your reply strictly confidential and we will publish only combined results. We will not identify information about individual ISPs in any published results. If you request it, we will not mention you or the ISP in the acknowledgments. Please find the questionnaire at http://www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html Answers are requested ASAP. (Hmm. As I write, the IPv6 access to that server is broken. Hopefully it will be back soon.) btw, we know that the questionnaire is imperfect; all questionnaires are imperfect. Also, this is not a marketing survey; we are after technical information. Regards Brian Carpenter

1 0

Call for nominations for co-chair position ipv6 working group 20100202
by David Kessens 25 Jan '10

25 Jan '10

I would like to invite everybody who is interested him/herself, or would like to propose somebody else for the position of co-chair of the ipv6 working group. Nominations should be received by me or on the list by close of business in a time zone of your choice by Feb 2, 2010. I already received two nominations for Shane Kerr <shane(a)time-travellers.org> and Marco Hogewoning <marcoh(a)marcoh.net>. The procedure that we plan to use to select our co-chairs is outlined in: http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00028.html As mentioned in the above mail, the exact selection procedure is still a proposal and subject to change. David Kessens ---

5 5

Two new IPv6 related articles on RIPE Labs
by Mirjam Kuehne 25 Jan '10

25 Jan '10

Dear colleagues, Please see two IPv6 related articles published on RIPE Labs recently: 1. REX - the Resource Explainer - is now also supporting IPv6 addresses. See a description and some examples here: http://labs.ripe.net/content/rex-supports-ipv6 Please check out the tool and let us know if you have any comments or suggestions. 2. We have been measuring IPv6 usage on RIPE Labs and other servers and found some encouraging results. You can find more details here: http://labs.ripe.net/content/2009-year-ipv6-took Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Proposed procedure for ipv6 working group cochair selection process
by David Kessens 22 Jan '10

22 Jan '10

All, As mentioned earlier, I would like to write down our approach for co-chair selection. This would help us to have an open and transparent process to get a cochair appointed, but also help in the future for other working groups as either an example or at the minimum that they can use the same set of principles. I believe that this request already has resulted in a quite bit useful discussion on a few things that we should, or shouldn't do and many of you mentioned that it would be useful if we don't wait too long as our new charter would also be a good starting point for the appointment of (an) additional cochair(s). Below, I will summarize some of the key principles that I came away with and my initial idea on how to start the process. Since these are initial ideas, I very much welcome your input or if you would be interested in volunteering to work out the text further. At the same time, there doesn't seem to be much disagreement about the first step of the process so I would like to start with that step right away: an open call for candidates. I realize that there is a bit of risk involved on starting this before we have agreed on the full process: however, there has been already quite a bit discussion on the list on the general direction and I have confidence in our community that we will be able to find a workable solution along the way. I will send a seperate mail with an official call for nominations. David Kessens --- Date: Thu Jan 21 21:36:39 PST 2010 Draft Proposal on handling of chair position selection within the RIPE community RIPE (Réseaux IP Européens) is a collaborative forum open to a parties interested in wide area IP networks in Europe and beyond. Work is carried out within a variety of working groups. Each of these working groups has more than one co-chair. The selection process for a chair position is deliberately left to the working group, so that at any given time, the community is free to select the organisational structure that best reflects the work they want to do at that time. Working group chairs are responsible for organizing the working groups activities as defined in their charters. In addition, they are required to participate in the policy making process to judge and ensure that the RIPE policy making process has been properly followed after new policy proposals have been accepted by a working group (http://www.ripe.net/ripe/docs/pdp.html). While the actual implementation of the chair position selection process is on purpose not codified in any process document, it is expected that such a process follows the same principles as outlined in the RIPE policy development process: 1. It is open to all and follows an established, bottom-up process of collaboration. Everyone interested in the well-being of the Internet may propose a policy and take part in the discussions that follow on from the proposal. 2. It is transparent. All discussions and resulting actions are documented and freely available to all. 3. Conclusions are reached by consensus. 4. All policies are documented within RIPE Documents and placed in the RIPE Document Store The same dispute resolution process as used for the policy development applies to cochair selection process or results of the process. The Process As there is no standardized process for working group selection, this section serves as an example only and describes on how the IPv6 working group is currently selecting its co-chairs. The following is a proposal only and it has not been decided on how to continue after the nomination step. - Call for nominations of more than 7 days (self nominations being ok) - During the same time period: 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 - If the discussion period seems to result in a consensus decision, a last call of more than 7 days is issued or - Each nominee writes a short statement to the WG Mailinglist - Election using single transferable vote (we need to figure out whether we can do this online or wheter this is better done at the meeting) ----

5 6

Ars Technica article about the last 20^H^H10% of IPv4 space
by Shane Kerr 22 Jan '10

22 Jan '10

All, I hate to interrupt our normal process discussions, but I liked this article by Iljitsch van Beijnum on Ars Technica yesterday: http://tinyurl.com/yaqu3f9 Maybe not news for folks here, but a nice explanation of different views of how much space is actually available. Sadly, I think the summary is correct: "it's now too late for a smooth IPv4-to-IPv6 transition, so prepare for a bumpy one where we run out of IPv4 addresses before there is widespread IPv6 adoption." Fasten your seatbelts everyone! -- Shane

1 0

working group co-chair(s)
by David Kessens 22 Jan '10

22 Jan '10

All, During the charter discussion, some of you suggested to appoint a co-chair. Most RIPE working groups have more than one chair person. In the past, I have never felt the necessity to do this job with more than one person. However, in the spirit that it is always good to try something new or different, we can certainly add a co-chair if the working group believes this to be beneficial for achieving our goals. Considering that we don't have any formal process for appointing a working group chair, there is no standard on how this is achieved in a transparent and fair way. This might have been acceptable in the early days of RIPE when there were far fewer people involved and governments weren't watching us. Given that there is an interest in appointing an additional cochair, this seems an excellent opportunity to achieve something more than just appointing a co-chair: if we define an open process and are happy with the results, we can propose the process as a RIPE policy proposal to the wider community for the appointment of chair people within RIPE. At the same time, I don't believe we should overregulate and loose one of the key benefits of our loosely organized community. Therefore, my personal preference would be to formulate a set of principles that we need to follow to appoint chair people while the actual implementation can vary depending on the position that needs to be filled. I would first like to hear what people think about this. If there is support, I would like to form a small task force to write a first version of the principles and how we plan to implement them in the ipv6 working group. David Kessens ---

15 22

New charter approved
by David Kessens 14 Jan '10

14 Jan '10

The Last Call for our new charter resulted in a very large number of positive responses and nobody at all speaking up against the new charter. I therefore conclude that we have consensus on the charter. I did receive a few comments from the working group chair list that the first sentence mentioning the 'IP protocol' is a bit awkward as 'IP' already stands for 'Internet Protocol'. It was suggested that we simply use the words 'Internet Protocol' instead of 'IP protocol' to avoid this issue. As this is really only an editorial change, I will go ahead and make this change when I request the RIPE NCC to post the new charter. Please let me know if you have an issue with this editorial change. I would like to thank Shane as the author of the charter text and everybody else who contributed with comments and suggestions for the charter discussion. David Kessens --- New proposed charter for the IPv6 working group: (first sentence was changed from: IPv6 is the next generation IP protocol to: IPv6 is the next generation Internet Protocol) ----------------------------------------------------------------------- IPv6 is the next generation Internet Protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing and fixing operational issues The working group will cooperate with operators and others, both inside and outside the networking industry, to share resources and combine efforts. -----------------------------------------------------------------------

3 2

2009 IPv6 Address Use Report
by Iljitsch van Beijnum 02 Jan '10

02 Jan '10

[ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace-ipv6-2009.php ] 2009 IPv6 Address Use Report Since 2005, I've been compiling an IPv4 address use report every year. With the start of the new decade, this is a good moment to start doing the same thing for IPv6. http://www.bgpexpert.com/addrspace-ipv6.php shows the amount of IPv6 space given out by RIR and by year, while http://www.bgpexpert.com/ipv6addressespercountry.php shows the amount of IPv6 address space by country. Both these pages are updated weekly from the delegation data that the RIRs publish on their FTP servers. 2008 saw a huge increase in the amount of IPv6 space given out and then a big drop in 2009 (amounts of IPv6 address space in the equivalent of /32s): 1999 10.88 /32s in 17 blocks 2000 19.75 /32s in 32 blocks 2001 33.13 /32s in 61 blocks 2002 156.75 /32s in 271 blocks 2003 261.38 /32s in 290 blocks 2004 13340.63 /32s in 295 blocks 2005 26985.00 /32s in 245 blocks 2006 9798.00 /32s in 243 blocks 2007 6687.01 /32s in 491 blocks 2008 81012.02 /32s in 886 blocks 2009 1091.03 /32s in 1280 blocks However, this is not the complete picture. The large number for 2008 is the result of two unusual events. The first one is LACNIC's delegation of the 2804::/16 block to the Brazilian national internet registry (NIR). At some point in the future, the delegation records will not show such blocks as "used" in their entirety anymore. Also, ARIN delegated 14 /22 blocks within the range 2608::/13 to the US Department of Defense. With these two artifacts removed, the amount of IPv6 space given out per year looks like this: 1999 11.00 /32s in 17 blocks 2000 20.00 /32s in 32 blocks 2001 33.00 /32s in 61 blocks 2002 157.00 /32s in 271 blocks 2003 261.00 /32s in 290 blocks 2004 13341.00 /32s in 295 blocks 2005 26985.00 /32s in 245 blocks 2006 9798.00 /32s in 243 blocks 2007 6687.00 /32s in 491 blocks 2008 1140.00 /32s in 871 blocks 2009 1091.00 /32s in 1280 blocks So the number of blocks given out keeps increasing, but their size is going down. There are two reasons for this: roughly between 2004 and 2006, RIPE and APNIC gave out some very large blocks to some very large ISPs. They mostly stopped doing that. And provider independent blocks started to be allowed and are getting more and more popular. These are the /32 - /35 allocations. /32 is the minimum block size given out to ISPs, this used to be /35. So this view shows the numbers of small-to-medium sized ISPs obtaining IPv6 address space: 1999 11.00 /32s in 17 blocks 2000 20.00 /32s in 32 blocks 2001 33.00 /32s in 55 blocks 2002 157.00 /32s in 254 blocks 2003 223.00 /32s in 251 blocks 2004 235.00 /32s in 241 blocks 2005 217.00 /32s in 217 blocks 2006 186.00 /32s in 186 blocks 2007 351.00 /32s in 351 blocks 2008 734.00 /32s in 734 blocks 2009 1011.00 /32s in 1013 blocks These are the blocks larger than /32 that go to large ISPs (excluding the BR NIR and DoD blocks): 2003 38.00 /32s in 3 blocks 2004 13106.00 /32s in 9 blocks 2005 26768.00 /32s in 13 blocks 2006 9612.00 /32s in 14 blocks 2007 6336.00 /32s in 8 blocks 2008 406.00 /32s in 7 blocks 2009 80.00 /32s in 4 blocks And these are the blocks smaller than /35, which are now mostly provider independent blocks, but also "critical infrastructure", such as root servers get a /48 block: 2001 0.00 /32s in 6 blocks 2002 0.00 /32s in 17 blocks 2003 0.00 /32s in 36 blocks 2004 0.00 /32s in 45 blocks 2005 0.00 /32s in 15 blocks 2006 0.00 /32s in 43 blocks 2007 0.00 /32s in 132 blocks 2008 0.00 /32s in 130 blocks 2009 0.00 /32s in 263 blocks So after a small dip in 2006, the number of small-to-medium sized ISPs obtaining IPv6 address space shows a steady upward trend, but apparently the very large ISPs either already got their IPv6 address space, are not focussing on IPv6 right now, are starting with a small block (or several small blocks), or a combination of all of these factors. Even with the BR NIR and DoD blocks included, the (equivalent of) 39395.56 /32s given out in 4111 blocks is only 0.026% of the 536870912 possible /32s in the currently defined global unicast space (2000::/3). For comparison, the number of IPv4 blocks given out is 99562.

1 0