- ipv6-wg - mailman.ripe.net

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