These are unedited transcripts and may contain errors.

The plenary session commenced on 3 May, 2011, at 9 a.m.:

ANDY DAVIDSON: Morning, everyone. Welcome to Tuesday at RIPE 62. Today's is a special day, we are going to have series of presentations all about IPv6 in preference to the usual IPv6 Working Group, so if anybody here hasn't heard of IPv6, then welcome, but this is likely to be very, very instructive and I suggest paying a lot of attention. The first presentation is from Gert Doring who is going to give us an update on things he has seen in the IPv6 routing table. Over to you. Thank you.

GERT DORING: Good morning, everybody. Thanks, Andy for the introduction. This pretty much is going to set the stage for today's discussion, give you background, what is going on, look at routing table growth, look some bit at regional distribution, what is happening in which regions and which countries, always with the routing table angle two things, and some detours to allocations statistics and so on. So this is numbers and nice graphs and enjoy your coffee and start slowly getting awake. I am quite happy to see a good number of people here at 9:00 in the morning. I have to be here; you will here voluntarily, so good morning, welcome.

This is what is going to be in there, numbers, pictures, trends and some things that maybe should not be there, some rambling from my soapbox, some examples how to improve things. The slides are on?line, so some of the slides with lots of numbers in there, we are not going to much detail due to, it's not that interesting to to it up here on stage but if you want to look at the numbers in more detail, feel free to just go there.

So, first thing is just looking at the BGP table and what is in there. This is pretty much as it is today. Or as the growth has been over the last 9 .5 years, which is the time we have been collecting this. If you look at this some nine years ago, it was really like 200 prefixes in the global table so you could know each prefix by first name, and sometime around 2007?2009 people have noticed there might be something with IPv4 runout and in the last couple of months people have really realised that oh, we are serious about IPv4 runout, so you see the growth has really taken up.

Zooming into the last six months, the curve is pretty much not very spectacular because the bend is sort of like here and you can't actually see it, if you just look at the six Mondays. Months. What you can see here is a funny bump where, all of a sudden, 300 prefixes appeared, and disappeared again. When the table was down at 200 prefixes and somebody leaked 10 prefixes and withdraw them, you could see it quite visibly. These days if somebody is leaking and withdrawing 20 or 50 prefixes you hardly can see it on the scale, but over 200 prefixes is very well visible, so that was interesting enough to look into it and I am going into detail on that specific one on a later slide.

When I did this talk last time in the end of 2009, I did some quad rat I can fits to try to extrapolate the growth, that is the greenish line here. The fit was done something like here and the amazing thing is the fit curve matches the real growth quite well until about Jan this year and then wave very notable bend in the curve and the growth really goes up and I think this might be somehow related to IANA event going out the last /8s and some people realising that, no, this time, IPv4 runout is really for real; maybe we should get the v6 thing now.

I have tried to do a new fit that sort of takes the new data into account and try to extrapolate but the problem is if you have a curve like that, like this, then off you go. It really depends on what data sample you use for extrapolating, so if you start with the data here, you get a linear curve that goes like this, which is not very realistic. If you start like here you get a quad rat I can curve like this which is also not so realistic, so I decided to abandon that effort for now and we will look into this again at the next RIPE meeting and try to do some more extrapolation and see how it goes. But really, if you have a curve like that, that changes behaviour quite drastically, any sort of numerical fit is difficult, at best.

Zooming into the routing table again and splitting by RIR region, we get that one, which is mostly what is to be expected coming from the previous years. The RIPE region has the highest number of prefixes, which is not surprising as the RIPE region also has the highest number of local registries and lots of countries, lots of small ISPs and lots of routing table things. Then, there is ARIN, LACNIC. ARIN APNIC, the two bigger registries and well?established. And you can see LACNIC and AfriNIC also gaining momentum, which is very good.

This one over here is the artifact that has been on the first slide, as well. So you can already see it's coming from the APNIC region.

Zooming in even more, this is by country in the RIPE land, also nothing very new here. Germany is upfront, which is, again, mostly explained by ?? we have the highest number of local registries in the RIPE land, so it's to be expected that we also have the highest number of v6 activity in there. Maybe wave little bit more v6 than just the raw numbers, but the overall balance is pretty much OK.

Britain and Netherlands next, then Russia taking up quite visibly, that is that curve here, and then the usual suspects from rest of Europe.

I am only showing the top eight from the registry statistics because showing all European countries which would just give you a very colourful graph that you cannot see anything from.

Looking over to APNIC, it's pretty much the usual suspects, Australia, Japan in the top, and there is interesting things coming from Indonesia, that is the curve that goes up and down all the time. I did not really investigate who is doing this; it seems to be a couple of different networks so I expect that there is some sort of peering going on with more specifics being exchanged on the peerings and every now and then some of them just announce the more specifics to the up streams as well and then they are visible in the global table. It's a fairly noticeable bump, but that is not actually the really big one you see on the first slide. The big one is coming from Vietnam, which is not in the list of countries here, so it's not on that slide. That sort of like the selection which countries to put up there is done by the number of assignments and allocations to that country, so if a country has a low number of allocations, but somebody is leaking 5,000 prefixes, they might not show up on that slide because, well, the country gets sorted out earlier in the process of digesting all these numbers. So I need to tweak the scripts a bit to maybe better see the interesting things there.

ARIN is not very interesting. You have USA and Canada, and a couple of other things that show up in the registry statistics, but sort of like are down there between 0 and 5 prefixes each, but actually, looking up all these country codes in Wikipedia was an interesting thing, to see what countries really belong to ARIN region, but they are so small that they don't show up. LACNIC, progress but small. AfriNIC, also progress. The reason why I had AfriNIC here in the first place was that when I prepared ?? that talk was presented at the last ARIN meeting, at NANOG and I wanted to see whether Egypt has really dropped from the v6 table as well when they had these political troubles, and indeed they had. That is down here, Egypt falling from the v6 table. The interesting thing is that Egypt has been very active on the v6 table before and after that, but that is completely unrelated to the political unrest. Political unrest is the small bump down from something like 3 to 2, down here, and not the bumps up to 22.

Looking at the data from the AS numbers angle, here is, well, data to look into it in more detail, how many ASs are there, some ASs are announcing, one prefix, two prefixes, three prefixes and more of that. These numbers are not perfectly accurate because my measuring box is showing one AS that is announcing 67 different prefixes and when I looked into it, OK, who is the culprit? The tool said yes it's this AS 23456, so I hear you laughing, that is an oldish box, no support for 32?bit, 67 prefixes being orangeinated by 32?bit ASs, and that is distorting the the measurements because the box says it's a single AS that is really announcing a hell of a lot of prefixes, but they should be most likely been to the originating one prefix. So I promise that for the next time, the collector machine gets upgraded to something that knows what 32?bit numbers are and I have completely accurate stats then.

Numbers, graphics. This is, well, the expected growth, if you have the table growth for the prefixes in mind, the growth for the number of active ASs is unsurprising. Most of the ASs are originating ASs; some are transit ASs; some are transit and origin, and that is pretty much to be expected.

We are up to 3,700 now which is a fairly nice number given that we started at pretty much zero.

Detouring to the iBGP world, this is a number of active ASs in the IPv4 world. The curve looks interesting because it's linear; it's really like a straight line going up there and it's still growing in a linear way, ways very untypical curve for Internet thingies, normally they go like this and sometimes like this, because something is full, but this is just straight line, and they are still strong growth in the v4 BGP world. If you look at the curves, that is typical Internet curve, goes up like crazy, and this is just not.

The reason why I have the v4 BGP here is because I want to put them into perspective and see what the ratio of ASs with v6 to ASs with v4 is. So that is the number of ASs that have ?? that I can see in the v6 table, divide by the number of ASs I see in the v4 table, and we get something like we are up to about 0 .1 there. The curve looks nice and it looks like we are finally succeeding, we are up there at the top of the curve but just ?? that is just a way on how you plot it. If you plot it like this, this is what we really should reach. One means every AS out there has v6 and v4; somewhat idealised, or the same number of networks out there have v6 and v4, so this is the goal and eventually we should have more networks with v6 than v4, and we are down here. So there is a bit of work to do.

Summarising this again: So nice growth but not growing fast enough. If I had nice pictures of train wrecks available, I would put a picture of that here. More work to do.

Looking at some other relationships, looking at the number of prefixes on average that an AS number announces in v4 and in v6, I can see that a typical ?? no, an average AS in v4 will announce just below 10 prefixes and in v6, it's something like 1.4.

Some of the numbers are wrong. It says 10 .5 here and that line is just below 10, so I don't know, too much beer, too little sleep. But still, there is a noticeable difference and if you divide the numbers, you see that if it keeps up like that, the IPv6 routing table is going to be a lot smaller because if everybody is announcing just 7 times less prefixes, the whole table will go down by a factor of 7, if the same number of ASs become active. So this is a given chance to not explode the routing table in v6 and I hope it will basically stay that way and not become polluted by, say, thousands of deaggregated prefixes and stuff.

Short background: If you wonder why people are announcing two prefixes instead of just one, some of this is due to deaggregation but most of the ASs that actually announce more than one prefix have good reasons for doing so, like having disting networks, customer prefixes that they announce in their own address space or, in some cases, these guys really have lots of different locations and have a provider?independent block from ARIN there and announce a different block from each location so it's really like it's not a a single network that is announcing all this but they have lots of different network announcing different ?? they look the same AS number, one need to look carefully before screaming. These look all pretty legitimate, to me.

Prefixes, that is one of the horror slides with all of it are numbers. This is more reference material. There is one interesting bit here, here is that is somebody is announcing a /12 in the global table. He was standing up here yesterday and said I have been announcing this and nobody complained. I didn't complain, I ran my script and it fell over and said somebody is announcing somebody funny and the interesting thing is my script /12 was not coming from no one networks so it was sorted as other and I looked more closely, I looked at the AS and said oh, it's Geoff, it's fine with me.

(Applause)

Well, they are some known researches out there and, yes, so it's necessary to send a mail. I know he is and he knows what he is doing so fine with me. If he wants to get all the traffic.

Again, looking at the prefixes from yet another angle, graphic by size of the prefix, to see what is contributing the majority of prefixes in the table, it's really like, oh, my God, we have opened the floodgates and PI is going to kill us all or whether it's really like the majority is provideers out there, we see that this line is 32s, which is to be expected, and I am quite happy to say that, well, the floodgates have opened a bit, but we are not swamped in 48s, so that is the 4s here. There is a good number of them but it's not like we have ten times as many 48s as 32s and I think that ratio sort of makes sense.

Down here is something between 32 and 47, which is largely PI blocks, deaggregates from the 32s, 35s, stuff that is there but then the numbers are, I would say, still under control; it's something like 700 in total. This is something even my old routers can handle so I am not worried too much here.

From the BGP table, I now go into allocations to see whether ?? what I see in the BGP table is actually reflected in the allocation statistics from the registries. This is also sort of checks like whether PI assignments are sort of like going out like crazy, completely unbounded and you have solid lines here, this one, this one and a few down here. The solid lines are the LIR allocations, 32s or bigger going to provideers that are supposed to aggregate lots of customers and the dash lines is the [(]froze) portable assignments, PI stuff from the different regions and you can clearly see that the majority is still LIR allocations and here is the ARIN PI, which is coming up fourth. I am not saying this is good or bad; I am just presenting this and I think it's not a problem, so there is nothing we immediately need to do about it. Keep an eye on it and if one of the curves goes crazy, then it might be useful to do something, but so far, I think we are in good shape.

This is comparing the allocations to what is actually in the BGP table. The solid line is the number of allocations in a given year and dashed lines is the number of prefixes that I can see from that year ?? from that year's allocations in the table the next year, the year after that and year after that, so in 2009 we had some thousand allocations. In the beginning of 2010, I saw something like 300 in the global table and yesterday I saw something like 500, so half of them are still not there. And this is something that goes on to ten years ago. Quite a number of of allocations go out there and are never seen again, which is not so easily explained, given that allocations are really something that wants to be in the global table because people want to use it to number their customers. This is not PI space that might go somewhere in closed networks, where it's really not visible on the global table, but this is allocations and my assumptions for the years has always been this is sort of like people getting prepared or getting a prefix and then organisations structure changing, not having time to startly start the v6 deployments and so on. We will see how that evolves in the next years.

Breaking it down by different classes, like how much percent of the PI space is visible, how many percent of the LIR exchange point allocations and different at categories are there. More reference material no time to go into that right now.

Something else I always find interesting to see is huge allocations. You know that by default, a provider can get a 32 with no questions asked, which is perfectly fine for small to medium?sized ISPs and hosting set?ups and everything, but for a large DSL provider, cable provider, this is just too small and so we have occasionally seen larger than that allocations in the last year, in the last ten years and in the last year, these numbers have really gone up. This is just for European ISPs, and I see most of the big national ones like mobile providers or DSL providers, in that table, so things are really picking up speed now, which is a very good thing.

Weird owes. I am running out of time. I started giving this talk nine years ago because I was talking to David Kassans and said I have seen very weird things in the BGP table and shouldn't we tell the Working Group about it? And he said, oh thanks for volunteering to give a talk about that. I said oh, my God. Anyway, this is one of the findings I had, actually in Jan of this year already. This is 2008, which is very much upset my script because the script said you need to investigate, I don't know which region this is coming from, I cannot properly plot it. I said, oops, 2008, did I miss something? Checked the data and 2008 is not just allocated yet, so 2008 doesn't belong to any regional registry. So I tried to figure out what sort of mistake happened here, and if you go to the AS number here, and play with the numbers over here and check that number, 2008, 100 instead of 2008 you see the same name showing up on the network and AS numbers so the assumption is it should just be 2800, and what is missing in that slide is actually the bullet?point that I put in this morning but didn't upload it here. I mentioned this to AG Net yesterday and 30 minutes later the prefix was done so people are acting if you tell them about it but I would actually prefer to have transit networks have filters in place to not accept that in the first place at all.

More things, that is the 256 prefixes bump that was clearly visible in the global table, that is coming from Vietnam, and I think that is not actually a weirdo in the sense that somebody is polluting the global table. Looking at the AS numbers, it's more like from the vantage point where I have been looking, this looks weird, but maybe nobody else has actually seen it because that is the originating AS, that is some company in Saigon that obviously set up their network with 32 and lots of individual 48s in the routing table. They announced it to the Vietnam Internet Exchange, also Vietnam Internet Exchange; that is APNIC research Japan and that is Telstar and they give me a full feed to actually see how things look from Australia, so looking at these specific AS numbers, I think that might have been a test or research, or whatever, so that might not have been visible globally, so a bit careful about finger pointing here; it might just be something that I saw. But still, if you set up your network that way, don't announce the 48 everywhere; just announce the 32, that is sufficient.

That is another nice beauty I saw. Prefixes starting with 1, 1 is completely outside all the RIR regions, so even a very basic filter that says, if it doesn't start with 2, drop, should have called us. I have the nagging suspicion that this is actually a router bug because I see numbers coming back. This is one A, F0 ?? 1A F0 and that origin network also has 2620: Is AF 0 (1) so maybe it's really like something in 6 PE got messed up and produced really weird prefixes. The thing is not so much that bugs happen, but what I am more griping about is that certain transit networks just accept this and transit it. So long story kept short, problems at end sides do happen but I think it's due diligence at transit networks to make sure that typos, bugs, whatever, don't propagate worldwide, so BGP filtering can be done and should be done and, well, I think it's our job to make sure our customer mistakes don't propagate.

That is another beauty, one /24s, one /120, 127s, in the global table. There is a saying in routing that most specific wins and obviously this is the winner.

Briefly, looking at Route?6, the RIPE database has had RPSL support for IPv6 since six years now and if you look at the number of routes from the RIPE region, the number of Route?6 objects in the RIPE database, we actually have more documented routes than we have actual routes, which is a bit unexpected. So, I decided to look into this and so where is this coming from? It's a lot of data, so you need to massage it a bit and clean up stuff like 2002: /16, which is originated from different prefixes on purpose, so this is artifacts again. If you clean this up, you have about 3,000 unique prefixes and, of course, all the BGP data. This is what I found for nearly 2000 prefixes: The documented prefix, documented origin matches what is in the BGP table, which is very good. We have some prefixes that have no Route?6, which is not so good. We have some prefixes that says this should be announced by AS 1 and in reality, it's announced by AS 2. This is very bad because it breaks people's filtering and you cannot then rely on the data and people will start manually overriding filters and more mistakes happen there, so don't do that.

We have 800 prefixes that have no documented route in the RIPE database. This is all just RIPE prefixes so I didn't look at the global table here, just the RIPE region data because getting the data from APNIC and ARIN is something I hadn't time to figure out yet, how to do that, so I plan to look into this more into detail but, for now, it's just RIPE.

We had some documented prefixes from other regions in the RIPE database, so one at 55 prefixes from other regions actually have correct Route?6 object in the RIPE database. Most of them have not, which is to be expected. They are documented in their home database and not in the RIPE database. A few mismatches, somewhat inconsistent announcements, but overall, it's not that bad; more work needed but good start.

Then, some few examples of the different categories, and I am nearing the end of the presentation, I see Andy looking at me. The question is, why is there no Route?6? One reason could be it's actually leaks, so prefixes that should not have gone to the BGP table in the first table would nicely match not having documented routing policy for them. But then there is 32s and I assume that these guys really want to announce the prefix, so they should better document it.

Then we have the other category, there is a Route?6 object but the prefix is not visible. I think those can be split in at least two different categories. These very much look like they are announced inside some research network compound, but not visible on the outside, so the fact that is there doesn't really harm anything and if they use it for internal filtering building, it makes sense to have the routes documented somewhere. I was just surprised when stumbling across it the first time. These are more interesting, this is sort of like, okay I have the 32, I get prepared, do everything in the database, document my routing policy and then we will eventually announce the prefix, so this got put in there in 2005, 2007, 2009, 2005 is a bit ago for getting prepared to announce my prefix, so makes you wonder what happened there.

Some mismatches. This is really something people should work on, like having the prefix with one origin AS in the database and in the BGP table with another prefix. This is not good. It could be a hijack, it could be typo, it could be documentation problem, but you cannot know and as soon as people start filtering really strict, you drop from the table and you don't want that.

This is how a Route?6 object could look like. It's really pretty straightforward so there is nothing preventing you from putting one in there for your data. This is another example that shows how to actually query the RIPE database for the Route?6 object. No need to go into details here; it's all on?line in slides. The tool is available from here, that is BGP Q and you just tell for that AS set, please build a v6 prefix list and then you can use that prefix list on your routers and filter your customers properly. It's really straightforward.

And that is basically it. So, if there is something unclear, inaccurate, whatever, please let me know, right now or by e?mail later on. Rudiger, please.

RUDIGER VOLK: Good morning, Deutsche Telecom. For the ?? for your slides where you are looking at routing registry stuff, I would suggest to start to also track the RPKI ROAs.

GERT DORING: Yes. Next meeting.

ANDY DAVIDSON: Any more questions for Gert? I just want to say I thought that was really very full and an enormously useful set of information, so thank you so much for preparing that and distributing that to us all, that was a very complete examination, thank you. If there are no more questions, then I think we should show our appreciation. Thank you.

(Applause)

GERT DORING: Thank you.

JAN ZORZ: (Jan Zorz)

ANDY DAVIDSON: So now we have a presentation on IPv6 and mobility systems, so over to Jan for presentation number two. Thanks.

JAN ZORZ: Good morning, Jan Zorz from Slovenia. I was asked to present our Slovenian proposal to European Commission about implementing the IPv6 mobility, basically it's dual stack mow bill IPv6 in emergency response teams and public safety.

So, today's agenda: Politics marketing and it's all about European Commission pilots and later on I will tell you what, in reality, we want to do.

So, European Commission decided to fund one big project that consists from four or five experiments for Member States from European Union and it's 50% founded. They decided to give out 3 million euro and we are running for that money. It's five experiments, at list one must be cross?border. And it must be a real IPv6 deployment, not just papers and research. It must be something that you can log in and ping it and things like this. So otherwise I would not be here talking to you, if it would be a research and just papers.

So, what exactly we want to do. Later on, there will be nice picture of high level overview of what we want to do. What we thought was, when these guys, when a natural catastrophe happens, I don't know, flood, fire, like Japan, like many other places, when these guys goes out and try save the property and the lives of people, they don't have time to try five devices, which one can connect to which network and try to communicate over it. They must have one device that connects to every possible transport and can be reachable from the operations centre. So, we use this IPv6 features that are quite obvious, so we have seamless connectivity, so we can connect over GPRS, over UMTS, satellite, TETRA, I don't know how many is familiar with TETRA, it's army and police network, and this device that this person carries with him can connect to every possible transport.

So, and this must be all automatic, so this guy who is out there helping people must not take care of how his device connects, right.

Of course, we need to secure the data and we need to have some quality of service. It's hard to speak about quality of service in the circumstances where there is a natural disaster and everything is broken, but we need to think about that, right.

So, not so obvious, IPv6 feature, that we want to use, is an overlay network for data transport done with DS, TLS that knock I can't is building. I saw sewn I can't here, he is original author of this RFC draft. Why DSM IP 6?TLS because it was found out IP Sec is not the best possible way of endescription for mobile IP and he only came out with the idea of securing the transport with TLS and I have working devices, I have the prototypes and also the home agent back in Slovenia and it works perfectly. I will show you the picture later.

So, the high system level view is, we have national emergency control centre and the guys who are on site. So, national emergency control centre can connect over here or over here. They don't care. The guy on the field is reachable all the time. They can engage his GPS, they can read the hit centre on fireman clothes so they can create hit map of the area if there is a fire. They can do whatever they want. With mobility in place, it's in Greenfield for application building, just your imagination and sky is the limit. What can you fetch from the guy that is on the field? Right. And the good point is that his IP is always the same. His home address, his IPv6 and IPv4 address is always the same and it's reachable from the national emergency control centre, so national emergency control centre can coordinate the action much better than they can do it now.

So, about dual stack mobile IP: We have it in Slovenia, I am running around the world and I carry my home address with me; it works perfectly. Currently, it's working on Nokia 900 phones but we are building in Slovenia the device that will connect to all these networks and will carry around DSMIPv6?TLS implementation. So how this works, very briefly:

This is home agent, it's ha.go6.si. And we hand out IPv6 home addresses and IPv4 home addresses and we hand out the public IPv4 home addresses because we don't believe in not.

This is the mobile node and when I'm in my home network, I received ?? I receive the packets directly. When I move out of my home network, I carry my IP address with me and I just connect over the tunnel to home agent back and the correspondent node that wants to communicate with me, just sends the packets to the home agent and the home agent redirects the.packet back to my mobile node, wherever in the world I am. So next step is to do the route optimisation, so if correspondent node can understand that I am in a foreign network and when I send my care of address in the binding update to the corresponding node, he can start talking directly to me. That is something that we still need to do and implement or Nokia have to implement in their DSMIPv6 implementation. And there is flow mobility and multiple care of addresses in this implementation, so I think it's more than good enough to deploy it on a field. So current testing shows us that it works pretty well.

So, as I said, mobile node on the field is always reachable. Mobile operators are not very happy with what we are doing because with mobility in place, the GSM number is not necessarily the only identifier of my mobile node. So my new identifier can be my home address, so you can call me directly to my SIP client and my phone will ring wherever in the world I am, and not being tied to mobile network and use only their data but instead that I am reachable in every network I am, maybe in wireless here, maybe in wired network somewhere else, this makes mobile operators quite nervous today. But, to get back to emergency response teams.

So we can call the guy via VoIP, we can check the temperature of firemen close sensor, whatever we want with his device remotely. We can do live multi?media streaming, we can send him the video, we can send him voice, we can read data. Really, this is, when you start thinking of it, it opens up the field of what you can do, actually. And it's done over many networks or transport technology.

So what is the intended outcome of this experiment:

With this in place, we need to deploy IPv6 in our governmental network, so we are enabling IPv6 over all the path, from the national operations centre to the guy that is in the field, so the good outcome of this is, or side effect, is enabling IPv6 in our governmental network. And also, the outcome of this experiment can be further extended to use mobility with employees of the government, so the guy from the government who sits in one office, can move around and use mobility as his identifier. So wherever he sits, if he goes for a visit to another ministry, he has his IP with him and all the security policy is the same for him. So this can be used as a personal mobility inside the government.

So, and also, of course, experiments will be used as a show case to derive best practices and guidelines and hopefully to enable IPv6 in all the governmental network.

That was quick.

Any questions?

AUDIENCE SPEAKER: Steve Kent, BBN. Earlier in your presentation you said that you found that IP Sec was not suitable for mobile IP use and that is why you chose to use TLS instead for security purposes. Two questions. One, what were the problems that you found trying to use IP Sec and two, did you mean TLS or D TLS so you could run a full suite of applications, not just TCP?based applications?

JAN ZORZ: IP Sec is not the best way to do it because its outer shell encryption. This is described in RFC draft in details from Nokia. It's really, really well described. I can send you a link later on and you can read it and it was found out briefly, it was found out that IP Sec is not the best way of doing it so encrypting the basically the signalling data with TLS and then optionally, also, the pale out with TLS is much easier and much faster. But you can read the ?? all the good reasons in the draft from ??

Steve Kent: The short answer isn't this isn't a determination made, you are going on the basis of what someone wrote and that is why you decided to follow this path?

JAN ZORZ: Yes.

Richard Barns: Jan, I was wondering why you decided, in undertaking this project, to go for an IP layer mobility approach versus an application layer mobility approach? I am thinking of things like Google Voice which provide a voice service across wi?fi and UMTS and satellite phones. Across IP aaccess but does it require changes lower down in the stack that run the devices that you can get things to. I am wondering if you had requirements to support many different applications or like web browsing is harder to do in a sort of mobile sense, so I was wondering why you looked more at a certain network layer mobility approach than application layer mobility approach?

JAN ZORZ: This is the question that we get often. If you go for application layer mobility, then you are tied to what that application can do, right? If you go for IP layer mobility, then you can think of anything you want in between your corporation centre, coordination centre and the mobile node. So you can throw over any application you want, you can connect over any protocol you want. You can build any application you need, right? If you do it with voice application, then you can just call the device. If you do it with something else, you can do just that. If you fundamentally change the way you connect to the device and you choose the IP layer, then you have a green field, you have an open field of you can do whatever you want, right? So we didn't want to tie our hands with just one or two applications with mobility and be done with it, right? Does that answer the question?

ANDY DAVIDSON: Any more questions for Jan? No, I think that is it, thank you very much, Jan.

(Applause)

ANDY DAVIDSON: And now Sander is going to present an update on RIPE 501, that's right, yes? There is no complaints, so I will take that as a yes.

SANDER STEFFANN: So, good morning, some time ago, Jan initiated the project that led to RIPE 501, a document for how to require IPv6 in tenders and things like that. So, basically, this is the summary what we have now, and we have a document that specifies what you should ask for if you write a tender for hosts, switches, routers, security equipment and also for software IPv6 support. And I must say that this has been very well received all over the world, but there were some issues with it. The most important one was this, the document contains a big list of RFCs with all different ?? for different kinds of requirements, and people didn't really know what to do with it so they could copy paste the list but I think everybody wants to understand what they are writing in their tender. So this is needs some clarification. And then we also had the problem that people said, okay but we have all these different types of equipment, but we want to do deployments with CPEs and have mobile nodes that we want to support IPv6 and there is nothing in RIPE 501 that addresses this, so this is also an area where we were asked to improve the document.

So, there were a few options we could choose: One of them was take RIPE 501, improve it, make it longer, make it more verbose, add recommendations and requirements for other types of devices, but this was little problem, that if we do that, then RIPE 501 will disappear and be replaced with a new document with a new number and a lot of people are already referring to RIPE 501, so we thought about it but then we thought about what are the other options and the other option is actually just write a separate document with the supporting nodes, so have RIPE 501 just specifying the core details and have RIPE something else for all the supporting nodes, extra information, things that you might help you in using the document.

So, in the end we thought that would be the best option and just leave RIPE 501, which is a good document, just as it is for now.

So, we decided to start working on a new document and I think Jan will continue here to describe what is actually being put into the new document.

JAN ZORZ: Thanks. So, there was a long discussion, we received many e?mails about what we should do in a follow?up to RIPE 501. I heard that RIPE 501 was translated in many languages and that governments use it. I heard that there was quite a bit of panic in few vendors because the big customers from Europe knocked on their door with a printed copy of RIPE 501 asking, do you comply? And so, yeah, that is great that people use what we do, but as you saw, the list of RFCs, they look cool to us, but they don't look cool to the guys that buys equipment that, writes standards, so we thought of a bit of wording, of definitions, what host this exactly in poor words not in high level RFC language. What switch is, what router exactly is, what is a security device, what is the firewall, and also we add in the CPE device and mobile node specification so we added wording about what exactly these devices are and how are they to be used.

So, what else is in the new document: We add the CPE requirements. There are mandatory RFCs and optional RFCs. We will also add mobile node requirements so when you buy a phone or when a big company buys a load of phones, what they should request in the tender and we have some mandatory RFCs and optional, basically we have been aiming to define the mobile nodes specification from GPP standards. We are not yet, we will need lots of your input in the RIPE 501 follow?up.

So, which are RFCs are optional and which are mandatory? I don't think this is the useful discussion in this room, but I would suggest taking it to the mailing list. We will also post a draft to the mailing list. It's now currently in early alpha pre release state so it's not useful for posting it to mailing list yet, but I think we will do it in one or two weeks. We really need your input, we really need your support and we really need very wide consensus on what is being done here.

So, what are the remaining questions? Any other feedback on RIPE 501, are there any suggestions how to improve it? Have we addressed all the concerns with what have been told today in the new version of the document? Is there anything else we should think of? We would really like to have your input. And the other questions are: Should we change RIPE 501 and get a new number or should we write the document that is as supporting nodes? So, if we decide to write a new document, should we split that document in two? Should we write the supporting nodes for RIPE 501 in separate document and CPE and mobile node requirements in separate document? A lot of questions.

So, is there any input, any comments?

ANDY DAVIDSON: I have got a quick question, when you say "discussion on the mailing list" do you mean the IPv6 Working Group mailing list or different.

SANDER STEFFANN: Yes.
Is there still existing IPv6 Working Group?

ANDY DAVIDSON: Absolutely. OK, who wants to kick off.

MARCO: Yes, IPv6 Working Group co?chair so yes, there is an IPv6 Working Group, mailing list despite not being very active is still there. First of all, thanks for all the effort and work you guys are putting into that. As far as the options are concerned, yes, sticking with 501 on one end makes sense; on the other hand, I think it will be unavoidable to release new documents in the future, anyway, because those RFCs will be updated and will get a new number, so in the end you have to build follow?up documents so I would rather say release one new document and actually ?? one of the top headers for logistics make it really explicit when people refer to this document, make sure they refer to that document or any follow?ups that might be there, and then you can ?? if it ever becomes needed to release a new one you could say like this soup sides RIPE 50 something with wherever and when some RFC change some small things. We have seen on the 506 one where the state has changed and it got a new number. So I would vote for make it clear that there is a new document and basically deprecate 501 in favour of this new one and tell people to start preferring this one. The document doesn't go, it will be moved to the archive section they will still be able to find it, it's not gone although depicated.

SANDER STEFFANN: Since you are talking about the document structure anyway, do you think put all the recommendations and supporting those in one document or putting the supporting nodes a separate one?

Mark co?: I would stick to one document to make clear, it's more of a continuous story. At the moment it's just a list of RFCs and I haven't checked them all but it might be that that list already is out of date, so I would stick it there and then basically, as it evolves, you can do updates but I would stick it in one document.

JAN ZORZ: When we have been thinking about changing 501, instead of doing additional document, there was one concern: 501 was translated in many languages. If we change 501, if we deprecate it, what happens then? These guys will have to retranslate the document.

Mark co?: It's unavoidable, that is the choice you make when you translate it properly. If do you it properly would you refer to this document and not translate it. At the moment you take the text and use it for your own concern. I think it's unavoidable that we have to update. What happens if another RFC gets released and you are forced to update 501 then that translation needs to be updated anyway. My main concern is if you split two you have a list of RFCs to maintain and supporting nodes and those might get out of sync, having it in one document makes it clear that when there is updates released both the supporting nodes and the list of requirements match each other and you don't get stuff like let's change RFC and don't change supporting node. If you keep it in one it's much easier for people to refer to it, if it gets updated, change the reference. When it gets deprecated it doesn't disappear.

JAN ZORZ: I think we should introduce the bis stuff here in RIPE, not changing the number every time.

AUDIENCE SPEAKER: I want to jump the queue, Shane Kerr, one of the other co?chairs of the IPv6 Working Group. I just wanted to address this suggestion that Marco had of saying 501 or any later version. I think this document especially it seems like people are interested in using it if in their tender process, when they are going out to ask for new hardware and I think if I was a vendor and I said this document or maybe some document which came out next week or, I think it would be very difficult so I think we need to be very careful saying or a later version." I am worried about making that into the document itself, it's making it less useful for some people.

AUDIENCE SPEAKER: Mohsen Souissi, AFNIC. I am among people who have attempted to translate that, for instance I have done that in French, and I am very happy to see these bis document going. I am in favour of keeping a single document. It's not that long. So keep it simple. But if it is to be updated, please go back to RIPE 501 and make clearly obsoleted by the new number. And that is the only way people will, if they go to RIPE 501 by any means, they will learn that it is obsolete and go sort of cross?reference to the new one, and if you want the new document to be split in supporting nodes and the variable RFCs, that is fine, that is an option we might go for, but please keep it in a single document. It's not that long.

Steve Nash, ARBOR Networks: You asked for comment and RIPE 61 on 501. Have you any ?? are there additions to be made to 501 as it is, changes that you intend? Is there a new release that you would be doing anyway? Or did you get no feedback.

SANDER STEFFANN: I think on the core of 501, people agreed that this was a good set of recommendations, of course for specific situations you always get some, yeah, concerns, but as a generic document, I think people agree that this was good but it needed more ? they needed more help in using it so that was the main feedback we got.

Randy Bush: IIJ. By the way, this document or whatever you want to call it, has been very useful.

SANDER STEFFANN: Thanks.

RANDY BUSH: I think we have too far general philosophy of how we handle documents and this fit in it. I don't think we want to hack around for this particular one and let's look at RIPE 81, 181, etc., etc., when the document ?? when the content changes, we issue a new document. And I have great sympathy for the translation problem, but that is the same problem no matter what numbers is on the front of the document. If you change it, they are going to have to translate the changes. And I want to note a parallel here where we have in v6, we have and I think it's a disease in v6, we have many allocations, etc., etc., but not much payload and we have more IPv6 Working Group chairs here than we have content.

SANDER STEFFANN: Sorry, Patrik.

Patrik Faltstrom: I am one of the persons helped create RIPE 501 and I think my name is in the document and I brought this home and our customers started to use this and actually ask us for fulfilling the requirements that I helped writing, which made me discover two different things. The first thing we saw, as you say, is that regardless of what kind of user or what kind of customer it was, they required everything that was in RIPE 501. And which of course ?? we encountered two different problems, and this is the main issue that we at Cisco: One group of issues were correct requirements that they require that our equipment didn't really fulfil yet, which are things that you end up in pretty tricky contract negotiations, etc., when, well, everyone in here has bought and sold things, you know what is happening. But then there were the other set of requirements or RIPE 501 are things we tried to convince the customer, that no, this is not so important for you, like 6 RD ?? well, you can think about all different kind of things where you don't need certain features. So, to conclude, we fully support from Cisco the creation of the document as you see and we are happy to help with that. Most of the work with ?? let me take a step back. I think you should write a new document and not just an addition. And there are two reasons for that: First of all, that is short document and I think it's really important to get a good document that people can use and I don't think RIPE 501 is of that quality, specifically I now know that after actually trying to use the document, seriously. But secondly, I think the document is also very short, so translating it again is not a big problem, and the third thing is that I think if it is the case that we try to write an addendum to the document that explain in what order you should read various pieces, that would probably be longer than RIPE 501 because a lot of the work you should do is move around text on the document, probably, common section, this is if you do this, if you do this, etc., and the last thing is that I think when we are looking seriously into the various RFCs that is now just sort of referenced in RIPE 501, in some cases, without being able to give any specific example, I think you actually in a RIPE 501 bis, you also need not only reference RFC but also potentially create a profile that use this RFC but you should do it this way to really get interoperability because that is the ultimate goal because sometimes these RFCs are a little bit open?ended, even though you aye implement the same, they don't get interoperability so I think the RIPE 501 bis laugh little bit more text added to each of the RFC text that talk about how to implement it. Strongly in favour of this work aye vouch for a new document. On the other hand, for me it doesn't matter, I want the new documents whatever you call it, I want that out now because people need it and people are interested in it.

SANDER STEFFANN: Thank you. If you have any feedback on the RFCs and specifics, just post them to the mailing list and we will take them into account.

JAN ZORZ: But you said that it needs to remain short, so my basic concern is, if we add the wording and explanation about different equipment, will it remain short?

PATRIK FALSTROM: A document from my perspective should always be short but not shorter than needed. When you cannot remove more words, don't.

JAN ZORZ: Thanks.

ANDY DAVIDSON: We have ten more minutes, so time for maybe three more questions.

AUDIENCE SPEAKER: My name is bull Brout from the Netherlands IPv6 foundation. If you write ?? sorry, we are working for a Dutch CPE vendor and the the vendor needs or asks us one document they can send over to their hardware vendors so they can implement that, and they love ?? those are not technical people and are not interested in RFCs, so they can only remember one number and if I can I can learn them to remember RIPE 501 that would be great achievement for us. So please stick to one number and use version numbers. If you are talking about ?? if you are looking at political, a commercial governmental type of implementation, now, not about the document but about the RFCs in the document, have you considered or are you going to consider making more things like this R C you should not use, things like 624, I don't think people are happy with it and I think my vendors would be happy if they can say well, not implement this RFC and you must implement this one and it would be nice or optional or more of a spectrum of advice on which RFCs to implement and not to implement.

JAN ZORZ: Well, there was request for specifying options and sub options of the RFCs that is mandatory or optional, that would also increase the complexity and the size of the document, so if the infruit this room is, yes, go for options and prolong the document, then I am fine with that, but I don't know if ??

AUDIENCE SPEAKER: If you make clear section within the document, then it can grow and you just have to agree on which sections are useful and then those sections can be updated on their own and have their own life like a section about CPE requirements.

JAN ZORZ: Okay by the way for, I forgot mention, for the CPE section there is RFC that I knee few days ago become an RFC from Cisco, he is the editor and the other guys, that makes the CPE specification, in RFC, but weighed long discussion with Ola in Prague we decided that we will interpret his RFC in a way that procurement people can read it and put it in the tender, so the CPE work will be basically done on Ola work. We will just interpret what he has done.

AUDIENCE SPEAKER: Procurement people can only remember one number, so keep that in mind.

JAN ZORZ: OK. So this is the question for the community or for RIPE NCC, can we introduce the versions for the documents? No. Randy is giving me out of air signal.

SANDER STEFFANN: I think we should stick with the current scheme that we have been using for many years, so let's not change that.

AUDIENCE SPEAKER: Wilhelm Bellinghaus. I will suggest you write a new document, that you keep 501 as it is, make a clear reference on the download web page for the new document because I think we have to see which are the customers of this document and we have two customers, the technical people who have to implement IPv6 in their companies and the management, and they normally don't understand anything that is written in the RFC but they have to sign the contracts so we need something like a management executive at the beginning of the document and then more text technical explanation, RFC lists but can he can't tell the company you have to use RFC, XXX, this way, because each customer has got his own network and he has to do an interpretation of this document 501 or the follow?up document, so don't be too specific on it. And translation has to be done. I think when a new document comes out, new translations will occur, no problem with this.



AUDIENCE SPEAKER: I think you were first actually. David freed Dan man. A number of things occurred to me whilst listening to this, the first of which being that a document that is living is practically a site. So why isn't there a site which collects all of this information together, displace it at multiple levels of understanding and is dynamically translatable.

SANDER STEFFANN: People want to refer to something ??

AUDIENCE SPEAKER: But it's changing all the time.

STEFAN: But if we use separate document so people can say this is what we want, otherwise somebody could write a tender and then refer to a website and it would change ??

AUDIENCE SPEAKER: A great example of this is 3 BGB P, try keeping up with that. What I am saying is if you keep all of this information and put it together in one place, then you have got a continually evolving standard and yes you have got incremental version numbers but it's collected in one place and it's dynamically updatable and you can provide different views of it, as well. Just an idea.

JAN ZORZ: Dynamically updatable document with a static number and referment would be great.

AUDIENCE SPEAKER: I have a question from Chad, from OTESA, he says it's more of a comment: He says I think this discussion of course should be taken to the mailing list. However, a suggestion might be to keep RIPE 501 and alter its form, to be just an index of references to other documents and we could, therefore, keep referring to RIPE 501 as an identifier and change the references accordingly. Just a remark.

JAN ZORZ: Thank you.

AUDIENCE SPEAKER: Martin again. I heard about putting some options on discouraging or recommending, let's say, 6 to 4 or any other protocol. I would urge you to think twice before putting in this document anything controversial, unless there is a clear recommendation from and for instance 624, I hate it but there is no clear reference from IETF saying it is to be deprecated.

JAN ZORZ: Yes, it is.

AUDIENCE SPEAKER: Not yet.

JAN ZORZ: I think that draft is out the door.

AUDIENCE SPEAKER: Pleaswe, wait for the RFC before putting anything, because this document needs to be trusted by the community. Think of those who are going to write comments are technical people and if technical people say, hey, this is not yet con, the whole document will just lose its quality, so think of it. Please don't put controversial things; put something which is factual and with hard reference in it.

SANDER STEFFANN: Don't worry, this document will be ?? will go for consensus and everything in the Working Group, so it will be discussed and only things that we can all agree on will all go in.

AUDIENCE SPEAKER: Thank you.

RANDY BUSH: I was just trying to close off part of the discussion on how to deal with the number of the documents so since nobody is coming after me...

JAN ZORZ: Thank you.

ANDY DAVIDSON: Thank you very much, that was lively discussion and I think it will carry on for some time in the mailing list but another useful document will fall out T I think it's wonderful news to hear people have been beating up vendors and making things happening with 501, anybody responsible for that can claim a beer from me later. Thank you very much indeed.

(Applause).

And that closes the first section of today's IPv6 day long special, so we will sigh again in half an hour after the break.