You're viewing an archived page. It is no longer being updated.
Date: 17 May 2018, 14:00 - 15:30
WG Co-Chairs: Jen Linkova, Benedikt Stockebrand, Raymond Jetten
Scribe: Massimiliano Stucchi
Status: Final
The WG Co-Chairs welcomed everyone to the session and asked for comments on the RIPE 75 minutes. There were none, the minutes were approved.
The presentation is available at:
https://ripe76.ripe.net/archives/video/126/
Wilhelm Boeddinghaus, iubari GmbH, mentioned that he read in the news that China planned to move 500 million end users to IPv6 in the near future. He also mentioned that segment routing could be a good feature to convince operators to move to IPv6.
Geoff Huston replied that he thinks it will be the mobile segment leading the move in China, since it's easier than for the broadband market.
Andreas Polyrakis, GRNET, said that what was discussed in the talk was good, but it's because of the people motivated to do something in their ISP and introduce IPv6. It might be because of other factors, such as IPv4 runout, but it mostly comes down to the people. He's also proud about Greece to be on the top five list.
Geoff Huston replied that small and medium companies can run the risk, but bigger telecom companies often have issues because they are too big.
Alain Durand, ICANN, commented that having CGN can be expensive. He then asked if the adoption line was plotted, could they look at the moment when 80-90% of users will be on IPv6. He also asked if they would still be pushing for IPv6 in the
next 10-15 years.
Geoff replied that networks were moving to be mostly mobile, so 464XLAT would be the best choice. It makes IPv6 work from the very first moment, still keeping IPv4.
Radu-Adrian Feurdan, Coriolis Telecom, commented that another incentive for moving to IPv6 could be legal pressure and obligation, combined with CGN. Operators could move because of customer identification, and don't want to use CGN for legal obligations.
Geoff replied that it was a data-driven presentation, but he had no data to comment.
There were no more questions nor comments.
The presentation is available at:
https://ripe76.ripe.net/archives/video/129
Ondřej Caletka, CESNET, asked about plans to make the tool open source.
Helge replied that he would email a colleague to ask.
Ondřej also asked about a github repository.
Ondřej said it didn’t exist yet.
Benedikt Stockebrand said he liked the concept from the start. He added that there was trouble for non-technical people to explain some concepts, and this tool could be helpful.
There were no more questions nor comments.
The presentation is available at:
https://ripe76.ripe.net/archives/video/131
Kostas Zorbadelos, GRNOG, asked about how the networks were provisioned in
the suggested draft.
Jordi answered that it was SLAAC without DHCPv6. This was meant to be simple and supported by every OS.
Ondřej asked about the advantage of host isolation, and suggested that the "L"
flag in SLAAC was supposed to work exactly the same way.
Benedikt suggested to look for previous work by him and Wilhelm Boeddinghaus on the same topic, which is available by searching on the IPv6 WG mailing list.
David Farmer, University of Minnesota, asked for clarification about the system being configured on the router, as this work does not affect clients.
Jordi confirmed it was all done on the routers.
There were no more questions nor comments.
The presentation is available at:
https://ripe76.ripe.net/archives/video/133
David Farmer, University of Minnesota, suggested adding text to the draft about a de-bounce to avoid starting to use a link as soon as it comes back up, but make sure the link was properly working before using it again.
Jen replied that the draft discusses it, and that you should have some link dampen/event policy to treat this case.
Baptiste Jonglez, University of Grenoble, asked about what to do if you can't use a ping to measure if the connectivity
is down.
Jen replied that the slides don't mention all the use cases, but the draft addresses different ways to understand if a link is up or down.
Ilijtsch van Beijnum, Logius, mentioned the IETF working group called "Multihoming in IPv6" and what was proposed there was complementary to the work. The working group is now called SHIM6. He also added that SHIM6 should be added, as it's complimentary to this draft.
Jen replied that SHIM6 couldn’t be deployed right now in that environment. In this case, multipath transport would be better, but it's not the scope of the work presented, which aims to be as simple as possible.
Ilijtsch suggested looking at all the work that was previously done and maybe refer to it.
Jen mentioned the use of MP-TCP as an example, as there was work in progress to enable hosts to make educated decisions about the network. In any case, multipath transport would help, but it was something to be considered for the future. At the moment, there were no clients supporting any form of multipath, while the goal of the draft is to have something useable
right now.
There was a question from Tim Bray, ProVu Communications, via chat. He reported that he tried this solution in his network and faced issues with the clients not coping with the change of addresses, especially with the PIO lifetime being set to zero.
Jen replied that it could be because of some conditions in the user's network, adding that she would get in touch with Tim to investigate the issue.
Bjørn Bürger, Pengutronix, reported that it did not work in his network. There were issues when the addresses change and all the configurations (prefix lists, access lists, other security measures) that needed to be tracked wasn’t easy. Even in small environments, this could be an issue. He also indicated that using PI in his case "just works" and it was apparently much easier.
Jen answered that the use case might be a bit different from the environment reported by Bjørn Bürger. The cases in the draft are meant to be for enterprises not wanting to run BGP.
Tim Bray, via chat, commented that mainly Linux desktops broke. He added that PI space was much better for medium-sized companies as well.
Jen replied that PI is still better, and it's known. This draft tried to solve different issues for a different set of organisations.
Nick Hilliard, INEX commented that this was an issue where renumbering IPv6 seemed to be easy, but it was not.
There were no more questions nor comments.
Session II
Date: 17 May 2018, 16:00 - 17:30
WG Co-Chairs: Jen Linkova, Benedikt Stockebrand, Raymond Jetten
Scribe: Nathalie Trenaman
Status: Draft
The presentation is available at:
https://ripe76.ripe.net/archives/video/136/
Raymond opened the IPv6 WG session.
Jen Linkova’s term as WG chair was up. She offered to stand
again and also announced that on the mailing list. Raymond asked if anyone
in the room had any objections. Nobody on the list or in the room had
objections. Jen was re-elected.
The presentation is available at:
https://ripe76.ripe.net/archives/video/139/
Jordi Palet asked if the feedback request was just for the RIPE NCC or also for the community.
Sébastien commented that the feedback request was meant for the RIPE community.
Jordi also asked if Sébastien saw the discussion and comments on the mailing list.
Sébastien explained he did not see any emails and found out there was something wrong with his subscription.
Tahar Schaa understood ITU papers that are a recommendation, is a declaration for a document to potentially become local legislation. And asked if his interpretation is correct.
Sébastien said that in some cases this could be and it us up to the country to decide.
Tahar said that the German government is enrolling in the public administration IPv6 already, with success. The schemas that they have used have nothing to do with what Sébastien presented. So if this recommendation becomes local legislation, this will stop Germany from enrolling IPv6 in the public administration.
Sébastien mentioned that the wording of the recommendation was very careful not to force anyone to adopt the proposed model. It was worded that is can be used as a reference and expected to be fully customised. It is only a starting point for those who want some guidance.
Tahar read the document and did not see an argument on why this document was needed and he asked Sébastien who paid him for this work.
Sébastien replied that he is payed by Mandat International an independent foundation. The revenue comes from research projects and he made clear that this project was not funded by any government or company. They have been working on IPv6 for a long time and saw how managed security was different in IPv4 and IPv6. This model saves time, money and energy to this who want to adopt.
Jordi commented that he tried to understand the document, and while he has many years of experience Jordi thinks it doesn’t make any sense what Sébastien proposes. Jordi suggests that Sébastien should participate in Registry meetings because some of the suggestions are against current policies and even the terminology is broken.
Benedikt Stockebrand said that he sent a longer comment to the mailing list and suggested that Sébastien reads the archive. Also, that there is an arbitrary categorisation of networks and there are some fundamental things missing. IoT is in there for example, but VoIP is missing. It also doesn’t allow for any options for future development, so the document is outdated when it gets published. There are missing security considerations and the biggest mistake in there, if you are repurposing bits of the address fields of the headers for things other than what addresses are meant for, which means routing information, what you do is you artificially shorten the addresses and with an internet growing at about 30% a year, that basically means you will shorten the lifetime of IPv6 by at least 20 years.
Sébastien would like to see the rationale behind this affirmation.
Jan Žorž read out the mail he sent to the IPv6 Working Group mailing list and asks what the problem is Sébastien is trying to solve? What is the scope of this document? Is there a BCOP?
Sander Steffann stated that there was a lot in this document that goes against policies and Best Current Operational Practices. In the current state, this document was not usable.
Marco Hogewoning commented that the RIPE NCC is an ITU-T Sector member and there is an ongoing exchange of liaison RIPE NCC and ITU-T study group 20 on this particular topic. RIPE NCC already committed to the study group by liaison that Marco will be collecting all the comments on the mailing list next week, look at the transcripts and minutes of this session and package them as a whole and provide them to study group 20 for their consideration. There is a deadline for the 1st of June to provide input, so please provide input to the mailing list before the 24th of May so Marco has time to include these comments. In future meetings we of course will report back on the progress of this work item.
The presentation is available at:
https://ripe76.ripe.net/archives/video/142/
Jordi commented that he was glad to see NAT64 was so popular, but it would have been better if there was a distinction between NAT64 and 464XLAT. It would have been nice to see the evolution over time.
Massimiliano explained that this was brought up by Jordi after the survey started and it was to late to change this.
Bjørn Bürger commented that it would be nice if the next survey worked on an IPv6 enabled webserver.
Massimiliano said he would look into that.
Jen mentioned it looked very positive, because we see the same arguments. However, what we can change is education. Jen asked Massimiliano what we can improve in the area of training, because it is still in the top three reasons.
Massimiliano explained that participants of the survey could provide multiple answers to the questions. Almost every week, the RIPE NCC delivers training courses and the most requested are still the Basic and Advanced IPv6. He added that they also do Train the Trainer programmes, yet they still see people who have little knowledge about IPv6. This is still very much the case and he doesn’t know the reasons behind that.
Kostas Zorbadelos asked what size of ISPs did Massimiliano examine and what the threshold of users was.
Massimiliano said he examined the ISPs with more than 100,000 users, eliminating the smaller ones.
Kostas Zorbadelos asked if Greece was in that data.
Massimiliano confirmed Greece was there.
The presentation is available at:
https://ripe76.ripe.net/archives/video/145/|
Jen Linkova commented that out of 1,000 queries, 750 were not working. That matches the adoption statistics. She added that they could start making bets on when they can start to forget about IPv4. She has seen presentations recently that still claim that IPv6 is a special feature. She asked Jens what he thinks about this time line, 10 years or 20 years.
Jens said that they should make a betting pool.
Peter Stryzweski asked if Jens tried IPv6 on the plane.
Jens commented that he only investigated airports.
Massimiliano Stucchi said that if you go to Schiphol, IPv6 works, both in the public Wi-Fi and in the lounge.
The presentation is available at:
https://ripe76.ripe.net/archives/video/146/
Iljitsch van Beijnum said that he is impressed with the work Diego has done but on the other hand it is sad that Diego spent so much time to keep IPv4 working.
Diego said that ISPs will still need IPv4 for their customers and that CGN is really expensive. This solution was open source.
Blake Willis requested that Diego in his slides on CGN uses a ratio of 8 to 1 or 16 to 1, instead of 1000s to 1, as per recommendation from Europol.
Diego will add it to the slides.
Kostas Zorbadelos replied to Iljitsch that he could always hire Diego to do something more interesting and he thanked Diego for his good work.
Benedikt Stockebrand largely agreed with Iljitsch about wasting time on transition technologies, but considering the problems people have with DS-Lite, this might help, especially because Lightweight 4-over-6 is open source.
Jan Žorž said that Diego mentioned MAP and Lightweight 4-over-6 and that he sensed an increased interest from operators to do something similar. He asked if Diego could elaborate in which cases you should use MAP and when Lightweight 4over6.
Diego said that at the moment, it was good to try different transitioning mechanisms.
Jan asked if Diego planned to do dynamic allocation of ports, because this was specified in A+P and asked him to stop saying that Lightweight 4over6 is stateless, because it is stateful.
Diego said that for him, Carrier Grade NAT was stateful because once you establish the binding table, all the connections are in the same NAT because all of the AFTRs share the same table. Diego will explore the dynamic allocation of ports. So far, they have managed to compile up to 40 million software binding tables.
Kostas Zorbadelos commented that in Lightweight 4-over-6, the binding table was fixed and the idea was to have different binding tables and offerings so you can switch the user from 1024 ports to something larger. This is also what Kostas was considering for his deployment.
Diego commented that the binding table can be abated, it’s not fixed. You can interact with it through Netconf and add and remove software.
Jordi said that there is not much difference between MAP-E, MAP-T and lightweight4-over-6, it depends on what the equipment is supporting. Jordi did a comparison between all the transitioning mechanisms and will share the link to the latest slides on the list.