IPv6 Working Group session
RIPE 87
30 November 2023
11 a.m.
RAYMOND JETTEN: Good morning everyone. We'll wait a minute because people are still coming in.
Good morning, welcome to the IPv6 Working Group. Today, we have some different programme than usual, we have a working group co‑chair who is stepping down, and a new one coming up and therefore, we have selections, not the elections but selections.
When you registered for the meeting you had a link to Meetecho, and we're going to use that as a voting system. Since then also remote participants can vote.
If you want to operate in the voting, you have to go to Meetecho and I suppose you do it now. So you can get the ‑‑ that's for that. I'll repeat it before we start the actual voting.
So, welcome to the Working Group this morning. The RIPE 86 minutes made by the RIPE NCC, thanks for that, who have been on the website for a long time. I have asked for comments but it's been rather quiet on the list according to that so, if anyone in the room has anything to what they want to have changed in those minutes, speak up now or they will be approved.
I don't see too many people running to the microphone, so with this, they are approved.
If you have questions, and you come up to the microphone, please state your name and your affiliation and then give your question.
STENOGRAPHER: And speak slowly!!!
RAYMOND JETTEN: Then with this, I will start the first bit. The co‑chair change. Benedikt, please come up here. Benedikt has been doing this for nine years, and, you know, he has been doing ‑‑ been a very nice colleague to work with and I can recommend him for anything you'd like to do with him, he is a very funny guy. But he has decided himself to step down. So, it's time to say good‑bye to one of our known faces and we have some things that we'd like to give you.
First of all, to make sure you don't dry out in this warm climate of Italy, you got something to drink. That's a thing the RIPE meeting doesn't work without, it's wine or beer or anything you like. Then of course if you sit in the back of the room see how we're doing in the future, you need POP corn. And to get the bolt open it's very handy to have a bolt opener. And because it's maybe in some countries a bit rude to drink from the bolt, we also have a special glass for you. Since you are stepping down from IPv6 Working Group, you have an IPv4 glass.
So, Benedikt, thank you very much, I mean seriously, and, you know, we'll see you anyway on stage at some point.
BENEDIKT STOCKEBRAND: Just for myself, you are not going to get rid of me. It's been great fun and a privilege or whatever you want to call it, being with both Jen and you and Anna before doing this, and I'm not stepping down because I'm tired of it, it's just getting harder and harder to get to work with everything else I do, but there's a good chance you'll hear from me because I might come up with the odd presentation anyway. And somebody actually asked me this morning, will you continue to come to the RIPE meetings? Well, silly question, isn't it!
Thank you very much. And if there is anything you need a hand with, you know where to find me.
(Applause)
RAYMOND JETTEN: I'd like to call Paolo and Christian on stage. And they will both give a short introduction to themselves and tell you why they should be voted for. And as you can see, we have a pool going on, which is on Meetecho, so log in there if you want to vote. You can see the results immediately on the screen.
CHRISTIAN SEITZ: I am Chris, I am 46 years old, I am from Berlin. And I started doing BGP in 1999 when I joined the non‑profit volunteer driven ISP individual network Berlin, and one of our members came to me in 2004 and told me, okay, I'm an LIR in Berlin doesn't have IPv6 yet, here is your prefix, please start deploying IPv6. And that was my first contact with IPv6.
And in 2005, I moved to a company named Strato, a big German web hosting company, together with William Berghaus and we introduced IPv6 in the network and turned it on for our products in 2011 during the World IPv6 Day, and never turned it off again because we didn't have any big issues.
In 2019, I joined system DE as a network consultant doing some stuff at customer networks because this was more interesting to me than just having my own network. We were also deploying IPv6 in those networks but we still have issues. Two years ago, one big vendor started to implement IPv6 on their firewalls and customers want to use high availability and until today, those boxes don't support IPv6 with high availability.
So there's just ‑‑ there is a lot to do these days. And we created a subsidiary last year which is ‑‑ does only IPv6 things, and created also an IPv6 knowledge base, I am supporting this subsidiary with my knowledge, and I am attending RIPE meetings since RIPE 56 in Berlin, and ‑‑ but have never been an active RIPE member. I always talk to the guys that joined the RIPE meetings and took a lot from those meetings and I think now it's the time to support and engage in the RIPE community and do things in the IPv6 Working Group and support Ray and Jen. That's what I would like to do.
PAOLO VOLPATO: Thank you Christian. So, Paolo, I am from Milano, Italy, I am quite local, I would say. In terms of affiliation. I am currently with Huawei, so if say Huawei, someone may think that that's, you know, a kind of under cover sales person trying to use his position to sell more equipment. No, actually that's not the case. I am with the European standardisation department of Huawei and as such my interest into IPv6 related matters is that I go to the IETF, and other standard bodies, to, let's say, try to make IPv6 evolve. And I do believe that here, at RIPE, there is a lot of operational experience and operational knowledge that we may benefit when considering the feedback on the work we are doing at the IETF. So, that's why I try to, you know, apply for this position. Compared to Christian, I'm quite newer to RIPE. My first RIPE meeting was less than two years ago, RIPE 84, but as I said, I think there is a lot of value. So that's why I'm here again. Thank you.
RAYMOND JETTEN: So, you have seen that we had some trouble with the poll and we have made a new one. So, if you have ‑‑ do they have to revote? Okay, so please revote. And do it within the next 50 minutes or so. I will tell you later who became the Working Group Chair or Working Group co‑chair.
Right. And then it's time for something different. Essentially it's actually Paolo having a presentation.
PAOLO VOLPATO: So, back again. So, while we wait for the right presentation to appear, let me just introduce my talk, which is actually I will say a high level summary of a work that the group of people that you'll see in the cover pages, when it appears, is doing in the v6 ops Working Group of the IETF, and it's about supporting multi‑homing using IPv6 clearly.
Now, why do we believe that speaking of multihoming is still relevant? There are a few reasons. First, resilience. So having, for example, enterprise site connected to multiple carriers is a necessity for many businesses because they need service continuity. And speaking technically, multi‑homing with IPv4 is basically solved the problem. So, typically you use a private addressing into a site, and you have translation at the border.
With IPv6 ‑‑ well, ideally, we should get rid of translation, so we would like to have end‑to‑end connection, yet the current methods available today and used in the field may have some drawbacks.
So, the ideas behind our work is to try to document what it's really used in the field field today to enable multihoming, discuss the pros and cons of the methods and try to define their applicability in a neutral way without any bias, I would say.
And there is one more reason. You see here at the bottom of the slide, there is an IAB statement that says ‑‑ and you will find the reference at the end of the presentation ‑‑ that says that as many as 10 million sites will use multihoming connectivity by the year 2050. Clearly we can disagree with that number, but yet if only a portion, only a fraction of that becomes a reality, clearly we have to consider at least for the impacts it may cause.
Now, the characteristics that we have considered in our analysis. Very quickly, we have a couple of CPEs at the border of the site. Internally we have arbitrarily complex architecture, or topology, and we have a host that connected to the two CPEs. The CPEs get for example two different prefixes from the carriers, they are connected to and they give at least one address per interface to the host. Then we have other things to consider. For example, the availability of walled garden services. So something that one of the carriers, carrier B in our example, grants to only a portion of the customer base.
Now, maybe I am oversimplifying the different cases here, but just to provide a quick example that everybody understands.
Host has a sort of an active role in deciding where to send the packets. And it's involved in how to forward the traffic he wants to send to a certain destination. Let's imagine that host is connected to a remote destination using carrier A and then some sudden failures happen over the link, other the ECP or whatever, and that failure is not signalled, is not communicated to the host. So, host has to rely on the information stored in its caches, waiting maybe for a router advertisements, setting the expected lifetime to zero or something like that and since it's working sort of standalone relying on the available information, he may keep using CP A as the ‑‑ CP 1, sorry, as the next hop, as the default gateway, and using the older address to communicate with the destination. And at the end of the day it gets stuck.
So, packets are not forwarded or if they are, may use another link entering carrier B and being filtered out at the border of the network. And the same could be considered if you use the walled garden service, so you are connected through carrier B, you lose connection, it's very hard to go back to the walled garden using the other carrier.
So, what are the solutions that we have started to consider?
Well, there are six at the moment, if you read the draft. Using static PI, providing independent addressing to the site and relying on the carriers to propagate the information. This is basically the case we have just seen in the previous slide. Then we have a couple of ULA based methods using translation, NPT v6 or NAT 66. An another two for example the number 5 is the centralisation of the issue of providing resilience to a central hub, so traffic is sent from branches to the central location and the central location is connected to the Internet reliably. And then we have an application proxy which more or less is similar to a number 3 or 4 in the table.
The next question is how do compare the mechanisms.
So, we look at the available literature. In particular, we have borrowed some content. We took inspiration from RFC 3582, which is about support multihoming, and we have defined at the moment seven main requirements. The first one is support any number of carriers, at least two but it could be more, end‑to‑end connectivity and see all the others here. For example, speed over convergence in case of deputation, traffic steering, support for sites complex topologies, maintaining internal connectivity no matter what the status of the CPEs at the border and so on.
Now, as I said, there are seven of them but you see there is space for more. So anticipating one of the conclusions I am sharing with you: If you think there is more we should consider, we are open to the discussion. So, any contributions on that is really welcome.
Having defined the mechanisms and the basis to compare them, we have started let's say pros and cons analysis. Given the strict time for the presentation, I am not going to go through the entire table here. The scope is just to save you, if you are interested, a kind of 15 pages reading of our draft detailing, you know, all the bits and bites of the different methods. But basically, you will see that using PI or dynamic PA, so the first two methods, they have a lot of advantages. Basically they are known especially the usage of PA is kind of common configuration. Above all, they preserve the end‑to‑end connectivity which is probably a requirement number 1, considering we are dealing with IPv6. Clearly they have costs. The first case, there is a configuration cost for a PI, not all the businesses, not all the enterprises are interested in using that or spending time and energy in configuring. For PA, as we know, not all the issues are solved yet. So there are corner cases where problems may arise.
On the other hand, just sticking to the use of ULA plus translation, well they have advantages. We have to be pragmatical here, so they tend to resemble what we have today in the field today. So they apply translation. It is through NPT is prefix translation, it is not NAT, which is on the other hand case number 4. But they have disadvantages. So we have to, let's say, take care if you want to apply them. There is the, an ability to connect for example from the outside if you use NAT 66, which is something that NPT v6 partially allows.
So there is the entire pros and cons, and again I invite to you read the draft and provide comments about that. I am skipping the other two because more or less it presents similar issues here.
So, if we move to the, let's say, final comparison, basically we have spent a lot of time inputting, you know, plus and minuses, so this technology is okay with a certain requirement, the other one is partially okay, you have, you know, a fixes or you have to manually configure something to apply that.
So, you do the mathematical sum, you draw the line and you get these results. So basically, if you look at the arrow just at the bottom of the slide, theoretically speaking the best method should be PI followed by PA and then the usage of ULA and translation. But as I said, that's, I would say, theoretical. This is why we need the support from the technical community, and we have tried to do so specifying a poll where everyone can propose the configuration used in the field, define the characteristics of the specific setup they are using.
So, having this table in mind, I moved to the poll because here, we have collected some feedback, some real feedback, I would say, from the people who decide to join the survey and propose their configuration. So, as you see, something from top left, the first question is: How many CPEs you consider in your deployment? And you see the majority of the cases is two. But there are case where is there are also three and more.
The uplinks, typically, is one per CPE, but you see that there are also cases where there are two. So a CPE is connected simultaneous to two different carriers. So you see that the specific setup, the specific configuration used become quite difficult to be configured and maintained.
What's the configuration you use typically is the active activity configuration. It's not active standby. There are no routing protocols in between, VRRP for example, for the dynamic update of the states between the two CPEs you see it's active active. They are available at the same time and clearly there is the coordination of the hosts inside the network of two forward the traffic. And finally the last question that is probably interesting. What is the method that you are currently applying? And you'll see that in blue, it's PI, followed by PA. And I would say that could be guess guest from the beginning then there are different flavours of usage of an ULA and translation. It's both MP v6 and NAT 66. You see the number of answers is not very high yet. So I do invite you to provide your experience and, let's say, grow together, see if if our survey becomes statistically meaningful. So that we can draw some more considerations for our work.
By the way, you see at the top of the slide the link to connect and provide your feedback.
So, from that I am moving to the conclusions.
Probably something that we may expect from reading the different RFCs on the matter. PI is the best tool we have to support multihoming. It is true because apart from getting the PI address and relying on the carriers to provide the announcement, there are no specific functionality requested on the host. So internally to the network of our side.
And then PA.
So, again, if we look at the theory, what we have probably that's the right choice. But there are consequences. So, if the IAB statement that I showed before is true, there may be in the future an impact on the global Internet table. So, we have to carefully define the applicability of a PI. Maybe not today but in a few years that could be the case.
And probably we are lacking some local factors, something that you consider in your job why in dealing with multihoming, using IPv6, that is not considered yet in our draft. So that's why we'd like to know if there are some other known technical aspects to consider, to provide a sort of guideline for the applicabilities of the methods we have seen before.
So there any other requirement that we should consider? We are very open to the discussionr. So that's why we would be happy to get your operational experience, any talks, any questions, any comments either at the microphone or during the break is important and welcome. I would say that's it.
(Applause)
JEN LINKOVA: I think we have Niall in the queue first.
AUDIENCE SPEAKER: While Niall is fighting with computers, I'll just jump the queue ‑‑ there he is.
STENOGRAPHER: The famous phrase: You are on mute!
NIALL O'REILLY: You can hear me? I am sorry, I was in the queue from earlier when I was pointing out that the first poll was running too fast and I forgot to stop. I think it was a good idea to run a dry run. So, anyhow, that's all I have to say at the minute.
JEN LINKOVA: Okay.
AUDIENCE SPEAKER: Gert Döring: I have been following the work you have been doing and it's great you are doing this. The problem space has been around forever, and actually having all the possible solutions in one document so people can make an educated choice is good.
While here I want to sort of stay in my favourite model for the barber shop stuff is the dual‑provider aggregatable prefix. Not because it's less burden on the routing table, which it is, but also because it actually empowers the client machines to make decisions. So you could actually have the client say, my super critical voice traffic goes to ISP‑A and my bulk downloads going to ISP‑B by proper source address selection. Which, of course, opens the huge can of source address selection and source address failover if you have a communication. If you mostly prefer ISP‑A but Google is not working there you could just Google over ISP‑B but the applications wouldn't know how to do that. So there is potential for bright solutions but stuff is missing, and has been missing forever.
PAOLO VOLPATO: I fully agree. I don't know if maybe the next speaker is also touching this point in the presentation. Could be... there is much more work to do, you are right Gert.
AUDIENCE SPEAKER: Rinse Kloek speaking from Delta Fiber. I also agree with Gert. I am also not a big fan of PI space, so, I also case about the growing routing table and if that number you mentioned in the start will do PI we have a big problem, especially for the users of alt routers and also if I look at my own AS number I see the PI is just a very small part of the customer. So ‑‑ that's the good thing. That was what I want to state.
AUDIENCE SPEAKER: So, have you looked ‑‑ so, we have an ability to inform clients they are, they have two different ‑‑ they are in two different PIs, but I won't say they support it because I have no idea where it's even used but have you looked into mobile IP extension?
PAOLO VOLPATO: Not yet, not in details. That's something we can consider.
AUDIENCE SPEAKER: Yes, because there is an ability, I would guess, that on the router that we could still replace and say, yeah, this is the IP where it's coming from now but the previous was that one. So there is an ability to inform, or at least an approximation of that, so maybe that should be an option to look if that's possible or if that can inspire a new solution.
PAOLO VOLPATO: Let's discuss later maybe. Thank you.
AUDIENCE SPEAKER: Jan Zorz, 6connect. Thank you for this. It's an interesting research. And if the AA P methodology is correct then you have 10 million, then ‑‑ or we decide not to do PI addressing, or we decide that silicone is chip. Maybe it will become chip. I don't know. But if we do a PA thing, the thing that you showed in your first slide, if the CPE 1 would die, then the neighbour reachability protocol would take care of it and switch the gateway to the next one. That part is solved.
The part with the host source selection mechanism being fundamental broken is not solved yet. So, but we're working on that at the IETF when people is now changing the standards that the host must have ‑‑ must keep the information from which gateway they received which prefix. This is part of the solution that maybe will get implemented in years. And the other problem is if the CPE one, when it comes back alive receives a different prefix then we have a problem, right? Because ‑‑ and Jen has a beautiful draft and beautiful, very, very good solution how to fix that with creating different gateways for different prefixes.
JEN LINKOVA: It's a working solution.
JAN ZORZ: Yes. And I like it. I like it. I would like to help you with working on that. So, we need to fix that part, because we document it in one RIPE document that it is talking about prefix delegation, dynamic or static, exactly this problem, and I am glad that somebody is working on this. Thank you.
And we are also now trying to change the timers of the ‑‑ the TTLs of the prefixes at the IETF, and I hope we will get through soon.
JEN LINKOVA: Don't forget to send me the draft. I'll put myself in the queue. No Chair hat.
Actually, a question: Are you intentionally trying to kind of boil the ocean and cover all possible random number of links and so on? I think it still might be easier if you consider different typical scenarios which might be low‑hanging fruit and cover, let's say, 80% of our current use cases and make it more attractive for people and let the last ten or 20%, say something like we need to think about. Because also I suspect that all these complex scenarios which is hard to address now might actually belong to the cases when networks do have their own PA space and don't have the problem at all, right. I basically do not know how big is the problem for, I have 25 different carriers and five ‑‑ and I still don't have my PA space. Maybe we don't want to focus on it. I just don't know.
The second question following upward on what Jan said, we cannot solve this in most of the cases without rule 55 right, result host tracking our gateways, but Microsoft Windows does this as far as I know, Apple definitely does this. I know there are open source developers in the room, so I know there is some work on Linux happening. In my opinion, Linux is the biggest problem right now so we need to make it happen in Linux and then we, strict leap speaking cover most of the normal host operating systems, because without it, yeah, the only thing you can do probably is PI on in the and NAT would break applications, because it might work for v4 but for v6 there is no NAT transfers in many implementations, so you just cannot do NAT because I think the argument it breaks applications bathe disqualifies the solution.
PAOLO VOLPATO: A quick question to both the comments. Yes, for sure, the draft will evolve according also to the evolution of the other drafts that you mentioned. And in termination of use cases, well our intention was to collect the currently available set‑ups, configurations, whatever. But as you say Jen, probably the draft will evolve, you know, to simplify a bit, you know, the landscape. So just considering the most common developments.
JEN LINKOVA: Thank you. Any more questions?
AUDIENCE SPEAKER: Brian from TWT. I just wanted to bring more an observation of what I have seen in the last year coming from some multinational American companies.
Here in Italy, I have had three different tenders for offers where they have their own AS system and they have their own IPv6 addresses, and they are assigning /48s worldwide to different sites all from their own block. And so I have seen now that the bigger companies are already moving towards that PI type of solution and fragmented obviously so we are getting ‑‑ I have seen three in the last year and they are all American multinational companies. I haven't seen it yet from any European companies but a lot of things start over there and kind of boil over here, so I don't know if that's the same experience others are seeing. But for us it's started.
PAOLO VOLPATO: Thank you. And let's say that based on the feedback we have collected so far, you are right. So probably the big PIs tend to prefer PI. Probably they have money, and as I say energy to put in that.
JEN LINKOVA: Okay. Any more questions? So, thank you very much Paolo.
(Applause)
ERIC VYNCKE: Okay. So don't be fooled by the slide colour and font, it's not Jen speaking, right. This is Eric Vyncke from Cisco and by the way AS 10 the Cisco is using a single PI and announcing at multiple places in the world. But we're not a small company.
So, this session is basically the continuation what we did in the IETF BoF in Rotterdam. I want to keep the contact between this community and the IETF community. A couple of people are bridging but let's make a session as well. What's new?
Disclaimer: I will take the liberty to basically express my own opinion on some work in progress that's being done there. They neither represent Cisco or as I am also the Internet director at the IETF, it does not represent the opinion of the IFG on this one.
Having said this, let's start with v6 ops. IPv6 operation. Okay.
The first one, 2001 db8 /22, the documentation brief. In some cases it's not large enough. If you want to make an example over a service provider having multiple customers, each of them doing MPLS VPN or other Layer3 network and having multiple sites, clearly if you want to be realistic, you need something which is a smaller prefix. So the intent is to get a /20 there to be more realistic. I think that's a no‑brainer right, so that's cool.
Another one is kind of funny, we all know IPv6‑only network exists, and it's mission impossible, right. Again a small hint. But if you want to have your resolver on your host because I may want to do DNSSEC for instance on your own, how do you do DNS64 or even to reach IPv4 only website especially if the authoritative server that you want to contact because you are the resolvers on your own PC is v4 only, it means that the DNS request needs to go through the NAT64 as well. But you get the chicken and egg somehow. Because you cannot run DNS64 without reaching the authoritative server. So basically you need to be able to pre‑configure a few things and be able to discover the prefix used for NAT64. It's basically a very simple draft but an interesting use access.
The other one, and this is where I will express my own opinion. This ULA usage consideration draft was quietly lingering in a cemetery forgotten by everyone but is back to life. So I'm not too happy on this. I don't like ULA just in case you didn't notice.
Another one, this draft ‑‑ we'll start with the draft last name and draft IETF, it means that it's not adopted yet by the Working Group. It's very far away in the design process, publication process. But you will see my last slides, there is a working group called snac and now it's ‑‑ no, it's not a hint for lunch. It's basically where if you receive an negative prefix at the PC you may want to run the HTTPD so watch your customer on your land on your inside. It seems to be common sense, but it's nice to say.
.
Happy eyeballs, remember 2011, 2012, Happy Eyeballs saved the world and said basically the deployment of v6, because we assume v6 is broken, right. There is a v2 which is implemented right now. There is a v3 coming, and the v3 will use as well as a new DNS record called SVCB where it's basically gluing a few errors together to simplify t the eyeballs with use this, including the selection about the transport mechanism, right, whether it's quick over TCP for instance, meaning we are shifting for something which is completely IPv6 orientated to something which is transport as well. So, this Happy Eyeballs version 3 may move out of v6 ops to something which is more transport orientated.
Then you have got the draft which I think is useful.
Another one, again I guess about the fund and the colour of the slides, it's DHCP‑PD per host, or per node. It's basically not only giving out a single IPv6 address to a node, but giving out a complete prefix, a delicated prefix. Typically a /64 to respect SLAAC and so on. Why? Think about tethering, if you want a multiple host behind so you need to extend it, or if you want to run multiple PMs on multiple containers on your laptops you need multiple addresses. It's also easier that all hosts rright now have multiple addresses, temporary addresses for instance, it means that all the routers and the switches and so on needs to remember the mapping between the MAC address and the v6 address, it doesn't scale so much right. So if you do this you only need to remember a single mapping. This prefix to this link local and it's moving from discovery which was never very secure, never scaleable into routing. Because you route to a prefix, right, so it's much more scaleable, it's much more resilient as well. So pretty cool.
Some brief. There is a check, can you guess which Working Group is this one? One man, two man, three man, four man, five man, six man, right! That's a good one. I stole this from Jen. It's not you? Okay.
Anyway. So, you are awake. So on this one. Remember, when I said we may want to delegate a prefix to a host. But how can a host know that he can get a prefix? So, what I did there is basically to add into the PI the prefix information option, one flack telling A, there is also delegated prefix there, right so. We can ask and request a PD.
Another one, RFC 6724, which is basically the source address selection. They want to make a change. Because currently, if you have a NAT IPv6 global it is preferred, of course, to IPv4 address but IPv4 is preferred to ULA, which I think does make sense. But some big US federal network deployed only using ULA. So having ULA and RFC 19 address space if you are following RFC6724 it, you end up using RFC 1918 address. And if you want to move to IPv6, it's not really correct.
So because some people, and again this is my own opinion, right, because some people make some strange network design, we may want to change this draft there, and basically updating the RFC.
Just in case I don't like it.
Another one is draft template, it's not an IETF Working Group document. It's based on the fact that bandwidth is higher and higher and so you can have more than 65,000 fragments on the path still waiting to be reassembled so you'd be running out of IDs for the fragments. So you want to extend the fragment ID's space from 16‑bit to 32 bits or more.
It's basically very early thing.
Extension headers, the one we like. There are basically two competing drafts. I mean roughly for the same thing.
This is from Bob Hinden, the one who wrote IPv6 t basically says each and every new hop by hop option, the stuff you put inside, should be design and only accepted if they are be done by speed. Very easy to do. Could be done in assic. If you remember all the option you put in hop by hop options starts with 2 bits and 2 bits and basically used to say hey, if you know process, if you don't know discard or process and path and so on. They want to remove all the discard part and replace must discard by may discard. So the hope is there people will accept more and more hop by hop because they can simply forward it blindly, right. They don't need to understand it to forward it.
The other one, as you can guess, I don't like it. Again, a personal point of view, it's extension header limits. There is a sentence there, "A source host should not send a packet with an IPv6 header chain larger than 104 bytes."
I think this is sending a bad sign. Because it basically will end up in maybe RFP using the next RIPE 772 saying hey you only need to support 104 bytes and guess what? All the vendors, maybe including my own employer, will design hardware only doing this and no more. So, we may end up forever being limited with 104 size for all the extension header chain. And this is scary. Right. It already carries a lot of me possible honest, maybe I am paranoid.
Routing headers. There are many many things happening there. There is one called 6man sids, sends out a note fire, this draft which is would be any time soon clarifies the relationship with R v6 and sids and IPv6 addresses and a side note, they also request to the IANA a /16 prefix that could be used by any operator deploying SI v6. So make it's the filtering very ease. In the vain vein there is a very early draft, not in inter‑RIR where they want to make neither time specific for SI v6.
Not linked to SI v6 but there is in 6man something called compress how are header, called CRH, I say experimental, and I think it will go there.
Last one, high expectation and high hope, it can come, some people in the room like SI v6, other people do not like it for security reasons. But, let's fix it right, let's write a draft all together and saying exactly what are the issues, yes or no? I have personally very high expectations there. We need to do things based on fact, so let's document them.
Now, the route for 6man publication can be very bumpy. Just to give you an example. Something which is very simple. You know all of us are doing the first comment, right. For instance to discover all the nodes in one segment we type: Ping FF 02 kernel 1, and of course you need to be specific and put provider scope for the link local. So percent ETH 0. There is an RFC for this. 6874.
Now, we want to modify somehow, and now we are facing an issue because people doing it what they call the web browser community, so the people coming from W3Z, the Mozilla and the Chrome people do not like it too much because if you wore to this URL like this, for the parser it's not easy. Remember, you see some URL somewhere the Union code and the space and code t so all they tend to say hey we will try to decode percent ETA 0 as a Union code correct errand we will be failing, right.
Now we can argue it is a big rocket, it's too complex, whatever. So we are kind of stuck there, it's a very simple document but it's stuck. I mean, it's like trying, I don't know what I can do there.
Snac. It's not time to leave for lunch. But we have more and more network that want to attach to the residential wi‑fi network, think about light bulbs, think about airports. These kind of things can be using IP layer, IPv6 sometimes, and they are using for instance this, but this Mac layer is using either 64‑bit MAC address or 16‑bit MAC address. You cannot bridge those MAC addresses to a network giving 48 bits like normal wi‑fi, so you need to be routing. The speed as well is completely different. We know that v6 is pretty chatty. You don't want to send all those chat broadcasts over the wi‑fi, it's bad, but if you forward it on a low powered network you'd be killing the battery. We need to find a way.
Taking into account that we cannot request any change into the wi‑fi network, right, it must run with existing thing. We simply need to find new parameters and basically best common practice is to do it. And it must work with IPv4 dual stack and v6 only.
And talking about boiling the ocean, maybe you remember home net, Working Group IETF, they tried to be very, very flexible, addressing all the use case. It failed, because the solution was too complex, took too long and change from the CPE to everywhere. So we want to avoid this.
So, there is a snac Working Group. There is only one draft. This may be another one, and reusing existing mechanism. That's what I put it in yellow. Very important. We do not change anything there. For instance, when you think RA what they call Adjacent infrastructure link, basically to detect whether there was IPv6 on the wi‑fi network, the main network. I don't like ULA but in some cases it needs to be used, so using ULA on the attached network, for instance, and as well using ULA on the wi‑fi network if there is no IPv6 there. Reusing NAT64, making multicast DNS, no wonder if you look about the authors from the snac document and the MD NS document they are the same right, so they are using their own tools.
Last Working Group, to finish on time. DHCP. The authors of the DHCP v6 documents, RFC 8415 wants to make it Internet standards, which is the highest level, currently it's proposed standards. It doesn't make a big deal in my opinion, but they want to do it. Why not?
.
For doing this, they need to clean up the specification, and remove all the paths that are not used and not deployed. So there is one part of the TCP v6 there was never deployed to our knowledge, I am happy to be proven wrong, it is the IA_TA, where DHCP was used to assign temporary addresses, right. Like the SLAAC and the extension but done by DHCP. So we'd be removing this.
And the last one ‑‑ and you can see again the fonts and the call user, and I find it honestly very, very amusing. We all know that some operating systems do not support DHCP to get an address, right. The same people are basically requesting to use DHCP to communicate to the DHCP server which address they have selected. You should see some faces at the top.
That's the way I read it.t.
So I can read for the slides. Right. So IPv6 is not yet done. We still need to do a lot of work. So nice to see it. Operators' views are not only welcome but they are required. I know it has been a bumpy road between the operators and the IETF, very bumpy, but please come. As I said, all the presented work there is work in progress, so there is still time to change it. I am happy to be fix on the my last slide because you don't like it obviously.
JEN LINKOVA: One minute 56 questions for questions, please be quick.
AUDIENCE SPEAKER: Jan Zorz, 6connect. Thank you for this brief thing. With my RIPE 772 co‑author hat on, if you, as an Internet error director, will let that 104 thing through, then we will have to update it of course. You know, it's up to you. And the other thing is, I really like the idea of prefix delegation to every host, because if you have /64 on the host, imagine if everybody on the planet would implement this, we can get rid of IP ports, because then you can run a web server on IP and we can completely get rid of these weird ports that ‑‑ you know. How cool would that be?
ERIC VYNCKE: Very cool. I will take the questions and I will not reply.
AUDIENCE SPEAKER: There is a lot of mention of some SR v6 related drafts in there. I am surprised you didn't mention micro sids. To provide some context for the operators that are here. I am a co‑author on the interior draft trusted domain SR v6 which is seeking an either type for SR v6 optional. And also of course there is a draft by one of your colleagues at Cisco requesting a prefix from IANA.
The reason that we're doing I think, certainly in my case, the reason that we're looking at this is because the Mike sids draft requires, or sorry allows for you to forego the S R H in the packet and at that point it looks a lot like IPv6 which concerns me greatly. So, what I wanted to provide that context and I wanted to make sure that people are aware of the micro sids draft and the reason why we're looking at trying to get eather through these things and prefixes from IANA because we need to be able to differentiate these things.
ERIC VYNCKE: By the way it's not the micro sids for the SRH less. My understanding it's SRH can be suppressed from the normal al SRH as well. So it's a long tile ago. I agree with your mimic, right, don't take me wrong.
AUDIENCE SPEAKER: Jordi Palet, just to mention that I think there is one additional draft, which is important for this community, which is being updated, which is RFC 7084, the basic IPv6 IP protocols, right.
AUDIENCE SPEAKER: I would also like to mention two additional drafts, one is the one updating the DNS trans record requirements making IPv6 an equal citizen to IPv4, which I think is something long overdue. And there is also something that has gone stale in, I think, in the area which deals with IPv4 via IPv6 next hops which we do have for NLRI and BGP announcements. But it's an amazing way to get rid of your v4 in your transit linking. Everybody should check it out.
JEN LINKOVA: Okay. Thank you.
(Applause)
JORDI PALET: So, I cannot mention the customer but this is a real customer that we started deploying in June this year. If somebody wants to know offline, I can talk about that.
Just to set the stage about what I am calling mid‑size, because it depends on your perception. This is a wired broadband with about 5,000 DSL subscribers, very view GPON at the moment, growing up also business customers, etc. We are using, well they were using already before starting the IPv6 deployment, PPOE for bot repaid and boast paid customers. Many in this part of the network there is not an automatic configuration system, so everything you do or you need to do in any CPE, you need to go home by home of every subscribe, so it's quite challenging.
About the cellular part, it's a small country, it's a set of islands. The total population living there is about 730,000 subscribers, so that's the scope, the maximum of the scope of the network, of the server network. Actually, they have about 40,000 contracts and typically the concurrency is about 25,000 cellular users at the same time. From those, 80% more or less is on Android, 20% is IOS. There is also support for broadband mode items over the cellular network, volt E, another problem in this network, there is no support for over the air upgrades, so, again if you do changes in the networks like APNs or whatever, you need to go and tell every user to change the setup. So that's what happens with this kind of small ISPs.
What was the initial status of the network? They were using ‑‑ well they are still using CGN for subscribers, especially in the server network. Not so much in the broadband because they have at the moment sufficient addresses but challenging already the core was already pouring IPv6 over millions etc. Nothing special. There is a single upstream provider supporting dual stack which has also a single upstream and is not the best one. It is one of the peering providers that has problems peering with the others. Everybody knows probably who I'm talking about. They have ‑‑ the upstream provider has catches but only from Meta, I think I can say that, so for the other big content providers there are no caches at the moment and they are not at the moment IPv6 enabled. Well when we started the project.
There are a few islands outside the main one which they are connected either by some fibre linkings or by also satellite. In some cases, some of the fibre linking were broken about two years ago because a submarine explosion of a Qrator etc., so that's probably giving you some indications of which country we're talking about. So they are recovering still from that.
They already had allocated the /32 from APNIC and that's sufficient for this network. They had already an addressing plan that we needed to redesign this a little bit because they had some misunderstandings even if they got already some IPv6 training about how to probably do an addressing plan in IPv6. We decided that this customer is going to get a /48, I mean for broadband, for cellular we do /64 for each TCP context. A /64 which global Unicast addresses for the point to point linking. And then they had also some corporate customers, including government and data centres which of course they use homing, even if today the upstream provider is a single one depending on a single one but that will change in a few months. And we suggested them to change from LIR assigned space to IPv6 PI from APNIC as well. The presentation from Paolo already described this situation before.
What we do with typically all of our customers is we start with training. We actually don't support doing a customer consultancy if we don't do a training previously because we learned across the years that they have very broken misunderstandings about IPv6 and they would try to do a consultancy and don't retrain them, many things get broken or misunderstood.
So actually they attended. We do IPv6 training in different registry meetings so we did the training in the new Caledonia meeting of APNIC, and they attended that one, and then for this project, we did an on‑site training covering different departments of the customer. Also a workshop for customers and executives. The question, the key question, was why IPv6?
I always tell all the customers this: IPv6 is actually easier than IPv4, but you need to unlearn IPv4 to learn IPv6, right, that's the big problem.
We did a review of all the core distribution access equipment etc., etc. We decide what needs to be upgraded in terms of firmware or hardware. It depends also on the financial capabilities. In this case this customer got the funding from the APNIC foundation, so they had sufficient money to cover almost everything. We discovered some bugs also across the initial deployment, as usual.
When we started looking at every customer, we looked for how we do the transition in every kind of network, and in this case because the situation was the CPEs, we decided that we will take the something to deploy the ACAs together with dual stack because the current providers of the CPEs don't support yet 464XLAT but this is going to change, so even if we deploy right now just dual stack because we also deploy an ACS, we can turn on ‑‑ turn that into 464XLAT in a later point in the time.
For the server network, of course there is no wait, we go for 464XLAT.
How we do the server setup. Basically, we do always try to convince the customer to go for a single APN supporting both IPv4 only, IPv6‑only and dual stack PDP context, and this way you can progressively deploy IPv6 on different kind of user equipments, depending on your timing, depending on the features of the user equipment, etc., etc. So that's the typical way of doing this as well for us.
We need to review things like building support for the server network, also aspects covering the roaming, and there are other important IETF documents that if you get involved in any of these projects, I recommend you to take a look, especially some of them are related to the roaming itself.
Some general deployment aspects. As it happens, very often, there was no IPAM, so we needed to start an IPAM. In this case we suggest open source. The monitoring systems were already IPv6 capable, so that was not the problem. We typically do, at the start of the project, try to collect data about what are the top ten or top 20 applications in the network. So we can understand how much traffic will move from IPv4 to IPv6 when it's enabled. So this way we can measure what will be the impact of the IPv6 deployment, especially we can calculate how much bandwidth we need to be capable for the NAT64 boxes.
We added support for 6 VPE because some of the business customers require that, we deploy IPv6 for them as well. Configure it IPv6 PTRs, DNS 64, that was easy because they had already the DNS based on buying so, quite easy. And we were lucky as well because the existing CGN boxes were supporting in different interfaces, not in the same interface, but that's quite normal, running NAT64 and the performance was sufficient, so no new boxes required and we used ‑‑ we decided to use the well known prefix.
In terms of security, we started with the existing IPv4 security policies. We make sure that ICMP prefix is not filtered. We also make sure and double‑check that PMTU is not broken, updating TCP filtering, etc., RPKI, DNSSEC, again another problem, the existing CcTLD don't have DNSSEC, so the route signatures can not be used so that's a delay on that part.
As usual, the most difficult part typically the CPE, we use RFC 8585 in order to push the vendors to support this. I mention already before we didn't have provisions system or a configuration, automatic configuration system, so we need to go on site to every customer to turn IPv6 on. There was already a known bug, which is a thread in IPv4, so that's also important to resolve that situation, fortunately it has not been exploited, at least not too much that it's now to take over the customer CPE, but it's a dangerous situation that we take the opportunity to resolve as well. I think I mentioned that already before, we took the opportunity to deploy the ACs together with the deployment of dual stack at the moment only in some of the customers, not the 5,000 yet, that's more for the customer to do in the next months.
Regarding the cellular network depending on the on the android version that you have, you need to manually select the PDP type that you want. So you need to say, I want to stay with IPv4 or move to dual stack or move to IPv6‑only. So that's again something that needs to be done because there is not a way to do it automatically.
What the customer is considering because at the moment the testing that has been done in the cellular is the employees, what they are considering is a carrot, so offering free bandwidth that switch to IPv6, etc., etc., things like that.
.
Apple: It's another registry. Basically, I will say that if you need to turn IPv6 in a server network, and this is something that happened to me, in all the cellular projects that we participated, you need to do it ahead of time because it takes ages to get the Apple to react and to get it done, okay. Basically what happens is you can configure a few handsets to get IPv6‑only and CLAT for the tethering. You need to connect with USB the handsets to your computer to do that, but of course that can be done for a thousand, but you cannot do for hundreds, and when you have done the testing, you need to tell Apple to prepare a cellular profile that will come to the user's iPhone in the updates, okay. So it's tricky.
As usual, we do a lot of testing. I mentioned here, I forgot to put in the slide, it was too late yesterday night, I mentioned here that we do some testing which initially with employees basically in the network, but for the cellular network we did the same. So basically we turn on IPv6‑only in androids and some iPhones for employees, and this is the stage we are right now.
Regarding the project timing. We can say that we started working with this customer a few years ago when they attended the new Caledonia APNIC meeting, well, probably we can say that that was the start of the project. But actually, the real work was some initial work in May this year. I was there for two weeks on site in June. Then I had been working on the project about two months afterwards and we planned about six additional months for the customer to finish the complete deployment. At least in the cellular part, maybe the broadband is more difficult and will take time because 5,000 visits to households is not something that you do in just six months, even if the island is not too big. But in comparison, I can tell that I have done similar projects for customers which have about 30 million subscribers, so having an ACA, having OTA, all these kind of things change the thing quite a bit.
And finally, I documented this kind of DOH employment already in RFC 8683 which is now like five years old I think. So basically you have much more information about all this in this document.
And I think that was my last slide. Yeah. Thank you.
(Applause)
AUDIENCE SPEAKER: Michael Richardson, so I have some less large experiences with customers in dual‑stacking and IPv6, and one of the problems I discovered is that customers complain something is broken and I go look for me, and then I discover that they are an IPv4 only customer. And it really does just work on v6. And so in your previous point that you dual stack many of the employees, did you experience a problem where, in fact, you had to undual stack them at times so that they could actually find out what was really broken?
JORDI PALET: I have found a situation where, for example, some gaming companies suggested the customers to disable IPv6 and then they were believing that they are running IPv6 and it's not working, but actually it's not working because they disabled it. So, I'm not sure fits the same problem but, yeah, sometimes we need to try to reproduce the problem that the customer has, and it's not easy and then we need to tell them let's try disabling IPv4, disabling IPv6 to see the differences. I think it's case by case what are the applications that are failing, etc., etc. But in general, I don't think I have too much problems.
AUDIENCE SPEAKER: Thank you for your presentation. I see a lot of similarity about the broadband part, like finding CPE vendors that support 4646 XLAT. I also had some experience. Did you finally find a CPE vendor that did support the CLAT part of 464XLAT?
JORDI PALET: I am one the authors of RFC 8585 and the other two authors are vendors, they support it, but it's true that sometimes you need to go to the vendor and tell them, provide me something for this specific device. In some situations we used a specific, let's say, configurations for some customers, but not all the customers are happy on using open source even if the original vendor is using OpenWRT as the foundation for his. So, definitely there are not too many but depending on how big you are, you can push the vendors to provide that. Or otherwise it makes sense, when you renew the CPEs, because they need more higher bandwidth or a more modern wireless device like wi‑fi 6 or 6 E, take advantage of that and if your existing provider don't resolve the problem, look for another one.
AUDIENCE SPEAKER: So you mentioned that with APNs with Apple, if I understand, I am just asking for clarification, there is an OTA from Apple that updates them, is that correct?
JORDI PALET: No. You need to have an OTA platform on your network. The same that in the case of broadband you need to have ACS system if you want to make it easy.
AUDIENCE SPEAKER: Because I am also asking for Android because I see they are obviously the configuration is already there. Is that just in the OS when you get the phone?
JORDI PALET: In Android its much easier because if they are ‑‑ I don't remember right now, which version specifically, I can try to look for that for you. But it may depend also on the specific vendor or model. At some point in the time, if they see that they can choose just IPv6‑only, it just works and you don't need to change the PDP type manually.
AUDIENCE SPEAKER: I was just wondering because, you know, I am default asking and what are the times to transition. Okay, I think I got my answer. Thank you very much.
JORDI PALET: That you know.
JEN LINKOVA: More questions? No. Thank you Jordi.
(Applause)
And now the moment we have all been waiting for ‑‑ and it's not lunch, it's actually the result of our Chair selection.
RAYMOND JETTEN: All right. We had a selection and there was a little bug with the poll. It started a bit early or it ended too early, no matter what. We had two polls. And now we can see the results.
Da da da!
JEN LINKOVA: We can see what happened, and the result is clear though. Paolo, thank you for standing, but unfortunately not this time.
Christian could you come up to the stage, please.
Congratulations.
CHRISTIAN SEITZ: Thanks for voting for me, although only some of you might know me from the last years, and I hope I can support and engage in the IPv6 Working Group in the next three years.
JEN LINKOVA: Welcome to the team.
RAYMOND JETTEN: Then please remember to rate the talks.
JEN LINKOVA: Yes please. Rate the talks, and see you all in Krakow. And please suggest the talks, please submit your talks, if you are not happy with the agenda, it's actually your fault.
RAYMOND JETTEN: Now off to lunch.
(Lunch)
