- ipv6-wg - mailman.ripe.net

New on RIPE Labs: Update on IPv6 Address Distribution
by Mirjam Kuehne 02 May '12

02 May '12

Dear colleagues, At the recent RIPE Meeting we presented some IPv6 address distribution statistics. In this RIPE Labs article, you can find statistics on IPv6 allocations and assignments. In particular, the article details what affect the removal of the requirement to be multihomed had on the number of assignments and the relationship between the age of an LIR and the number of IPv6 addresses they have received. https://labs.ripe.net/Members/mirjam/update-on-ipv6-address-distribution Kind regards, Mirjam Kuehne RIPE NCC

1 0

Last Call for publication of RIPE-501bis (reply by 20120426)
by David Kessens 02 May '12

02 May '12

In the IPv6 working session at the RIPE meeting in Slovenia, we discussed: http://go6.si/docs/Requirements-for-IPv6-in-ICT-equipment-v.9.pdf The meeting participants felt that the document is now ready for publication. Therefore, I would like to give everybody a final chance to bring up major issues that must be resolved before publication. Please comment by Thu 20120426 if you have major issues that require a delay in publication. We will ask the RIPE NCC to publish the document after the Last Call ends if no serious issues are uncovered by that date. The RIPE NCC will do an editorial pass for spelling, grammar and minor issues before it will publish the document. Feel free to contact the working group chairs directly <ipv6-wg-chairs(a)ripe.net> if you find anything minor that doesn't need working group review and we will make sure that it gets fixed in the final document. Thanks, David, Shane & Marco ---

3 3

RIPE 64 Working Group session
by Marco Hogewoning 18 Apr '12

18 Apr '12

Hi all, This is to remind you that the IPv6 Working Group will meet here in Ljubljana, tomorrow Thursday the 19th. We have 2 sessions, starting at 11:00 after the first coffee break in the main room. With a lunch break in between we continue at 14:00 in the same room for the second half. The agenda is posted to the website and available via https://ripe64.ripe.net/programme/meeting-plan/ipv6-wg/ We hope to see you all there. In case you couldn't make it to Slovenia, as always these sessions will be broadcasted and recorded for the archives. For remote participants feedback channels using IRC/Jabber will be available. More information can be found on the RIPE 64 meeting website, the stream is available via https://ripe64.ripe.net/live/ (Grant Union Hall). In case you want to join remote, Slovenian local time is UTC +0200. See you tomorrow, Marco, David and Shane

1 0

Fw: WG Review: sunset4 (sunset4)
by Shane Kerr 18 Apr '12

18 Apr '12

All, FYI, the IETF may be starting some (more) work of interest to IPv6 folks. Perhaps this will inspire us to change the IPv6 working group to the IPv4 CGN/NAT working group. ;) Cheers, -- Shane Begin forwarded message: Date: Tue, 17 Apr 2012 09:41:57 -0700 From: IESG Secretary <iesg-secretary(a)ietf.org> To: IETF Announcement List <ietf-announce(a)ietf.org> Subject: WG Review: sunset4 (sunset4) A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg(a)ietf.org) by Tuesday, April 24, 2012. sunset4 (sunset4) ----------------------------------------- Status: Proposed Working Group Last Updated: 2012-04-13 Chairs: TBD Internet Area Directors: Ralph Droms <rdroms.ietf(a)gmail.com> Brian Haberman <brian(a)innovationslab.net> <TBD> Internet Area Advisor: <TBD> Area Advisors: OPS: <TBD> TSV: <TBD> RTG: <TBD> Mailing Lists: <TBD, pending final WG name> Description of Working Group: The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6. The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed. These technologies will likely be less optimal than equivalent technologies for IPv6-only and dual-stack networks. The Working Group works only on IPv4 protocols to facilitate IPv4 sunsetting. The Working Group may work on fixing security bugs in existing IPv4-specific protocols but is not chartered to add new security functionality to those protocols. The working group will provide a single venue for the consideration of IPv4 sunsetting, while ensuring that any such technologies do not impede the deployment of IPv6 and do not duplicate functions and capabilities already available in existing technologies. Therefore, along the lines of draft-george-ipv6-support, before the working group adopts any technology, it must: 1) describe the problem to be solved and show that there is widespread demand for a solution 2) demonstrate that the problem can not be solved with existing technologies 3) provide a description of the proposed solution along with the impact on current IPv4-only use and its ability to promote the deployment of IPv6 These steps will likely be described in the form of a use case and requirements document. Only after the above mentioned steps have been completed and the results accepted by the community will the IETF consider adding new work items to the Working Group charter. This new work may include protocol specifications. The work spans over multiple IETF areas including as Internet, Operations, Transport and Routing. Therefore, cross-area coordination and support is essential and required. Any work on IPv4 to IPv6 transition methods is out of scope. The initial work items are: * Review current CGN documents, including requirements for standardization, and determine is CGN is a suitable sunsetting technology to become a work item * Gap analysis of IPv4 features to facilitate IPv4 sunsetting Milestones 2012-09 Complete review of CGN and, if necessary, propose CGN work items 2013-06 Send gap analysis on IPv4 sunsetting to IESG

1 0

Slides for "Recent Advances in IPv6 Security" at Hackito Ergo Sum 2012
by Fernando Gont 16 Apr '12

16 Apr '12

Folks, The slides for my presentation entitled "Recent Advances in IPv6 Security" at Hackito Ergo Sum 2012 (http://2012.hackitoergosum.org/) are available at: <http://www.si6networks.com/presentations/HES2012/fgont-hes2012-recent-advan…> The same slides are available in other formats at: <http://www.si6networks.com/presentations/index.html> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Slovenian IPv6 study for government - now available in English language
by Jan Zorz ＠ go6.si 11 Apr '12

11 Apr '12

Dear @IPv6 WG Long time promised Slo IPv6 study, done for our government in 2010 is now available in English language. The authors did a revision and added few changes just in order to make document more "current". All in all, many things that we wrote is 2010 still holds. You can download the PDF from following page: http://go6.si/en/2012/04/slovenian-ipv6-study-english-version/ In the doc there are 11 key questions from governmental point of view and many answers to them. Hope that this work can help some governments in their way towards IPv6. See you all in few days, Jan Zorz Go6 Institute.

1 0

Preview of the final RIPE-501bis.
by Jan Zorz ＠ go6.si 10 Apr '12

10 Apr '12

Dear IPv6 WG. After long and exhausting IETF week, where we met with some great experts from the industry and did some sanity checks and corrected some mistakes and misunderstandings in the RIPE-501-replacement document, we are issuing next (9th) version of the draft, that is in our opinion really final one. I mean it. Last one. There was lot's of time, efforts and work put into this document and I think we are done. This replacement document is also meant as a some kind of input or initial template for EU IPv6 profile, so we wanted it to be very solid and accurate. Thanks to all of you involved, you know who you are (you are all in Acknowledgements section ;) ) and thnx to this WG and their co-chairs for support, help and all good comments. We already set the last version to RIPE-NCC for grammar checks and conversion into HTML in order to appear in RIPE Documents section as a draft, but meantime, we are publishing the last version also in PDF in order for you, community, to read it prior to RIPE64 meeting. http://go6.si/docs/Requirements-for-IPv6-in-ICT-equipment-v.9.pdf Please, those of you who are interested and have time, read it and express you r opinions and possible comments. Rumor has it, that we'll have "review" period over the RIPE64 meeting and Last call shortly after that. As this is not an official PDP, we can also propose chairs to change the procedure, if there is any need for that. Track of the progress and different versions of the draft can be found at: http://go6.si/ripe501bis/ Cheers from co-authors: Merike, Sander and Jan

3 3

IPv6 stable privacy addresses
by Fernando Gont 10 Apr '12

10 Apr '12

Folks, We've posted a revision of our IETF Internet-Draft entitled "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)". The document is available at: <http://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-01.txt> The abstract of the document is: ---- cut here ---- This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. ---- cut here ---- Interested in IPv6 security? -- Follow us on Twitter: @SI6Networks Interested in discussing IPv6 security topics? -- Join the ipv6hackers@ mailing-list at: <http://www.si6networks.com/community/mailing-lists.html> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 SIM cards at RIPE64
by Jan Zorz ＠ go6.si 03 Apr '12

03 Apr '12

Dear IPv6 WG :) For those who are attending RIPE64 meeting in Ljubljana: We just got confirmation from Simobil, one of mobile operators that deployed IPv6 in their mobile network, that they will provide 100 SIM cards for RIPE64 attendees. The cards will be pre-provisioned with IPv6 APN and IPv6 traffic for free. Of course, don't misuse them as they might throttle you if they see any abuse or misuse. For those, who will need also to make phone calls and SMS-es or IPv4 traffic, 5EUR vouchers will be available. Official announcement will go out on a general mailing list, just wante to give you heads-up :) So, fellow IPv6-ers, bring your IPv6 capable devices and enjoy the "IPv6 is in the air" feeling during the RIPE64 meeting in Ljubljana. FYI: Nokia phones works, Android 4 phones usually works, etc... See you in less than two weeks, Jan Zorz, Go6.si

1 0

Re: [ipv6-wg] 2010 IPv4 (and IPv6) Address Use Report
by Silvia Hagen 27 Mar '12

27 Mar '12

Hi Iljitsch Are you updating these for 2011? Thanks Silvia Sunny Connection AG www.sunny.ch +41 (0)44 887 62 10 shagen(a)sunny.ch **************************************************** The new book "Planning for IPv6" has been published with O'Reilly in September 2011. **************************************************** Our website is dual-stack and can be accessed with IPv4 and IPv6 **************************************************** >>> Iljitsch van Beijnum<iljitsch(a)muada.com> 04.01.2011 12:30 >>> [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7-19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use <em>really</em> takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address <em>space</em> given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use.

2 1

RIPE-501bis: Some additional IPsec comments from Tero Kivinen
by Jan Zorz ＠ go6.si 21 Mar '12

21 Mar '12

Dear IPv6 WG... We received some additional comments from Tero Kivinen. Tero is one of THE experts in IPsec and a long-time implementer. He is part of IETF IPsec wg and a key contributor. As he's not on RIPE IPv6 WG mailinglist, I'm adding him to cc: and at the same time encouraging him to subscribe in order to follow and contribute to the discussion: http://www.ripe.net/mailman/listinfo/ipv6-wg So, his comments are listed below. We would like to "measure the heat" in working group and hear some comments, what you think should be implemented and what not. I explained, that we have certification/testing profiles (NIST, USGv6, IPv6 Ready, etc...) and we have RIPE-501 (soon replaced), that is procurement profile, intended solely as a help to procurement people (usually IPv6-clueless) to order equipment, that makes sense. Tero's comments: -------- In section IPsec: mandatory or optional, I would format the end as following: ---------------------------------------------------------------------- Organizations that use IPsec or expect to use it in the future should include the follwoing in the mandatory section when initiating the tender: * IPsec-v3 [RFC4301, RFC4303, RFC4302] * IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC4306 and RFC4718)] and if support for old IPsec is required add following: * IPsec-v2 [RFC2401, RFC2406, RFC2402] * IKE version 1 (IKEv1, ISAKMP) [RFC2407, RFC2408, RFC2409] ---------------------------------------------------------------------- I.e. prefer IKEv2, and move IKEv1 as separate case. Also note that IKEv1 is tied to IPsec-v2 and IKEv2 is tied to IPsec-v3 and you cannot really mix them that well. Note, also that RFC5996 obsoletged both RFC4306 and RFC4718. This same change should also be done for other places. Also I would rather use IKEv1 than ISAKMP for the old obsoleted key management protocol. ISAKMP is the name of framework on which the IKEv1 protocol is based on (and IKEv2 is also based mostly on the same framework, but everything from that framework document got incorporated to the IKEv2 RFC, so thats why it is not referenced anymore). It seems you do not have IPsec-v2 anywhere, even when you do have IKEv1. What is the reason behind that? IKEv1 works with IPsec-v2, and IPsec-v3 do require IKEv2, so am not sure why IKEv1 is included at all... There are multiple cases where you have "if xxx is requested the equipment must support yyy", where that yyy do require IPsec. Should those be spelled out too. For the Requirements for Mobile Devices the optional support list should probably include RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE), as it is something that is really useful in the mobile nodes. Requirements for Load Balancers: Now the mandatory support has only IKEv1 (ISAKMP), and no IPsec-v2/v3 at all. There isn't really that much that can be done using IKEv1 only. IKEv2 + RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) would make some sense even without IPsec-v3, but IKEv1 does not even have any such uses. The optional support list should probably have RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) and perhaps RFC6311 (Protocol Support for High Availability of IKEv2/IPsec). The optional list has IKEv1 (ISAKMP) again. ----------- (end of Tero's comments) I think we still are in review phase, so we can implement some changes. I hear that Last Call is planned for after RIPE64 meeting, so we still have time for last changes. As usual, comments and suggestions very warmly welcome. Cheers, Jan Zorz (writing for all co-authors) Go6 Institute Slovenia

3 4

New on RIPE Labs: Growth in IPv6 Capable Infrastructure
by Mirjam Kuehne 19 Mar '12

19 Mar '12

Dear colleagues, Please see this new article on RIPE Labs: "Growth in IPv6 Capable DNS Infrastructure: https://labs.ripe.net/Members/emileaben/growth-in-ipv6-capable-dns-infrastr… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: IPv6 Deployment: Trends and Tidbits of 4, 800 Dual-stack ASes
by Mirjam Kuehne 08 Mar '12

08 Mar '12

Dear colleagues, Please find a new article on RIPE Labs, contributed by Matthew Luckie, Amogh Dhamdhere and Brad Huffaker from CAIDA: "IPv6 Deployment: Trends and Tidbits of 4,800 Dual-stack ASes" https://labs.ripe.net/Members/mirjam/ipv6-deployment-trends-and-tidbits Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: ASes Announcing IPv6 - One Year Later
by Mirjam Kuehne 05 Mar '12

05 Mar '12

Dear colleagues, Please find a new article on RIPE Labs showing the percentage of ASes announcing IPv6: https://labs.ripe.net/Members/mirjam/networks-with-ipv6-one-year-later It is interesting to see what has changed since we presented this graph for the first time about one year ago. Kind regards, Mirjam Kuehne RIPE NCC

1 0

Call for agenda items for RIPE 64 in Ljubljana
by Marco Hogewoning 28 Feb '12

28 Feb '12

Dear colleagues, You guessed it, it is that time of the year again that we get busy to prepare for another RIPE Meeting., the 64th already. This one will take place from 16 till 20 April in Ljubljana, Slovenia. For this meeting we even have arranged for two sessions of the IPv6 Working Group. Both are scheduled on Thursday, starting after the coffee break at 11:00 and continuing after lunch until 15:30. This means we have a total of three hours to fill with topics you think are interesting when it comes to the adoption and deployment of IPv6. So please if you would like to share anything, wether it are thoughts about how to progress IPv6 deployment or showing your latest IPv6 project, please drop us a line at ipv6-wg-chairs (at) ripe (dot) net. Please include a short bio, a synopsis and if available a copy of the (draft) slides you intend to use. Hope to see you all in Ljubljana and of course if you can't make it the sessions will be broadcasted with the option of remote participation. Greetings, The IPv6 WG chairs collective, Marco, David and Shane

1 0

Policy proposal 2011-02: "Removal of Multihomed Requirement for IPv6 PI" Implemented
by Kjell Leknes 22 Feb '12

22 Feb '12

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2011-02, "Removal of Multihomed Requirement for IPv6 PI", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 PI assignments without multihoming being a requirement. The full proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2011-02 The revised version of the IPv6 policy was published on 23 January 2012: http://www.ripe.net/ripe/docs/ripe-545 The new request form template for IPv6 PI assignments can be found at: https://www.ripe.net/ripe/docs/ripe-546/ The new supporting notes can be found at: https://www.ripe.net/ripe/docs/ripe-547/ Kind regards --- Kjell Leknes RIPE NCC

1 0

RIPE-501 replacement draft, version 7
by Jan Zorz ＠ go6.si 15 Feb '12

15 Feb '12

Fellow IPv6 working group... It is time to put out another version of RIPE-501 replacement draft document, and this time we are aiming for Last Call, if WG chairs decides so. We've been babysitting this doc for quite some time now, and many of latest changes and modifications are described in this post: http://go6.si/en/2012/02/ripe-501-replacement-ready/ Doc itself can be found in .pdf on http://go6.si/ripe501bis/ , find 7th revision (the last one). We'll also ask RIPE-NCC staff (Chris, actually) to HTML-ify it and put into documents store as a draft. It's time for 501 replacement. There is a long list of entities, that are waiting for this to move forward. We'll start collecting more suggestions and ideas for new work shortly, but I think the authors team needs some time off now ;) So, if chairs agree, let's try and ask, if there is consensus to move this draft in BCP status. Merike, Sander and Jan, authors

1 0

Fwd: RA-Guard: Advice on the implementation (feedback requested)
by Fernando Gont 02 Feb '12

02 Feb '12

Folks, You've proabably read about this a few times -- still, most implementations remain broken. If you care to get this fixed, please provide feedback about this I-D on the IETF *v6ops* mailing-list <v6ops(a)ietf.org>, and CC me if possible. Thanks! Best regards, Fernando -------- Original Message -------- Subject: RA-Guard: Advice on the implementation (feedback requested) Date: Wed, 01 Feb 2012 21:44:29 -0300 From: Fernando Gont <fgont(a)si6networks.com> Organization: SI6 Networks To: IPv6 Operations <v6ops(a)ietf.org> Folks, We have just published a revision of our I-D "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" <http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>. In essence, this is the problem statement, and what this I-D is about: * RA-Guard is essential to have feature parity with IPv4. * Most (all?) existing RA-Guard implementations can be trivially evaded: if the attacker includes extension headers in his packets, the RA-Guard devices fail to identify the Router Advertisement messages. -- For instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>) contains tools that can evade RA-Guard as indicated. * The I-D discusses this problem, and provides advice on how to implement RA-Guard, such that the aforementioned vulnerabilities are eliminated, we have an effective RA-Guard device, and hence feature-parity with IPv4. We'd like feedback on this I-D, including high-level comments on whether you support the proposal in this I-D. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Draft minutes of RIPE63
by Marco Hogewoning 31 Jan '12

31 Jan '12

Dear colleagues, Attached are the draft minutes of our working group session in Vienna at the RIPE63 Meeting. Please review them and if you have any corrections or comments, please post them to this list before Friday the 27th of January COB. If we haven't received any comments or corrections by that date, we will assume consensus and will ask the RIPE NCC to publish these as final. Again many thanks to the RIPE NCC for their support in scribing the session. Marco Hogewoning RIPE 63 Scribe: Mirjam Kuehne WG chairs: David Kessens, Shane Kerr, Marco Hogewoning Date: 1 November 2011, 16:00 - 17:30 IPv6 WG meeting (first session) Marco Hogewoning opens the IPv6-WG 1. Administrivia: - Minutes of RIPE 61 have been circulated - There was no IPv6-WG session at RIPE 62 - Thanks to the RIPE NCC for taking minutes at RIPE 63 2. Renumbering IPv6 - IETF 6RENUM WG (Tim Chown, Wes George; presented by Shane Kerr) The Address Policy WG asked the IPv6-WG for some advice about renumbering. Trying to avoid renumbering could be a reason for organisations to request PI space. Renumbering is considered to be difficult. But if renumbering would be very easy, then this wouldn't be a good reason for PI space (there might be others however). The IETF 6RENUM WG is working on this topic. It was formed after a BoF at IETF 81. There was some previous work done on IPv6 renumbering (see RFC 4192, RFC 5887 and draft-chown-v6ops-renumber-thinkabout-05). The current work of the 6RENUM WG is focused on renumbering for enterprise networks, not ISP networks. But enterprises all get their Internet connectivity from somewhere - from ISPs. Many of them are in the RIPE community. Tim Chown is looking for feedback from this community. The first 6RENUM WG draft documents internal triggers to renumber. There is also a document providing a gap analysis. Q&A: James Blessing commented that IF you design your network properly in the first place, renumbering is fairly straightforward - it is still work, but it's straightforward. Marco was wondering if it would help if this group would come up with a BCP about network design. Shane thought this would be a good idea (people usually appreciate RIPE BCPs). Gert Doering (Spacenet and IPv6 user for many years) agreed with James: A large part of the pain can be avoided with a good network design. Don't hardcode IP addresses etc. A BCP document listing the dos and don'ts would be useful. On the other hand, we don't want to overlap with the IETF WG (would have to check that this is not part of their charter). Marco emphasised that the IETF 6RENUM WG is mostly focused on enterprise networks. He suggested that the RIPE IPv6-WG could fill the gap and provide some documentation for ISPs. Gert said he obviously thought about this also, because it is related to address policy. Gert said he spent some thought on that as well, because obviously touches on Address Policy. Like I if he’s a small ISP and not multi‑homed yet but wants independent addresses and why not just renumber if you change upstream and? One of the really painful things about renumbering an ISP network is you have to renumber your customers and that works for end users that are fully automated provisioned, like prefix delegation and stuff so there is no boxes to be touched and the box auto configures everything on connection anyway but it doesn't work at all for business ISPs where you have many configured firewalls and everything, so renumbering an ISP with business customers is nearly impossible. Gert said he’s done it two times and that it's nearly impossible. So this might be the reason why they have excluded ISPs from this scope. On the other hand, some parts of the ISPs are just an enterprise network, like server housing, DNS servers, firewalls and stuff, so there is overlap again. Shane said there was a couple of different things going on, one being able to provide recommendations to people who are doing network design, maybe even in the case where you have customers perhaps recommending prefix delegation or whatever. But the other issue is the recommendations on the policy space, maybe clarifying in which cases PI space makes sense, for instance a small ISP with downstream customers or something like that. Gert said that better defining the problem space, would certainly help making appropriate policy. Documenting different use cases could be helpful. James commented that according to current policy, having PI IPv6 address space stops you from giving addresses to customers. Gert said that this is correct and that it's an artefact of the history of PI address space policy. This will be discussed more in the Address Policy WG. Maksym Tulyuk (AMS-IX) reported that at AMS-IX they renumbered from PI to PA IPv6 space and that this was not a big problem. Marco clarified that this was a migration of a service network, not a customer network. Benedikt Stockebrand said that when it comes to renumbering, the biggest problem is all the legacy equipment and configurations. You need to figure out first what the network is supposed to be doing before you renumber it. Shane asked the audience if IPv6 provides any benefits at all when it comes to renumbering? Benedikt said it is important that people realise how to pay for this in the long run. Aaron Hughes (6connect) reported that in the ARIN region, a best current operational practices track was started. The first document described subnetting IPv6 for ISPs. We also said that they'd be happy to work on documentation for enterprises as well. These topics are discussed on the following mailing list: bcp-discuss at bind.com <mailto:bcp-discuss at bind.com > Aaron said he’d send more information to the RIPE IPv6-WG mailing list. Jan Zorz wondered why the IETF created the 6RENUM WG. Shane responded that it might be a little early to present their work since the WG has just started. Gert responded to Shane's earlier question that renumbering in IPv6 is easier, because all stacks know how to handle multiple addresses at the same time. But from a planning point of view, it is the same. ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. 3. Replacing ripe-501 (Jan Zorz, Sander Steffann) See "Requirements for IPv6 in ICT Equipment": http://www.ripe.net/ripe/docs/ripe-501 ripe-501 was published a year ago and has already been translated into ten languages.Since then many requests for changes were received. The document was a great success, but of course things can always be improved. New devices were added to the document. Specifications about load balancers were added. The compliance criteria were also simplified. There was a good discussion on the mailing list. The document is currently in last call. Note that the document is meant as a template, don't just cut and paste bits and pieces. Jan and Sander thanked Merike Kaeo for providing a lot of useful input. Randy Bush (IIJ) had a question about the CPE diagram in the document. Jan explained that the RFC written by Ole Troan was included as a mandatory requirement. The idea was not to duplicate Ole's work. If a CPE does not support this RFC, it should not be taken into account in the process. Sander asked people to send comments to the mailing lists to specify if this comment should be included right now (which means extending the last call) or if it is OK to include it in the next version. The Last Call for the current version of the document ends next week, 10 November 2011. Tahar Schaa (consultant supporting German government) asked what their plans were to include source address validation improvements. Sander confirmed that it would be included in the document. But it is up to the tender initiator to ask for this requirement or not. 4. Horses for courses - like IPv6 profiles for German Administration (Constanze Buerger, Bundesministerium des Inneren, Germany) The prepsentation is available at: http://ripe63.ripe.net/presentations/74-2011_RIPE_63_de.government_Constanz… Maksym asked if the files Constanze mentioned in her presentation are publicly available. Constance said this has not yet been decided. Alexander Isavnin from Russia wondered how much this process is costing the German taxpayers? Constance responded that they are just coordinating the IPv6 address space allocated to them and the deployment to all federal governments and institutions. But it will take a long time until this is finished. Alexander asked if each department has its own budget. Constance confirmed that this is the case. She also explained that it is not so easy to convince people to cooperate. Every municipality can do their own thing. That means she and her team have to do a lot of convincing, but they cannot force the others to cooperate. Jan Zorz thanked Constanze for considering ripe-501 as a basis for her work and mentioned that there will be a new version (and a new number). He asked that Constanze and Tahar make their own adjustments in their documentation when the new version comes out. Tahar clarified that ripe-501 goes into the same direction as their work is going already anyway. So yes, a few adjustments will have to be made, but it's not that difficult, because they are aware of the changes. Jan asked if Constanze or Tahar are aware of any other governments following the German example. Tahar said he believed that Spain is following a similar process. Martin Levy (Hurricane Electric) thought it would be better to rephrase the earlier question: “What would this cost if you were to ignore IPv6?”. Constance explained that they tried to analyse the costs so that they can put some pressure on the leadership. But it turned out to be very difficult, because the government and the network is so heterogeneous. In the end they had to stop the process analysing the costs. Tahar added that Germany, due to its constitution, is a complex country. The costs are held and managed in each state and each municipality. All that can be done really is to provide the first steps and some supporting documentation. He saw two main motivations to deploy IPv6: 1. Address renumbering (there is a long history of using IPv4 address, mostly private, which means that there is now a horrible network of cascading NAT layers. Some of the networks have been renumbered up to four times and this is very costly. Deploying IPv6 will solve these problems. 2. If one wants to set up a telephone infrastructure in Germany today, it is only possible to buy VoIP telephony. What about one office wants to call another and the addresses clash? You can better start using public (IPv6) addresses. In conclusion, the question is not: What does it cost to do it, but what does it cost not to do it? Constance said yes, just do it. 4. Status of ADSL Deployment in the XS4All network (Timo Hilbrink, XS4All) The presentation is available at: http://ripe63.ripe.net/presentations/75-th-ipv6-ripe63-20111101.pdf Maksym asked why the MTU on one of the slides was set to 1452, why it was so low and whether it was part of his implementation. Timo said yes. Gert applaud Timo and XS4All on this. He said it was great to see one mass-market provider go forward with this. He said he hopes that there will also be more users in Germany any time soon. Andy Davidson (Hurricane Electric) asked if Timo knew the retail prices of the new CPEs that include IPv6. Timo said they were around EUR 100. Andy concluded that that price is coming down all the time, which is great. 5. Lightning Talks 5.1. Results of the 2011 Global IPv6 Deployment Monitoring Survey (Chris Buckridge for Maarten Botemann) The presentation is available at: http://ripe63.ripe.net/presentations/114-ipv6-survey-BUCKRIDGE.pdf 5.2. Effects of Capacity Building on IPv6 Adoption and Deployment (Marco Hogewoning, RIPE NCC) The presentation is available at: http://ripe63.ripe.net/presentations/66-MH-RIPE63-Capacity-LT.pdf 5.3. Stateless IPv4 over IPv6 in 5 minutes (Ole Troan, Cisco) The presentation is available at: http://ripe63.ripe.net/presentations/40-RIPE63-MAP-lightning.pdf Jan, as a member of the MAP (A+P) architecture team, asked attendees if they felt that well-known ports must never be allocated to a user or if the user should have the opportunity to use well-known ports. Ole responded that you could give users that are not happy with the default setting a full IPv4 address. Benedikt explained that users shouldn't need low ports. He wondered if prolonging IPv4 is really worth the effort. The majority of people don't want to run a server at home. For those who want to, they will switch to IPv6 shortly. Those who use an IPv4 server at home will get some IPv4 addresses from somewhere. It's not something you want to provision for mass customer products. Jan said he believed stateless A+P is worthwhile because we don't want CGNs. Benedikt disagreed and said he wants CGN and wants it to hurt that much that people will use native IPv6 in the end. Jari Arkko (Eriksson) pointed out that there are trade-offs: If you are doing port division per customer on an static basis for customers, the power user and a small user get the same service, which neither of them will be happy with; we will pay in any case. 6. IANA Reserved IPv4 prefixes for shared CGN space (David Kessens) The presentation is available at: http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedad… < http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedad… > Gert wondered which address space they were going to use. David agreed that this is of course an issue. However, since this proposal was well received in the ARIN region, it was suggested to use a /10 out of ARINs' address space. Jari reported that he was one of the IESG members who reviewed this document and said he had a couple of concerns. Apart from the policy issues that are down to the RIR communities to decide, there are some issues with this particular proposal. What's the affect on the ISP ("My device works well now, but does it have negative affects on other parts of the network?"). He urged people to participate in this discussion and check if this would break anything. Kurtis Lindquist commented that this whole process seemed a little weird (between one RIR and the IAB and the IESG). Martin Levy said it is interesting that they were talking about IPv4 and CGNs a lot instead of about IPv6. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list. 7. IPv6 Speed Dating Marco asked the audience how many people in the room have deployed IPv6 (about half of the room). The other half is busy deploying it. He further asked those who are busy deploying it, what the biggest challenge is they face in the process? A speaker from the audience said that the biggest challenge is to convince the management. The management thinks it is too expensive. Marco asked those who deployed IPv6 how they passed that hurdle. Andy said to just do it anyways. Jan Zorz responded that he gave a 45 minute presentation earlier explaining how to convince the management. Benedikt suggested to ask the management: "What's the business case of an earth quake?" The same applies to IPv6: by trying to safe money, you might lose customers and money in the end. Timo suggested to explain to the management what they would lose if they didn't do it. Jen Linkova (Google) explained that from an operational perspective they are still discovering bugs now and that they have to test almost everything again for IPv6. Therefore her advice is to test everything twice from the start, don't expect things to works out of the box. Marco pointed out that this community and especially this IPv6 WG is a great pool of resources on IPv6 deployment. Dave Wilson (HEAnet) responded to the question of what problem he had to solve and how he convinced his boss. He said he solved this in his case by providing a business case. But that might be different in other environments. A speaker from the audience said that after convincing your boss, the main problem is organisational: all departments in your company (networks, IT, service, marketing etc.) have to work together. That is not always easy. Andy added to his earlier comment that even if people don't have official mandate, he would advise them to skill-up anyways, so they can be prepared for the deployment phase. The working group co-chairs thanked attendees and closed the session. Summary of Action Points – IPv6 WG RIPE 63 ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list.

1 1

RIPE-501 replacement document - IPsec question to community - we need your input.
by Jan Zorz ＠ go6.si 27 Jan '12

27 Jan '12

Dear IPv6 community. (copy/paste from our internal discussion) The authors of RIPE-501 are finalizing the last comments from previous last call and would like community input for what to do with IPsec. All authors feel that IPsec should be a mandatory requirement for all devices although due to technical limitations, for mobile devices it will be optional. We are aware that RFC6434 made IPsec support a SHOULD rather than a MUST. From RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. The change was largely due to limitations found in low power devices and therefore we still feel the community is best served by requiring mandatory IPsec support in all other devices (hosts, routers or layer-3 switches, network security devices, load balancers) If we get this input from you this year, there is a great chance that we could put out the new/final draft out for discussion and/or maybe last-last-call before new year. For RIPE-501 authors group, Jan P.S: wishing happy new year, merry xmass, happiness, IPv6 and all that stuff in at least next year :)

16 35

More IPv6 on mobile networks testing...
by Jan Zorz ＠ go6.si 18 Jan '12

18 Jan '12

Hi, I suspect some of you could find this interesting. Excuse to others for filling their mailboxes ;) http://go6.si/en/2012/01/nokia-usb-modem-21m02-ii/ Nokia USB "Internet stick" with PDPv4, PDPv6 and PDPv4v6 capability test. Cheers, Jan

3 2

IPv6 Launch Day
by Marco Hogewoning 17 Jan '12

17 Jan '12

The follow up on World IPv6 Day has just been announced. Marco http://www.worldipv6launch.org/press/20120117-2/ World IPv6 Launch Solidifies Global Support for New Internet Protocol Top websites, Internet service providers, and home networking equipment manufacturers commit to largest transition in the Internet’s history [Washington, D.C., USA and Geneva, Switzerland] – 17 January 2012 – Major Internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012. Organized by the Internet Society, and building on the successful one-day World IPv6 Day event held on 8 June 2011, World IPv6 Launch represents a major milestone in the global deployment of IPv6. As the successor to the current Internet Protocol, IPv4, IPv6 is critical to the Internet’s continued growth as a platform for innovation and economic development. “The fact that leading companies across several industries are making significant commitments to participate in World IPv6 Launch is yet another indication that IPv6 is no longer a lab experiment; it’s here and is an important next step in the Internet’s evolution,” commented Leslie Daigle, the Internet Society’s Chief Internet Technology Officer. “And, as there are more IPv6 services, it becomes increasingly important for companies to accelerate their own deployment plans.” ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: ● AT&T ● Comcast ● Free Telecom ● Internode ● KDDI ● Time Warner Cable ● XS4ALL Participating home networking equipment manufacturers will enable IPv6 by default through the range of their home router products by 6 June 2012. Committed equipment manufacturers are: ● Cisco ● D-Link Web companies participating in World IPv6 Launch will enable IPv6 on their main websites permanently beginning 6 June 2012. Inaugural participants are: ● Facebook (www.facebook.com) ● Google (www.google.com) ● Microsoft Bing (www.bing.com) ● Yahoo! (www.yahoo.com) Content delivery network providers Akamai and Limelight will be enabling their customers to join this list of participating websites by enabling IPv6 throughout their infrastructure. As IPv4 addresses become increasingly scarce, every segment of the industry must act quickly to accelerate full IPv6 adoption or risk increased costs and limited functionality online for Internet users everywhere. World IPv6 Launch participants are leading the way in this effort. For more information about World IPv6 Launch, products, and services covered, as well as links to useful information for users and information about how other companies may participate, visit: http://www.worldipv6launch.org About the need for IPv6 IPv4 has approximately four billion IP addresses (the sequence of numbers assigned to each Internet-connected device). The explosion in the number of people, devices, and web services on the Internet means that IPv4 is running out of space. IPv6, the next-generation Internet protocol which provides more than 340 trillion, trillion, trillion addresses, will connect the billions of people not connected today and will help ensure the Internet can continue its current growth rate indefinitely. About the Internet Society The Internet Society is the world’s trusted independent source of leadership for Internet policy, technology standards and future development. Based on its principled vision and substantial technological foundation, the Internet Society works with its members and Chapters around the world to promote the continued evolution and growth of the open Internet through dialog among companies, governments, and other organizations around the world. For more information, see: www.internetsociety.org Akamai Technologies, Inc. Jeff Young AT&T Jenny Bridges Cisco Marc Musgrove Comcast Jorge Alberni D-Link Denise Keddy Facebook Nisha Gulati Google Inc. Internet Society Wende Cover Internode John Harris Limelight Networks Microsoft Bing Bill Hankes Time Warner Cable Justin Venech Yahoo! Christina Scharrenberg

1 0

v6 World Connectivity To v4 World
by Matthew Walster 14 Jan '12

14 Jan '12

Apologies if this would be more suitable for IETF v6ops rather than IPv6-WG, I'm not overly familiar with the v6 development community. As is painfully apparent, most of the world if v4 only at the moment - and the various DNS ALGs etc for getting v4 connectivity onto v6 only connections seem "hackish" at best, and have real problems when it comes to things such as 1500-byte v4 packets needing fragmenting to travel over v6 nets. While playing with my local ssh daemon, I was reminded that inside my ssh client is a SOCKS5 server - I can connect to it by just setting my global SOCKS setting to use the localhost and all the traffic is forwarded down the tunnel to the remote host for processing. I was wondering whether anyone had any experience in setting a SOCKS proxy on a v6-only host, where the DNS/SOCKS proxies have both v4 and v6 addressing, and whether they can then access v4 services like web sites, mail servers, gaming applications etc. The basic idea is that you would use the v6 internet where possible, and go through your ISPs v4 SOCKS gateway for anything that didn't return a AAAA record. Is that idea right, and if so, is it sustainable? Assuming for the moment that I've made a correct assumption, is there a way we can make the process easier? Back in v4 world, there's DHCP option 252 which allows you to configure a WPAD file that would be downloaded and parsed by your web browser, setting HTTP proxies etc for certain classes of service - non-local traffic etc. Is it feasible to add an option to DHCPv6 so that a "v4 compatibility" string could be set, whereby a fall-back SOCKS server is used for non-v6 connections? Thinking off the top of my head, it would work as follows for the "no-clue" home user: User's router talks to ISP via DHCPv6: gets response detailing address to use also gets prefix delegation for local LAN usage also gets v4 compatibility string, which it stores for relaying to clients User's router listens for DHCPv6 requests, issues clients on local LAN public v6 addresses: sets option for v4-compatibility for clients User's computer turns on, asks for addressing information: gets v6 address via DHCPv6 gets v4-compatibility string and sets global SOCKS proxy variable, if not manually configured gets other string - DNS servers, routes etc. I stress that this idea is for v6/v4 co-existence, and isn't designed for "islands of v4" or "islands of v6", it would of course assume that v4 availability is restricted and a real effort to move to v6 was made. It's a transition mechanism that should be easy to turn off once most of the services have been migrated (hopefully transparently to the end customer). If there is a major flaw in my idea, I'd greatly appreciate constructive criticism and feedback! Matthew Walster

1 0

Latest 6::gle phone Nexus supports IPv6 on 3G
by Jan Zorz ＠ go6.si 02 Jan '12

02 Jan '12

All good in new year, the year of IPv6 :) In Go6Lab we tested new 6::gle phone with Android 4 and good news is, that it supports IPv6 PDP context over 3G. With Cameron from T-Mobile USA we are compiling list of apps, that are not working in IPv6-only environment, but for now we can live with it in everyday life :) The list will be published and compiled later. Short first report with snapshots: http://go6.si/en/2011/12/samsung-galaxy-nexus-nov-google-phone-podpira-tudi… Good news for start of new year. Cheers, Jan Zorz Go6 Institute Slovenia, CEO

1 0

Usenix: Google deploys IPv6 for internal network
by Carsten Schiefner 19 Dec '11

19 Dec '11

Dear all - maybe this: https://www.networkworld.com/news/2011/120911-usenix-google-deploys-ipv6-fo… is an interesting read-up for at least some of you... Best, -C.

2 2