IPv6 Working Group
Thursday, 17 May 2018
At 4 p.m.:
CHAIR: Good afternoon and welcome to the second slot of the IPv6 Working Group. Today, we will have some different sessions about every different kind of thing, but let's start with the Working Group Chair selection. As all of, you know, all of us sometimes have to step up and down. This time, it's Jen's turn, and could you ‑‑ would you like to come here and do you want to stay there? It's fine with me. So Jen has been doing this for many years, three‑and‑a‑half, at least, yes? Yes. And she is stepping down now because our protocol says you should do so. Now she has stepped down. Then there was some re‑election possibilities, on the mailing list there has only been support for Jen and I have seen no one who wanted to say something against her. Is there anyone in the room here who dares to? No. That is very good. You will behaving much better life after this. So as far as I can say, Jen, you are re‑elected. Congratulations.
(Applause)
JEN LINKOVA: Thank you very much. I am honoured, yes, so you have to see ‑‑ another three years, don't blame me, it was your choice. Thank you very much.
CHAIR: They wouldn't dare to. Before we go on, please remember to rate all the talks, so we have some idea what you like and what you don't like and we can make sure it is based on those in the future. So, so next up we have Mr. Sébastien Ziegler and we are going to have to do a lot of tricks to get him over Skype here. This is the IPv6 reference model for IoT, and it's been written by Sébastien and he is working for the ITU. Can you hear us? Good afternoon, welcome to the IPv6 Working Group.
SÉBASTIEN ZIELGER: I can hear you, but ‑‑ okay. Can you hear me now?
CHAIR: We do.
SÉBASTIEN ZIELGER: We are on the phone. Thank you very much, you should have received slides, I don't know if you want me to send my screen to show you the slides if you want to use them ‑‑
CHAIR: Yes, please.
SÉBASTIEN ZIELGER: I think you should be ‑‑ there it is. So good afternoon everybody, thank you for the ‑‑ so I am representing [inaudible] ‑‑ ITU ‑‑ serving ‑‑ [inaudible] I will give you a brief introduction, so we [inaudible] for many years in research ‑‑ [inaudible] ‑‑ IoT ‑‑ this study was result of such activity [inaudible] ‑‑
CHAIR: I am sorry to interrupt the quality of the sound is incredibly bad. I don't know what would help, but at this moment it's very difficult to understand what you say.
SÉBASTIEN ZIELGER: I will try to switch the microphone from my end and check it again.
CHAIR: Feel free to do so. We can get your presentation here locally online and if you just say a word we can change the slides to the next one. It will save your bandwidth a bit.
SÉBASTIEN ZIELGER: Do you hear me better now? Maybe I will speak slowly, first of all good afternoon to everybody, and it's a pity that I cannot be with you, it would have been a pleasure but I hope we will opportunities to meet face‑to‑face. As I mentioned I am not working for the ITU, I am serving as ITU members ‑‑ but I am working for ‑‑ in this presentation I will present you the work that has been currently developed at ITU ‑‑ to design a reference model for ‑‑ IPv6. A little bit on the slides ‑‑ work quite [inaudible] ‑‑ ITU, and ‑‑ by adressing, where we could avert IPv6 or Internet of things network. We have such projects for which we attempted to [inaudible]... use of IPv6 to support ITU plus. ...[inaudible]. ...some of this projects you have seen the slides, minutes ‑‑ some pubnet. ...project, ITU 6 which is [inaudible] ‑‑ in which he had ‑‑ all the projects ‑‑ currently exciting projects and. [Inaudible] ...synchronicity. Some of the concepts which I present are. ... [inaudible] will be published IEEE a few years ago and the fundamental ideas address some of the many issues [inaudible].
CHAIR: I am sorry, the sound quality is very bad again. Do we have the slides local already? We are going to switch to showing the slides local and just give a word when you have to change the slides and we will do that for you so you can save some bandwidth on this.
CHAIR: Can you test it now?
SÉBASTIEN ZIELGER: Do you hear me?
CHAIR: We still hear you.
SÉBASTIEN ZIELGER: Is the sound better?
CHAIR: At least for this moment, yes. So I don't see what is happening on your side now, so I ‑‑
CHAIR: You can give us a hint when we should change slides. At this moment we have only your first slides so just put it up. Now we have the worldwide map from Google.
SÉBASTIEN ZIELGER: Okay, very good. So as you see the good news is that IPv6 is ramping up, so that is very good news in terms of adoption. The band use is quite heterogenous in terms of adopting and facing a new digital divide, in terms of adoptions, with countries like US or Switzerland, with very large rate of adoption. And other countries like most African countries and developing countries which are lagging behind. Let me just open the slide on my side too. So one of the motivation for ‑‑ is to ease global adoption and adoption by IPv6 by end users all over the world. And to prevent its IPv6 digital divide between developing countries, between industrious countries, some developing countries like India and the rest of the developing countries. It's also to anticipate the expansion of IoT as you all know, given the figures that ‑‑ over 50 billion connected devices ‑‑ so as also to provide customisable reference model ‑‑ to easier policy management very clearly other groups addresses and to the interconnection and multiple IoT networks. When we started working on this model we follow four main guidance ‑‑ reference mod ‑‑ [inaudible] ‑‑ evolution, cluster support from IPv4 to IPv6 and ‑‑ finally IPv6 only ‑‑ and then to enable simple and constant filtering [inaudible] ‑‑ the recommendation ‑‑ make you can move, I don't know if you are still on the slide with figures? Move to the slide on.
CHAIR: The slide we are on is considered requirement.
SÉBASTIEN ZIELGER: Maybe you can look to the next slide. Thank you.
CHAIR: Focus on subnet addressing plan.
SÉBASTIEN ZIELGER: The focus of this recommendation is really and exclusively on the subnet ID so not interfering with address location. Neither the host ID which may be many cases devised [inaudible] and the focus is really this part of the IPv6 address structure which is managed and controlled by the end user. You can move to the next slide. So on this basis what we did is to see how to leverage on the subnet ID and this is///48 and see how we can ease the organising subnet address plan ‑‑ IPv6 and IPv4 ‑‑ finally to full IPv6 ‑‑ IPv6 network environment. Can move maybe to the next slide.
CHAIR: That is done. You still have about five minutes.
SÉBASTIEN ZIELGER: I will try to ‑‑ so in this slide you see the segmentation in which we worked, proposing default allocations, again it's reference model which can be customised by the users, just to give some guidance of ‑‑ you have five main sections, DMZ, Internet server, regular LAN, then we have substantial section for IoT and building automation and we have a fixed LAN which is reserved for flexibility. This is this enables for instance to extend the IoT and building automation to subnet address space or to extend the more regular LAN to the space or ‑‑ it gives more flexibility. You have then the first part of the table is about IPv6 IPv4 addressing, and one of the ideas to enable between IPv4 ‑‑ [inaudible] ‑‑ addressing plan dual addressing, and which means that last one [inaudible] ‑‑ the second the category of group allocation, set ‑‑ IPv6 so can came the same addressing for the previous addressing plan but then we extend by using a first and last, in this case ‑‑ [inaudible] ‑‑
What we did is make sure that we can the same approach subnet allocations, address allocation, can move to the next slide. /56. /56 again the same approach except that due to the ‑‑ you have so we can have more mapping and/44 is the next slide.
CHAIR: Done.
SÉBASTIEN ZIELGER: Then again we try to follow the same principle, to propose a reference model which can be used for also the transition phase to have consistent addressing plan with IPv6 and IPv4 and then IPv6 only ‑‑ the whole potential of the address allocation. The same for /40, which is next slide. Or /36, which is the next one. Thank you very much. And then maybe next slide. So for us it's an opportunity to listen from you to try to collect comments, suggestions, proposals, if you have any idea to improve the models, against a model which is designed to reference model which can be fully customised. There is no formal description for it, it's a reference model that can be used and again your expertise is welcome ‑‑ [inaudible] ideally to help ‑‑
CHAIR: Okay. This is your part, I guess.
SÉBASTIEN ZIELGER: Yes, it is.
CHAIR: There is going to be quite a few questions here in the room, first one is here from Jordi Palet.
JORDI PALET: Hi, I just saw the slide that said that the invitation is for the NCC not for the community.
SÉBASTIEN ZIELGER: It's for the RIPE community but as ‑‑ ‑‑ [inaudible] you can consider it for the RIPE community.
JORDI PALET: Also are you following the mailing list because we have provided a few comments in the last couple of days and we didn't get any answer?
SÉBASTIEN ZIELGER: I subscribed, I think, two months ago, but I didn't receive any mail so I send again mail this morning to Marco to understand what happened. But I subscribed a really long time being with you didn't receive any reply, I thought it was silence, but today, I asked, again, Marco, so I don't know what happened.
CHAIR: We will solve that later on.
SPEAKER: Hello, Mr Ziegler I am Taha Sha, consultant for German government. As I understood ITU papers a recommendation is a declaration for a document which will perhaps have a chance to become local legislation in countries, isn't it?
SÉBASTIEN ZIELGER: In some cases, yes. Which country to decide.
SPEAKER: German government is enrolling in the public administration IPv6, very success flee. We have already schemas adapted to police, to public administrations to monsipalities and every part of the country which totally doesn't have anything to do what you presented. So, if your recommendation would be a local legislation, you will stuck our country in enrolling IPv6 in the public administration.
SÉBASTIEN ZIELGER: I don't think so. The way we worded the recommend day, we are very careful not to force anybody to adopt ‑‑ [inaudible] if a country would be like to ‑‑ to prevent any position [inaudible] ‑‑ fully customised ‑‑ does not to lead the way any user is structuring its ‑‑ so only reference for that can be used as but not as to ‑‑ [inaudible].
SPEAKER: We don't hear you any more. Chair chair the sound quality is ‑‑
SÉBASTIEN ZIELGER: I am sorry. The way the recommendation is worded we were very careful to word in such a way that it cannot be, cannot impose anything to anybody. It's very clearly worded, it's just proposed a reference model that is expected to be customised, atopped ‑‑ floss incentive which say you have to follow [inaudible] ‑‑ it's only a starting point, for those who answer guidance and hope the structure [inaudible] ‑‑
SPEAKER: Let me have one statement on what you have done and one question, if, okay.
SÉBASTIEN ZIELGER: Yes.
SPEAKER: The question is, we read your document and we didn't saw any real argument for that this is needed, as it is ‑‑ there are some ‑‑ somehow statements about the development of technology now but it's no real legitimation why this is needed, why such a schema is needed. Do you ask for replies on your work? This is our reply, or my reply, and a real interesting question for me is, who pays you for this?
SÉBASTIEN ZIELGER: Thank you, I will answer those questions. The statement first. Or maybe the I will answer the question first. I am paid by Mod International which is a foundation, which is an independant foundation. Our revenue comes from research activities, research projects this work is not subsidised by any government or company interest, to be very clear and transparent. We are working on IPv6 and Jordi I think knows me since many years, we are working on IPv6 since many years, we have been also confronted over ten years ago when we started working on IPv6 to many troubles regarding the deployment, in particular to enter the legacy, to see how could manage security, different addressing plans [inaudible] ‑‑ and we started to [inaudible] to lose a lot of time to reconfigure, to restructure the plan, to [inaudible] for efficient and ‑‑ so his answers [inaudible] those who ‑‑ what you propose is a can save time, money and energy for those who want to adopt.
CHAIR: We move on to the next question, it's again Jordi.
JORDI PALET: Sébastien, Jordi again I try to understand your document and I can tell you that I have done consultancy for IPv6 and deployment, only counting governments for a more than 20 and 100 ‑‑ enterprises and ISPs and it don't make any sense what you are proposing, if you really have experience in operating networks and deploying IPv6, believe me this is no sense at all, it's ‑‑ that is why I was asking if you are in the mailing list which is open so I don't understand for the problem for you to resist, nobody has any problem, but believe me, this is something absolutely useless. I think you need to participate in registry meetings because some of the things you are saying are even against policies and you need to participate in IETF because even the terminology that you are using, it's broken totally.
BENEDIKT STOCKEBRAND: I sent a longer comment to the mailing list because this is going to be longer in more detail. Anyway, when it comes to the mailing list there is an on‑line archive so you can read the old existing mails going through there on line on the web forum. What I have seen from, when I have taken a look at your thing, you have pretty much arbitrary categorisation of networks, there is some things missing but IoT in there but other possibly important things like voice‑over IP are missing. Having class reserved and others is something you want to talk about, to somebody who knows about standardisation or specification things. The thing is, it doesn't allow for any real options about future development, so it's pretty much outdated by the time you release it. You lock IPv4 and IPv6 together, in a lot of ways which means that you draw ‑‑ you preserve all the problems we have with IPv4, you bring them into the IPv6 world. I missed pretty much any security conversations except calling some networks for DMZ, your project doesn't work with micro segmentation and it will be a complete nightmare for any firewall administrator if you can actually configure it and operate it on a firewall at all without running out of memory, and finally, and this is probably the biggest mistake in there, if you are repurposing bits of the address head ‑‑ fields in the headers for holding things other than what addresses are meant for which means holding routing information what you do is you artificially shorten the addresses and with an Internet growing at roughly 30% a year, that basically means even if IoT doesn't really provide any significant kick in the number of machines you will shorten the usable lifetime of IPv6 by at least 20 years.
SÉBASTIEN ZIELGER: I would be see the rationale behind this affirmation.
BENEDIKT STOCKEBRAND: I will send to the mailing list.
CHAIR: We have one more comment from the time.
JAN ZORZ: I would like to request we take more time for this subject. My name is Jan Zorz and I am speaking here completely on my personal capacity, as a long time IPv6 advocate and member of RIPE community and my views and comments are not necessarily represent the views of my employer. So, since Mr. Sébastien you didn't receive any emails from the mailing list, I will read my review that I posted to the mailing list really quickly. So, first of all, there is absence of problem statement. Technical documents normally identify the problem that they are trying to address. Do you really have a problem? What is the really problem and what are we trying to solve. Is the addressing of IoT devices an actionable issue anyone has? There is no clear requirements. If a problem is defined where are the requirements for any solution. What are the scope of the document and what is the framework under discussion? Lack of documented or experience or good practice. What is the best current operational practice for this problem or has any experimental environment involving many hundreds of devices identified the need for this solution. If neither is the case what is the evidence for that prescribed solution with neither operational nor experimental experience would work as planned. There are factual errors. There are several errors in the document some of them has been explained by other people already. Then there is clear misunderstanding of how IPv6 addressing policy works. Then and my last question is what is the ITU's motivation for doing this? The Internet standards, were developed by organisations involved with its operations and best practices evolved out of their direct operational experience. The network operator communities, for example RIPE, are there best placed to understand to find and implement for the IoT devices. Other interested organisations including the ITU are of course encouraged to participate in this process, raise issues of concern to their communities and contribute to the best current operational practice but should not seek to prescribe solutions unilaterally. Personally, I feel the purpose of this document is unclear and there is a limited value in further discussion of this document for the various reasons described above. I will be open to review future version of this document from LG 20 that will take into account all the above concerns. Thank you very much.
(Applause)
SANDER STEFFANN: Hello, I am Sander Steffann, I actually wrote some addressing plan best practice documents and until very recently was could chair of the Address Policy Working Group. And there is a lot of this document that goes against current best practices, that goes against even the current policies. So in the current state, it's unfortunately not usable.
MARCO HOGEWONING: Speaking on behalf of the RIPE NCC as probably most of you are aware and I thank you for your presentation. We are an ITU sector member, as Sébastien explained in his presentation there is an ongoing exchange of liaisons between the RIPE NCC and iTouch. Study group on this particular topic. We have already committed to the study group by liaising that what I will do after this session and basically next week, I will be collecting all the comments on the mailing list, I will look at transcript of this session, we will look at the minutes of this session and we will all package this up and transmit itssssd a whole to study group for their consideration. With that, respecting deadlines, we are on a deadline to submit those comments June 1st. I suggest that if you have any further comments regarding the content of the document please leave them on the list. Do that before next week, Thursday, that gives me sometime to process it and prepare the statement outgoing to the ITU and in future meetings we will report back on the progress of this. Thank you.
CHAIR: All right. Thanks for the input from the hall here. Sébastien, thank you for your presentation in this community and it was very unfortunate you couldn't be here. Are you still there?
SÉBASTIEN ZIELGER: Yes, I am still here.
CHAIR: I will try to give you some hints tomorrow on how to work with that mailing list and where you can see them on the website and you can use the web interface to use it as well.
SÉBASTIEN ZIELGER: Could you let me know why I was not effectively subscribed to the mailing list, if you can have a look on what happened.
CHAIR: Can you send me the email address you used to subscribe.
SÉBASTIEN ZIELGER: It's the one you have you.
CHAIR: You better do that by email because I can't hear it very well. Thank you very much and we will move on to the next presentation. Thank you for participating.
(Applause)
SPEAKER: It's not going to be easy to jump on the stage after this, I will try.
CHAIR: Just a second, so I answer you. Next is Massimiliano Stucchi and he has something on global IPv6 development.
MASSIMILIANO STUCCHI: Good afternoon. I am happy to see that for those of you who were he here in the previous session, on IPv6, we have seen some data by Geoff Huston, which actually comforted me and showed me what I am going to show you now is in line with what is happening.
What we have done is that, well, late me ‑‑ I am the IPv6 programme manager at the RIPE NCC. This is an effort that I am going to show you that was actually started before I became the actual IPv6 programme manager by Nathalie, sitting there in the corner, it's also part of what she has done.
What did we have? On the 6th June 2012 there was world IPv6 launch day. So the idea was to try to collect some data for six years later, 6th June 2018, which is coming in a bit. We are going to be holding a big event on this day, it's RIPE NCC Educa, I will have more about it later, but the idea was to gather some data, get new data from a survey that was already run in the past, some years ago. There are some ‑‑ it was run in starting 2008, it was run in 2012, 2013 and now it was done by the NRO. So we decided to go ahead and try to do it again. Let's compare the data and see what happened between then and now in IPv6. So we talked to Martin Botterman, who was the person who ran the same survey back in the days and we decided to go with the same exact way of running the survey as we had back then which means we used Survey Monkey, and it wasn't long after we launched, after we published the survey that we got tweets and emails from people saying, well, you are doing a survey about IPv6 but it doesn't run on IPv6, so I am apologising here. But I am sorry, but you have to understand the reason we did it it was that we needed to have data consistency between the survey run in 2013, in 2012 and the previous ones and what we were running now, without having to waste some data in the process. So that is why we went for the same exact way. SPO what happened is that we received a total of 1218 responses that we still have to track. It was closed at the end of March but we also received a few answers by the beginning of April and we received the data from Martin after he processed it in a little bit of analysis last Monday. So this is the reason why, I don't really have that much to show today but this is considered to be a teaser for what you can see, what you will be able to see during the Educa event which I already mentioned.
Now, what do we have? We have 1,218 responses. How to these compare to the previous years. They are a bit less. They were a bit less and what else can we see from it? That 87% compared to a previous 48% from 2013 came from our own region, and thinking about it, looking at this data it might have been a overlook on our side. When we announced the survey and the way we named it, we said the RIPE NCC global IPv6 survey. So it might be that some people in other regions felt oh I don't really have to fill the survey because it's RIPE NCC, I am not part of that region. We still got quite a good number of answers and we started looking into this data, where does it come from, how can we compare the countries between the previous version and this one, and the situation was pretty much the same. We still have Germany, US and UK in the first three positions, and then we have some new entrants like Switzerland and Spain but we lost some friends from other regions of course because we have fewer answers from there. So let's a look at the basic data we can find in here, because as I told you we didn't have much time to look into this but together with my colleague Stephen you will see a picture of him later on we started looking into what can we find here, what are the demographics in here. So organisation types. Basically, no change, what we found is that ISPs were around 50% of the total number, but we also had a good mix of around 10% each so this slide might be a bit misleading, of ICT, educational content and also 5% each of government research and what was classified as other. So it didn't really change between the previous years and what we have now. The other I think that hasn't changed is that wave good mix of customer based size which was only asked a question to those who selected that they were ISPs. What do we have? We have both small and medium, 60%. Also between 10,000 and 100,000 users we have 20% and then we also have other presentation of ISPs, a good representation of those above one million users, one million customers. How does this translate into IPv6? 85% of them, and this is what I called the obvious data, have an IPv6 allocation which reflects actually a little bit more of what we see in our statistics and you probably be able to hear about them tomorrow morning when my colleagues from the registration services department will show them, which 85% means a 20% increase from 2012, actually 10% increase from 2013 so it means things have happened bit in the meantime. Hosted infrastructure and this is a nice thing that we found there, because in the question we asked if you don't have an IPv6 allocation why don't you have it and one of the main answers was, my hosted ‑ I have a hosted infrastructure from a third party so I don't need it, that could be done ‑‑ this could be because of the clouds, which was much less relevant in 2013 than it is nowadays. Now, this is important. I am in the training services department and what we support in our training course is that oh, well, the ‑‑ we have the availability of ‑‑ there is a lack of availability of knowledgeable stuff and this is also what we found in the survey, why you tonight implement IPv6 because I can't find someone who is actually good at that. And then comes cost and then I can't make a business case for my manager, I can't make a business case for whoever is above me to go and move to IPv6. These were the top three reasons for not being able to implement IPv6. And also vendor support as reason for not implementing IPv6 hasn't changed. So it means that probably in the meantime vendors have not done much regarding IPv6 so probably there are new features that are still lacking in implementation. So this hasn't changed. It's nice to see that NAT 64 and ‑‑ is the predominant transition mechanism, we see a bit of DS‑Lite and 6RD and the little two fields there are MAP‑T and E and which had I think a total of two representatives each so only two. But the good data is more than 50% of the respondents say they don't use a transition mechanism.
Now, there is another good news in here, and I really liked when I saw it, so this is a graph that I got directly from Martin Botterman. We asked do you use or plan to use IPv6 together with carrier grade NAT or not and you see the transformation in the years. We went from a good 30% to 0 and that was good. That was good to be seen. I was kind of happy when I saw this. But all this data we got it and with Stephen we were discussing can we trust this data? So we have to find a quick way, yes, we have to find quick way to find out if people are telling the truth. And if you had very limited time available, how could we do something like this? So, we decided to take the question, we had a question like, what is the percentage of users or customers that you have enabled on IPv6? So, let's create a heat map with that and let's compare what we see in that with the data that we can have from Google, from Geoff Huston, from APNIC and from our own RIPEness. What did we come up with? Look at this. So 2013, and in the next slide I notice the moment ago will say 2013 but it's 2018. The higher we go, the higher the number that the respondents told us percentage of users they have on IPv6. And the darker the colour, the more they told us. So look at the change. I can go back and forth a couple of times, look at the change between 2013 and 2018. We moved quite a lot. I can go back and forth a couple of times so you can see it. Woops. But this is 2018. So very, very small, I am sorry but we really didn't have much time to work on this data. There are the country names. So I went ahead and said can I compare the countries that are on the top there and see if I find the same data in my ‑‑ in what I see from Google, from APNIC from our RIPEness and, yes, I could find something fun. So there I took the top right and what is there is the US, which has a high‑ranking because of all the mobile operators having all the users going to IPv6, I have the UK, sky broadband, I have Switzerland with Swiss.com, and ‑‑ and I have the Netherlands where we also have a couple of operators that also do IPv6. Unfortunately we don't have ‑ difference looking for Belgium in here, we don't have it but it's probably because we are only considering the bigger ISPs, the bigger customer bases. So this is the ‑‑ this is what was comforting me also when I saw the data from Geoff. Because he was mentioning exactly the same countries there and the top of his list. So this is comforting and this means that we can go ahead and do a little bit more, although that was not meant to be there, but we want to look at all the fields with open answers which cannot be looked at programmatically, we are going to share the data internally with other departments and by the 6th June when we will have the new T‑shirts from the RIPEness which should have been here this week, we are going to present it later on on 6th June by the way and let me go back a moment. Let me thank Stephen, which is also a person behind this presentation and Pedro who did all the nice graphics that you could see, without him my presentation would have been much more boring. We will present this at the, our upcoming Educa event on 6th June where you will be able to learn more about what people have done with IPv6 in these years. So if you can put this in your calendar and join us on that day, it's a live event online so you don't have to fly anywhere, you can just join us there. And this is it. Thank you very much.
(Applause)
JORDI PALET: You know what I am going to say probably. We have talked about this. I am very glad to see NAT 64 in that big picture, but I really think there is a small mistake but it's very important and relevant for future work, which is a split NAT 64 only versus 464 XLAT because at least half of the operators which are the ones that are providing more data, if they are cellular are you seeing actually 464 XLAT at least for the ‑‑ users. I think that can change a lot the picture and it will be very nice to see the evolution.
MASSIMILIANO STUCCHI: And I understand. It's that your comment came a bit late in the course and I couldn't go back and change the data set that I had already received. But thank you for the comment, but as I answered already, there wasn't much we could do at that point. Thank you.
SPEAKER: Bjorn it would be nice to have the next survey on an IPv6 enabled web server.
MASSIMILIANO STUCCHI: I know. I planed the reasons why we did it this time.
JEN LINKOVA: Thank you very much, it does look very positive for the reasons that we got used to hearing that it's outside of our control as engineers because it's money, it's management, we can convince them, but I see one nice thing which people can change here is education. So do you know what is going on because you are doing great job, educating people. I see people here whom I know, improvements but why it's still the top, in the top three? What do we need?
MASSIMILIANO STUCCHI: So the three tops, let me take a step back and explain how that question was. You could answer multiples, so you could provide multiple answers to the same questions, say I can't move to IPv6 because of this, this and that. We see and my colleagues also in the room can also tell something about this but we basically ‑ almost every week we give a training course and the most requested ones right now are still basic IPv6 and advanced IPv6 training courses. We are trying to do a lot about capacity building in this, where we also have a programme you might have heard about, it's the train the trainer programme. We industrial to do a lot of documentation about it, we are trying to do more and more. But we still see that there is a need always for more, and every week we find people who come at our courses and they write ‑‑ we write in the course report what we see, people who have very, very little knowledge about IPv6 and we still see that. So I actually can till by going to all the training courses at that we give that this is the case. That we see a lot of people that have no idea about IPv6. And I don't ‑‑ I don't know what the reasons are behind that.
SPEAKER: OTE Greece. Last time I check, Greece was quite high in penetration. I am not really informed up to date but in the last Akamai's internet report, we were quitify just like Belgium that you mentioned, so you mention what size of ISPs did you examine and what was your threshold, in terms of users?
MASSIMILIANO STUCCHI: The number was ‑‑ the ones above 100,000 so we eliminated the very small ones in that case.
AUDIENCE SPEAKER: Did you find Greece inside that data.
MASSIMILIANO STUCCHI: I think it is there, if you get the slides and look at the small print I think I remember Greece being there. I wanted to take a few examples. It's not ‑‑ I am from Italy, I am Mediterranean friend of yours, I didn't want to exclude Greece for any other reason.
SPEAKER: It's not about excluding. I wanted to know methodology. I did not imply anything, okay.
MASSIMILIANO STUCCHI: I am pretty sure Greece is there in the numbers. Okay.
CHAIR: Any further questions? Thank you.
(Applause)
Next up is Jens Link and he has some very strange subject, are you in the right room?
JENS LINK: I think we don't need IPv6 ‑‑
CHAIR: The door of the room is there.
JENS LINK: So original of the title was we don't need IPv6 including the quotes, somehow they get lost. NAT provide, NATS are good and we should use 240/4 and IPv6 is just too complicated. I am just kidding. I am using IPv6 for about 3,500 days and I finished my first project around June 6th, 2012. So mention before what IPv6 day and we implemented IPv6 for top 50 portal in Germany in three months, without making it a big project, we just did it on the way. So somebody had to touch some networking stuff, some application stuff and we changed the relevant things on the way. It's not a big problem implementing IPv6. You might think. So we already had that. Back in the days we were discussing when the majority of systems on the Internet would be reachable over IPv6. I think 2018 was among the answers. So some time ago on Twitter that is the reason for this presentation, and I still can't find out why so many people complaining about IPv6 problems on Twitter which has no IPv6. So, can't deploy directly from GitHub on IPv6 only servers because GitHub of all places don't have IPv6. Yes. So, I complain to them a couple of times, so first time was please provide an address ‑‑ oh, no, we don't have IPv6, and now they are going to some more ‑‑ they claim that they are planning. I ask myself can I build Linux from IPv6 only host. Unfortunately this get a bit mangled up. Yes, Linux from scratch has an IPv6 address and the part on the slide you couldn't reach the web server over IPv6. So there was a AAAA record but the server wasn't linked to IPv6. So that was the first problem.
Some SCP cut, sort later I came up with a list of 32 unique URLs and I used can you recall and some shell script and 18 of those URLs were not reachable from an IPv6 only host. I checked yesterday, it's only 17 now. And then I started to answer people why. It didn't take ‑‑ took that much time to find out contact addresses, I just asked the people where I easily could find an address. If you want to you can open IPv6, bingo.com and play along.
It's mostly in our SIS admin's hands though at least we made some progress, launch pad. Plus one from GitHub. It must be my 25th plus one. When there appear IPv6 only networks that have trouble reaching ‑‑ this issue may become RIPE, until then it seems like a non‑problem. This is, I looked it up, source master was the ‑‑ so they have IPv6. The hosting provider I use still don't support IPv6. Okay. It's on our roadmap, that is something you hear quite often. We are deployed new servers and they sent me addresses and reverse mapping and stuff like that but still don't have IPv6, that was ‑‑ I did the same thing with CentOS using the home page in the rpm spec, I got about a thousand unique URLs, about 750 not reachable via IPv6, so and I get 50 NX domains. This needs some further testing and I will not ask them all. Some more questions? I've been travelling a lot, right now and so I asked hotel wi‑fi providers and airport providers, so nobody asked before is very common answer, we have no absolutely no plans for this and this was really fast, this was really tough. This was on the Zurich airport, you are the first out of our last 5 million customers to ask but we will start rolling out IPv6 in July.
(Applause)
And it was on Saturday and it only took two hours to get an answer, so maybe unless I was on the plane. Zurich Airport. If you wanted to get people angry just have to say IPv6. Project minus 1 was rather large Internet portal, IPv6 ‑‑ the network was IPv6 ready for use but they were moving to the Cloud and didn't have any interest in IPv6 and our current project I actually can do IPv6 again after a couple of years. Yes. As small content provider I ran my own block and it has a AAAA record. People are complaining that I have missed something. And I am running a WIKI for in the mailing list, for some nerd and I ask if I can make the WIKI host IPv6 only, I will make ask again in 20 years. So it wasn't a nice discussion.
Conclusion:
Most people are aware of IPv6, I have never heard, no we never heard of this protocol and nobody needs it. Some people just don't care. Some people chose to ignore the problem. Some people haven't noticed/have forgotten that IPv4 addresses are scarce. It's still a very long way doing. And if we don't ask about IPv6 there won't be much happening.
Ideas: One idea we came up, or we both came up with over some beers was set up a website and make a regular event where people ask why is your service offering no IPv6. Yes. So that was basically it.
(Applause)
JEN LINKOVA: I have two comments, I would say. First of all it's finding out ‑‑ out of 1,000 queries, you see 750 not working right so it's around adoption rate.
JENS LINK: Yes.
JEN LINKOVA: I think we should start making bets when we can finally forget about IPv4 because I was upset for the last three days seeing our presentations, we have a special feature called IPv6, I want to see presentations as soon as possible saying our product has a special feature we still support that called IPv4. So what do you think like 10 years, 20 years?
JENS LINK: I don't know. We should make betting pool.
PETER STRZYZWESKI: Have you tried to be IPv6 only hold in the plane?
JENS LINK: I only try on the airport.
PETER STRZYZWESKI: Try. Next experience.
MASSIMILIANO STUCCHI: A related note. If you go to Schipol, IPv6 is there, it's working both in the public wi‑fi and in the different lounges there.
JENS LINK: I found one place in Germany where I could get IPv6, a French chain of restaurants and breakfast shops so they do have IPv6 so thank you. No further questions. Thank you.
(Applause)
Next up is Diego Pino Garcia with a presentation on lightweight 4 over 6.
DIEGO PINO GARCIA: I work as software engineer, I gal I can't, small consultancy, specialise in open source and mostly ‑‑ we do other stuff on graphics, on multi media and wave team that works on networking and this talk is very much related with a talk that Kostas ‑‑ on plenary session on Tuesday, he talked about lightweight 4 over 6, their experiences deploying it at OTE in Greece and this talk is the story of data plane that they were using.
I can provide more context on how we get involved into this project, we started networking we were working with data plane but took it for developing data plane called Snabb and ‑‑ there is one of the authors of lightweight 4 over 6 and he ask us if we were interested in developing an open source solution of the RFC, we evaluated, we say yes, the reason why they wanted to have an open source implementation is because they are using it in their next generation network at Deutsche Telekom, it's an IPv6 only network and for providing for connectivity using lightweight 4 over 6 so I have defined ‑‑ divided the talk into two parts, the first part is about the, comparing with dual stack lite because has many things in common, I am going to talk about carrier grade NAT and the other half I am going to cover open source implementations of lightweight 4 over 6.
When I ‑‑ what I am doing these dates, I work on IP transition technology usually they ask me why somebody is interested in IPv6 why not just deploying IPv6. And that is a good point, that is dual stack lite, if do you that you need an IPv6 transition technology but in theory how things should have worked, but it didn't happen that way. So we need mechanisms that is transition to IPv6. And there are two possibilities there: You either provide IPv6 connectivity on IPv4 only network with technology such as 6RD or ‑‑ Hurricane Electric for example or you have an IPv6 only network and provide IPv4 connectivity to your customers. And this is where I think the industry is going, we think such dual stack lite or lightweight 4 over 6 is simplifies this much, you don't have to configure things twice or troubleshoot problems twice, you have your IPv6 network and offer IPv4 connectivity to your customers. Deutsche Telekom, Verisign is doing the same in the US for ‑‑ Comcast is delivering TV to their customers, on IPv6 only network. But since we know some years ago, in 2011 APNIC ran out of IPv4 public addresses and others follow and ISPs they needed to accommodate to a higher demand of customers with the same pool of IPv4 addresses, so they started to do NAT on their networks. From a logical point of view carrier grade NAT ‑‑ address domain usually a private address to another address domain, public address. It is stateful and keeps per flow information of this the map and NAT is man in the middle, it breaks end‑to‑end principle of the Internet, before all addresses were public and needs to recalculate TCP and IP check sums it changes the addresses on the ports. This is not very demanding, if you are doing your CPE but doing it for large amount of customers it is something.
So this is now a NAT works. In maps. An IP private address to public address, and now we need to create a binding on entry, this binding table of this mapping. This is how carrier grade NAT works. We have this laptop and have a private address and want to reach the Internet IPv4, we want to CPE, performs a NAT. Now we have got this new address, this is like a private address that IETF standardised, private address in the one. Then we reach the CDN that is deployed, translate this address to a public address so we have one binding entry at the CPE and another one at the carrier. Since we don't have any control of what is going on at the carrier network makes more do I have host services in our client networks and breaks many applications. Another inconvenience is that a stateful so that means it's hard to scale and since now there are many users behind the same IPv4 public address, we have this complain of law enforcers, when they ask us to identify who is the user behind IP address.
So to solve some of the problems people start to think maybe we should move to IPv6 to alleviate the demand of IPv4 public addresses on our pool. So dual stack lite what proses is IPv6 only network and is fog facilitate IPv4 connectivity over this IPv6 only network. A dual stack lite architecture consist of two end points, network functions, one of these network functions is called B 4 is going to encapsulate packets at the CPE and the other is deploy at the carrier and is going to perform the carrier grade NAT. This is how it works. We are ‑‑ want to reach IPv4 Internet, our packet reach the CPE, is not going to do a NAT, there is some confusion here, in dual lack style ‑‑ encapsulates the packet in IPv6 and our a router after network function and the network function where it's going to do is two things, decapsulate the packet and forward the NAT. B4 stands for Basic Bridging Broadband, encapsulate IPv4 packets in IPv6 and acts as DNS proxy to, is it possible to resolve AA records using IPv6, users can use their own DNS but that will make request to the AFTR, is it possible to get the DNS resolved by native IPv6? And then the AFTR means address family translation router, runs at the carriers's income, tunnel end point decapsulates and going to perform a NAT on the packets. When it does the NAT it needs to keep an entry as the one that saw before but this time is also needs to have an extra field to know to which TP it has to send the packet when it comes back.
Advantages and inconvenience of is tunnel based, we can deploy the tunnels, anywhere in the network makes sense the edge the network. Removes one level of NAT, no NAT at the CPE. Is meant to be deployed at IPv6 only networks. One inconvenience is that as anything would have to do with encapsulation it has do deal with fragmentation and reassembly, is the maximum size of MTU and in addition we put the 40 bites of, the author has to handle this fragmentation, this is something specifying in this and another inconvenience is there is a stateful because it uses carrier grade NAT.
So to solve this problems there were some suggestions on dual stack lite and that finally became a new RFC is 7596, lightweight 4 over 6. So where it tries to do is to remain the stateful nature of dual stack lite and going to do two things: Move the NAT back to the CPE as it also relies on two network functions. Now before is called the ‑‑ is called lightweight B4 going to do two things, NAT and encapsulation and lightweight after and going to do a software lookup and decapsulation. You may wonder where is software. The way that lightweight 4 over 6 shares IP addresses among customers, what it's going to do is going to give a portion of the space to each customer, instead of having a customer 65,000 ports at that we usually have maybe we are going to have 1024 ports.
This is how it works. We have this laptop and want to reach the IPv4 Internet, our packet reaches the CPE and is that is going to do a NAT and is going to encapsulate the packet in IPv6. The packet gets routered until it reaches about the router the lightweight after function is going to do a look up in a binding table, this table is static, it's not dynamic, already created and if there is a match it's going to decapsulate and forward it to the Internet. So Softwires is something, software maps two different address families, IPv4 and IPv6, is not exclusive of lightweight ‑‑ MAP‑E and this is how on entering the ‑‑ we have an IPv4 public address, a port range, and the IPv6 address of CPE. This is the schema of a software. There is also address of the After, this is needed for permissioning, and the port actually doesn't work like a minimum value and a maximum value, not encoded like that. Explained what this means. So a port is a 60 bit number. So in this port set field we are going to say how we are going to use the 16 bits to have a size of a port set like 1024 and the then the rest of the bits we can use it for the number of port sets, in this case 6 and 10 going to have port sets from zero to 1023 ‑‑ I encode the port set of a software with an identifier so port set identifier 8 it actually corresponds to this values.
Another cool thing of softwares is you don't necessarily need to do the same split for the same IPv4, you can have different splits, in this case then you imagine usually a question that I got is what happened with the privilege ports, the standard recommends not to allocate the, one go from zero to 1024 but if a customer wants to host services you give a full IPv4 address and also if a customer has a big client network you can give a wider port set like 16,000 ports. Another cool feature of lightweight 4 over 6, is that imagine that this this computer here and you want to reach a website which happens to be host in the same carrier network, your packet gets routed to the after and when it does a look up it realises the destination is within their network so you send packet back to the client, doesn't decapsulate because that is going to come back anyway.
So there is a document called the deployment considerations for lightweight 4 over 6, a study from China Telecom and ‑ university and among they test several applications and many of them work. But this is an experiment, what it really matters are real use cases like the one that IT is doing, deploying it for real in production environment and the ISPs can get really good feedback so it would be awesome if you belong to an ISP that you take this software and try to test it in your labs.
Pros and cons. The advantage of lightweight 4 over 6 it removes carrier NAT and that makes stateless and when you are stateless you can scale much easier, if you need to cope with more are demand and throw more afters to your network and dual it has to have fragmentation and reassembly. So about open source implementations, first things first, the B4. The B4 is available in a programme called NAP. It is on OpenWrt so if your CPs are running OpenWrt, it is supported. But if not, this function actually is not very complicated, it can be emulated using comments such as IP root 2 and IP tables for doing the NAT. There is an article that participated the and that he describes how to implement that before using Linux comments.
About the after itself, there are right now as far as I know two open source implementations, one is from BBB, better packet ‑‑ by Cisco and the other one is in Snabb, there is nice talk, Cisco engineer he talks about VPP and with specific examples of lightweight after.
And about Snabb Lightweight after. How many of you are D P K or VPP? More or less. So Snabb is similar to the ‑‑ toolkit for developing data planes it was started in 2012 by Luke, similar to the DPDK or VPP. All these tool kits do the same thing, bypass the kernel to get the maximum performance. One particularity of the Snabb is that it's rich in Lua virtual machine. So this is what we use for developing the lightweight after. About, forget all the, this is about making hard ward appliances and there is two approaches for that, you can do X86, you build something that is equivalent to a high end Cisco Juniper router or you can go the other way using ‑‑ using P4. So Snabb goes this way. X86. Hardware right MoU is good enough for building something ‑‑ high end Cisco router, 10G, 40G, 100G, Intel ‑‑ and ‑‑ more bandwidth and we have tons of processing power like arcs with 12 up to 48 cores. So we can build of the appliance and then programme our data planes. But if you to that, and you use like something like Linux, the bad news is that Linux because how it's built it doesn't ‑‑ it doesn't work well as a a forwarding plane. Whenever packet reached it has doing through the networking layer and reaches user space and you do your thing and that has a cost and the worst performance and that is why all these user space networking movement started some years ago however there is an update, has not been have tackled this problem and now there is a new layer in the kernel called extreme data path that borrows many ideas. And now it's possible to attach programmes to an XDP interface and as soon as it's received you can run your network function so we are going to see really cool things coming in the kernel about high performance networking.
Okay. About Snabb. This is the toolkit we used for data plane. I am going to explain what it is. It's very easy. Consist of three things: Apps that represent network functions such as filter or lightweight after. Links that are going to connect apps together and programmes, are interfaces with this graph of collected apps.
So we can have a programme that uses Intel NIC and whatever comes out on Intel NIC, we are going to pass it to a filter and whatever comes out from the filter, we pass it to PCAP app, that is going to write down this packet to a file. Once we have this programme, this graph or app, we pass it to a Snabb engine and that is going to execute it. Each breadth consist of two steps, inhaling is pulse packet from one or several sources and puts them in the links and processing, this is going to give a chance to apps to do something with those packets in their incoming links. For instance this is a ‑‑ we create a configuration, with our apps, there is a NIC, a filter, a PCAP app and connect them together as we saw before, we pass this configuration to an engine and run it. Each app has a push method and this is what it gives the AP to do something with packets. So I am going to read the packets in the link, going to receive them, I do something with them like applying filtering expression if it matches I forward this to the next app, if not I can drop it. And with this basic elements, these primitive, actually you can build any network function, the lightweight after function is combination of these small steps but it's more ‑‑ much more sophisticated. So about the developments. We started in 2015 and delivered first version in October and this version was mostly like a prototype. We wanted to test that it worked. So we implemented basic encapsulation/decapsulation, work with small binding table, with custom format, we achieved our performance with 550‑byte packets, for doing this development we have to develop our own tools for measuring performance like something that passes a load to the function, ramps up and see at what point we start to lose packets. We needed to validate implemented the standard correctly so we had lots of end‑to‑end tests, another features were fragmentation and reassembly, rate limiting, ingress and egress. Version one that is the ‑‑ full complaint with RFC 7596, uses large binding table, with custom format, we try out with one million softwares, reach lightweight performance, implement ‑‑ for dealing with NDP and ping, it was required we needed to ping the interfaces of the lightweight after, the IPv4 site, the IPv6 site, also we managed to run it as a BNF, the performance was lower but still very good and more things we is it was more tests, continuous iteration, improved our tools. This is the version that it is deployed at OTE, as Kostas explained in his talk Juniper took this data plane and for providing the needs for the contra plane and what we see here is actually a Snabb programme, this is the network function lightweight after and this is the then Juniper he called this applications that is split packets, fragmentation, network how it works is like whatever packets are data plane are passed to the lightweight after and anything that is contra plane is sent to a machine that is running JUNOS that is going to resolve, and send them back.
We learn a lot of things while working in this project especially about performance. It was necessary to meet the performance criteria so things that we learn was profile heavily, we were running on virtual machine, there was no interpreted code, everything has to be ‑‑ use tied loops you are always doing something. The downside is the CPE is used 100 percent. Also use single instruction multiple data things likes AV X, emit your own assembly if you necessary. About environment, what you are working on data intensive application, disable hyper threading because it can trust performance. NUMA awareness, we completely ignored, make sure when you run your application your devices and your cores are in the same NUMA and isolate CPEs don't let your operating system dispatch other applications in the CPUs where you are running your programme. Version 3 came out in end of 2016. It added YANG support was very nice, we arc the programme, we run it in two process because for this table there is a certain programme that is going to use net could have been comments to feed it and there is a programme with deals with that and the worker just runs the data plane so can go a very fast speed. And version 4, we implemented RSS on Intel NIC, if you have a load distributed amongst different cores, now there is one and that and we got support for YANG alarm model as well. Adone, the very much linked with Deutsche Telekom, using lightweight 4 over 6 there but can be used in any other network deploying it in Greece.
Conclusions. Lightweight 4 over 6 is an iteration over DS‑Lite, implements ‑‑ relies on A plus P soft wires, stateless which is very easy to scale and full‑fledged open source implementations available today. The collection of links and I can take any questions. Thank you very much.
(Applause)
SPEAKER: So I have two thoughts. On the one hand I am impressed you got so much cool stuff done. I am depressed you spent some too keep this crappy old IPv4 running and you really should check your Working Groups because this is the IPv6 not the legacy IPv4 Working Group.
DIEGO PINO GARCIA: Pity it took so much time to do what?
SPEAKER: All this energy, you spend it on keeping IPv4 working that is sad.
DIEGO PINO GARCIA: No. I mean ‑‑ well yeah I understand. It would be great that everything would be IPv6 but I think that for real IPv6 transition ISPs are going to rely on IPv6 transition, notice need to provide IPv4 connectivity to this customers, mechanism for doing this thing which actually I think if you compare CGN, real expensive and now we have this solution, there is open source, and you can buy ‑‑ piece of hardware, maybe 5,000 US ‑‑
SPEAKER: I am very impressed, it's really cool it's so sad that it's still needed.
DIEGO PINO GARCIA: It would be great everything would be IPv6 thank you very much.
Blake Willis: Thank you very much for presenting this, I have banged around on it a little bit in the lab actually. Just a quick request actually. If in your slides on carrier grade NAT could you please be sure in the future to use a ratio of like 8 to 1 or 16 to 1, no less than 4,000 blocks per user in your examples. I know this is just an example and you are not making a suggestion but people still copy paste it a lot. And ‑‑
DIEGO PINO GARCIA: 4,000 blocks.
SPEAKER: 8 to 1 to 16 to 1 as recommended by Europol, Belgian and French authorities so they don't have to trace ‑‑
DIEGO PINO GARCIA: Information no more than 16 users under the same IPv4 public address.
SPEAKER: The police have begged us not to do 64 users per IP ‑‑ so they don't have to trace that many.
DIEGO PINO GARCIA: I will add it to the slides.
SPEAKER: You can always hire them to do something more interesting and fun and for Diego, thanks very much for your very interesting work, keep up the very good work. Thanks a lot.
DIEGO PINO GARCIA: Thank you very much.
BENEDIKT STOCKEBRAND: I largely agree with should waste time on transition technologies which tend to just delay the inevitable and make it more painful and when it actually happens but considering the trouble a lot of people have with the ‑‑ this might actually kind of help in number situations and having this open source is definitely a very good move. Thank you.
JAN ZORZ: So thank you for this very nice work. You mentioned MAP and you mentioned lightweight 4 over 6 and from Monday when Kostas presented or they implemented in real life, I sense the increased interest from operators to do something similar, but they are a little bit confused, should we go MAP, lightweight 4 over 6? Can you please elaborate a little bit more, so people would understand in which case you should use lightweight 4 over 6 and which case you should go for MAP?
DIEGO PINO GARCIA: I think I don't know much about MAP E but very similar to lightweight 4 over 6 and what is happening this is a very early stage for this other approaches of doing A plus B and sometimes what is happening is it's the time to try things out and I think eventually one of them will be the most relevant but at this moment I think it's good to try different things.
JAN ZORZ: Do you plan to add dynamic allocation of additional ports of 4 over 6 ‑‑ additional ports so if a user runs out of ports because this was specified in a stateful A plus B that is basically lightweight 4 over 6 and please stop saying that it's stateless, because it's stateful. Do you plan to...
DIEGO PINO GARCIA: Why do say it is stateful? Because somewhere, there is a subscriber, are not their connection.
JAN ZORZ: You have BINDings.
DIEGO PINO GARCIA: Yeah, but the binding...
JAN ZORZ: It doesn't matter. It's stateful.
DIEGO PINO GARCIA: For me, it's a carrier and is stateful, because once you establish this binding table, all the connections have to be going to the same NAT. But in the AFRs there is a big binding table that all the AFRs share and it doesn't matter ‑‑ certain subscribers or not.
JAN ZORZ: It doesn't matter. If you are looking to add the dynamic allocation of additional ports because some people use it.
DIEGO PINO GARCIA: I am not familiar with what it means, we will explore it. So far, at this moment the work that we are tackling is we have managed to be able to compile larger binding tables, now we can have up to 40 million software binding tables and that is what we are doing right now. We will keep on working on the project, definitely.
Kostas: In regards to this, the binding table in lightweight 4 over 6 is more or less fixed. I think an idea for that is to have different binding tables and different offerings so you could switch the user from 1024 ports lay to something larger. So ‑‑ so this is what we are also considering in terms of ‑‑
DIEGO PINO GARCIA: The binding table because I went very fast very end, it can be abated, it's not that it's fixed and you never change it, through NETCONF you can interact with this and you can remove software add a new one etc..
JORDI PALET: Responding somehow to the first question from Jan, there is not that much difference between MAP T and MAP‑E and lightweight 4 over 6. Most of the time is a decision which may be based on what is your equipment supporting and what the CPEs are supporting. On the other side, if I am ‑‑ I have done a comparison between all the transition mechanics and I am happy to share the link to the latest slide in the list because they are in English but I presented those in the last meeting in the tutorial. So you can actually see why one or the other has some or less advantages. But especially in those cases where you may have also cellular network or you may want to offer a hybrid service like broadband, and server backup, instead of going to any of those transition mechanisms I will recommend to go to 464 XLAT.
CHAIR: Okay. Any further comments, questions? If not, then this session is about to be ended. But at 6:00 we have a BoF in this room about IP and ASNs for governmental ‑‑ some governmental issues with getting IPv6 ports I have heard. So welcome then. But for the rest, thank you for your input and for your presence.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
