Kies jouw kleur

Veel bezocht

Veelgestelde vragen

  • Ik zoek de houder van een domeinnaam. Waar vind ik die?

    Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).

    Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.

  • Ik wil mijn domeinnaam verhuizen. Hoe doe ik dat?

    Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.

  • Ik wil mijn contact/adresgegevens aanpassen bij mijn .nl-domeinnaam. Hoe doe ik dat?

    Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.

  • Waarom staat mijn domeinnaam in quarantaine?

    Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.

    Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.

  • Ik heb een klacht over mijn provider/registrar. Kan ik daarvoor bij SIDN terecht?

    Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.

  • Waaraan moet ik voldoen als registrar?

    Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.

Meer veelgestelde vragen

RFC 9313: transitiemechanismen voor IPv6-mostly-netwerken

NSA raadt alles af behalve NAT64/DNS64 en 464XLAT

De afkorting IPv6 in rood te midden van witte binaire code
  • dinsdag 4 april 2023

Waar dual-stack nog steeds de traditionele manier is om zowel IPv4 als IPv6 aan te bieden aan thuis- en netwerkgebruikers, is dat voor grote mobiele aanbieders niet te doen. Vanwege de schaarste aan IPv4-adressen bouwen zij hun accessnetwerken op IPv6-only, en zetten vervolgens een IPv4-IPv6-transitiemechanismein om hun klanten ook toegang te geven tot diensten die alleen via IPv4 bereikbaar zijn. Netwerkspecialist Ondřej Caletka spreekt in dit geval van IPv6-mostly-netwerken.

RFC 9313 noemt deze aanpak IPv4-as-a-Service (IPv4aaS) en bespreekt 5 transitiemechanismen om mobiele gebruikers van IPv4-toegang te voorzien. In het tweede deel van deze RFC bespreken de auteurs de karakteristieken van en de verschillen tussen deze mechanismen. Netwerkoperators kunnen deze overwegingen gebruiken bij hun keuze voor een specifiek transitiemechanisme voor hun infrastructuur.

5 transitiemechanismen

Dit zijn de 5 transitiemechanismen die RFC 9313 relevant acht voor de ontsluiting van IPv4-diensten voor mobiele gebruikers op IPv6-only-accessnetwerken:

De auteurs bespreken deze mechanismen in sectie 2 van de RFC. Maar voor een toegankelijker uitleg verwijzen we graag naar de betreffende items in onze IPv6 FAQ (zie daarvoor de links in het lijstje hierboven).

RFC 6180

RFC 6180 (een hele andere dan RFC 9313!) behandelt de inzet van IPv4-IPv6-transitiemechanismen in bredere (algemenere) zin. Van de 4 besproken scenario's gaat de derde (behandeld in sectie 4.3) over het beschikbaar maken van IPv4-toegang over IPv6-only netwerken. De aanbevolen techniek daar is DS-Lite.

Deze RFC is inmiddels echter meer dan 10 jaar oud, wat betekent dat modernere transitiemechanismen (vaker gebaseerd op translatie in plaats van tunneling) destijds niet beschikbaar waren. Vandaar dat we deze RFC alleen vanwege de algemene richtlijnen en principes zouden willen aanraden.

Legacy transitiemechanismen

In de FAQ’s over IPv6 bieden we een uitgebreid schematisch overzicht van alle relevante IPv4-IPv6-transitiemechanismen. Zoals je ziet hebben we alle mechanismen links (in het grijs) als legacy gekwalificeerd. Die zou je dus zeker niet meer moeten gebruiken.

(Klik op de afbeelding om deze te vergroten.)

Transitiemechanismen inclusief legacy
https://images.ctfassets.net/yj8364fopk6s/2M9cLWIjy8a9zQWWwHDXtp/97ec2304e1e495f2c46d9ea79370599e/Transitiemechanismen_inclusief_legacy.svg

Actuele transitiemechanismen

Van de actuele mechanismen rechts (in het groen) hebben we een apart overzicht gemaakt. Zoals je ziet zijn de 5 mechanismen besproken in RFC 9313 ook precies de 5 opgenomen in dit overzicht.

(Klik op de afbeelding om deze te vergroten.)

Transitiemechanismen
https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/4d90151be50e1deb022901b4f3efb833/Transitiemechanismen.svg

Alleen NAT64/DNS64 en 464XLAT?

Op basis van de 'IPv6 Security Guidance', onlangs gepubliceerd door de Amerikaanse veiligheidsdienst NSA, kunnen we deze shortlist nog verder reduceren. Deze dienst raadt om veiligheidsredenen (vooral vanwege de complexiteit en veiligheid) de toepassing van elk protocol gebaseerd op tunneling en translatie af – uitgezonderd de inzet van NAT64/DNS64 en 464XLAT in IPv6-only-netwerken (merk op dat 464XLAT voortbouwt op die andere 2 technieken). Een belangrijk bezwaar tegen tunnels is dat deze de beveiliging van de netwerkperimeter – denk aan firewalls en screeningrouters – omzeilen.

Bij dit alles waarschuwen we echter om de andere 4 mechanismen niet gelijk af te schrijven: ze ontlenen hun bestaansrecht juist aan de onderscheidende eigenschappen die ze geschikt maken voor specifieke omgevingen. Dat betekent dat je de overwegingen in RFC 9313 moet bezien met je eigen netwerkomgeving en behoeften als uitgangspunt.

Maatwerk

De eigenschappen van en onderlinge verschillen tussen de 5 transitiemechanismen worden besproken in het tweede gedeelte van RFC 9313 (sectie 3 en verder). Ondanks dat de inzet van NAT64/DNS64 en 464XLAT uitgangspunt moet zijn, raden we netwerkbeheerders en -architecten die hun IPv6-only-gebruikers van IPv4aaS moeten voorzien aan om door die secties heen te gaan om te zien of een van de andere besproken mechanismen wellicht toch beter bij hun specifieke situatie past.