Large UDP packets in IPv6 [pdf] | Hacker News Reader

Large UDP packets in IPv6 [pdf]

ripe72.ripe.net

74 pointsliotier12 comments

This talk from Geoff Huston seems great (as usual) but it has not been presented yet at the conference. You can connect to the live streaming [0] around 14pm CET on Wed 25th, or watch it later from the presentation archives [1]. I suggest you also check out the other two talks he's giving at the conf.

[0] https://ripe72.ripe.net/live/main

[1] https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/

While waiting I can recommend this Packet Pushers podcast episode where Geoff Huston takes on IPv6 and the future of the networking:

http://packetpushers.net/podcast/podcasts/show-275-future-of...

I second this. I like when he points out that available entropy in CGNAT (ipv4+proto+port) is larger than what available in IPv6.

The talk will be in the side room from 14:00-15:30 CEST (~45 mins from posting this)

https://ripe72.ripe.net/live/side/

Meeting agenda:

https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/#weds

As someone who works in the application layer, the recommendation to have a fast failover to tcp from udp seems silly. Shouldn't the recommendation be to keep packet sizes below 1280?

Well there are often times where you may need to send more data than fits in a 1280 packet, so what do you do then? Ans: cut over to TCP.

Send more than one packet?

But then you need to design a system to make sure all the packets arrive, including sending missing packets, and that they're processed in the correct order. Or you could use a time-tested off the shelf system to handle this complication: TCP.

> the recommendation to have a fast failover to tcp from udp seems silly

it does, in some ways. I imagine if you're using UDP you have a specific application in mind that may not be performant over TCP... otherwise why not just use TCP by default?

Oh, whatever happened to SCTP?

The reality that to much stuff in networks (mostly firewalls, NAT and other middleboxes like that) only understands the basics (TCP, UDP, random bits of ICMP) and drops SCTP. You can do SCTP over UDP, or use it in networks you can control and fix, but not reliably as-is over random internet connections. So we now have HTTP2 and other protocols now reinvent parallel streams instead of swapping to SCTP, but that's how it is.

SCTP is alive and vell in very niche applications. SIGTRAN [1] for example is an adaptation of middle layers of SS7 network stack that runs on top of SCTP/IP.

[1] https://en.wikipedia.org/wiki/SIGTRAN

Reply on news.ycombinator.com