IPv6 Working Group
Thursday, 17 May 2018
At 2 p.m.:
JEN LINKOVA: Good afternoon. Welcome. This is IPv6 Working Group, if you are interested in security, you probably might want to be in another room. We have been pointed out that people don't know who we are. So those two gentlemen are co‑chairs of IPv6 Working Group, Ray and Benedikt and I am also co‑chairing. I am just a clown. Welcome. So we have busy agenda as usual. Yes. It's our welcome, introduction Working Group chairs, when you go into microphone and I hope you will go to microphone please state your name clear so stenographers can do their job or magic and typing our names. This time, I actually done my job, you see I am getting better at this after three years, I sent meeting minutes from the last one to the mailing list at least months or two in advance and I know some people have read them and made comments so I am going to ask you, do you have any comments to ‑‑ about the meetings? Because otherwise we are going to approve them. Nobody read them. Okay approve them. Easy. Agenda: We have busy agenda. And I am actually ‑‑ I don't know of you have been been to the BoF on Tuesday when IETF complain that you guys are not coming to IETF, so we are trying to close the gap so we have at least two presentations about ‑‑ IETF which might be of interest for the operational community. So, and before we start presentations, just a reminder, please rate the talks, because we do get your ratings and we build an agenda based on this so that is why I will ask Geoff to come and give us a talk because he is always getting the best ratings. So please do rate the talks.
(Applause)
GEOFF HUSTON: I work with APNIC. I think I work for APNIC, they are not sure. This is a quick sort of 20‑minute talk because Jen asked me to do an update about what I see about IPv6. We measure it, we don't measure traffic, we measure, you know, the way we to this is not via something like Atlas where if you will, a bunch ‑‑ a number number of folk, predominantly geeks go and put probes inside your house. This is much bigger than that. We use Google's online ad system and you have all seen ads, every last one of you, I know you have all seen ads, they have ads on folk who were in the Internet on the Faro Islands, they are everywhere. What we do inside ads is almost standard stuff these days. We have JavaScript, and what the JavaScript does is get you to fetch a small number of web objects, but one of those is only accessible using v6. One is only accessible using v4 and one is dual stacked just to see which way you go. We make sure that the name, the domain name is absolutely unique, no caching. So we see the DNS because we are the server, and then we see your subsequent web fit because we are the serve. So we measure not only a huge amount of the Internet every day, we do around 10 million experiments and the other thing about Google and they are brilliantly, unless you really like an ad you never see the same one twice. If I am the advertiser, every day I see 10 million new websites and users so I get to see, over time, a bigger and bigger cross‑section of the Internet.
So I actually do two measurements. Capable says you have got that thing that was only accessible in 6, you are capable. When you are forced you will do it. Preferred is what happens in the dual stack world, you have got the choice: 4 or 6, which way did you go? And I measure both things every single day. Now, the one thing about Google ads which is a little bit sort of I suppose obvious in some ways, I'm cheap, Google is cheap too in some ways, I don't bid 50 bucks a click or 100 a click, I am not selling real estate in San Jose, right, that is not part of it, so in general, I don't get that many hits in the US but an awful lot in India because, you know, that is the way economics work. So I do have to do a certain amount of compensation and I balance the numbers to go if Google were going to evenly smear my ads across the entire Internet, big if, this would be the answer. So what you are going to see is not the raw numbers but if you will a compensated set of numbers that compensates for the sort of bias in the ad. So here is the picture because I have been doing this for a while, since late 2011, this is a classic up and to the right, back in late 2011 you needed an atomic microscope, there was no v6 and anyone who said there was was obviously deluding themselves. There is some interesting artifacts aren't there that sometimes preferred and capable deviate. Now, we know why and it's bizarre. When India were first experimenting with v6, their v4 server that was closest was in Singapore. That's cool. But there was only one v6 egress in India and it went to London. And the traffic was still going to Singapore and guess what, that is more than 300 milliseconds so obviously ‑‑ said no v6 is too slow so the preferred numbers plummeted for just that period. So you can see, I suppose, obvious things in this data when you understand what is going on. But there is one other thing about this graph that is not up and to the right, and that's here, up up up, what? What is going on? When I blow it up a little bit you see quite clearly that I wouldn't say peak v6, that is going way too far, but I would say stalled v6. The globally, v6 Internet has been growing only at the same rate of growth of the Internet since late last year. It it hasn't been growing faster. It's kind of stopped the acceleration. And I am curious about that, because why, have you all got bored? What is going on? Why has it stalled? Now, one explanation is that whatever forced the folk who have deployed v6 in the past is no longer effective, whatever reason why Comcast did it and why reliance G O and so on did it is no longer relevant to the rest of you. Or something else. I really don't understand why it's stalled and I am not sure anyone does. So, if I look at the object sit side of that question, what are the factors that push people to deploy v6 and why is that factor no longer working? So that's what I want to explore to try and explain why it's stopped growing, what drove you to deploy v6 in the past? Can we look at the data and find out anything about this. So the first of these is kind of testing your own knowledge and understanding of the Internet and v6, that is a pie graph. If you imagine all of the v6 users in the world, 540 million of you, was one big pie, which colour is which country? Who is that major, major blue? Comcast? There is a lot of Americans out there, 550 million of them, most of them use the Internet. You would be wrong, it's India. 44% of the world's v6 users, that is 44% come from India. Only 22% come from America, Germany with the Deutsche Telekom and a few others, Brazil, Japan, the UK. Who are the most populous countries in the world? Well, there are a lot of Indians but even more Chinese. And so the one thing that is missing from that oddly enough is China doesn't feature on these lists. In Indonesia doesn't feature. Only Vietnam, and that has got a tiny amount of deployment. So in terms of population, this is a funny graph. It's not the largest bunches of users, v61 not being properly deployed across these countries, USA it's not even 44%, so why is it only one‑fifth? What is going on. So interesting, interesting. So let's look a little bit further. Let's put it on a map, that is the way the map looks, India beams out, Germany France, UK, Greece, Brazil ‑‑ you are here is the list by country so within the country of India 58% of Indian users can access a v6 only. That is the same as Belgium. It's an amazing achievement India, United States at 44%, you can read this as well as I can. I count every country including the three people in the Aland islands. The goat is just hanging out, the v4 only goat. You can read these slides. I don't need doing through them. Let's flip it the other way because it's not everyone in the country, it's ISPs within the country that do the work. So which ISPs have a lot of customers and a lot of v6. We heard a lot about Comcast over the years and Comcast did an amazing achievement. What is amazing, too, is that while v6 is everywhere, not every user uses it. CPE equipment, their own equipment, there are still these blockers even inside their network while the network is complete the roll‑out isn't. Why is geodoing such a bigger job? Because they are mobile. I don't know about you but I find programming these things an amazing joke, the device is hermetically sealed and if the carrier wants v6 they got it inside the hand yet, with geothe user number is just extraordinarily high, similar AT&T, a mobile network, 708 I believe, and it wasn't just one person in India, had you much and ICL net in India, it wasn't just geo, a few of them moved together to produce this outcome. That is the ISP list. Where is the top French one? Down there, I don't know why they use that in the RIPE database, they are really called Orange, but for some reason they register their ASs 3215, it's a French thing. So, you know, what drove them? What drove them? So the idea was if you cast your mind way, way back in time before most of you were born that was long ago, we thought this was easy and we were running out of v4 and they were used to actually identify end points, if we had more than 4 billion we are stuffed, we need something bigger, let's run v6? Right. So we ran out of v4 addresses a long time ago, 2011 or so, yet we have still only got less than 20% of v6 so that theory was wrong. So what drives people? What are the motivations to drive people to look to deploy v6. Let's look at a few. Three years ago, I could substantiate this, you got to be rich because right now today, you don't need to. It's not as if you can't have customers if you don't have v6 because 80% of the world doesn't use v6, the proof if point is you don't need v6 to live, it's not essential, if it's not essential what is it? Is it a luxury? Is it something you can afford to do? So let's measure the wealth of ISPs. Really easy, take the GDP per capital at that, money, take the estimate of the number of customers, money times people gives you value. The richest ISP in the world is Comcast, because while it only has 50 million users they are rich. So their combined value is some astonishingly large trillions of dollars of value. Does it deploy v6? Absolutely. Second biggest, China.net has an extraordinary number of users, 314 million, GDP per capital at that, less, but they are still reach. V6.06%. When you look at the list of the richest ISPs I only get 13 that have more than one‑third v6 and there is a number of hang outs including in China, in the United States, again in United States with MCI and in Great Britain, something called NTL, whatever, you know who you are. So it's not sort of everyone, it's some in that rich list. Put it on a scatter plot, why? Because if there was a correlation all of these things that bunch together and you get top to bottom, that is what scatter plots are meant to do, to show correlation. Not looking at that good. Can't really see anything, but that is only 20 data points. Let's take the 400 largest ISPs and calculate their value and v6 deployment, if you can see a pattern you are doing better than I. And all the stats techniques in the world won't get a pattern out of that. Basically they crowd towards random numbers there, there is no strong could relation between money, wealth and v6 deployment. And in fact 73% of the world's users are outside the richest top 20 in v6 so the ones if aren't as ICL, Brazil ranked 53 by ‑‑ you can read this as well as I can. So that you don't have to be rich to deploy v6. It does help, money helps everything. But it's not essential. It's not the precondition for v6. And certainly China is one of these examples. So, no. Well, maybe you have grown like crazy in the last few years and don't forget if you have you haven't used v4 addresses because you can't get them no more from the RIRs, you are paying a huge premium. Let's look at the ISPs that had the highest growth rate in the last 16, 17 months and look to see if those ISPs which are growing like crazy had pressure to deploy v6. A network in Thailand grow by a factor of three, Korea by a factor of three so there are ‑‑ across much of the world. But while that one has 43% and that one has 56%, the v6 deployment in Uganda is zero. So growth and v6 don't naturally go together. Let's put them on a scatter plot but first look at the rough data, 100 ISPs with more than 100 ‑‑ grew by more than 20% but only a quarter of them did v6. It looks like that. Can you see a pattern? I can't. That is not the reason. So it's probably not rapid growth. You are running really short of v4 addresses so you need to do something. So I know how big you are, I know how many v4 addresses you advertise, I know what your stress rate is. If you live in Nigeria you are sharing that IP address with 394 other users if you are VCH, which I assume is Vodafone. The record is globe come AS where you share your IP with 841 others yet no v6, no v6. Of these ones that are stressing, again if I put it on a scatter plot here is the stress rate, this is Nigeria down here, there is no obvious up and to the right, more stress ISPs are not deploying v6. Again I can't see a a correlation. So running short of ISPs ‑‑ running short of v4 addresses does not equate to deploying v6, it just means you are buying bigger NATs, that is all it means. There is no pattern. I am getting a bit frustrated at this point aye look at the ones that are running really short, 19 have more than 100 customers per address and again only one of them, only one of those 19 has any noticeable v6. They just love buying NATS. I don't know. There is something that has changed and I think it's the changing Internet itself that is changing the drivers. We are now a client server network, client don't need addresses except when they are talking, they don't need permanent end point addresses so in some ways the pressure of exhaustion has been absorbed by a change of the architecture of the Internet, that is fine. It won't last forever, we cannot make v4 do magic so at some point it's going to break but not today, and what we are really looking at is perceptions of risk and if there is one thing the sewsiologists and statisticians will tell us, if we know there is a risk factor all of us will react differently. 40 million people live in California, you know who you are. It's going to have a massive quake. It might even be tomorrow, but your perception of risk is going no, it's okay. Some of us don't live in California and don't really want to because of the same perception of the same risk. This is really what we are seeing, that the perception of risk of this change differs remarkably across the industry, some move, some don't. But one thing I do know is that if your competitor does it you are more likely to do it. In India, 3 of the largest 6 have v6, not 1 you about 3. In bell yum, more than 3 of the largest 6. USA, 3 of 6 or more, Germany, Greece, Japan and Brazil. So in some ways there is a little bit of follow the leader, if someone big does it the others do it because of competitive equality. But not every country does that in the UK, it's only two, merely only one major player, not every country is the same but sometimes this happens. What can I say? You don't have to be rich but it helps. You don't have to be growing a user base quickly but maybe that's a reason. You don't have to be stressed out like crazy on CGNs but you should be worried, you really should. And, you know, if your competitors do it you don't have to to it but you might want to. They all work in individual cases but there is no single case. I can't tell you what the major killer reason is today, and I can't tell you why we have stopped. What will shift the dial is China, so many users. If they ever get that central command economy thinking long and hard about the next ten years and if you can't think that ten years in a command economy where can you think forward, the needle will change when China moves. Until then I kind of think we are kind of wondering around going geez I hope someone else does it because I can't tell you. We really don't know at this point why people do it. Lots of possible reasons but no killer. Thank you.
(Applause)
JEN LINKOVA: Geoff, I should say I am so disappointed because I was looking at that graph and I had the same question and I did hope you have answered. We have some ‑‑ time for few questions.
William: I have one ‑‑ a few remarks. I read somewhere in the newspaper, I don't know the source any more that Chinese telecom providers will activate 500 million end users, customers in the next two years so this will give pressure, I hope. And the other reason why we hopefully get into more IPv6 could be techniques like ‑ routing where we have techniques that don't work with IPv4 any more but have so many advantages that people move forward.
GEOFF HUSTON: I think the first reason, you know, 500 million folk in a couple of years if you look at what happened with reliance Geo in particular, it is possible to deploy across 100 million in a few months and the way they did it was not like Comcast, these are not broadband wired networks, they are mobile networks, and mobile networks have a lot more control left with the operator and a lot less choice with the user. And if China goes it will be the mobile networks that flick first that is obviously the case. Will they go? We hope so. When? We know, they don't. Thank you.
SPEAKER: Andreas from ‑‑ I am from Greece and Greece is quite high in the writing as you already showed, so especially I follow very closely the IPv6 in Greece. So I am very confident to say that there isn't for being in ‑‑ the reason for being in this position so not so much ‑‑ all these parameters that you mentioned affect but eventually do it for the people, there is a single person that attends that meeting who is especially responsible for being on the fifth position instead of being on the 30th position in your rank so it is people who are motivated to happen to be in environment with motivated manager, who happen to be in a company that it is not so excited and maybe some factors like POU exhaustion exist help them promote upper management and eventually it is because of people are motivated that have eventually deployed IPv6. And of course, we have seen it in Greece that when the largest ISP starts doing things with v6 the other ISPs will follow, but eventually it boils down to people.
GEOFF HUSTON: In some ways the hero engineer, the advocate does make a difference, particularly in smaller companies because the larger ones like the telephone companies we used to criticise, they are businesses and they are heavily capital and process intensive. Change is terrible for them because that is cost. They will change if they can see revenue. If they can't see revenue the case for change is very hard. In v6 often the case for revenue is very, very obscure it's more about risk. And that is why many of these large companies are willing to keep on going in CGNs for longer. Because the risk hasn't tipped them over. So yes, advocacy works and sometimes if you are lucky you are working in a company that is ‑‑ often we work in companies that never listen because they are just too big and got too many other issues but it's good to see it when it happens. Thank you.
ALAIN DURAND: One other reason people went there and belt is suspenders, maybe v6 will work and when we have to do something not to be caught pants down, we do CGNs, belts and suspender things gets expensive so maybe that explains some of the decline. But the thing I wanted to point out is if you start to plot for curve of adoption even some of the most advanced countries where you have richest ISPs and you see if you keep the same adoption rate increase year after year at what point will we be at 80 or 90%? And the plot I have made shows it's a minimum of 5 to 10 to 15 years depending per country so that is a bit worrisome. So we sustain the momentum to try pushing for IPv6 for another 10, 15 years and still being in belt and suspender mode where there is no major business case.
GEOFF HUSTON: There is another view, and that other view is actually T‑Mobile USA reliance geo, AT&T and the 464 XSLAT on mobiles because up at 92, 93% almost immediately because you guys can't play with mobiles, and maybe, just maybe, you guys using laptops are the old mainframe grandfathers of tomorrow's Internet and you will be irrelevant very, very soon, and the network will go v6 and we are all be on these and we don't care about your laptops any more and for you to upgrade stuff because you just won't matter. That is the other view.
ALAIN DURAND: From an IPv4 perspective 464 XLAT ‑‑ we have ‑‑
GEOFF HUSTON: You get astonishingly fast uptake and the case for v6 only is temptingly close when you can do it on mobiles. That is why I suggest maybe mobiles will control the tempo.
ALAIN DURAND: Let's talk about this in 15 years.
SPEAKER: There is one other incentive that I didn't saw on your presentation, I know it's something which is not very well appreciated around here. It's legal pressure. This combined with CGN may result to the fact that operators at some point just in order to be able to fulfil their legal obligations, customer, stuff like this, they will have to deploy IPv6 because they will no longer have sufficient IPv4 or using CGN will get them to a point where they cannot properly respond to legal obligations.
GEOFF HUSTON: I understand what you are saying. This was a data‑driven presentation. I had data on all of these artifacts, I have no data on legal, I am sorry, in some ways you are possibly on a good point there but I will have no data to back it up so I can't comment. Thank you very much.
JEN LINKOVA: Thank you very much, Geoff.
(Applause)
Now, our next talk is going about visual representation of data, IP addresses in this case.
HELGE HOLZ: Dataport for public administration in six states, we are calculating for six states out of 18 and we are using the network or providing the network for two states, for Hamburg ‑‑ I am also responsible for the IP addresses for 25 years now and I don't get rid of those ten addresses.
Now, I am responsible for the IPv6 addresses and I had to provide an address scheme for the German government to say every stage has to be, has to have structured IP address scheme but I couldn't explain it. I printed it, it was useful but no one could understand what I did. So because of that, I had to create something new and this is something I had, I showed four years ago. Who of you have been to my lecture four years ago in Russia? Oh. About 10 people. That's ‑‑ yes. Okay. So a short wrap‑up. What I wanted to do is print, drawing a picture where you can see aggregateable address space. This is the picture, it's a wonderful picture, no you think it's boring. It's just numbers. If you look at those faces, just think this will represent your Whois address space and if you look there it's the same as last time. Every sub square is showing address space as long as you stay inside those squares where the outside lines are wider than the inside lines. If you put some colour in it, you can see a little bit more. For those who don't see it, I just translate that to ‑‑ you have got the numbers you know. So if you think this is representing /B network you can see every sub space is representing a class C subspace. You take ‑‑ you take any of the squares you have left upper corner the network number and in the lower right corner you have the broadcast number so this is the quarter of the whole class D network, this is somehow an eighth of the class B network, you have the upper left corner you have the network address and then the lower right corner, you have the broadcast address. Back to v6. So, we are going to have this picture. I think it's a beautiful picture because with that you can really easy calculate address schemes, very structured. Last time Jen suggested that we made a web application so everyone can use it, so my colleague wrote some. You can here find the web links. So there you have the description of the programme, there you have demo version of the programme and it looks like that. You are starting the programme and you are just getting an address scheme. You are starting with any scheme here, that is the documentation prefix and then you start colouring squares. Okay. That's the documentation scheme. You can see this is the documentation number and you are just structuring the first ‑‑ next two digits. We will rename it because I just provide something for the ‑‑ network. So I did not do anything with that square but rename it to S H ‑‑ that is a new square. This square is representing the whole address /32 and now we are going to do some structure into it. So we are taking the lower square here for the police. Most of the addresses are consumed in German government by the police, we have more than 2000 police stations and they need everything for their cars and something like that, they need addresses. So I got them a quarter of our whole address space and they were needed.
So for the programme you just click on one of those squares and it's shown how many addresses you can get together which are aggregatable. So you click anywhere here and it will take this square. You pick a colour, I took blue for the police, here you put down the name here, the prefix is calculated. And you are finished. So you have just arrived for the first square of your address space and now you are doing the next, the German government we have ‑‑ we have 16 rural districts so I just picked here one square with 16 districts and the colour is I think coloured yellow, I think. No, I coloured it red. But it doesn't matter. At this point you can see I am still in the first square and doing the first digits of the programme so we are always in the first square. Now, that is the upper scheme. One we are going down you pick one square, I think I put the first one and that was one of the rural districts, it will be ‑‑ you click on to that square and you have got a new empty square and like you can see here now I clicked on the 40 so we are here, we have the 40 picked and we are now structuring the next two digits. In seg berg we have several villages so we could do inside the rural district, we have many towns so I picked one of them to say that is the next town to use. So I clicked on that thing, now we are structuring seg berg and we can see we are at the next point to structure our address scheme. One of the villages is ‑‑ a little bit bigger than the next one and that is trap encamp so you by size anything you want to do and when you have got your village then you have to put your addresses to something else. So we got there the Town Hall or the library they are getting some addresses. Okay. Now, you can see we are at /64, it's a little bit too far. So we are structuring our network and the /64 so insight is not a good idea so you can recalculate your address scheme and say I don't have another addresses, go back to the RIPE and say give me nor. They won't to that. Or you have to recalculate and say okay, I have to give them a little bit more, then you have doing back and say, okay, we have to give less addresses to a rural district and something like that, so you can play inside those squares up and down and at the end you will get really structured address scheme, just by colouring some squares.
Now, do we need a programme like that? When I first thought about that and put together this address scheme and showed it to the German government, they said, you should publish it. I said no, I won't, because my first thoughts, nobody who can write address plans needs it. He can write address plans, so it shouldn't be useful. And nobody who needs this programme should write address plans. And still, thinking this is right. Because for the first thing, yes, I don't need this programme to write address plans, but to explain it, it's very easy, you can go with scheme and go to the police and say, hey, that is your blue square, that is your addresses, and this red square it's for the ‑‑ it's very easy to explain it so even someone who can write it can use it. The other way, no one who needs this programme should write address plans, that is true. We are having large data centre and we are building test data centre for IPv6 so my colleague had to build it and said I need some IPv6 addresses. I gave him a block of /40, I said should be enough for you. Just pick some addresses, two weeks later I am seeing some addresses and said, they look awkward. What is the idea behind these addresses? He couldn't explain. Then I said put it in the tool, two days later it doesn't fit in the tool. Then I said, that is not possible, it has to fit in the too. What is the idea behind this? No idea. He just did the same as IPv4. Oh, there is some space, I pick some addresses but that is not the idea of IPv6, we have enough addresses to get some structure address scheme. So I said no, you have to put it in there. Think and do it like this. One week later, have you done? Have you solved the problem? Yes. I gave the address plan to another one. Okay. I went to this guy and, yes, he started with this programme. I liked it. I looked at the ‑‑ at some interest and said, they also look walk ward, what did you do? I wanted the routing is very concentrated, I think that is good for the Internet but we have a data centre we have to do something for security, do we really want that your network devices has the same addresses as applications for routing, that is nice but for the security the not nice, I don't want one for denying everyone doing to my network devices and not to the applications. So the structure should be something else. It's the same when I thought I am giving the blue square to the police. Right now, we have 2,000 police stations with 2000 addresses, address networks, going to a ten applications, that makes 20,000 ‑‑ in data centre we have problem with excess lists not with routing, we have 3 million excess lists spread over 500 firewalls and we have to look that everything is working. We can do it because we manage it centrally, it works. But could it be better? Yes. If I use this blue square for the police, I only have one network for the police, ten applications, I have ten excess lists. That is much better. So I am reducing the excess lists by using structured address plan. So my second thought is, yes, we can use this programme because someone who can't right excess plans can't use it with this programme. So I am ‑‑ I am good. The advantages of such a programme, the resulting address plan is structured. The second: You are able to explain it, and the third, you can adjust easily to new challenges because the old scheme always went something new happened, mobiles or telephones with IP addresses, they come back to me, you have to adjust your address scheme, if you make one like that someone else can put that into it, so I am good.
The disadvantages: You may get the illusion: Structure is everything. That is not the case. You have to think before you write an address plan, what do you want to achieve? And why? So in the Internet you have to be with the routing, it should be good. In the data centre you have to be ‑‑ you have to think about your excess lists. Another disadvantage it's much easier to criticise your address plan. If you are showing showing someone he will understand it so he can criticise you. I also encourage you to do exactly that. You can't be that good you can't miss everything so everybody can talk about that to you.
Okay. Questions.
Andrei: Have you thought of open sourcing the software?
HELGE HOLZ: Yes, you can just ask my colleague, he will send it to you, right now we are waiting for comments from you so that he can adjust something like that.
Andrei: I was thinking of some kind of GitHub repository.
HELGE HOLZ: I am not that far. I am happy to find someone to programme that for me, it's a first step but I think it can make better.
BENEDIKT STOCKEBRAND: Just speaking for myself, I remember the very beginnings of this concept and I loved it from the start. But actually, there is a third set of thoughts where might at the side you don't want that, and that's when non‑technical people said oh, yes, I understand that and let's have one more column for whatever here and there and they don't understand about binary boundaries or things. Seriously, being able to explain these things to other people, a couple of people I am working with right now, they actually went to all the trouble to use video to draw these diagrams by hand because they still found it well worth trouble to have something to explain it to not so technical people and it's tremendously useful for this purpose, just a bit of feedback from my side.
JEN LINKOVA: Thank you very much.
JORDI PALET: When we had the last RIPE meeting there was a presentation, I think it was Benedikt and I mentioned hey, I have the solution for you so I am here presenting the solution for you, somehow. The point is about one year ago I think more or less we had this RFC from IETF, it was a work that probably took two or three years. The basic idea of this is sometimes it's useful not just to have a single address at every interface, even if we call this unique IP prefix per host I was arguing we should call it to be more clear but at the end didn't fit, but the idea is we are not doing a new protocol it's something that is basically using SLAAC so it's already there, you just need some tools maybe to manage that and so on but basically the it's not just a new protocol but new let's say usage of auto configuration, SLAAC. What this provide in this document is host isolation and by that better management and networks so ‑‑ by ‑‑ of course the ‑‑ the immediately idea for everyone here is building machines on host so you have IPv6 global address for edge ‑‑ machine you can have in a host. I am not going to go into the details, you can take look later on the slide and I am here also the rest of the week if you don't understand anything, also in order to be conservative with the time and I prefer to concentrate in some usages scenarios. The first thing here is this is something that we already using because as most you already know probably in the solar world we are doing already that we provide /64 for every PDP context so it's nothing new and then in the case of the ‑‑ we use technology that is called prefix sharing in order to allow at the time erring devices hanging from the server phone. This is also good to facilitate what we are calling since a while in IETF, IPv4 is a service because you can provide IPv6 only service to the server phone or to the host or to the device, and that was about the presentation from Benedikt in the case of enterprises, I recall from the previous RIPE meeting, and then you can use IPv4 as a service, for example, in the case of cellular but also in broadband we are also 464 for that. So it allows extending that concept that we have been using in the server ‑‑ that is what I am going to do now so if we use this we are automatically providing an isolation between user devices which typically is sometimes requirement by‑law by other times just to avoid abusing the network or avoiding privacy considerations between different users and so on so that is very common today but this way we can do it much easier.
It's also avoiding some possible attacks which are based on ICM IPv6 and it provides much better scalability and robustness for the duplicated proxies and forwarding and a few more features so this will be the example of this scenario, you have, for example, hot spot provider is getting a /48 for the hot spot inside from the for their ISP ‑‑ you have one laptop connecting to the access point and instead of single address is getting /64 and so on. ‑‑ the devices will work as usual but it's a possibility that the device can have that /64 for whatever usage they regard. Data centre usage, while very, very similar, in this case the user equipment is the server, not a laptop or a tablet or whatever, and a set you can have better machines or containers making usage of those. It's may be not so common in today laptops but I am running about 10 in my laptop so why not. Data centre example. So again, you have the ISP, let's suppose this data centre is getting the addressing space from an LIR, not being an end user, so it gets /48 for the data centre and it has decided that it's going to be using/56 for every wrack and then we have some servers getting a single /64 in one link, we have other servers that may be they have dual links so they get /64 for every link and so on. So basic scheme is the same as what we have seen in the previous example. I want to insist here that the addressing space, the length of the prefix is just an example, that is irrelevant. The important thing is that the last hop, the last mile is instead of a single address a /64.
Enterprise example, and this has some good things for the problem that Benedikt stated and also some surprise for Jen, I hope you appreciate it because I was late uploading the slides. So we have the enterprise example, same situation, let's suppose getting /48 and then they have some switches and they provide, for example, a/56 for every switch and in this case they use VLANs and instead of having a single dress for the VLAN they allocate a /64 for the VLAN. We do that across the network and you have your Jen, in your presentation from the plenary, and we can do the same and you can have also ‑‑ enterprise networks, Jen was asking every presentation so you have it here. So good. So the interesting thing here for Benedikt is you wanted to have a solution to still provide because you need to notice; let me go back, in the previous slides you had IPv6 but I was saying IPv6 I was not talking about IPv4, so I am beyond that time, I am finishing in three minutes. In this case it's just, I am talking just about IPv6, but if you look at the enterprise examples I mentioned explicitly IPv6 only VLAN, okay? So there is an IPv4 here, in the previous case as you can have as well as IPv4 but here I am not talking at all about IPv4 so what I am going to do now is make sure that it fulfils Benedikt requirements that we can also provide POU and how we do that, and automatic on demand IPv4 as a service BBN on top of the IPv6 only enterprise network. So that's the idea. It works. I already tested using OpenWrt so up to you to start using it. And I think that is basically it, I have some conclusions but open for questions.
JEN LINKOVA: I would expect people running to the mic. Asking how to configure.
SPEAKER: From OTE. How do you provision exactly those /64s, is it standard ‑‑
JORDI PALET: Using SLAAC, auto configuration, I was not sure how much time I was spend on the presentation, so I didn't stop it, I think it was the second or third slide, you have the details of the configuration but using just the SLAAC. The idea because it's ‑‑ so we don't want to use something that it will not supported by every mechanism so why we need to invent something new if we can do with this just SLAAC.
SPEAKER: So there was no need for extension to SLAAC?
JORDI PALET: It's the way you use it.
Andrei: I would like to ask because you said the main advantage of this is a host is innovation and the fact that every inter host communication goes through the first hop router.
JORDI PALET: That is the idea.
Andrei: I was under the impression why it is in the ‑‑ if you use off link prefix you will get exactly the same thing with one just /64 for all hosts.
JORDI PALET: This is what we were doing but it was not reflected in any document, we are taking advantage of the SLAAC.
BENEDIKT STOCKEBRAND: Just speaking for myself and which will Yes, ma'am berg house along the way. Just in case you want to find that thing, I didn't do that myself, we is it it together, I did it with which will Yes, ma'am and on the RIPE NCC archive you find it under his name because everybody ‑‑ my name is going to be mentioned often enough anyway. If you want to take a look you will find it in last RIPE meetings archives.
SPEAKER: David farmer University of Minnesota. Back to the what is changed. Nothing changes on the client side, there are some changes on the router side that ‑‑ so you need to be clear about that.
JORDI PALET: Yes. It's a different way to using an existing protocol. That is it. Thank you very much.
(Applause) link link I have more time than I expected. Cool. Let's continue what is being done at IETF recently. Please raise your hand if you are running a kind of enterprise cooperate network? No, cool. Raise your hand if you have deployed IPv6. How did you do multi‑homing?
AUDIENCE SPEAKER: PI.
JEN LINKOVA: I don't know how many in the ‑‑ but they would love it, I know. So, let me tell you how I am trying to do this. API are cool but if I am afraid that every single coffee shop around is going to take a PI and send it to the global routing table, I say vendors would love it because you mentioned how often you need to upgrade your router and how much memory we need. Secondly, I have this problem, long, long time ago when one galaxy far away we decided we are not going to put any new design which is not dual stack in the network and then we realise sometimes you have a real small corporate office which need to be ‑‑ but it's so small in such remote location so ISP might not actually want to run BGP with you, even if you have PI doesn't help you much. And indeed, we are not going to talk about address translations, this time we are not ‑‑ we want to have all these benefits of IPv6, no address translations. And it wouldn't be really smart thing to make changes on the host because there are some things which could help you to get multi‑home v6 if you can change something on hosts. Right? But, you know, corporate networks are quite conservative and they have a lot of legacy stuff there and I am grading all this stuff and my grandchildren will do that.
So, there is a set of requirements, how we can solve IPv6 multi‑homing problem for those networks. There are actually three things which need to be solved. First, if I have multi‑homed network I need to make sure I am sending packet based on source address to the correct ISP because it does not sound like a really good idea to send packets from ISP A space to ISP B, because I do hope that all those ISPs are good Internet citizens so they suppose to filter those packets, even if they are not ‑‑ we had a lot of presentations this week about spoofing and routing caches and so on.
Then corporate network might have some ideas oh, this is uplink and much bigger and cheaper, I want the traffic doing there until one day there is a big, all those people with instruments appears and cut my fibres so now I want to use my backup uplinks which I do not want to use all the time. How we can imemployment those policies and what we are going to do if uplinks are going down or actually what you are going to do when they come back up because it's completely different question. So, selections uplinks, first of all for small networks this black magic of policy based routing might actually work quite well for you. If you have like one or two routers, just few lines of policy and it would work. For people who like play with ‑‑ there is some work being done, when you actually make routing decision they can source addresses in the account, or there is a nice shiny thing about IPv6 routing and and and so on so there are solutions for this problem. What we do not have is solutions for how host selects the correct source address because again one uplink might not be suitable for host or it might be actually down. There is a work on making hosts aware of where provisioning domains, this is ‑‑ information about ISP A, here is ISP B prefix and DNS and so on, here is another set of information and host could understand that it's not connected to one like network black box, it actually different paths in the network and host might make some educated decisions but it's work in progress and we obviously do not see this thing being supported everywhere right now and I want everything right now, I don't want to wait another ten years before we can get multi‑homing done in enterprises. Multipath transport, my host might pick up all addresses at the same time, start sessions use them in parallel or decide this is the best one so I am going to use it. If there is some issues on the path will switch to another source address, it's quite cool, yes. There is MP TCP, there is work on making quick supporting on multipath but again if you look I am quite sure most of them do not do it right now and what we need is at least topical solution for this problem which we can do right away. So, let's limit the scope. We have been working in Routing Working Group at IETF too ‑‑ for every single possible topology, how we can solve this. It could be done but it's really tricky, and you again might need to make some changes on the host. So I will thinking let's make the scope smaller, let's look at simple but very common use cases. Let's look in the small enterprise or corporate networks which use those ISPs to access Internet, right, just Internet uplinks to two or maybe more or just two and used in two scenarios, primary pick‑up or kind of load sharing so I have two uplinks and I do not care which one is used by hosts to send traffic to. So something like that, wave host in enterprise network which contains ‑‑ to Internet, we are two uplinks, green and blue and users browser Internet to seek ‑‑ yeah. By the way one of the main difference between v4 and 6, in v6 host by design can have multiple global addresses and hosts are using source dress selection to find out which one to use. Each ISP gives you /48 because it's a good ISP and not giving you /64, there is a whole network of sum ISPs, don't do this. And host can assign green and blue addresses to itself and now it could use any of that. So, what we need to do? First of all if uplink let's say blew up link fails host mostly should stop using those blue addresses, late me go back so just for simplicity I am going to say blue addresses and green, if uplink is down floss way to use that address we cannot send the traffic anywhere, if we could it wouldn't come back. Let's say uplink came back up, we want to use that address again because if my primary uplink came back up I do not want to keep using backup ISP uplink so we need to signal to host as well and we might have primary back up policy and say blue ISPs is expensive, uplink has low bandwidth let's always use green if it's available. So three things which need to be signalled to the host somehow, so host is usually the best address it could. We actual have that already. We have existing mechanism which is fundamental in IPv6 called stateless address auto configuration. Router, router, still host, here is your prefix, blue or green? Use it. You can assign addresses from that prefix and use it because this is a prefix information and it has preferred lifetime which is on zero. And just to get everyone on the same page. So host might have 3 or 4 addresses with no restrictions used for new communication. After a while when preferred lifetime is expiring that address becomes duplicated which means if host might still use it if there is no other preferred addresses but it's not recommended, preferred addresses are better than duplicated but communication to duplicate that address would be still accepted because it might be some old connections. So, wow, SLAAC actually does it for us because if prefix has non‑zeros life times and hosts know we can use it, if host ‑‑ if my host receives RAZs preferred lifetime zero it's explicit clear signal that you shouldn't be using this prefix, use something else if you have something else. If you don't, don't use it. Okay. Now, how can we use this well‑established reasonably well tested mechanism to achieve enterprise multi‑homing? Cool. If my uplink goes down router shall just duplicate the prefix. If uplink comes back up prefix should be, how I say, deduplicated, might preferred again, whatever, router are send this prefix is available and use it. As a result, actually primary pick up scenario it will do the situation when your back up link is down until primary one fails and you pick ‑‑ comes back up. We need to do is keep backup prefix duplicated until it's time to use it. Looks reasonably simple. Question is how we can do that. It looks like we need something like policy, and those who use we actually have something like that, right? You can use interface ‑‑ most of the enterprise routers when you can say this is a master unless those interfaces goes down and then another router should be back up. Something similar. So what I want, I want to have a policy. I want preferred lifetime in prefixes not be something said in stone, you configure for all cases this by based on some policy, condition in the network. What kind of conditions. Interface state. My uplink to ISP when town or my BGP session went down, or some routers disappear. Whatever right? We can define that set. I am describing a kind of framework here. What needs to be updated? Obviously preferred lifetime for prefixes. Actually you might to the same with DNS if you use two different continueses from each uplink but I do not think it's common scenario, if you have two routers and you want one to be not used.
Example scenarios. Quickly. Primary backup link. Let's say green one is primary blue one should be normally backup. When everything is okay router sending two PI O green and blue and it's only zero glue one is duplicated so hosts would prefer green addresses for everything. And our policy would like like if uplink is up preferred lifetime for prefixes seven days default so you can use whatever you want. And if uplink is up blue one should be duplicated, otherwise we need to bring it up. Let's say primary uplink fails suddenly routers implement the policy and start sending non‑zero, and hosts obviously will keep ‑‑ host will start using blue ones and all the existing connections to green ones for example inside the network will be still okay. So I think it looks good. Next one, active, active, even simpler. Just use both prefixes, let host decide, whatever, it doesn't matter. If uplink fails, then obviously the failed prefix will be duplicated. What we have here, the first few slides were about situation where you have one router, two uplinks, you might say oh wait it's a single point of failure anyway. Not necessarily because that one router might be actually few logical routers combined ‑‑ two physical combined as one logical, I don't know, SR S, cluster and so on. Two two routers, makes your routing policy more complication but would be signalling the failure because both routers need to know about uplink state on another one, right? So here maybe you might want to use this interface route on your routing table or route or something else. But the whole logic stays the same. If uplink is ‑‑ can be used then prefix have non‑zero preferred live time and for duplication prefix we just use preferred live time zero.
Failure scenario and in this case green ISP uplink is down. Green prefix is duplicated and example policy is on the right side of the slide.
Active, active, basically the same, I will leave the ‑‑ you can look on the slides later but I hope my idea I make idea reasonably clear. Indeed, as I said, I wanted to limit the scope so I do not think this is ‑‑ this would work very well for really complex topology unless you actually want to use particular routes as a signal because the more complex your network is, the harder it might be to signal all those things but for small networks it actually works quite well. But you can use your imagination on how you can use this for particular network topology. So, actually the interesting thing, for uplink failure it behaves like what we have in IPv4 world, it will ‑‑ if uplink fails connections which were going through that uplink will fail. Sorry, because the source address will change. But for uplink recovery and like what we have in IPv4 NAT, your connection will still say the same if the host was using blue addresses because of the primary uplink failure and then primary uplink went up, you can sill send those blue source to the blue ISP and everything would work. While new connections will be using green source, so actually, it's better than v4. It's not just the same. Cool. Some people told me it's insane, it's complicated, why are you making these things up. It's not actually something new. First time I heard had problem I was thinking about all this tricks with RA, I went to vendors and ask how other people, how do other people do that? And they were like, they don't so I went to other people and they told me come on, just get rid and use OpenWrt, use Homenet solution does it for you, it's a requirement for IPv6 CPE if your uplink disappeared, duplicate the prefix, it's already here, just an attempt to get this functionality into small, medium business enterprise, great stuff. Not something new. Prefix disappear you have no way because host could not use it any more.
So, I expect people thinking how can I do it now, which general version or OS version I need to install right now, to have it. Well, vendors are working on getting this implemented as a configuration policy, net could have been ‑‑ some nice vendors have some automation in place, so actually this is could be done in a in case of one particular vendor using event policies. Could be done right now, there is a work in progress on making example scripts available on GitHub, not there yet but stay tuned. So you can do it. And you can say I am ‑‑ it's almost SDN. So questions?
SPEAKER: David farmer, University of Minnesota. One thing that I was thinking about, when your link comes back, you probably want your policy language to also include some sort of debounds because you couldn't ‑‑ when it comes back did it really come back or come back for a second and so you probably want too far debounds to hold it down for a little while, it came back is it really going to be back? .
JEN LINKOVA: The draft which is just when, it is currently last call, talks about that. So indeed, you might want to have some kind of link policy saying I am not unduplicating the prefix unless I am sure it's really come back if it's flipping a lot, it's actually more strict thing doing for example with June OS automation because you can do everything except event policy you have to keep about history, you need to use real automation scripts here yeah. But obviously this is actually covered in the draft and I am talking about all details, you can read the draft, I am looking for comments and it will be actually happening RIPE post about this tomorrow so you can read more details there, probably.
SPEAKER: From University of ‑‑ so you always assume that you know that ping went down? What happens if you don't.
JEN LINKOVA: Link I could not cover all possible cases and combinations of everything on this slide. That is why I am using a ‑‑ a is generic logic, what can you use as a trigger is up to you, right? Because it might be interface state. If you have BGP you might say okay it's my BGP state. You might use kind of ping or like monitoring thing from the router for example, it's up to you, it's ‑‑ it's really, I don't think it's possible to reliably determine that this uplink is not working, you might have some indications and ping something through that uplink, it will give you probably better criteria but, yeah, interface state is something really simple and I am just using interface uplink as a general I can term, not necessarily interface state but just an example.
SPEAKER: So, Jen, did you look at Shim6?
JEN LINKOVA: It is a draft. We have something which you can deploy right now, right?
SPEAKER: 50 years ago the IETF had a Working Group multi‑homing in IPv6 and then we looked at all of this, then we came up with a new Working Group Shim6 which basically has a system that allows you to switch live session without going down from one IP address to another and all of ‑‑ not all of this but many of the things you propose here are complementary to that work so they could amplify each other and of course Shim6 wasn't really implemented but if you are going to ‑‑ there was an implementation but I should say there wasn't really deployed. But if you are going to do this, you want to at Shim6 because even if it doesn't help, if the other side also uses it then then you get to survive your sessions when something goes down.
JEN LINKOVA: I think Shim6 is not ‑‑ it's not ‑‑ we don't have deployments, right? And for Shim6 if I understand it correctly we can benefit that if some other people did some work for us, I have enterprise network with some laptops and phones and I have no control over that ‑‑ actually I have no control over them, I have a where people come into me with something and I need to make sure those devices work and if I have a power of enabling something on devices and Internet, I would route enable multipath transport and let them use like MP CP but what I am looking here is for something which works for less common demon Nater, random v6 enabled host which implements source address selection. Multipath transport or Shim6 if I wake up and see deployed, will complement this but I do not see it for you should be deployed widely enough.
SPEAKER: So the notion that multipath TCP will help you with this is incorrect because it's meant to have multiple paths at the same time, it's not meant to ‑‑ not a mobility solution, so you read up on the whole discussions or of does the captain survive the sinking of the ship with the MPTCT but that is not really a solution. If you are going to do that it is foreign refer to the folder work so you are not reinventing stuff and you say I want something that is deployable now, how long does it take to implement new options and router advertisements in all the routers that are out there, it takes forever also. So I don't think that just because it's not deployed today that is a reason to write off stuff.
JEN LINKOVA: First of all, I use in as an example, there is a lot of work happening right now in various, I am co‑chair of ‑‑ of making hosts being able to make educated decisions about different parts of the network, not necessarily P ‑‑ whatever we want to have as multipath transport would help us with it a bit I don't believe any time soon I as network he can engineer and enterprise network would say I don't care about hosts which could not do that, we have enough hosts which could so let's do this. I need something which make all of my users happy so ‑‑
SPEAKER: If you say I want to make all of my users happy that doesn't then starting from scratch well, there is stuff out there that already does a big part of what you need and ignoring that stuff, that doesn't make sense. If you say I want other stuff also, then just make it part of a bigger picture and it will help each other and that will make the case for what you want stronger.
JEN LINKOVA: I also think explicit signalling is always better than doing some ‑‑ I guess this path in my network just is not good any more so I need to switch to another one. So this would help ‑‑ anyway transport to know oh this uplink is going down, we are not using it any more at all, right. So I do not think how this would break anything for multipath enabled host, they could work very well together but I checked in my network, I do not see plenty of user at the vices with any form of multipath transport and implementing these is like one day of doing automation, it doesn't take much time to implement, it's very quick.
SPEAKER: I don't agree. No time for all that.
ANAND BUDDHDEV: This is Anand from the RIPE NCC chat monitor. I have a comment from Tim Bray of. He says I have tried to do this in my organisation and office networks, the theory works but clients don't work well in practice. They don't cope at all PI O preferred lifetime equals zero.
JEN LINKOVA: It would be very interesting to know about devices which do not do that because basically sending PI always preferred lifetime zero is actively used in ‑‑ so I will ‑‑ unless there is a busy wi‑fi network when some RAs might get lost, send some, more than one of them, it would be ‑‑ we need to stay in touch and discuss which hosts don't do this.
SPEAKER: I have done that and it doesn't work. Actually, if you have a small network the problem is you don't only have eyeball customers that need to access YouTube or whatever for a short time but you have an office network with with self employments with whatever access list you can imagine even in small companies. And you won't change that all the way down the road when you are changing your uplink especially if you have users outside your network and they will dial in and use one of these connections, you also have to take the DNS changes into perspective. And just doing round‑robin won't work, doing load balancing won't work for the small companies probably as well so I am one of those companies ‑‑ I am representing one of those companies using PI for multi‑homing because it it works way better, it just works. You have all these long running connections not breaking, and whether your concept ‑‑ with your concept they break.
JEN LINKOVA: I do agree there are scenarios, some topologists when they won't work, however I have seen cases where people using D DSLs as backup, wouldn't help you there at all. So and about connections which have to survive, if ‑‑ there is no way if ‑‑ which cannot do not want to run BGP and we are talking about them. If you can run BGP, if you can run the have PI it's not for you obviously, there is a network there which have no options of running BGP and using PI.
SPEAKER: The thing is I wouldn't run PI if this would work.
ANAND BUDDHDEV: The same guy Tim has a small comment. He says mainly Linux desktops broke for him, that were on wired ether nets and he continues for medium‑sized companies with any kind of on site file service and stuff, PI space is much better.
JEN LINKOVA: Again, yes. I probably should have phrased it better, if you have PI you can run BGP and go back to your emails. I am solving the problem of places where we do not have PIs and still need to be multi‑homed.
NICK HILLIARD: INEX. This is a restatement of the problem about renumbering IPv6. IPv6 has never been easy to renumber despite what we have been told by the IETF about how easy it is to renumber. And although it's a nice idea, it doesn't fix this problem which is the main problem that small sites face for multi‑homing.
BENEDIKT STOCKEBRAND: We are already way into the coffee break. Thank you very much, and we are going to see you hopefully in half an hour.
JEN LINKOVA: Rate the talks.
LIVE CAPTIONING BY AOIFE DOWNES RPR
