These are unedited transcripts and may contain errors.

The plenary session commenced on 2 May, 2011, at 4 p.m. as follows:

Joel: Hello, welcome back for the second session of today's plenary. We have two talks and then some for this session. The first one is Randy Bush, whenever he is ready on BGP security and there will be a talk by Geoff Houston on IPv6 dual stack performance. Everything OK?

RANDY BUSH: OK. Everybody know what the most dangerous animal on the planet is?

AUDIENCE SPEAKER: Human.

RANDY BUSH: So ?? here we are. So, I do a lot of work in BGP security and with a bunch of friends so I'm going to tell you, first, a little bit about some of the BGP security work, just so those who don't follow it get some context, and then some of the threats. Not to BGP but to the BGP security work.

So let's assume, I am sure you have heard about this endlessly, the RPKI, this structure routed at the IANA with registries and everybody is to track resources, Internet resources, who owns them and to be able to formally verify ownership. And we have pretty gooiess through which you can control all your stuff and all sorts of Internet glop to make it finally come down a router so routers can make decisions which AS can announce the prefix, 4128 can, 3130 should not.

So we have a way to validate origins of routing announcements. The problem with that is that there is no cryptographic assurance of the origin itself or of the AS path, malicious router could announce the proper origin, put itself on the front, forge it and get validated. This is not good, so the IETF Working Group that does all this glob CIDR, secure inter?domain routing, is moving forward to something called path validation, and before we get there, I just want to say, we are trying to ensure that the BGP protocol is not lying, not that policy is being followed. I cannot know whether Mary wanted to announce the prefix to Bob, I can only validate that Mary did announce the prefix to Bob. OK? Policy, I can't know; the only way we know policy, is in fact, BGP because we have a way of distributing the effect of policy and it's called BGP. So BGP Sec, this path validation stuff, Val validates that the protocol has not been violated and not what business policy should be or intent. So we get full path validation, which would be rigorous per prefix validation of the AS path, and it's it's to protect against origin forgery and AS monkey in the middle attacks like the Pillasof capella attack where they completely took over and snatched the entire show network without being detected.

So, here is a simple attack, just to give an illustration of what we are trying to stop, is the traffic should have gone this way because B announced the prefix to W, announced the prefix to X, the dollar should have flowed this way but Z fake that had she was connected to B, she lied here, she said Z B, the dollars went this, she kept going. OK?

This is a simple stupid attack. There are many worse ones. So, we are going to do something called forward path signing where, when B hands it to W, B signs with B's private key that hey, I am sending it to W, this is why it's forward path, the fact that B is sending it to W is what is signed here and similar to X, similarly when W sends it to Z but this means Z cannot tell X that it received it from B, because Z does not have a B sends to X nounsment to sign (announcement). This is going to be a capability negotiation in BGP because it extends it considerably, it requires a longer BGP P DU, it only happens when the BGP speakers agree on it. OK?

Something else that is interesting is replay attack. R 0 connects to R1, R 0 decides to switch provideers, connects to R2, R1 announces and replays the old announcement, so the traffic goes this way. This will also present, how do you prevent a replay attack? OK. Is that when R0 announces here, it puts an expiration on that, a time, so that that can only be replayed for certain amount of time, it reduces the replay vulnerability window, so we call this beaconing and it reannounces the prefix and suggest we are talking about days here, aside from truly critical infrastructure.

So, what this looks like is here is a BGP announcement. Today, I have the prefix network ?? oh, my God ?? who remembers? Network layer, there we go, reachability information, and my AS, that is what I currently do. We add to it my ?? a point tore my certificate so you can find my public key and where I am sending it, the next AS and I sign it, and this is a new attribute, OK? . The next AS signs over my signature and does the same, says where she is sending it, signing over my signature since it's the signature over a hash is the equivalent of signing over this whole thing. So this is forward signing, this is BGP Sec. It's only a provider edges, it does not cover IGP or even iBGP. The iBGP will have to carry it, OK? Route reflectors will have to carry it, etc.. OK. One cool thing about it is, this is a multihomed edged site, in other words it only originates a prefix. It receives unsigned ?? it receives unsigned data from its upstreams, because it trusts its up streams to do the validation, so it doesn't receive all this glop; all it has to do is take its private key and sign its announcements. This it can do with current hardware.

So, this has been designed by a conspiracy of this kind of people and this is operators and people from the government standards folks, from operators, from vendors, so on and so forth. There are people in this room who are on this list of bad people who did this. And it's now in the IETF.

So, I have got all this wonderful stuff. What is the two legged animal going to do? We have this distributed RPKI. Do you want to bet your reachability on all these things being reliable? Right. Do you want to bet that ARIN and APNIC can keep up reliable 7 /24 services reachability from all over the Internet forever and ever? I mean, after this last month where we have hadAmazon and so on and so forth. So one thing is, the RPKI protocols have publication protocol so that you can, instead of this customer hosting their own data, they can push the data up to their parent more reliable people, so reducing the number of publications points improves things but what do you do to get this really reliable? And I think what we really want to do is remember the lessons we have learned from the DNS, and to do things like using Anycast, using distributed publication and replication, etc., but this is yet to be explored. I think it's stuff we have to do.

Next is don't overload the global RPKI, don't, you know, have ten million ISPs all fetching from it; start doing regional caches, do your inpop, this is a large ISP so they have caches that feed off of caches, connect to multiple, then you have customer facing just like you have DNS. Get the load off the global data.

Here is a fun one. So I had a 16, I got it from RIPE. It consists of, you know, my infrastructure, my look backs and stuff like that, static customers, right, that are just statically routed. Unused space and BGP speakers. I want to issue a covering row yea to protect this whole 16, to protect the static customers in my infrastructures from accidental miss announcements, aka, hijacks. So I need to announce that 16, but if I do this before my customers issue ROAs for their BGP data, they are going to be shown as invalid announcements because they look like hijacks, because they didn't come from my AS and my AS covered the 16, and there is no ROAs for them, so the thing is that I am responsible for being sure that all these ROAs are working and active before doing that. Operational fun.

Here is a great one. So, the IANA got 00, it allocates 988 to ARIN, ARIN gave me a 16, which I handed a 17 down and here is an ROA, and we look up the chain and this administrator hasn't been updating their cert for actually ARIN hasn't updated their cert, or whatever, and it's soon to expire. If it expires, my ROA will be ?? my announcement will become invalid because my ROA is expired, OK?

So the ROA will become invalid, my announcement will become not found, unless my upstream has a ROA for the covering prefix, back to the previous example. So I am going to be either not found or invalid. So, this is my parent is being sloppy. Now, these are not identity certs so I am not sure who that is. Who do you call? GHOST busters. There is a ghost busters record ways profile V card that has name organisation, etc., that that cert can sign, so I know who to call, I call them up and I say, you know, please fix this thing and three days later, I check again and they haven't, and three days later I call them up and I check again and they haven't and now it's four days before my certificate expires, or pardon me, their certificate expires, and my routing is threatened. OK.

So, what if they don't do it, if I call the ghost busters and they are not there? Can I go to my ?? to my grandparent to take responsibility? In other words, here was IANA who signed to ARIN and could we get ?? can I go to ARIN or RIPE and say, hey, would I own this stuff, etc., you can see there is an existing cert there, will you issue a cert to me until we get these people's attitude adjusted? OK. There is serious policy issues there, and serious liability issues there. OK? In other words, as Geoff said yesterday or day before, so this certificate, the one that is going to expire, exists now, but how does ARIN know that I am not having an argument with them, I haven't paid my bill, whatever it is, so I call up ARIN and I say, hey, will you do a bypass? And what ARIN is doing, is they have a customer they didn't' have a relationship to me. So what is their liability and their exposure in doing that? OK. Should we, as an RIR community, try to make procedures and policies that allow this to happen?

Here is another expiration: ARIN has some, you know, this entity hasn't paid their bill or; we have always been told by the RIRs that they will never control Internet routing. Well, now they seriously affect it. So when this happens, when I get an in an argument with the RIR or whatever it is, there is a procedural issue and my cert is about to expire, who do I call? The Cert task force, the Address Policy Working Group? Bob's new policies that he has just published? Don't know. OK. So, you know, I am very concerned, one way to me to solve this and it's why I have been arguing, is I think the RIRs and in general people in the chain, should not be using expiration time of the certificates as a contractual issue, that they should be issuing fairly long lived certs and if they get in a financial or contractual argument with me, they have a way of handling that, it's called revocation, right, they can issue a revocation for that certificate; in other words, it takes a positive action to affect me, not just letting something sit there. That is what ?? these are, again, we should be talking about this as the community.

And if you believe that them is us in this community, read the ARIN policy mailing list. It's embarrassing.

And that, in the end, it's cheering that you control your routing policy, still, even with origin validation, etc., you ?? that doesn't make the router automatically drop the route; it's your routing policy is in control. You can ?? you know, do route maps or policy stances in Juniper to say what happens to an invalid route, the example I like to use My Friend Steve Bellamen who is a security researcher, might have his filter set up to only accept invalid routes, because he wants to see them, the valid ones are uninteresting to him. So the Internet draft currently says that invalid origins may be used but should be less preferred. But do I, if I don't reject invalid, what is all this work for? So we really need to be very careful thinking about our policies and our procedures for how we use the RPKI and in routing and how we maintain and control the RPKI, because it's now a much more serious effect on the Internet.

Just so, you know, that the people who fund this are indeed the people who take the TS, run the TSA and take your scissors away and what we are doing is turning those scissors into plough shares.

So, I really enjoyed this morning's workshop. I will go into detail on the BGP security stuff in the Routing Working Group and any questions? Don't go any further.

CHAIR: Any questions for Randy?

AUDIENCE SPEAKER: I just want to add something that is, it is imperative that you understand that this RPKI thing just gives the authority to the RIRs and, nowadays, you can announce anything and the RIRs is just common, you know, we are agreed that RIRs are good so we are follow the policy of the RIR but we are not forced to and if you change this, then if you have this central authority, then totally you give away control about that.

RANDY BUSH: Two things: I don't assume the RIRs are good; I think the RIRs are a good demonstration, that when you create monopolies eventually they go bad.

Secondly, is, with authority goes responsibility, and unless responsibility and authority are equal, you get trouble. So indeed, the RIRs really didn't want to get into the routing game, they really, really, really didn't, but the problem is, that is our administrative hierarchy for issuing addresses so that is the authority chain. So if you are going to do this certificate system, you are stuck. Geoff really wants to speak. I can see it.

GEOFF HOUSTON: APNIC. I suspect that there is a little bit of misunderstanding about the way deregulated industries actually coordinate necessary activities amongst themselves, because the RIRs are not an imposition, and they are not a foreign body and they are not a third party; they are this industry, they are you guys and the whole reason why we have these open policy fora is for this industry to develop mechanisms to work together, so it's not that the RIRs are adding, removing or imposing impositions that are not something that you yourselves want. What we do is what you ask for as a deregulated industry. So that is why I shake my head when I sort of see these conversations about the RIRs imposing themselves upon routing. What controls do you guys, as an industry, want, in terms of the necessary acts of working together and announcing and carrying each other's routes? What controls do you want your deregulated coordinating body, your RIRs, to enforce, in your name to at least mitigate some of the worst effects of bad behaviour? If you want none, you get none. If you want some, say so and we will do it, but we are the industry, we are not some external imposition. That was why I was shaking my head, we are not a third party in this, we are fart of the fabric.

RANDY BUSH: We are part of it but I would argue indeed, what we are is the incumbents and wave history of putting up barriers to keep out newcomers, with the excuse that we are trying to reduce the size of the routing table, you have to be big enough to get in the door.

GEOFF HOUSTON: But that is commentary or on the industry as distinct from the RIRs. That was ?? thank you.

DANIEL KARRENBERG: RIPE NCC, working for another of the RIRs, actually, co?perpetrator of the first RIR. It's very important to listen closely to what Geoff has said. The RIRs are industry self regulation bodies. There is going to be a membership meeting of the RIPE NCC on Wednesday and everybody who puts money into the RIPE NCC can go and elect a board there, and the board runs the association and can tell the RIPE NCC to get the hell out of the RPKI business, if that is what you want. This is how it works.

The other thing that I resent is this constant thing of Randy going like, you know, monopoly gone bad. It's exactly the other way around. The RIRs are actually the industry and are trying to help organise ourselves in a way that is acceptable to everybody in the industry and hopefully, also, acceptable to consumers out there and hopefully also acceptable to those who look after the public interest, i.e. governments, so also think of that. And to what the previous, previous speaker said, I had exactly the same comments as he had three years ago when this was all going on and what we see now and what we saw at the workshop this morning is that the way this is implemented right now, at least in some alpha code from some router vendor that we all love and hate, there is actually no imposition of this stuff at all; you get the information whether there is a ROA, is a valid ROA, actually, and then what you do with it in policy is your stuff, it's basically what Randy said, so it's very important to recognise that so if you don't like what the RPKI tells you, if you don't trust your RIR, well, first of all you should go and elect a different board, but if you think you can't do that, just do that stuff. Thank you.

RANDY BUSH: Daniel, the problem with this one particular one, I didn't go into it, is here it's saying what the recipient does, OK? I receive the announcement, I choose, by my policy. You, as the announcer, did not get to set that policy. So, in a sense, we have the ?? one of those cases where the cost in benefit are separated, which is a problem. All I am saying is, this is into the perfect solution. It's the best I have been able to think about, it's just not perfect and I need to admit it because I am an engineer not a politician.

DANIEL KARRENBERG: Exactly, the way it was since BGP one, it's not new. It's actually the say it was since EBGP.

RANDY BUSH: It's also not magic.

AUDIENCE SPEAKER: What I was thinking after the previous two speakers is that if RIPE or if any RIR has authority over address space and via that over the routing table, that should they also have some sort of, you know, mechanisms to ?? for punishment if somebody doesn't play along and what sort of methods should that be? Should there be any? Or if it's wanted that this self regulating body should really be the upper most authority in this region, then should there be some international treatees to enforce that law or where should we be going?

RANDY BUSH: You are above my pay grade.

AUDIENCE SPEAKER: Malcolm. Some of you may know me, I do government stuff. So it's no surprise to me that this discussion has quickly turned into something that is more philosophical than technical and I know there are many in this room that will be turning you off. Please don't let it turn off. This stuff is really important. These arguments we have just been having now are far more important than most of the day?to?day stuff that RIPE deals with in its policy development. I stand somewhere between personally Randy and Geoff's comments there. I wouldn't say that the RIRs are an example of any monopoly gone bad yet, nor would I say that don't worry ??

RANDY BUSH: You are not in the ARIN region.

AUDIENCE SPEAKER: Nor would I say, however, that they are just us and there is nothing different, because the Internet has been structured historically over avoiding hierarchies as much as possible. You can ignore what other people are choosing to do and just get together with the peers that you work with and your stuff will still work even if some other dictator in a foreign land decides to switch the Internet off over there and the only area where we have got a substantial hierarchy that really matters is DNS and this is a talking about creating another one and it's talking about creating another one that will be fundamentally important. Now, Daniel would like us to believe that we can, because we are part of the RIRs, because they are membership organisations and controlled by us, we don't have to worry about this because we will just come up with the solutions that we all support and then we buy into it and we can choose to submit ourselves to that authority and then there is no problem. Well that is fine, except for a couple of things: One, as Randy said, we will change over time, and I certainly believe that the predecessors of all the people sitting here in this room thought seriously about these questions in days gone by and we are approaching one of those points where we have to decide what the shape of the Internet is going to be. I hope Daniel doesn't take this too personally in the way that it sound like there, but frankly, Daniel, you are not us because you are responsible to the policeman that comes knocking on the door and because you will have no choice but to obey him, you are authority that is not us in a way that ??

CHAIR: Can you make it brief. We do need to move on.

RANDY BUSH: That is the missing slide which I really need to put in this, which is one of the biggest threats is the Dutch civil authorities.

AUDIENCE SPEAKER: Well... or some other civilisations.

RANDY BUSH: Courts.

AUDIENCE SPEAKER: Don't mind Holland and the Netherlands, it's government per say, it's distinction between hierarchical system and a mesh, network structure and we are talking about potentially changing here so one of my questions, and it's way outside my technical understanding: Do we really need this to be a tree? I understand that the validation tree works nicely and a simply, would a mesh or forest ?? I know that you couldn't have an entirely mathematicalically perfect way of validating without it, but how bad is this problem anyway?

RANDY BUSH: Two things: One is, the actual allocation hierarchy, the administrative hierarchy for handing out addresses, structure, is hierarchic, so it's only the RIR who can say to whom they gave the data, who can sign something, whether it's BGP or whether it's X 509. The second thing is, we haven't really got a good mesh certificate structure technically available to us.

AUDIENCE SPEAKER: No ??

RANDY BUSH: I think we need to have another person at the mike.

AUDIENCE SPEAKER: I didn't want an answer from you, I wanted to open up questions for other people to consider: How important do you think this kind of stuff is and would setting up meshes amongst small peer groups be an adequate response for me rather than having this big structure that could be a potentially big change.

RANDY BUSH: Come to the Routing Working Group on Wednesday please.

AUDIENCE SPEAKER: This is going to get very philosophical and I would encourage people to take part because this is all how the Internet is going to be.

RANDY BUSH: Agreed. Gentleman at the front mike.

AUDIENCE SPEAKER: I am going to first of all say I agree pretty much with everything that Malcolm has just said, and actually what I wanted to say is can we please get this cruft off the routers. We don't need this. It's not a big enough problem. We are trying to solve problems that don't exist and only exist in people's imaginations.

RANDY BUSH: 7007 only exist in someone's imagination? The YouTube incident only in somebody's imagination?

AUDIENCE SPEAKER: Yes, those are problems with people trying to do things they shouldn't be trying to do. But they will continue to happen.

AUDIENCE SPEAKER: We need to get better at managing networks.

RANDY BUSH: Good luck. I think it's Rudiger before you.

AUDIENCE SPEAKER: John Curran, ARIN president and CEO, designated punching bag. So, Randy, you had a slide, will the grandfather rush to the kids? a little while back. And you talked about the validity periods for certificates and advised maybe they shouldn't be tied to necessarily administrative or contractual relations. What is your recommended validity period? I know the draft certificate in this area, in the RIPE region, says end of year plus six months. I am wondering what is your advice, because, clearly, that is the concern you are talking about.

RANDY BUSH: I would design it based on expected crypto vulnerability lifetimes and I am not an expert but talking somewhere between two and five years.

Steve: That is too short for crypto?vulnerability lifetimes, really.

RANDY BUSH: Three years would be perfectly reasonable.

AUDIENCE SPEAKER: If that were the only rationale.

RANDY BUSH: All I am saying is big enough so that what I am worried about is I am worried about more 7007s and more YouTube incidents. To solve that, there is technology that we can argue about and work out and try to make better that we really need to have deployed. One of the biggest impediments to that deployment is operators' fear of this hierarchy is examining to bust my routing so one of the things we can do is make it less threatening.

AUDIENCE SPEAKER: Understood. And that doesn't really contrast with the fact that resources might be revoked or reclaimed for some reason. Has guidance regarding this issue from a sort of technical BCP area been given by the CIDR Working Group, is there a statement that says lengthy periods are better than short periods? Is it in the draft CP?

RANDY BUSH: No. Message received. Message received. And I was talking this morning to Benno who is saying there is a bunch of stuff we should do in this area as far as practices that, you know, the IETF documents don't cover, maybe they should be IP F documents, maybe not.

AUDIENCE SPEAKER: The reason I ask, ARIN is the official respected laggard in this space, mostly due to some of the legal issues in rolling out a services the fact you have some thoughts on that area will help us because we still have plenty of time to get a CP that does what we want.

RUDIGER VOLK: Deutsche Telecom. Actually, I would have liked to raise questions about, well, OK, what of the ?? what of the techniques mentioned in the presentation and there were several distinct ones, could be expected at which time and place ?? at which time to actually hit the operational networks, but we are kind of stuck in the policy swamp, and ??

RANDY BUSH: This presentation was specifically about to ?? supposed to be about policy. That is what I was asked to do so this is why this discusses the policy implications and what we should be thinking about as we discuss how to use this stuff socially as opposed to technically.

AUDIENCE SPEAKER: There is a further technical talk in Wednesday on the routing group just after lunch, Rudiger.

RUDIGER VOLK: Well, OK, for the policy side of things, yes, I think there are a lot of potential practical problems and a lot of them need to be analysed very carefully to figure out what technical or process means can be used to deal with them. That kind of detailed discussion is pretty hard and, well, OK, some of that discussion may actually expose that once in a while I'm not Daniel, and Daniel and John may be interested in things that I'm not so much interested and vice versa. And there is a lot of need for people coming in with good ideas to identify the threats and more good ideas to deal with them. I think we do not have a systematic map of the threats that actually are cause for people being afraid. Being afraid in general is very easy and for some ?? for some of the things, it is, indeed, extremely important to look at, well, OK, things that the RIR may tell us, this is just our business practice and you don't ?? you don't need to think ?? look at this, and, well, OK, it may be actually something where the policy, we as a user community and, by the way, not the board, decides, to define ?? to define and get into place, but, well, okay over the last two years or three years where we have been discussing this within the RIPE community, we haven't been made ?? we haven't ?? have not been getting much of progress on this.

RANDY BUSH: Steve? Good morning.

Steve Kent: I want to say two things in response to Martin but Randy already pointed out one which is the address allocation system is a hierarchic one, the certification standpoint have exactly the same entities attesting to who holds which chunks of resource as the folks who handed them out in the first place, getting any third parties involved is very much likely to make things worse. We have a whole community of browsers out there with that notion embedded in them which is a mess at this point in time.

Secondly, the other thing to keep in mind, ultimately this is input to ISPs to make decisions. ISPs still get to make the decisions and so, if the system works well as perceived by the ISPs, they will presumably place a lot of stock in this and make good use of it and it will have force and if it is not working well, people do not feel that it is a benefit as opposed to a danger in and of itself, then it will not be used in that fashion and that will that will be the ultimate determining factor. Any time someone suggests bringing in governments to help us, I, like you, want to run away scared, based on experience.

RANDY BUSH: There was, up until recently, war between the RIRs and the IANA, that IANA shouldn't be the root of the arc hirer and five should be, please remember that when you want to go get more v4 address space, where else are you going to get it? Of course, now IANA doesn't have any v4 address space but the RIRs have come to their senses and it will be the normal hierarchy so things move along well.

CHAIR: We need to move on eventually.

DANIEL KARRENBERG: RIR inventor. I just wanted to say to Malcolm that I don't take any of these arguments personally and and to the contrary, actually. You might remember that in this very room, I had animated conversations with Dr. Canter there around the same subject but what I have come to believe is that this community is actually ready for this and the fear has subsided a little bit, but what ?? the point I want to make is, we need to be absolutely sure and we, as a RIPE community, but also we as a RIPE NCC, need to be absolutely sure that that is the case and remains the case, because there is not, Steve has said it, adoption will tell the tale, but on the other hand the significant investments we are making into this whole thing so if at any point the general mood becomes not favourable to this, we have to have, as a community, the courage to actually admit that and stop the whole thing. If what ?? the sentiment Malcolm has expressed, which I have expressed before becomes prevalent then we need to recognise that as a community, otherwise we are not grown up, we are just putting our heads in the sand. Again, personally I think this is going in the way that people are cautiously sort of accepting that this is happening, but if not, then by all means, speak up.

Sandy: Sandra Murphy, Sparta. That, I have a couple of comments which reiterate points others have made but I wanted to respond to one comment about the examples that we have seen in public of routing incidents were just accidents and therefore, can be dismissed. I encourage everyone to try to remember that anything that that can happen through human error can be made to happen through human intent. The fact that we have seen accidents are worked examples that malicious events are possible and trying to produce smoother management interfaces to reduce the likelihood of accidents, doesn't in any way protect the system against malicious actions.

To reiterate the comments about the allocation system as hierarchic, security protections work best, if at all, if they are tied to the action of the system that you are trying to protect. If the allocation system is hierarchic the protections have to be tied to those. If you want to come up with a peer to peer web of trust, we protect ?? we trust our neighbours we are doing our business with, ways of ensuring globally unique address allocations with good storageship, then you can define a non?hierarchic protection for that system. If you have got that allocation hierarchial system that you have the system, the security protections must also be hierarchic. And finally, with the single point of failure and court systems, remember that, as has been mentioned, DNS is lass hierarchic system. No one seems to be concerned about the NICIN countries being forced by court order to take down zones or things of that sort. This is not a new vulnerability, the fact that wave hierarchy system introduces it.

RANDY BUSH: A student of mine from 1992 by the name of Terret Kamel turned off the Internet in Egypt. Didn't take a certificate.

Sandy: OK.

RANDY BUSH: I am reinforcing your point. I also believe aeroplane accidents probably should be evaluated for changing the design of the aeroplane. I fly a lot.

WILIFRIED WOEBER: One of the herders of some legacy address space and I think the community should actually do some sort of reality check against the vision that the IP address space is hierarchical because at least in the Internet that we are operating right now, it is only to some degree. There is big chunks of addresses which do not obey any sort of hierarchy and looking at the developments in IPv4 end game, we might see more holes getting punched into this perceived hierarchy. Looking at all the toxic waste ?? looking at all the legacy class Bs, there is no hierarchy and whatever we actually want to implement here, whatever the trust model is and the organisational framework is, it should also encompass, sooner than later, that part of the Internet which is not run on top of a hierarchical address space. Thank you.

CHAIR: Thank you very much for everyone who has contributed to the discussion. It's taken a bit longer than we expected but it was well worth it. So, try to move as quickly as possible to the next presentation here. Geoff.

GEOFF HOUSTON: I have a presentation somewhere, do I? Good afternoon, I am with APNIC, and this afternoon, I would like to talk to you about v6. Some of you might be aware we have run out of v4 addresses over in the Asia Pacific area. Really. With luck, I can even make the next slide pointer work. Try again. This worked. This is running v4, is it? I can tell. Next slide, please. Fairees make it happen. So, the real question is, if working with one protocol really does have its problems, and it seems to, because quite frankly even after 25 years of doing v4 we still don't get it right most of the time, the real question is, you know, when you actually get two protocols to play with just how weird can you make the world look like. I love that picture. What lunatic would have thought you can strap jet engines on a plane, how does it go around corners? Badly.

What we are going to try and do here is look at the world when you convert your favourite web server to run dual stack, because, quite frankly, the world gets pretty weird. So, this is an exercise in trying to measure the world from the perspective of the content itself. In some ways, measuring this actually measures everything else, because if you can get to a dual stack site or v6 site using v6, then quite frankly, everything is working; your site is working and your machine, the DNS is actually resolving AAAA records, your local server is doing v6 and routing, the other end is doing v6, all the other bits and pieces of network infrastructure works. Otherwise you would do v4. So in looking at the metrics for v6, one of the best ways of looking at this is not to count the number of AS or number of entries in routing tables because that is elements. If you really want to see how much v6 is out there, look at end?to?end. Look at how many folk are able to use v6 end?to?end. So, this is a test which is actually really simple, like all good tests it actually gets down to the elements.

What we do is we, through Java script, ask the client to download three 1x1 gifts, so they are tiny little things, one of them is only away with a AAAA, so unless you can ask for a AAAA, get it and actually do the retrieval, you will not get that first object. The second one is kinder, both AAAA and normal A record so it's dual stack and the last test is a v4 only, only got an A record. We are nice because sometimes your v6 sucks. You know, the 20 second wait in Windows XP is still out there, the three?minute wait on some systems is still out there, sometimes when you offer a dual stack to a poor unsuspecting client they take up to five minutes to figure out that life is hell, so this is actually got a cookie behind it so you only go through hell once every 24 hours because hell is meant to be rationed that way. Other thing, we use packet server dumps, we are looking at every single packet that arrives at the server to figure out precisely how stuffed you are. So we will have a look at this because what we are going to look at is retrieval rates, failure behaviour and the transaction times.

So, here is the sort of bunch of tests, v4, v6 and dual and you can kind of categorise site. If you are v4 only yes you will do v4, you won't do the v6 object, obviously, and the dual stack you will do v4. That is clear. The ones that are kind of interesting are the bottom three. It used to be, until about two years ago when folk figured out how stupid it was, it used to be that if you could possibly do v6, you would. Anyone using XP out there? You poor sucker. Welcome to hell. Because it's not working very well. Most operating system vendors got the clue, even Mac OS got it earlier this year and most folk now don't do 6, even when they are capable of it they do v4 in dual stack mode and there are a few poor suckers, a number that are really a problem, who will do v4 but when get to a dual stack go, nothing more happens. So we can count these folk and actually have a look at these.

This is actually looking at the APNIC website since May last year. And a similar test has been done in RIPE and they get similar numbers. And the one thing I have to say about that, you folk all use the RIPE site, ripe.net? You are weird. You are completely weird. Because those numbers aren't found anywhere else on the Internet. The fact that there are up to three percent of folk every day who come to APNIC and prefer to use v6 in a dual stack mode, is anomalous, it just isn't reflected in any other part of the network. So you folk out there who come to these RIR sites are not typical. This is typical.

Those of you at the back row, because you can't see it because it's down on the floor, that is the amount of v6 that you see on a dual stack site. And if you look very, very hard, you will see that it's grown from .2 percent to . 3 percent of all clients in 12 months. Well done. If that is a metric of success, go home. It's just not working.

The other interesting thing is that basically, 4 percent, 4 out of 100 folk, if you give them the v6f only URL they will use v6 and get it but they all prefer to use v4 and in dual stack mode. We can have a look at what is going on here now, and the way you do that is kind of you pose the question: Why is it that all those hosts who are capable of doing 6, don't? Because the ones who are capable, 15 times more than the ones who prefer to use it so there is a huge amount of v6 capability out there that is never getting exercised. Now, the beauty about v6 is that the things that don't work self identify themselves with their source address. So all you poor suckers out there using 2002: /16 are down there and the Teredo victims are there as well. Interestingly, the folk who prefer to use v6 these days, all actually run with Unicast v6, v6 that appears to be at least, to the end host, native rather than auto tunnelled. So that is the rise from 0.2 percent of the universe to 0.3 percent of the universe, is all basically v6 Unicast ways good thing.

Let's have a look at the folk who don't prefer v6. And this is the breakdown of the same thing. The folk who don't like to expose the fact that they are capable of doing v6, when they are coerced into doing it do it with 6 to had. All of those auto?tunnelling mechanisms don't naturally come to light unless you give them a v6 only URL. The folk who run Unicast, and there is a residual amount of Teredo, that is weird and spooky, by the way, we will come back to why that is weird and spooky but that amount of Teredo down there at.005% or so, shouldn't be happening but then again Teredo is weird, anyway.

So, you know, the answer is most hosts who have Unicast v6 do you recally prefer in dual stack and those with auto?tunnelling generally prefer to use v4. So, what is going on here? Why ask the vendors switch? We will see why because I am going to give you some figures about this. But basically, the older versions of preferred 6 over 4 actually had really, really crap performance, that it was better if you will, to actually go v4 than try v6. Windows XP was a classic, that if you actually managed to try to do v6 and it didn't work, you actually sat there with the spinning egg timer or whatever for 20 seconds for every last connection attempt. What happens on a 50 part web page? Go and make many cups of coffee. So it's no surprise that recent OSs have depreffed that. Let's look at this in terms of quantifying performance.

This is the average amount of time to retrieve the v6 object compared to v4 per day across all the experiments that were taken. So this solid blue line is the average v4, 0 seconds, so whatever it took for you to get the v4 object, that is fine, let's now measure if what the v6 object took relative to that. Interestingly, and I find this actually really encouraging, the green line, Unicast v6, is about as fast as v4, even though there is a fair amount of use of tunnelling in the infrastructure, the tunnel brokers, the hex goes of this world and so on, on the whole the performance of v6 that Unicast is as good in terms of round trip time, round trip time, as v4. This is good, smile allot. However, once you get into auto?tunnelling, performance sucks, that an individual 1x1 gift that should load in milliseconds, for Teredo, takes, on one particularly bad day, on average, six seconds longer than v4, six seconds, not milliseconds. So as you see, performance tends to be really crap. Teredo, one to he three seconds on average up to 6, even 6 to 4 has been 1.2 seconds more.

So why? The first thing is, that Teredo is bizarre because of this astonishing A work it has to do to set the NAT up and tunnel through it. Because what Teredo is trying to do is deliberately force a NAT state, and it goes through a fair amount of effort to do that, and it takes a minimum of one round trip time, and a maximum of many, many tens of trip times to do it. And the second part is that tunnelling doesn't necessarily use the same path. This is the worst case in 6 to 4. Here is the v4 only NAT happens to go from the client to the server and back again but in 6 to 4, instead of going directly to the server it has to go to any this Anycast relay and to the server but has a v6 packet, sends it back to its relay that goes to the client. This may look good, except if you are in industrial Australia and that is say in America and you are in Europe and that is in somewhere over in Japan, you have got a really, really bad around the world loop. And the real question is, how many folk actually provision local relays in both directions? It wasn't rale question that you should answer, basically none of you do it. Most of the packets go around the world most of the time. We can help you with this, if I can get the next slide.

What I have done in the server is actually put the v6 relay back, so now, in theory, the only difference in performance is the outbound packet towards me, so let's have a look at the set?up time for 6 to 4. 6 to 4 is stateless, the set?up time should be 0. Interestingly, some folk take up to two seconds to send that first packet. God knows what you were doing. I don't. But most of the time 6 to 4 comes up really quickly and at the same time as v4. What about the tunnel RTT in 6 to 4? This is more interesting.

A large number of folk are around 100 to 200 milliseconds longer than the v4 path. I'm in Australia. A lot of clients of this stuff are actually in the Asia Pacific region. What is 150 milliseconds away? America. The trans Pacific route twice. So for 6 to 4, a huge amount of relay server is being used by folk in the Asia Pacific region sit on the west coast of America. For a smaller number of folk, the 6 to 4 relay servers they use from Asia Pacific to get to Asia Pacific are located in Europe. 350 millisecond peak. No wonder 6 to 4 sucks.

So you get an average of 1.2 seconds, basically because what is going on is this massive transit delay being added by both trance specific and global trance its coming in. So the other thing is, too, that a very small number of 6 to 4 relays get a huge amount of traffic and their performance sucks, because you are not paying for it. These servers are actually done by charity, by other folk that either you don't pay and I don't pay. So the problem of both long transit and congestion comes through that 6 to 4 is really quite shocking.

So, let's go to Teredo. I love Teredo. Teredo is this amazing protocol, because 6 to 4 always seems to me like shit. Who the hell has a native v4 addresses at home? Come on, come on. Less than 10%. The rest of you sit behind NATS, and 6 to 4 doesn't help. So, most of you sit behind NATS but none of you use Teredo. Or do you?

So, I have started sniffing in the dark and if ?? actually, last Christmas, no the year before, someone announced a/3 in v6, a/3, and they held it up for two months and nobody noticed.

I have just announced the /12 in v6 and I have been doing it for the last two months. Nobody sent me mail. So what do I see? Well, that is very quick snapshot of what I saw this morning. And this is one 100th of a second. So it's a quick snap of a few packets. Now, I have blotted out most of it, except that the source addresses, I have just taken out the last bits and I have ?? but it's kind of Asianish, but the thing to note is that of this dark traffic I am seeing, 98% is Teredo connection attempts because the first thing Teredo tries to do is send an ICMP. The second thing you might notice is that there are no Teredo sends. Every last one of those attempts failed. Well, they had to because I am not answering. Whoever they thought they were delivering the packet to was never going to work. Why aren't these people complaining? Interesting. Because they are getting crap servers and interestingly 98 percent of that dark traffic is Teredo. So next question is, how much v6 traffic is Teredo? And the inference that I have seen and I have seen some reports coming out from ? sort of underlines the fact that a huge amount of the v6 traffic actually is Teredo. So what is going on here, why can't I see it in a normal web test? Because when you use standard sort of theology software like browsers, Windows get host by name, won't query for a AAAA record if all it sees is Teredo. Micro torrent will. Or enters do things very differently so most of the traffic was peer to peer, all I have got is web page rather than peer to ?? can I expose that capability, of course you can, bypass the DNS. So there is a fourth test I add to every single client who goes near me, it's this test here, which says don't worry about the DNS just try and get that gift for me, just bring that back. So now I see something very, very different.

Now, I see 0.2 percent of folk will actually expose the fact they can do v6, good on you. Around 4% if I corner with v6 only URL, yes, I can get that. 30% of you, three out of ten, if I give you that literal URL will actually successfully get that and put it in the log file, yes it got delivered. So there is a huge amount of the Internet that can do Teredo. What about the other 70 percent? What is wrong with them? I don't know. Let's go back and look at that 30 percent harder.

Now, I want to see what is going on with performance. I love this slide. Go and look it in it for detail, it comes from Microsoft. This is the amount of packets, all fine nine of them have to take place before you get the first send. I am going to talk back this and send a packet over there, a bubble goes there. Teredo does an amazing amount of work to set up the tunnel. That is the unit, that is not mille seconds, that is seconds. So on the average, most folk take two?thirds of a second before they get that first packet to me, before I see anything at all. That is 12% of folk. There is a whole lot of folk at two seconds, even more at three, and there are some folk out there at 9 .5 seconds, 9 .5 seconds. This is the horse drawn Internet. So now let's look at the RTT costs.

Oh, my God, I am in Australia, what is 350 milliseconds away from Australia? Here. How the helm I actually managing to send packets around the globe? Fascinating. So on average, Teredo sucks, and the reason why it really sucks is that its set up time is somewhere between one to three seconds on average and the RTT, every single packet takes a third of a second longer. Hence Teredo is two seconds longer than v4. So, the reason why operating systems like windows and Mac OS have decided that auto?tunnelling should be deprefed is the protocol from hell. It just sucks performance?wise. The penals in terms of RTT and set?up are simply crap. Why? Because you folk, the ISPs out there, are lazy. None of you have ever done any work in installing local 6 to 4 or Teredo relays. I am reliant upon the kindness of one or two stainingers, predominantly hurricane electric, to take most of this traffic. None of you are doing a bloody thing, and the problem is auto?tunnelling protocols simply don't work very well.

So if you are a web consent server, the least you might want to think about is at least doing something in local 6 to 4 relay. Because it will only make your clients happy, it won't piss them off. At the moment, if you go dual stack without doing this, a small amount of your customers are now going to see inordinate delays as their packets go around the world.

So that is performance.

But that is not all. Because things really do suck when you look at failure. Because the real question is, I am kind of interested in if you turn on your web server and go dual stack, how many of your existing happy little customers who see your web page are about to become ire rate folk who will see the spinning beach ball of death? How many folk are you going to piss off by going into dual stack, how many folk won't work? So interestingly, that is a big number. Since November, what I see is that around .6, going up more recently to .8 percent of all clients who are successfully able to retrieve the v4 object appear to have trouble in retrieving the dual stack on. They could have retrieved it in v4, they did not. If you have a million customers a day, 0.6 percent? Enough to be worrisome. So, what is going on here? What is this dual stack failure all about?

I am not sure. I am really not sure, because there is a certain amount of Java Script going on, there is a certain amount of ordering of the way these things are going, so at some point might be sitting going abort, on to the next page, there is a certain amount of user re?set and I am not sure the fail back to v4 is working very well so can I put a better methodology on failure? Oh, yes, I can. Because I am logging packets and the one thing I have been fascinated with since birth if you really get down to it, is naked SYNs. Naked SYNs are quite wonderful because it is when you see the incoming SYN of the TCP and then nothing. You send back the SYN ACK and for some reason you never get the ACK. Now, this is really cool because now I can quantify how many folk successfully send me a SYN but never see anything more. How many naked SYNs are out there? So I am not trying to figure out how many folk never got to the SYN; I am only interested in the SYNners amongst you but you are fascinating people. Now, this is the SYN connection failure rate of v4, no SYNers in v4, versus v6. Wow. In v4 I get a failure rate where I see around .1, a little over, percent very, very little. Wow, between 6 to 10% and it's rising, of v6 connections, fail, just don't get beyond the first SYN. This is weird. So then I tie it down 6 to 4 between Teredo and Unicast. This is Unicast, this is the blue. This is Teredo, that is the green, this is 6 to 4. 6 to 4 sucks. Wow, between 10 and up to 18% of all connections fail. But that Teredo number, the one at the bottom is Teredo really that good? Well, I wasn't measuring things right. Let's go a bit further here, because Teredo exposes much more of its, if you will, sing than 6 to 4, because what I see in Teredo, if everything is working properly is that the server sees an IMP echo coming in and it answers it and that is the way it ramps up its tunnel and does every good stuff. If the ICMP fails I can go well that is a dud because normally I would see the sign and if I see both I still get failure. Now, let's have a look at Teredo failure.

Next slide. Teredo is not that good at all. Teredo sucks. 35% of Teredo connections don't. One in three. So, what is going on? The 6 to 4 stuff is kind of easy, kind of easy. The problem is, that auto?tunnelling is not deliberate tunneling. It happens on your machine without you even knowing about it. Now, most of you live behind some kind of firewall, yes? What do you filter out? Well, normally, you don't explicitly block things; you allow things. You allow TCP, you allow UDP and some of you even allow ICMP. Well done. A lot of you don't allow protocol 41. What is 6 to 4? Protocol 41. So you will happily send the outbound SYN because it's SYNing in protocol 41 and you don't care about outbound but when the SYN at comes at you, not allowed. Because you are auto?tunnelling you don't know you are throwing it away. OK, that is the 6 to 4 failure rate. Self inflicted damage, no sympathy. 35 percent of Teredo, what is going on? It's not filtering. Because this is standard UDP and IP. There is nothing wrong with that.

Teredo uses a very simple version of STUN, and it's designed to actually understand the way in which NATS behave. How good is stun as a protocol? Sucks.

Next. So, 6 to 4 is kind of shit. Would you put up a service to your clients where you say look, you 20%, you are stuffed. The rest of you have a good day, you guys, you are finished. You are not in the business of pissing off your customers. And that failure rate is bad. But look at Teredo. Half the room, you are out of luck. Teredo simply does not work. And it seems to be between some form of local ICMP filters and some amazing amount of stun, not understanding how NATS work, because NATS really are weird, and automated methods of doing NAT binding fail astonishingly often and quite frankly, even Unicast v6 sucks because it's 20 times the failure rate of v4. If we think that this is a network that is v6?ready, we are on massive mass delusional drugs. This is crap.

So, we are about to do world IPv6 day, we are about to piss off most of the customers on this planet, because what can we say about performance of dual stack? It's viable, just, but a small fraction of folk who are quite happy customers on that day will get a service that is much, much slower because when they go to v6 because you have done dual stack and preferred v6 for whatever reason, a small number of them are going to find their packets circulating to pollute owe and back just to get to your server. They will not be happy. A much smaller fraction are not going to see you at all and the failures are going to be bizarre. Some of it will be the machine getting wedged, some black hole problems from hell and most of them the fact that auto tunneling doesn't work. But that is not everything. Don't forget, dual stack is not the end station. For dual stack, you still need v4 and we have just run out. There is no more. At some point, you guys are going to have to contemplate services that sit only in v6. Could I put up a service in v6 right now, today? Well, yes, but only 4% of the room will see me and even those will see me very, very badly.

So, what is does this tell me about v6 transition? I have heard a lot from the ISP industry that this is not their problem, that they don't have to worry, that they don't have to do anything because clients can get to v6 servers by auto tunneling. Why should they spend money and put up a v6 servers? Why should they strap the jet engines to the train at incredible cost when you guys can do it anyway? Microsoft has solved my problem. Teredo will get past NATS, I don't have to do anything. If you think that, you are wrong. Auto tunneling is not a solution. It sucks. There are so many problems around there, that there is no way in the world that Teredo or 6 to 4 is any kind of useful transition. If you think that is going to save your bacon, you are on drugs again. It aint. There is only one way of doing this and if you are an ISP, you are the problem and you are the solution. Because the only way we can make v6 work, the only way, is to deliver v6 Unicast in line in the service. If you think end hosts can hop over your laziness, hop over your inability to do this, you are wrong. Your customers will die horribly with you. The only way to do transition is to do it yourself and do it as Unicast.

Can you play with this? Yes, you can. We have done some stuff at APNIC labs that allows you to use Google analytics to figure out the way your customers will behave in dual stack which is work done with Emile of the RIPE NCC so go and have a look. That is my presentation. Hopefully, that has been amusing in terms of understanding exactly where we need to go to v6. Any questions?

AUDIENCE SPEAKER: Thank you very much. Leo Vegoda, ICANN. So I couldn't work out, because you were showing long times on setups from your server which I assume is in Brisbane, how much of that was down to your server being there? If it was in Barcelona or Birmingham or Basil or Baltimore, would it be different?

GEOFF HOUSTON: This is a great question. You can do a trace route. You trace route 2001: :1 and I thought to myself I am in Brisbane, the Japanese are very switched on, surely there is a Teredo relay close me and it goes Brisbane, San Francisco, oops, New York, holy shit, London, and I am examining this is just weird, right. 350 milliseconds round trip. I can fix this. So I did. I can run married dough like the next person, put it one millisecond behind the serve. Do the trace route. I am laughing. This is great. The round trip time collapses. I look at the set?up time, no change. Shit. I am like, that entire 2 to 4 to 10?second gap in Teredo has nothing to do with round trip time. There is some bizarre behaviour in Teredo with timers and NATS that sit go have I pissed you have the customer yet? No, I will wait a bit. Oh, OK. It made no difference to the contribution of set?up time.. so I give up, Teredo is truly broken. And there is nothing I can do to fix it. In terms of putting the servers and putting the relays goes to me, it doesn't help. So I have no idea why Teredo is the protocol from hell, but it is.

AUDIENCE SPEAKER: Thank you.

CHAIR: Anyone else, questions for Geoff?

AUDIENCE SPEAKER: Benedict, Strachobhand, I am a freelance worker with IPv6 since 2003 and back when I first tried 6 to 4, I figured out that the situation fundamentally is way less optimistic that you say. Basically, what happens, and that is with all tunnelling mechanisms short of things you do with tunnel broke or whatever, you don't know who your tunnel provider is, so first time I tried it, towelly worked and the timing wasn't too bad, there was a 6 to 4 relay actually in Switzerland and it worked fine. Six weeks later I gave it a try and it didn't work. Trace route showed that about 5 kilometres from where I lived Deutsche Telecom tried to set up 6 to 4 relay and failed miserably, so the big problem with these mechanisms is not, in my opinion, not even the extra delay or whatever, but that as an ISP I run a serious risk of whoever services I make money with, might have a problem, shut down or whatever, and all of a sudden, heaps of customers blame me because their Internet is broken. This, in my opinion, is even worse and significantly worse, especially if you work for large scale ISP like I used to a long time ago, if you have a couple of million customers who have been using IPv6 without knowing and all of a sudden things break, you need to upgrade your calll centre.

GEOFF HOUSTON: So, what we have done in this world is bizarre? Because in the IT world, in the networking world, there are two ways of coping with failure: One way is to try and fix it; the other way is massively overprovision so that failure doesn't matter. The peer to peer folk have figured out a couple of things: One, you guys deploy deep packet inspectors in v4 only, true? And that you don't look further into the packet, and doing the dark packet work, I am amazed to find that two v4 hosts are communicating using one side 6 to 4 and the other Teredo, to sent same packet to each other and it's basically a peer to peer opening packet. Why? Because you guys don't packet?inspect. But the failure rate of doing that is massive. Why aren't your call centres being inundated. Peer too peer is so amazingly overprovision that had a few peers don't work. So what? If you want to build a network that every time you want to make one connection you open up 50, let's just go down this route because that is where we are heading. If you want to build a network that is reliable, that has any decent kind of performance, this is no way to do it. We can do better than that. Part of the issue is to learn from the fact that we have played around with tunneling for three decades, and every single time we have played around with it we have learned one basic fact: tunneling sucks. It never worked and it never will work.

(Applause)



AUDIENCE SPEAKER: Martin: Have you tried, in your experimentation, something based on 6 RD?

GEOFF HOUSTON: 6 RD is not something I can play with. Don't forget, I am just the web server and you are just the client, so I can't 6 RD to you; that is something that your ISP does. Now, the beauty about 6 RD and I will say its beauty, both ends of the tunnel are managed by the service provider and are known to each other and in theory, you are managing the MTU and if you get everything right, getting rid of half the room, if you get everything right, it will just work, but don't forget there are failure cases even in 6 RD that are difficult because there are failure cases in tunneling that are exceptionally difficult. 6 RD is one of those desperation measures of, I have to do something, I can't upgrade my infrastructure. Oddly enough I can upgrade the customer CPE. If that is where you are, that is just fine. It's not the uniform solution and it's not where you want to be in the long?term, because in the long?term, tunnelling sucks.

AUDIENCE SPEAKER: I completely agree with you with this qualification of 6 RD solution and I am not advocating its solution. Native is the best. But when you said that all tunnelling mechanism sucks, and putting that in the same level, I am just wondering whether 6 RD is not rather closer to the Unicast, with relation to connection failure and you haven't measured that.

GEOFF HOUSTON: The problem is MTU black hole problem in v6.

AUDIENCE SPEAKER: Just ask people using 6 RD and whether they have been stuck with MTUs and maybe they have never seen those cases.

GEOFF HOUSTON: Randy Bush is coming to the mike.

AUDIENCE SPEAKER: I personally use 6 RD at home. I am not satisfied with being with that forever, but it's much better than any other solution based on tunnels.

RANDY BUSH: Solution to what problem? I want to get TV. I don't care whether it's 6 or 4. I have tried 6 RD. It was better than 6 to 4, but it sucked.

(Applause).
Tunnel sucks. There is something that sucks worse than tunneling: NATS.

(Applause.)

RANDY BUSH: It combines them both.

GEOFF HOUSTON: The combination is really toxic, yes.

RANDY BUSH: You can see the effects in your measurements. The answer is deploy IV6. End.

GEOFF HOUSTON: I wasn't impressed with Teredo. The failure rate is so high and there is no obvious reason why it should be. It's easy for 6 to 4 to think about local incoming filters on protocol 41. There is no reason, structurally, why Teredo should fail. When you rook at that failure rate and you think what other protocols and applications do you guys think that users are deploying successfully today that attempt to do stateful transition across NATS, has anyone measured their true success rate? How many folk are you actively pissing off, even today? How successful are these protocols? If Teredo is that bad, and it is and we can see it and we can measure it, how bad are other protocols that attempt to do stateful NAT transitions? It's an interesting question and I suspect answer is worrisome.

AUDIENCE SPEAKER: First of all, did you try Teredo without a NAT in front of you?

GEOFF HOUSTON: I don't have the NAT, you guys have the NAT. I am just testing clients. I have no NAT in front of me. I am Unicast 6.

AUDIENCE SPEAKER: The second thing is, I don't know, this is just for people's information, but there has been moved in the IETF in the v6 Working Group to deprecate 6 to 4, to move it to historic status and that would effectively mean the end of it.

GEOFF HOUSTON: Well, if the message behind this is to the ISP industry that you cannot rely on clients to patch over your own delay in deploying v6, you cannot rely on customers to hop over your own problems problems. That is the real message.

AUDIENCE SPEAKER: I would really like to meet somebody who considers tunnelling and auto?tunnelling mechanisms to be the saviour here for your business. I really would. I don't know that these people exist. I am scared to hear than you have met some of them.

AUDIENCE SPEAKER: They are on the IETF mailing list actually, you can see some of them.

AUDIENCE SPEAKER: We run measurements similar to us yours on ongoing basis, Lorenzo, Google, sorry ?? what we do is we control for v4 and v6 in the same experiment and same measurement, and another thing I wanted to point out, by the way, is that we looked at one hip from one IP address in one day and we realised that users that are behind proxies so we basically threw that restriction out. We signed the hits instead. We control for v4 and we do see the difference between a 4 had nines 9 network and ?? so we do that by looking at successful v4 hits but measuring v4 in itself, I don't know how to do it. If you can if you can think of a good way to do it, we don't have out?of?band reachability.

CHAIR: Can you make it very brief.

AUDIENCE SPEAKER: I heard sort of applause about deprecating 6 to 4. Being in an ISP community, I am not very happy with that, and even if I don't support, I hate 6 to 4, but this might be seen as a pretext for ISPs to continue doing nothing more many of them so if we want to deprecate 6 to 4, go for it but we should recommend ISPs to go for native IPv6 and do something.

GEOFF HOUSTON: I am not sure you could get a stronger recommendation than simply saying that if you think your future lies in v4, you are wrong. Thank you.

(Applause)

CHAIR: Thank you, Geoff. So, just a few quick remarks for everyone. This is not the last session of the day and I am not talking about the social; I am talking about the network complexity workshop which is starting about now, a few minutes ago, in the room when you go out of this room, the one that is immediately in front of you which we also use for other meetings at the RIPE meeting. This is back because we got very good feedback from the panel we had in Rome, except this time it's in BoF format so there is more room for participation from your side. So, you are very welcome and encouraged to go over there.

Second thing, on Wednesday morning, we will have a session that has been traditionally part of the plenary programme, reports from the RIRs and NRO, I have been told to this take 60 minutes and the slot is 90 minutes. In this spirit of making the meeting better as we go along, we are going to use the other 30 minutes in that slot, the first slot on Wednesday to do lightning talk which is something that happened at other meetings already but we never got around to doing here. They are things you think you can share with others in this audience without having to have a very overloaded presentation or a lot of forethought on what you want to present. It's short, to the point message, a little bit better than what I did earlier, with some preparation. That was a last?minute thing. So if you want to submit one of these, please do send a mail to meeting [at] ripe [dot] net, and tomorrow afternoon, we will pick amongst the ones that have been suggested. And pick three, because that is the time we have to house them, and let you know. And we will hope everyone will enjoy and benefit from that.

So, just a reminder, network complexity BoF is going on on the other side.

DANIEL KARRENBERG: Are the lightning talks at the beginning or the end of the slot?

CHAIR: They are at the end of the slot. Thank you very much.

(Applause)