RIPE 64

IPv6 Working Group Sessions I and II - RIPE 64
Scribe: Mirjam Kuehne
WG chairs: David Kessens, Shane Kerr, Marco Hogewoning

Session I

19 April 2012, 11:00 - 12:30

Administrivia
Marco Hogewoning opened the session at 11:00 local time and introduced the IPv6 co-Chairs. He informed everyone that the draft RIPE 63 IPv6 WG minutes have circulated to the list. He thanked the RIPE NCC staff for taking minutes.

Deploying IPv6 in the Swedish Public Sector - Erika Hersaeus, PTS The presentation is available at: https://ripe64.ripe.net/presentations/204-PTS_IPv6_Work_-_RIPE64_April_19th_2012_natt.pdf

Shane Kerr, ISOC, asked how the recommendations were generated and whether there was industry consultation.

Erika confirmed that the industry was consulted. PTS first produced a description because there wasn’t one. Then it was presented to the public and private sector.

Shane asked if the recommendation to deploy IPv6 no later than 2013 meant January or December 2013.

Erika confirmed that it meant December 2013.

Osama Dosary, MENOG, said that it sounded great but wondered if it was working.

Erika explained that in the coming mandate, a lot of awareness raising will have to be done. But the government has stated their political will and said that they will give PTS new government assignments. It is up to the government to define on what level this will take place. But at PTS people believe it needs to be done through information and follow-up.

Osama also wanted to know if PTS is measuring IPv6 adoption.

Erika said yes, PTS is doing that.

Osama asked if there were any indications for adoption so far.

Erika said that there is another committee following this, but that they will stop doing this. So yes, PTS will keep an eye on adoption.

Carlos Martínez-Cagnazzo, LACNIC, congratulated the Swedish government for their work and asked if the guidance document was publicly available.

Erika said it was.

Carlos asked if the document was very specific to the Swedish government or if it could be used by other organisations and governments. Erika said that the document is fairly generic and could be used by others.

Marco asked what feedback PTS received so far and whether they knew what phase people were in currently.

Erika explained that there are over 5, 000 public authorities in Sweden, so they cannot ask all of them individually. Also, they are all independent, so PTS doesn't have the mandate from the government. But it is possible to ask where they  are at the moment, if they have any deployment plans, increase awareness and find out if they need any guidance. After that, a summary report of the situation can be prepared.

Marco asked if any voluntary feedback was received.

Erika confirmed that positive feedback was received. In Sweden there was no such guidelines document available so far. So people appreciated this, both journalists and other public authorities. She said she would also be grateful if the expert in the RIPE community would also provide feedback.

Marco further asked what Erika expects will happen when IPv4 runs out and what would happen if the demand for IPv4 is bigger than the supply.

Erika responded that PTS has not yet made up their mind, but that they did various market surveys. She added that they are considering including a question in future surveys about IPv6 deployment plans.

Marco commented that they are letting the market do their job and that was a good thing.

 

Update from the RIPE NCC - Marco Hogewoning and Susannah Gray, RIPE NCC
Susannah’s presentation is available at: https://ripe64.ripe.net/presentations/192-IPv6-Update-RIPE64-1.pdf

Marco’s presentation is available at:
 https://ripe64.ripe.net/presentations/185-IPv6-Update-RIPE64-1.key

Shane Kerr, ISOC, asked how many of the IPv6 allocations were made to how many organisations because if 70-80 allocations are made per month and LIRs never come back for an additional allocations, we would be done in around 5 years.

Ingrid Wijte, RIPE NCC, answered via chat that LIRs have one IPv6 allocation. There are some cases in which an LIR ended up with two IPv6 allocations after a merger. These are very few though. There was never an additional IPv6 allocation to any LIR. A small number of LIRs came back and asked for a larger block and the original /32 was exchanged for a larger block.

 

D. IPv6 RIPEness Update - Vesna Manojlovic, RIPE NCC

Vesna’s presentation is available at:
 https://ripe64.ripe.net/presentations/190-ipv6-ripeness-ripe64.pdf

There were no questions.

Quick Status Update on Altibox IPv6 Roll Out - Ragnar Anfinsen, Altibox
The presentation is available at: https://ripe64.ripe.net/presentations/190-ipv6-ripeness-ripe64.pdf

Jan Zorz, go6, noted that Ragnar had mentioned CGNs in his presentation. He said he knows that Altibox is also thinking about A+P and 4rd and asked Ragnar to give his perspective on that.

Ragnar confirmed that he is following these developments closely. The problem is that today there is no running code. The backbone network is not IPv6 ready, so it wouldn't make sense to do that now. From a technical perspective, doing CGN in the current network is very, very easy. However, there is the complexity of losing the end-to-end communication between customers. Altibox is looking at trying to find a way to identify customers who do not actually need a public IP address and taking that away from them, CGNing them and giving the addresses to the customers who actually need them. But that is very difficult to do. Ragnar also said that some other kind of transition technology will be done in the new design. CGN will probably be done at start, but he is also looking at the work Jan and others are doing.

 

Reverse DNS Domain Names for IPv6 Address Blocks - Joseph Gersch, Secur64 SW Group
The presentation is available at: https://ripe64.ripe.net/presentations/175-CIDR_Naming_HowTo_IPv6.pdf

Ruediger Volk, Deutsche Telekom Technik, asked Joseph how it can be that if he is assuming a device has 64 addresses they actually fit into the binary tree as a contiguous fit.

Joseph clarified that he is assuming they are within the same subnet. The application has to know how it's segmenting things if there are 64 non-contiguous addresses.

AOB:

Filiz Yilmaz, on behalf of the RIPE Programme Committee, announced that Daniele Arena's term on the PC is finishing and that there are elections. The call for nominations is closed. Eight nominations have been received. A webpage with more information for each of the nominees will be published after the lunch break. Elections will take place in the Friday plenary session.

Marco thanked attendees and closed the session.

--------

IPv6 WG Session II
19 April 2012, 14:00 - 15:30


Experiences in Setting up Automatic Home Networking - Jari Arkko, Ericsson Research
The presentation is available at: https://ripe64.ripe.net/presentations/179-ripe64_homenet_exp.pdf

Benedikt Stockebrand asked if there was a specific reason why Jari used OSPF rather than RIP.

Jari responded that the thinks RIP would be more easily available and that many home routers have RIP inside. It is probably not used much, but it is there. That would be an advantage for RIP. With a link routing protocol, it's easier to build a topological map and try to understand where the address space is needed. Benedikt agreed that the advantage for RIP is that people are running it in their home networks. When they run into trouble, they have a chance to deal with it. RIP is much easier to understanding and getting along with than OSPF.

Jari jokingly suggested to do an experiment and go meet his mother, print out the packet traces, one with RIP and one with OSPF and see which she understands better.

Benedikt said he thought it was interesting but that Jari’s mother is unusual because she has a son who can deal with OSPF. For most people, RIP is easier to understand. He said that in various trainings he provided OSPF is simply way out of scope. And it is important for home networks and for small companies to have a routing protocol they can understand.

Jari responded that he won't argue too much against Benedikt's point and that he thinks the jury is still out on that.

Randy Bush, IIJ, said he thinks Jari's mother would find a TCP dump of IS-IS much easier to read.

Jari responded that the IETF WGs have been discussing multiple exits quite a bit and that he doesn't want to go into multi-homing right now.

Marco Hogewoning jokingly said that they’re so confident with our ISPs that they don't need multiple exits.

David Freedman, Claranet, said that he has been watching this new IETF WG form and and that he thinks this is very useful work. But to see that the choice between routing protocols is painful. RIP has all sorts of problems, robustness for instance. Maybe they don't need routing at all, maybe bridging is enough. A lot of work was going on behind the scenes. He was a bit surprised to hear that OSPFv3 may be more feasible than some of the other things that were considered, but certainly better than some other suggestions.

Randy clarified that he was not suggesting RIP and that he does have some sympathy for a routing protocol in this environment, but they might want to think of something more simple than OSPF.

Gerd Doering said he is quite happy to see progress on that front, but was sorry to hear that they bring themselves to the choice between RIP or OSPF. He said he was convinced that everything for a home user needs to work on auto-pilot and work automatically. Home users are not going to look at router protocols.

Jari agreed and mentioned that users indeed ignore or throw equipment away that is too complicated or doesn't work automatically.

 

Handling the Different Equipment Profiles and Standards From a Vendor Perspective - Eric van Uden, AVM
The presentation is avialable at: https://ripe64.ripe.net/presentations/94-AVM_RIPE_64_EVU_20120417.pdf

Marco Hogewoning asked if there were cases where features are taken out after they have been tested in the lab.

Eric confirmed that this happens quite frequently. He said ENUM was tested, but in the end nobody was asking for it, so it was taken out. There are other examples. Eric said it depended on feedback and on the number of downloads he sees from the customers.

IPv6 Profile Document - Tahar Schaa, German Government
The presentation is available at: https://ripe64.ripe.net/presentations/100-IPv6_R&D_project_German_public_administration_2012_TSA_brief.pdf

Jan Zorz, go6, thanked Tahar for making the work of this community useful and for doing it in a proper German organised way.

Marco asked if the document Tahar presented is available.

Tahar said he assumes that the document will be available in English in the next few months and that it will then be published. Tahar said that vendors were invited in this project and that they were happy to be involved because they often have to deal with a lack of specification in tenders.

Jan commented on another project that is working on an IPv6-related recommendation for the European Commission. It is not yet decided which template to use, but it will likely be based on the ripe-501 follow-up document.

Marco thanked Tahar for his presentation and asked him to send a pointer to the document to the IPv6-WG mailing list when it becomes available.

Replacing RIPE-501 - Jan Zorz, go6
The presentations are available at: https://ripe64.ripe.net/presentations/219-RIPE64-IPv6-steering-2.pdf
and
https://ripe64.ripe.net/presentations/169-RIPE-501_replacement_-_Update.pdf

Marco asked the audience how they should proceed with the document. After the new version of the document was sent to the mailing list after the last RIPE Meeting, some comments and suggestions were received which were incorporated in the document. The question is if the call for comments should be extended or if the document should be closed and published under a new number at this stage.

Rob Blokzijl, RIPE Chair, said that it is for the working group to judge, but that he would recommend publishing the document as soon as possible and then run the review cycle until the next RIPE Meeting.

Marco thought that if the document is updated too often and they assign a new number to it too often, people will get confused and they will lose them.

Rob agreed and said that this will probably be a living document which will be updated frequently.

Jan Zorz said that the authors strongly agreed with Rob.

David Freedman, Claranet, suggested to publish the document as soon as possible. He said he didn't think that it was useful to try to make it perfect before publishing it.

Jan thanked David for all the time he spent on the document and the help with spelling and grammar.

Another speaker from the audience agreed and said if the document is kept open and doesn't get a new number assigned, people might think that they cannot use it yet. If the document needs to be updated and they need to assign a new number to it in a year or so, that shouldn't be a problem.

Tahar also agreed and said they would like to reference the new version of the document in their project in Germany. He suggested to publish it as soon as possible.

Sander Steffann, APWG co-Chair, said that there seemed to be consensus.

Marco suggested to send the document will be send to the mailing list for one last call, maybe for five working days. After that it will be published under a new number and the old ripe-501 document will be obsolete.

Jan asked the working group attendees if they want the current authors of the document to further work on it and keep it updated or stop here.

Marco further asked if it would be an idea to set up a monitoring task force that keeps an eye on necessary changes.

Jan asked the community to be more active and help to keep the document up-to-date.

Sander said that he assumed that if people think changes are needed, they will speak up.

Marco concluded that there will be one final last call on the mailing list and that the document will then be published under a new number. He thanked the authors and everyone who contributed to this document.