These are unedited transcripts and may contain errors.

We are nearly at the end of RIPE 62. There are a few small reports to be done and a couple of other announcements and then you can go for lunch.

The first report I would like to invite Brian Nisbet. Yesterday at the end of the day, there was a BoF on measurements issues, and Brian will report.

BRIAN NISBET: We had the Measurements BoF yesterday, part of the meeting evolution and change. It lasted just over an hour. Lots of interesting conversation ideas: There is more on the MAT Working Group mailing list and people are encouraged to contribute there and join up and keep the conversation going and the Working Group Chairs have told me that they'll develop an action plan and, you know, work with the NCC to go from there.

We also had an incentive to come along and give ideas and a prize for the best idea is decided by the Working Group Chairs for RIPE Stat. So, and I am going to probably mispronounce this, so the prize of the iPod goes to [Muritzio Bogara], if he is here at all:
(Applause)

ROB BLOKZIJL: Okay. And I suppose we will see very soon on the stats website the implementation ??

BRIAN NISBET: I suppose so.

ROB BLOKZIJL: Okay. Secondly, I would like to invite Joao, I have been told that he will do the reporting on ?? basically, we started this meeting with a presentation by the Working Group Chairs meeting taskforce with a proposal. In the course of this week we have had at least one big meeting and a lot of hallway discussions, and Joao will now report on the results of that.

JOAO DAMAS: Thank you, Rob. I hope you all, at least most of you saw the report from the meeting taskforce given by Andy Davidson in the opening Plenary Session and there was recommendation there to make things a little bit more structured regarding how the RIPE meeting content, other than the Working Group content, is scheduled from now on and the recommendation was to put together some initial programme committee which everyone will be able to address and will be in charge of organising the content in a timely manner. Can I ask the people who are now going to participate in the boot strap programme committee to stand up and if you can actually walk over here so that everyone gets to see who you are, and that will be even better.

There are eight people, not all eight are here. I'll give you out the names. Some of them are sort of appointed positions; for instance, myself, I am appointed by the Working Group Chairs. Some others come from different places, so, for instance, we gave special attention to two regions that somehow have more challenges than the rest to come here. That would be MENOG and ENOG. We want to bring the content into the regular RIPE content and so, for ENOG, we have one person here who will bridge the gap between the [] /AEURB yen community and the rest of the RIPE community. Andrei Robachevsky. MENOG, pending confirmation, are we are hoping on getting the Chairman of MENOG, Osama [al de Sari] to participate and, again, bridge the gap between their community and the rest of of us. For each meeting, we thought it would be a good idea to ask someone local to participate for that meeting, wherever it takes place, so we can engage with wherever the committee wherever we go. The next RIPE meeting, RIPE 63, will be in Vienna, Austria, and, for that representation, we have [] Hal [Michen] from V?IX operations. The four remaining persons are meant to be from you all, representing all of you. For that, we have selected a few to get things going. From the end I'll start with Sander Steffann, who you probably all know; Todd Underwood, who has been involved with APRICOT and NANOG for a time and knows what he is doing in these sorts of things. Daniele Arena has been involved with NaMeX and the RIPE. He worked for RIPE NCC when we were both there some years ago. A good colleague, a very good person. He is from Italy so we also bring some from outside the Germany, British association. And Rob Evans, who works for JANET, he is a co?chair of the Routing Working Group and a good chap all around.

The idea is that these four people who come from you all, will ?? one of them will stand down or put himself up for re?election at each of the RIPE meetings and each of them will serve four meetings, not the niche ones obviously. So that the idea is beginning already with RIPE 63 in Vienna, one of them, we'll figure out who, will put his position up and you will choose who, whether you reappoint the person or pick a different one and from then on we enter a rotation and that's how things are going to work.

In case someone is wondering, yeah, you talk about change but you are still the one holding the microphone, I am tired of your face. I'll make a commitment right here to not be on this committee for more than four meetings. Make it that RIPE 66 will in any case be my last one. All I want here is to provide smooth transition, and get things going.

There is a mailing list which you all will be able to use to address all of us, pc [at] ripe [dot] net. Standing for programme committee this time. Everyone is welcome to post. The archives won't be open to everyone though, because we want to have some space where we can discuss freely what the proposals that come in look like and without necessarily embarrassing anyone.

The idea is to start working right now. And open the call for papers for the next RIPE meeting as soon as feasible. We are looking at some systems that are already in place and used elsewhere are to structure the way we work. And take it from there. So, again, talk to each of us, send mail to the mailing list. We welcome ?? we ask that you come with suggestions for content. Content that this committee is going to be addressing is the Plenary, the tutorials and the BoFs. For the Working Groups, refer to the Working Group Chairs. And one final word. On the screen, you are seeing an URL. It's a brief questionnaire. We are asking you to fill it out, and there have been some tentative changes this time around. We would very much welcome your feedback, by filling out this survey. I took it yesterday before it was announced and I timed it, I took exactly two minutes and 40 seconds to fill it out. It's not a big burden, so please try to to it.

And, with that, back to Rob, and thank you very much everyone.

ROB BLOKZIJL: Joao, you have been, for, I have forgotten how many RIPE meetings, the driving force behind the primary programme ?? since RIPE 49 ?? you can do the calculations yourself, and yeah, I know, a lot of people always contributed to the Plenary programme and there was this loose cloud of people who did it on a sort of regular basis, but Joao has always been the person who got it all together and who was driving you to come with good content. If you think now we have a more established programme committee that you will be are relieved from the task of getting, of participating, you are wrong. Instead of Joao, now hopefully you have eight Joaos knocking on your door. So keep contributing, but I think it is, it is appropriate and a great personal pleasure to say thank you, Joao, on behalf of all of us ?? don't go away ?? and we had two options: We chose something to represent our thanks, but then we realised that could only be a huge thing, which is not handy when you travel, so you can still choose a huge thing but we don't have the responsibility there. Enjoy. And we will see you on the programme committee. Thank you.
(Applause)

Next we have a report on the meeting network. And Eric is giving the report. It's always nice to see that the technical crew has everything working.

ERIK ROMIJN: I guess this is Murphy's law. Hello everybody, my name is Eric Romijn, I am the senior software engineering in the RIPE NCC and this is the technical report. Introducing our team. We have eight engineers, we have seven engineers and one manager from various departments in the NCC that come here three days in advance, do the set up, support the meeting and then tear everything down again.

Our responsibilities are are basically anything with wires except lighting, audio and stenography, there is a number of of local service doing DHCP, IRC, the registration software, the power blocks that you are all using, of course the network but also the printer that prints your badges.

We also have a few things that don't have worries, so we still have these around. I don't see them much anywhere else, but every meeting we still make a few people happy with the static IP address they can get.

The network setup this time is quite simple. We are in the Krasnapolsky, so there is a fibre directly to the NCC office on the other side of Dam Square. We used to have two routers and a VR P setup, we didn't do it this type. It's a hot stand by because it usually gave us more trouble somehow than it fixed for us, so we went for the simple set?up. There is three networks within, at the venue for, one for public, which we are all using and two private ones which contain the servers, the registration software, and things like this.

Downstairs in the basement, it looks like this, so this is after we come in and patch our stuff. It used to be a little bit cleaner. So, we use two Juniper switches and two Juniper routers, we have some spare as well. So, on the left here, all the patches is for the access points. And on the right I can see the yellow fibre going back to our office.

So, we also do a lot of creative setup, so where you might hear or see an emergency exit lighting, we see an opportunity for a webcam mount. And although this may seem like an emergency exit button, this is actually a way to mount a MAC?mini plugged into that very webcam.

So, we introduced an few set?ups at this meeting. We got some better webcams for the Plenary. This is the old model. You can see it on the right there from me and we replaced two of them with this, which you can see on the left here, and they have better optical zoom, they are better light sensitivity, so it means we get a less blurry and less grainy image.

We have also changed the plasma screen set?up. We used to put a MAC?mini or some other machine next to it which would then have to have a keyboard and a mouse lying around tall taking a lot of space and time. So on the back in the corner here, we have mounted a little device which takes a USB stick ands plugs into the TV, so we can just tape it on the back and it's a lot simpler.

We also added a LISP SS ID this time. This was a separate network so that you could experience LISP. There is been a few talks about it as well, but I missed all of them. And basically, on the slide you can see the router being installed in the basement. It's here, a little Cisco, and the LISP SS ID has got an up to about 80 users. This might not all be meeting people because it was open, there was no password, so, there are some other people in there as well.

So, a few issues we had during this meeting. We had to ?? we bought a new printer for the Terminal Room and we made sure it supported IPv6 and that it did bonjour and things like that, but, unfortunately, over bonjour it will just hang and your Mac will wait and re?try over IPv4 after the usual one to two minute time?out and then print over v4. The solution for now is, unfortunately, to disable IPv6 on the printer, but we have a case open with HP and hope that they will fix it for the next meeting.

We also had some issue with IPv6 connectivity. There were a number of unrelated problems which, altogether, caused issues. The LISP router that I showed you earlier actually sent R8s for awhile. We tried to disable them but then got hit by a MacOS bug which prevented this from happening. There was rogue RAs from a Windows box, which is very rare. That, apparently, still is in the network. And we think we have some issues in multicast traffic but we haven't pointed those down well yesterday. Basically the IPv6 debug is strictly for v?cast. When you are debugging things like people not receiving a router advertisements, it could also be the wireless so you never know where to look and most of the problems we have seen, they are very intermittent, so by the time we get most complaints, the problem is already gone, and only reappears after we are no longer with the person who has the problem.

To show you something that we ran into. We sometimes take more time to debug IPv6. This is something that got us confused for awhile, had absolutely nothing to do with any problem that we had. It's the NDP cache on my laptop, and, of course, here is the entry for a router, and it has an expiry, but this expiry timer runs from 24 hours, runs three minutes down, then jumps to 5 seconds, expires, jumps to 40 seconds, expires and goes back to 24 hours. So if you think you may have an issue with NDP caches, then if you run into stuff like this, it does puzzle you for awhile. I still don't know whether this is normal or whether this is a bug or whether we haven't pointed any problems words to this specific thing.

So, we also had rogue RAs from the LISP router. Basically, it had its own VLAN separate from everything else and it used the public network as its up link. It used one of the packs that I showed earlier for static IP, IPv6 also configured and what it then does is it waits for the RA to come in from our router, takes that address and then says, oh, I have an address, I can now become a router, too. And it will send out RAs. Of course, you can suppress them, so we did. But that only blocks the solicited routed advertisements. Every time a Mac connects to a network, it does a router solicit, which makes discount solicited router advertisements and they are not stopped. So, other work around, you just set a lifetime of the RA to zero, this is in the spec. If the lifetime is zero, cannot use this router, despite receiving the advertisement, which unfortunately does not work in MacOS. So, eventually, we went for the quick fix, which is we disabled the IPv6 in the interface, which is okay, because this was LISP, so people behind the LISP network would still be able to do v6 traffic because it would be encapsulated inside the IPv4. I understood later that a fix would be to suppress the R8s and then build an access list that would prevent the router from receiving routes from this list. That would be the only other work around. This is already done by Apple and will be fixed in lion, so...

Another rogue RA problems which showed up a few hours after we fixed the first one was somebody on a Windows laptop doing 6to4, probably Internet connection sharing. Nobody should be affected by that because native should be preferred over 6to4, we are not sure whether that happened everywhere, we have a few vague case where is it may not have been the case, but nothing clearly reproducible.

It's also very hard to find ?? you think that a Windows laptop in a RIPE meeting is easy to find, but we couldn't find it. So, we went for another solution to make them find us, and ?? so they haven't approached us yet, so if you have a Windows laptop and you no longer can get IPv4, then you might want to disable your Internet connection sharing and make many other people happy.

So, the trickiest issue we found was that there is an issue with multicast, we think. There is the effect, basically, is that some people don't get an address or they get it very late, or, once they get it, they can't reach first hop. Not everybody is affected. And it randomly appears and disappears. So, we have, in one case, been able to reproduce at one of the access points. It did pass some but no RAs while we were sure they were on the network and that wasn't at a busy time at all. That was in the evening, so, we don't think it was simply filling up the wireless multicast channel. But something more complex. In this access point it went away after moving it to a different patch. Which of course also rebooted the access point. We set the switch board, so, either of these could have helped the problem. There is definitely also a lot of multicast DNS traffic, more than half of the multicast traffic on the network is multicast DNS. So, I don't know whether they are just simply a threshold where, at some point, even though it not being too much, the access points get issues with it. We'll have to do further investigations and, of course, suggestions are welcome.

Another thing we noticed is that some newer Mac Book Pros, the very latest model, some of them seemed to drop off our wireless continuously and the report, we felt, was it's fixed if you frequently send pinging to, basically, anywhere. Other traffic doesn't help you. We haven't been involved in a lot of debugging with this, so I don't entirely know where this comes from. I hope it will be fixed in newer firm ware from either Apple or Cisco.

So, basically, based on the experiences from this time, for the next meeting, we'll be looking at filtering IPv6 RAs, possibly also with finding a fast way to block people off the wireless in case they do rogue RAs, because, as far as we have looked so far, the access points themselves cannot block the RAs, so we could block it on the switch, but if you are on the same access point as this Windows user, you will still get his strange addresses.

And we'll also, if if we find that the level of multicast traffic is somehow causing problems for the access point, we'll be considering multicast DNS filtering in some way.

Also, making our debugging more complex is the fact that some of the patches in this hotel are very long. Some of them are up to 190 metres, which doesn't really work for Ethernet in our case, so this is a case where we had to use a patch panel further back in the room, but needed a network in the front of the room so the only solution we could do this is by putting switches inside the panel to reinforce the signal.

So, looking at some statistics about the meeting. As usual, we mounted a GPS antenna somewhere on the hotel; in this case, on the window of the ops room. The box that says don't move is keeping the window shut because the cable was too thick, so it hang from the outside of the ops room here. And if you were in Rome, you might remember that we had a GPS antenna also mounted in a rather unusual construction, right across from the American embassy, which was next to the hotel, and that didn't give us any problems. So, I was thinking that this time, as the opposite of this window is the back of the shopping centre, I thought we wouldn't get into any trouble, but a few days later, on the 4th of May, in the evening, suddenly all these people showed up. So, looking at the TTM observations, there is nothing too unusual. All the IPv6 for TTM is working. There is some usual stuff ?? there is a few boxes on which we actually find lower IPv6 than IPv6 latency. Most of them are still higher, unfortunately, but there is an example where v6 connectivity is actually slightly better.

So, looking at the stats that DHCP server gives out. 60% of the meeting network is Apple, which includes all Macs, iPads, i?phones, and so on and the first follow?up after that is HTC, which manufactures smart phones only. So, you can imagine the earlier problem I mentioned, a problem which only occurs on Macs does not immediately jump out as being Mac only.

For the up?link traffic, we have picked about 50 megabit, 9 megabit out. We had a gig link, so we are still pretty safe. Comparing that to IPv6 traffic, we can see that, this time, 17 percent of the meeting traffic was IPv6, despite having some issues.

So, last time I also made a graph predicting exponentially and linearly, based on the last few meetings, how it would develop, and this is actually very close to the exponential growth mark, it's just a little bit under compared to last meeting, so if we take this meeting now, then, basically, at about RIPE 66, we should be completely IPv6 on the meeting network if we continue our exponential growth. Growing linearly, we will have to wait until 76.

For a wireless this time, we deployed 20 base stations, that's mostly because this venue is more exact. A record peak this time of 450 associations. It looks like we have having a lot more smart phones on the network right now. And, as usual, we have applied our high density access point distribution, so, if you are sitting on a chair that's slightly warmer than the others, this is the reason...

I had just ?? only just noticed that there are people sitting in the back on the floor and a lot of people standing in the back there. There is an entire row of seats there clear, there is nobody there which happens to be one of the rows with an access point. So...

That pretty much rounds it up. I look forward to seeing you in Vienna, and, in case we have any more issues with RAs, we will be providing a backup mechanism for IPv6 address assignments.

(Applause)

ROB BLOKZIJL: Thank you, Erik. Owe lay has a question:

AUDIENCE SPEAKER: [Ole Jakobsen], in this case representing the IAOC, which is the administrative arm of the IETF. I wonder if you had considered bridging your network into the hotel network wireless perhaps with or without the blessing of Swisscom. At our Maastricht meeting of the IETF last year, we didn't do that and then after a couple of days we had to do it because their network melted down. It would have been really nice to have wireless in the rooms as well. RIPE should be a fairly good client of this hotel by now, or even Swisscom.

SPEAKER: I think in the past, for meetings, it has been considered but hotels are not always cooperative to do that. That's actually a question for Camilla and Nick, who do the negotiations with the hotel, to take that on board as a suggestion.

AUDIENCE SPEAKER: Fernando. I am one of the people, users who have problem with the new Mac Book Pros, and I discover another solution it the problem and it's not ?? disable IPv6. If you disable IPv6, there is not more dropouts in the activity. I don't know why.

ROB BLOKZIJL: Okay. Thank you, Erik, and thank the whole team.
(Applause)

I don't think many people of you know who [Juergen [] Rausenbach] is. Earlier this week, I got the sad news that he died last week. [Juergen] was one of the very first participants in RIPE and RIPE meetings, this was in the late eighties and the early nineties, where one organisation that was extremely active in campaigning against the introduction of the TCP IP stack in Europe was the German research network, DFN. So, they got to hear about these rogue people who were having meetings in Amsterdam and I decided to send a representative from DFN mainly to find out what the enemy was doing, and I sent Juergen. It took Juergen only one RIPE meeting to come to the conclusion that it was great what all these people were trying to do. So he went back to DFN and said we should do the same. Well, it took him a couple of more RIPE meetings to get the message inside his organisation across, but I just wanted to mention him in this meeting. I can also tell you that we, later today, sent a card to his family offering our condolences as a community, of which he was a very important member many years ago.

RIPE 62: We have seen at various moments this week that things can be crowded. Well, RIPE 60 we had 427 attendees; 61: 430; and RIPE 62 is the winner with 463 attendees.

You folks have set a new record.

Newcomers, old hands, distribution, you can see that about a quarter is newcomers. Newcomers, of course, come in two flavours. Newcomers, as in my company, has never heard of this RIPE, and I convinced my boss I should go and see what it is all about; and newcomers, just a new staff member in an organisation that is a regular attendee, and I think, Nick, I would like at one time in the future to see whether we can sort this out. Just for interest.

You came from a lot of different countries. As could be expected, the local country, the meeting country, the Netherlands has a fairly large blob, but it is, I think, a healthy distribution.

You are from different types of organisations. This is coming from the registration forum, I think, where you indicate who you are.

It has been presented by Paul Rendek, in the NCC services Working Group, I think ?? in the Opening Plenary, of course, but that's such a long time ago ?? the RIPE NCC is about to start membership and stakeholder survey and Nick will give a few words of explanation.

NICK HYRKA: Nick Hyrka, RIPE NCC, Communications Manager. If you were here on Monday, you did see the presentation from Paul Rendek from the RIPE NCC, and Desiree, where they introduced this new survey. Every three years, the RIPE NCC holds a new survey; this is the year to do it. We find the analysis document that we get, the results from the survey extremely critical for evaluating the services that the RIPE NCC provides and the activities that we do, and also plan for the strategy down for the years ahead. So, I cannot tell you how critical it is to have your input.

As I stand here, I am going to wave my hand, they are going to make this now live, so this survey is now up and running and will run from today until 10th of June. What can I tell you? All of the information that we receive, that we don't receive it, but all the information that is given in the survey, whether it's your company data, etc., is all confidential, everything is anonymous, the RIPE NCC has nothing to do with that. All that information will go to the Oxford Internet Institute. Desiree will oversee the analysis and the research done on the survey, and then the results will be presented at the Vienna meeting, RIPE 63.

To get you all encouraged further to participate, we have a few iPads to give away, so there will be a drawing of someone, an early response, so anyone who responds before the 16th of May will be in a draw for the first iPad and the rest will be chosen at random by the end of the survey period.

I think that pretty much covers it, but honestly, we really need your input. We have two tracks, one for the membership and one for those people who have a vested interest in the activities and services of the RIPE NCC. Please, please participate. Thank you.

ROB BLOKZIJL: Thank you. To give you time to have a very careful look at this URL. Next on the programme are a few prize draws ? two, to be correct. The first one is from the NCC Services Centre. We had an NCC Services Centre open for the whole week and many of you took the opportunity to meet the services team, discuss your problems, if you had them, and after your interaction, you got a lot, and now we will do the draw, and Anna will do the draw and read the winner of something.

Number 67...

More prizes. We always like you to register early, that makes life easier for the people who do the planning of the logistics for RIPE meetings. So, in order to encourage you, we give away small prizes for the first three to register and still is in the room here. And in a very scientific way, I start with registration number 2, because I have one, but that is a feature of the software. Number 2, you can find your registration number in the right?hand top corner of your badge where it says "RIPE 62?something" and number 2 is Flavio Luciani. Is he still here? Bad luck, Flavio.

Then we go to the next on the list, that is registration number 3, [Imar Bintz].

Next prize goes to number 4, oh, Sergey Myasoedov. I saw him earlier this morning, I think. Sergey, where are you?

And the next and last one, Paul Hoogsteder.

Congratulations. Folks, if you think this is not fair, appeals will be received till the start of the next RIPE meeting.

Right, I think we are getting very close to the end. There is one more report I have been instructed to give the floor to a representative of the secret Working Group. For those of you who are real newcomers, this is one of the most important parts of the whole week.

REMCO VAN MOOK: While I am setting this up, you all know that I am here against my will and previously another tall Dutch person was doing this, but he managed to get out of the country again. So, I am here and I am back here again, which is very unfortunate for me and my family. I hope you sympathise.

So, this is the report of the secret Working Group and I have to say that some people apparently don't really understand what the secret Working Group is about.

This is very secret...

ROB BLOKZIJL: Secret Working Group group, thank you whoever you are. It's not those guys, they were just sent to report.

Right. A couple of things. In the first place of course, I'd like to thank you our sponsors, various activities around the RIPE meeting take place with great support from our sponsors, and here you see them all, they have been on the front page of the RIPE website for the whole week. AMS?IX, Juniper, Intradata, Intersection, Brocade, Telecom Italia, Sparkle, Efficient IP, network hardware resale. Thank you all.

You may have noticed from the previous speaker that there is a RIPE 63 meeting coming up in Vienna in October, 31st of October to the 4th of November this year. And I would like to invite Christian, who is ?? who represents our local host in Vienna, who would like to say a few words.

Christian: Thank you Rob, and thank you, Remco. After his marketing presentation, there is nothing more to say. I am very much looking forward to be part of the local host team for Vienna, after 12 years again, so RIPE 33 was the last one in Vienna, 63 will be the next one and we are local hosting it in the Acronet research network context, the Vienna Internet Exchange context. Vienna Internet Exchange is becoming 15 years old this year, so be prepared for some celebrations and, of course, with with our co?local host, NIC.AT, doing the domain registry for Austria. So welcome to Vienna, looking welcome to welcoming you all in October later this year. Thank you.

ROB BLOKZIJL: Thank you, Christian. I think we are all looking forward to meet again in Vienna. Before I close this RIPE meeting, I would like to thank the RIPE NCC staff, all of them who have been involved in, yet again, preparing and running an absolutely seamless meeting. Thank you all very much.
(Applause)

And that's the end of RIPE 62. I wish you, if you are staying on in Amsterdam, a pleasant stay, and all of you have a safe trip home, and see you all in Vienna. Thank you.