Archives

These are unedited transcripts and may contain errors.

IPv6 session at 4 p.m. on 1st November, 2011:

MARCO HOGEWONING: We are good to go. Welcome to the IPv6 Working Group. This is the IPv6 Working Group, if you are looking for antiabuse, that is starting next door. This is the next slide. As it said on the programme, it goes until 5:30. We are actually scheduled to go to 6 o'clock but the programme said 5:30 for aesthetic reasons, we tried to change it but it looked ugly. The session is broadcast, if you wish to make a comment use one of the microphones and state your name and afill nation so people remotely can hear what you have to say and who you are.

Please switch off all electronic devices. As far as the administrative matters goes, the minutes of RIPE 61 have been cycled to the mailing list and have been approved and as you have noticed, there was no session on RIPE 62 so there are no minutes to be approved for that secretaries. And for this session, scribes and remote participation monitoring is supplied by the RIPE NCC, Miriam, to be precise. We have got quite a full programme. We start off with a bit of discussion on renumbering, we have got Jan to introduce the document, we have a presentation from Constanze from the German government what they are doing with IPv6 and as mentioned in the previous session, they are quite ahead with IPv6 deployment so Tim is going to show what is happening there. And later on, we decided to put in some lightning talks so we are examining to do some short presentations on IPv6 monitoring deployment survey, some statistics we ran at the RIPE NCC and talk about softwares and IPv6 over IPv4.

David got something about stuff happening in the IETF regarding shared address space for CGNs and as a closing thing we have got new experiment and that is IPv6 speed date what I will explain later on.

With that, time for our first speaker so I am going to hand Shane the mic. I forgot to introduce our cochairs. I am Marco, this is Shane and David and us three are the chairs of the IPv6 Working Group.

SHANE KERR: Thank you Marco. So does the speed dating have anything to do with the beauty contest or is it unrelated? It might. OK, cool.

So, most of this talk is actually me proxying someone  one who is unable to join us today. We are doing little slide. By way of introduction, while we are talking about renumbering, the Address Policy Working Group wants some advice from the IPv6 Working Group, and the reason for this is that renumbering has policy implications. If it's difficult for people to renumber their networks, then basically, that is a justification for wanting PI space. So, if, however, it's very, very easy or even trivial to renumber your networks, then there may be other motivations for wanting provider independent space but that is not the one. But in order to properly inform that debate and that discussion we need to know what the status of renumbering is.

So we are going to talk about it the v6 context here because we don't care about v4.

So, what is this presentation? Well, the IETF, which is the body that makes all the Internet standards, well most of them, recently formed a Working Group to look at the problem space of v6 renumbering so I think it's the chair of the Working Group was going to come here and present that but he was unable to make it so he sent some slides which go over the developments in that area. I am going to go through those and then we can have a discussion afterwards, I think we will have a little time of bit for that. My cochairs will tell me if we don't. So that is the basic idea.

So, enterprise site renumbering and these slides are by Tim Chown, I am just proxying this, as I said.

So, not too surprising here, renumbering is considered difficult. There is a lot of work that has to be done, most of it manual, in some environments, and as I mentioned in the introduction, this is one of the justifications for getting provider independent space. It mentions that there are other reasons you will have to renumber even if do you have PI space, yes, if you corporate mergers things like that, you are never going to be totally free of that burden. And so he talks about the formation of the Working Group. The way things work in the IETF is if someone has interest in developing standards or technology and anything like that, they meet what is called the BoF, we have them here and if there is sufficient interest in that charter for the Working Group and the work gets started in official Working Group, and in principle, in the IETF Working Groups have a beginning and end so the idea of this work is to produce a set of standards and technologies and documents explaining things and then close down the Working Group with it all being solved. So you can see the slides here, the title is focused charter and they had their first meeting recently.

So background, previous work that was done in this: We have lost our slide here. Well, there was a slide, an RFC on how to renumber IPv6 without a flag day. It's basically having multiple addresses in your network and so on so you don't have to do anything funky and turn things off and restart them. More recently, there was a document called renumbering still needs work and there was a document produced in 1996 called renumbering needs work. So this document is from I think last year or the year before, which they did an analysis of the stateoftheart now, 15 years later, and it turned out that renumbering is still nontrivial, but it's come along ways. At that time, DHCP wasn't widely adopted and things like that, there was no widespread stateless auto configuration. This is a draft here. You can see just the name of it, not the whole thing. This is actually by Tim, talking about a lot of the issues as well. I think there is another thing of previous work here but we can't see it so I am going to skip it here.

So, based on this problem statement, this discussion, what the issues were, the IETF agreed to create a charter, a new Working Group, and it's focused on the enterprise, so the problem space is not ISPs, which may limit the  which may seem to limit the interest for this group, I don't know how many people here represent enterprises V ISPs, I suspect more of you are involved with networking so it's really ISP space. The 6 renumber doesn't look at the cohoe problem and there is a separate Working Group in the IETF which is working on home Gateway equipment, which may also be interested in that area, but it's not the exactsame problem. So, that is the focus of it. As it says here, excluded were charter v4, v6 SoHo and ISPs.

So this is the first draft. Talking about this, it documents triggers for renumbering, internal and external, and having PI doesn't help you for internal triggers, and it talks  goes to the different perspective in ways that the renumbering problems could be simplified. There is also a gap analysis text this. Goes through a lot of different things. You see the list here, protocols, policies and procedures, management tools and renumbering event management. As it talks about there, this is the gap analysis, so it starts to be an honest assessment of the situation even if there is no obvious solutions to these problems today. The idea is to at least document them and solve what seems solvable. The IETF tries to be an engineering group so researches is mostly excluded, so that is the idea here.

So, Tim wanted to come here and talk the RIPE community, v6 guys, about this issue. As I mentioned earlier, the 6RENUM is focused on enterprises, but enterprises all got their Internet connectivity some where so a lot of enterprises get PI space, you need to go to an LIR to get that so they still have some interaction with the community. All have a relation with their ISP. So the questions Tim wanted to ask are, what are your recommendations as far as renumbering, what are the key issues and would you rather try to avoid renumbering. That is the last slide.

So, that is kind of the background.

Marco reminded me yesterday that we have actually had a presentation given by someone who did relatively large renumbering, showing that it's possible. It's not impossible and in fact, it's not even very hard; it's just work.

So, I guess maybe a question. We have someone at the microphone.

AUDIENCE SPEAKER: James Blessing from Limelight Networks. I might have been the person who got up and did the presentation. As a whole, it's not a problem if, and the big if, is if you designed your network and your numbering in the right way in the first place, so if you design it right the first place, renumbering it is fairly straightforward. It's work but it's straightforward work.

SHANE KERR: Right.

MARCO HOGEWONING: That is quite interesting because, actually, the topic at hand, yes, what we as a Working Group should do with that, and as James is commenting, like design, so would that be a way forward if what does the group think, what I am trying to  would it help if, for instance, this group came up with some BGP or design guidelines that actually enable people to renumber?

SHANE KERR: I think historically, people really love RIPE recommendations, these documents. Gert is going to the microphone. It's partially your fault that we are here, right?

GERT DORING: No, it's not my fault, it's Marco's fault.

MARCO HOGEWONING: Blame me.

GERT DORING: IPv6 user since a while. I think I want to agree with James Blessing about large parts of the pain can be avoided if you do proper preplanning, like don't hard code IP addresses into software and use DNS which, for some reason, seems to be not very much in favour in enterprise networks. They really love hard coded IP addresses.

So, best practice document that tells people not to make the mistakes right from the start, that would then make renumbering really painful, might be a good thing. Now, I haven't read the IETF documents so what we shouldn't do is duplicate the work the IETF group is doing already, but there might be some benefit in doing this in the group here.

MARCO HOGEWONING: One of the interesting points, there is  the IETF charter of 6 renumber excludes ISPs and it's in the topics, that is actually the question to the crowd I think, is should we, as an IPv6 Working Group, fill that gap and see if we can do something that focuses more than the ISPs?

GERT DORING: I have spent some thought on that as well, because obviously touches on Address Policy. Like I if I am small ISP and not multihomed yet but I want independent addresses and why not just renumber if you change upstream and? One of the really panful 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. I have done it two time, I know 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 KERR: Well, so I think there is a couple of different things here: One is 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 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 DORING: Sort of well defining or better defining the problem space would certainly help the policy side of things. If we can tell people the experts have said this is not so hard, please go for PI space from your provider or, on the other side, if we have sort of on record that yes, if you have a network that looks like this, you really don't want to renumber that. It makes it easier to actually justify PI there. Or justify  independent block, whatever it's called.

James Blessing: A specific comment on this point: PI space in the v6 world specifically stops you giving it to customers as it stands, I believe. Ways completely separate argument, I was just going to point it out at this point.

GERT DORING: Well, there will be more on that in the Address Policy Working Group, and that is one of the artifacts we have out of the history of the PI policy development.

SHANE KERR: I don't know who was next, actually.

AUDIENCE SPEAKER: Max Amsterdam IX. In Amsterdam IX I did my Graham from IPv6 PI to IPv6 PA  no, from we had two IPv6 bay blocks and migrated to one IPv6 PI blocks, yes. And from my point, there was no  nothing specific, so it was like normal migration from one IP address to another IP address, just from operation point of view. So everything was  if you do any IP for migration it will be the same or quite similar.

MARCO HOGEWONING: You are talking about migration of the serve network not peering one.

AUDIENCE SPEAKER: Yes, it was for other Internet  network. It wasn't peering network.

SHANE KERR: So that is actually possibly similar to the enterprise environment that they are looking at in 6RENUM.

AUDIENCE SPEAKER: I think so.

MARCO HOGEWONING: People standing at the microphone are welcome to place their comments.

AUDIENCE SPEAKER: Ben /TKEURBGTS freelance IPv6 guy for a couple of years now. From what I have seen when it comes to renumbering, the biggest problem is really not IPv6  if you have reasonably  if you know what your network looks like, it's a bit of work but you can get it sorted out beforehand, which is the problem, really; you need to know in your network, so the big problem is you have all the crowd collected in the last ten years or so, which is really causing the pain. Once  so the most important thing about this, really, from an enterprise network, is that you have to figure out what your network is actually doing and have the people who can sort it out. That makes it difficult to figure out how much of an effort it is and that makes it especially painful for the ISPs who have customers like that, so that is really the problem. Otherwise, you can do it by textbook, if you know your network, it's fairly simple or straightforward exercise, but that doesn't really always meet the situation in the real world.

SHANE KERR: So a question is, does IPv6 provide any benefit at all in terms of renumbering?

AUDIENCE SPEAKER: Well, OK. Some people will hate me for this, for people who renumber every four weeks, they will make a habit out of it and it will be quite easy.

SHANE KERR: Is that a policy proposal?

AUDIENCE SPEAKER: No. But it's just a different way of thinking at these things. No it isn't, but we should actually  we should, somehow, make people realise that how to peer for this in the long run, what information do they need and how do they keep it. That is probably the 

SHANE KERR: That sounds like work for this group, then, yes.

AUDIENCE SPEAKER: This is ARIN Hughes from 6 connect. I just wanted to mention an effort that we recently started in the ARIN region and while it is not specific to the ARIN region we simply started there, which was best current operational practices track that builds living documents somewhat like PCPs only current. Our first document that we realised was sub netting IPv6 for ISPs and happy to work on something for enterprises as well. There are about 200 people on the list so far and it is pretty well discussed topic. I think it might be pertinent and help solve some of these problems by getting a document out like that. It currently lives in a temporary place so the list is BCPdiscuss at bind dot com, we have a park domain which we should have launched in the next week or so. And I think this is probably a good place for these kind of documents.

MARCO HOGEWONING: Can you do a favour and send these addresses and some information to the Working Group list as well?

AUDIENCE SPEAKER: Absolutely.

JAN ZORZ: From Slovenia. I am not sure that everybody in this room, including me, actually really understands what this Working Group is all about and what they want to achieve.

SHANE KERR: Do you have question?

Why creating a Working Group about renumbering?

SHANE KERR: On the IETF side?

JAN ZORZ: Yes.

SHANE KERR: If you read the gap analysis documents there are spaces  I think the idea is there is an opportunity to provide technology to make it easier. I mean, my personal opinion is that it's actually a bit early to introduce this work to this group because there is not really anything there yet. There is no technology to get your hands on. Of course, if you have interest, I think it's worthwhile joining the 6RENUM discussion at the IETF but right now, it's really I find quite abstract and there is nothing new been added yet that is of value to operators.

GERT DORING: On the question on whether renumbering v6 is easier than in v4, it is in certain parts all the stacks now thousand handle multiIP addresses at the same time so that bit is easier and that is what the document from Tim about renumbering is basically about, introduce new prefix, change all the references then remove the old prefix so you don't have to do it all in once. That bit is easier. The other bits, like having references hard coded IP addresses DNS on zones that you have no access to, that is not  the poor planning bit is the same.

SHANE KERR: OK. Thank you.

MARCO HOGEWONING: Where are we going to take this from here, is, I think the final question, from the audience?

SHANE KERR: I guess what we should probably do is send a teaser mail to the Working Group list, basically asking for volunteers to figure out what work, if any, we want to do in this area, I mean given there is already work being done in another community maybe we can just point to that.

MARCO HOGEWONING: Sounds like a plan.

SHANE KERR: Thank you, everyone.

(Applause)

MARCO HOGEWONING: Next presenter will be Jan and Sander. We are going to get a dual presentation there on the work that has been going on on the followon document for RIPE 501 which is currently a last call in this group.

JAN ZORZ: From Go6 institute Slovenia. We have been with this RIPE 501 document here for a long time and in  this was one year process to get a new version. I have been told that I need to be very quick, so and I can't speak for more than two anyone's a row I will three of to Sander to say the new staff.

So for people in the room that don't know what RIPE 501 document it, it is a procurement document that covers the IPv6 requirements when we are buying equipment in tender, in a public tender or wherever else. So in RIPE 501 we covered hosts and consumer grade layer 2 switches and enterprise service provider two layer switches and firewalls, intrusion detection systems and requirements for system integrateers. What they immediate to know, how much experience they need to have and actually there, we even included a declaration like that system integrator needs to sign, that under criminal and material responsibility, they declare they know how to deploy IPv6 and this helped, I can speak for my country, a lot in raising the knowledge of IPv6 in our system integrators.

So, RIPE 501, there were three ways to comply: First option was long list of RFCs and we had IPv6 ready logo certification option or mix of those two options, that means that equipment, if equipment was put under IPv6 ready logo certification, that, then, it complies, or else then they need to comply to the long list of mandatory and optional RFCs and I will leave to sand tore do the improvement part that we were  that we put lots of effort in the last year.

SANDER STEFFANN: So, RIPE 501 was a great success. We had lots of good responses but of course, things can always be improved. So, we added some extra devices, CPEs and load balancers to the document and we added specification for what a mobile node should support. Apart from this we made some textual improvements, a list of definitions so it's in general a much better document than RIPE 501.

We had discussion about this on the mailing list, had good feedback. It's now on last call. So that is going well.

We did simplify it a bit because there were different options and as an initiator of a tender you could choose how to use RIPE 501, you could say it has to comply with this or that, but those are the options that Jan showed you just before. We did make it a bit simpler now, actually show with all the list of RFCs, show which are covered by the IPv6 ready logo testing, so there is just one option, a device can comply with IPv6 ready logo and then you can see which RFCs are probably  which are not included in the logo testing, so what you might have to explicitly ask for in some cases.

So you can, as tender initiator, you have a much better overview of what asked for, what is covered with the testing programmes, etc..

So this hopefully makes it easier, even, to use. I have to point out, though, a lot of people have been using RIPE 501 just as a whole document. It is meant to be a template to be used, so you can copy paste a lot of it but if you use it to initiate a tender please pay attention to what you are actually copying.

I think we have to express our thanks, both of us, to Mike /KA*EUL, she has been helping us a lot with this document so she really deserves a lot of credit this time.

JAN ZORZ: Also Sander put lots of his time into this process. So we finished the editing phase. We are now under last call. There were lots of input on list and offlist. I would like to thank you all, you, you know who you are, that commented and made some useful input. Some very late but still useful comments came in, but many people in organisations are really waiting for the official replacement of 501, so, we decided to continue with the last call and hopefully we will succeed on this and get the consensus. So we are here asking you if you read the document and you agree with it and we promise that we will look into new and updated version at some point in time and I see Randy on the mic.

RANDY BUSH: IIJ. Could you give some clue as to the diagram between this and the document that is in the IETF, the CPE document that is there?

JAN ZORZ: With the CPE specification that we added, we included RFC from Ole that specifies the CPE requirements as a mandatory requirement. So we did not go  we did not redo the work from Ole, so because it makes no sense, because that RFC is brilliant I think and we just included it as a mandatory requirement, so if CP does not support that RFC, it is thrown out of the process. Is that answer your question? OK. Thank you. Any other questions? So please, use the document. It's meant for you, when you buy equipment you will require IPv6. 501 was translated in more than ten languages and now all these guys will have to redo their work because there is a new version coming out. So I hope that we did not cost too much trouble about that. Thank you.

SANDER STEFFANN: One more small comment: If you read the document now and have comments post them to the mailing list. Please specify if you think that if you make a comment, if it's really important enough to stop the last call, not declare as final or if you say, OK, I would like to see something changed but this can be changed in the future version so we can know if the last call is successful or not.

MARCO HOGEWONING: Thanks for that comment.

AUDIENCE SPEAKER: One last question. I saw the document  my name is Taja, I am a consultant somehow supporting German government, and I have one question concerning this source address validation improvements. What are your plans to pull it in your future documents, because you stated it, you will update it and it's from our perspective not without some discussion about these features.

SANDER STEFFANN: If all the specks are there we can look at including them. It's always up to the tender initiator to decide if they are going to ask for this or not. So, I agree with you that we are going to update it but it's always up to the initiator to decide if they want the source address validation or not in their tender.

JAN ZORZ: With this type of document, we could go forever on and on and on and on with new changes and following out with the IETF stuff that is doing there, but at one point in time, or at some point in time, we need to decide, OK, we publish a document and then we continue the work for the future updates. So, I propose we choose this moment now, which is this last call, we publish a document, declare a consensus, if there is one, and then continue the work. Will we continue the work?

SANDER STEFFANN: Of course.

MARCO HOGEWONING: So, this document is not part of the policy development process, it does not specify policy. We put it out to last call, last call will end next week, November 10. As Sander said, we can continue editing all the way so as people are waiting for a new version, unless somebody raises a red flag on the mailing list in the next few weeks it's our intent to publish this document as a RIPE document and move RIPE 501 to historic or whatever the state will be. Thank you.

(Applause)

Have a look, it's on the website under the draft documents section. Thank you. And talking about how these documents go, and what is happening with them, our next presenter is Constanze Buerger from the German government and one of the organisation that is actually is using the RIPE 501 document I think, so the floor is yours, Constanze.

CONSTANZE BUERGER: Thank you for the opportunity to speak and, first, thank you to Jan and Stefan for the work on 501, yes, it's for necessary and we are waiting for. On our presentation, first, we looked for very good title. It took us a lot of time, horses for courses. Typical German title, I think.

I want to give you an overview about all the things we did in the last time and we want to continue in the next time, and what happened; a few of you know me, we try to deploy IPv6 and we got from RIPE NCC a/26 and the of the interior and the further office of administration took over the role of the government. Big role for me, my banner is not here today and we took over the coordination of IPv6 Working Group. These are colleagues from municipalities and other user levels and we are going to discuss all IPv6 problems in the public administration. And I am very proud because the first thing what the Working Group was done, was the IPv6 website and so we have our own website and it's very untypical for German public administration from many user levels.

So, we are very proud l we have a decision in Germany for all that, in organisation and address space structure to use it and it's very new from March, for us it's very new, and so we started the process, every user can get an IPv6 address via our leer, and we have blocks for safe administration and these parts are called Suppea. We know we have to learn a lot and so we are thankful for our first RIPE NCC training. We had it in the last  in this year, and you see we have to learn a lot. Our first steps was to enter the RIPE database and this was very interesting for 20 people of us and so you see our Working Group there, and I think we are want to going on.

Our aim is to teach each other and what we did is we offered or we put all our experiences in a reference handbook and this reference handbook includes all addresses, concepts, templates, roles, organisations, processes, technical recommendations and so on, and this reference handbook is good, I think, good example for other governments to learn from each other, for our users or for advice as to help governments to implement IPv6. It's an offer we can make. I am going to translate it, this in English and I think if it's ready, we can offer it for you if you want, you can join our experiences.

What did we learn from RIPE training? For instance, RIPE policy compliant IPv6 address concepts from federal states and successfully matched the organisational structure of German administration to RIPE database objects. My first step without RIPE training, it took me four or five hours to use the database and many calls to RIPE NCC to organise myself, so it was very helpful for us to learn this via the training.

What are we doing also? We are telling about our needs. This is very important to specify the demands of public administration with respect to v6, and we are going to discuss technical policies with the community, considering the special needs and we explain the government's strategy, to manufacturers so that they can anticipate future developments. Then, we learned IPv6 is not v6 in the products we can buy or use, and this is a big problem for the public administration. Therefore, the work of Sander and Jan is very important for us because we need a special profile for the public administration. So we set up a research and development project and we want an IPv6 profile for ICT equipment and we know all the profiles, RIPE 501 N IS T, IPv6ready and what we are going to do, it's the comparison and we want not limit it to hardware but consider, also, software. This profile should be transparent for industry and users and influence the public IT infrastructure.

My colleague were the federal administration office is going, are the chiefs of the project and they are  they have two modules for the project, and one module is the IPv6 profile and migration guide. This supports transition to IPv4 and v6 dual stack, a blueprint migration plan and implementation guide and supporting calls for tender.

And the second module is a definition of justified IPv6 profiles. In this profile, we tried to explain why we do something and why we need some special functions. We defined three en/SREURPLTS and for every environments we defined a context depended profile, considered not only to technical, also to legal requirements. And so we got a definition of optional environments, a definition of profile for network components and what is new, and an analysis of software components. New is also a structure grouping of IPv6 standards according to functionality, so it's easier for our users to use this profile.

I show you an example. This is a profile matrix and you see the groups, and so you see the last column the German public administration, it's mandatory or it's not mandatory and I think so the profile work is going on. Thank you for for the supporting and work on this.

The profile matrix is ready in March next, in the next year.

So, we also can offer it for you to share it.

What we are doing, also: All the experiences are going into the application for a pilot from the EU Commission. There is a pilot from the EU Commission and we are going to a.m. Kate and this is in the ICT programme for innovative government and public services and regards and thank you for all colleagues who are joining this pie /ET. It's a lot of work, I know this, and the aim is a definition of European strategy and recommendation for transition from v4 to v6 based on best practices guidelines, backed up by real national and crossborder transition cases.

So, we join this pilot, Germany, the task in this pilot is a transition of data centre services and other /SHROEF convenient I can't, also Jan's country is also in that pilot, and we are  we have also crossborder pilots, there are many informations to this project if you want to have some more, I can give you this. Thank you for your attention and just a few  just the slide, for instance, for these crossborder pilots and if you want to have more information, you can contact me. Thank you.

(Applause)

MARCO HOGEWONING: Are there any questions, before you leave?

AUDIENCE SPEAKER: Amsterdam IX, you mentioned some files that was developed. I mean proceed use, is it available for public or it's only internal documents?

CONSTANZE BUERGER: We haven't done this decision but I think it will be open but it's not ready yet. So when it's ready, I think it will open.

AUDIENCE SPEAKER: Russian Federations. Could you tell, please, how much this costs German taxpayers? It's very interesting questions because year you were reporting about progress in German IPv6 enabling but your site is not  this site is not IPv6 enabled.

CONSTANZE BUERGER: Yes, you are right. I answer like a political; we are just coordinate at that thank address space and tried to deploy IPv6 and I think it's a normal process to bring it in the countries in the money /EUS /PALTS so it will take a long time, and we try to make it matching on the financial situation, on every municipality and country so and we can support on different ways and let's see how we can support. Let's our task to decide this.

AUDIENCE SPEAKER: But how much?

CONSTANZE BUERGER: It's RIPE meeting, I know. I can't 

AUDIENCE SPEAKER: It's not general meeting but we are 

CONSTANZE BUERGER: I can't answer that question because every user has to decide for its own /TPHROEUPLT process.

AUDIENCE SPEAKER: Each department have its own budget for IPv6 enabling?

CONSTANZE BUERGER: Yes.

AUDIENCE SPEAKER: So there is no coordination budget or your presented is voluntary instead of some government employers?

CONSTANZE BUERGER: We support the RIPE fair and we give some ideas to do, to work together with us but it's not so easy to convince all the people to work in the same network with the same services. You have to recognise the situation in the German administration. Every country, every municipality can do their own thing after constitutional rights, so they don't want to be pressed or we can't do any pressure, we can't give them good arguments and good services and good ideas to join us, so, and if they want we can discuss about money.

AUDIENCE SPEAKER: Thanks.

JAN ZORZ: Jan again. Thank you for considering 501 document as the basis for your work, it was really nice, but now we are up to the new version of 501 so this means you will have to restart all the work you did or 

CONSTANZE BUERGER: You she had answer. You know more than me.

SPEAKER: I read your document, your new one, and it's quite in the same direction we worked, so we are really happy about the mobile device category because we already also defined it in our work, so we just have to do a little update. It won't be a complete new start. /SPWHROR /STKPWHROR you are considering uptaking with the new document and keep on 

SPEAKER: Yes we planned it. We knew that you want to update your document, we knew it when we started the project and we already planned then to do a little bit update but it's not so much because the gap is really small.

JAN ZORZ: This is a good example of a best practice. Are there any other governments following?

SPEAKER: I don't know. Spain wants to do a profile and perhaps we can negotiate something about that.

JAN ZORZ: Thank you.

CONSTANZE BUERGER: I think it's very good to have the opportunity to use it and I think governmental work is very slow, but if you have document as a template, you can join or you can use for your work, it's very necessary, very good, it's a good starting point to begin, so for us it's very worth that you work in that 501 document for us.

Martin Levy: Hurricane Electric. I know that I am respond /BGing to the previous question about cost for the German taxpayer, and I commend you on a very politically safe response, which is understandable. Can I rephrase the question? And say what would this cost if you were to ignore v6 and that can either be, I don't think it can be an absolute answer but it can now be a more generic answer that may be easier to answer and more useful for people to hear.

CONSTANZE BUERGER: I can try honest, we tried to analyse the costs when we started to make pressure, to make pressure on the leadership, but it's not  there is no sense to do it because the infrastructure in Germany you can't compare it, and every municipality and country has another lifecycle and so the first impact we did, was to realise in the procurement process, the  to enable the v6 products and softwares and go out and buy just products with v6 enabled and so on, and so, we stopped that process to analyse the costs that was not sense to do this, so I can't say anything. Do you have an idea?

SPEAKER: Perhaps, Germany is a really complex country because of our Constitution, and therefore, the cost for really deploying IPv6 components is in each municipality and each federal state, and therefore, what we do is to provide the addresses in the first step, and to provide supporting documents and guidelines and the thing is, there are two motivations that I see in German public administration to deal with IPv6 and to say, OK, hey, we have to do it. The first one is address renumbering. We have a long history in our complex State that in the beginning of IPv4, someone said OK we need IP addresses, oh let's see, we take ten 000 /8. Everyone did this around 2000, and so we have a horrible network of cascading gnat gateways because all the administration offices have the same addresses (NA T) and they joined us to cost pressure and then they have to renumber because they have double addresses. And we have administration offices, they have renumbering history of four times and these are costs you can measure. These are really costs. And now, they are say, oh, this is horrible and so expensive, we don't want this any more; we want to have global unicast addresses with IPv6 so we get rid of this.

The second really motivation for administration in Germany to deal with IPv6 is another interesting thing; if you,, today want to buy as an administration guy, a telephone (today) infrastructure, you can't buy any more some ISDN or something like this; you are only able to buy voiceover IP telephone networking, so you have to deal with your IP network and, then, you have to think about the next step: What about if one office wants to call the other one and? And you have double addresses and this horrible NA T gateways and so better you have than to start from the beginning with this thing with IPv6. And these are the, from my perspective, now, the two main motivators to do this, and there is not a question what does it cost to do, but what is the cost not to do?

MARCO HOGEWONING: Thank you. We have got some comments from Jabber.

AUDIENCE SPEAKER: It's not a question, it's just a comment from a user from Anycast. He mentions about the question about Russia, Russian citizens will not pay for initiatives like that, they have too bad roads leaking water pipes, etc..

CONSTANZE BUERGER: I can add a political issue, yes. That is not only a technical side. We need technology and research things for the future and without technology, there is no development, so they are new business cases, they are new thinking about the open world, the connectivity. There is border. We have to be open, we don't want NAT, we want to be native, we want to go out without barriers so this is a very big argument for the political level and it's necessary to do just that. Let's do it.

MARCO HOGEWONING: I like the way you think, just do it. Thank you, Constanze. Great presentation.

(Applause).

Next up, Timo Hilbrink.
I left the company a year ago.

TIMO HILBRINK: I am a network engineer at XS4ALL, Marco used to be my colleague before he turned talking about IPv6 to his job. Mark cohas showed this slide a lot of times so I am not going to spend too much time on it it is in all the archives and everything. The only thing I will say is we are now also providing fibre to the home since October, so that gives us a whole new part of the market. Own technologies because there is no PPA involved any more which is what we use for most of the other stuff.

So we are providing IPv6 native since August 2010, and it's an optin service available to almost all our customers. In order to enable it you go to dashboard and you have to click that you want a prefix. Up to yesterday, we had about 15,000 registered /48s, so that is pretty good. Except there is another accept that customers have to take, and that is enabling it in their CPE. That works like that. And you have to do both steps to actually be able to use IPv6 in. As Erik already pointed out is that since I think about few weeks, this step is not necessary any more because in all the recent firmware, in the most firmware it is automatically switched on, so in theory, all those 15,000 prefixes should become  should come online. The only thing is you have to go through the setup wizard of the CPE to get it enabled, but anyway, we have over the time, we have been keeping a track of how many of those v6 leases we hand out, and it's pretty interesting to see what the public exposure does to the prefixes.

This is the graph over time. This graph starts somewhere in December 2010, when it was still  we were just out of the pilot and just starting to make it a normal service. I will go through the little details of the bumps you see in this graph here.

This was when AVM supplied a firmware that actually worked over PP U A, the previous, until then over PP U E which meant only our VDSL customers were able to Tuesday because the normal ADSL  still use the PPPOA so that's a slight bump there. Then we made a company blog posting about IPv6, explaining why it's necessary, basically what we have been talking about here for years already, but then in terms that our end users would understand. That is another significant increase in active prefixes, so that was good.

Then, there was another blog posting about IPv6 day, which caused a lot of you, we wanted more people to be aware of it and we wanted to something to happen in our network on World IPv6 Day, so what did we do? We set up a prize draw, a prize draw consisted of setting up an IPv6 only website where customers had to go to and predict, using a native IPv6 address, predict how many people would have an active DH IPv6 at end of World IPv6 Day. Well, that worked. So we got about, I think about 2, 3,000 extra prefixes online just in those two or three days that this prize draw was open, and the end result I think was 4,800 and something. So that was  so you give away one iPad and you get that many new people on IPv6 in our network.

What you also see is a slight increase at the end of the graph. That is the firmware I talked about earlier where it is already switched on so you see people going lieu the setup wizard and actually coming online.

That is as much as for the development of deployment.

For the rest, there is some small news is we have new service, we developed our own web TV application where both the dashboard and actual streams are dual stack, so our IPv6 customers, they view the web TV application, including content over v6 completely.

For the rest  oh, yes, we have one more CPE that we have tested on our network, both pppoa and pppoe, the Zixel 28 /12. I think the firmware is not public yet but it will be very soon and this box works fine. It has DHB v6 on the server on the line which is also nice. So, for the rest, we are going to test more CPEs shortly since we have the fibre to the home product now so we can actually test equipment that has, that lacks PPPOA, so see if this, this is compatible with our setup. And that was it. Thank you.

MARCO HOGEWONING: Any questions?

AUDIENCE SPEAKER: Max. There was a slide that shows settings for CPE. Yes. There is MTU show 1452, why it's so low?

MARCO HOGEWONING: To do with the fact that this is PPoE link.

TIMO HILBRINK: I was thinking. All this mine for the 80s for the PPoE?

TIMO HILBRINK: No.

AUDIENCE SPEAKER: Will bring you 8 byte, will bring you some 40. It's like part of your implementation.

MARCO HOGEWONING: Thank you.

GERT DORING: Actually, I didn't want to discuss MTU because that is all this technical stuff. I just want to applaud you on this because it's really great to see one major mass market carry a go forward instead of having doubts about all this new technology. So thanks very much and I hope that I will see some sort of more than 100 users deployment in Germany any time soon.

(Applause).

MARCO HOGEWONING: So, one final question: If one iPad yields 5,000 customers, when are you going to buy the other 50?

TIMO HILBRINK: We are looking into a mass deal on I pads so maybe we can see if we can do something to get some more customers. I think our customers would like those promotions as well.

AUDIENCE SPEAKER: Andy David son from Hurricane electric. Do you know approximately the retail price of the 6 old router that supports v6 for your end users, approximately?

TIMO HILBRINK: The shop price?

AUDIENCE SPEAKER: Yes.

TIMO HILBRINK: It's around 100 euros as far as I know. Not far. Andy Davidson: That price is coming down all the time, everybody should be doing something knowing CPE is going to cost less next year.

MARCO HOGEWONING: Not hold you back on buying them now. We know they are going to be cheaper. Thank you.

(Applause)

Next up is bit of experiment. We got so many requests for speaking slots and people that had interesting things to show, we have decided to introduce the concept of lightning talks to this Working Group so what we are going to do is three short talks on different topics and I would also encourage other people that have information to share for the next meeting, consider joining up and sending in light thing talks because I do think it's a nice way of getting a lot of areas covered in short time. And first one up is a proxy speaker, I think the agenda said Paul Rendek but Chris Buckridge.

CHRIS BUCKRIDGE: Thanks. I am a proxy speaker squared I guess because I am replacing Paul Rendek who was replacing Martin Botterman from GNKS who is responsible for the global deployment monitoring survey. This is the third year that this has been done, the first two years it was actually sponsored by the European Commission and was conducted with the support of the RIRs. The first year was just in the European region and the second year then global and this third year it's also global, but without the affiliation to the European Commission, but the NRO has continued to provide some support.

It comes with the caveat that this survey is done as a volume tier online survey so compared to some of the very hard statistics and data you will see here this week this is probably more something that should be used for impressions, ideas about how some people in the industry are feeling with all of the understanding that it's probably a self selecting group of people who are very interested in IPv6 to begin with.

So this year, there were over 1,600 respondents from 135 countries. That is slightly more than last year so that is, we are releasing the level of interest taking part in the survey is consistent. 46% of the respondents were from the RIPE NCC service region and the profile of those respondents in terms of the sector they represent, the size of the organisation is quite similar to previous years as well. I think roughly, 46  46% are Internet service providers or identified as Internet service providers.

So, and then this statistic alone will indicate that this is probably not representative of the Internet community generally. But we can see that around 93% of respondents either have an IPv6 allocation or assignment or are planning to get one in the foreseeable feature, so it's a positive result from the survey but as I said, probably not representative of the industry.

But I think what is useful in this survey is that we can compare it to previous years, we can see if there has been any movement and so, one of the results we see here and where there has been quite some significant positive movement is, and this is a question that was only asked of the Internet service providers, what percentage of their customer base is using IPv6, so, in 2010, 60% were on zero percent, which basically means 40%, only 40% of ISPses were offering IPv6. Whereas now, we see only 44% and are not offering IPv6 and this is of those respondents.

This graph again probably, the text is a little bit small and to actually see the detail but it does give an impression. We can see over the three years there, that those respondents with no plans for IPv6 deployment on any of their services, is consistently shrinking.

In terms of the biggest hurdles that people are facing when they are planning to or in the process of deploying IPv6 we are seeing each of these and we have vendor support availability of knowledgeable staff, costs, business case to nontechnical business decisionmakers, information security other and don't know. We are seeing those consistently dropping, except for information security, where we are seeing there has been some increase. So I am not sure what to make of that but that is perhaps an area worth looking at. And then for those who have deployed IPv6, we are seeing the biggest problems with IPv6 in practice. The lack of user demand is actually larger in 2011 as are the technical problems and budget issues. So, again, we make of that what we will.

This has been a very brief summary or not even summary, part of the results of that survey. I'd encourage you if you are interested to go and have a look at the full results that URL. If anyone has questions, I can certainly attempt to answer them but we will probably direct to you Martin's email there, he can answer any questions.

MARCO HOGEWONING: Thank you, Chris. Questions? No.

(Applause)

Which brings me to my own topic, I am up next. Thank you. As a disclaimer, first of all, this is me presenting as trainer of the RIPE NCC, big disclaimer, this is really preliminary work; we were just curious on what happened. The effects of human capacity building on the deployment of IPv6 ways fancy way of all these training courses that we provide, are they actually useful?

So as let's see what we can do with the stuff we have. So we took some statistics on the IPv6 deployment, which we have at the RIPE NCC, which is namely the number of members that have an IPv6 allocation; in other words, those that show up on IPv6 RIPEness as one star or at least one star, and we have statistics on networks that are advertising ASNs. Both these statistics are nicely groupable by country. So we split them per country and plot them over time as a percentage of the total networks or total number of members. And what we then made on that timeline, we plot in what we think are significant events. Mostly training courses because that was what we were after in the first floor. We also do stuff together with MENOG, MENOG IPv6 roadshow which is a slightly more technical networking course and plotted in some meeting dates and let's see what happens.

Take a look at the random sample. Bosnia, it's a tiny pool only 29 LIRs so whenever it gets an IPv6 allocation immediately causes a big jump of a couple of percent. This looks like a signal. We do see that somewhere there was an IPv6 course and we do see both the number of networks, that is the green line, that has an IPv6 allocation go up as well as the number of networks that are advertising IPv6, that is the red line.

We also see some spike not related to a training courses. These time lines go from 2008 until now so you are looking at roughly four years.

And we see at World IPv6 Day, there was no result. Taking a look at the slightly bigger country, and we took Poland, for example, which has almost 300 LIRs, there are no significant changes. There is no signal, no spike here. And that is probably where these statistics are not really that smart, training courses tend to be attended by 25 or 30 people so we only hit very tiny percentage of the LIRs in a specific country and evenly percentage of that percentage is changing to IPv6, it's probably won't show.

Going back to a small country again, Georgia, we see some clear indication or clear signal closely after the IPv6 course. We also see an interesting signal that at least one network started to advertise IPv6 close before World IPv6 Day. They left it on, but about a month ago, they switched it off again, so  and we are actually quite curious on what happened. We probably need to contact those guys. So this is it.

To answer my own question, are trainings effective? Based on this, we seriously, we can't tell. We do think that there is a signal, especially take smaller sample groups, we do see spikes. It's likely those spikes are also showing on the bigger countries, the bigger deployments but it's really hard to tell. Our statistics are not granular enough to show this. Why am I showing this, why am I up here? What we are going to do next and our intention was to do it before the RIPE meeting but that is the busiest time of the Manning year so we didn't manage, probably next week a link to the web server containing all these graphs for all these countries and what I would like you, and I will post a link to the list when it's up there, to have a look at it and maybe, inform us on events, because we also see spikes on places where we can't place it and maybe you, in group nodes, there was a task force meeting or we did some something, training courses, see if we can actually plot out these spikes and make this more useful and see if we can fine tune this data.

With that, any questions? No. Which brings me to the third and final lightning talk, which is Ole Troan.

OLE TROAN: From Cisco, going to talk about something we call stateless IPv4 or IPv6. In five minutes, I have to use five slides, I have ten; we will see how this goes.

So, the reason we don't have much v6 deployment is clearly because we haven't invented enough transition mechanisms. So, when people now realise that oh, shit, we are running out of v4, things happen in that blue blob down to the right there, and these are all the new proposals for how to do, you know, v4, extend the lifetime of v4, all these mechanisms basically do shared IP addresses. There is also some on the left there, the most famous one is the DS light, which does shared IP addressing by moving the NAT from the CP to the CGN over an IPv6 tunnel. The other alternative is to use the CGN and double NAT but transporting private addresses in your core network typically leaves to some form of tunneling anyway so why not use v6? . The problem space we have down on the right is solving two problems: It's doing the  extending the life of IPv4 and unfortunately we have to do that by having the NAT at the CPE but sharing the port space. So this is A plus P if anyone remembers the Tshirts with 32 plus 16 larger than 128. That is this space.

The other problem it solves is further down the time horizon where you have residual v4 left, right? You start to turn v4 off, then you can use these mechanisms to carry your v4 traffic over your v6 network. I mean, if you built a new network today, would you build it dual stack or v6 only? And some people are actually thinking of let's just jump to v6 only and transport v4 across it.

So this is dual stack, tunnelling everything into a large NAT, please raise your hand if you like CJNs? There is one hand only. There is two. And Sandra. So if everyone had raised their hands we could have just finished because then this wouldn't be much point.

What some people have claimed is that, you know, large scale NATS, they are costly, hard to make reliable you need proprietary protocols between multiple NATS if you want to scale them and stuff. So some proposals came up which basically is the reverse of 6 RD, you embed all the state you need into the v6 address, we can just stuff some v4 in there and some port set bits in there and we have the, all the state we need to do the mapping between v4 and v6 into the address. There is two proposals, one called 4 RD which is enclapslation, tunneling as we know and love, it's full, you have direct communication between all the CEs for the domain traffic, go to the B R which is just a router doing tunneling, you can just add more BRs when you need more traffic so while CGN scales on the number of sessions you have, B R scales on the number of packets it forwards so it's just vanilla router.

The other alternative is to do this with DIBI which is double translation, NAT 464, just that it's stateless. Basically exactly the same thing and I call it a null encapslation; you carry the same thing, just replace the v4 header with a v6 one.

So this is how the addressing coding scheme looks like. We are running through, this is kind of fresh stuff, we just published a new draft on it yesterday. How this should look like. Typically what you would do is put last part of your v4 address into the v6 one, so let's assume you have a v6 prefix  sorry, a v4 prefix, /16 for example, then you put the last 16 bits into the v6 address and that kind of looks like this. You have wellknown service provider prefix first, you put the 14 bits of address and port and whatever else you have left, don't care about those. You provision a /24 in this case, so you served you combine half of the bits to create your v4 address so this does v4 provisioning of your address and prefix and a shared IPv4 address. Take the remaining bits and create the port set ID, which you put in the middle. There is some good reasoning why it is infix and not a prefix. It could very well be the prefix, that would be the simplest algorithm but end up giving away the wellknown ports. Combine all this, you get about 1,000  1008 ports, for each customer. And you can scale up to this so one /24 would serve 16,000 subscribers, so you amplify your v4 space quite a lot. It's obviously not as efficient as CGN would be or a DS light because then you have much larger user space to multiplex among. The big benefit is you keep the NAT at the CB where it is today. Every one of these solutions it requires CPE changes of course, so need some flexibility in the firmware there. The only solution that doesn't is CGN but if you want to be behind a double NAT without any v6, well good luck to you.

So this is basically the idea of the forwarding architecture. The you take the existing NAPT 44 that is in the CPE, hook it up with the Map function and translation looks exactly the same replace slightly different end cap, v4 with v6. This is never exposed to the applications, purely done on outside address of the NAT. This is  this is overview of the architecture. See the difference between encapslation and translation there.

If you have any questions buy me a beer.

JAN ZORZ: Jan. So this is basically not a question to you but to the community: It happens that I am part of this MAP architecture team and if you can go back to that slide with the mathematics. When you said that you can  that you exclude first thousand wellknown ports, so there was a long discussion, if you think that wellknown ports must never be allocated to an end user or you think there must be a possibility for the operator to give one of the users on that IP the possibility to have wellknown ports, and if somebody have an opinion on that, from operator side, I would be really happy to hear that. Thanks.

OLE TROAN: Please run up to the mic. Just to say something more on what Jan said, that, you know, so we would expect that some users will not be happy with a shared IP address, you know they will not be happy behind a CGN or DSLite we have a solution to this in this map address and port solution which is to give, then you can give a full v4 address to the customer and that is supported in this mapping so that is the simple solution.

AUDIENCE SPEAKER: Thank you. Benedict, freelance IPv6 guy. On Jan's question, I think you don't need to give users any low ports because it shouldn't be necessary for what they need to do. If they really need low ports for whatever reason, all these mapping schemes, and I mean pretty much all of them, are going to give so much trouble it's not going to work properly anyway. So this is  if we talk about, you know, private end customers, low ports are not really worth the trouble, aside from the fact that they are pretty much antiquated concept by themselves. The other question, or the one thing I am not sure about: Are these  all these mechanisms we are currently coming up, trying to prolong IPv4 support in our net, are they actually worth the effort or aren't they counterproductive?

OLE TROAN: Yes. The good thing about these mechanisms is they make v4 day by day crappier, encourage v6 deployment.

AUDIENCE SPEAKER: Yes because people only start to do things when things hurt. I am not even sure if they hurt now.

JAN ZORZ: You say if user wants to run servers at home, then just buy full IP address, pay more and be done with it?

AUDIENCE SPEAKER: What I am saying is that the majority of people won't want run a server at home as much as they do these days. Those who want to, really want to do that at home, they will quite likely switch to IPv6 in a very short time by now. Those people who really want to run an IPv4 server at home or wherever, will have to get some real IPv4 connectivity, IPv4 addresses somehow and that is going to be difficult to be done at home but it's not something you want to provision for at the mass end cusser ISP level with their standard products.

JAN ZORZ: Yes. OK.

AUDIENCE SPEAKER: That is just an opinion right off the head. I might change my mind after a couple of beers.

JAN ZORZ: If it's worth the pain, I am a quarter of A plus B with Randy and Nokia and Juniper and other guys and this is basically stateless A plus B, so we think it's worth the effort because this is the only alternative to the CGN. We don't want CGN to happen, right?

AUDIENCE SPEAKER: I want CGN and I want it to hurt 

JAN ZORZ: I think it will be explained now how that works.

AUDIENCE SPEAKER: I first had a comment on this issue of that  I think it's a very good solution that if people want to have better servers we give them a real IP address and that works today and we should keep on doing that instead of adding more complexity to do something else. And I also want to comment on the prolonging the life of IPv4 issue and when you were asking if people here in the room like CGN I did not raise my hand, OK? Just for the record. But I just wanted to say here I think it would be fair to point out that there are tradeoffs here so one tradeoff here is that if you are doing this port division per customer on a static basis, the power user and the grandma get the same thing and neither one might be that happy.

And the other thing is that putting the portalication in the address, in the IPv6 address, will sort of bind your IPv6 address plan and the port allocations together so if I have a customer, I am an ISP, has 1000 ports I want to give him, one customer, 2000 ports, the worst case you renumber the entire ISP and all of your customers.

OLE TROAN: That is a pretty bad case, though. For your first case you could easily have, if you have two v4 subnets one with 1,000 ports per customer and another with 256, you could do that. You definitely are right that you have to renumber. I think when we have solutions to that 

AUDIENCE SPEAKER: There is good cases and bad cases, I, on purpose, took that extreme case. Just pointing out that there is no free lunch here, that we will pay for this the CGN thing but also some of these other designs.

OLE TROAN: Yes, absolutely.

MARCO HOGEWONING: Thank you, Ole.

(Applause)

DAVID KESSENS: This should be the next presentation now. So I am David Kessens, I am going to talk to us about some ongoing work in the IETF, it's a topic that I think it's important people are aware of. I want to emphasise that I am speaking here on personal title because I am also happen to be a member of the IAB so this presentation has not been checked by the IAB, it's just my presentation, how I see what is going on on this particular topic.

Unfortunately, this topic is also about CGN and, again, this is about an informational presentation; I am not stating whether I like or dislike this proposal, I just thinks important that people are aware that this is going on.

So, the problem that people have identified is the fact that if they are going to deploy CGN in a big network, they are going to have issues with address  overlapping address space, either the inside or outside of CPE. This is all beautiful problem, so people decided they need to find solution to this, so proposal came from especially the cable industry to yet another set of shared address space as they called it, and that address space could be used in the ISP network to make sure that there is no overlap between the CPE side, customer side and the network side.

This proposal was not so well received at the IETF the first time, and hence, those people started to look around a little bit and it turned out that ARIN community actually liked this and took this up as a policy proposal and decided to go forward with that, and they actually wanted to have a /10 allocated for this. At that point, the ARIN board actually consulted with the IAB and said, mmhmm, I think there is some agreement between IETF and IAB and IETF about special address space allocations so they looked at it again and it was decided that IETF will take, again, a look at this proposal, so this proposal, again, ended up in the IETF.

The result is that there is knew draft that has reached the IAC where the IAC has had a few comments on it. It was decided to change the status of this document so, therefore, there is new last call outstanding on this document, and my big thing is I would like to encourage people again to just take a look at this, see what you think about this and make sure that you are aware of this. It is, in itself, it is of course about IPv4, but of course any time you do something with IPv4, it affects, also, IPv6 deployment of future deployments of IPv6, so please take a lot at this  at what you think about this and that is basically it. And don't shoot the messenger, it's not my proposal. Questions?

GERT DORING: So which address space are they going to use for it? Given that there is nothing left in IANA pool?

DAVID KESSENS: That is of course one of those issues. However  however, since this proposal actually was well received within the ARIN community, within ARIN it was decided it was well worth ARIN's address space to help out with this.

GERT DORING: Yes some address space has been identified.

GERT DORING: So they are going to IETF to get ARIN address space?

DAVID KESSENS: Something like this. Yes.

GERT DORING: I fully understand ARIN's policy process.

AUDIENCE SPEAKER: I think the idea for, with this process was to check with the IETF that it actually makes sense or will break some other things and not cause any surprises, and I was actually one of the IS T members who reviewed this document and had a little bit of concerns with it, actually; I mean, there is several things, one is whether we actually want to do it, that that sort of a community decision, of course, but there was also some issues with the particular proposals that they seemed to think about this in terms of what is the effect on the ISP, that I am an ISP, I allocate this thing or get this address space and my devices work well now, but this other effects on the rest of the Internet infrastructure or applications, anything that relies on correctly analysing whether a particular IP address is private address space or not. My en, there is a lot of equipment that is built with those assumptions. I did a little search on a few things, a couple of different pieces of software and most of them had some code in them that, you know, was hard coded to do RFC 1918 addresses and the effect of  I mean it's good for the ISPs but what is the effect on other things like applications that rely on this stuff? That is a little unclear. So, I guess I making David's call for participating in this new discussion and providing your opinions on whether you really need it and whether it makes sense and whether it breaks something that you care about.

KURTIS LINDQVIST: So is the proposal that was thrown out, it was two IETF Working Groups, voted down in two RIRs, sent back to one RIR, to the IAB to override all the other processes?

DAVID KESSENS: I am not saying that I missed all the places where it got thrown out, but it did happen in several places, yes.

Martin Levey: This question is prompted by your talk, David, but really goes over your head to the Working Group. It seems to me we are not talking about v6 enough in this Working Group; we are spending a lot of time talking about v4 issues which carrier great NAPs and translation protocols. Is it possibly we could, humorously yet, v4 to move the carrier grade NAT and noncore 6 issues so we can really focus on v6 proper. And that is  after a few talks, that is just prompted by this is the straw that broke the Kamell's back, talk. Open for questions.

DAVID KESSENS: That is obviously a question that can be and may be asked, you know, and even one of the Working Group chairs and this is something that should be decided by the people in the room so I think I should refrain from comment on that and ask what people think about that.

JAN ZORZ: Martin, I agree.

MARCO HOGEWONING: Can we defer this to the mailing list.

DAVID KESSENS: I think considering timing, deferring this to the mailing list might be a very healthy option in this case and/or making some extra time at next meeting for both for 

AUDIENCE SPEAKER: I look forward to an interesting session in the next meeting, then.

AUDIENCE SPEAKER: Just some comments. I probably said something very similar in 2007 and then I was talking to some friends who do not want to discover his identity, but he is sitting in this room, in this room, and he said that we can create a pool of addresses just by adding, by ISPs some address space, and even we develop the kind of mechanism for that, how to add and probably  after some address space so this was an option.

DAVID KESSENS: Thank you. So, just to be clear, this was just a short presentation that people have an idea what is going on. I mean, it's not strictly IPv4 but of course it has  yes, influence on what is happening in IPv6 space. I give now the mic back to the other chairperson.

MARCO HOGEWONING: How much time do we have left. About 15 minutes. We are actually quite nice. As I said earlier on, bear with with us, this session is going to take until 6:00. We are going to be in time for all the socials, rest assured.

This is a bit of an experiment. Speed dating. It's a world first, I think. I hope. I made that claim earlier on. And it was challenged. What is this about? This is a continuation of something we are doing in our training courses and it hopefully satisfies Martin Levy's need to talk about IPv6 in this Working Group and actually do a bit of work in a Working Group. There are two types of people:

Probably also in this room. It's very easy, we have those who have IPv6 already deployed and those who are hopefully busy deploying IPv6. And if you look closely, you will discover that there are people who are planning to be busy deploying IPv6 and people busy testing and people are busy rolling it out. Let's do a quick show of hands here: Who considers himself part of the first group, who says like I am fully deployed dual stack IPv6? That is quite a big show of hands. I can do it in a lot of other rooms  I can do this in a lot of other rooms and gets two or three hands. Assuming the other one are busy deploying IPv6? Yes. That is the other half.

Now, of those who are still busy and maybe also the people who already deployed IPv6, you probably encounter some problems and, well, you can call them problems, you can also call them challenges. Let's give this bit of a thought and think about what was your biggest challenge, what is your biggest challenge in deploying IPv6 and already throughout the day we heard some examples, for instance CPE. Give this a second, think about it and let's see and try and solve it, because if you have challenge deploying IPv6 there are other people in this room that already passed that point. So, and I am going to step off stage now and see if somebody is actually  who is willing to share one of his challenges? You don't have to state your name of affiliation, anonymity guaranteed. But out of this group who is busy deploying IPv6, who is willing to speak up and tell me what their biggest challenge is. Go on, don't be afraid.

AUDIENCE SPEAKER: Yes, my big problem is combines the it useful and good spend money. They don't understand T they think it's a lot of money.

MARCO HOGEWONING: So management thinks is about money and they don't get the point across. Out of those people who have deployed IPv6, probably somebody who had the same discussion with his boss, how, in the end, did you convince it?

Andy Davidson: Do anyway. Hog a convincing argument for your boss.

JAN ZORZ: I have 45 minutes presentation on there about Go6 in Slovenia that explains the same thing.

MARCO HOGEWONING: You can always fly in Jan.

AUDIENCE SPEAKER: There is one reasoning: I don't fully recommend using this if you don't know your boss, but ask him what is the business case of an earthquake? IPv6 itself doesn't have a business case and managers trying to reason about business case all the time, will eventually realise that they have lost business because they saved so much money. The point I found helpful is explain to them you can't avoid it. And if you look back, year 2000 didn't have a business case except for some people, and they pretty much had the same problem. This time we don't have a fixed date but otherwise it's going to be the same. Again, don't mention year 2000 unless you know your boss because the situation might get, well, sort of embarrassing to some people, but in some cases it actually helps to make people understand that they have a very similar situation here.

MARCO HOGEWONING: Thank you.

AUDIENCE SPEAKER: I think you have to explain to your boss that he should write a business case, what cost if they don't do it, that simple.

MARCO HOGEWONING: Thank you. So, anybody else? Maybe a technical problem.

AUDIENCE SPEAKER: Thank you. Google. So from operational perspective, the biggest problem I have ever seen is that we are still discovering bugs and unfortunately, some bugs could not be easily found in test environment and also we are trying to avoid using customers' traffic to test our network, sometimes we still have to do that. And another problem, you could not take anything for granted any more. I mean if you believe something is working for you before, it does not mean it work for v6. (V4) we had an issue when for example, routers stopped detail for V of and we asked vendor what is going on and the first answer was, you have not asked us to do that. So, we have to test almost everything again for v6, even some basic stuff, so my idea was to just to test everything twice and don't think anything could work just out of the box. Because you can find some rid includes stuff sometimes on your network and sometimes you need actually real production environment. I don't know how to solve that, except for testing.

MARCO HOGEWONING: As you mentioned, testing, wouldn't it be great if you not only did the tests but shared it with the group. It's actually the background of this presentation that was a couple of weeks ago I was at another conference and somebody in the room asked me the question like: Is there a global, is there a big knowledge base about IPv6, is there some global resource pool? And my response to him was, you are sitting in it. And that is actually what this IPv6 Working Group is about. This can be big pool of knowledge and resources if you are willing to share and are willing to help out, and I think that is the key message here is that transitioning to IPv6, deploying IPv6 is not only your problem; it's everybody's problem, and once again, we can only ask you to reconsider and help each other out here because I personally do believe that that is the way forward. I see Dave.

Dave Wilson: HEAnet. Let me get this straight: The question is what problem do you have to solve in convincing your boss to let you deploy v6, is that right?

MARCO HOGEWONING: Yes, that was one of the issues at hand, is how to convince your boss.

Dave Wilson: How many hands went up again to say they were deploying v6?

MARCO HOGEWONING: About half the room, so went past this point.

Dave Wilson: So we don't know the answer to that question? The people in the room don't understand that problem because we solved it in our case, I solved it in my case and with something that looks like a business case, at least where I come from. So we are stuck. What we are talking about here I think is something akin to market research where we have our opinions and we have our experiences, but they must be different from the other 90 or 95% of the industry.

MARCO HOGEWONING: Yes, thank you.

AUDIENCE SPEAKER: Just a point: Sure there is some other technical problems for deploying IPv6 but it's certainly not for operators now the main problem. After convincing your boss, the main problem is more organisational because, in fact, all the departments in the company, in the operator company, is impacted; I mean, networks, IT, services department, marketing department and all have to work together and going to the same path and it's not always easy to, even if you are convincing as a technical people you have to go to IPv6 that all the departments have to work together and it's a very big problem, I think it's one of the main problems today.

MARCO HOGEWONING: Thank you.

Andy: From Hurricane. I have got a slightly more serious to the question that is built upon Dave's comments from a moment ago about how do we convince our employees to let us roll out v6, and my first answer was just do it anyway, but I think that that has got  there is a slight bit of serious overtone to that because if you are not spending some of your own development time at work, even if there is no official mandate, if you haven't built a tunnel into your lab environment and that you are getting personal experience with v6, so that you can roll it out more quickly when the business case follows or you are forced to by your competitors then you are not going to be able to roll out v6 so whether there is an official mandate or policy or not is a really good idea to skill up yourself because if you take this to the logical conclusion and never roll out v6 so the company you work for goes bust, who are you going to work for next if you haven't been getting skilled up with v6. Whether there is an official mandate or policy or not, it's something everybody should work on just by building a tunnel to their lab and figuring out how does this work and when you have done that you can get it in through the back door more quickly.

MARCO HOGEWONING: That is fairly well remark here, get yourself skilled up, this is not only about your boss, this may only be about yourself. We are running out of time here and people may wonder what the speed date is about.

What we are now going to do is, hopefully David can help this, is we have got some stickers here and two colours of dots and we have got orange, I kind of picked two different colours of orange, someone a bit pinkish and black dots and we are going to distribute them and what I would like to say is pick one and place it on your badge and if you say I have black one, I have some questions and put on the black one. If you think you have some experience with IPv6, you were in that first group, pick one of the bright coloured ones, and I want you to promise me thing, sometime tonight during the social wear this and if you see somebody who has the other colour, just talk to him and approach him, I see you have a question on IPv6 can I help you? Hey, you have some experience with IPv6, maybe you can pep me. And that is what I think and as Martin said, I think this is what this Working Group is about, talking about IPv6 and sharing this knowledge and sharing this experiment. So with that, I would say, have fun and remember that if the first time at speed dating you might find somebody who doesn't have the answer so you might want to just try again if the first time you are not lucky.

So that is it for now, I think.

The bright ones are, I have some experience with IPv6; and the black ones are, I have some questions.

DAVID KESSENS: I will be standing next to the door if you are leaving so I can just hand it to you if you didn't happen to get it neighbouring snaking through the room.

RUEDIGER VOLK: Marco, I am kind of surprised you think those two colours are mutually exclusive.

MARCO HOGEWONING: Of course you can put both colours on your badge but promise me you won't be talking to yourself all night.

(Applause)

We are overrunning slightly. Before we close this session, I have been asked to make a short announcement and that is about tonight's social, Netnod is providing a night out in the museum. It's about 15 to 20minute walk through stat park or if you want, you can take the subway, the green line I think it's U 4, two stops from here, the social starts at 7 o'clock and in your pack you will find a flare with some more information. On the topic of fliers with more information I have also been informed that you have been bought a dinner ticket, there is a misprint on the subway information; so don't rely on your dinner ticket, we will provide more information later on on the correct subway lines and stops you should take. With that, once again, thanks for your participation. Use the mailing list, it's there, and hope to see you back in sleeve own I can't somewhere between 16th and 20th of April. Thank you.

Applause)

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE



1