Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

‘Videovergaderen wordt slachtoffer IPv4-tekort’

06 juli 2011 - 13:503 minuten leestijdActueelCloud & Infrastructuur
Jolein de Rooij
Jolein de Rooij

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.

Meer over

IPv4IPv6NetwerkenTelecom

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Bouw de AI-organisatie niet op los zand

    Wat is de afweging tussen zelf bouwen of het benutten van cloud?

    Computable.nl

    Slimme connectiviteit: de toekomst van bouwen

    Hoe stoom jij jouw organisatie in de bouw en installatie sector klaar voor de digitale toekomst?

    Computable.nl

    De weg van dataverzameling naar impact

    Iedere organisatie heeft data, maar niet iedereen weet hoe je het goed gebruikt. Hoe zet je waardevolle informatie om in actie?

    Meer lezen

    Computable.nl
    ActueelCloud & Infrastructuur

    ‘Handel in IPv4-adressen is goed’

    Computable.nl
    ActueelCloud & Infrastructuur

    ‘IPv4-adressen zijn niet op’

    Veiling
    ActueelCloud & Infrastructuur

    Microsoft betaalt miljoenen voor IPv4-adressen

    Computable.nl
    AchtergrondCloud & Infrastructuur

    IPv4-tekort maakt secure routing urgent

    Computable.nl
    OpinieCloud & Infrastructuur

    Wereldwijde voorraad IPv4-adressen is op

    Computable.nl
    ActueelCloud & Infrastructuur

    ‘Run op IPv4 kan internet vertragen’

    7 reacties op “‘Videovergaderen wordt slachtoffer IPv4-tekort’”

    1. Chris Buijs schreef:
      6 juli 2011 om 15:23

      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…

      Login om te reageren
    2. Sander Steffann schreef:
      6 juli 2011 om 15:42

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

      Login om te reageren
    3. SvdE schreef:
      6 juli 2011 om 17:18

      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?

      Login om te reageren
    4. db87 schreef:
      7 juli 2011 om 07:10

      Dan ben ik het eens met Sander… LOL

      Login om te reageren
    5. Gilbert Spoor schreef:
      7 juli 2011 om 08:29

      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).

      Login om te reageren
    6. Peter schreef:
      7 juli 2011 om 12:18

      @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.

      Login om te reageren
    7. Gilbert Spoor schreef:
      8 juli 2011 om 08:12

      @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.

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialInnovatie & Transformatie

    Computable Insights

    Een ai-agent die klantvragen afhandelt. Dat is een van de nieuwste troeven van softwareproducent Salesforce, dat daarmee meesurft op de...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs