1. Introduction

The purpose of this document is to describe the role, responsibility and expectations associated with RIPE Working Group (WG) Chairs.

The document is divided into the following sections:

• WG chairs and co-chairs

• Creating WG charters

• Updating WG charters

• Policy Development Process (PDP) responsibilities

• RIPE Meeting responsibilities

2. Working Group Chairs and Co-Chairs

WG chairs and co-chairs should always make it clear whether they speak on behalf of themselves, the organisations they work for or the WG for which they are chair or co-chair.

RIPE WGs have two different ways of dividing up the responsibilities of the WG chair(s): WG Chair Model and Equal Co-Chair Model. The model that is used depends upon the specific needs, history and set-up of a particular WG.

i) WG Chair Model

In this model, a WG chair has overall responsibility for the WG and can be supported by co-chairs. These co-chairs can assist with general WG support and can deputise for the WG chair if he/she is not able to attend a RIPE Meeting.

ii) Equal Co-Chair Model

In this model, the co-chairs share the responsibility for RIPE Policy Development Process (PDP) and RIPE Meeting activities. The co-chairs act together to make any formal statements (for example on policy development) that are relevant to their WG. For each RIPE Meeting, one of the co-chairs serves as the primary contact for the WG and for session organisational matters.

The number of chairs and co-chairs of each WG should not exceed three (3).

3. Creating Working Group Charters

i) Working Group created from a Task Force

A WG usually emerges from a Task Force. In this case, the procedure for creating the WG Charter is as follows:

The head of the Task Force creates the charter for the new WG in consultation with other members of the Task Force. Once this has been agreed, and approved by the RIPE Chair, the charter for the new WG is officially recognised.

ii) New Working Group Emerging from an Existing WG

If a new WG emerges from an existing WG, then the chairs and co-chairs of both the new and existing WG should draw up the charter for the new WG. Once this has been agreed, and approved by the RIPE Chair, the charter for the new WG is officially recognised.

4. Updating Working Group Charters

If a WG Chair needs to update the WG charter, he/she needs to have the text approved by the WG co-chairs before presenting the revised charter to the WG for their approval via the WG mailing list and/or at a RIPE Meeting.

5. Policy Development Process (PDP) Responsibilities

WG Chairs are expected to:

• Stay up-to-date with all phases of a policy proposal relevant to their WG

• Follow discussions on the relevant WG mailing list(s)

• Guide mailing list discussions as appropriate

• Take charge of PDP milestone decisions relevant to their WG

• Ensure PDP milestone decisions keep to the timeframe as described in the document “Policy Development Process in RIPE” (ripe-500)

• Make a collective, final decision supported by a reasonable level of awareness as to whether a particular policy proposal has received consensus

• Inform the RIPE NCC when a policy proposal has received consensus and should become a RIPE Document

Note – In a WG with an equal co-chair model [see 2(i)], these responsibilities are shared between the co-chairs.

6. RIPE Meetings Responsibilities

i) General/Plenary

WG Chairs are expected to:

• Attend RIPE Meetings or ensure that a co-chair attends the meeting

• Lead a Plenary session as agreed in advance of the meeting and pass on any action points that are decided in this Plenary session to the relevant WG

Note – In a WG with an equal co-chair model [see 2(i)], these responsibilities are shared between the co-chairs.

ii) Working Group Specific

WG chairs are expected to:

• Solicit relevant presentations for the WG session

• Post a draft agenda for their WG session (at least 2-3 weeks before a RIPE Meeting where possible)

• Lead the WG session and encourage active participation

• Review and approve the minutes from their WG session (4-6 weeks)

• Attend WG chair lunches during RIPE Meetings

• Attend WG chair meetings between RIPE Meetings

• Update the action list of their WG after the RIPE Meeting

• Approach the RIPE Chair and the EOF Coordinator with any requests to fund a speaker’s attendance at a RIPE Meeting. If the request for funding is deemed appropriate by the RIPE Chair and the EOF Coordinator, the RIPE Chair will request funding from the RIPE NCC Managing Director. The RIPE NCC Managing Director may or may not approve such a request at his own discretion.

Note – In a WG with an equal co-chair model [see 2(i)], one co-chair takes overall responsibility for these activities at a particular RIPE Meeting.

1. Introduction

2. Background

3. Recommendation

4. Discussion

Introduction

Recent discussion has shown there is a limited requirement to be able to advertise more specific prefixes from an IPv6 Provider Aggregatable (PA) allocation where a Local Internet Registry (LIR) contains several networks which are not interconnected, or for traffic engineering purposes. This document recommends such advertisements are limited in both length and scope. It is intended to supplement the working group's Recommendations on Route Aggregation [RIPE-399].

Background

The IPv6 address allocation and assignment policy for the RIPE NCC Service Region [V6-ALLOC] only allows LIRs to obtain more than the minimum PA allocation if they can demonstrate address utilisation that requires it. This fits with the address space management principle of conservation. However, as understood in the RIPE Routing Working Group's Recommendations on Route Aggregation [RIPE-399], there are occasionally requirements for the advertisement of more specific routes from within an allocation. With a few ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause significant difficulties for some networks wishing to deploy IPv6.

Some reasons for wanting to advertise multiple prefixes from a PA allocation could be:

• The LIR has several networks that are not interconnected.

• Traffic engineering: A single prefix that covers an LIR's entire customer base may attract too much traffic over a single peering link.

This document is only concerned with IPv6 Provider Aggregatable (PA) allocations, and does not discuss Provider Independent (PI) prefixes which are unlikely to be divisible beyond the default assignment of /48.

Recommendation

It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. The operator community will ultimately decide what degree of subdivision is supportable, but the majority of ISPs accept prefixes up to a length of /48 within PA space.

Advertisement of more specific prefixes should not be used unless absolutely necessary and, where sensible, a covering aggregate should also be advertised. Further, LIRs should use BGP methods such as NO_EXPORT [RFC-1997] and NOPEER [RFC-3765] or provider-specific communities, as described in RIPE-399 to limit the propagation of more specific prefixes in the routing table.

Operators should register appropriate "route6" objects in their preferred routing registry, or ROAs in the RPKI, to reflect any more specific advertisements.

Discussion

There is a valid need for some LIRs to advertise more than one IPv6 PA prefix. As either obtaining more address space and advertising more /32 prefixes, or advertising more specific prefixes within an already allocated /32 have the same impact on the routing table, it is suggested that the latter approach is taken to prevent address space wastage.

It is understood that this may not cover all possibilities. There may be circumstances where sites will have to consider the suitability of Provider Independent addresses, or LIRs may have to consider mechanisms of obtaining more than a /32 of Provider Aggregatable space.

The RIPE Programme Committee (PC) is responsible for

• ensuring that the RIPE Meeting programme consists of interesting, relevant and inspiring content

• planning and all content at RIPE Meetings other than RIPE Working Groups

• the timely publication of the RIPE Meeting agenda

The Programme Committee works by consensus.

Composition and Roles

The PC will consist of up to eight appointed individuals:

1. Four community representatives selected by participants at-large at RIPE Meetings;

2. One appointed by the RIPE WG Chairs;

3. One appointed by the MENOG Programme Committee;

4. One appointed by the ENOG Programme Committee;

5. One appointed by the local host, where appropriate.
   
   The member appointed by the RIPE WG Chairs act as the liaison between the RIPE WG Chairs, the RIPE PC and the RIPE Chairman.
   
   Those members appointed by the Network Operations Groups (NOGs) act as liaisons between their own Programme Committees and the RIPE PC, and also represent their region generally.
   
   A local host representative may be co-opted by the PC in consultation with the organisation hosting a RIPE Meeting. They should be well known to the local community and provide a liaison between them and the PC.
   
   In addition to the appointed members, the PC has the discretion to co-opt individuals whenever expert or local knowledge would help to plan the agenda for a RIPE Meeting. Such individuals co-opted on to the PC serve only until the meeting that required their co-option takes place.
   
   The PC members select a Chair who oversees the work of the PC: scheduling its meetings, issuing calls for papers, co-opting members, etc.
   
   The RIPE NCC appoints a permanent, non-voting observer to the PC to provide any co-ordination functions which may be required.
   
   Appointment of and Terms of Service for Programme Committee Members
   
   Four members of the PC selected by participants at-large at RIPE Meetings (a above) serve a term of four consecutive RIPE Meetings. Each such member is elected for a four meeting term at each RIPE Meeting, through a deliberate process by attendees of the RIPE Meeting.
   
   Community-appointed members of the PC (a above) serve a maximum three consecutive terms. For these members appointed by the NOGs and WG Chairs (b-d above), each group will decide how it selects its PC appointee.

Responsibilities and Expectations for Programme Committee Members

PC members are expected:

• To stay aware of the topics that address the needs and interests of the RIPE community.  This usually assumes regular attendance of RIPE Meetings and tracking issues discussed by the global technical community.

• To actively seek content that is relevant and interesting to the RIPE community. This includes reaching out to presenters of interesting talks, people involved in projects, research or other activities that may be of interest to the community.

• To actively participate in forming the plenary programme of the RIPE Meeting. This implies active participation in the PC activities (teleconferences, on-site meetings, reviews, etc.) and working towards reaching consensus on decision points.

The RIPE Programme Committee can be contacted at: pc [at] ripe [dot] net.

This document describes the RIPE Registry and its history.

Purpose of the RIPE Registry

The RIPE NCC keeps a comprehensive record of all Internet number resources registered within the RIPE NCC service region to ensure that each Resource Holder holds unique and legitimate Internet Protocol (IP) address space and Autonomous System Numbers (ASNs). The collective of this data is generally referred to as the "RIPE Registry".

Historical Background

Throughout the history of the Internet, the Internet Assigned Numbers Authority (IANA) has been the primary authority to allocate and assign numeric identifiers required for operation of the Internet. In 1990, the term "Internet Registry (IR)" was defined by the Internet Engineering Task Force (IETF) in [RFC 1174] as "the organisation which has the responsibility for gathering and registering information about networks to which identifiers (network numbers, autonomous system numbers) have been assigned by the IR".

At the time [RFC 1174] was written, SRI International served as the sole IR for the IANA.

It was recommended in [RFC 1174] that:

Under this proposal, the IR would be charged with the registration and administration of the Internet number space but not with the enforcement of policy. The IR should collect enough information to permit network administrators to make intelligent decisions as to the acceptability of traffic destined to or from each and every legitimate Internet number [...] At a later step, we anticipate that it will be desirable to distribute the IR function among multiple centres on different continents.

Shortly after the IETF identified the need to distribute the IR function, the RIPE community published [ripe-19] (16 September 1990), a document that proposed that a network coordination centre be formally established to, among other things, take on the role as Regional Internet Registry (RIR) in Europe. The RIPE Network Coordination Centre's (NCC) first activity plan was published the following year on 5 May 1991 [ripe-35].

The following year, the IETF published [RFC 1366], dated October 1992, proposing a plan for a systematic approach to allocate Internet number resources globally. It was in this document that the criteria for a regional registry were established:

a) Networking authorities within the geographic area legitimise the organisation;

b) The organisation is well established and has legitimacy outside of the registry function;

c) The organisation will commit appropriate resources to provide stable, timely, and reliable service to the geographic region;

d) The commitment to allocate IP numbers according to the guidelines established by the IANA and the IR;

e) The commitment to coordinate with the IR to establish qualifications and strategies for sub-allocations of the regional allocation.

Having met the criteria to become an RIR, and with the endorsement of the RIPE community, the RIPE NCC was authorised by the IANA to take on this role in the service region of Europe, the Middle East, parts of Central Asia and North Africa. The RIPE NCC service region was redefined to exclude North Africa when AfriNIC, the fifth RIR, was formed in 2004.

The responsibility for record keeping covers Internet number resources allocated to the RIPE NCC by the IANA, as well as Internet number resources that were distributed in the RIPE NCC region by the IANA prior to the RIPE NCC's existence. These resources are known as Early Registration Transfers (ERX), or legacy space.

The base set of operational guidelines that Regional Internet Registries are required to follow is documented in [RFC 2050], dated November 1996. These guidelines include:

Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels.

Data in the RIPE Registry

The RIPE Registry contains a set of registration data for all Internet number resources administered by the RIPE NCC. Information must include:

• The number resource or range of number resources
• Status of Internet number resource. This is one of:
  • Allocated
  • Legacy
  • Unallocated
  • Reserved
• Date of last status change

In case the Status is either "Allocated" or "Legacy", the following information is also mandatory:

• Full legal name of Resource Holder
• Full address of Resource Holder
• Contact information for matters of an administrative nature, and for matters of a technical nature. This information consists of an email address and a telephone number

If the status is "Reserved", the reason for the reservation must be noted in the Registration (e.g. a reference to a RIPE policy document).

As registration data may change over time, the RIPE NCC also keeps a history of changes in the Registry.

The RIPE Database provides access to the public data of the Registry. Note that this database contains additional data that is not part of the Registry, and is defined by separate RIPE policies.

Responsibilities

The RIPE NCC has the responsibility for keeping the Registry comprehensive, correct and up-to-date. To do this, the RIPE NCC relies on Resource Holders to supply data that pertains specifically to the Resource Holder, as documented in the RIPE NCC Standard Services Agreement [ripe-435] and/or the Independent Assignment Request and Maintenance Agreement [ripe-462]. For holders of legacy resources this responsibility is derived from the original allocation by the IANA Internet Registry.

Terminology in this Document

Internet number resources: IPv4 addresses, IPv6 Addresses and Autonomous System Numbers.

Registration: The documentation of Internet number resources within the RIPE NCC service region.

Resource Holder: An organisation or individual that has been allocated Internet number resources in the RIPE NCC service region.

Further Reading

[ripe-495] Blokzijl, R., Karrenberg, D., "Principles for Number Resource Registration Policies", July 2010.

References

[RFC 1174] Cerf, V., "IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet 'Connected' Status", August 1990.

[ripe-19]  Blokzijl, R., Devillers, Y., Karrenberg, D., Volk, R., "RIPE Network Coordination Centre", 16 September 1990.

[ripe-35]  Blokzijl, R., "RIPE NCC Activity Plan", 5 May 1991.

[RFC 1366] Gerich, E., "Guidelines for Management of IP Address Space", October 1992.

[RFC 2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., Postel, J., "Internet Registry IP Allocation Guidelines", November 1996.

[ripe-435] RIPE NCC, "RIPE NCC Standard Service Agreement", August 2008.

[ripe-462] RIPE NCC, "End User Assignment Agreement", February 2009.

This document sets out the principles for IPv4 address registration after the unallocated pool of addresses has run out. The purpose of this document is to expose the thinking of the authors, and encourage a discussion in the community.

This is not a policy proposal. Once there is community consensus about these principles, the authors intend to instigate the development of appropriate policies.

2. History

From the very first RIPE Meeting in 1989 the need for a registry has been identified. In the early years of RIPE this consisted of documenting the use of IPv4 address space in the RIPE region on a voluntary basis. The actual address space was not distributed by RIPE.

From August 1992 the new RIPE NCC started distributing address space in the RIPE region. These allocations were done following rules agreed upon by the RIPE community. Over the years these rules - or policies as we now call them - have evolved based on the principle of distributing unallocated resources. While the vast majority of the policies deal with distribution of address space, some of them deal with registration.

Allocations made by the RIPE NCC have always been documented in the registry by the RIPE NCC and the Local Internet Registries (LIRs).

In the foreseeable future there will be no more unallocated address space. However, the authors believe that the need for an accurate registry will remain.

3. The Need for New Registration Policies

Current registration policies are part of much wider distribution policies. In the near future the unallocated pool will have run out. Therefore the whole set of distribution policies will become historic. However, the registry will still remain and the authors expect that the community will still find it useful.

There will be a continued need for registration policies. Rather than changing the current policy documents by removing the parts relating to address space distribution, the authors suggest to produce a registration policy document that reflects the new situation.

4. Purpose of the Registry

At the root of any policy about the resource registry lies the purpose of the registry. Therefore we briefly enumerate the diverse purposes of the RIPE registry below.

The RIPE NCC address registry serves two purposes:

1. A comprehensive public recording of the address space for which the RIPE NCC has administrative responsibility. This concerns both address space allocated by the RIPE NCC and address space allocated by others and transferred to the administrative responsibility of the RIPE NCC.
   
   
2. A comprehensive public recording of the current holders of the address space.

Transparency and accountability about the administration of Internet number resources has always been very important. Publication of the registry is an essential element of this transparency and accountability.

The registry plays an important part in the operational coordination between Internet operators.

Other applications of the registry are numerous and are not defined by the RIPE NCC.

5. Properties of the Registry

In order to serve its purpose, the registry must have the following properties:

• Comprehensive: The registry has to cover all address space the RIPE NCC is responsible for without exceptions.
• Current: The registry must be kept up to date.
• Correct: The registry must correctly document the holder of the address space.

Note that we describe the properties of the registry and not possible services based upon the registry. One example of this would be a global look-up service across all RIRs.

6. Incentives and Disincentives

The registry can only serve its purpose with active participation of the holders of Internet number resources - the registrants. Any policy must consider incentives and disincentives for registrants to participate.

Here are a few examples:

Incentives:

• Publicly document that the registrant is the rightful user. This is one of the safeguards against hijacking.
• All address space will be registered, irrespective of current or past allocation policies.
• The registry benefits the whole Internet community.

Disincentives:

• Privacy concerns. Concerns about revealing too much personal data in a publicly available registry need to be addressed.
• Commercial confidentiality. Registrants may be concerned about the registry revealing too much about their commercial activities. These concerns need to be addressed.
• Cost. The cost should not be unreasonable in relation to the benefits for the Internet community.

7. What the Registry is Not

The registry is an address registry. It does not constitute a directory of Internet Service Providers (ISPs), neither does it license ISPs.

The registry is not the instrument to implement policies concerning access to, and routing over, the Internet.

8. Conclusion

The authors believe that the RIPE community needs to develop registration policies for the IPv4 address space. This document presents some initial thoughts on the registry. We encourage RIPE to discuss the principles for a registry.

Once the principles are clear and accepted, RIPE should develop policies that define registration services.

Though this document has been developed with IPv4 addresses in mind, the authors are of the opinion that in general a separation between distribution and registration policies should be made for all Internet number resources. Ideally, one registration policy should be applicable to all resources.

This document has been produced by the RIPE Enhanced Cooperation Task Force to explain:

- How the existing structures of Internet governance evolved
- Why these structures are uniquely suited to facilitate ongoing development and innovation in the Internet

With stakeholders outside the traditional Internet community, particularly in the public sector, taking an increasing interest in Internet governance, it is vital that these points be effectively communicated, and that we ensure that innovation and technical development continue. As the "Information Society" considers the future development of Internet governance, "enhanced cooperation" between the RIPE community and these new stakeholders must be a high priority for both the RIPE community and the RIPE NCC.

Contents

Part I: Introduction To Internet Addressing

Chapter 1: Internet Addressing Explained

What is an IP Address?
IP Addresses and the Domain Name System Distinguished
IP Addresses and Internet Routing

Chapter 2: Address Management Explained

Bottom-Up Coordination

Chapter 3: Mechanisms For Address Management

Part II: How Internet Address Management Is Conducted in the RIPE NCC Service Region

Chapter 4: Organisational Structures

RIPE
RIPE Working Groups
RIPE Task Forces
RIPE NCC
Global Coordination
ICANN and IANA

Chapter 5: Policy Development And Implementation

Types of Policy
Address Allocation Policies
Database Policies
Best Practice Statements
The Limits of Addressing Policy
RIPE Policy Development Process
RIPE NCC Activity Plan

Part III: Enhanced Cooperation

Chapter 6: The Need For Enhanced Cooperation

Chapter 7: Consultation Processes

RIPE Meetings
RIPE NCC Government Relations
RIPE NCC Government Roundtables
Other Processes

Chapter 8: Learning Points

What Works
What Doesn't Work
What Is Not Yet Known
Recommendations

Part I: Introduction To Internet Addressing

Chapter 1: Internet Addressing Explained

What is an IP Address?

At the heart of how the Internet works is the Internet Protocol, the standard according to which different devices communicate. The genius of the Internet Protocol is that when devices use this standard they can connect to each other and exchange information, even if they are completely different kinds of device (such as a personal computer running Windows and a mobile phone), made by different manufacturers, owned by different users and are connected to different networks in different parts of the world. Using the Internet Protocol (also known as IP), truly global interoperability is achieved between highly diverse information processing systems.

In order for one device, such as a PC, to send data to another, it must be possible to identify the destination and distinguish from alternative possible destinations. The Internet Protocol achieves this by saying that each device must have an address, known as an IP address. As the public Internet seeks to achieve global interoperability, each device must have an IP address that is distinct from that for every other device; its address must be globally unique. If the addresses were not unique (that is, if two or more devices use the same address) then data intended for one physical destination could be mistakenly sent to another. This would not merely result in a loss of confidentiality: if data is sent randomly to several devices experiencing such an address clash it will generally result in a complete communications malfunction.

Ensuring that each Internet-connected device is capable of being assigned a globally unique IP address is therefore a primary requirement for the successful operation of the Internet.

IP Addresses and the Domain Name System Distinguished

IP addresses are the means by which machines identify themselves. In the case of IP version four (IPv4), each address represents a 32-bit number, which is actually displayed as a series of four numbers (each between zero and 255) separated by dots, such as 10.201.57.254. This format is not particularly memorable for humans.

In order to identify a particular location on the Internet (such as a website), humans generally use a different addressing scheme called the Domain Name System (DNS). The DNS contains the addresses that are widely recognised, such as www.example.com. When a human uses a computer and seeks to contact a website using such an address, the computer must first translate the DNS address (which is understood by humans) into an IP address (which is understood my computers). www.example.com becomes 10.201.57.254.

Both IP addressing and the Domain Name System are critical Internet systems and present important issues for Internet governance. They are, however, quite different systems; they are managed separately and face different issues. This paper is concerned with the management of IP addresses only.

IP Addresses and Internet Routing

A machine that accepts data from another device and passes it on towards its ultimate destination using the Internet Protocol is called a router. Internet networks consist of routers, which select paths or routes over which they transmit messages toward their destination.

To transmit a communication across the Internet, the data is first split up into packets. This is true whether the communication is an e-mail or a web page, a voice call or a video stream, or any of the other myriad types of communication that occur on the Internet. Each packet is labelled with the destination IP address, and passed from one router to the next until it reaches its destination, at which point all the packets are reassembled into the format of the original communication. This means that routers do not need to understand the different kinds of higher-level communication that occur on the Internet – to a router, the packets that make up an e-mail appear no different from those that make up a video stream; routers simply need to know how to route Internet packets towards their destination.

A router may be connected to a few or many other routers, but since the Internet spans the world, no router will be directly connected to every other router. It is not possible to be directly connected to more than a tiny proportion of all the routers that exist. An Internet packet will therefore commonly pass through a chain of routers as it moves progressively closer to its destination. The core function of a router is to choose the best nearby router to pass each packet to, so that the packet will reach its destination.

Each router announces or advertises a list of routes it can process, expressed as ranges of IP addresses for which it can provide routing service. Put simply, a router tells its peers, “If you have traffic intended for IP addresses in the range between 192.0.0.1 and 192.5.255.255 (for example), pass me those packets and I can route them onwards.”

This is something of an over-simplification: in practice, a router will often be directly connected to more than one other router capable of reaching a particular destination. There is therefore a communications protocol that routers use, called Border Gateway Protocol (or BGP), which assists routing decisions. This includes helping routers to determine which is the best (shortest) path for a packet to reach its destination.

Chapter 2: Address Management Explained

Bottom-Up Coordination

As discussed in Chapter 1, it is imperative that IP addresses are globally unique. However, IP addresses are just numbers that have been programmed into a computer or other network device as its address. How does the person configuring a new computer with an IP address know which address to use?

In principle, a new device could select any unused IP address and use that. This is slightly complicated by the fact that the device must persuade the router to which it is connected to honour that choice of address, and to announce to its neighbours that it can now route traffic to this new address. And how does the router, or chain of routers, know whether to honour such a new address? In one sense, it doesn’t matter: one IP address is much like another; they’re just numbers and no one address is superior to any other. Accordingly, one might suppose that any such announcement should be honoured.

However, if everyone simply selected their IP address at random, there would inevitably be clashes, and as explained earlier this would destroy the global interoperability of the Internet – data sent across the public Internet would no longer reliably reach its destination. There is therefore a need for IP address users to coordinate amongst themselves so that when configuring a new device they do not select an IP address that is already in use.

The design of the coordination process is called a “bottom-up” process because it is based on the concept that all IP address users can make an active contribution to that process. Every user of IP addresses shares the same interest in ensuring that address conflicts do not occur, and so the community of IP address users comes together in various groups to organise, discuss and make decisions on how the process will work. This is distinguished from “top-down” hierarchies, such as governments or corporations, where an established and recognised authority has the right to determine a policy and to instruct others to carry it out.

Within the geographic region comprising Europe, the Middle East and parts of Central Asia, the name given to the bottom-up community is RIPE (Réseaux IP Européens). The primary purpose of RIPE is to ensure the necessary administrative and technical coordination is achieved. The RIPE Network Coordination Centre (NCC) acts as secretariat to RIPE and carries out the administrative directives of the community.

The RIPE community has determined that it needs to act collectively to prevent IP address space conflicts. This requires mechanisms to facilitate coordination, develop policies for the operation of those mechanisms, institutions to operate those mechanisms in a neutral fashion in accordance with the policy, and processes for the development of new policy and the governance of the institutions. The next chapter discusses these mechanisms, policies, processes and institutions, and explains how these are all derived from and closely tailored to support the requirement to prevent address space conflict.

Chapter 3: Mechanisms For Address Management

To satisfy the requirement that IP addresses be globally unique, the mechanisms for IP address management must be global in scale. As noted in Chapter 2, bottom-up policy is coordinated in Europe, the Middle East and parts of Central Asia by RIPE, but there are similar organisations in other geographic regions that play similar roles. These other organisations are:

• AfriNIC: Africa
• APNIC: Asia Pacific
• ARIN: North America
• LACNIC: Latin America and the Caribbean

As well as acting as a forum for policy decision-making, these organisations perform the function of Regional Internet Registries (RIRs). RIRs have two vital tasks:

1. To distribute IP addresses to their regional community according to the policies developed by that community
2. To maintain a publicly available registry of which addresses have been allocated for use in that region, and to whom

Under the first task, RIRs are designated as the "gatekeepers" of IP addressing, though they act on the instruction of the community members to whom they distribute addresses.

The second task is equally important, however, in providing the coordination to prevent address space conflict. Registries, known as "whois" databases, are maintained by each of the RIRs. The whois database maintained by the RIPE NCC is called the RIPE Network Management Database, which is generally shortened to the RIPE Database.

As well as IP addresses, a whois database contains the names of organisations or customers to whom the addresses have been allocated, and related Points of Contact (POC). They also contain registration information for Autonomous System (AS) Numbers, a separate numbering system used in network-to-network routing.

Coordinated IP address distribution and publicly available databases of address registration information are important factors in the effort to ensure global uniqueness of addresses. The bottom-up coordination of such infrastructure, however, involves a variety of organisational structures, which vary from region to region. Part II of this document looks at these structures and how they operate in the RIPE NCC service region.

Part II: How Internet Address Management Is Conducted in the RIPE NCC Service Region

Chapter 4: Organisational Structures

Implicit in the adoption of bottom-up coordination is the understanding that all members of the Internet community must have the opportunity to participate in the development of IP address management policies.

RIPE

As discussed in Chapter 2, the Internet community in Europe, the Middle East and parts of Central Asia is represented by RIPE, a collaborative forum open to all parties interested in wide area IP networks in the region and beyond. Importantly, there are no membership requirements for participation in RIPE, and no membership fees; its activities are performed on a voluntary basis, with decisions made by community consensus.

RIPE conducts its coordination activities through a number of smaller bodies.

RIPE Working Groups

The majority of work done under the auspices of the RIPE community is carried out in working groups. Each working group focuses on a specific topic or area of interest, and each has one or more mailing lists where relevant topics and questions are discussed. They also hold face-to-face meetings twice a year, as part of RIPE Meetings.

As with RIPE generally, membership of these working groups is open and, for the most part, non-formal (though there are formally appointed Chairs and Co-chairs). New working groups can be formed with the consensus agreement of the RIPE community (or can close down if their area of interest ceases to be of relevance to the community), but they are designed to be ongoing forums for discussion.

RIPE Task Forces

RIPE Task Forces, on the other hand, are designed to complete a specific task or set of tasks. A task force is established by the RIPE community and is given a specific directive and timeframe. At the conclusion of its task, a task force will generally disband.

Anyone with an interest can volunteer, but the number of participants is usually limited, depending on the nature of the task. The outcome of a task force generally takes the form of a report with specific recommendations. These recommendations will be discussed by the RIPE community, and implemented if consensus can be reached.

RIPE NCC

The decisions and policies of the RIPE community are enacted through its secretariat, the RIPE NCC, which is an independent, not-for-profit organisation. As discussed in Chapter 3, the RIPE NCC also acts as the Regional Internet Registry (RIR), providing Internet resources (IPv4 and IPv6 addresses and AS Numbers) and related services to members in the RIPE NCC service region.

The RIPE NCC is funded by its membership, which is a subset of the RIPE community, specifically those community members who have obtained resources from the RIPE NCC. These members are referred to as Local Internet Registries (LIRs) and they are generally Internet Service Providers (ISPs), telecommunication organisations and large corporations with significant presence in the region.

Global Coordination

The nature of the Internet means that there are many challenges whose solutions require global coordination. The RIPE community and the RIPE NCC offer a channel through which global discussion can be conducted, and global agreements reached when necessary.

These discussions happen in many ways, both formal and informal, and there are well-established processes within the RIR system for the development and implementation of global policies. Such policies require discussion and consensus agreement in all RIR service regions.

All of the RIRs are also members of the Number Resource Organization (NRO), a body through which they formalise their cooperative efforts. This can be useful when communicating and coordinating with other Internet organisations, or when engaging parties outside the traditional Internet community (for instance, the NRO has participated in the World Summit on the Information Society (WSIS) and Internet Governance Forum (IGF) processes).

ICANN and IANA

It is also through the RIRs (and sometimes the NRO) that the Internet community communicates with and participates in the "top level" of Internet coordination.

The Internet Assigned Numbers Authority (IANA) is a high-level body responsible for coordinating some of the key elements of the global Internet. Its responsibilities relate to some aspects of domain names, number resources and protocol assignments. The IANA is currently operated as one of the activities of the Internet Corporation for Assigned Names and Numbers (ICANN), an internationally-organised non-profit organisation mainly responsible for the stability of the DNS.

The IANA is responsible for the stewardship of the remaining pool of unallocated addresses. As such, the IANA distributes IP addresses to the RIRs. The global policies under which this distribution occurs are decided within the policy setting forums provided by ICANN, with input from a wide range of stakeholders. The RIRs in turn distribute those addresses to their communities.

The RIRs contribute to these processes both through direct communication with ICANN and IANA representatives at meetings around the world and through more formal relationships. The NRO Number Council, a body made up of three community members from each RIR service region, also fulfils the role of the Address Supporting Organization (ASO) Address Council, whose main tasks include overseeing recommendations on global IP address policy and the appointment of several Directors to the ICANN Board of Directors.

Chapter 5: Policy Development And Implementation

While policies guiding the management of IP addressing are vital to the successful operation and development of the Internet, it does not follow that the same policies will be appropriate in all regions. Different economic, geographic and historical factors mean that the requirements of the Internet community in each region can be very different.

For this reason, Internet policies of various kinds are agreed on at a regional level by the Internet community, and implemented by the RIRs. The broad definition of "Internet community", which includes ISPs, governments, regulatory bodies, network engineers, end users and anyone else with an interest, means that this system allows for all concerns to be addressed before a policy is agreed on.

Types of Policy

The policies developed and agreed on by the RIPE community are expressed in RIPE Documents, and fall into several broad categories (though some policies may fall under more than one of these):

• Documents relating to address policy and address management (including IPv6 documents)
• RIPE Database documents
• RIPE NCC organisational documents
• Information Services documents
• Request forms and supporting notes

All RIPE Documents are accessible to anyone on the RIPE website:
http://www.ripe.net/ripe/docs/index.html

Address Allocation Policies

Policies governing the allocation and assignment of IP addresses and AS Numbers are central to the RIPE NCC's role as the Regional Internet Registry, and central to the overall goal of global uniqueness in addressing. These policies are created and implemented to fulfil four major requirements:

• Uniqueness: All public IP addresses address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
• Aggregation: The distribution of IP addresses in a hierarchical manner permits the aggregation of routing information, which helps to ensure proper operation of Internet routing.
• Conservation: Public IP address space must be fairly distributed to organisations that operate networks and can demonstrate a legitimate need.
• Registration: The provision of a public registry documenting resource allocations and assignments must exist to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

These goals will be represented variously in policies covering IPv4 addresses, IPv6 addresses and AS Numbers. Separate policies are necessary to meet the varying technical and operational needs of the different protocols.

Database Policies

Responsibility for the RIPE Database is another central role of the RIPE NCC, and the community must agree on any substantive decisions about the operation of this database. A Database Working Group exists for discussion of database-related issues, and a RIPE Document relating to the database can be viewed at:
http://www.ripe.net/ripe/docs/ripe-419.html

Best Practice Statements

Some RIPE Documents look at Current Best Practices in relation to various aspects of network operation. By helping to foster practices that are recognised as efficient and useful for network trouble-shooting, these statements are useful to the whole Internet community.

The Limits of Addressing Policy

It is important to note the limits of IP addressing policy. As noted earlier, the fundamental design of the Internet means that anyone can at any point "announce" any address they choose to. IP addressing policies cannot change this fact, but at the same time it is in no one's (legitimate) interest to make the Internet unusable.

IP addressing policy, as it is currently developed, can take into account the needs and concerns of all sectors of the Internet community. This results in policies that produce the best result for the Internet itself, and for the community at large.

RIPE Policy Development Process

The RIPE community creates policy according to a well-defined process. This Policy Development Process (PDP) is laid out in a RIPE Document, and is available at:
http://www.ripe.net/ripe/docs/pdp.html

The RIPE PDP is designed to allow all interested parties to have input into the decision making process, whether through the RIPE Meetings or working group mailing lists. A policy that has come through the PDP will have had a chance to be considered by all interested parties, meaning that the final result is widely regarded as being in the best interests of the broad Internet community.

RIPE NCC Activity Plan

In its role of implementing the RIPE community policies, it is important that the RIPE NCC be seen to be fair, unbiased and transparent. The RIPE NCC Activity Plan is an important way in which this is demonstrated. It publicly lays out the plans and priorities for the RIPE NCC over the coming year, and all members of the RIPE community have the chance to comment on it. At the end of this process, the RIPE NCC Board, who are elected by RIPE NCC’s membership, will decide whether or not to approve the Activity Plan for the coming year.

Part III: Enhanced Cooperation

Chapter 6: The Need For Enhanced Cooperation

"Enhanced cooperation" is a term that was coined during the World Summit on the Information Society (WSIS) in 2005. It refers to the developing relationships between all stakeholders in the "Information Society", particularly between the private and public sectors. It is an issue that has taken on increased prominence in recent years, as the wider Internet community strives to ensure that all stakeholders' voices are heard and all interests served.

As detailed in the first two parts of this document, the existing structures of Internet governance (including RIPE and the global RIR system) have evolved over the past decades to meet the very specific challenges that the Internet poses. While the RIPE community therefore welcomes the increased participation of all Information Society stakeholders, it is important that these new stakeholders participate with an understanding of the ramifications that even local IP addressing policy can have on the global Internet.

For the RIPE community then, enhanced cooperation is an important opportunity to improve communication with those stakeholders in the Internet community who do not tend to participate in the standard RIPE forums. This especially includes government and regulatory bodies (the public sector), who in recent years have taken an increasing interest in issues of Internet governance.

It is also a chance to educate these other stakeholders on the existing systems, and why we believe they should be maintained and strengthened. The reasons for this belief include the following points:

Provide Assurance of Operational Stability

The RIR system emerged in part to address the need for a stable, reliable means of controlling IP address distribution and management globally. The structure of the Internet itself relies heavily on such stability and certainty. Factors such as the depletion of unallocated IPv4 address space and the increasing involvement of public sector organisations, however, mean that the Internet industry is facing a period of change.

In this environment, the need for open and clear dialogue between all stakeholders, and especially between the public and private sectors, is vital to ensuring the ongoing operational stability of the Internet's infrastructure.

Provide Assurance of Good Policy

While the RIR policy development system is designed to facilitate input from all interested parties, this goal can only be achieved when all parties are aware of the process. In the past, this has meant that some parties with an interest in Internet addressing policy have not taken part in policy development.

One of the goals of enhanced cooperation is to increase awareness of and participation in the existing policy development processes, which is vital to the final goal of creating policies that are in the best interests of all parties. These processes allow for input from various stakeholders through a range of channels, not just RIR meetings.

Maintain Confidence in Institutions and Processes

The RIPE community believes that the existing system of institutions and processes for Internet policy development has proved itself to be fair, open, flexible and efficient. As such, it is well positioned to meet the challenges of policy development in a rapidly changing industry.

Enhanced cooperation is an important means of disseminating knowledge of the existing system, its institutions and processes, and of building confidence in that system's ability to meet the needs of all stakeholders. Confidence in these institutions and processes is vital to ensuring wider participation in the development of policy, and general respect for the policies produced.

Chapter 7: Consultation Processes

The RIPE NCC is already involved in a range of activities that fall under the description of enhanced cooperation. These include activities within the official policy development process, as well as outreach activities described in the Activity Plan.

RIPE Meetings

RIPE Meetings are some of the biggest undertakings of the RIPE NCC, and happen twice a year. As well as playing a central role in the policy making process, the meetings are a chance for members of the Internet community to gather and meet. Most importantly, RIPE Meetings (like all RIR meetings) are open to everyone, and therefore offer a unique opportunity to further enhanced cooperation through face-to-face contact between all sectors of the Information Society.

RIPE NCC Government Relations

The RIPE NCC is also taking an active role in reaching out to the public sector, including specific governments. With governments taking an increasing interest in Internet policy, this can often mean simply acting in an advisory role at government-organised events.

RIPE NCC Government Roundtables

The RIPE NCC is also pro-actively engaging the public sector through Government Roundtable meetings, at which are discussed Internet management issues relevant to governments, regulators and industry partners. These events provide a chance for attendees to learn more about how to participate in IP address management policy-making. High-level discussions of IPv4/IPv6 address space and root name servers (one of which is operated by RIPE NCC) also provide attendees with an overview of the main elements involved in the technical coordination of the Internet.

Other Processes

The process of enhanced cooperation is ongoing, and will include activities beyond those discussed here. Such activities are often spearheaded by the RIPE NCC, but may involve contributions from other members of the RIPE community.

It is also important that the RIPE community be aware of the activities being undertaken in its name, and it is for this purpose that this Task Force recommends the formation of a Cooperation Working Group.

Chapter 8: Learning Points

What Works

Enhanced cooperation with the public sector has been a priority for the RIPE NCC since the lead-up to the WSIS events. This priority has been reflected in events such as RIPE NCC Government Roundtables and an increased presence at various government-organised events.

From this experience, it is clear that the best results in this area are produced by targeted activities. This can mean engaging the public sector participants in their own forums, or it can mean organising specific events beyond the traditional RIR event schedule.

What Doesn't Work

It is clear that the conventional channels and processes of the Internet community are not, of themselves, sufficient to meet the demands of enhanced cooperation. There is a range of reasons why interested parties outside the traditional RIPE community have not taken the opportunity to participate in forums such as the RIPE Meetings or mailing lists, but it is clear that if Internet policy is to have any authority, the policy development process must engage with these parties.

"Business as usual" in this case will not work. With the addition of targeted outreach activities and a flexible approach, however, the existing processes and institutions can still meet the needs of enhanced cooperation.

What Is Not Yet Known

At this point, the future of Internet addressing policy remains unclear. Enhanced cooperation is a broad strategy to ensure that as the Internet community adapts to the changes ahead, the needs of all stakeholders, both private and public sector, are recognised and reflected in Internet policy.

At the same time, it is also vital that the evolving policy development processes not hinder the ongoing operation of the Internet and development and innovation in the Internet industry.

Recommendations

This Task Force notes the ongoing importance of enhanced cooperation to the RIPE community and recommends that the RIPE community form a Cooperation Working Group, with the following charter:

The Cooperation Working Group is a forum for discussion focusing on cooperation between the private and public sectors on Internet matters. This kind of cooperation has taken on increased prominence in recent years, as the wider Internet community strives to ensure that all voices are heard and the interests of all parties are considered. Fostering more open dialogue between all stakeholders is vital to ensuring the continued stability of the Internet.

The working group discusses the following:

1. The working group will primarily discuss outreach from the traditional RIPE community to everyone else, especially governments, regulators and NGOs, all of whom we are trying to bring into our community. Topics are not to duplicate issues discussed in other working groups. This working group should complement the other working groups and help participants engage in appropriate work.
2. The RIPE NCC's current outreach activities will be reported, and the RIPE NCC will seek advice and guidance on future activities. This is to make the discussions more focused - currently the only forum for these discussions is the ripe-list mailing list.
3. The working group will develop and clarify the RIPE community's position on issues that are of relevance to the public sector or on which a community position has been sought.
4. The working group will be responsible for maintenance of the RIPE Document produced by the Enhanced Cooperation Task Force, describing the RIPE community, existing policy development processes and outreach programs. The working group explicitly does not have change control over the RIPE Policy Development Process (PDP) itself.

The working group is also an important channel through which the RIPE community can communicate with others in the Information Society. The Chairs are not to become special Ambassadors for RIPE. Their role is the same as other RIPE Working Group chairs, which implies they of course could be asked now and then what the status of the working group is. The process by which RIPE and RIPE NCC respectively coordinate with other bodies (such as the NRO) and communicate (mostly via RIPE NCC or the chair of RIPE) is not changed by creation and existence of this working group.

Footnote

Globally Unique:

The Internet Protocol can also be used to enable communications on private networks as well as the public Internet. The IP addresses of devices on a private network do not need to be globally unique, merely unique amongst the devices connected to that network. However, if such devices are also to communicate with the public Internet they must have a globally unique IP address, or else rely on some intermediary device that does. For details of strategies whereby many devices may share the use of such an intermediary, thereby reducing the number of IP addresses that are needed, see Network Proxy and Network Address Translation.

Practicalities

All sponsored hosts are responsible for the provision of:

• Space in a data centre for the TTM equipment
• Sufficient power and cooling
• All of the infrastructure that is required to connect the node to the Internet
• Remote hands support.

The RIPE NCC will provide TTM equipment for fully sponsored hosts. Partially sponsored hosts will need to provide server hardware. The RIPE NCC will provide the necessary Global Positioning System (GPS) antenna equipment to all sponsored hosts. No TTM service fees will be charged to any sponsored host.

Sponsorship Criteria

This document lays out the criteria used to select a site for sponsorship. Although these guidelines cover a range of site/host requirements, fulfilling all these requirements does not automatically entitle the host/site to receive a sponsored node. Similarly, those hosts/sites not meeting all the requirements are not automatically excluded.

Preference will be given to neutral and independent bodies, such as academic or not-for-profit organisations, and to those organisations that work to support and promote the development of the Internet. Commercial organisations are not normally considered as candidates for sponsorship.

Requirements

1. TTM nodes should be located:

• Within a major Autonomous System (AS) or;
• At a point where a large number of ASs peer, such as a major Internet Exchange or;
• At any other point of significant interest, such in proximity to a root DNS server

This is to ensure that the node serves as a good reference point and so any conditions, such as bottlenecks, which might distort the general connectivity overview, can be avoided.

DNSMON is built on top of the Test Traffic Monitoring (TTM) network [2], and it uses the same probes for its measurements. Measurements are carried out by sending normal DNS queries to monitored servers at regular intervals. All results are available to the public.

The RIPE NCC's DNSMON measurements benefit the entire Internet community by providing an objective and impartial global overview of TLD-level DNS operations. As part of this service, we monitor some interesting infrastructure domains, including the root, free of charge.

If requested by the operators, we will also configure monitoring for the DNS servers of:

• Any TLD (ccTLD, gTLD etc)
• Any Tier-1 ENUM domain (for example, 1.3.e164.arpa)

Fees are charged for this service on a cost-recovery basis. Subscribers receive additional benefits, which may change from time to time. These are documented within the DNSMON operational service documents [3].

[1] ftp://ftp.ripe.net/ripe/docs/ripe-342.pdf
[2] http://www.ripe.net/ttm
[3] http://dnsmon.ripe.net/

A survey carried out in March 2006 revealed that around 11-13% of the nameservers listed in delegations from IANA to the RIPE NCC are 'lame', meaning they are not responding correctly. This document provides more information on the subject.

Table of Contents

1. Background
2. Definition of Lameness
3. Lameness Checking and Reporting
4. Interaction with ns.ripe.net
5. Email to Maintainers

1. Background

The Internet Assigned Numbers Authority (IANA) has delegated the following zones to the RIPE NCC:

• List of delegations was correct at publication date.
• This table includes those parts of Early Registration Transfer (ERX) space that are under the control of the RIPE NCC.
• ERX was a project to take IP allocations made before the RIR System started and move them into management by Regional Internet Registries.

2.Definition of Lameness

There are several definitions of lameness available. However, within the context of this document and these checks, a server will be regarded as lame if it does not satisfy the following test:

• The target of an NS RR must resolve into at least one address record RR (A or AAAA RR).
• A standard DNS UDP query with RD=0 for an SOA RR in the IN class, with QNAME=zonename, must result in an authoritative response, sent from the same address the queries were targeted at with a single SOA RR for the QNAME in the answer section.
• This testing will be network layer protocol independent.

If a server fails this test it will be retried five times over a period of ten days (at varying times of day). After this time, it will be classed as lame.

• In the case of multihomed servers with multiple A (or AAAA) records, repeated failure of any of the designated A records will result in the server being classed as lame.
• In the case of anycasted servers, only the server visible from the RIPE NCC premises in Amsterdam will be tested. If this project is successful, we may expand this test to cover different areas.

3. Lameness Checking and Reporting

The RIPE NCC will run a lameness check once each month against all DNS servers listed as delegation points within the RIPE NCC delegated zones.

• Lameness will be checked over both IPv4 and IPv6, but reported separately.
• Following the completion of this check, we will send an email (via SOA RNAME) to all operators with servers reported as lame.
• We will send an email to the maintainer listed for the domain object in the RIPE Database.
• We will send just one email for each lame server.
• We will publish details and statistics of lameness levels on www.ripe.net.
• We will periodically assess the effectiveness of these efforts by reviewing the published statistics.

4. Interaction with ns.ripe.net

• As the server ns.ripe.net is a delegation target for all /16 IPv4 reverse delegations, we will check all of its zones automatically.
• We will further investigate all zones reported as lame on this server to determine why and resolve the problem as soon as is possible, although this may also involve contact with third parties.

5. Email to Maintainers

The sample text of the alert email that we will send to operators with servers reported as lame:

Dear administrator of [server name]

According to checks made on [date], your server, [server name], was lame for the following zone(s):

[zonelist]

For information about the checks that we made on your zone(s), please see:
http://www.ripe.net/ripe/docs/ripe-400.html

The DNS root nameservers are a critical part of the Internet’s infrastructure, and anycasting is increasingly being used in their deployment. However, while there is little doubt that anycasting improves resilience, its effects on other aspects of DNS service quality are not well understood. We present methodologies to study the quality of service provided by an anycast server cloud, combining analysis of packet traces and server logs with active measurements from both the client and the server side to evaluate both aggregate performance and the benefit of each individual anycast node. We apply the methodologies to the K-root server and, in contrast to other work, find that anycast is effective in decreasing latency and preserving node affinity, suggesting that the impact of anycast depends heavily on the type of deployment used. We also study the effects of K-root’s anycast deployment model on server load and routing, highlighting particular scenarios in which the model can lead to performance and reachability problems.

Table of Contents

1 Introduction
2 Background

3 Measurement methodologies

4 Application of our methods to K-root

5 Routing issues

6 Effect of anycast on server load

7 Conclusions

Acknowledgements

References

1 Introduction

The Domain Name System [16, 14, 15] is a database of Internet names and addresses, which is used, for example, to translate Internet hostnames such as www.ripe.net to IP addresses such as 193.0.0.214 . It is a distributed database in which domain names are maintained in a hierarchical tree structure. The DNS root nameservers maintain the authoritative list of servers for top-level domains such as .com, .net and .org. Any DNS query, except for queries in a domain made to a DNS server that is authoritative for that domain, requires a response from a root server to be answered. The response may be cached, but if the root servers are not available, no names can be resolved once the caches expire.

As the root servers are such a critical part of the Internet infrastructure, anycasting [18] is increasingly being used in global root server deployments. At least six of the 13 root servers (C, F, I, J, K, and M) have adopted anycast in some form, and some of these have deployed tens of nodes all over the world (for current status, see [23]). However, while there is little doubt that anycast improves resilience, the effects of anycasting on other aspects of DNS service quality are not well understood. In this paper, we present methodologies to study the quality of service provided by an anycast DNS server and the results of their application to the K-root server. A brief list of the contributions of this paper is as follows:

• We present methodologies for evaluating the quality of service provided by an anycasted DNS server. By combining analysis of packet traces and server logs with active measurements on both the server and the client side, we are able to evaluate both the efficiency of the deployment as a whole and the benefit to clients of each individual anycast node. We show how these methods may be used to evaluate the location of a prospective new anycast node.

• We apply the methodologies to the K-root DNS server, combining the results with geographical and operational data to provide what we believe is the most comprehensive analysis of the performance, client placement, and server load of an anycasted server to date.

• We examine routing issues related to anycast, providing examples of non-obvious issues that can cause perfor-mance and reachability problems.

The rest of the paper is organised as follows: Section 2 provides background information on anycast, its goals, and the topologies used, and on the particular topology adopted by K-root. We present our methods in Section 3 and describe their application to the K-root server in Section 4. Section 5 discusses routing issues, and Section 6 examines the effects of anycast on server load. We conclude and discuss future work in Section 7.

2 Background

In this section we provide background information on DNS anycast and its goals and provide an overview of the types of deployments used, citing the K-root server as an example.

2.1 DNS Anycast

We define DNS anycast as the practice of providing DNS service at the same IP address from multiple geographic or topological locations [9, 1]. A node is a set of one or more DNS server machines and associated network equipment in a particular location; all nodes, regardless of location, answer DNS queries sent to the same IP address, which we name the service IP address. We name the set of all nodes the anycast cloud.

Every DNS query sent to the service IP address is routed to exactly one node, the best node, which is the closest node as determined by the routing protocol in use. At a given moment, different clients will in general have different best nodes according to their routing policies and metrics. A client making a DNS request does not usually know which node it is communicating with; however, most anycast deployments provide this information via a special DNS query, which returns the name of the node that answers it [27].

The DNS server machines are typically also reachable using unicast IP addresses, which we name internal ad-dresses. Depending on the type of deployment, the the internal IP addresses may be routed in the same way as the service IP address; if so, then the path taken by DNS queries to the service IP address (except the portion of the path inside the node itself) will in general be the same as the path to the internal IP addresses of the best node.

2.2 Goals of anycast

Anycast is deployed on root servers for various reasons, including increasing resilience, increasing performance, and providing a more stable service. Before describing the methodologies we propose to evaluate the quality of service of an anycast deployment, we briefly discuss these goals here.

2.2.1 Resilience

One of the two goals of anycast stated in [1] is to improve the resilience of the DNS infrastructure to denial-of-service attacks. This problem cannot be solved simply by increasing server performance, because in most current deployments the servers can already withstand higher attack loads than the networks that surround them, and during an attack it is network congestion rather than query load that renders the servers unresponsive. Denial-of-service attacks are mitigated both by local nodes, which act as local sinks for DOS attacks in their catchment area, and by global nodes, which spread the attack load over multiple servers and networks. We may assume that that anycast improves resilience: the more nodes deployed and the more widespread the deployment, the less likely that a node failure or an attack can cause widespread disruption of service. However, we did not attempt to measure the effect on anycast on resilience.

2.2.2 Performance

Another goal of anycasting is to improve performance. Deploying nodes topologically close to clients will decrease query times; however, network topology only loosely correlates with geography [10] and therefore deploying nodes geographically close to clients is not necessarily an effective strategy for minimising query times. Furthermore, as we show in Section 5, the presence of local nodes may complicate the situation and actually decrease performance.

2.2.3 Reliability

Finally, anycast should increase the reliability of DNS service. Deploying nodes close to clients should increase reliability by decreasing the number of network elements that queries must traverse. However, although the vast majority of DNS queries are simple request-response transactions involving one UDP packet in each direction, some queries involve multiple packets (e.g. queries using TCP, or queries in which the UDP query packet is fragmented). If a client’s best node changes while the query is in progress, not all the packets will reach the same node and the query will fail. Therefore, as the number of deployed nodes increases, the number of routes competing in the routing table increases, and with it both routing churn and the probability of query failure in these cases.

The impact of this problem is not clear: for example, in a study of J-root [5] the authors state that this is a serious problem and recommend that stateful services not be run on anycast at all. Other work has since concluded that the

impact of node switches is not significant enough to be a concern [6, 12]. Our own results for K-root are presented in Section 4.3.

2.3 Anycast topologies

In the following we shall consider BGP-based anycast mechanisms as described in [1]. Each node announces to the routing system reachability information for the same network prefix (the service prefix), which contains the service IP address. The announcements from different nodes compete in the interdomain routing system, where they are propagated according to the usual BGP route selection process. Two types of anycast nodes are defined: global nodes and local nodes. Global nodes are intended to provide service to the entire Internet, and must have sufficient bandwidth and processing power to handle a global load of client requests. Local nodes are intended to provide service only to a limited area known as the node’s catchment area. The distinction between node types is accomplished by using BGP policy mechanisms: firstly, the paths announced by global nodes are artificially lengthened using AS-path prepending; since one of the most important metrics used by the BGP route selection algorithm is the length of the AS-path, this causes the paths announced by local nodes to be preferred. Secondly, the announced made by local nodes are tagged with the “no-export” community value [8], which requests that their routing announcements not be propagated to other ASes.

Different root server operators use different deployment strategies. In the following, we term an anycast topology flat if it contains only global nodes, hierarchical if it contains a small number of global nodes close to each other and a large number of local nodes, and hybrid if it contains both a number of widely-distributed global nodes and a number of local nodes. Examples of flat, hierarchical, and hybrid topologies are J-root [5], F-root [1], and K-root respectively. A hierarchical deployment has both advantages and disadvantages with respect to a flat deployment. Since local nodes do not need to handle a global load of client requests, they may be deployed in areas with limited Internet connectivity and bandwidth; also, problems with a local node can at worst disrupt service in its catchment area. On the other hand, clients not in the catchment area of a local node will send queries to global nodes, and since the global nodes are concentrated in a small geographical area, this will result in high query latencies for distant clients. Finally, if an announcement from a local node is mistakenly propagated into the global routing table, the node and the surrounding network infrastructure may be overwhelmed by the resulting increase of requests.

2.4 K-root deployment structure

The K-root nameserver uses a hybrid topology which currently consists of 5 global nodes and 12 local nodes, as shown in Table 1. A node typically consists of two servers running the NSD nameserver software [17], a monitoring server, routers and switches. Queries are distributed between the servers using OSPF load balancing [2]. We name the network interface a server receives queries on its service interface; the service interface is reachable both through the service IP address, 193.0.14.129 , and an internal IP address, which is different for each server. Normally, the internal IP addresses are firewalled and queries sent to these addresses from the Internet are dropped. The prefix containing the node’s internal IP addresses, which we name the node’s internal prefix, is announced in the same way as the service prefix.

3 Measurement methodologies

In this section, we present our methodologies to evaluate the benefit of deploying anycast on a DNS server. We first discuss methods to evaluate the efficiency of the deployment as seen by a given client by using client-side and server-side measurements, and then present methods to evaluate the benefit of a given node in the cloud.

Our main performance metric will be query latency. Since our measurements on K-root hardware showed that response times are dominated by network latency, and that the capacity of a single node substantially exceeds both the typical network connectivity of a node and the total query load of the K-root server, in the following we shall neglect the effect of server load and focus only on network latency.

3.1 Measuring anycast efficiency

Ideally, every DNS query sent to the service IP address should be routed to the node with the lowest latency. Therefore, for every client we may see whether anycast is choosing the node with the best performance by comparing the response time of the node chosen by the routing system with the response times of the other nodes in the cloud. The former may be measured simply by sending a query to the service IP address; the latter may be estimated by measuring the response time of the internal IP addresses of all the nodes in the cloud. Note that this assumes that each node announces its internal prefix in the same way as the service prefix. This assumption is not true in all anycast deployments, but it may be verified, for example, by examining the BGP or router-level paths to the two addresses. It also requires that the internal addresses of all the nodes respond to probe packets, which may not be the case (for our K-root measurements, the firewall was opened to allow queries to the internal addresses).

More formally, given a population of clients P and the set of server nodes N , for every client c_i we measure the latency RTT ⁱ to the service IP address and compare it to the latencies RTT ⁱ_n of the other nodes in N . If the deployment contains local nodes, a given client might not be able to reach all the servers in N , but it is obviously only interesting to measure the latencies to the set N_c of nodes that the client can actually reach. However, if we assume that routing is configured in such a way that local nodes are favoured (e.g. if the announcements of global nodes are prepended and the local nodes are announced with no-export), then N_c = N_G ∩ A , where A is the client’s best node¹ . We define the anycast efficiency factor of the client, α_i , as the RTT to the service IP address divided by the RTT of the closest global node:

If α_i =1 , then the client’s best node is the node with the best performance. If α_i > 1 , then the routing system is choosing a sub-optimal node. If α_i< 1 , then the client’s best node is a local node.

3.1.1 Client-side measurements

The anycast efficiency factor for a given client client expresses how well the routing system does in selecting the best node for a particular client. Therefore, by measuring α for a suitable client population, such as that provided by the TTM network [22], Skitter probes [11] or PlanetLab [19] and aggregating the results, it is possible to obtain a general picture of how effective of an anycast deployment is in reaching its clients. Thus, client-side measurement allows us to obtain a fairly accurate picture of the efficiency of an anycast deployment in relatively little time.

3.1.2 Server-side measurements

Due to the fact that measurements are made by a limited number of probes, the results results suffer from various limitations. Firstly, they do not provide a complete evaluation. Secondly, they are biased by probe location. Finally, the probes are not necessarily representative of the client population of the anycast cloud.

Another possible approach is that of measuring latency from the server nodes to the client population. This has the advantage that the data set is much larger (for K-root, the client population seen in one day is of the order of one million, which is three or four orders of magnitude greater than any network of measurement probes that we are aware of), and that the data set is representative of the actual client population. Furthermore, if data on the number of client queries is available in addition to the client population, it is possible to weigh the anycast efficiency factor of every client by the number of queries it makes in order to evaluate the performance seen by those clients that are most important. Measuring the RTT to a client from a server can be done by sending an ICMP echo request (ping) packet and measuring the time it takes for the client to reply. Note that many clients may not respond to pings because they

¹ For simplicity, we are ignoring the case in which the AS of the client could reach more than one local node. In this case, we assume that the interior routing of the AS has picked the correct node.

are behind firewalls or for other reasons, which biases the results; data on the incidence of this problem in the K-root client population is presented in Section 4.2.

Note that if the RTTs obtained by server-side measurement are to be representative of the actual RTT of a DNS query, then the path followed by probe packets and responses must be representative of the path taken by DNS traffic. This implies that (a) probe packets must be sent out using the same route that DNS replies use to reach the client, and

(b) probe replies must reach the server by the same route as DNS requests from the client.

Requirement (a) can be satisfied simply by sending probe packets from the DNS server itself or from another host that uses the same next-hop router. However, requirement (b) is harder to satisfy. Probe packets cannot be sent by a node using the anycasted service IP address, because if they were, the replies would reach the client’s best node instead of reaching the node that sent the probes. Therefore, the source address must be a unicast address that is guaranteed to be routed to the node that sent the probe packet. Whether such an address is available depends on how routing announcements are made and on the internal structure of the node. As we have seen in Section 2.4, in the K-root deployment each node announces its internal prefix in the same way as the service prefix, so any IP address in the internal prefix may be used for this purpose.

3.2 Evaluating the benefit of individual nodes in the cloud

Measuring the latencies from the server nodes to the client population allows us to evaluate the benefit provided by each node in the anycast cloud. We may define the benefit provided by a given node to a given client as the increase of performance, if any, that the client experiences thanks to the existence of the node, or, equivalently, as the loss of performance that a client would see if the node did not exist. We may express this as the latency RTTⁱ_≠n that the

client would see if the node n did not exist divided by the RTT seen from the client i to the service IP address RTTⁱ . Because we cannot predict the effect of routing changes, the value ofRTTⁱ_≠n is not known. However, if we assume

that routing is optimal, i.e. that every client selects the node with the lowest latency, then RTTⁱ =min_n RTTⁱ_n and RTTⁱ_≠n =min_{j ≠n} RTTⁱ_j . Thus, for any client i and node n , we define the loss factor βⁱ_n as follows:

Since we assume optimal routing, βⁱ_n ≥ 1 . If βⁱ_n =1 , then the node provides no benefit to the client; if βⁱ_n =2 , then the presence of the node doubles the client’s performance, and so on. It may also be useful to evaluate the effect on performance of a set S of nodes at the same time. For example, evaluating the combined benefit of all the nodes in a particular geographic region gives an idea of how much redundancy the nodes introduce, and evaluating the combined benefit of all the nodes except the first node deployed gives an idea of how effective the anycast deployment as a whole is. This can be done trivially by calculating the sum in (2) over all nodes except all the nodes in S .

Of course, the assumption of optimal routing does not hold for all clients. For example, as can be seen in Fig-ure 5(a), α_i ≈ 1 only for about 50% of the clients that responded to our ping probes. However, we believe it is a useful metric in order to evaluate how well the server nodes are placed in relation to the client population.

Once the benefit of a node to each client has been determined, we may calculate the total benefit of a node B_n simply by taking the weighted average of the benefit seen by every client, where the weights are proportional to the number of queries that the client sends to the server:

where Q i are the queries sent by the client i to the server in a given time interval. The higher the value of B_n , the more useful the node is; a node with β_n =1 provides no benefit to clients.

4 Application of our methods to K-root

In this section we describe the application of our methods to the K-root DNS server. First, we performed client-side measurements from the TTM network to obtain a picture of the efficiency factor, and examined the stability of the average efficiency factor over time. We then used server-side measurements to obtain a more representative view of the global client population. Finally, we used the results of the server-side measurements to determine the benefit of each individual node in the cloud, the two global nodes in Europe, and the total benefit of the anycast deployment.

Figure 1: Efficiency factor α seen by TTM. (a) Two global nodes, April 2004; (b) Five global nodes, April 2005.
Click the images for a larger version

4.1.1 Methodology

Measurements were taken using the dig command to query for the hostname.bind record. Every test-box i performed a set of 5 queries to the service IP address, then a set of 5 queries to each of the two internal IP addresses of every global node. (Since the internal IP addresses are firewalled and do not respond to queries, to perform these measurements we had to temporarily open the firewall.) From each set we then calculated α_i as described in (1). As described in Section 3.1.1, if α_i =1 then the routing system is choosing the optimal node; if α_i > 1 , then the routing system is choosing a sub-optimal node; and if α_i< 1 , then test-box i is using a local node² .

As already discussed, our client-side measurement methodology assumes that the path to an internal IP address is the same as the path that would be taken to the node if that node were the node chosen by the routing system. In the case of K-root the internal IP addresses are announced in exactly the same way as the service IP address. However, the paths are still not guaranteed to be identical, since the service IP address and the internal IP addresses are in different prefixes, and BGP routing policies could in principle distinguish between announcements for the service prefix and for the internal prefixes, even though they come from the same source. However, we believe that current operational practices make this a rare occurrence; furthermore, querying the RIS [21] showed that the the AS-path to the service IP address was the same as the AS-path to one of the internal IP addresses in almost every case.

4.1.2 Results

Two example results are in Figures 1(a) and 2(a), which plot values of α_i measured on 2005-04-08 at 15:00 UTC and on 2006-04-12 at 00:00 UTC. As can be seen from the graph, most values of α_i are close to 1, indicating that the routing system is selecting the appropriate nodes in most cases. This is even more visible in Figures 1(b) and 2(b), which only shows data for test-boxes whose best node at the time of measurement was a global node.

Note that in each of the two graphs in Figure 1 there is a notable outlier. These are due to particular performance problems caused by K-root’s hybrid deployment and are analysed and explained in Sections 5.3 and 5.2.

4.1.3 Effect of number of nodes on efficiency

The graphs in Figures 1 and 2 show that the anycast efficiency seen by TTM did not significantly change between April 2005 and April 2006, even though the two data sets were collected about a year apart, and had substantially different deployments (in April 2005 K-root had two global nodes and nine local nodes, in April 2006 it had five global nodes and twelve local nodes). This suggests that K-root has not reached the point where there are too many

² A result of α_i< 1 could also be due to the path to the service IP address being different from, and slower than, the paths to every internal IP address. However, examining the query responses showed that in every case where α_i< 1 , the node that replied was a local node.

Figure 2: Efficiency factor α seen by TTM, only test-boxes whose best node was a global node (a) Two global nodes, April 2004; (b) Five global nodes, April 2005
Click the images for a larger version .

routing announcements competing in the global routing system for BGP to draw substantially wrong conclusions and that there is still room for more global nodes.

4.1.4 Consistency of anycast efficiency over time

Figure 3: Average value of α over all test-boxes except tt103 over a 7-week period.
Click the image for a larger version

To determine whether the anycast efficiency factor is consistent over time, we repeated the measurements once every hour for the 7-week period between 8 March and 26 April 2006. For every hour, we averaged α_i over all the test-boxes except tt103 and plotted the results. The results are in Figure 3. As can be seen, the average value of α is fairly constant over time.

4.1.5 Comparison with similar work

Our results show that the efficiency seen by TTM is quite good. This contrasts with existing work using similar methodologies which finds that BGP anycast has poor properties of locality [24, 4]. In particular, [4] examines the performance of the the J-root server, finding that that 40% of the clients used experienced values of α greater than 4. The authors suggest that the problem is due to to the fact that each J-root node is deployed in a POP of a different ISP and therefore the customers of each of those ISPs see as shortest path the node deployed in the POP of their ISP, regardless of their location. The same authors, in [3], study the anycast deployments of F-root and of the AS 112 project [25] with similar negative results. This suggest that the effects of anycast on latency are strongly dependent both on the type of anycast deployment used and on network topology and that further research is needed to model them.

Figure 4: Locations of TTM test-traffic boxes

4.2 Server-side performance

The client-side results we have just described show that the K-root deployment is very effecient. However, the mea-surements taken by TTM are biased: firstly, the client population is limited to a few tens of nodes, and secondly, as can be seen in Figure 4, the positions of the test-traffic boxes are biased towards Europe. Therefore, we applied the methodologies described in Section 3.1.2 in order to obtain a more complete picture of the quality of service provided to the client population as a whole.

4.2.1 Methodology

The global client population of K-root was obtained by analysing the packet traces of the global nodes. We examined 6 hours of data, for a total of 246,769,005 queries from 845,328 client IP addresses. From every node we then sent ping packets to these IP addresses using the custom pinger software developed by the authors³ .

In order to avoid loading the DNS servers themselves, the pings were run from the monitoring server in each node; to ensure the paths taken by the packets to and from the client were as similar as possible to the paths to the DNS servers, pinger was configured to use the same gateway towards the Internet as the DNS servers and to send the ping packets from using a source IP address on the same subnet as the servers’ internal addresses.

In order to minimise the likelihood of routing changes affecting the RTTs to the clients, our goal was to to ping the whole client population in as little time as possible while limiting server load. Therefore, pinger was written to parallelise pings using a configurable number of threads; for our experiments we used 500 threads sending out one packet per second each. The measurement was performed on 18 April 2006 and lasted approximately two and a half hours, during which each client was pinged five times in consecutive seconds. As can be seen in Table 2, almost half of the IP addresses queried did not respond to our pings, possibly because they were behind firewalls.

4.2.2 Results

The values of the anycast efficiency factor α are shown in Figure 5(a). As can be seen, only approximately 50% of clients choose the node with the lowest latency. These results are substantially worse than those observed by client-side measurements using the TTM network presented in Figures 1 and 2; this may be due to the fact that the TTM test-boxes are predominantly based in Europe, which is very well provisioned with two K-root global nodes.

The rightmost column of Figure 9 contains CDF plots of the loss factor βⁱ_n. The first two plots show that neither the LINX or AMS-IX nodes provide much benefit on their own. This result is surprising, because these are the busiest K-root nodes and the ones with the richest set of peering connections. The explanation for this is in Figure 5(b), which

³ The source code to pinger will be available on-line by the camera-ready deadline.

Figure 5: Evaluating K-root performance using server-side measurements: (a) CDF plot of the anycast efficiency factor α; (b) Combined loss factor of the AMS-IX and LINX nodes, showing that each provides little benefit on its own, but taken together they are important; (c) Loss factor of all global nodes except LINX, showing that the deployment of anycast brings substantial benefits to clients.

plots the loss factor of both nodes taken together. The graph clearly shows that although neither node provides much benefit on its own, taken together they are important; the low benefit each node has reflects the fact that the nodes are very similar from the point of view of clients and thus are redundant. The remaining three plots show that the Miami node provides moderate benefit for some clients, that the Tokyo node is the best node for a small population of clients, but those clients are very poorly served by the other global nodes, and that the Delhi node only provides marginal benefit.

These results are consistent with the calculated benefit values B_n of each node, shown in Table 3. As can be seen, there is a wide variation: the node providing the most benefit, Tokyo, has B =14 . 1 , while the node providing the least benefit, Delhi, has B =1 . 01 and thus its presence is only marginally useful. Taken together, LINX and AMS-IX have a high benefit value of 23.1 .

The server-side measurements also allow us to evaluate the benefit of deploying anycast as opposed to keeping K-root in only one location (before anycast was deployed, K-root only had one node at LINX; see Table 1). Figure 5(c) shows the combined loss factor of all the global nodes except LINX. As can be seen, more than 80% of clients have a loss factor greater than 1. This is also reflected by the combined benefit value of all the other nodes, B_A =18 . 8 .

4.3 Impact of node switches

To evaluate the effect of routing switches on queries, we analysed all the UDP queries seen by the global nodes of K-root in a given time period. We processed queries in chronological order, and for every query, we logged the client IP and which node it was sent to. If a given client IP was observed to query a different node from the one it had last queried, we logged a node switch.

We repeated the experiment twice, once in April 2005 and once in April 2006. The results are in Table 4. As can be seen, in these two samples node switches are fairly rare: the April 2006 results show only 150 , 938(0 . 06%) node switches; that is, 99 . 94% of all queries made were made to the same node as the querier had used for the previous query. Furthermore, of 845 , 328 client IP addresses seen, only 2 , 830(1 . 1%) switched node one or more times during the 24-hour period. These results are comparable with those in [12], which studied all the anycasted root servers using DNSMON [20] client-side probes and observed node switches in approximately 0 . 017% of queries. If we compare

the April 2005 data to the April 2006 data, we note a large increase in the percentage of node switches. This may be due to the larger number of routes competing in the global routing table leading to increased routing churn and more routing switches.

5 Routing issues

In this section, we examine various non-obvious routing issues that we observed during our analysis and that cause performance and reachability problems.

5.1 Performance degradation due to local nodes

Figure 2(a) shows that while local nodes can increase performance, they can also have the opposite effect. Of the 20 test-boxes whose best node is a local node, 16 (80%) have α_i < 1 and thus benefit from the presence of the local node, but 4 (20%) have α_i> 1 and therefore obtain worse performance by querying the local node than they would by querying the closest global node. The most obvious example of this behaviour is test-box tt89, whose performance is worse almost by a factor of 10. Queries from tt89, which is located in the UK, were being routed to the denic local node in Frankfurt, which had a response time of 28 ms, instead of the linx node in London, which had a response time of 3 ms (see Figure 6). When we analysed the results, the problem had been resolved and it was not possible to determine the cause of the problem with certainty. However, we believe the explanation is as follows: the path to the service prefix was announced by the Frankfurt node to an AS A which ignored the no-export community and propagated it to tt89’s AS B . AS B also received the announcement for the service prefix from the London node, but since this path was at least three ASes long due to prepending, it preferred the announcement it received from A and thus chose the Frankfurt node. Unfortunately, we note that in current operational practices it is not unusual for operators to propagate routes with the no-export attribute to their customers. We note that it is not the presence of the local node that is causing the problem here: rather, it is the use of prepending on the global nodes that is causing clients to query local nodes even when a global node is better connected. This is one of the disadvantages of the hybrid deployment adopted by K-root.

193.0.14.129 k2.denic 29 k2.denic 30 k2.denic 29 k2.denic 30 k2.denic 29
193.0.16.1 k1.linx 4 k1.linx 3 k1.linx 3 k1.linx 3 k1.linx 3
193.0.16.2 k2.linx 3 k2.linx 3 k2.linx 3 k2.linx 3 k2.linx 4
193.0.17.1 k1.ams-ix 12 k1.ams-ix 11 k1.ams-ix 12 k1.ams-ix 13 k1.ams-ix 13
193.0.17.2 k2.ams-ix 12 k2.ams-ix 13 k2.ams-ix 11 k2.ams-ix 12 k2.ams-ix 13

Figure 6: Raw latency results from tt89 on 2005-04-08 (times in ms)

5.2 Performance degradation due to different prepending lengths

Due to the fact that AS-path length is a relatively coarse metric, announcing different prepending lengths from different nodes can lead to performance problems. The outlier in Figure 1(b), tt103, has an efficiency factor of 208. tt103 is in Yokohama, Japan, and reaches the Tokyo node in 2 ms. However, as shown in Figure 7, it is using the Delhi node, reaching it in over 400 ms. Subsequent traceroutes later showed that the path to Delhi was also very inefficient, going through Tokyo, Los Angeles and Hong Kong in order to reach India. Inspection of the BGP tables of tt103’s AS, AS2497, show that all the AS-paths to the Tokyo node seen by tt103’s AS, AS2497, are four ASes long, while the AS-path to the Delhi node, 2200 9430 25152 25152, is three ASes long. This is due to the Tokyo node announcing a non-optimal prepending length of four.

193.0.14.129 k1.delhi 422 k1.delhi 416 k1.delhi 423 k1.delhi 428 k1.delhi 419
203.119.22.1 k1.tokyo 2 k1.tokyo 2 k1.tokyo 2 k1.tokyo 2 k1.tokyo 2
203.119.22.2 k2.tokyo 2 k2.tokyo 2 k2.tokyo 2 k2.tokyo 3 k2.tokyo 2
203.119.23.1 k1.delhi 422 k1.delhi 418 k1.delhi 421 k1.delhi 415 k1.delhi 426
203.119.23.2 k2.delhi 422 k2.delhi 428 k2.delhi 419 k2.delhi 417 k2.delhi 417

Figure 7: Raw latency results from tt103 on 2006-04-12 (times in ms)

Figure 8: Reachability problems with no-export. ISP1 and ISP2 peer with local nodes of K-root, but the no-export community prevents them from reannouncing the route to Customer.

5.3 Loss of connectivity due to no-export

The use of the no-export community can lead to scenarios in which a client may not be able to reach K-root at all. This problem, first reported by Randy Bush on an operational mailing list [7], is due to the problematic interaction of no-export with anycast. Consider Figure 8: the customer AS receives transit from two upstream providers, ISP1 and ISP2. If the two providers both peer with a local node of K-root and honour the no-export community, then their routers will be forbidden to announce the route to the customer AS. In this case, the customer AS will have no route to K-root and will be unable to reach it at all.

This problem was addressed in the K-root anycast deployment by announcing a less-specific prefix of the service prefix, the covering prefix, without no-export. If a BGP router has a route to the service prefix, it will use it, but if it does not, it will use the less-specific route to the covering prefix. This ensures that the service IP is reachable.

Note that the covering prefix announcement does not affect routing: once packets addressed to the service IP reach one of the upstreams, they will follow the route to the service prefix and will thus reach the local node seen by that upstream. Therefore, the covering prefix is announced from one node only (currently, the AMS-IX node).

6 Effect of anycast on server load

In this section, we present operational data on the K-root deployment with a view to understanding the effects of anycast on server load. First, we analyse server logs order to study the effects of K-root’s hybrid topology on load-balancing between nodes. We then examine the geographical distribution of the clients seen by each node.

6.1 Analysis of server logs

To determine the effects on server load of the deployment of new nodes, we analysed the server logs to obtain the daily average of the number of queries per second seen by each local node from January 2004 to April 2006. Our results are in Figure 10(a). As can be seen, deploying new local nodes does not decrease the number of queries processed, and thus the effectiveness, of existing local nodes. We would expect this to be the case: due to the small catchment areas of local nodes, the probability of a given network receiving announcements for more than one local node is very small. Note that we are assuming that the load offered to the K-root server is constant and independent of the nodes deployed, which is not strictly true due to the fact that many nameserver implementations select which server to query on the basis of past query latencies [26]. However, the addition of one local node to a root server system which already consists of tens of nodes is not likely to cause large shifts in traffic.

Figure 9: Client distribution of K-root global nodes. From left to right: query map; latency (ms); node benefit.

Figure 10: Geographical distribution of global node clients.

6.2 Geographical distribution of queries by node

To discover the geographical distribution of K-root clients we extracted a list of IP addresses from approximately six hours of packet traces and used geolocation software to map them to geographical coordinates. The number of queries and clients seen by each node in this interval is in Table 5. The geolocation software used was the the free GeoLite [13], which is claimed to be approximately 97% accurate at the country level and 60% accurate at the city level.

The results are in the left column of Figure 9 and aggregated in Figure 10. Every location containing one or more clients is mapped to a dot on the maps; the more IP addresses in a given area, the larger the dot. As can be seen from the maps, the LINX node is the one with the farthest reach: clients are spread all over the world as far as Australia, South America, South Africa, and the Far East. The AMS-IX has a slightly lower reach but is more concentrated in Europe. The clients of the Miami node are heavily concentrated in the Americas; this can also be seen in loss factor distribution, which shows a moderate number of clients gaining a moderate benefit, and in the latency distribution, which shows a m. The Tokyo node is very concentrated in Japan, probably due to the non-optimal prepending configuration already observed in Section 5.2. Finally, the Delhi node has very high latencies to most clients and is not substantially queried even in India.

7 Conclusions

In this paper we have presented methodologies for evaluating the performance of an anycasted DNS server that com-bine the analysis of packet traces and server logs with active measurements to evaluate both the benefit to clients of the anycast cloud as a whole and the benefit provided by individual nodes in the cloud. We have applied the methodologies to the K-root DNS server, combining the results with operational and geographical to obtain a comprehensive picture of the performance of K-root.

Our results show that anycast has good effects on latency, especially in Europe, which is very well provisioned with two K-root nodes, and that node switches, which have been identified in other work, are not currently a serious problem for K-root. Furthermore, the comparison of data gathered in 2005 on a deployment with two global nodes with data gathered in 2006 on a deployment with five global nodes shows that the K-root deployment has not yet hit the point of diminishing returns and that the deployment of future nodes could increase performance. Our results also show better performance than that observed in other work, suggesting that the types of anycast deployment and topologies used have a large impact on the effects of anycast and that further research is needed for a more general model.

In the future we would like to apply our methodologies to other root server clouds in order to determine the effects of different topologies on performance and to determine which topologies, if any, are optimal. Other problems we intend to work on are determining the effects of prepending schemes on anycast performance and developing a methodology for choosing the most effective location for a new node in the cloud.

Acknowledgements

The authors would like to thank Walter Willinger for his guidance and insightful comments and Daniel Karrenberg, Rene Wilhelm and Robert Kisteleki for useful discussion. Thanks go to Randy Bush for pointing out the loss of reacha-bility caused by no-export and Randy Bush and with Matsuzaki Yoshinobu for helping investigate tt103’s performance problems.

References

[1] J. Abley. Hierarchical anycast for global service distribution. ISC technical note 2003-1, 2003.

[2] J. Abley.A software approach to distributing requests for DNS service using GNU Zebra, ISC BIND 9 and FreeBSD. ISC technical note 2004-1, Mar. 2004.

[3] H. Ballani and P. Francis. IP anycast measurement study. Unpublished manuscript.

[4] H. Ballani and P. Francis. Towards a global IP anycast service (pdf). In Proceedings of SIGCOMM ’05, pages 301–312. ACM Press, Aug. 2005.

[5] P. Barber, M. Larson, M. Kosters, and P. Toscano.Life and times of J-ROOT. In Proceedings of NANOG 32, Oct. 2004.

[6] P. Boothe and R. Bush. DNS anycast stability: Some early results (pdf). In Proceedings of APNIC 19, Feb. 2005.

[7] R. Bush. Oh K can you see. NANOG mailing list archives, Oct. 2005.

[8] R. Chandra, P. Traina, and T. Li. BGP communities attribute. RFC 1997, Aug. 1996.

[9] T. Hardie. Distributing authoritative nameservers via shared unicast addresses. RFC 3258, Apr. 2002.

[10] B. Huffaker, M. Fomenkov, D. J. Plummer, D. Moore, and k claffy. Distance metrics in the internet. In IEEE International Telecommunications Symposium (ITS), Sept. 2002.

[11] B. Huffaker, D. Plummer, D. Moore, and k claffy. Topology discovery by active probing. In Symposium on Applications and the Internet (SAINT), Jan. 2002.

[12] D. Karrenberg. DNS anycast stability. In Proceedings of NANOG 34, May 2005.

[13] MaxMind LLC. GeoLite free country database. http://maxmind.com/ .

[14] P. Mockapetris. Domain names - concepts and facilities. RFC 1034, Nov. 1987.

[15] P. Mockapetris. Domain names  -implementation and specification. RFC 1035, Nov. 1987.

[16] P. Mockapetris and K. J. Dunlap. Development of the domain name system. In SIGCOMM ’88: Symposium proceedings on Communications architectures and protocols, pages 123–133. ACM Press, 1988.

[17] NLNet Labs. NSD nameserver. http://www.nlnetlabs.nl/nsd/ .

[18] C. Partridge, T. Mendez, and W. Milliken. Host anycasting service. RFC 1546, Nov. 1993.

[19] Planetlab. http://www.planet-lab.org/ .

[20] RIPE NCC. DNSMON project. http://dnsmon.ripe.net/ .

[21] RIPE NCC. Routing Information Service. http://www.ripe.net/ris/ .

[22] RIPE NCC. Test traffic measurements service. http://www.ripe.net/ttm/ .

[23] DNS root nameservers web site. http://www.root-servers.org/ .

[24] S. Sarat, S. Pappas, and A. Terzis. On the use of anycast in DNS (pdf). In ACM SIGMETRICS 2005, June 2005.

[25] P. Vixie. AS112 project. http://www.as112.net/ .

[26] D. Wessels. Update on anomalous DNS behavior. In Proceedings of NANOG 29, Oct. 2003.

[27] S. Woolf and D. Conrad. Identifying an authoritative nameserver. Work in progress.

IP source address spoofing is the practice of originating IP datagrams with source addresses other than those assigned to the host of origin. In simple words, the host pretends to be some other host.

This can be exploited in various ways, most notably to execute Denial of Service (DoS) amplification attacks that cause an amplifier host to send traffic to the spoofed address.

There are many recommendations to prevent IP spoofing by ingress filtering, e.g. checking source addresses of IP datagrams close to the network edge.

Most equipment vendors support ingress filtering in some form.

Yet recently, significant DoS amplification attacks have happened that would be impossible without spoofing.

This demonstrates that ingress filtering is definitely not deployed sufficiently. Unfortunately, there are no direct benefits to an Internet Service provider (ISP) that deploys ingress filtering. Also, there is a widely held belief that ingress filtering only helps when it is universally deployed.

At RIPE 52 in Istanbul, RIPE established a task force that promotes deployment of ingress filtering at the network edge by raising awareness and provide indirect incentives for deployment.

2. Charter

This task force shall

• raise awareness about this issue among network operators,
• inform about operational methods to implement ingress filtering,
• collect and channel requirements to equipment vendors where appropriate,

and

• seek ways to provide incentives and benefits to operators that do implement ingress filtering.

The task force shall have completed its task when

• network operators cannot reasonably claim not to be aware of the issue,

• information about ways to deploy ingress filtering are readily available

and

• any incentives that it may have devised have become available.

The task force shall be disbanded when these tasks have been completed or when there is consensus within RIPE that completion of the tasks is no longer realistic.

3. Time-Line

RIPE 52:

BoF and Establishment of Task Force Quickly draft and publish a RIPE recommendation citing existing work. Compile How-To with (pointers to) vendor documentation and operational experience reports. Establish liaison with MIT ANA Spoofer Project and promote their tools. Analyse Spoofer data for the RIPE region.

RIPE 53:

Published "RIPE Recommendation on Ingress Filtering". Published first edition of "Ingress Filtering How-To". Collect any critical requirements to be communicated to equipment vendors. First analysis of Spoofer data. Discuss possible incentive schemes. Revise and extend How-To. Devise possible incentive schemes like a "Source Address Clean" network logo, suitable RIPE Database attributes ...

RIPE 54:

Published second edition of "IP Source Address Filtering How-To". Further analysis of Spoofer data for the RIPE region. Launch of any incentive scheme. Implement incentive scheme. Monitor progress and effectiveness.

RIPE 55:

Evaluation and Disbanding of Task Force.

4. Contacts

The task force mailing list is <spoofing-tf@ripe.net>.
The web interface for subscriptions and the archive are at
http://www.ripe.net/mailman/listinfo/spoofing-tf .

The task force is co-chaired by Nina Hjorth Bargisen (NINA1-RIPE) and Daniel Karrenberg (DK58).

A web page detailing current activities will be set up.

5. References

RFC2827 aka BCP38
Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Address Spoofing
http://www.ietf.org/rfc/rfc2827.txt

SSAC004
Securing the Edge
http://www.icann.org/committees/security/sac004.txt

SSAC008
DNS Distributed Denial of Service (DDoS) Attacks
http://www.icann.org/committees/security/dns-ddos-advisory-31mar06.pdf

ripe-66
RIPE Task Forces
ftp://ftp.ripe.net/ripe/docs/ripe-066.txt

MIT Spoofer Project
http://spoofer.csail.mit.edu/

RFC3024 - Reverse Tunneling for Mobile IP, revised
ftp://ftp.rfc-editor.org/in-notes/rfc3024.txt

Due to heavy graphic use, this RIPE Document is best read in .pdf format.

On request, we will supply a .html version.

Introduction

DNSSEC [RFC 4033,RFC 4034,RFC 4035] provides authentication and integrity checking to the domain name system. DNS Resource Records (RR) are signed using private keys. The signatures are published in the DNS as RRSIG resource records. The public keys that are needed to validate the signatures are published as DNSKEY resource records.

In addition to the DNSKEY and RRSIG RRs, DNSSEC introduces the NSEC RR that is used to prove the non-existence of data, and the DS RR that is used to delegate signing authority from one zone to another.

The introduction of these records causes zones to grow significantly. It is expected that this growth would have an effect on disks, memory and bandwidth usage. Besides DNSSEC aware servers have to do special processing to include the appropriate DNSSEC data. This might increase CPU load.

In this paper, we have set out to address the following question: What would be the immediate and initial effect on memory, CPU and bandwidth resources if we were to deploy DNSSEC on k.root-servers.net and ns-pri.ripe.net?

We performed a number of experiments in a test lab. Focusing on the immediate effects we used packet traces captured from the ns-pri.ripe.net and k.root-servers.net production servers. These traces were replayed --mimicking real-time behaviour-- in the lab. The name server answering the queries carried zones that were signed with various sized keys. We measured memory consumption, packet counts and performed bandwidth measurements. These metrics in addition to some observations about the data contained in the traces provided enough information for provisioning the server infrastructure for DNSSEC.

In section 2 we describe the lab environment. In section 3 we perform an analysis of the query traces that were used in the experiment. The EDNS0 properties[rfc2671] of these traces is an important factor in the final bandwidth usage.

In section 4 we describe the impact of loading signed zones on the memory usage of the name servers and provide the parameters that can be used to estimate memory increase when loading signed zones.

In section 5 we assess the impact on CPU load when serving secured zones. Section 6 focuses on the bandwidth and the packet statistics for the various measurement configurations.

In section 7 we discuss the results and provide recommendations.

Appendix B provides a somewhat academic taxonomy of the replies for some of the experiments. We look at size distribution and discuss some of the phenomena that can be observed in these size distributions. This section contains the count of replies with the TC bit.

The paper by [ADF05] contains a similar analysis. Their experiments were more extended. They involved a caching forwarding name server. Their analysis used traces for which all the queries had been modified to include the EDNS0 OPT RR with the DO bit set. They measured the 'per packet' overhead. In this paper we will divert into a similar measurement -- not through the modifications of the query but through the modification of the name servers. We also measure bandwidth increase instead of per packet increase.

We assume the reader is familiar with DNS and DNSSEC jargon.

The figures and graphs are clearest when viewed in colour.

The Test Setup

The DISTEL Lab

The tests are performed on the Domain Name Server testing lab "DISTEL" test lab [KYLK02]. This lab was designed and implemented by the RIPE NCC to perform regression tests during the development of NSD. It is currently maintained by NLnet Labs.

The lab (Figure 1) consists of three identical machines containing AMD Athlon(TM) XP 2000+ (1670.46-MHz 686-class) CPUs. Two machines, labelled player and recorder contain 256 MB of memory. One machine, labelled server, contains 1.5GB of memory and acts as DNS name server. All machines run FreeBSD 6.0-CURRENT (13 June 2005).

The machines are connected through a 100baseT full duplex Ethernet network. The interfaces on that network are configured with RFC1918 addresses. The experiment is controlled through the player.

Figure 1: The DISTEL Test Lab

The DNS server has a host route configured for the player and has its default route configured to recorder. recorder has host routes for the other two machines and a default route to /dev/null.

Experiments are performed by taking libpcap traces from the production machines. After modifying the destination IP and MAC addresses to be those of the server the traces were replayed using a modified version of tcpreplay. The modifications to tcpreplay were done to avoid packet burst caused by problems with usleep having limited resolution and sometimes skipping a beat. See [KYLK02] for details.

Because of the default route configured on server the answers end up at recorder on which a tcpdump is collecting the answers before they end up at /dev/null.

In this setup, we can only study the effects of UDP traffic. The server used in the experiment has slightly lower hardware specifications, and runs a different operating system from the ns-pri.ripe.net and k.root-servers.net production systems.

The Server Software

For these experiments, the DNS sever ran BIND 9.3.1[BIND] and NSD 2.3.0 [NSD]. BIND was compiled with open-ssl and without multi threading ^FN, NSD 2.3.0 was compiled with the default options.

As well as the stock version of these name servers we used modified versions of both of the servers for a subset of the experiments. The modifications were designed to make the servers behave as if every query that had an EDNS0 option without the DO bit set actually had the DO bit set. It also acted as if every query without EDNS0 options actually contained an EDNS0 packet advertising 2048 UDP defragmentation capabilities of the query and with the DO bit set.

named was configured without recursion or any logging ^FN.

The Zone Configuration

We performed the experiment on two configurations. One configuration
[4]ns-pri.ripe.net and one that was to mimic k.root-server.net.

For the ns-pri.ripe.net type experiments, we used the configuration from 15 June 2005. At this date ns-pri.ripe.net was authoritative for zones like 193.in-addr.arpa (/8 reverse zones), 000.193.in-addr.arpa (/16 reverse zones) and their IPv6 variants whose content is dominated by delegation NS RRs 3.94 * 10⁵ in total). Besides these 'delegation-only domains' there are a number of /24 reverse zones and a couple of small forward zones that relate to the RIPE NCC infrastructure. These account for about 0.05*10⁵ RRs roughly equally spread between PTR, CNAME, A and other resource records.

For the k.root-servers.net type experiments, we created a configuration where the server was authoritative for the root zone with SOA serial 2005070400. The server was not authoritative for other zones like the 'arpa' and 'root-servers.net' that are normally hosted by k.root-servers.net.

Zone Signing

We created a 2048 bits RSASHA1 key signing key (KSK) and two zone signing keys (ZSK) varying from 512 to 2048 bits. The ZSKs and KSK were included in the zone before it was signed with one ZSK and one KSK, using dnssec-signzone from the BIND 9.3.1 distribution. In the signed zone all RR sets are signed with one ZSK. Only the DNSKEY RR set is signed with two keys - the KSK and one ZSK.

Having two ZSKs in the DNSKEY RR set is expected to be a common situation for pre-publish zone signing key rollovers as in section 4.2.1 from [KG05]. In the pre-publish ZSK rollover model, the DNSKEY RRset grows during a ZSK rollover while the number of signatures over the RR sets in the zone remains constant.

Properties of the Query Traces

To perform the experiment, we obtained traces from the production servers. The traces we used contained UDP packets directed at port 53 of the server machines. The amount of data was roughly equivalent to about 10 minutes elapsed time and was taken at a random time for which the query stream did not seem to show anomalous behaviour.

We used two traces. One trace from ns-pri.ripe.net and one from
[4]k.root-servers.net. Table 1 summarises the properties of the traces.

The first column of the table lists the identifier used for the trace during the experiment. The second column lists the time we started recording the trace. The 3rd column the amount of UDP packets to port 53 contained in the trace. The 4th column lists the amount of DNS packets that the analysis script interprets as DNS packets. The packets that have their opcode set to "QUERY" and have not been truncated and do not have their query response flag set are probably bona-fide queries. We analysed those remaining packets on their EDNS0 content. The results are in Table 2 and the pie charts in Figure 2.

The left pie charts show the distribution between queries without the EDNS0 extensions, with the EDNS0 extension but without the DO-bit set and with the EDNS0 extension and with the DO bit set. The middle pie charts show the UDP defragmentation sizes advertised by the clients in the set of packets with an EDNS0 extension. The pie charts at the right show the sizes for those EDNS0 packets with the DO bit set.

The EDNS0 size distributions clearly differ for the query streams against the k.root.servers.net (top) and ns-pri.ripe.net (bottom). While the contribution of the "4096" size to the total of EDNS0 packets is roughly one third for all traces there is a distinct difference between the ratio of 1280 versus 2048 EDNS0 sizes. EDNS0 size 1280 makes up for almost 15% of the EDNS0 packets for the k.root trace while for the ns-pri traces, the contribution is less than 1 %. The EDNS0 size distribution is not the same for the queries with and without the DO bit set. EDNS0 size 1280 is not present for these queries.

The properties of the query streams clearly demonstrate selection effects. We have not investigated what causes the difference between the properties of the queries to k.root-servers.net and ns-pri.ripe.net. If we were to undertake such investigation, our working hypothesis would be that most of the queries to ns-pri.ripe.net are targeted to sub-domains ofin-addr.arpa and that those queries originate from environments where there is a preference for certain name server implementations.

We were also interested in the scenario for which all queries have the DO bit set. We simulated this by modifying the NSD code, to cheat the server into believing that queries with EDNS0 but without the DO bit had their DO bit set, and that queries without the EDNS0 extension had an EDNS0 section with the DO bit set and an EDNS0 size of 2048. [ADF05] chose to use the minimum value of 1220 octets. We use 2048 because that is the minimum value that we've seen in the captured queries that have the DO bit set.). We only performed measurements with this modified name server using the k.root-servers.net configuration. These experiments are marked ``k.modified'' and referred to as experiments on the ``modified server''.

Figure 2: EDNS0 Properties for the k.root (top) and ns-pri Traces (bottom).

Figure: VMS for Different Key Sizes
Left column on FreeBSD. Right column on Linux 2.6.10, top row measurements for named 9.3.1 and bottom row measurements for nsd.

Figure 4: Bandwidth as Function of Key Size for Trace ns-pri

Figure 5: Packet Counts as Function of Key Size For Trace ns-pri

K.root Traces Figure 6: Bandwidth Increase as Function of Key Size for the k.root Trace Against named 9.3.1 and Modified named 9.3.1   Figure 7: Bandwidth Increase as Function of Key Size for the k.root Trace Against nsd 2.3.0 and Modified nsd 2.3.0   Bandwidth increase due to zone signing for the root is shown in Figures 6 and 7. The egress packet counts are plotted in Figures 8, and 9. What can be observed from these plots is that the packet counts on the unmodified versions do not show significant offsets. All lines overlap. The response packets from the modified named, in the left graph of Figure 8, grow above the Ethernet MTU. This shows through the offsets in the packet counts. All response packets from the modified nsd have sizes lower than the Ethernet MTU therefore all lines in Figure 9 overlap. Figure 8: Packet counts as function of key size for trace k.root against named 9.3.1 and modified named 9.3.1   Figure 9: Packet counts as function of key size for trace k.root against nsd 2.3.0 and modified nsd 2.3.0 Discussion Because the number of packets with the ``DO'' bit set is relatively low, there would be no significant impact on the bandwidth consumption for k.root-servers.net if a signed root zone were to be served today. Even in a worst-case scenario, when all queries to the root would have the ``DO'' bit set, the bandwidth usage would only grow by a factor 2 to 3 depending on key size and implementation used. For ns-pri.ripe.net signing all its zones would increase bandwidth use by a factor 2 to 3 depending on the key size. The increase in CPU and memory usage will not cause problems on the production system. It is safe to conclude that the impact of DNSSEC deployment on CPU load is of no concern. The impact of memory consumption can easily be estimated from the zone content. The growth in memory consumption is significant, but we do not think that the total amount of memory needed will be an issue for most authoritative servers running on commodity hardware; when serving of the order of 106 resource records the four gigabyte limit on 32bit Intel architectures may become a barrier. The impact on bandwidth usage is much harder to estimate.   Estimating Bandwidth Usage The effects of enabling DNSSEC is depends on many variables. These are, roughly in order of significance: the fractions of queries with the ``DO'' bit set;   the inclusion of a DNSKEY RRs in the additional section; (See the recommendation below.)   the amount of queries for existent and non-existent domain names; (The size difference between an unsigned Name Error packet and a signed Name Error packet is significant, also see [ADF05].)   the size of the ZSK and KSK. The effect of the size of the KSK is not measured here, but it makes up a significant fraction of the DNSKEY RR set and its signatures;   the amount of KSKs and ZKSs in the DNSKEY RRset; (Depending on the rollover scheme used there can be multiple DNSKEY RRs in the zone and multiple RRSIGs over these keys. If multiple algorithms are used, which could be the case when a transition from RSASHA1 to ECC is made, the size of these RR sets can grow quite significantly.)   the label depth of the records in the zone and therefore the need to include a second NSEC RR, with corresponding RRSIG, to prove the non existence of wildcards;   Because of these variables, there is no easy method to determine the impact of signing zones in generic environments. The two configurations we tested were biased towards ``delegation only'' zones. For a delegation, two RRs are added to positive responses when serving a signed zone, an NSEC or DS RR and a RRSIG. When serving ``end-node'' data only a RRSIG is added for positive responses. When estimating the impact of DNSSEC deployment, you should first look at the fractions of queries that have the DO bit set. If that fraction is small the impact of DNSSEC deployment will not be significant.   Effects Not Measured These experiments only provide insight to the first order effects. We do not know what happens on the Internet when DNSSEC answers are returned to the clients. The following scenarios seem likely:   Scenario A - A client behind a middle box (e.g. a firewall) sets the DO bit. The query crosses the middle box and is answered by the server. The answer that contains DNSSEC information does not cross the middle box, simply because the middle box does not implement DNSSEC or is not configured to deal with fragmented UDP on port 53.   scenario B - The Client sets the DO bit, but does not know what to do with the DNSSEC information in the answer and continues to query.   Scenario A is most likely. The EDNS0 specifications [rfc2671] do not demand that a resolver should retry without EDNS0 when there has not been an answer from an EDNS0 query. However, BIND developers have explained that BIND9 will re-query without EDNS0 and will cache the EDNS0 capability of the server. In other words, BIND9 resolvers will fall back to non-EDNS0 behaviour, resend their query without the DO-bit and receive non-DNSSEC answers FN We are not aware of any clients that set the DO bit and would not know how to process the DNSSEC replies. Appendix A provides an overview of which type of clients queried k.root-servers.net. Most of the DO queries are being sent by BIND servers. Only an analysis of query patterns of deployment on signed zones on the Internet can tell us if we should worry about non-linear effects.   Recommendation The distinct difference between named and nsd is that the latter does not add DNSKEY RRs and related RRSIGs in the additional section for a Name Error response. Both servers comply to the specification since a security-aware authoritative name server [...] MAY return the zone apex DNSKEY RRset in the Additional section (section 3.2.1 [rfc4035]). This different behaviour is the main cause for the difference in bandwidth consumption between the two implementations. It can be argued that at the start of DNSSEC deployment, while the amount of validation DNS clients is small, there is little need to add the DNSKEY RR set to the additional section. Most DNS clients that set the DO bit will not use the information anyway and the minority of clients that do need the key information can afford the extra query. Our recommendation is to make the inclusion of DNSKEY RRs in the additional section, a configurable option, at least during early deployment of DNSSEC. Stripping the RRSIG RR set from the additional section without stripping the DNSKEY RRs increases bandwidth consumption, while validators that need the DNSKEY RRs for validation will still need to re-query to obtain the missing signatures.   Conclusion Serving signed zones has little impact on CPU resource use. The impact on memory usage is predictable and well within the specification of the production machines that are authoritative for the zones we used in this experiment. Bandwidth usage increase can be significant, an increase by a factor of 2 to 3 was measured. To reduce the impact of bandwidth consumption, we recommend configuring your name server to not include DNSKEY RRs in the additional section.   Appendices   DNS Clients We took a sample of 3927 unique IP addresses from the traces and used a DNS fingerprinting tool [AS] to see what type of clients set the DO-flag. We could determine the client type for 2373 of the IP addresses.   Table 5: Implementations Setting the DO Bit Client implementation no. ATOS Stargate ADSL 1 BIND 8.3.0-RC1 - 8.4.4 2 BIND 8.3.0-RC1 - 8.4.4 [recursion enabled] 8 BIND 8.3.0-RC1 - 8.4.4 [recursion local] 4 BIND 9.0.0b5 - 9.1.3 [recursion local] 3 BIND 9.1.0 - 9.1.3 17 BIND 9.1.0 - 9.1.3 [recursion enabled] 71 BIND 9.2.0a1 - 9.2.0rc3 [recursion enabled] 4 BIND 9.2.0a1 - 9.2.2-P3 [recursion enabled] 29 BIND 9.2.0a1 - 9.2.2-P3 [recursion local] 1 BIND 9.2.0rc4 - 9.2.2-P3 [recursion enabled] 7 BIND 9.2.0rc7 - 9.2.2-P3 173 BIND 9.2.0rc7 - 9.2.2-P3 [recursion enabled] 836 BIND 9.2.0rc7 - 9.2.2-P3 [recursion local] 47 BIND 9.2.3rc1 - 9.4.0a0 [recursion enabled] 828 ISC BIND 9.2.3rc1 - 9.4.0a0 309 Microsoft Windows 2000 3 Microsoft Windows 2003 1 Microsoft Windows NT4 1 MyDNS 18 PowerDNS 2.9.4 - 2.9.11 4 Runtop Implementation 3 TinyDNS 1.05 2 totd 1 No match found 325 TIMEOUT 1229   This table only provides an indication of the resolvers that queried the root server. The fingerprinting was done at a different time to when we made the original query. This could explain the appearance of implementations that, as far as we know, do not have a DNSSEC support. We performed a visual inspection on the queries sent by implementations other than BIND. These packets were all valid DNS packets with EDNS0 OPT RRs in the additional section that were 'properly' formatted i.e. they had no other flags than the DO-flag set, advertised 2048 or 4096 sizes, etc. As mentioned in 7.2 the behaviour of BIND9 in situations where middle boxes drop replies is well understood.   Analysis of the Recorded Replies The replies recorded by the recorder contain much information. Since we tried to limit the scope of this paper and because of the lack of dedicated tools, we did not correlate the queries that were sent with the answers received. Neither did we investigate the variations in response times for different key sizes. In Table 6, we present the core parameters of the recorded reply traces. In the second column of each of the four sub-tables we list the amount of DNS packets we counted in the reply trace. The third column lists how big a fraction this is from the number of DNS packets that we've listed in the third column of Table 1. The decreasing percentage of DNS packets received for growing key sizes is not caused by the servers dropping packets. The analysis script, that was written to measure first order effects, does its own IP packet defragmentation. It is likely that it fails to to do defragmentation in all cases where IP fragmentation has occurred. The fourth column indicates the amount of packets with the truncated (TC) bit set. What can be seen from this table is that the introduction of DNSSEC will cause packet truncation for about one packet each second. Wider application of EDNS0 would reduce truncations for unsigned zones (e.g. the k.modified query has 0 truncated packets compared to 0.5k packets truncated for replies from the unmodified server.) The fifth column presents a count of the number of packets that had at least one RRSIG resource record in any of the sections of the packet.   Table 6: Core Characteristics of the Recorded Response Traces ns-pri against named 9.3.1 ZSK DNS TC with size packets set RRSIGs 0000 1703986 (99.91%) 0 0 0512 1703993 (99.91%) 199 475803 0768 1703972 (99.91%) 199 475837 1024 1703837 (99.90%) 199 475786 1280 1704008 (99.91%) 205 475828 1536 1703957 (99.91%) 205 475829 1792 1704119 (99.92%) 205 475843 2048 1703858 (99.90%) 209 475771   k.root against named 9.3.1 ZSK DNS TC with size packets set RRSIGs 0000 2235229 (99.80%) 0 0 0512 2233248 (99.71%) 518 226756 0768 2228432 (99.50%) 548 226208 1024 2230825 (99.61%) 550 226496 1280 2228756 (99.51%) 583 226189 1536 2229255 (99.54%) 603 226192 1792 2227160 (99.44%) 603 225811 2048 2230531 (99.59%) 628 226218   k.root against modified named 9.3.1 ZSK DNS TC with size packets set RRSIGs 0000 2234747 (99.78%) 0 0 0512 2231873 (99.65%) 1 2227936 0768 2229299 (99.54%) 68 2225284 1024 2227767 (99.47%) 75 2223773 1280 2227267 (99.45%) 119 2223217 1536 2225612 (99.37%) 648 2221042 1792 2226255 (99.40%) 684 2221640 2048 2225794 (99.38%) 705 2221160   k.root against nsd 2.3.0 ZSK DNS TC with size packets set RRSIGs 0000 2239770 (100.01%) 518 0 0512 2236494 (99.86%) 520 226882 0768 2235973 (99.84%) 549 226730 1024 2237481 (99.90%) 550 226853 1280 2237250 (99.89%) 585 226796 1536 2237242 (99.89%) 606 226809 1792 2236459 (99.86%) 610 226782 2048 2237055 (99.88%) 634 226749   k.root against modified nsd 2.3.0 ZSK DNS TC with size packets set RRSIGs 0000 2240141 (100.02%) 0 0 0512 2238062 (99.93%) 0 2234120 0768 2238556 (99.95%) 0 2234612 1024 2238696 (99.96%) 0 2234752 1280 2237768 (99.92%) 0 2233825 1536 2236664 (99.87%) 519 2232201 1792 2235883 (99.83%) 519 2231424 2048 2234545 (99.77%) 517 2230096   Size Distribution We measured the sizes of the packets in the response traces which had OPCODE QUERY and did not have the TC bit set in the header.   Size Distributions for ns-pri Experiment Figure 10 shows the size distribution of four different key sizes on a linear scale. In this plot, you can distinguish distinct peaks that we will refer to as harmonics. To study these more closely, we created a plot with a logarithmic scale in Figure 11. In this plot, we marked a number of the harmonics. The properties of these harmonics, that are specific for the ns-pri setup are described below. These harmonics are defined by observed peaks. The amount of responses (the signal) in these peaks is determined by zone content and query distributions and are therefore specific to the system under observation.   Figure 10: DNS Packet Size Distributions for ns-pri Traces Against named 9.3.1   Figure 11: Logarithmic DNS Packet Size Distributions for ns-pri Traces Against named 9.3.1 Table 7: Harmonics Found in the Signed Responses for the ns-pri Trace. Also see Figure 11 id 512 1024 1536 2048 1 289 353 385 449 2 530 733 925 1117 3 1233 1536 1837 2193 4 1380 1764 2158 2542 a 1619 1939 b 1590   Below we describe the properties of some of the harmonics found in the ns-pri replies.   Harmonic 1 is caused by packets that contain delegations in reverse address space that contain two NS, one NSEC and one RRSIG resource record in the authority section and have an empty answer and additional section.   Harmonic 2 is caused by by packets that contain a delegation for a /16 in-addr.arpa zone for which ns-pri is an authoritative server. So, in addition to the two NS one NSEC and one RRSIG resource records in the authority section the additional section contains an A and AAAA RR for ns-pri.ripe.net plus the RRSIGs over those records.   Harmonic 3 is caused by Name Error responses (NXDOMAIN). These packets contain a SOA, an NSEC and their RRSIG Resource records in the authority section and the DNSKEY RR set (containing three keys) with its RRSIGs (one with the KSK and one with the ZSK).   Harmonic 4 is also caused by Name Error responses. These include the SOA and two NSEC RRs with their RRSIGs in the authority section, and the DNSKEY RRs with RRSIGs in the additional section. The inclusion of two NSEC RRs is needed to deny the existence of wildcards.   Harmonic A is a harmonic 4 type packet with the RRSIGs over the DNSKEY RR set in the additional section removed.   Harmonic B is a harmonic 3 type packet with the RRSIGs over the DNSKEY RR set in the additional section removed.   The difference between Harmonic 3 and 4 is that Harmonic 3 contains a NSEC RR that immediately proves the non existence of a 'closer encloser' like in ;; QUESTION SECTION (1 record) ;; 215.103.43.84.in-addr.arpa. IN PTR (...) 9.42.84.in-addr.arpa. 7200 IN NSEC 128.43.84.in-addr.arpa ( NS NSEC RRSIG ) while Harmonic 4 packets need two NSECs for such proof as in ;; QUESTION SECTION (1 record) ;; 47.112.102.80.in-addr.arpa. IN PTR (...) 80.in-addr.arpa. 7200 IN NSEC 0.80.in-addr.arpa ( DNSKEY NS NSEC RRSIG SOA ) 100.80.in-addr.arpa. 7200 IN NSEC 104.80.in-addr.arpa ( NS NSEC RRSIG ) See section 3.1.3.2 of [rfc4035] for details. The harmonics do not always contain the same amount of packets. As soon as the size of packets of a given harmonic become larger than that advertised by a significant fraction of the clients, some of the signal from that harmonic is transferred to another one. For instance, at ZSK size 1536 signal from Harmonic 4 is transferred to Harmonic A since the harmonic occurs at a size larger than 2048. On the other hand there is no sign of an equivalent to harmonic b since harmonic 3 is still below the 2048 size limit. Since the amount of signal is hard to judge from these logarithmic plots, we show the fraction of the total amount of packets that is smaller than a given size for the different ZSK sizes in Figure 12. In this kind of plot, the harmonics can be identified by the steep rises in the curves. You can clearly see the transfer of signal for ZSK sizes of 1536 bits and larger. The last step in the graph corresponds to Harmonic 4. For smaller keys this harmonic accounts for slightly less than 10% while for larger keys some about half of these packets are moved to Harmonic A. Figure 12: Cumulative DNS Packet Size Distributions for ns-pri Traces Against named 9.3.1   Size Distributions for k.root Experiments For each of the four experiments we performed using the k.root trace we created the various size distribution plots (Figure 13, 14 and 15). In these plots, the left column presents the measurements for the named 9.3.1 and the right column the measurements for nsd 2.3.1. The top row shows the effect of replaying the k.root trace as it stands, the bottom row shows the effects of replaying the trace against the modified versions of the server. Since the fraction of packets in the k.root trace with the DO bit set is roughly 10%, the effects of signing are not as extreme as for the ns-pri trace. To study the effect of signing on packet content, we use the output of the modified named server and define a number of harmonics. These harmonics are listed in Table 8 and indicated in the bottom left plot of Figure 14.   Figure 13: Size Distribution for Different ZSKs of Response Packets after Playing the k.root Trace Against named 9.3.1 (top left), nsd 2.3.0 (top right), Modified named 9.3.1 (bottom left) and Modified nsd 2.3.0 (bottom right).   Figure 14: Logarithmic Size Distribution of Response Packets after Playing the k.root Trace Against named 9.3.1 (top left), nsd 2.3.0 (top right), Modified named 9.3.1 (bottom left) and Modified nsd 2.3.0 (bottom right).   Table 8: Harmonics Found in the Signed Responses for the k.root Trace Against the Modified named 9.3.1 name server. Also see Figure 14 id 512 1024 1536 2048 1 573 630 702 768 2 653 717 781 845 3 901 1215 1546 1847 4 1130 1464 1770 2104 5 1256 1645 2054 2408 a -- 960 1152 -- b -- 1020 1272 1518 x -- -- -- 1036   Below we describe the properties of some of the harmonics found in the replies from the modified named 9.3.1 server.   Harmonic 1 are delegations to the arpa domain containing 12 NS RRs, on NSEC and one RRSIG over the NSEC in the authority section and 12 A type glue RRs in the additional section. This harmonic would not occur on the production system as [4]k.root-servers.net is authoritative for the 'arpa' domain. It would return a delegation to the relevant subsequent domain or return a name error.   Harmonic 2 are delegations to the gtld-servers. The authority section contains 13 name servers, one NSEC and one RRSIG. The additional section contains 13 A type glue RRs and 2 AAAA type glue RRs.   Harmonic 3 are typically Name Error responses. They contains the root's SOA, two NSEC RR and their RRSIGs in the authority section and the signed DNSKEY RR without a RRSIG RR set in the additional section. The two NSEC RRs are needed to prove non-existence of the exact match (pointing from NR. to NU.) and one to prove non existence of a wildcard. If the RRSIGs had been included, these packets would be included in Harmonic 5 This harmonic can not be distinguished in the responses from nsd (bottom right plot). nsd does not include the DNSKEY RR set and the data remains hidden between the majority of queries in the band around 500 octets size. This harmonic can also not be distinguished in the responses from the unmodified name server for 512 bit ZSK (see the plot on the top left). They are significant in plot for the modified server. The third harmonic in the 512 ZSK measurements is mostly caused by queries for [4] _ldap._tcp.dc._msdcs.ntserver. IN SRV. This harmonic appears because on the modified server the original EDNS0 size is honoured and a significant fraction of the clients advertise that they can handle 1280 sized responses.   Harmonic 4 are typically responses to . IN A queries. The responses typically contain the SOA and an NSEC RR (owned by `.') and their RRSIGs in the authority section and the signed DNSKEY RR set in the additional section.   Harmonic 5 are typically Name Error responses that contain the root's SOA, two NSEC RR and their RRSIGs in the authority section and the signed DNSKEY RR with their RRSIG RRs in the additional section.   Harmonic A only occurs in the plots for ZSKs 1024 and 1596. Packets in this harmonic are typically responses to the priming query . IN NS. With the roots NS RRset and its RRSIG in the answer section and a DNSKEY RR set without RRSIG in the additional section. This harmonic appears and disappears because it is a by-product of the 1280 size honoured by the modified server.   Harmonic B are typically Name Error responses to queries for records in numerical top level domains with only one NSEC RR and corresponding RRSIG in the authority section. (The NSEC that denies existence of numerical TLDs also denies the existence of the `*') for ZSK 2048 Harmonic B also includes the packets from Harmonic 4 with their signatures stripped.   Harmonic X only occurs responses from the zone signed with a 2048 bit ZSK. These packets typically contain a Name Error response. It has a two NSEC RRs proof for non existence in the authority section. It does not have DNSKEYs in the additional section. These are the packets that did not fit in Harmonic 3. It is Harmonic X that shows the distinct peak in packet distribution for 2048 ZSK zones served by the modified nsd 2.3.0 server (bottom right plot of figure 14. For smaller key sizes this harmonic is convolved with other harmonics.   In the figures for the modified nsd responses there is one distinct peak at 1625 and 2009 octets for the 512 and 1024 bits ZSK distributions(Figure 14, bottom left plot, second and third frame from the bottom). Those peaks are caused by responses to the . IN ANY query. The amplitude of the peak is 518 packets. The reason for this peak not to occur for the 1592 bits ZSK responses is that these responses do not fit and the packets are truncated. This is confirmed in Table 6 where these packets show up as being truncated. The peak also shows in the 512 ZSK graph (at 1852 octets) and occurs at 1801 octets in the 1024 ZSK graph for named. The content - or the sizes - of the responses to the ANY query are different. The named comes with an empty additional section while nsd adds A glue records to the additional section. These peaks do not occur in the unsigned zone either. We did not include the DNSKEY RRset in the the unsigned version of the zone. The response to the ANY query then only measures 296 octets for named and 493 octets for nsd, the latter including glue. The distributions for the unsigned zones differ slightly between the unmodified and modified servers (compare the bottom frames of the same row). This is caused by the fact that the modified treats all clients as if they are able to deal with responses of 1280 bytes or more. The unmodified server will need to honour the 512 byte size limit for the 65.5% of the queries that do not have the EDNS0 extension. Figure 15: Cumulative Packet Sizes for Replies From the k.root Traces Figure 15 shows the cumulative size distributions. The graphs indicate that the amount of signal in the harmonics is rearranged for larger key sizes. The most important conclusion that can be drawn from the graph is that when the DNSKEY RRs with their signatures are not included in the responses, the nsd behaviour packet sizes will not grow beyond 1259 octets, well beyond the MTU on Ethernet networks.   Acknowledgements Thanks Daniel Karrenberg for the design and implementation of the DISTEL lab, proofreading of the manuscript and the Vlaai FN during his instructions on how to operate the lab. Erik Rozendaal for coding the modifications to NSD. Mark Andrews for explaining the EDNS0 behaviour for BIND. People that helped me by asking clever questions or suggesting directions are Joao Damas, Lorenzo Colitti and Mark Santcroos. Adrian Bedford and Jaap Akkerhuis for proofreading the manuscript. Most of this work was done while I was employed by the RIPE NCC.   Bibliography   ADF05 Bernhard Ager, Holger Dreger, and Anja Feldmann. Exploring the Overhead of DNSSEC, April 2005. http://www.net.informatik.tu-muenchen.de/~anja/feldmann/papers/dnssec05.pdf, Work in progress.   AS Roy Arends and Jakob Schlyter. fpdns - Fingerprinting DNS servers. FPDNS webpages. http://www.rfc.se/fpdns/.   BIND ISC BIND nameserver webpage. http://www.isc.org/index.pl?/sw/bind/.   KG05 Olaf Kolkman and Miek Gieben. DNSSEC Operational Practices <draft-ietf-dnsop-dnssec-operational-practices-05.txt>, September 2005. http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-operational-practices-05, DNSOP WG Internet draft, drafts are subject to change and have a limited lifetime. See also the Internet-Drafts Database Interface   KYLK02 Daniel Karrenberg, Alexis Yushin, Ted Lindreen, and Olaf Kolkman. DISTELDomain Name Server Testing Lab, November 2002. http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-dnr-distel/.   NSD NLnet Labs NSD nameserver webpage. http://www.nlnetlabs.nl/nsd/.   rfc2671 P. Vixie. RFC 2671: Extension Mechanisms for DNS (EDNS0). IETF, August 1999. ftp://ftp.ietf.org/rfc/rfc2671.txt.   rfc4033 R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. RFC4033: DNS Security Introduction and Requirements. IETF, March 2005. ftp://ftp.ietf.org/rfc/rfc4033.txt.   rfc4034 R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. RFC4034: Resource Records for the DNS Security Extensions. IETF, March 2005. ftp://ftp.ietf.org/rfc/rfc4034.txt.   rfc4035 R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. RFC4035: Protocol Modifications for the DNS Security Extensions. IETF, March 2005. ftp://ftp.ietf.org/rfc/rfc4035.txt. Note: URLs may be subject to change. Document history: This RIPE document is based on of the manuscript source.   Footnotes ... Kolkman (olaf@nlnetlabs.nl)mailto:olaf@nlnetlabs.nl ... threading BIND 9.3.1 that came with FreeBSD 6.0 CURRENT was compiled with multi-threading and that showed a clear performance limit at 3000 packets per second answer rate. ... logging During the preparations of experiments we noticed performance problems that were caused by having the default logging category logged to a channel that was configured with severity debug 6. ... increase The fits shows very different results for the amount of memory consumed per NSEC (the B parameter in Table 3). We do not expect that parameter to change between the various fits. The cause is that the number of NSEC RRs and the number of RRSIGs is not completely independent. The number of NSEC RRs is never larger than the number of RRSIG RRs, and the ratio for the zones for which ns-pri.ripe.net is authoritative is between 1:1 and 1:2. As a result we are trying to fit a plane to an almost straight line in the space and there are to little data points away from the line to reliably determine . ... answers As soon as these client configure a trust-anchors they will see validation failures and will not be able to resolve signed zones at all. ...Vlaai A treat from the province of Limburg Olaf Kolkman 2005-09-28

1. Introduction
2. Why Measurements
3. Strengths
4. Weaknesses
5. The Way Forward
6. Membership Support
7. Summary

1. Introduction

The RIPE NCC has collected data and published statistics form its inception. In fact the hostcount has even started before the RIPE NCC began operations. Other measurement and data collection activities have been added later, most notably Test Traffic Measurements (TTM) and the Routing Information Service (RIS).

After more than 10 years it is time to re-visit this area and adjust the direction based on input from the RIPE community and the NCC membership. This memo proposes the new direction and seeks to establish consensus among the RIPE NCC membership.

2. Why Measurements

Besides satisfying the curiosity of the RIPE community and fostering academic research there are a number of reasons for collecting and publishing measurements:

Statistics such as address space usage and routing table growth are vital for the development of address space policies and RIPE operational recommendations. Data such as the usage history of address space and routing identifiers is used extensively by the NCC in daily operations, so is monitoring data on the quality of the DNS root service.

The NCC also produces measurement products for use by the membership in both short term operations and long term planning. TTM gives test-box hosts both minute-to-minute information and long term trends. RIS can be used to get a global picture of inter-domain routing from a single source and is unique in providing this information not only for the present but also for user selectable time intervals in the past.

Last but not least RIPE NCC statistics are also aimed at telecomms regulators and government bodies that look after public interest concerns in our industry. To them we provide a neutral and unbiased view on developments that goes a bit deeper than some ad-hoc measurements that are published to further specific agendas. This area has become increasingly important over the last few years.

3. Strengths

The biggest strength of the RIPE NCC in the area of measurements is its proven neutrality and impartiality. We have developed this over the years and earned the trust of all players. The NCC staff doing the work have a very high degree of professionalism and experience in the area; this results in very high quality data that is used widely. We are not doing any passive measurements on production traffic in order to avoid privacy concerns. Because of our long history of measurement activities we have a number of very long time series of well defined measurements which can be used to analyse long-term trends.

4. Weaknesses

The emphasis on producing high-quality well defined data has lead us to take a somewhat academic attitude towards measurements. Our products are very detailed and need considerable time to use effectively and to learn how-to use in the first place. We have not developed enough easy to use and immediately useful products for the RIPE NCC membership and the RIPE community at large.

We have developed TTM as closed user group service. Only those who participate and pay have access to the data. We assumed that the user group would grow to a significant part of the RIPE NCC membership as the benefits became obvious. This has not happened for a number of reasons one of which is certainly that it has become very easy and cheap just to add capacity. Consequently TTM today serves only a very small minority of the NCC membership