These are unedited transcripts and may contain errors.

---

The Plenary Session resumed on the 5th October 2009 at 4:15 p.m.:

CHAIR: Welcome to the next block of presentations, continuing with the topic of IPv6. The first presentation will be by Christian from France Telecom giving us a little bit of background on what their IPv6 project is. What their feedback is, what their experience is.

CHRISTIAN: Good afternoon everyone. I am responsible for the so?called IPv6 programme which has been launched last year been France Telecom, hopefully after more than ten years having spent on the development of IPv6, most of the France Telecom employees see it as a kind of last smile before the actual deployment of v6 in our networks. So hopefully I won't be required before I see the very first IPv6 data gram crossing the French domestic backbone, for example.

The presentation itself is mostly organised according to ?? one is the programme itself, and we'll get into the technical details which will yield the starting of the very first pilot deployments in different country affiliates of the group.

You will see the rationale is the forthcoming global IPv4 ?? since the top level management of France Telecom is actually sponsoring this programme, they absolutely want to make sure that the business will not be degraded because of this forthcoming global IPv4, depletion, but I guess we are aware of the fact that we are entering a transition period during which both kinds will have to be forwarded in different conditions, which means for us that we need to make sure that any kind of communications can be established during this transition period, especially v4 to v4 communications.

So, the programme itself is something which not only gathers the people from the corporate entities of the group, but also our colleagues from the different country affiliates who will be in charge of initiating the design recommendations as well as the operational guidelines related to the progressive introduction of v6 capabilities, hence two main objectives, one is the current specification effort, which is basically presented by what we call a kind of architectural framework document, which will be further forwarded in engineering rules and operational procedures that will be enforced within each country of the group. Needless to say that the specification of itself requires some validation to ensure that the technical feasibility is compliant with the technological constraints of our environments. And this is why we have got our colleagues from the country affiliates around to table the programme itself but also they are deeply involved in making sure that the so?called IPv6 strategy is correctly enforced, considering their respective constraints.

We have also got some communication obviously. Internal, and I'll get back to this in the, what we learn session slide but also externally, because there are still some issues that need to be fixed and we are pretty active on the standardisation front to make sure that everything will be smoothly.

So the phased approach itself is quite typical, I would say. Phase 1, which is the introduction, is mostly characterised by fact that we are focusing on the, what I would call the elementary IPv6 capabilities. Namely the definition of the numbering scheme, that is the way prefixes will be dynamically assigned to CP devices, whether the ECP are installed for the residential market or the corporate market. And this very first space is also for the definition of the forwarding routing policy according to our own specific environment and this obviously includes the peering policy itself, as well as the operational considerations especially the assessment of the introduction of IPv6 capabilities in our information system, which is a kind of monster.

This is why the introduction phase itself is restricted to the Internet access, which means that during this phase we will deliver the other service offerings provided by the group, without any change as far as the introduction of v6 is concerned.

Phase 2: Migration phase: This is the phase where we cover all the service offerings provided by the routes, something which was started since the beginning of this year and this will be another opportunity for us to make sure that our IEPT customers will access v6 in a couple of years or so.

Then phase 3: Is currently targeted at 2010. This is the phase where the actual delivery of the services, whatever they may be, is fully industrialised and the production of IPv6 customers has become the rule, not the exception.

So, now, moving to the technical bits. This is where we stand regarding the design recommendations, we are moving towards the dual?stack architecture where our CPE devices will become dual?stack routers. The IPv6 prefixes will be dynamically assigned as per the DHCP within the typical deviation context. The only difference that we have and this is also a constraint by our information system, is that we need to centralise the bindings that reflect the v6 prefix that will be assigned to our customers with the customer identification information. So, it's, I would say, a slightly different way of using a typical delegation, prefix delegation where the first up router would be the delegating router itself. In our case this will be the DHCP server, which will behave as a delegating router.

As for the hosts, and this includes not only the PCs, but some of the phone terminal devices that we provide will dynamically form the IPv6 addresses by means of the slight mechanism. No magic there.

And regarding the information which is designed and the enforcement of the policy, the CP IPv6 switch information will actually be dynamically acquired by the first IPv6 enabled router which hopefully will be what we called the meantey service access node, that is the device which aggregates the connections as well as the FCTH connections, by means of a IPv6 option and this is something we are currently validating in our labs.

So, this is the strict v6 design recommendations, but obviously we have to deal with the need to make sure that the entire communication can be established. In a world where we wouldn't be able to provide a global IPv4 address to each and every of our customer. To give you an example: In the French country affiliate of the group, will be running out of global IPv4 addresses sometime during the first half of 2011, which means that we need to make sure we are ready at that time to provision our customers with IPv6 prefix obviously, but also to make sure that these customers can still access the whole range of service offers they have subscribed to.

So, hence, this notion of necessary evil. In a world where we won't have as many global IPv4 addresses as we have customers. We are entering a phase where we are considering the sharing of the global IPv4 addresses that are left, which means that in that case, this would assume at least to call into the current state of the art, the introduction of net capabilities in our network. So this is something we are currently working on. So from a technical standpoint you have got what we called carry great nap. You have got two options, one is the double not approach, which introduces a second level of NAT in the network. And obviously this assumes a firewalling scheme based on IPv4 addresses which are not meant to be on the table public ?? let alone the overlying addressing scheme which are very likely in that context.

And the other approach is what we call ?? what was in the Software Working Group, the DS?Lite approach, with the privately addressed IPv4 traffic will be encapsulated into IPv4 data grams, towards one of the available NAT capabilities in the network and then we'll have the typical NAT operations to access the v4 Internet itself. So in that case this assumes that the CPE device itself does not act visit any NAT capability anymore, which means that we need to make sure that each of our CPE devices that will be installed in our customer premises will have the correct IPv6 information to forward the privately address to one of the available net devices. So again that that context, we have decided to use the DHCP machinery to convey this IPv6 rich information to the devices.

Why the choice in our context?

We see it actually as a kind of catalyst for IPv6 deployment. Mostly because obviously in that design, the CP or the user equipment need to be provided with the IPv6 connectivity and need also to embed an encapsulation scheme to make sure that the v4 traffic will be encapsulated towards the CJN. So this is a catalyst for us because by definition it mandates the introduction of v6 capabilities, at least in the access net infrastructures. On the other hand, we see the double NAT approaches and even the so?called 6204 lack approaches as a kind of showstopper, if you will, because all these solutions, let alone the major drawbacks we see, at least with the year usage of double NAT approaches, they still mandate the use of an IPv4 address, the 6to4 presumes the use of a global address. The enhanced flavour of the approach can rely upon a private IPv4 address for the tunnel establishment band. To me, to us at least, it's a kind of character and skill effect. We don't want to go that way.

And like I said, it maintains only one level of NAT, and the good news is that the technology is already at a level. We have launched last week a request?for?information questionnaire, which will help us in refinding what's currently available in terms of state of the art. We have already evaluated two implementations. There is a clause which has been provided by ISC which will be using for our technical feasibility demonstration. So something is going on around DS?Lite. There is also quite an important standardisation effort which has been initiated and we do plan to provide some suggestions about the DS?Lite extension to say gracefully move to something that would help us in getting rid of the NAT capabilities that would be deployed in the network, which means that we are considering the so?called A plus B addressing scheme as a kind of ultimate target for the rest, for the very few, hopefully, v4 to v4 communications that will be established in the UK. So you have got the reference to the Internet drafts that will be commenting during the next ITF meeting in Japan in November.

So, the next three slides basically depict what's going on right now actually, because the pilot deployment is underway in France and in Senegal. This is, as far as France is concerned, we use CPE devices that are provided by two French companies based upon our own technical design recommendations, if you will. So the CPE is a dual?stack router that embeds with the IPv6. The choice of the length as being, first of all discussed with the technical people and second, discussed with the marketing people, we are especially considering forthcoming evolution of our residential services towards the introduction of machine to machine communication services. Based upon sensor networking technologies, which are basically natural customers of the IPv6 protocol and from that standpoint, bearing in mind that such residential services will evolve to what's video monitoring, smoke detection, motion detection, the fact that we will provide sufficient flexibility to dedicate a couple of sub?nets to convey that kind of traffic has been seen as a kind of asset for us. So this is why we are providing by default a /56 for the residential market, but also for the corporate market.

As far as the IPv4 terminals are concerned, because obviously we don't make any basic assumption about the terminals technology that will be used within the customer premises, there is still the HCP server which is embedded in the CPE and which is responsible for allocating private IPv4 addresses for these terminals and, once again, the traffic itself will be encapsulated into the v6 packets towards NAT capabilities.

Forwarding: This is the CPE is a dual?stack router. One thing I wanted to mention here is that in terms of acquiring the default route information from the CPE, we will use a kind of flavour of slack based upon the fact that the CPE will behave as an IPv6 host to what's the first hot IPv6 router and there will be an exchange of typical router solicitation and router advertisement messages so that the CPE acquires the default route information. Why this? Because we didn't want to activate a specific routing protocol between the CPE and the first op router for security reasons but also for operational reasons.

So IPv6 traffic is natively forwarding. Again we decided to move towards a 6 P design. The basic reasons for this are twofold: The technical reason is we don't need to activate a specific IPv6 IGP in our network which has quite a dramatic impact on the way we operate our networking infrastructures especially in terms of training. That is the people who are currently in charge of operating our backbone infrastructures do not need to be trained to IPv6 IGP specific protocol machineries. That was one thing.

And the other thing is the economical set related to the 6 P design, even though it must be moderated by the fact we don't have many IPv6 in the core of our infrastructures. Still, by definition, you still don't need to up rate the core routers with the introduction of v6 capabilities in that context.

Another interesting thing that we are currently working on is actually the evolution of some of our IPT service offerings, namely the live broadcasting. And the fact that the 6P is, by definition, clearly incompatible with a typical IP multicast transmission scheme, we see it as an excellent opportunity for us to introduce point to point MPLS?based precomputation capabilities in our network, whose characteristics in terms of [] /KRAOEUT /TEUFT of service will hopefully comply with some of very strong requirements we have from our customer base, especially in terms of minimum zapping times.

So the introduction of 6P design could be also, will be the opportunity to move towards point to point 3 structures for conveying some of the traffic related to the IPT service operations.

As for the v4 traffic. We have moving a DS?Lite approach. The encapsulation scheme is very basic. It's restricted to the 40?byte of the IPv6 header.

Operating: Device management in domain at least for the devices are our backbones will still be managed by means of v4. Especially because I don't regard dual?stack routers such as the 6P routers, or we got P routers which remain v4. Obviously, as far as the CPE is concerned, the introduction of the DS?Lite design clearly raises quite an important technical issue for us, because we used to manage our CPE devices by means of the global IPv4 address which is a sign which is currently assigned to the one interface of the CPE device. And since the CPE device itself will no longer be provided by an IPv4 address and, even worse, the v4 traffic will be processed by means of a DS?Lite capabilities is located in the network, then we don't have any means anymore to actually access from management perspective, the CPE rights. So we are currently implementing the IPv6 flavour of the management management tool which is used within our information system.

Customer management: This is also an evolution which somewhat related to the companion project of the IPv6 programme which consisted in simplifying our access networking infrastructure, based upon the protocol as the previous protocol to convey customers specific identification information. That will be up, we use typical DHCP options for customer identification purposes.

So, this is basically the picture that tells the story, as Rod Stewart would put it. So, once again we do not make any specific assumption on the terminals that will be connected to the dual?stack CPE router. I'd like also to mention that we have got quite an equivalent picture in the area of mobile. That is that the programme also includes the integration of the mobile world where we will rely upon C 3 BP specification and we are are working with some vendors to make sure that the equipment can use the IPv6 stack, and that will allow the customer to access the Internet, whatever the version of the IP protocol which is used.

And once again, one of the interesting of the 6P design is that the forwarding plain itself is preserved.

So, moving to concrete stuff. Pilot deployments is underway, at last:

So, these pilot deployments are projects which are driven by our respective country affiliates. They're derived from a programme as far as the technical design is concerned. And the very first pilot deployments are admittedly focused on the residential market but I think it's also worth mentioning that our colleagues from the corporate branch have actually announced the availability of the IPv6 and service offerings back in May ?? you have got the press release in that slide. So we are working within the programme, we are making sure that all the technical stuff is fully coordinated as far as the introduction of v6 is concerned.

So who are the candidate countries? France has already started, actually. As far as the customers are concerned to be perfectly correct, the v6 pilot deployment will be available from February next year. We are currently working on the upgrade of the routers, as well as the information system. Our colleagues from Poland will launch a pilot programme which is the same as going on in France as early as January next year. And we have got also our colleagues from Senegal and will be on next week. And we are currently structuring v6 on the Senegal country affiliate as soon as November, based on, once again, the same kind of design recommendations.

And Switzerland is also involved, the characteristic of the order specificity of Switzerland is that we are focusing on the mobile market in that area.

One thing I wanted to mention very quickly is the group's internal network. It's an interest thing because this is the only example where the actual global IPv4 address is not the primary driver. Here you have got an Internet which is spread over the different countries and we want to make sure that every person can access its own corporate resources. So the guys who operate the G network, this is the way we call it, have decided to use Microsoft's active directory application to do that. An active directory is quite well known to misbehave in that NAT environments. Let alone the fact that each of the country affiliates in charge of operating the local network which is connected to the group's internal network, have decided to move towards a private IPv4 addressing scheme and the scale of the G network is obviously completely overlapping. So it's another issue we have to tackle.

So the guys have started the [] G N V GI N. The core network will be IPv6 ready by November. The plan is to move towards a complete V connectivity as far as we are, France Telecom employees, wherever we may be to make sure that we can access our resources.

And this is something that should be up and running by the end of 2010.

So, concluding slides: Some of the lessons learnt. First of all, something I didn't mention on the slide. Obviously, communication is key, especially within France Telecom there are still come colleagues of mine who are rereluctant to move towards v6 for various reasons, bad reasons, but anyway...

This is something which is almost a day to day job. But aside from that the basic recommendation is for us to consider the impact of v6 on the information system. This is probably one of the trickiest areas we have to deal with. Hopefully it's not that bad, because most of our applications are pretty much v6 ready, but still it should be the very first action to perform.

Regrettably enough, we have got some vendors who are definitely not IPv6?minded yet. This means for the specific case of France for pilot deployment we have to deal with some bad work around where we decided to outsource the basic v6 capability. Especially thinking about the support of a DHCPv6 capability outside of the box, simply because the [] our /RAOEUPBDers will not be ready yet to cope with the milestones that have been identified by the French project. So it's really painful and admittedly disappointing considering all the work that's been conducted on the v6 duration. So I think in that area, this is another good opportunity for the service providers to unite and decide that the the requirements that happen expressed towards the vendors to make sure that they do address our requirements.

Still learning: Obviously the pilot deployments will perhaps help us in acquiring the operational experience we are currently lacking. In France, to give you some numbers, 200 customers will be involved in the very first phase of the pilot deployment and then obviously will extend the customer base all throughout the year, next year so as to make sure that what we recommend is hopefully ?? access to the v4 Internet will change, which means that at least from a communications point of view, we need to explain that to access the v4 Internet through a NAT capability or something that could become an A plus B router could possibly impact the way they subscribe to the service operator. So we are working with the market people to define an acceptable communication policy for this.

Obviously IPv6 introduction is ?? it's not only a matter of integrating a couple of routers in the network. DNS, and all the capabilities that need to be IPv6 ready are counted in tens if not hundreds, at least as far as we are concerned. And we are still experiencing some issues in the v6 Internet, as you know. Something like 300, 400 of transit delay is clearly not acceptable. So this will be an opportunity for the service providers community to enhance that area too.

And next steps: Specification: So, like I said, we are completing the phase 2 over the year, design recommendations will be ready by the end of this year.

Duration, we have got multiple efforts. This is a way of IPv6 training sessions that have been set up. We have got something like 150 employees who are now trained to v6, including the people trained to operate the machines. Hopefully this time it's for real.

So I guess that's pretty much it. Thank you very much.

(Applause)

CHAIR: Thank you, Christian, and thanks for remaining within the time slot. Are there any questions? I guess we will have time for one or two.

I would have a very small one. And this is, I suppose you did more than sort of this brain product coming up with recommendations and coming up with a sort of strategic plan. I get you also did some sort of lab tests. Can you share a couple of highlights of those, like the good thing and the bad thing or?

Christian: Let's start with the bad things: We got some router technologies which behaved very badly whenever you decide to forward both IPv4 and IPv6 traffic, namely we observed something like a 50 percent liquidation in the switching performances, especially from vendors who claim their hardware ready to cope with the v6 traffic, this is really disappointing.

There are some good things: I mean, the ?? what could I quote? The [] D PCP v6 design, the servers that we have been evaluating definitely address our specific requirements especially the connection between the server and the AAA server to make sure at least the CPE is perfectly entitled to acquire the request. We need to make sure that they are in the database. It worked quite well. Hopefully based upon open sources, like the code which has been delivered by iec, not openly for the DHCP server machinery, but also the most recent DS?Lite NAT capabilities, it helps us in better understanding where we should avoid some mistakes.

CHAIR: Thank you very much.

(Applause)

CHAIR: My apologies, there is another question.

AUDIENCE SPEAKER: It's not really a question, but a request: Could you please so kind as to applaud your signs of the RIPE repository.

CHAIR: I think we took care of that if you allow us.

Christian: Of course. Sorry about that.

AUDIENCE SPEAKER: One more question:

Suzanne Wolfe: I see. I just wanted to point out to people thank you very much for noting our code. We have discovered that naming our code after the protocols it implements does not work that well for us, so the ISC code to do this technology, we are calling it address family translation router. AFTR. And that's public. So anybody that's interested in playing with that code, go to our website and look for AFTR and the codes there and we are really interested in your feedback.

CHAIR: Thank you for that advice and that piece of information.

Next presentation is going to be given by Dave Wilson from the Irish National Research and Education Network titled something like a strategic approach.

DAVE WILSON: Thank you very much. My name is Dave Wilson. I have a number of hats at this stage. The one I am wearing today is of the network development department where I am project manager in the Irish National Research Network. Now, I am giving this presentation off my own laptop, because I am awkward like that and I appreciate it's awkward when speakers do that. I uploaded a copy of the slides in PDF format about an hour ago. I got this file name.

This talk isn't about HEAnet and its IPv6 deployment. We did that. We finished it. We pretty much finished it six years ago and we gave the talk, it's still there if you want to look at it. This talk is about what comes next.

You have all seen this slide. This is Geoff Huston's slide, this is how transition was supposed to work. In 2003, this is, happily, where we were, we were waiting for liftoff in good time. And it didn't work out like that, so we need a plan B. The IPv4 pool is drained. V6 is not in a place to replace it. One way or another, we are going to have a bumpy transition. So we have turned our attention to how we will manage that transition. In particular, I'll characterise it like this, and I think it was Niall Murphy came up with this statement: The problem we face is the gap specifically between the end of the old way of doing things and the start of the universal IPv6 and returning to the world of plenty that we know.

The way I see this is that there are three separate problems instead of the one we now have to deal with. The first is, like I said, we need to deal somehow with IPv4 depletion. V6 isn't going to save us on time. We know that well by now. We also need to prepare for an IPv6?only world, which is a little bit subtle, I'll get to that in a bit. And we need to shorten that gap as much as we possibly can.

So by the time we get to the end of this presentation, what I'll have done is I will have unpicked the different parts of this and tease them out. And as a bonus, I am going to present you with the one thing that no one else has, which is a business case for IPv6. No pressure...

I'll get to the bloody academics in a minute. The point is we have three different problems, not one, therefore we need three different approaches. The approaches look like this: The IPv4 depletion problem. There is a truly IPv6 only service interoperability. There is supporting our customers and partners to bring them along with this.

Now, these are parallel approaches but they are more or less independent. There are some dependences, I'll talk about them in a bit. I want to say who we are and why we are doing this.

We are a national research network. As a national research networks go, we are not huge. Ireland is a small enough country, we have 150,000?odd customers plus all the primary and secondary school pupils in the country, and our network is, we have our layer 2 is based on ? presents Ethernet circuits. We have a layer 3 network based on centrally routed core. The most important thing we do, and apologies if I am overdoing this, but I want to say our single most important product is production quality Internet service. And I don't think my colleagues will disagree with me, if you think that our customers will allow us to take an experimental approach to the service we offer, I don't think you have spoken to university IT departments recently. We are very very serious about this. They are using the same equipment, you know the same vendors as everyone else in the industry and they have the same expectations of their ISP. They also expect us to handle a whole different class of customers where we do have to take quite an experimental approach and then we have to marry these two problems.

But we don't get to escape this. Our pressures might be slightly different depending on the value of the dollar on the day. But we don't get to escape providing, you know, full quality production Internet service. So, with that in mind, what are we going to do about IPv4? Again another graph you have all seen, the projections in about two years time, the immediacy of the problems depends on the rate of usage for your particular local Internet registry. The date of the problem ?? it's going to be fairly unpredictable. It's going to be different for each us. Depending on internal factors as well as external. If we don't deal with this in good time, we are probably going to have different departments in our own organisation and your organisation, anywhere else, competing for a squares resource in an uncoordinated way, which is what I call a crisis.

And we can solve this. We can find individual solutions for all these different problems. What I am not confident of is that we can solve all these problems at the same time in the weekend after our local Internet registry turns around and says no more space, sorry. And I suspect there is plenty of surprises in store that we haven't yet accounted for, so with the objective of a smooth and stable transition from the IPv4 world of plenty, or something close to plenty that we have now, to one where we can't get the addresses or pay through the nose for them. We want to try and do in this a smooth and stable way and we have done something very like this before. We have been around this house before. We have dealt with a time limited change. Okay, Y2K was calendar bound, but that's no big deal. It was the same kind of problem I think. We had to find services in our business, pay me money it's a business. That that were dependent on something that required a work around. And then we had to implement the work?around in time. Fine we do this with IPv4 addresses. This is our first round. We make a list of everything we do with IP addresses. Everything we provide. It's a finite list. It's not actually unmanageably long in our case. The next step is work out how many addresses we'll need in five years. I know that's that like.

The main object of this exercise is to get the people involved, you know, taking the two eyeballs and looking at the problem. Get them thinking about how this might grow. How the service might need more addresses. Does it scale linearly or does it not scale at all? If it's a web server, will one web server do forever? Then I say assume for a minute I can't give you these addresses any more, what's your work around? Are you going to use a NAT box? Are you going to use some sort of proxy? Will it be fine if we can just leave it sitting off some PI space that you already have? Is it going to scale and do we have so stop taking customers if we can't get addresss in that gets people thinking about the priorities, the work?around and gets them listed in one place.

I tried to fire people's imaginations with this. Because you are going to bet some great stories out of it. The next ?? after we get something written down, we have a framework for dealing with it, for adding up what the expectations seem to be at the moment. For seeing it some of them look a little bit low, which they probably will. For seeing if they add up to more than a hundred percent on how much more. And then we work on making them mutually achievable. And this is the bit where I don't want five different departments implementing five different solutions to five different problems.

Like I say, these plans are going to be subject to change. I can't expect to turn around to one of my colleagues now and say how many address will that service need in five years? Sign the contract. It's just a tool and one of the hard things actually is to convince people it doesn't have to be gospel. It has to be an honest projection with some honest working out of the consequences in a way that we don't necessarily do this this level of detail and magnitude. It's okay it's going to be subject to revision.

The important thing is it gives us a picture which is coherent and clearer, more holistic than we had before about our ongoing address usage. Not based on a line in a graph of here is how many we asked for in the last five years. We'll probably ask for the same again in the next five years. We'll try and tie that to the requests and services we actually get.

As well as just giving us a first look, it gets us thinking about what might have to change. What compromises we might have to make. If there is going to be a problem with the ongoing use of IPv4 and the services we offer, it's starting to give us a tool for giving us a picture of what's that going to look like and get a handle on it. You start to see where the business case is coming from.

That's how we are approaching step one. I didn't mention IPv6 in that once. That's been in some way the hardest thing to get across to people to say do not now about IPv6, at least for the purpose of this conversation. The thing is people will come up with great ideas on how to convert to IPv6 as a result of that exercise. When you start thinking about the resources they are consuming or a very expensive resource, they will start to think about the work rounds in way they don't right now and you also see that. This is where we get to harness them, step 2 is where we take that information and use it. Now, didn't we finish this in 2003? Didn't we say we implemented IPv6? We did, we got the routers working, we got clients connected up where they wanted it and we got web servers going and mail servers and any servers you like, we either dual?stacked it or turned it off.

And a lot of people, you know, tell me, aren't [] en /REPBs sorted here, I didn't say there a problem with national research networks? Haven't you bought your router so that it will handle it? Aren't you finished? Yeah, we have turned it on. But what does that get us strategically. We have got IPv6 turned on here. Remember when we turned off IPv4 for an hour? How did that go for you? Did it work? It worked not badly for me. We have reached a technical milestone. We have our services capable of running on IPv6, that's great, that's important. That's a fantastic first step but it's not the end game. The end game is a working service.

I am going to make another definition. I am up here, I can do that. A working Internet service, the end game we are looking for here is a working IPv6 Internet service, end to end, which means you have your clients, client PCs, whatever you like, your routing and your services all working, and yet we're interoperating with the IPv4 Internet. And then once we do that, we can start to unpick it. This is the important thing here. We are talking with basically pulling out the bits that are can he pent on other bits or not dependent on other bits. Dealing with them and the needs to the other parts which have dependences and a lot of those pieces are already in place.

Some of us even managed to make Google work during IPv6 hour in Berlin, it was great. That was tremendously encouraging where it worked. Obviously, a lot of us didn't. So there were some missing pieces. And our approach to this, to find those missing pieces and enumerate them, is to make a lab. Now, I thought IPv6 labs are passe since 2002, you know, what's the point in having a IPv6 lab in the office, just dual?stack and have done with it already. This is a complex service, working Internet access using only IPv6.

We are going to have to follow, if we are going to implement it, it's basically a new service, the notion that you don't need IPv4, we are going to have to follow the approach of pilot pre?operations, operations, like any project in order to make this work. And this is where the really good information from that checklist I mentioned last time comes out. Where people start thinking about IPv6, you start writing that down as well. And once we have suffered the v4 problem we start thinking very hard about this and work out, if someone were to connect to us today, and we were only giving them v6 addresses what would we need to fill? What we are really working on now is how to make customers work on IPv6 alone?

So, I told my colleagues in otheren /REPBs that our CEO announced that we are planning to turn off IPv4 in a few years, the plan is quite serious, in the sense that there is a milestone we need to reach which is a working service, a working IPv6 only service, interoperable like I say with the IPv4 service, but with no IPv4 underlying it. And the crux, then, of our plan is to prepare in the next few years to have a prototype of this. I note a lot of the technology isn't there. But it's a big deal, and the reason we are approaching it like this is I genuinely believe now we need to have a plan to turn off our IPv4 in finite time. That's quite a claim. And I know it looks pretty difficult to achieve. The reason I say this is, unless we plan for it, we will never have a network that is independent of IPv4.

I am not saying that I want, or I think we need to turn off the IPv4 routers in, say, 2012, or even 2013, but I am saying that if you don't have a plan to do this with some sort of data attached to it, to be able to do it, we will never reach this point.

So, okay, fine... there are some more dependences on this one, not a stupid number. This isn't unachievable. To get to the prototype stage we need to get systems to make this work end to end. We had a go at it in Berlin. We need operating suspects to work. We need NAT/PT to work. In order to get to the production stage, once we tried those in the lab ?? because that's your lab ?? first an internal lab and then find a winning customer to guinea pig, and then to get the production money to refine these systems, where there is a big role, obviously, for customer demand. That's really only bug fixes at this point. By the time we get here, all these bits should exist. All the indications are they do exist and are not working very well.

That's fixable. It's the same thing I think we do when we accept a new server plugs into our routers. The first thing is we test the thing end to end. We have never done anything, a proper test of an IPv6 only Internet, a proper end to end test. I have not done it myself. I think we need to start thinking about this in our own context. I know people have done is. I have seen it done. I don't think it's a common thing to do and I really do think now it's time to go back to the lab in this particular sense.

So, we are looking at this in a way that will deliver a meaningful alternative to IPv4 services. Do I think I will have million customers on day one, no. Do I think ?? if we are sitting here saying that IPv6 will cure all the problems and we need to have a stable transition and so on, I think we'll need to have this in place so that people can begin to accept the advantages where they fulfil the recognise sits. And it will take a long time before these are good enough that most people will be willing to do that.

Who are the users?

Will this is dependent on strand one, how well the techology works compared to NAT is going to be the key here. If NAT is actually as bad as we think it's going to be, then it's really time to put our money where our mouth is and show where IPv6 is good. So, this is, for example, a strong justification now for why an organisation like our own should be quite serious about requiring IPv6 in public procurements that we perform in the ten years that we run. We have been statutorily strategic in HEAnet for some time, but now we have an actual service we are planning to do with an end goal that will lead to a result, which is a genuine alternative to the IPv4 NAT bound service that we assume people are going to end up with sat some point. We have land to make that happen: It's both doable and necessary, is our picture of this. If we are going to have a future Internet at all which isn't the same as what we have today, it's going to look something like this.

Step 1 is to identify the piece that you need to make them work, stream them together in the lab, see how it goes. You open a pilot to winning customers.

Step 6: We identify the problems. You know, we began this in Berlin and now we need to take this further. The problems that we identify become the statement of goals here ?? production service.

To do that, to pull that off, we will need to convince our suppliers to deliver. We need to convince them in meaningful way and that leads us to strand 3.

What do we do about everyone else? Great job Dave, wonderful if you can carry it off on your own. But you are not going to be able to accomplish everything on one occasion. All depends we stripped out earlier sort of fall down here and clutter a bit and soil the carpet.

But not only have we taken the dependences out of those two strands so we can get some work done. But those two strands, we now have plans about them, which look achievable, which will get results, which impede into this. They get the benefit of that work, and I suspect it's already started. I hope some of you you making spreadsheets at this minute. At least in your heads. And in particular, to do that we need to start in terms of the actual compromises on the service. What will we be offering to customers in three years time that's different from now? That's beginning to build?up justification for obvious changes. Then we start to show progress in the plan for IPv6 services. I don't mean 1 percent of traffic or 10 percent of our traffic from v6 addresses or, you know, 20 percent of our users know what v6 is. I mean, we have milestones where we deliver a thing and that's a convincing justification for another thing which is a convincing justification for another thing.

And to illustrate that, we have been focusing I think until now, or at least I have, I have been really bogged down on all of these things, [] straw men where people go, I go and try to guilt?trip people and say why haven't you done v6 yet? People go, it's Dave again,. When Google does it, we'll do it. Then I come back and say Google are doing it. And they go how about a hotmail? Or a lot of people, and I know the pressure is here, you can't just arbitrarily stick stuff in in RFTs and expect the results to come out. We strongly encourage you to at least have a road map, then we see the cost. The small plinth, market demand, you know, all those things.

The thing we are miss something any strategy, basic coherencey about this. A plan to reach an actual sensible goal in a convincing way.

So, how do we approach this? I am going to step into a parallel universe for a minute? What's my least favourite question in the world? Why do I hate this question? Because I have been interpreting it as this: I don't know how to make money from this. If I knew how to make money from this, I will be standing here explaining how to make money from it. And I probably wouldn't work for a non?profit. But that's not ?? I think the correct interpretation. It's certainly not the only interpretation. You can answer the question of a business case by numerating a bunch of different things. Why you want to do it, the benefits, the time scales, how long it will take and how much it will cost? And the point doesn't have to be we'll turn a profit in six months, depending on who you are trying to convince. I know there is some people who won't be convinced at all without a profit. I think that we we show that there are going to be particular benefits for making a change, which we know about, that will go along way to justifying why we start small first but meaningful in order to step along a plan.

Back to the real world, we convinced our CEO that we needed to do something about this. Then we started looking for place where is we could cooperate with others that kind of level, talk with other people. The places don't really exist. Really good I think here, at cooperating technically. I think we are not so good at making, you know, strategic cooperation happen. We are dealing with places like the Irish Business and Employers Conference, which is about the right level of people, we are ?? it's quite a new path in Ireland to try and do this kind of stuff here. That's a really juvenile example because I am really bad at this. There are at least 14 problems of that example and if you can name more than I'll happy accept them on my e?mail.

Maybe it's not completely juvenile. It came out of my head. It's an abstract example. It's, you know, deploying 100 users on DSL. We'll make a service work well on this website and then there will be some traffic and then we will show some real world experience with continued we'll now how much it costs and we'll now what went wrong and we'll be able to justify a thousand users and ten web servers. It's kind of abstract and we are never going to win, if I keep assuming what you need for your plan. There is certainly, in my organisation, a willingness to take steps to try and get us out of this situation of v4 into a situation with v6 where our peerings are really meaningful.

But all I have been doing so far is asking the questions like I saw before, getting answers like you saw before and then making assumptions in what would be really convincing and my assumptions aren't good enough. Come up with better ones.

It's a bit like politicians trying to focus to ratify a treaty. Work out what a CEO wants, show a plan to commit to it, including organisations, which is kind of boring but we need to put in the right way.

If an idea looks unachievable in a short?term, I used to just dismiss it. I am really trying hard not to do that any more. The same is not especially useful to make money, at least in the short?term. If it serves as any kind of a pilot for larger scheme, but delivering something to users even on a small basis with another organisation and reaching a commitment with them, is, for business processes, quite valuable.

So, I said, we are not clear on what organisations are out there where we can really do this kind of thing, because we have great technical organisations, the business organisations have never heard of us. The v6 task forces will probably be a great place to do it, but if they are full of people like me right now, which, you know, at least the Irish public has quite a lot of people like me, then that's not quite right. But we do need to think in terms of high level targets that we can't achieve on our own. We need to work on costs, benefits, present them upwards.

I think a lot of this is just we haven't been putting it right. We are starting to crack it. Get different organisations talking, get them to commit some resources, something manageable, something fairly small with a goal that you can prove. And that, I think, makes a good plan, I looked back over the slides, it looks obvious, I have not really seen people talk to us about doing this in a coherent way and I would welcome this kind of approach. If people are doing this sort of stuff, I have not seen them sharing the result, and I am sorry if I am out of touch.

If we take these three things, work out what's genuinely going to hurt in our service. What lies between where we are now and something our customers can use that won't hurt like that. And how we justify it.

I think if we take those three things, make a plan, note the dependencies, put some time scales and costs on it, progress towards the benefits. That, to me, counts as a business case. Now, I am not wearing a tie. Maybe it's not. But I think if we find ourselves speaking this language and putting the plan like this, it will become much more convincing to make some sort of progress towards the goal that is this thing right here, which is our end game.

And, with that, thank you very much.

(Applause)

CHAIR: Any questions for Dave, or comments? So your strategy was convincing.

We continue with the third presentation this afternoon, it's IPv6 in real life, by Fernando Garcia and Juan Pedro Cerezo.

FERNANDO GARCIA: Good afternoon. This presentation, like all the previous one that many of you have seen in other meetings, are created, together with ?? by me, that's Fernando Garcia, and Juan Pedro Cerezo, and we use play ?? source paper and I do time because I made the presentation.

This is the fifth version of this presentation. We have made four previews versions with data, with each ?? for the actual data at RIPE meetings. We started in RIPE 53, 54, 55, 56. There are some back then and this is the final one.

For the people that didn't see this presentation earlier, we think, we thought that this was a good idea to make ?? to discover what will happen if we put a computer to our wife and see who will try to use Internet with only IPv6 on it. For those who will know, our wives are lawyers and they don't have computer literacy.

Our recommendation is that I can tell you from first hand, don't try to do this with your children. Children are a lot more dangerous than your wives.

So, you know, IPv4 space is running out. Actually it's ?? it at 24 December, about 10:15. That's when everything mail from the RIPE has a new address, so I think someone will receive about that time a mail saying there is no more space.

For many people, saying you must migrate, you must migrate. Can we migrate?

This is what we can see from the users point perspective. This presentation, this is a recap of the same thing that we made at the other meetings, so I will go fast. There is to rocket science in this presentation, in this data we have behind it. We made ?? you can do this same thing. We simply made it work for you. You only need an IPv6 section. You can do some look ups in the DNS space and some easy to do tests.

And as you see, we have regular updates in the RIPE meetings.

What we get is the, is all the similar studies we have seen, we get the data from the most popular websites in the world, from Alexa, Alexa has a tool bar that many people use and that sends the statistic regularly to us, to our server that collected data and creates a list of more popular servers, globally and by country. Then for all these servers, we take, if there is an AAAA DNS for the work server and for the e?mail. Also we take the DNS servers. We verify that it works. This is simple. We open the web page, we type IPv6 navigator, we tell it to port 25 and do some very simple STMP dialogue and we check what are the outer DNS server for these web domain and we check if any of these DNS server has IPv6 address.

One thing, as many of you know, is that people don't like to move across address to their normal web server name. Google is the most clear example. They have their separate name for the IPv6 web server. So, we must check, ?? these, we check four of them, if any of them result, we can see that there is success.

We also verify the DNS hierarchy, starting from the root server down to the country level.

Some changes regarding our previews measurements. In April 2009 Alexa changed the information they provide. They provide Alexa with the top 1 million sites. We don't check 1 million. We don't have time nor resources to do that. Yes, we check about 15,000 more sites. This is a lot more than previously. Previously we checked something about 5,000.

And for the data: The green star is service that have an IPv6 address and works.

The red, I don't know how in English ?? the red mark is incorrect but it doesn't work ?? no, sorry, they don't have an DNS entry.

And the blue question mark is a liar. They have a DNS IPv6 address associated with the service, but the service don't answer the DNS ?? in the IPv6, sorry.

Some results: This is a letter from RIPE 53. We checked 75 countries. A total of 4,315 domains, and we found 12 web servers, that is 2.78 per thousand. In RIPE 54, we discover this. That doesn't mean there were less web servers, but the list of 9 more popular web servers changed and sort of the new web servers didn't have an IPv6 address.

RIPE 55: We have an increase.

RIPE 56: A big jump, and I am glad to say that RIPE 59, we have a small but considering increase. We have 8.6 per thousand web servers. That's not too much, but it's something.

So, some samples.
Australia: You see they have one web server that works and one liar web server. They don't have any SMTP working on IPv6 and no DNS server.

Indonesia is probably the most populated IPv6 country. They have a total of 6 web servers, 5 SMTP servers working on IPv6. I must say that it is the same SMTP server that is used by five of the domains. This thing happened with the DNS, but the question is that for the 455 domains that we checked, 5 of them, you could send an e?mail in over an IPv6 connection.

Portugal: We are here, so there is no ?? they have 3 servers.

China: China is, well, we say 10, because China is supposed to be one of the big movers in IPv6.

From the global list, from the 15,000 domains we evaluated, we discover 129 web servers. Some of them didn't have a real useful IPv6. They were liars. And some interesting cases is the following: They use this. There are more cases but I like this name.

And this is ?? this is very self ?? there are some people that I don't really know where they get the IPv address. It's a mystery for us because look at this, online .fc uses this. And some people live really in the past. There are [] doning a 6to4 address.

OKay, SMTP and DNS. We discovered 28 mail servers. 206 them were unanswered. So people have used IPv6 will have problems sending e?mails to each domains from this list. DNS servers: There were 44 and 42 answered. That's not bad. I have the ?? we have the data if you want to discover the culprits. An some of our friends: RIPE: Okay, they have their homework done. arin.net still doesn't have any DNS servers, perhaps they have, but we haven't been able to discover it.

APNIC, LACNIC and AfriNIC, very good.

IANA, okay. ICANN, and IETF. For those that remember the previous presentation, this is a baby change. In the first presentation nobody had the MX or SMTP server.

The DNS hierarchy, we have 7 root servers operating IPv6 and they are in the hints file distributed by Internic. So all the companies that distribute the system give their hints file of data, that's too much to say, will distribute IPv6 reading [] /HEUPBS files.

Provided TLD DNS servers. This is the history. In RIPE 57 we have ?? the number of TLDs has changed but we have 97 TLDs that didn't have any IPv6 DNS server. That decreased and started growing with mainly 3. RIPE 55, we checked more but the number was still low. RIPE 56 saw a real increase, and hopefully RIPE 59 will see it's moving faster over IPv6. Perhaps in RIPE 80 that will reach all of them.

And the gTLD, the same. They grow a little fast because many of saw the trend. The trend is mainly that the [] union estate Government and army doesn't know what is really IPv6, even when they speak a lot about it. Even they do, the domain has now a 1 DNS server working in IPv6.

Many TLDs use RIPE IPv6 servers as secondary. We found 72 of them. That's very good.

Popular DNS servers: This is just putting names of some people that provide the service.

This means that there is an a.rod service net [] /TK?PS 8, so on. Each one of them is secondary for 6 TLDs.

Many of you will say where is RIPE in this list? RIPE is making something very, I don't know if it's strange ?? they have one different secondary name for each domain, so they have 72 different IP DNS name and address. So, in fact, it's one of the biggest secondaries, but they are not in the previous list.

And we reached the point that many of you have seen this presentation previously want to know, what kind of a strange have these people used this time to show what is IPv6? Okay, this is the answer: Welcome to the [] /TREUS tan do it /SAOUPB a, the most remote inhabited archipelago in the world. It's in the north Atlantic.
Population: 271.

Nearest civil identification: 2430km. And that is not too much to say because the nearest civilisation is the [] isn't /HREUPB a island with 5,000 people.

AUDIENCE SPEAKER: It actually looks like it can blow up at any time.

FERNANDO GARCIA: You can get all this information in this ?? that's in the presentation that we have uploaded. Thank you.

CHAIR: Thank you very much. Any questions or comments? Other than asking for a replay of the funny addresses. In order to avoid ?? okay. Thank you very much.

We continue ?? the fourth presentation in this string is Carlos Friaças.

CARLOS FRIACAS: This is a very short presentation. I am, for about ten years with the Portuguese National Research Network, which is called FCCN, and I have this short talk about the IPv6 in the citizens with special needs network.

So, this is the agenda. I'll talk briefly about FCCN, RCTS, which is the network that is run by FCCN, and I'll talk about the citizens with special needs network.

So, FCCN, as already described, is 20 years birthday two years ago. It manges several important services here in Portugal. It manges .pt, which is the country code ccTLD, and it also manges the university network and also the Internet exchange, among our other projects, so I have listed here with some logos, some projects, we have security?related projects, Internet?archive?related projects, libraries projects, voice?over protocol projects, we are also involved with [] /P?FL about IPv6, we are also part of the 6 deploy project which focuses on training about IPv6.

So, what are RCTS, which is the university network? It's mainly composed by 15 universities and polytechnical institutes. It has also some research labs. It has a fairly old ?? it uses a fairly old IS number, a 1930, and it is to the European backbone.

Our universities and State labs and other types of things use bandwidth with capacities that range from 1 megabit to 10 gigabits. In the last month, we were in the process of upgrading the biggest universities from 2 gigabits to 10 gigabits and that has been a fairly hard job. We are still building a network over a 6 self owned fibre cable. So, basically, we have the three layers: the end layer, the Ethernet layer and the IP layer. We are still building it to mostly towards the interior, so we have already have crossed the milestone of reaching two borders with Spain.

So, about the solidarity network, it's the citizens with special needs network. It's about 250 nodes. It is basically ?? they are basically using the SL technology as we are not a DSL provider, we did intend to have the ?? to have each node to provide the DSL connectivity. So we have nodes installed in several types of associations: youth associations, associations for the handicapped, rehabilitation centres, senior universities, orphanages, parishes and all of the non?profit organisations that you can imagine for certain that at least in 250 you will find one of each type.

As I said, each node is DSL based. The [] /ET err was tendered towards 8 megabits downstream and 1 megabit upstream. This all ?? this DSL traffic is delivered by the DSL ISP that won the tender and it's delivered on the ?? on our city as the main node, and then it works basically as one access to our city. So we decided to run 1 public address, one public IPv4 address for each node and this was the router we selected. So pretty much standard. I have already heard some people that says that CISCO is not cost efficient as they would like, but this was our solution.

So, how was IPv6 possible in this network? So, this is the core of my message, so the tender process was the key. We really went on express, on using the word "mandatory" instead of "it was nice to have" so it wouldn't ?? so, we have placed the companies that would answer our tender in that position of having to provide IPv6 or we wouldn't accept the service.

So, we really went on this ?? went on this track and we only accepted a node as ?? a node that had been correctly installed after we verified IPv6 was really working. That was particularly easy because we already have RCTS working with v4 and v6, so it was really easy to test it.

So, the chosen CPE of IPv6 worked, so that was part of the gain, too, so we knew we wouldn't have any problems there.

So, we did go onto the deployment phase. So we did get a /60 for each node, so a /48 through to the side of the set of nodes was enough. I expect some people in the room don't ?? will not like this approach. But due to the nature of each node, we thought it would be enough.

So, we had 3 LANs in use: wired, wireless and roamers. So we have a /64 for each of these lines. And we also have the sites WAN interface as a /64.

So the deployment phase was not really a problem after we really convinced the SL supplier that they really needed to comply with the IPv6 requirement. Firstly, they were not very worried about this, so ?? but when we really made the point of having it tested and then approved, the installation, they really saw that they didn't have any other choice than doing it.

So, we went with this option, the second DSL profile, because, firstly, there was a first DSL profile just for v4 only, and then, after everything got settled, they created a second DSL profile. And then there is the normal setup, we did the BGP setup, we did the DSL provider, so one thing that facilitated it was also that they already had their v6 block, so it was easy to configure the GE trunk.

So this is some graphics on the traffic. I don't have a very large example, but from here we can see that we have about 30?something megabits of traffic for these 250 nodes on a normal day, and we already see about 200, 300 in the case of IPv6 traffic on the same period. I have that also on a week, so to show you that there is also ?? that there is already some continued v6 traffic even over the course of an entire week.

This brings us on to the last question: Is it really an 85 IPv6? I would say yes. There was a simple example on finding a way to confirm this. I just ran a script which showed IPv6 negotiations and in about half of the nodes, I found something and in my opinion, this proves they are using natives v6.

So questions?

(Applause)

MARCO: It's Marco. Wonderful stuff you are doing. A question on the wireless: You mentioned you are running wireless on the Cisco 877, only ten minutes after my presentation I received a mail from Cisco telling me that they are aware of problems on v6 and wireless. So I am kind of curious to your setup.

CARLOS FRIACAS: We have ?? we also did bump into some problems with the wireless, but the solution we had was ?? well, I think the problem was mostly with the roaming part because we are also integrated with [] he'd Rome and the solution was to have an extra VLAN for running this. This is working for, I would say, more than six months, so...

AUDIENCE SPEAKER: Cool. So you have got it working. Wonderful.

AUDIENCE SPEAKER: I think the problem with the 877s is that you can't bridge v6 between wireless and wired. You can have a separate v6 network rooted to the wireless, that does work I think.

MARCO: It makes sense.

CARLOS FRIACAS: I am not sure we are talking about the same problem, but... yeah, this is perfectly non?profit based setup, so I can easily share what we are using.

MARCO: Thank you.

AUDIENCE SPEAKER: Daniel Karrenberg, network citizen, I am slightly sick so maybe that's the reason why I didn't quite get it. I didn't understand why you have a second DSL profile. Do you have one for v4 and one for v6?

CARLOS FRIACAS: No, this goes with the complex story that the guys that won the tender ?? the guys that won the tender didn't believe they were by contract obligated into providing v6. So firstly, they only provided a dedication that made the network only provide a v4 address. Then there was a second DSL profile that with the same DSL provider. So there was a second profile for each node with a different authentication in order to turn the router to be able to get from the network both the v4 and the v6.

AUDIENCE SPEAKER: So you had to reconfigure all the nodes with new credentials for radius?

CARLOS FRIACAS: Basically, yes.


AUDIENCE SPEAKER: I understand. Thank you.

CHAIR: Okay? I think that's the end of the line of questions. Carlos, thank you again.

(Applause)

CHAIR: And thank you to all of you. This is the end of this presentation block, and have a nice evening.