IPv6: verschil tussen versies

Huidige versie van 19 jul 2017 om 15:22

Op dit moment ondersteunt geen enkele Nederlandse telco (en/of MVNE) IPv6. In tegenstelling tot Limesco zien Pareteum en veel andere MVNE's daar geen brood in¹, en volgens een rapport van de ACM worden MVNO's weggezet als bellers en niet als dataverbruikers². We kunnen de eerste zijn met IPv6.

In de infrastructuur is het in principe mogelijk om IPv6 aan te bieden, maar daarmee zijn we afhankelijk van bovenliggende leveranciers. Dat wordt een lange draad, en geen kansrijke zolang we relatief klein zijn. Wel kunnen we gaan werken via een tunnel.

6bed4

Een ontwikkeling van Rick (die ook lid is van Limesco) is het 6bed4 tunnel mechanisme. Dit is een tunnel die meestal peer-to-peer connectiviteit biedt, en die alleen in uitzonderlijke gevallen (namelijk bij gebruik van Symmetric NAT) terug moet vallen op een backend server. Je zou kunnen stellen dat het doet waarvan Microsoft droomde met Teredo -- maar waarvan ze inmiddels badend in het zweet zijn wakkergeschud. Daarentegen is 6bed4 stabiel.

Onder normale condities kan 6bed4 omgaan met peer-to-peer verkeer, en dat houdt in dat er niet meer latency is dan met normaal IPv4 verkeer. Bovendien schaalt dit ook naar grote aantallen gebruikers; bij afwezigheid van een tunnel service is er geen centrale node die een knelpunt kan worden.

Normaalgesproken voegt een tunnel headers toe, en worden pakketten dus langer. Dat is ook zo met 6bed4. Alleen zijn er manieren om daar wat aan te doen voor speciale applicaties. Voor ons interessant is dat de RTP-stromen van een mediaverbinding daaronder valt. Het mechanisme om dit te doen is Robust Header Compression, en daarvoor bestaat uiteraard open source code. De grap is dat de ingebouwde ondersteuning van RoHC in 6bed4 ervoor zorgt dat het minder ruimte kost om RTP over 6bed4 over IPv4 te streamen dan rechtstreeks over IPv4!

Eigen of Publieke 6bed4 Server

De normale werkwijze om een 6bed4 Server te draaien is op een netwerk met een /16 prefix. Hierop kun je namelijk een /48 IPv6 prefix voor 6bed4 construeren, en zulke prefixes worden doorgaans goed gerouteerd. In de infrastructuur is ook een mogelijkheid voor ondersteuning van de /32 prefix die alles 6bed4 omsluit, en servers die dat in BGP aanbieden zijn gehouden om het verkeer naar langere prefixes zoals /64 te forwarden.

Het is ook mogelijk om een eigen 6bed4 server op te zetten op je thuisnetwerk. Daarbij heb je een /64 prefix en dus ben je daarmee afhankelijk van een /32 forwarder, dus het is niet het ideale geval, maar nog altijd mogelijk. Je kunt natuurlijk ook gebruikmaken van een publieke 6bed4 server, die heeft dan wel een eigen /48 en routeert goed. Er is een tussenweg, waarbij je in je thuisnetwerk een router hangt die lokaal verkeer routeert naar de ingestelde publieke 6bed4 Server; die configuratie werkt perfect samen met port forwarding vanuit je router. Je kunt dan intern adressen in een /114 prefix uitgeven via DHCPv6.

Work In Progress

De nieuwste specificatie van 6bed4 verandert een aantal dingen. Die dingen moeten worden omgezet.

Daarnaast werken we aan een App die 6bed4 op je mobiel beschikbaar brengt. Dennis (een lid van Limesco) heeft aangeboden hiervoor een nette GUI te bouwen, Rick werkt aan de client zelf. Limesco heeft toegezegd dat ze 6bed4 actief wil ondersteunen als de voorlopige defaultmethode om IPv6 bij Limesco werkend te krijgen.

We zullen te zijner tijd ook een publieke 6bed4 Server aankondigen; daarvoor is inmiddels long-term support verzekerd.

Op dit moment werkt er niemand aan codecs die via RoHC worden gecomprimeerd en op 6bed4 geplaatst. Dat zou geen zinloze exercitie zijn, omdat het VoIP-verkeer voor IPv4/UDP/RTP meer ruimte neemt dat IPv4/UDP/6bed4+RoHC/IPv6/RTP. Dat is niet eens zo raar; de headers van RTP zijn langer dan die van de gecomprimeerde variant, doordat die herhaalde patronen onderdrukt.

Referenties

¹⁾ parafrase uit Xopr (overleg)'s support ticket [Limesco #1169] (mar 2015 en feb 2016)

²⁾ zie rapport via https://www.acm.nl/nl/publicaties/publicatie/15722/Telecommonitor-vierde-kwartaal-2015/ pagina 13