The Internet s Caretakers


The Internet's Caretakers

Numerous organizations, standards bodies, and even corporations function in different capacities. All of them contribute in some way to the Internet. Some allocate domain names (such as cisco.com) or assign IP addresses to the Internet's end users. Others create the technologies that make the Internet work or that let you use the Internet. All these entities are integral to the Internet's operation. We'll look at each one in this chapter, but only one can truly be considered the Internet's caretaker. That organization is the Internet Engineering Task Force (IETF).

IETF

The manner in which the Internet's technology base is developed and ratified might not be intuitively appreciated. In fact, the arrangement is one of the more unconventional approaches you may ever find. As we start to explore just how it operates, and how standards and other recommendations are developed in this forum, you'll appreciate why I call it unconventional. Nevertheless, it is a model that works using both collaborative and competitive forces.

One of the unique qualities of the IETF is that it consists almost entirely of unpaid volunteers. Don't misunderstand the point; these are highly technical and well-paid engineers who contribute their time to the IETF in addition to the work they do for their employers. Such volunteers don't pay dues to join the IETF. They simply "join" and either lurk in the background or actively contribute to the work being performed.

The IETF, and the way it operates, can be traced back to the nascent days of the Internet when just a few hosts were interconnected directly with serial lines. In those days, the technical personnel responsible for supporting the various interconnected hosts realized that there was great benefit to working together for the sake of deriving consistency in naming conventions, the technology base, communications protocols, and guidelines for using their internetwork. Lacking a central budget, mission, or any of the other trappings of a conventional organization, nothing could be dictated. Only the mutual desire to improve the functionality of their interdependent network bound them together. Everything had to make sense for the entire community to form a consensus. Otherwise, suggestions and recommendations might not be adopted. The technical community supporting this early internetwork (a group of interconnected networks) formed a loose confederation and called themselves an engineering task force. The moniker stuck.

Informal collaboration and communication worked quite well for a number of years, and then the Internet began its exponential growth stage toward the end of the 1980s. The first official meeting of the IETF was held in January of 1986 and was attended by just 21 people. Membership and participation have increased steadily since then and now encompass thousands of people. Although the IETF has grown tremendously, its original essence remains embodied in the way it is organized. Today, technical professionals from competitive companies work side-by-side under the auspices of the IETF to develop and maintain the Internet's technology base. Its membership is an ever-growing group of highly talented individuals who volunteer their time to collaboratively engineer and evolve the Internet's technology base. The IETF's work in spelling out the protocol-level details of new technologies, as well as methods and procedures, is published openly in a series of documents, which include the following:

  • Internet drafts

  • Requests for Comments (RFCs)

  • Internet standards

  • Best Current Practices (BCPs)

  • FYIs (For Your Information)

Each type of document serves a specific purpose, and we'll look at each one in detail. First we need to examine the hierarchy of the IETF. That will help you better appreciate the inner workings of the IETF as it pertains to the development and ratification of these documents. As we explore the IETF in this chapter, you'll notice how its every nuance, including how the IETF is organized and functions, is recorded in a publicly available document that fits into one or more of the previously mentioned document classes.

NOTE

All of the IETF's documentation is publicly available on its website at www.ietf.org.


Many organizations are affiliated with the IETF, each with loosely defined responsibilities. These groups include the following:

  • Internet Society (ISOC)

  • Internet Architecture Board (IAB)

  • Internet Research Task Force (IRTF)

  • Internet Assigned Numbers Authority (IANA)

  • Internet Corporation for Assigned Names and Numbers (ICANN)

  • Internet Engineering Steering Group (IESG)

  • Working groups

Each of these organizations is further explored in the remainder of this section.

ISOC

The ISOC is an international nonprofit organization. It differs from other Internet organizations in that it is not a suborganization of the IETF. Its sole mission is to foster the growth of the global Internet. It does so in fairly abstract and less-than-obvious ways. For example, it theoretically provides oversight to the IETF and its subcomponents, but that oversight is limited to financial, logistic, and legal support. For example, it provides insurance coverage for people involved in the IETF's standards-creation processes, and it functions as a public relations channel whenever an IETF entity needs to communicate via the press.

Perhaps the most visible output of the ISOC is that its trustees ratify the rules and procedures by which standards are developed for the Internet by the IETF. Thus, although the ISOC doesn't directly shape the Internet or its technology base, it sets the rules by which the Internet evolves.

IAB

One of the more critical subentities of the IETF is the IAB. Originally known as the Internet Activities Board, the IAB has evolved and grown over time in response to changes in the Internet. Today, the IAB is known as the Internet Architecture Board. It is responsible for long-range planning and coordinating activities across the various subcomponents of the IETF. As such, it is uniquely positioned to see the big picture of the IETF's cumulative efforts. Part of its role might be to bring issues to the attention of specific area directors if they think a long-term item requires some attention.

IRTF

The IRTF is sponsored and overseen by the IAB. This group conducts research into emerging technologies, and this research becomes an input to the IAB's long-range technology planning activities.

IANA

The IANA is responsible for keeping track of all numbers and numeric values that must be reserved or assigned for the various protocols and technologies maintained by the IETF to work properly. The most obvious example is the IP address space (the sum total of all IP addresses), but IANA's responsibilities also include maintaining the list of TCP and UDP standardized or well-known application port numbers.

IANA is also the Internet's core registrar. This dubious distinction was conferred by the IAB, and it made IANA the "owner" of the root of the Internet's name space. This role has not exactly resulted in a positive perception throughout the Internet community, and unfortunately it has overshadowed some of IANA's other responsibilities. Although IANA once was a relatively autonomous entity within the IETF, and it still is technically charged with maintaining all the unique parameters used on the Internet (addresses, domain names, and port numbers) today, IANA appears to be slowly melding into ICANN.

ICANN

The ICANN is a nonprofit corporation that was established to maintain IP address allocation, assignment of protocol parameters (such as port numbers), and management of the Internet's domain name system (DNS). These functions had previously been performed by IANA, but they have since been delegated to ICANN.

To carry out its duties, ICANN has formed three function-specific supporting organizations (SOs):

  • Address Supporting Organization (ASO)

  • Domain Name Supporting Organization (DNSO)

  • Protocol Supporting Organization (PSO)

ICANN functions as the root of the Internet's domain name space and charters both registries and registrars. The registry function is distributed by regions around the globe. It allows address space to be parsed out and managed regionally. Such registries are known as Regional Internet Registries (RIRs). There are three registries, but some cover more than one region. Table 1-1 lists the regions and their supporting RIRs.

Table 1-1. RIRs and Their Regions

Global Region

Supporting RIR

Europe

RIPE NCC

Africa

ARIN and the RIPE NCC

North America

ARIN

Middle East

RIPE NCC

Latin America and the Caribbean

ARIN

Asia-Pacific

APNIC


ARIN stands for American Registry for Internet Numbers. APNIC stands for Asia Pacific Network Information Centre. RIPE NCC is a bit tougher for North Americans to grasp; it stands for Réseaux IP Européens Network Coordination Centre.

Each registry is given a block of IP addresses and is responsible for assigning and managing that space within its region. Two other geographic regions have announced plans to form their own RIRs: Africa and Latin America. ICANN is the only entity that can charter an RIR and assign it an address space.

Within each RIR's region, other entities can apply to become Local Internet Registries (LIRs), much like an Internet Service Provider (ISP) can assign address blocks to its customers' operational networks.

Registrars, on the other hand, are responsible for managing the assignment of Internet domain names. This is a much more contentious issue than merely parsing out numbers. Don't worry just yet about why domain names can be contentious; we'll cover that in detail in Chapter 8, "Internet Names." For now, it is enough that you just appreciate the acronyms, roles, and responsibilities of the various bodies that regulate the Internet's growth, evolution, and operation.

The Internet's Registries and Registrars by Alex Kamantauskas

The topic of registries on the Internet can cause some confusion. There are multiple "registries" as a direct result of the breakup of the Network Solutions monopoly on domain names. Prior to the advent of ICANN, Network Solutions functioned as both the registry for domain names (the entity responsible for making sure the root servers were updated, the whois servers were maintained, and so on) and the registrar (the point of contact in the trading of domain names as a commodity). When competition was introduced into the domain name market, Network Solutions (and now VeriSign) maintained the registry function, and the registrar function was split among the various competing companies, including Network Solutions. That company was both registry and registrar for a while, but I assure, you they didn't play favorites. In order to become an accredited registrar, you had to agree toand usethe Network Solutions/VeriSign registry.

However, today the distinction between registry and registrar is growing fuzzier with the advent of sponsored domain names. For instance, NeuLevel is now the registry for the .biz domain name. It provides registry services for the domain name for registrars that are selling names in the .biz space. So, now you have the registry for Internet numbers, multiple registries for Internet names, and competing registrars.


IESG

The Internet Engineering Steering Group (IESG) provides technical management of all IETF activities, as well as its standards-development process. The IESG consists of area directors, each of which are nominated by the IETF's nominations committee and serve a two-year term. The area directors oversee a specific technical area. Current areas include the following:

  • Applications

  • General

  • Internet

  • Operations and Management

  • Routing

  • Security

  • Transport

  • User Services

These areas correlate almost perfectly with the functional areas of the working groups, which are described in more detail in the next section. The only exception is the General Area, which exists as a catchall mechanism for the IESG. Not many initiatives fall into this category, but those that do can be assigned to whichever area or areas are deemed appropriate.

It's important to note that the oversight of the IESG and its area directors doesn't extend to direct oversight of technical development efforts. Instead, oversight is construed as ratifying the output of the working groups. Thus, the IESG can exert influence on whether any particular proposal advances to the point where it can be implemented. Typically, the IESG accepts the recommendations of working groups, but it can reject a recommendation if it believes the group has either strayed from its charter or has recommended something that will have an adverse effect on the Internet and its technology base.

Working Groups

The detail work of developing specific technical solutions to specific technical problems is performed by transient organizations within the IETF known as working groups. The IETF has sought to create a continuity of technical expertise in working groups by organizing them into functional areas. Each functional area is directed by an IESG area director. An area can have multiple working groups operating simultaneously, focused on extremely specific activities. It is important to note that these areas do not necessarily translate cleanly into areas recognized by the IESG. Consider this imperfect correlation between working groups and IESG areas; a feature that enables flexibility, as opposed to a flaw which promotes confusion. The output of any given working group may be reviewed by multiple IESG area directors to obviate potential conflicting technologies or recommendations.

Currently, the IETF has active working groups in the following functional areas:

  • Applications Broadly defined as things that use IP networks and security mechanisms, but excluding all security and network mechanisms. Applications that require network connectivity rely on well-defined interfaces to the transport and network layer protocols, and that becomes the bailiwick of the Applications Area working group.

  • Internet The Internet Area encompasses developing mechanisms and capabilities for IP itself. For example, developing the ability for IP to be transported over new network technologies such as InfiniBand, Fibre Channel, and cable networks lies in this functional area.

  • Operations and Management Anything that defines how things operate is the responsibility of the O&M functional area. Generally speaking, anything involving Simple Network Management Protocol (SNMP), Management Information Base (MIB), or operation of services is done within the O&M area. Specific examples of active working groups in this area include a group investigating the extension of SNMP agents, Domain Name Server (DNS) operations, and the evolution of SNMP.

  • Routing The Routing functional area is tightly focused on routing protocols. Some teams active in this area are looking at the Routing Information Protocol (RIP), Open Shortest Path First (OSPF) routing protocol, and the development of a virtual router redundancy protocol (VRRP).

  • Security Security is fairly self-evident, in that the teams in this area focus on improving the authentication, privacy, and safety of networked computing assets and data. Security teams are currently working on such things as the creation of an XML-based (extensible markup language) digital signature and an open version of Pretty Good Privacy (PGP) encryption software, among others.

  • Sub-IP The Sub-IP Area is one of the hardest areas to describe. At least, I have a difficult time understanding what differentiates it from the Internet functional area. Substantial overlap between the two groups is evident when you consider that two of the currently active Sub-IP groups are developing the specifications for IP over optical facilities and Multiprotocol Label Switching (MPLS).

  • Transport The Transport functional area focuses on developing interfaces for higher-level protocols and services. Some of the specific areas of current activity include IP Telephony, IP Storage, Differentiated Services (DiffServ), and audio/video transport.

  • User Services Anything that defines how people want things done across a network. This group tends to focus on developing FYIs instead of RFCs. (If these acronyms don't mean anything to you, keep reading. We'll look at all the outputs of the various IETF subentities in the next section, "The Internet Standards Process.") This group also helps users of all levels improve the quality of information available on the Internet. That might sound a bit vague, but you can think of it this way: The User Services group is more of a communications vehicle for the IETF than a technology development group.

If these categorizations sound a bit soft, and it seems there is great potential for overlap, you're right. Many specific technical problems are worked on jointly by two or more working groups. Membership in a working group is voluntary.

If the notion of joining a working group and helping develop new standards for the Internet appeals to you, do yourself and everyone in the IETF a favor, and read RFC 3160. Entitled "The Tao of the IETF," this document helps you better understand the organization, its culture, and everything about the work it produces. The URL is www.ietf.org/rfc/rfc3160.txt




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net