The next session will commence at 11 a.m..
CHAIR: Welcome to the next session of the Plenary. We have a fairly packed session. We have four speakers this morning. First one will be Mark Townsley. We changed the order slightly with respect to ROSIE. Mark will go first with perspectives on IPv6 in the ITF. Mark, over to you.
MARK TOWNSLEY: Thank you. Actually this is going to be prospectives on IPv6 in the ITF and in the broadband forum. Can I pull the audience? How many people here regularly walk the halls of the IETF, follow everything there, know exactly what's going on, etc., etc.? If you are an AD, you should be able to raise your hand.
How many of you were at the IPv6 implementers conference at Google about a month ago?
Okay. And broadband forum?
Okay. Thanks. This shouldn't be too repetitive, though some of the slides some of you may have seen before.
So I do walk those halls quite a bit. I served as area director for four years of the Internet area. I also regularly participate at the broadband forum and service their liaison to the IETF and the conversations have been changing where we used to hear you know do we really need IPv6? What is the business case? That is slowly being drowned out by "I need server load balancing, I need better MIB support. I think Lorenzo made the comment the other day I know this particular service provider must be doing something with the IPv6 because the bug he is finding, the only way he is finding is if he was deploying it. Those are the kind of questions that are coming up more and more drowning out the, do we need this? What's the business case? This kind of stuff.
In the IETF -- you know what, I have been looking at my presentation...
I'll continue...
So this is what I just said.
There is a number of documents in the IETF. Here are the sort of categorised in terms of numbers of documents between IPv4 and IPv6. The documents in the IETF sit at various states, some of them for very, very long time, proposed standard tends to end up being the standard rather than marching through our three-step process. Point being there is plenty out there to read if you absolutely want to read it. I hope, by the end of this, realise that you don't have to go read everybody about IPv6 in order to deploy it.
General areas in the IETF that are working on IPv6. There is just a bunch of names of things that have something specific in their charter about IPv6. They are not the actual working groups, they are categorical areas. There is about 120 working groups in the IETF and a lot of them if not all of them have some hit on IPv6. So what is the goal? The high level goal here is a wrestle between two different things.
The goal in general is to continue the growth of Internet. We saw lots of stats on this audience should be well aware that the address exhaustion is happening.
The two kind of opposing sides in this tug-of-war is a group that believes the growth of the Internet means retaining the simplicity of having addressable devices and so extending that address space out to all those devices. Keep this part of the Internet functioning.
For others it's retain the infrastructure I am familiar with. So IPv4, v4, IGMP, all the things -- arp, all the things that I know and love. The IP address with dots and doll colons. These kinds of things and these sort of play in a battle against each other. Merge them together and the overall goal would be continuing the growth of the Internet with maximised application options, minimized long-term operational and capital cost. This implies deploy IPv6 for more addresses, IPv4 /IPv6 coexistence at some point turn off IPv4.
What do you think the next slide is going to be? Okay. This is electricity throughout the world. Gosh you can hardly see it. The contrast -- maybe it's these lights. You can see India quite well here. Of course you see Europe and the US. This is electricity in year 2000. This is your IP addresses in year 2007. Some of the countries that you could make out plainly via the electricity that they are burning is a little bit more difficult to visualise here. Sometimes we forget in your op, sometimes we forget in North America, we have got lots of IPv4 address, but of course around the world that's not the case.
So this as all been hitting the IETF and I am going to get into a little bit of the recent work in IETF on IPv6 and transition.
So, the unworkable approach is to expect IPv4 and IPv6 to directly inter work with one another. You know, maybe 15 years ago we could have thought about doing that but certainly not now.
The period of approach: Dual stack, we all know about this. But of course we have run out of time for this to become, to be as smooth as we would like it to be. We have also kind of forgotten how to run multi-protocol networks. Back when IPv6 was designed, running a multi-protocol network was normal business for a lot of people, you had IPX, you had Apple talk, I don't know what you had, you had all sorts of different protocols on your next. Nowadays, the unfathomable success of IPv4. Certain link layers like Ethernet have made the number of protocols that we run on the networks much smaller and we forget this multi protocol route that came when IPv6 was being developed. It was very natural back then to run two protocols on your network. Today it bothers some people. It will cost twice as much, etc., etc..
So, a couple of working groups that you should know the name of. If you do want to follow what's going on in the IETF. Is Soft Wires Working Group, this can be loosely thought of the as the Tunnels Working Group. So every combination of your v4 over v6 whether it's connecting meshes of islands, islands of v4 over v6 or vice versa. Dual stack light pops up in here and I'll have a graphic that explains that a bit more what we mean by that.
But this is the Working Group to go to if you want to talk about tunnels.
If you want to talk about translators, so actually doing the best kind of translation you possibly can between IPv4 and IPv6, this is new work going on in the Behave Working Group. This is intended to be a temporary tool to help with the coexistence problems. It's most applicable when you end up with a network or a host that is absolutely IPv6 only. Imagine a large wireless deployment with IPv6 only network and deployment. Most of the time talking to itself within the wireless, within the wireless network, needing to get back to the legacy IPv4 Internet and wanting to put a big box on the side. There is other applications as well in the inter price space, Windows 7 has a feature called direct access, they are putting a translator box in as part of the architecture of that. We see this coming up more and more and you see the Working Group is chartered to work on four different combinations of you know my network to the Internet, where the Internet is v6 or v4 or my network is v4 or v4, so those four combinations. What was deemed as unworkable is the v6 Internet turned to the v4 Internet. Impossible so you have to scale down one side of this to make it workable.
Work on IPv6 itself continues. IPv6 maintenance Working Group, the IPv6 Working Group itself is gone and shut down. The message being we are done. Go deploy. Now it's in maintenance mode, okay. Because of course you find bugs. There is also a couple of Working Groups that are spun off working on say new features. The Savvy Working Group which is, if you are familiar with IP source guard and IPv4 by some certain vendors, this is being documented in IPv4 and worked on in IPv6 because some of the implications of what's done there are different in IPv6.
In addition, secure neighbour discovery, things like this, the CSI Working Group.
There was a pretty controversial BoF at the last IETF meeting in San Francisco and here we discussed whether or not to design IPv6 NAT. The main issues of the day around that are: Renumbering, multi-homing, simple security, topology hiding and these are all discussed.
Bubbling up from the top is a certain amount of fear that IPv6 NATs, for whatever reason, are absolutely going to exist and if we don't define them and say this is how you do it, programmers will get very creative and if you have heard Geoff Huston's presentations on this, he has distained from creative programmers. They will go out and look at the NAPT code from IPv4 and just copy it over into IPv6 and that's what you'll get. Where because of the address space in IPv6, you could actually do a lot better if you were to design this.
So, that's one of the reasons for doing this. Of course there is reasons for not doing it and the IETF hasn't fully decided what they are going to do here.
In addition, there is a side of IPv6 under the relation that IPv4 isn't going to be able to be turned you have nearly as fast as we had hoped, wee see a lot of work around sharing an IPv4 address amongst multiple subscribers or house holds. This can be done in a couple of different ways. You see double NAT is sort of the first obvious solution where you have already got NAT in your home with private IPv4 and you come in and you plop in a big box, maybe it's called a carrier grade NAT, the name hasn't been settled upon really, but you end up with two levels of NAT here. Of course, this CGN, we are not doing aggregation here. This has to hold full state of every single RG out here because it's actually translating the flows and has to keep up with that. So this is a big honking box that's got to do a lot of work.
One of the issues is what do you address this space with? If you have got private IPv41918 space in the space, if you have got is global Internet out here, what do you use here? You can use private here then you have a collision issue, can you use global here? What do you use? And we discuss this had at the last IETF meeting in the Internet area and in the OPS area. No real conclusion on that
This is no way to do NAT, and it is service provider NAT, within the first layer 3 edge device. If you happen to have a point to point link or somewhere at layer 2 to identify this subscriber, you can actually remove the NAT in the RG assuming you have control over the RG to do so. Okay? Because you can disambiguate the different subscribers based on something at layer 2 and then virtualise their NAT here and you are still sharing, you are reducing the number of IP addresses you need for your set of subscribers. This of course has issues because it requires you to have far more control over the RG. This requires less control of the RG because you are assuming it's already NATTing. You are getting into the various deployment of trade off solutions.
I have started here, you know, where you plop down a box and make it work with your existing network and I have moved it out a little bit more and I am going to move it out more, if if with your global IP address you have also got a port range. Instead of you having 65,000 ports to choose from you only get 1,000. Hang out in that space. And your neighbour gets the same IP address and he gets another thousands thousand an so on and you start divying it up like this. Requires a great deal of coordination between that box and this box, the RG and the BNG to be able to handle that but once you get out here it just looks like relevant IP again. Now multiple customers look like one, but I am waving my hands at that for a moment.
These are the kind of three areas in IPv4 preservation so to speak, that are being discussed in the IETF. I promised you something on DS light. Put IPv6 underneath here, so let's say your service provider with lots and lots of nodes and today, you have got to address those nodes, your internal nodes, your set top boxes and what have you, and you have got so many that you have to -- you can't globally address them because you need those global addresses for your subscribers so you address them in 1918 space then you have got overlapping 1918 space because you have got more than 16 million. It becomes a nightmare. IPv6 all of a sudden becomes a really interesting solution, not to give access to the subscribers, but to use within your own service provider network. So that becomes the initial goal of IPv6 deployment. It's a bit reversed from the tip perspective of I want to give IPv6 to my subscriber. I am going to use it within my own network. Once it's therefore, again multi protocol kind of bothers people. Turn off the IPv4 here in the service provider network and tunnel it across into your IPv4 Internet and to your NAT here if you are running out of IPv4 globals. That's the main idea around dual stack light. The ultimate -- what that ultimately means is on the subscriber side, you are putting IPv4 over IPv6 and if you have separate tunnels coming in, you can actually give everybody the same IPv4 address if you want. You can disambiguate them by the IPv6 address because it's bound together. That's why it's called dual stack light. Your applications see dual stack but your provisioning system doesn't have to provision IPv4, different IPv4 addresses for all your devices. That's the light piece. The light is in the provisioning.
So, is this stuff going to exist, the NAT 444 stuff? NAT 444 is sort of a shorthand to some people for double NAT. This is how they see it. Pick your own time line. But, you know they see some point out in the future, IPv6 coming along enough to reduce the number of CGN or private 1918 IPv4 users.
So, in this world of double NAT, what's going to happen? I want to go back a little bit and talk a little bit about applications and the transports that run on top. Because what happens is you change the IP, who sees that? It's not so much the subscriber sees oh my IP is address is now in a different range, the average subscribers doesn't understand that but the application feels it and they have to respond and start working. Back in the dial up days each PC, even if only temporarily, had a global IPv4 address. Applications came a long, then the NATs came along and broke some of the applications like VPNs. Remember when you couldn't get through your NAT with the VPN. Various games, IRC. That's a geek tool. Who would ever want to send telecommunications messages to one another? What a silly thing to want to have to do? You know...
FTP, you know, silly little application, broke with the NATs, right. Well, the applications, what did they do in the face of this? They evolved. I would love to queue some BSQ music for this, but...
This is just one of the evolutions, these are ten slides from a 660 slide presentation on ice, so ice is this 9 step programme to make two devices be able to communicate with one another. This is the IETF version, it uses things like turn servers and stun and keep alives and all sorts of magic. Skype has their own kind of version of it. Eventually, what you have is a cocktail of approaches, every application has to run through. The connectivity cocktail, we can all toast to that sometime this week.
So, whatever your device is, whatever your application is, they go through all these sorts of things and more and more and more just to try to talk to each other because of course the IP level is broken.
When NAT444 comes, other applications will break again, just like ten or 15 years ago when, or ten years ago when the NATs came along. A new cocktail will be formed, we'll add additional ingredients, okay. Once it's done, it's done. And we need to break that cycle before it starts. So, if you walk away with one message here with respect to IPv4 address exhaustion, there is another, there is another inflexion point coming, okay. We missed the first one. We should deploy IPv6 yesterday, right and let me give you an example: I had a friend live next door to me growing up in the deep south of Alabama, he had really strict baptist parents, wouldn't let him go out and stay out after ten o'clock at night or something like that and I was, my parents were a little bit more laid back and we'd be out. Once that clock went past ten o'clock he said forget it, I should just stay out all night long, right, because I am going to be in trouble anyway, I might as well enjoy it. So the question is: Are we in that situation with IPv6? We missed it, we just forget it, fine, we are in trouble anyway who cares? Or is there another inflexion point coming up where that's the real deadline, right. I am argue that go there is a inflexion point, it has to do with these application that is run on top.
They run in a cocktail, right, they try whatever they can, they don't care, right, they'll try, IGD, they'll do /AR sap, they don't care, they just want connectivity, so if you as a service provider are considering a 1918 service, a NATTed service to your customer, please deliver IPv6 at the same time or before. That way when the applications have to evolve again they see I have got this neat IPv6 bind to it and maybe we break the cycle.
So I promised something about the broadband forum, I have got a few minutes on that.
The broadband forum, this is their scope, everything from the radium management to the access layer and into the home and they developed technical reports or technical recommendations, I can't remember, TRs. They decided to kind of assess the situation in respect of IPv6 a year or two ago.
Kind of looked at what works, DSL with PPOA and PPOE kind of sort of work, mind you this was built way back in the day when we knew how to do multi-protocol networks. You can run dozens of protocol over PPP. IPv4, IPv6, fine. Of course IPv4 sent risk management, billing, but generally speaking standards wise for sure, and product wise, you will hear more from the following two speakers on that. We can make this go.
What doesn't work so well? Well in about 2005 we developed this thing called TR 101, which is the next generation for moving broadband into the next 10 or 20 years. We forgot about IPv6. The [] December LANs were actually built to sniff IP packets. They stopped being L2 and they started being L2 and a half and they started sniffing IPP packets and stuffing things inside of them and making the fact that Ethernet and maybe ATM and IP, the Ethernet and IP were really the only two protocols that you had to deal with, and IPv4 at that. So the layers merged. Especially in the access networks. So lots of new brand new next generation features came along which really don't work well with IPv6 at all. So you end up with this you know non PPP stuff having a big gap right there in the centre.
So, the broadband forum woke up to this and launched a forum about a year ago. This is simplified. The broadband forum bits out broadband sweets with whole sets of documents. A couple key once, TR 19, TR 101, TR 124, these are published recommendations or reports that defines some of the key things about running IPv4. WT 187 encompasses the sort of what we know. So what work slide and it's an update to TR 59 and part of TR 101. The stuff? TR 101 that kind of broke is a different document. WT 177, so if you are part of the broadband forum you can read the TRs, cannot read the WTs unless you are a member of the forum.
IP sessions was already a work in programme. IP sessions are this sort of stateful thing sitting on a layer 3 edge that's bound to guess what? An IPv4 address. So, we have got to think about how to make that work with IPv6 prefixes instead. So, this document was put on hold and we said all right, we'll fix this one and ship it with IPv6 involved.
TR 124 is the home recommendation so what do you do in the home? In addition, there will be IPv6 on all new broadband forum documents. I am getting kicked oft stage. That's great because Alex and reand Marco have some great presentations. I want to point out Google and free, you will hear about them if you run around in IPv6 circles. There is a whole host of people that came before them that have been work on this for a long, long time Marco being one of them. What's interesting about Google and free is they didn't exist when IPv6 was invented and they only came on the scene really in the past few years and started doing the work, you know, 2007 as you see and they got it going on the backs of all those other people, but they got it going. So that's the point where I think we are at an inflexion point where it's not just the people who have been working on it for ten years in their own sand box but it's actually gone the next stage, okay. With examples of free and Google.
So how did they do it? They turned on what they could, they found out what was broken and what was not, and they filled in the gaps. Sometimes themselves, sometimes they were pressuring their vendor, whatever. And now there is traffic. This is one of Alexandre from free.
So the overall message, IPv6 is ready for deployment. There is a great deal of implementation to build upon. It ain't perfect. System level gaps absolutely exist buff we are at the stage that we have got to deploy in order to find them so we have got to have people that aren't afraid of doing it and doing it in a production environment, not just a research, not just in a trial but a production environment and that's very important.
The IPv4 exhaustion tools are being built too and your vendors will ship them. Use them where you must but not without IPv6 alongside. Don't let the cocktail get more ingredients without letting IPv6 being one of those ingredients. Bring your experience back to the IETF and help us help others. Thank you very much.
(Applause)
CHAIR: Thank you. Questions for the speaker. No questions?
SPEAKER: You could maybe hold the questions so that Alexandre and Marco have their time.
CHAIR: Okay. No questions. Then the next talk -- so...
AUDIENCE SPEAKER: One of the core of your messages is about the cocktail where the cocktail brings essentially costs to the application developers, and you use that as a message to, as an incentive for the network operators to deploy IPv6. I see a misalignment there. I see a misalignment in -- and this is not really a question, it's more a statement -- I see a misalignment there in the sense that as long as you don't realise that it is the APS that make the bits flow, then there is a business alignment but as soon as you realise that it's the APS that make your network grow and do cool things, then that misalignment is gone.
SPEAKER: Exactly and that's what this presentation was about. That misalignment exists and this is about awareness, that the misalignment is there and just to be aware of it. That what you do at the IP level affects what the applications do. It's not about the subscribers demanding IPv6. It's about whether or not you give the applications somebody decent to work with which means whether or not your network is valuable or not. And if you keep break it go it becomes less and less valuable. That's the point. Thanks Olaf.
CHAIR: Okay. Thank you. The next talk will be by Alexandre Cassen on deployment of v6 in the home.
Alexandre Cassen: I am here to present to you the work we have done in 2007 in order to provide an IPv6 connection to our providers, to our customers, sorry.
So, first, our company provide, Free is the second largest ISP with over 4 million broadband subscribers with ADSL and FTTH. We have providing a triple play set top box to all of our customers. And everything from the set top box, from the hardware to the software, it completely designed and done inside in-house. So on your left, there is the set top box. On the top there is a routing set top box on the bottom the IPT set top box and here is the big fridge [] dislamb. So that having the software component, we can have time to market it and the ability to deploy and to grade everything on the backbone really quickly.
So, it's about IPv6, our statement as a service provider. In 2007, IPv6 was not really needed from us, we'll look at it as a technical interest. It was great, we had a few people with technical geek looking at this, but the first point is that that DSLAM didn't support the IPv6, so we were stuck with the regular 6:4 approach which have some design issue, especially with dot exposition and not really fit our need. And what we like to do when we push a new service to our customers, is to push on the big red button say bam, I want this to be directly to my customer and with the regular 6: 4, we have got some issue with that.
So, I would say, once upon a time, Remis Depris come and knocks on our door and says "I have a great idea. Let me in." We said "Okay" and he explained his idea to extend in fact the 6:4 approach. He calls this 6rd for deployment and we spent the whole night sketching the work flow to say, it's working so we need to give it a try and to start working on a prototype for the CP and for 6 -- gateway. So we did this, you got the time line and in December, we launched this service to, big red button to all of our customers. And in March we launched IPv6 only service called Telesite and what's important here is what is Telesite? Telesite has the ability for any content provider to push any data to the IPv6 set top box of all of our customers. The fact is that our IPv6 stuff is inside the IPv4 network and the content provider on the wide Internet. So, there is the need for kind of a CGN stuff to translate the stuff, and so we say, yes, we have got IPv6 so, no CGN, no NAT nightmare with that stuff.
So, once the 6rd idea is? It's like 6to4, regular IPv6 encapsulation into a IPv4, but instead of using a regular prefix for 6to4 prefix, it is using a regular IPv6 prefix, so that a provider running the 6 RG gateways is announcing his prefix using regular routing protocol so the traffic, he can have the control over the routing return pass. You have this on this Internet and for us, it was really a nice stuff. It was a way to provide IPv6 connectivity to our users.
So here is just a slide to give you the user experience on how they can activate this IPv6 service. They just log onto the surf care service and check the boxes and everything is IPv6 for that customer. IPv6 and IPv4. It's dual stack. The set top box, everything is Linux and running in dual stack, v6 and v4.
So, I will enter into much more detail for the 6rd. The 6rd path, it's providing the specification of the link prefix of regular IPv6 address. I mean, you get your IPv6 prefix and you open your IPv4 address and to build this link prefix so that the IPv6 you request to the RIPE must be less or equal to 32 bits so that the link prefix can be a full net. The deep err -- you want to provide sub-net to your subscribers. So, what we get from RIPE, we get that IPv6 prefix and a /26, and we make some specification for the 27 and 28 bits to give them a meaningful -- for example, the 0 was designed just for our Internet, co-networking routing stuff. I mean inter-connection between router and stuff. We reserved 1 and 2 and we dedicated 3 to 6 RG, so that, in our Internet, the 6 RD prefix is that /28 prefix.
So, we can offer to our customer a sub-net ID, we can use a lot of stuff. What is not in the slide is we dedicated another bit after the 60 bit, to address our equipment ought side of the customers. If I want to reach, if I want to operate any kind of administration stuff to the CPE, through the IP stuff, I can reach that box directly through IPv6.
And so, it looked like CISCO art. It is a little. It's our, mainly our networking environment, so we are -- we have a co-network all around and we have got the DSL and -- I will not talk about F T -- because we are supporting network IPv6 here, much more focused on the DSL part. We plug directly into our CRS 6rd gateway, PC on the CRS, pulled multiple 10 gigabit on the CRS and we are currently on our network running two 6rd gateways to load balance the traffic and to have the redundancy.
So, okay at the customer seat, there is a native IPv4 and dual stack IPv4 and IPv6. So, I have some use case, I have got two use case. The first use case is for packet travelling through the 6rd gateways. If a customer wants to reach the Internet, the connection between the customer and the freebox, the set top box is native IPv6 and starting at the freebox, it's entering the 6rd terminal, sending packet to an Anycast address that reaches the 6rd gateway and travel all over the Internet. And the same thing on the, for a packet coming from the Internet. Since we are announcing prefix through BGP, packet are curving inside the gateway by this routing, so it travels back to the set top box.
The other concept is like, the 6rd is an evolution of 624. It's set to set communication directly made between CPU. We don't put the traffic to the 6rd gateways.
So, here I have some kind of techie, geeky stuff. I will not free enter into detail with the configuration stuff. This slide is just to give you the full picture. This slide, you take this slide, you take a Linux box and you will be ready to run a 6rd gateway. So this, I will present the CPEs and the 6rd on the CRS configure. We are running the area to announce that's that's all with IPv6.
The configuration is a 6rd tunnel configuration. The set is we set the tunnel and the IT address and the default routing to the Anycast address of our 6rd gateway.
On the 6rd other side, it's plugged with the 6rd directly -- one inside the IPv6 world and the other inside the IPv4 world.
The configuration: Your have got the v4 configuration. You have got the v6 configuration. You have got the look back configuration to set the Anycast address and you have got the tunnel play ground at the end.
At the CRS side, it's the symmetry of the 6rd gateway. You have got the v4 world, a v6 world and here we are setting the /32 for our Anycast address. So that we can be bugged and we are setting a route for our prefix, the /26 prefix we get from RIPE and our 6rd prefix of /28 directly routed through the 6rd gateway.
And on the BGP configuration, we are redistributing our connected route and that's all for the configuration.
Here is a work we done with you are our friend at Google. It's I think the hands on reversibility. Because of the rate that our customer that checks the box for IPv6 can be black-holed to access Google, because of any issue on our side or any other side over the Internet. So, what we did is we dedicated a /24 class and ask to Google to reply to that, to request coming from that IP address inside that /24 class with the credit answer to google.com. And our side we are setting the IP address source to set the request to Google. So that if we got an issue on free network, I can stop sending request with the IP address and symmetry if Google don't want no longer to reply to the credit, they simply stop the replying credit for us. But this is a work just for the transition with Google. This work right now is over and there is kind of, we can white list this. It's working for two years, so right now, it's working so it's kind of outdated.
And finally, I have got some traffic shape. First, our customer number right now, the last week I get results of the statistics, is more than 310,000, and daily traffic is like that. And much interesting stuff are coming. It's yearly traffic, it's both 6rd gateways, and it seems there is a kind of IPv6 traffic rising right here.
Here is the global aggregation of all the graph for the IPv6 traffic all over our network, yearly with one day average so that the graphic is kind of...
So there is a rising traffic for IPv6.
So, okay, here is just the last slide to give you some resources if you want to dig more into detail with 6rds, there is Remis Depris draft and there is upcoming work done by mark and Remis to extend and to push the 6rd current specification to another level of standardisation. Targeting really the standard track. There is also an incoming CISCO book from early, there is this presentation you but into much more detail and today we will push to the kernel development of Linux all of our 6rd. So if someone wants to give it a try, today we will push everything. It's not out of line but we will push the thing.
So, I am done.
(Applause)
CHAIR: Thank you. Questions for the speaker?
AUDIENCE SPEAKER: I am Kostas, I work at OTE SA, which is the largest ISP and telephone incumbent of Greece. We are facing now with -- we are face with this scenario how to introduce IPv6 in our negotiating? Do you think that all of this would have worked if you didn't control everything, the set top boxes and the DSLAMs
A.
No, in this presentation -- we have got the -- on the CP hardware and software -- everything. And so that we can rapidly 6rd deploy that stuff, but I hope that for the future, there will be a standard that will push this technology to the CPUs, to the vendors and to the generic, because we have got lots of customers and it's working, it's working.
AUDIENCE SPEAKER: It's an amazing work,. Congratulations.
Just to make sure that it doesn't involve the DSLAM. This question was do you need the DSLAM.
AUDIENCE SPEAKER: Only CP?
SPEAKER: Yeah.
AUDIENCE SPEAKER: And the core the 6rd, the gateway, which is a standard Linux box, with 10 gigabit interfaces connect to go your CLS?
SPEAKER: Yes, 10 gigabut currently 10 gig is kind of super sides, but yeah...
AUDIENCE SPEAKER: Very well. Thank you.
AUDIENCE SPEAKER: I just want to say well thank you and congratulations for actually doing this. All the big telcos are waiting for something to happen to make IPv6 demand show up and you have pretty well demonstrated that there is demand there. There is customers using it and it's working and there no reason to delay this any longer. Thank you very much for that.
SPEAKER: Just that comment, when we look at the traffic shape that is rising, one important thing to say is that it is not peer to peer traffic. It is direct traffic through the IPv6 Internet, because peer to peer traffic is directly concentrate to our customers and since we have a lot of customers, most of our own customers will download the same content so the graphic, the IPv6 traffic is rising is really a it's not peer to peer traffic.
AUDIENCE SPEAKER: Neil O'Reilly, University College Dublin. I have a little bit to add to what Gert said. He said most of what I wanted to say. I want to say this was a really good piece of work and an exceptionally good presentation. And especially valuable were all the configuration examples. It's a great encouragement, not just to the kind of people that Gert mentioned but also to large enterprises and universities, that, hey, you guys have done it we can follow easily and you have made it look -- well, it won't be easy, but you have encapsulated your experience in that presentation and I think I was surprised that nobody applauded at the end of what Gert said.
(Applause)
CHAIR: Okay. Then the next slot will be Marco Hodgewoning, who will be talking about essentially the same thing, deploying IPv6.
Marco Hodgewoning: Welcome. I am basically on the same topic as Alexandre, although we feel it sufficiently different that we should pay attention to this. Well spend sometime on this as well. I am Marco Hodgewoning, I look familiar, yet I lost the hair, this is about a company I worked for, XS4ALL, basically how to get that 4 out of the logo and back into a 6. This is just a first draft.
The stuff I am going to sell you is still very preliminary. It's only the first steps, we have been working on this for about two months, but we feel we have done some breaking work and we would like to show you what we have done and maybe get some support.
The slide on the company. XS4ALL is the oldest Dutch ISP, founded May 1st 1993, which is slightly over 16 years old. We have origins in a group called hack particular. One of the things we found is cofounder of AMS-IX.
Since December 1998 we are 100 percent owned by KPM. At the moment we have 200 employees on the outskirts of Amsterdam and we serve about 300 thousand customers. Currently DSL, hosting and colocation.
Our IP history goes back as far as back as the company. We got space in 2001 followed up by real BI block in 2002. We have been running a tunnel server ever since we got IPv6 addresses. We also felt there wasn't enough content, so we launched a free IPv6 use net servers in October 2002, already recollect it's called this. It's still there, it's still open. Road only. In 2003, already, I think we had first DSL line with IPv6, which was a small hack using a point to point tunnelling protocol and some transparent modems. Other experiments involved Google over IPv6, we have been running that for about six months without a problem I must say.
At the moment, we ship out approximately 300 megabits per second on IPv6 traffic. The graph is right there. It's mostly use net reader traffic. These are actually human beings using IPv6.
Our network set up in in in contrast to Free, we just buy wholesale access. On the left side, which is we have some aggregation stuff, which in our case are Juniper E320 routers. We have 8 of them. In the middle, it's built offer Ethernet VPLS roughly operates the same. And on the right side. There is the CPE. Again, we supply CPE if a customer shows up, but it's completely free. If he doesn't like it, he is free to go to a shop, buy any CPE off the shelf, it will work. So we are open.
Well, that brings us to the initial requirements. We wanted to be a platform or vendor independent. It's really important for us to use only open standard. If the customer doesn't like what we are offering, have him buy something else and it must work.
The other one, and that's something we have been finding around ever since, is that on our PPP links, we want to have local scope only. Reason for that, a lot of vendors told me to start up route advertisement. Have the modem able to configure itself. We get untraceable addresses. If you have seen the presentation from yesterday, we operate on the under Dutch law. We can't cooperate with untraceable addresses because somebody somewhere in the end will show up and who is the customer behind this address? And well it's like ... we don't know. So, it's really a requirement for us to go large scale is get rid of any untraceable stuff in our network.
/48 we are customer, why bother with 56, the policy says 48, we don't want a discussion with our customer slapping us with the policy 48. Because it's not NAT, we require fire wall. The CP must have a fire wall available in it.
Well, back to the original subject: Native deployment. First working attempt May last year. Well working with slight problems. E320 a bit unstable. We turned on one lig configure option and it decided to reboot.
CPE: Still largely expensive. CISCOs not really suitable for your average home user and another main issue we had was we didn't have load balancer and yeah, we can provide native DSL but we would also like those customers to have something to play around with, is we need to provide services on IPv6.
Just a short configuration example. It's really not rocket science. It's all in the manual. This is all you need to get native v6 working. It's only 20 lines, it's 648 bytes and the the box works.
CPE, this is an example for a CISCO 807 I have done. This is all you need. Of course the correct IOS version might help. But cut and paste this in, this will work.
It's not rocket science, we have been running that for a year.
Why am I up here? This is the real news. Modems we supply at the moment, if you subscribe, is called the AVN print box, it's a small German company, it boxes everything, all wireless, decked, a huge force over implementation and we have been pushing them around to do v6 for about two years, and all of a sudden, in March this year, press release came, it's ready, we do v6. So, 6to4 and native, and well we have seen those launched before, what do you know? It worked. It's not paperwork, they to say it on my desk, plugged it in and it worked.
The other big news: This retails, this particular modem that can to this, retails for approximately €190. It's still expensive. It's not the 20 dollars you want but then again we didn't order 20 million of them. So... forget about expensive CPE. It can be done.
Well, it works.
Footnote: It's better. It's loads better. You can't even get it unless you talk to me because we are distributing it with.
Still German-ish. It's about half translated, it's half English, half German, you are to speak like eight languages to configure it. Other main problem: It requires route advertisements on the want connection. We told them not to do it but yeah, it does. So we now have untraceable addresses in the network. So we solved that by dropping the connections, so you can't do anything with that address and you can't do any harm, so we think we might get away with it.
There is no fire wall in it. They forgot about the other requirement. At least they did the sensible things, they now drop all incoming connections so the box is safe.
And there is no manual configuration left over there. So, yeah, you can put a little tab saying yeah, I run v6 and that's about it. It doesn't take manual addressing whatever, you can't configure the route advertisement.
And another main issue: At the moment this is not the modem we ship to customers. This is successor. So if we want to roll this out, it requires hardware to operate, well imagine my boss doesn't like me to order 300,000 modems, our customers would like a new one, but...
So the current status: Our provisioning tool is called VI, which kind of limits the amount of users we can actually support to maybe 500 or 1,000, but certainly not the 300,000 we have. In fact, we have 15 lines configured at the moment, twelve of them are active, none of them are -- we have one line at our supplier which makes it easy for them to trouble shoot and we have one paying customer. He is in the room...
And the second one is actually on the way to post office to pick up her modem. Traffic, combined it's 40 megabits towards the customers, we see 600 kilobits incoming. I can only assume that's people actually reading news net. We don't trace it much further than that.
So, we're we are now. Where do we stand? This is the current status. What are we going to do next? Well this is a rough road map for the next six, nine months. It's very hard for us to get vendor to implement it. We have been keeping track of the ITF, the work Marco has done the broadband forum, but it's still all draft. We have guilt or or CPE specifications document. We wrote down this is what we need, this is how it should work because that's the comments we get from vendors. Yeah, we will implement v6 but please tell us how to. What do you want? What do you don't want? This first one, we tried to hook into the IETF drafts as much as possible, point to RFCs if they are there. So stick with the open standard but get everything in one place, if you want to supply modems and you want us to support it or maybe even buy those, do this.
Of course, the main issues is want to get rid of the route advertisements and get a firewall or at least get a little knob to turn it on or off. The vendor is working on a back board. The initial report was that the current install base didn't have enough memory to support v6. They are now looking into stripping other functionality and to get a v6 firm wear out there so that we can supply our customers with firm wear instead of a new modem, which makes roll out a lot easier.
I am starting a project as we speak to get services working. We can offer customers v6, but it's very hard if they don't get to play around with it, so mill servers, DNS has to do with v6.
Other main issue: Monitoring, containment, in case somebody does start spamming on v6, we probably want to shut them down. At the moment it's very hard, it's all manual labour and we want to automate it as much as possible.
Provisioning database needs to get fixed, get rid of the VI stuff and at the same time, we try to get a small pilot group together, to get it going. Other stuff: We are planning on to do some hands on session for our colocation customers. Show them this is v6, this is how to configure it just to get the content there, get some people to play around with it.
Other main thing: Create public awareness. We have been considered an opinion leader here in The Netherlands. We have got large amounts of valuable media contacts and we are using them. In fact, today there is a press release announcing that Olaf is our first customer and not only that, we included about 1 A 4 about what v6, what is the problem about how to solve it.
We participate, we are here, we are running the IPv6 taskforce, everything we can get our hands on, giving the message, it can be done:
So, why are we doing this or maybe why shouldn't we? Well, there sure is no customer demand, people aren't exactly lining up on our doorstep. Well, they are in this room, I have been approached by three or four people already, can I get? Well then you are not the average customers. The average customer count know he has a problem so the average customer will never knock on your door saying "I want v6." You have to tell him he has a problem and then he will probably ask you to get v6. But, at the moment, there is no positive business case. This is costing us money, we are not making it.
So, why do we do it? We see it as a necessity. V6 will be there in the end. There will be somebody running out of IPv4 addresses, there will be v6 only services, we have to go there. In the meantime, like I said, explain to the customers what's happening, create our own demand. We can sit here all day waiting for the customers to knock on the door. The customer is unaware.
.and last but not least, if he knocks on the door, we want to be ready. Be ready for it. It's like we are riding a bike again. You fall over every time. You have to stand up, fix another birth, oops that's not it, the only way to do it as Mark pointed out is to run it, find the bugs, solve them and go with the flow.
So the main reason we are doing this because we can. And moreover, we are doing this because we care. The good of the Internet, but we also care about our business case in let's say 2012, 2014, when we run out of IPv4. So, that's it for me. Questions, comments, I'll be around all week, you can also send me e-mail. The address is right there. I have got colleagues running around if you can't find me.
(Applause)
AUDIENCE SPEAKER: Hi, do you have any initial ideas about load balancing? Of course this is a question I would also like to ask to Lorenzo, I guess it has more to say on the subject but do you have initial thoughts?
SPEAKER: Well, yeah, we actually -- we thought we had it solved. We are using Foundary equipment, we got it working. We have got an initial release running, Foundary, as you may well know, has been taken out to you [] Brook 8 which took a look at their agenda and slightly modified it, so they are now told us that the current version we are running is end of development and all books I report are considered feature requests which are no longer accepted and we have to wait for the new platform, which at the moment is vapour wear, so we have got a slight issue there. We are trying to work it out together with [] Brook 8 to get better testing on the new firm ware and new hardware.
CHAIR: Thank you, any more questions?
AUDIENCE SPEAKER: Hello. Affilius, RIPE NCC. You just mentioned something about the policy requirement and maybe a /48 for the customers. This is coming often so I wanted to make a clarification, I know you know it.
In 2007 the policy was changed and now LIRs are free to make any decisions about assignment size for their customers with IPv6, yes, there are some, you know, guidelines that are being followed, but, as far as the policy goes, it is not a requirement any more. Thank you.
Lorenzo: One question about firewalling. So your requirement stated that the CPE must drop, or your implementation was that the CPE will drop any current connection.
SPEAKER: That's the current status and we like to have a fully configurable firewall. All our current v4 networks which run NAT and has a firewalling. We basically on v6 want the same thing so on a host by hose basis allow certain parts to come in and certain parts to be dropped. But in the meantime, we already would be happy if the current would chance to have a little knob saying allow all incoming connections. Then at least you can play around with it. If the default is still to drop all incoming connections, we are happy.
AUDIENCE SPEAKER: I ask, because some very widespread operating systems have Teredo addresses and basically if you know their address, you can -- you are basically not going through the CPE firewall at all. So since you can already talk to these systems, why firewall at the CP as well?
A. Well, in the end, the box as is currently stands starts spreading out route advertisement. So if you show up with your Mac, hook up to it, it will get an IPv6 connection and, well, people might not be aware that it's running v6, so people might get surprised that, all of a sudden, they see activity on their mill server because it found out it had an IPv6 address and it defaults to an open relay and we have to get them off again because they are spamming or being abused without even being noticed that they are being abused.
AUDIENCE SPEAKER: You'd have to guess their Mac address or you'd have to know where they were.
SPEAKER: Yeah, our you'd have to see other traffic coming from that host and know that they are alive. So yeah, it's far short but we do like to get as secure as possible, at least in the default setup.
AUDIENCE SPEAKER: Olaf: I think that the aspect from the user end is actually important. The way I experience this is that it was a little bit awkward to have to cycle to the offices to pick up a modem. But otherwise it was just as getting a modem shipped over the mail, connecting it, turning it on, doing absolutely nothing, connecting to an IPv6 site and seeing that IPv6 just worked. I didn't tell my wife. And she didn't notice any de/TKPWRAEUGS or improvement of the service, and I think that is an important message. Things just work.
SPEAKER: That's the way we designed it to work and that's the only way you can roll it out. In the end, the customer is agnostic about addressing, v4, v6, the guy thinks you are talking about car engines, he doesn't mine as long as his pictures comes in if he clicks on something and that's the way we want to run it. That's it?
CHAIR: Okay. Thank you.
(Applause)
The last speaker of the session is Maria Boen from TNO about measuring IPv6 deployments. This talk is actually an introduction. There will be a longer session this afternoon in the IPv6 Working Group where things can be discussed in far more detail.
Maria: Good afternoon. My name is Maria Boen from TNO, Netherlands. First of all, I would like to thank the RIPE organisation for giving me the chance to give a presentation about our study, IPv6 deployment monitoring.
First of all, some background information:
Last year, the European Commission adopted an action plan to support the deployment of the IPv6.
The important objective of this action plan is to support the widespread introduction of IPv6 in Europe because:
We know that the timely implementation of IPv6 is required as the pool of IPv4 addresses is being depleted.
And also IPv6 with its huge address space provides a platform for innovation in IP-based services and applications.
The action plan sets out a number of measures that should have a measurable effect on the adoption of IPv6 in the market.
And the last is: That the action plan aims to achieve widespread availability and use of IPv6 by 2010. This objective is quantified to mean that at least 25% of users can do their essential Internet activities without noticing whether they are using IPv4 or IPv6.
One example of the last customer access for all shows that it happens. I am very happy to hear that it's really, it's really live for the first customer in The Netherlands.
And what is the objective of the study? Is to measure the deployment of the IPv6 in the European Union in 2009 and 2010. It includes also the availability, quality and the usage of IPv6 products and services.
The study also determined as to whether the 25% targets as set out has been achieved. This is a kind of measurement moment to now, where are we now?
The important key points are:
The prevention of wrong timing, because if the customers' ISPs are not aware of the necessity of IPv6, then they will not start timely, and the European Commission also has some policies to stimulate the using of IPv6. And more information is needed for the focus and it is really your assistance to us is essential for gathering all that information. And your assistance has really a positive effect for the future and it is highlighted no privacy issues are involved.
So, it is an announcement from our side that we need your help in gathering information under the IPv6 deployment for the purpose of policy making in the future.
The EC wants to create stimulating policy and measures for IPv6. To look at the right policies to stimulate the deployment of IPv6. And the policy can range from stimulating the resource and development on IPv6 in Europe for example if the F P 7 projects, inform and create fora for users about IPv6 possibilities.
So our aim is. Of the study is to develop and use new methods in cooperation with RIPE community. We would like to measure the development of IPv6 in European countries, the percentage of the end users, we would like to measure the availability, the present states of the availability services, to measure the differences between IPv4 and IPv6 performance and also to perform an IPv6 survey. For this part recollect the last part, there is this afternoon, a special session on IPv6 Working Group. The partner of TNO will also give a presentation of it. And the measurement part, it will be taken on Friday, together with a session of AMS-IX.
So, to be focused on the policy making, there are more information needed, because the current measurements are focused on volumes, but some additional information is also needed. Amongst others the number of used addresses about the end users, and do companies do the migrating and considerations whether to migrate. And if this information can be gathered from interviews, surveys and high level measurements.
So, we think that it is very, very important that we are assisted by the RIPE community so that we can find the right experts to do the measurements and also the survey and to reach the relevant stakeholders with the survey. And with the assistance of the AMS-IX and its members, we can gather relevant high-level data.
And we think that your assistance to the policy makers will have a very positive effect.
You will know what data is used by policy makers and gain insight into the IPv6 user volumes in an anonymous way.
And for the survey part, the details of the surveys and also the measurement part will be presented during the today, on the IPv6 Working Group and for the measurement part on next Friday.
We are calling on the RIPE community to help us shape this survey to yield the best results.
We would like to thank you beforehand and we would appreciate your participation in the questionnaire and also the facilitiation of the measurements.
Our project manager, Paul [] till an us, you can reach him by the information here, but you can also contact me and we would really appreciate your help if you can contribute to this study project. The goal of us is to get a kind of starting point to know how far we are in Europe with the implementing of IPv4 and IPv6 and also, to make the success of the implementation of IPv6.
Thank you very much.
(Applause)
CHAIR: Okay. Thank you. Questions for the speaker?
LORENZO: Lorenzo from Google. One question: The definition was kind of hard for me to understand. The definition was that a user can use IPv4 or IPv6 and not notice. It was quite early on.
SPEAKER: This definition, the last bullet?
AUDIENCE SPEAKER: So, I don't know if this is what we are trying to measure or not. It's not clear to me, but I mean, I could say that today 100 percent of users can to their essential Internet activities without noticing whether they are using v4 or v6. Because they are using only v4. So the subjective is met and we can go home. So I guess the question is: Is this also what we are trying to measure? If this is the objective that we want to meet, that's one thing. We have met it, okay, horay, but if it's what we are trying to measure also, then we shouldn't be trying to measure it. Because this number will always be 100 percent.
SPEAKER: It is stated we are using IPv4 or IPv6 and IPv4, I agree, it's about 100 percent and for IPv6 we don't have any information about it.
AUDIENCE SPEAKER: So the point is that the users can use the Internet without noticing what they are using, that's true today. They use the Internet without noticing what they are using and it's true that if they don't have IPv6, they can do everything that they need to. So, I guess I don't understand how this metric can help us see how much IPv6 is being deployed.
SPEAKER: I think we have to make the definition sharper and we will in fact focus on the IPv6 parts of it, we would like to see how much end user are using the IPv6 and based on that, then we would like to take a look at the integration of it, because as you said earlier, that if we are looking at only IPv4, then we have 100 percent, but we are, what we are now going to do is first take a look at the IPv6 itself. A colleague of mine will make some additional information on it.
Thanks for the question and of course what's in a definition? I think what's it's really about here is is that the European Commission and Council agree on that it's necessary to really make a provision of mainstreaming IPv6 and that's what it's about. This definition that comes from the document is there, but it's really about how do we get IPv6 up and running here in Europe before we run into brick walls or whatever? And I think the nice thing about this is that there is a Government to say, hey, Internet community is there, and it has become so essential now for our lives and economics, that we cannot say we'll leave it to the Internet community alone. Let's see what we can do to help make that happen, and what we'll try to do with the project is to come back to the Commission. Also are suggestions of things that would make sense for them to contribute to and to help us all to make sure that we can continue Interneting effectively and that may need to include IPv6 as well. Does that help?
Daniel: Let me try to bridge the gap here. What you have on the slide there is a political statement. What you are saying is like you know, that is, what Lorenzo is saying we can't measure political statements, we should probably measure stuff that we understand here. And that's actually why these people are up there. So don't -- they are coming here and saying hey, you know, we could make up some figures, which is what usually gets done, so, let's do something meaningful and that's what that he made them come up here, the guy who spoke to us in Berlin. So what we need to do, and I hope we can do a little bit of help, helping them in the IPv6 Working Group on their survey, is actually to get useful results that are interesting to us as well, so it's a cooperative effort, and that also allows the politicians to make some statements about what happened with those goals. And that's what we have to do all together, rather than being antagonistic and saying this is not interesting or we can go home or things like that. So this is what's before us but not now because lunch is coming up. It's in the IPv6 Working Group after lunch.
AUDIENCE SPEAKER: Okay. So that's fine. We have data actually today I am going to present some of the latest data that we have been analysing recently and we are certainly open to share the methodology, sharing the data itst a little more difficult because there are strong private implication to say it but that is more difficult. But we are certainly willing to work together with you on methodology and to try to come up with numbers that mean something, and can be used to track something real as opposed to some nebulous definition.
SPEAKER: Perfect. Thank you very much.
CHAIR: Final question.
AUDIENCE SPEAKER: It's not really a question. Matt Forde, ISOC. Just I don't know if this helps but for the record the text of the action plan actually says, "At least 25 percent of users should be able to connect to the IPv6 Internet and to access their most important content and service providers without noticing a major difference compared to IPv4."
SPEAKER: Thank you for that addition.
CHAIR: Okay. I think that concludes the session. We will continue at 1:30 and lunch is being served.
(Lunch break)