Managed hosting door True

'Videovergaderen wordt slachtoffer IPv4-tekort'

 

Videoconferencing zal één van de eerste applicaties zijn die concreet hinder gaat ondervinden van het IPv4-tekort. Dat voorspelt ip-onderzoeker Iljitsch van Beijnum. 'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio en videogesprekken niet tot stand kunnen komen.'

'Stel dat een ISP geen IPv4-adressen heeft, maar wel nieuwe klanten krijgt', legt Van Beijnum uit, 'dan gaat hij die klanten via NAT444 samen achter één IPv4-adres plaatsen.' Hoe intensiever providers gebruik zullen maken van NAT, hoe trager p2p-applicaties zullen worden, voorspelt Van Beijnum.

Videoconferencing-applicaties zullen daar het eerst hinder van ondervinden, aldus de onderzoeker: 'Bij p2p-applicaties die relatief weinig dataverkeer gebruiken, zoals bijvoorbeeld instant messaging en VoIP, is het mogelijk het verkeer via een server te laten lopen, maar vanwege de grotere bandbreedte van video is dat in dit geval een minder bruikbare oplossing.'

P2p-applicaties krijgen het zwaar

'NAT in het algemeen dwingt internetverkeer af dat verloopt volgens een client-serverarchitectuur', zegt Van Beijnum. En die architectuur vloekt met programma's die ip-pakketten versturen via een peer-to-peer (p2p)-netwerk. Zo'n p2p-netwerk is gedecentraliseerd: het kent geen vaste werkstations en servers zoals in het client-servermodel, maar enkel gelijkwaardige aansluitingen ('peers' ). Ze functioneren allemaal zowel als client en als server voor de andere aansluitingen in het netwerk.

'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio- en videogesprekken niet tot stand kunnen komen', legt Van Beijnum uit. De internetonderzoeker weet dit ook uit eigen ervaring: 'Thuis heb ik twee BitTorrent-machines staan. De één staat achter een NAT-box, de ander niet. Met die laatste laptop, die een eigen ip-adres heeft, kan ik vier tot tien keer sneller bestanden downloaden.'

Iljitsch van Beijnum

Iljitsch van Beijnum is onderzoeker aan de Madrileense UC3M-universiteit en het overheidsonderzoeksinstituut IMDEA Networks. Hij ontwikkelt daar onder meer nieuwe ip-technologie, voor het gefragmenteerd en daardoor efficiënter versturen van ip-pakketten over verschillende paden tegelijk. In zijn huidige functie droeg hij bij aan de ontwikkeling van NAT64. Dat is een mechanisme om IPv6-clients te laten verbinden met IPv4-servers. Hij schrijft met regelmaat artikelen over netwerkarchitectuur en internettechnologie op online medium Ars Technica. Hij is lid van de Nederlandse TaskForce IPv6.

Van Beijnum publiceerde in 2005 een handboek over het gebruik van IPv6: 'Running IPv6'. In 2002 schreef hij een BGP-handleiding: 'Building Reliable Networks With the Border Gateway Protocol'. In 2005 rondde hij een informatica-opleiding af aan de Haagse Hoogeschool. Van Beijnum was stagiair bij XS4All in 1995, werkte bij bART van 1995 tot 1997 en begon in 1997 met vier anderen voor zichzelf als Pine Internet, tegenwoordig Pine Digital Security. Tussen 2000 en 2007 was hij zelfstandig consultant.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4027162). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

CGN/LSN zijn niet de oplossing... Is alleen maar lucht creëren voor om niet te investeren in IPv6 en/of beperkingen te verdoezelen... De foute beslissingen genomen afgelopen jaren is het echte probleem...

@Iljitsch en @Chris: ik ben het met jullie beiden helemaal eens!

Als de routers op de traditionele manier blijven werken, dan wordt het IPv6 verkeer op de 'buitenkant' door een firewall tegengehouden. Wat is dan het verschil met het huidige RFC1918 (bijvoorbeeld 192.168.x.x) achter een NAT?

Dan ben ik het eens met Sander... LOL

Deze informatie is naar mijn idee wat achterhaald. Er bestaan al jaren oplossingen voor het h323 en sip probleem dat normaliter niet achter nat bereikbaar is.
Er zijn bijvoorbeeld session border controllers (lees: een device dat de media relayed op het internet) die elke zichzelf respecterende videoconferencing apparatuur bouwer in zijn portfolio heeft. Hiermee kan van achter NAT zonder problemen videoconferencing naar andere achter NAT geplaatste video systemen gedaan worden. Tevens wordt gesuggereerd dat datavolumes en gebrek aan ip adressen aan elkaar gerelateerd zijn en dat is niet het geval. NAT performance is meer afhankelijk van de gebruikte hardware en NAT techniek. Al met al een slecht artikel geschreven door iemand met weinig kennis van zaken(wat videoconferencing betreft).

@Gilbert: Dat werkt alleen als je als gebruiker van die videoconferencing zelf ook de NAT-doos beheert. Als providers meerdere klanten achter NAT zetten, is dat niet meer mogelijk. Ja, misschien kun je bij de provider een videoconferencing abonnement afnemen waarbij je achter een, door de provider beheerde session border controller zit, maar dat werkt niet voor veel particulieren (en MKB) die af en toe een videoconferentie op willen zetten. De grote bedrijven, die al veel aan videoconferencing doen, hebben voldoende IP-adressen.

En @SvdE: Als je zelf de firewall of NAT beheert, kun je selectief poorten open zetten of forwarden. Daar hoef je dan niet bij je provider voor aan te kloppen.

@peter: Dat is niet helemaal waar.
Je kan vanaf achter een one to many NAT vertaling waarbij enkel verkeer van binnen naar buiten open staat registeren op een border controller op het publieke internet, daarvoor hoef ik geen NAT aan te passen. het binnenkomende verkeer gaat over de return pakketten terug naar het videosysteem aan de "binnenkant" van het netwerk.

Het is niet nodig een statische translatie te doen om dit te laten werken, en het syusteem heeft ook geen publiek ip adres nodig.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×