Experimenting with new internet infrastructures: SCION
SIDN Labs connected to SCIONLab
Chose your color
Frequently visited
Frequently asked questions
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.
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.
To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.
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.
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.
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.
SIDN Labs connected to SCIONLab
We are experimenting with an emerging internet architecture called “SCION” to better understand its advantages and disadvantages over the current Internet and to evaluate how it performs in practice. This blog provides a brief update and looks ahead at the SCION-related work we have in the pipeline at SIDN Labs.
Some time ago, we wrote a long read about the 2STiC research programme, a vehicle for experimenting with emerging internet architectures and open programmable networks in collaboration with NLnet Labs, SURF, Delft University of Technology, the University of Amsterdam and the University of Twente. The goal of 2STiC is to develop and evaluate mechanisms for increasing the security, stability and transparency of internet communications, in particular for critical applications such as intelligent transport systems, smart homes and smart grids. Our long-term objectives are to establish a centre of expertise in the field of trusted and resilient internets, and to help put the Dutch (and European) networking communities in a leading position in the field.
One of the internet architectures we are looking into is SCION (Scalability, Control, and Isolation on Next-Generation Networks), developed by Professor Adrian Perrig's team at ETH Zurich in Switzerland. SCION is intended to deliver a more stable and secure internet by isolating trust in so-called Isolation Domains (ISDs), which are collections of autonomous systems. At the same time, SCION users will benefit from more control over and insight into the inter-domain routes their traffic takes (i.e. which autonomous systems the traffic passes through). We decided to start with SCION as it has an actively maintained software implementation we can use, an active community, and a public international testbed to connect to.
One of the first things we did was connect SIDN Labs’ network to SCIONLab, the international SCION testbed that interconnects around thirty sites. We’re running a permanent infrastructure autonomous system within the SCION network as part of the European ISD (see figure below). We are connected to multiple other autonomous systems to provide redundancy and to enable us to experiment with multi-path routing. We’re currently connecting through an IP tunnel, but we are working on a direct connection to the testbed. That means we will no longer be using the current Internet (in particular BGP and the corresponding IP routing), but instead connect to the SCION network by means of native SCION routing.
If you’re interested in the geo-locations of SCIONLab sites, check out the world map on the SCION website (which shows our node in Arnhem, see figure below).
As SCION is introducing a new protocol stack, we have developed several applications in order to familiarise ourselves with its protocols, software and infrastructure. For example, we've developed an application for easily setting up connections over SCION, similar to netcat. To gain insight into how packets travel through the SCION network, we have also developed an application that visualises the path that your packets take through a SCION-based internet, i.e. which autonomous systems they pass through (see screenshot below).
To evaluate how SCION performs in practice, we are implementing the SCION protocol in P4. P4 stands for Programming Protocol-Independent Packet Processors and is a domain-specific programming language intended specifically for parsing and processing network packets on hardware. With P4, it is possible to program custom protocols such as the SCION stack onto supported network devices, such as switches based on the Barefoot Tofino we are using at SIDN Labs (see figure below). The advantage of our hardware-based approach is that it (1) enables the actual deployment of SCION (data plane and control plane) on whitebox equipment and (2) achieves higher performance than is possible with the current software implementation of the SCION stack. We developed an initial P4 implementation of SCION; there wasn't one when we started with 2STiC, but in the meantime ETH Zurich has independently begun work on a P4 implementation, albeit for a different platform (a network card based on an FPGA). We currently have the basic SCION forwarding functions working in the open-source P4 simulator simple_switch. During the development, we came across several bugs in the open-source P4 compiler (as you would expect with cutting-edge technology) and submitted patches for them. The next big step we are working on is getting our SCION-in-P4 implementation to run on actual switches based on Barefoot’s chip.
In April we visited the SCION team in Zurich. We presented some of our early results and our SCION-related plans, while the SCION team at ETH told us about the current status of their research and their future plans. That led to fruitful discussions and plenty of ideas for collaboration, such as exchanging experience with porting the SCION protocol stack onto hardware using P4 (see above) and setting up a BGP-less connection between SIDN Labs and SCIONLab. Over the last few months, we have actively contributed to advancing the SCION architecture by providing recommendations for changes to the SCION packet headers to make it easier to process them on hardware. We also provided comments on proposals for the next version of the SCION protocol stack. We are currently discussing these changes and comments with the SCION team and they’ll likely be (partly) included in the next version of SCION. We have also contributed several patches to the core SCION software.
Our aim for the next few months is to build a more advanced demonstrator to show what properties SCION can and cannot provide compared with the current Internet. We’re also involved in setting up 2STiC’s national P4 testbed, which we’ll report on together with the other 2STiC partners in one of our future blogs. In our next blog, we'll also be sharing our experiences with other emerging internet designs, such as RINA, in connection with which we visited the research team at i2CAT in Barcelona at the beginning September.
Article by:
Share this article