Chose your color

Frequently visited

Frequently asked questions

  • I am looking for a domain name registrant. Where can I look it up?

    The Whois is an easy-to-use tool for checking the availability of a .nl domain name. If the domain name is already taken, you can see who has registered it.

    On the page looking up a domain name you will find more information about what a domain name is, how the Whois works and how the privacy of personal data is protected. Alternatively, you can go straight to look for a domain name via the Whois.

  • I would like to transfer my domain name to another registrar. What is the procedure?

    To get your domain name transferred, you need the token (unique ID number) for your domain name. Your existing registrar has the token and is obliged to give it to you within five days, if you ask for it. The procedure for changing your registrar is described on the page transferring your domain name.

  • The details registered about me/my company are incorrect or out of date. How can I get them updated?

    To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.

  • Why is my domain name in quarantine?

    When a domain name is cancelled, we aren't told the reason, so we can't tell you. You'll need to ask your registrar. The advantage of quarantine is that, if a name's cancelled by mistake, you can always get it back.

    One common reason is that the contract between you and your registrar says you've got to renew the registration every year. If you haven't set up automatic renewal and you don't renew manually, the registration will expire.

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

  • What conditions do I have to meet as a registrar?

    Would you like to be able to register domain names for customers or for your own organisation by dealing directly with SIDN? If so, you can become a .nl registrar. Read more about the conditions and how to apply for registrar status on the page becoming a registrar.

More frequently asked questions

RFC 9313: transition mechanisms for IPv6-mostly networks

NSA advises against everything except NAT64/DNS64 and 464XLAT

The abbreviation IPv6 in red amidst white binary code
  • Tuesday 4 April 2023

Although a dual-stack set-up remains the conventional way of offering both IPv4 and IPv6 connectivity to home and network users, it isn't viable for major mobile service providers. Because of the shortage of IPv4 addresses, such providers rely on IPv6-only access networks, combined with IPv4-IPv6 transition mechanisms to enable customers to access services that only support IPv4. Network specialist Ondřej Caletka calls such set-ups 'IPv6-mostly networks'.

RFC 9313 refers to the approach described above as 'IPv4-as-a-Service' (IPv4aaS), and presents 5 transition mechanisms for providing mobile users with IPv4 access. In the second part of the RFC, the authors set out the characteristics of and differences between the 5 mechanisms. Network operators may find it helpful to consult the information when considering which transition mechanism to use for their infrastructures.

5 transition mechanisms

The 5 transition mechanisms that RFC 9313 identifies as useful for making IPv4 services accessible to mobile users on IPv6-only access networks are:

The authors discuss the 5 mechanisms in section 2 of the RFC. However, for a more accessible explanation, we advise looking at the relevant items in our IPv6 FAQ utility (see the items linked in the list above).

RFC 6180

RFC 6180 (an entirely different document from RFC 9313!) covers the use of IPv4-IPv6 transition mechanisms in general. Of the 4 scenarios discussed, the third (dealt with in section 4.3) involves providing IPv4 access over IPv6-only networks. The RFC recommends using DS-Lite for that purpose.

However, RFC 6180 is now more than 10 years old, and therefore dates from a time when more modern transition mechanisms (typically based on translation, rather than tunnelling) were unavailable. We therefore advise referring to this RFC only for the general guidance and principles.

Legacy transition mechanisms

In our IPv6 FAQ utility, we provide an extensive schematic overview of all relevant IPv4-IPv6 transition mechanisms. As you'll see, we've classed all the mechanisms on the left (in grey) as legacy mechanisms. In other words, we don't advise using them any longer.

(Click image to enlarge.)

Transition mechanisms including legacy
https://images.ctfassets.net/yj8364fopk6s/2M9cLWIjy8a9zQWWwHDXtp/3b768532311efdca42b438baa5463288/Transition_mechanisms_including_legacy.svg

Contemporary transition mechanisms

We've provided a separate overview of the contemporary mechanisms listed on the right (in green). As you'll see, the 5 mechanisms considered in RFC 9313 are the same 5 included in our overview.

(Click image to enlarge.)

Transition mechanisms
https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/d89f852cd2d73fc8da7a9ba702973051/Transition_mechanisms.svg

Only NAT64/DNS64 and 464XLAT?

The IPv6 Security Guidance that was recently published by the US National Security Agency (NSA) suggests that the shortlist could be reduced still further. For security reasons, the NSA advises against using protocols that rely on tunnelling and translation, mainly because of their complexity and security. An exception is made in relation to NAT64/DNS64 and 464XLAT in IPv6-only networks (note that 464XLAT builds upon the other 2 techniques). An important objection to tunnelling is that a tunnel bypasses the security of the network perimeter – firewalls, screening routers, etc.

However, we would caution against discounting the other 4 mechanisms. They have become established because they have characteristics that make them suitable for particular types of environment. The points made in RFC 9313 should therefore be considered with your own network environment and requirements in mind.

Bespoke solutions

The characteristics of and differences between the 5 transition mechanisms are addressed in the second part of RFC 9313 (section 3 and following). Although the use of NAT64/DNS64 and 464XLAT should be assumed, we advise network operators and architects who need to provide their IPv6-only users with IPv4aaS to study those sections of the RFC, and to consider whether any of the other mechanisms covered could be more suitable in their particular circumstances.