You're viewing an archived page. It is no longer being updated.
Date: 25 October 2017, 16:00 - 17:30
WG chairs: Jen Linkova, Benedikt Stockebrand, Raymond Jetten
Scribe: Mirjam Kühne
Status: Draft
The presentation is available at:
https://ripe75.ripe.net/archives/video/180
Jen opened the IPv6 WG session.
Benedikt Stockebrand’s term as WG chair was up. He offered to stand
again and also announced that on the mailing list. Jen asked if anyone
in the room had any objects. Nobody on the list or in the room had
objections.
The presentation is available at:
https://ripe75.ripe.net/archives/video/181
Alain Durand, ICANN, mentioned that his laptop at RIPE 75 was connected to his
VPN at home, and that he was using two browsers from two different vendors. He noticed that on one of them he can access a well-known search engine, on the other one he cannot. Only after switching off IPv6, he can do it on both browser.
Jen said it wasn't related extension headers, but it shouldn’t have happened since they made some changes in the morning of that day.
Lee Howard, Retevia, wondered if Geoff could do some scaling for different packet
sizes so he could get a better sense of the probability.
Geoff said it’s currently running by default. They are doing a bit of path MTU discovery from time to time but their work said 1350 at this point.
Lee said this could be a good topic for a BCOP document and that there is a good chance that there will be a side meeting at IETF100 to work on this.
Shane Kerr, Oracle/Dyn, said that measurements have shown that TCP is between six to ten times as expensive as UDP. However, current DNS systems have 10x their
needed capacity because they use UDP. Shane said he was less pessimistic than Geoff about TCP for DNS. He added that he was nervous that everyone seemed to think that QUIC will solve all of the problems.
Geoff urged people not to do what they did with transition mechanisms, they only need ONE mechanism.
Brian Trammell, ETH Zürich, said that when Geoff was looking at the pain, it’s all about extension headers. He suggested to take an experiment to differentiate the DNS brokenness from the extension header brokenness.
Geoff said that 38% cannot receive an answer if the IPv6 response requires extension header fragmentation.
Brian added that even strong opinions are susceptible to measurements and recommended to look into comparing DNS over TCP performance with DNS over UDP performance.
People thought this would be a good idea.
Philip Homburg, RIPE NCC, commented in the chat room that TCP (also on IPv4) only works because of MSS clamping. It's an obvious solution, implement the same for DNS, i.e. clamp the UDP buffer size, do not try to discover it. But that's more for the DNS community.
Geoff responded and said that DNSSEC needs big answers and that they need to think about IPv6 without extension headers
Jen wondered if they were having this problem because the Internet still has an MTU of 1,500.
Geoff said that this would be correct were it not for the extension header drop problem: a number of large vendors put out equipment that is sensitive to looking at what is inside the transport part of the header and insensitive to going searching down extension header chains. So even if you do your MTU right, if you put out extension headers no matter what you have got a problem and if do you a 5,000 octet, 20,000 DNSSEC with all the signatures in the world of people going mad with TXT records you are still going to have the same problem and the underlying issue is, it's just not working right.
The presentation is available at:
https://ripe75.ripe.net/archives/video/182
Jordi Palet Martinez, The IPv6 Company, recommended looking at SIIT-DC. From the perspective of the customer side it will then look like dual-stack.
Andrei reported that he looked at accessibility of certain web services on which he was deploying NAT64 and DNS64. There was a problem when sharing it with third parties, but it usually works. Andrei also said that Acme.sh works well.
The presentation is available at:
https://ripe75.ripe.net/archives/video/183
Jordi applauded the speakers for their idea and referred to an RFC that is almost done (see below).
Rob Evans, Jisc, mentioned draft-ietf-v6ops-unique-ipv6-prefix-per-host, which covers a large chunk of what they appear to be trying to do. Jordi sent the link to the draft
to the WG mailing list:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/
Christian Scheele, embeDD, said he really liked the idea. He added that he has an
older Juniper switch and would see if he could get it running on it. He asked what the speakers suggest for wireless clients.
Benedikt said there is no simple answer to this and that this can be quite difficult.
Jordi added that the document he and Rob referenced was also meant to work for wireless networks.
Lee said that as a vendor of IPv4-as-a-service he applauded this design. But he wondered if a layer-3 switch wasn’t more expensive than a layer-2 switch.
Wilhelm confirmed this, but added that on the other hand one gets many advantages when using layer-3 switches.
Lee further asked that when using VPNs inside enterprise networks, doesn’t one need a VPN concentrator.
Benedikt said that this depends on the applications on the network. For high-demand bandwidth it can indeed get expensive.
Lee asked if the speakers considered existing transition mechanisms.
Wilhelm said that they don't know how to configure this on regular Windows system, because they have not found the knob to configure it yet. They have to find something that is easy to configure.
Holger Zuleger asked via the chat room if they saw scalability issues because of the routing between each and ever host instead of L2 switching.
Benedikt said that if you have a single route to every single switch, an aggregated route for 48 ports and you connect those to your backbone, you have one route per switch, that shouldn't be much of a problem with today's hardware.
Andrei asked if the presenters considered using private or public IPv4 addressing for the machines because if they were using private addresses, he said, he doesn’t see a reason why they wouldn't use dual-stack on every single port with a small DHCP.
Benedikt said that dual-stack hurts.
Andrei wondered if VPNs weren’t the bigger problem.
Benedikt responded that dual-stack makes trouble-shooting much harder.
Wilhelm said that there was another reason for not doing this. In IPv6, they have neighbour discovery, which means the router announces itself by router advertisement and the client is able to generate an address. This is not possible in IPv4. If you have 10,000 office networks you don't want to have 10,000 DHCP pools with one address in it.
Alain Durand said he is happy to see what the presenters were doing. He also referred to RFC 6353 (DS-Lite).
Jan announced the publication of ripe-690 and suggested working on
a new BCOP document that describes solutions and best current practice
for IPv6 for mail servers.
Jordi, Aaron Hughes and others volunteered.
Most people in the room think this would be a useful document to have.
One person said it’s too early, because the technology isn’t ready yet.
The presentation is available at:
https://ripe75.ripe.net/archives/video/185
There were no questions.