Overview of ITU's History (1)

Overview of ITU's History (1)
Connecting the world and beyond
عربي
中文
Español
Français
Русский
Advanced Search
ITU
About ITU
Media Centre
Events
Publications
Statistics
Action areas
Regional Presence
Careers
General Secretariat
Radiocommunication
Standardization
Development
News
Members' Zone
Join ITU
Overview of ITU's History (1)

Search the History Portal
ImageUrl
You are here
ITU
>
Homepage
>
History of ITU Portal
Share
History of ITU Portal
Site Map
Explore the Digital Collections
Discover ITU's History
Focus on Areas of Work
Overview of ITU's History article
ITU Library and Archives
Send feedback

Page Content 20

Persistent Identifier for this page
Page Content 20 Title Hyperlink
http://handle.itu.int/11.1004/020.2000/s.210
Page Content 2
For a century and a half since 1865, the International Telecommunication Union (ITU) has been at the centre of advances in communications – from telegraphy through to the modern world of satellites, mobile phones and the Internet.
The story of ITU is one of international cooperation, among governments, private companies and other stakeholders. The continuing mission is to achieve the best practical solutions for integrating new technologies as they develop, and to spread their benefits to all.
Table of Contents
Page Content 3
(1) From telegraph to telephone
(2) Radio
(3) Keeping up with progress
(4) Television
(5) Space and satellites
(6) The Internet
(7) Mobile connectivity
(8) Development to bridge the digital divide
(9) Global meeting place
(10) Serving the modern world
(11) Looking forward

Download a PDF version of the Overview of ITU's History article
Page Content
From telegraph to telephone

See also:
Pre-1865 International Telegraph Agreements
The First International Telegraph Conference (Paris, 1865)
For thousands of years, the quickest method of sending complex messages over long distances was with a courier on horseback. At the end of the 18th century, Claude Chappe inaugurated a network of visual semaphore stations across France. Then came the electrical revolution. Experiments were conducted in sending electric signals along wires, and in 1839, the world’s first commercial telegraph service opened in London with a system created by
Charles Wheatstone
. In the United States, Samuel Morse used the new Morse code to send his first telegraph message in 1844. Already in 1843, a precursor of the
fax machine
for transmitting images had been patented in the United Kingdom by Alexander Bain.
Delegates at the first International Telegraph Conference (Paris, 1865) (Source: ITU)
Telegraph wires soon linked major towns in many countries. A
submarine telegraph wire
(coated in protective gutta percha) was laid between Britain and France in 1850, and a regular service inaugurated the following year. In 1858, the
first transatlantic telegraph
cable was laid. But there was a problem. Where lines crossed national borders, messages had to be stopped and translated into the particular system of the next
jurisdiction.
To
simplify matters, regional agreements began to be forged, and in Europe, representatives of 20 States gathered in Paris at an
International Telegraph Conference
to find ways to overcome barriers and make services more efficient. They would create a framework to standardize telegraphy equipment, set uniform operating instructions, and lay down common international tariff and accounting rules.
The first Convention of the International Telegraph Union signed in 1865 (Source: ITU)
On 17 May 1865, the first
International Telegraph Convention
was signed in Paris by its twenty founding members, and the International Telegraph Union (the first incarnation of ITU) was established to supervise subsequent amendments to the agreement. That significant date – 17 May – eventually
became
World Telecommunication and Information Society Day
.

ITU based in Switzerland
The 1868 International Telegraph Conference, in Vienna, decided that ITU would operate from its own bureau in Berne, Switzerland. It began with just three members of staff.
In 1948, the headquarters of ITU were moved from Berne to Geneva.

Only a decade later, the next leap forward in communications occurred with the patenting of the telephone in 1876. At the International Telegraph Conference held in Berlin in 1885, ITU began to draw up international legislation governing telephony. An article added to the Telegraph Regulations specified five minutes as a unit of charge, and the length of a call was limited to ten minutes if there were other requests to use the telephone line.
One of the earliest illustrations of Graham Bell's telephone in 1877 (Source: From Semaphore to Satellite, ITU)
Telephones meant you could actually speak to another person over long distances, as well as sending Morse code telegraphs. But what if a wire could not reach them, for instance, on a ship? In 1880 at the Royal Society in London,
David Edward Hughes
demonstrated what was later to be recognized as wireless signaling. Practical experiments began to be made in the 1890s by such inventors as
Nikola Tesla
,
Jagadish Chandra Bose
,
Alexander Stepanovich Popov
and Guglielmo Marconi. Radio, known as “wireless telegraphy,” was born.
Inventors of "wireless telegraphy" [clockwise from top left] David Edward Hughes, Nikola Tesla, Alexander Stepanovich Popov,
Guglielmo Marco
ni
, and Jagadish Chandra Bose.
next page
Follow us
Twitter
Facebook
YouTube
Flickr
Linkedin
Instagram
Soundcloud
Podcasts
Spotify
Spreaker
TikTok
© ITU
All Rights Reserved
Contact us
Terms of Use
Privacy notice
Accessibility
Report misconduct
Back to top


RFC 1454: Comparison of Proposals for Next Version of IP | RFC Editor
Skip to content
Info
RFC
1454
:
Comparison of Proposals for Next Version of IP
T. Dixon
Informational
Network Working Group                                          T. Dixon
Request for Comments: 1454                                         RARE
                                                               May 1993
Comparison of Proposals for Next Version of IP
Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This is a slightly edited reprint of RARE Technical Report
   (RTC(93)004).

   The following is a brief summary of the characteristics of the three
   main proposals for replacing the current Internet Protocol. It is not
   intended to be exhaustive or definitive (a brief bibliography at the
   end points to sources of more information), but to serve as input to
   the European discussions on these proposals, to be co-ordinated by
   RARE and RIPE. It should be recognised that the proposals are
   themselves "moving targets", and in so far as this paper is accurate
   at all, it reflects the position at the 25th IETF meeting in
   Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the
   original draft have been incorporated.  Note that for a time the term
   "IPv7" was use to mean the eventual next version of IP, but that the
   same term was closely associated with a particilar proposal, so the
   term "IPng" is now used to identify the eventual next generation of
   IP.

   The paper begins with a "generic" discussion of the mechanisms for
   solving problems and achieving particular goals, before discussing
   the proposals invidually.
1
. WHY IS THE CURRENT IP INADEQUATE?
The problem has been investigated and formulated by the ROAD group,
   but briefly reduces to the following:

      - Exhaustion of IP Class B Address Space.

      - Exhaustion of IP Address Space in General.

      - Non-hierarchical nature of address allocation leading to flat
        routing space.
Dixon                                                           [Page 1]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
Although the IESG requirements for a new Internet Protocol go further
   than simply routing and addressing issues,  it is these issues that
   make extension of the current protocol an impractical option.
   Consequently, most of the discussion and development of the various
   proposed protocols has concentrated on these specific problems.

   Near term remedies for these problems include the CIDR proposals
   (which permit the aggregation of Class C networks for routing
   purposes) and assignment policies which will allocate Class C network
   numbers in a fashion which CIDR can take advantage of. Routing
   protocols supporting CIDR are OSPF and BGP4. None of these are pre-
   requisites for the new IP (IPng), but are necessary to prolong the
   life of the current Internet long enough to work on longer-term
   solutions. Ross Callon points out that there are other options for
   prolonging the life of IP and that some ideas have been distributed
   on the TUBA list.

   Longer term proposals are being sought which ultimately allow for
   further growth of the Internet. The timescale for considering these
   proposals is as follows:

      - Dec 15 Issue selection criteria as RFC.

      - Feb 12 Two interoperable implementations available.

      - Feb 26 Second draft of proposal documents available.

   The (ambitious) target is for a decision to be made at the 26th IETF
   (Columbus, Ohio in March 1993) on which proposals to pursue.

   The current likely candidates for selection are:

      - PIP ('P' Internet Protocol - an entirely new protocol).

      - TUBA (TCP/UDP with Big Addresses - uses ISO CLNP).

      - SIP (Simple IP - IP with larger addresses and fewer options).

   There is a further proposal from Robert Ullman of which I don't claim
   to have much knowledge. Associated with each of the candidates are
   transition plans, but these are largely independent of the protocol
   itself and contain elements which could be adopted separately, even
   with IP v4, to further extend the life of current implementations and
   systems.
Dixon                                                           [Page 2]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
2
. WHAT THE PROPOSALS HAVE IN COMMON
2.1
Larger Addresses
All the proposals (of course) make provision for larger address
   fields which not only increase the number of addressable systems, but
   also permit the hierarchical allocation of addresses to facilitate
   route aggregation.
2.2
Philosophy
The proposals also originate from a "routing implementation" view of
   the world - that is to say they focus on the internals of routing
   within the network and do not primarily look at the network service
   seen by the end-user, or by applications. This is perhaps inevitable,
   especially given the tight time constraints for producing
   interoperable implementations. However, the (few) representatives of
   real users at the 25th IETF, the people whose support is ultimately
   necessary to deploy new host implementations, were distinctly
   unhappy.

   There is an inbuilt assumption in the proposals that IPng is
   intended to be a universal protocol: that is, that the same network-
   layer protocol will be used between hosts on the same LAN, between
   hosts and routers, between routers in the same domain, and between
   routers in different domains. There are some advantages in defining
   separate "access" and "long-haul" protocols, and this is not
   precluded by the requirements. However, despite the few opportunities
   for major change of this sort within the Internet, the need for speed
   of development and low risk have led to the proposals being
   incremental, rather than radical, changes to well-proven existing
   technology.

   There is a further unstated assumption that the architecture is
   targeted at the singly-connected host. It is currently difficult to
   design IPv4 networks which permit hosts with more than one interface
   to benefit from increased bandwidth and reliability compared with
   singly-connected hosts (a consequence of the address belonging to the
   interface and not the host). It would be preferable if topological
   constraints such as these were documented. It has been asserted that
   this is not necessarily a constraint of either the PIP or TUBA
   proposals, but I believe it is an issue that has not emerged so far
   amongst the comparative criteria.
Dixon                                                           [Page 3]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
2.3
Source Routing
The existing IPv4 has provision for source-specified routes, though
   this is little used [would someone like to contradict me here?],
   partly because it requires knowledge of the internal structure of the
   network down to the router level. Source routes are usually required
   by users when there are policy requirements which make it preferable
   or imperative that traffic between a source and destination should
   pass through particular administrative domains. Source routes can
   also be used by routers within administrative domains to route via
   particular logical topologies. Source-specified routing requires a
   number of distinct components:

      a.  The specification by the source of the policy by which the
          route should be selected.

      b.  The selection of a route appropriate to the policy.

      c.  Marking traffic with the identified route.

      d.  Routing marked traffic accordingly.

   These steps are not wholly independent. The way in which routes are
   identified in step (c) may constrain the kinds of route which can be
   selected in previous steps. The destination, inevitably, participates
   in the specification of source routes either by advertising the
   policies it is prepared to accept or, conceivably, by a negotiation
   process.

   All of the proposals mark source routes by adding a chain of (perhaps
   partially-specified) intermediate addresses to each packet. None
   specifies the process by which a host might acquire the information
   needed to  specify these intermediate addresses [not entirely
   unreasonably at this stage, but further information is expected]. The
   negative consequences of these decisions are:

      - Packet headers can become quite long, depending on the number of
        intermediate addresses that must be specified (although there are
        mechanisms which are currently specified or which can be imagined
        to specify only the significant portions of intermediate addresses).

      - The source route may have to be re-specified periodically if
        particular intermediate addresses are no longer reachable.

   The positive consequences are:

      - Inter-domain routers do not have to understand policies, they
        simply have to mechanically follow the source route.
Dixon                                                           [Page 4]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
- Routers do not have to store context identifying routes, since
        the information is specified in each packet header.

      - Route servers can be located anywhere in the network, provided
        the hosts know how to find them.
2.4
Encapsulation
Encapsulation is the ability to enclose a network-layer packet within
   another one so that the actual packet can be directed via a path it
   would not otherwise take to a router that can remove the outermost
   packet and direct the resultant packet to its destination.
   Encapsulation requires:

      a.  An indication in the packet that it contains another packet.

      b.  A function in routers which, on receiving such a packet,
          removes the encapsulation and re-enters the forwarding process.

   All the proposals support encapsulation. Note that it is possible to
   achieve the effect of source routing by suitable encapsulation by the
   source.
2.5
Multicast
The specification of addresses to permit multicast with various
   scopes can be accomodated by all the proposals. Internet-wide
   multicast is, of course, for further study!
2.6
Fragmentation
All the proposals support the fragmentation of packets by
   intermediate routers, though there has been some recent discussion of
   removing this mechanism from some of the proposals and requiring the
   use of an MTU-discovery process to avoid the need for fragmentation.
   Such a decision would effectively preclude the use of transport
   protocols which use message-count sequence numbering (such as OSI
   Transport) over the network, as only protocols with byte-count
   acknowledgement (such as TCP) can deal with MTU reductions during the
   lifetime of a connection. OSI Transport may not be particularly
   relevant to the IP community (though it may be of relevance to
   commercial suppliers providing multiprotocol services), however the
   consequences for the types of services which may be supported over
   IPng should be noted.
Dixon                                                           [Page 5]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
2.7
The End of Lifetime as We Know It
The old IPv4 "Time to Live" field has been recast in every case as a
   simple hop count, largely on grounds of implementation convenience.
   Although the old TTL was largely implemented in this fashion anyway,
   it did serve an architectural purpose in putting an upper bound on
   the lifetime of a packet in the network. If this field is recast as a
   hop-count, there must be some other specification of the maximum
   lifetime of a packet in the network so that a source host can ensure
   that network-layer fragment ids and transport-layer sequence numbers
   are never in danger of re-use whilst there is a danger of confusion.
   There are, in fact, three separate issues here:

      1. Terminating routing loops (solved by hop count).

      2. Bounding lifetime of network-layer packets (a necessity,
         unspecified so far) to support assumptions by the transport
         layer.

      3. Permitting the source to place further restrictions on packet
         lifetime (for example so that "old" real-time traffic can be
         discarded in favour of new traffic in the case of congestion
         (an optional feature, unspecified so far).
3
. WHAT THE PROPOSALS ONLY HINT AT
3.1
Resource Reservation
Increasingly, applications require a certain bandwidth or transit
   delay if they are to be at all useful (for example, real-time video
   and audio transport). Such applications need procedures to indicate
   their requirements to the network and to have the required resources
   reserved.  This process is in some ways analogous to the selection of
   a source route:

      a.  The specification by the source of its requirements.

      b.  The confirmation that the requirements can be met.

      c.  Marking traffic with the requirement.

      d.  Routing marked traffic accordingly.

   Traffic which is routed according to the same set of resource
   requirements is sometimes called a "flow". The identification of
   flows requires a setup process, and it is tempting to suppose that
   the same process might also be used to set up source routes, however,
   there are a number of differences:
Dixon                                                           [Page 6]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
- All the routers on a path must participate in resource
        reservation and agree to it.

      - Consequently, it is relatively straightforward to maintain
        context in each router and the identification for flows can be
        short.

      - The network can choose to reroute on failure.

   By various means, each proposal could carry flow-identification,
   though this is very much "for future study" at present. No setup
   mechansisms are defined. The process for actually reserving the
   resources is a higher-order problem. The interaction between source-
   routing and resource reservation needs further investigation:
   although the two are distinct and have different implementation
   constraints, the consequence of having two different mechanisms could
   be that it becomes difficult to select routes which meet both policy
   and performance goals.
3.2
Address-Assignment Policies
In IPv4, addresses were bound to systems on a long-term basis and in
   many cases could be used interchangeably with DNS names. It is
   tacitly accepted that the association of an address with a particular
   system may be more volatile in IPng. Indeed, one of the proposals,
   PIP, makes a distinction between the identification of a system (a
   fixed quantity) and its address, and permits the binding to be
   altered on the fly. None of the proposals defines bounds for the
   lifetime of addresses, and the manner in which addresses are assigned
   is not necessarily bound to a particular proposal. For example,
   within the larger address space to be provided by IPng, there is a
   choice to be made of assigning the "higher order" part of the
   hierarchical address in a geographically-related fashion or by
   reference to service provider. Geographically-based addresses can be
   constant and easy to assign, but represent a renewed danger of
   degeneration to "flat" addresses within the region of assignment,
   unless certain topological restrictions are assumed.  Provider-based
   address assignment results in a change of address (if providers are
   changed) or multiple addresses (if multiple providers are used).
   Mobile hosts (depending on the underlying technology) can present
   problems in both geographic and provider-based schemes.

   Without firm proposals for address-assignment schemes and the
   consequences for likely address lifetimes, it is impossible to assume
   that the existing DNS model by which name-to-address bindings can be
   discovered remains valid.
Dixon                                                           [Page 7]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
Note that there is an interaction between the mechanism for
   assignment of addresses and way in which automatic configuration may
   be deployed.
3.3
Automatic Configuration
Amongst the biggest (user) bugbears of current IP services is the
   administrative effort of maintaining basic configuration information,
   such as assigning names and addresses to hosts, ensuring these are
   refelected in the DNS, and keeping this information correct. Part of
   this results from poor implementation (or the blind belief that vi
   and awk are network management tools). However, a lot of the problems
   could be alleviated by making this process more automatic. Some of
   the possibilities (some mutually-exlusive) are:

      - Assigning host addresses from some (relative) invariant, such
        as a LAN address.

      - Defining a protocol for dynamic assignment of addresses within a
        subnetwork.

      - Defining "generic addresses" by which hosts can without
        preconfiguration reach necessary local servers (DNS, route
        servers, etc.).

      - Have hosts determine their name by DNS lookup.

      - Have hosts update their name/address bindings when their
        configuration changes.

   Whilst a number of the proposals make mention of some of these
   possibilities, the choice of appropriate solutions depends to some
   extent on address-assignment policies. Also, dynamic configuration
   results in some difficult philosopical and practical issues (what
   exactly is the role of an address?, In what sense is a host "the same
   host" when its address changes?, How do you handle dynamic changes to
   DNS mappings and how do you authenticate them?).

   The groups involved in the proposals would, I think, see most of
   these questions outside their scope. It would seem to be a failure in
   the process of defining and selecting candidates for IPng that
   "systemness" issues like these will probably not be much discussed.
   This is recognised by the participants, and it is likely that, even
   when a decision is made, some of these ideas will be revisited by a
   wider audience.

   It is, however, unlikely that IP will make an impact on proprietary
   networking systems for the non-technical environment (e.g., Netware,
Dixon                                                           [Page 8]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
Appletalk), without automatic configuration being taken seriously
   either in the architecture, or by suppliers. I believe that there are
   ideas on people's heads of how to address these issues - they simply
   have not made it onto paper yet.
3.4
Application Interface/Application Protocol Changes
A number of common application protocols (FTP, RPC, etc.) have been
   identified which specifically transfer 32-bit IPv4 addresses, and
   there are doubtless others, both standard and proprietary. There are
   also many applications which treat IPv4 addresses as simple 32-bit
   integers. Even applications which use BSD sockets and try to handle
   addresses opaquely will not understand how to parse or print longer
   addresses (even if the socket structure is big enough to accommodate
   them).

   Each proposal, therefore, needs to specify mechanisms to permit
   existing applications and interfaces to operate in the new
   environment whilst conversion takes place. It would be useful also,
   to have (one) specification of a reference programming interface for
   (TCP and) IPng (which would also operate on IPv4), to allow
   developers to begin changing applications now. All the proposals
   specify transition mechansisms from which existing application-
   compatibility can be inferred. There is no sign yet of a new
   interface specification independent of chosen protocol.
3.5
DNS Changes
It is obvious that there has to be a name to address mapping service
   which supports the new, longer, addresses. All the proposals assume
   that this service will be provided by DNS, with some suitably-defined
   new resource record. There is some discussion ongoing about the
   appropriateness of returning this information along with "A" record
   information in response to certain enquiries, and which information
   should be requested first. There is a potential tradeoff between the
   number of queries needed to establish the correct address to use and
   the potential for breaking existing implementations by returning
   information that they do not expect.

   There has been heat, but not light, generated by discussion of  the
   use of DNS for auto-configuration and the scaling (or otherwise) of
   reverse translations for certain addressing schemes.
Dixon                                                           [Page 9]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
4
. WHAT THE PROPOSALS DON'T REALLY MENTION
4.1
Congestion Avoidance
IPv4 offers "Source Quench" control messages which may be used by
   routers to indicate to a source that it is congested and has or may
   shortly drop packets. TUBA/PIP have a "congestion encountered" bit
   which provides similar information to the destination. None of these
   specifications offers detailed instructions on how to use these
   facilities. However, there has been a substantial body of analysis
   over recent years that suggests that such facilities can be used (by
   providing information to the transport protocol) not only to signal
   congestion, but also to minimise delay through the network layer.
   Each proposal can offer some form of congestion  signalling, but none
   specifies a mechanism for its use (or an analysis of whether the
   mechanism is in fact useful).

   As a user of a network service which currently has a discard rate of
   around 30% and a round-trip-time of up to 2 seconds for a distance of
   only 500 miles I would be most interested in some proposals for a
   more graceful degradation of the network service under excess load.
4.2
Mobile Hosts
A characteristic of mobile hosts is that they (relatively) rapidly
   move their physical location and point of attachment to the network
   topology.  This obviously has signficance for addressing (whether
   geographical or topological) and routing. There seems to be an
   understanding of the problem, but so far no detailed specification of
   a solution.
4.3
Accounting
The IESG selection criteria require only that proposals do not have
   the effect of preventing the collection of information that may be of
   interest for audit or billing purposes. Consequently, none of the
   proposals  consider potential accounting mechanisms.
4.4
Security
"Network Layer Security Issues are For Further Study". Or secret.

   However, it would be useful to have it demonstrated that each
   candidate could be extended to provide a level of security, for
   example against address-spoofing. This will be particularly
   important if resource-allocation features will permit certain hosts
   to claim large chunks of available bandwidth for specialised
   applications.
Dixon                                                          [Page 10]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
Note that providing some level of security implies manual
   configuration of security information within the network and must be
   considered in relationship to auto-configuration goals.
5
. WHAT MAKES THE PROPOSALS DIFFERENT?
Each proposal is about as different to the others as it is to IPv4 -
   that is the differences are small in principle, but may have
   significant effects (extending the size of addresses is only a small
   difference in principle!). The main distinct characteristics are:

   PIP:

      PIP has an innovative header format that facilitates hierarchical,
      policy and virtual-circuit routing. It also has "opaque" fields in
      the header whose semantics can be defined differently in different
      administrative domains and whose use and translation can be
      negotiated across domain boundaries. No control protocol is yet
      specified.

   SIP:

      SIP offers a "minimalist" approach - removing all little-used
      fields from the IPv4 header and extending the size of addresses to
      (only) 64 bits. The control protocol is based on modifications to
      ICMP. This proposal has the advantages of processing efficiency
      and familiarity.

   TUBA:

      TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control
      protocol. TUBA provides for the operation of TCP transport and UDP
      over a CLNP network. The main arguments in favour of TUBA are that
      routers already exist which can handle the network-layer protocol,
      that the extensible addresses offer a wide margin of "future-
      proofing" and that there is an opportunity for convergence of
      standards and products.
5.1
PIP
PIP packet headers contain a set of instructions to the router's
   forwarding processor to perform certain actions on the packet. In
   traditional protocols, the contents of certain fields imply certain
   actions; PIP gives the source the flexibility to write small
   "programs" which direct the routing of packets through the network.

   PIP addresses have an effectively unlimited length: each level in the
   topological hierarchy of the network contributes part of the address
Dixon                                                          [Page 11]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
and addresses change as the network topology changes. In a completely
   hierarchical network topology, the amount of routing information
   required at each level could be very small. However, in practice,
   levels of hierarchy will be determined more by commercial and
   practical factors than by the constraints of any particular routing
   protocol. A greater advantage is that higher-order parts of the
   address may be omitted in local exchanges and that lower-order parts
   may be omitted in source routes, reducing the amount of topological
   information that host systems are required to know.

   There is an assumption that PIP addresses are liable to change, so a
   further quantity, the PIP ID, is assigned to systems for the purposes
   of identification. It isn't clear that this quantity has any purpose
   which could not equally be served by a DNS name [it is more compact,
   but equally it does not need to be carried in every packet and
   requires an additional lookup]. However, the problem does arise of
   how two potentially-communicating host systems find the correct
   addresses to use.

   The most complex part of PIP is that the meaning of some of the
   header fields is determined by mutual agreement within a particular
   domain. The semantics of specific processing facilities (for example,
   queuing priority) are registered globally, but the actual use and
   encoding of requests for these facilities in the packet header can be
   different in different domains. Border routers between two domains
   which use different encodings must map  from one encoding to another.
   Since routers may not only be adjacent physically to other domains,
   but also via "tunnels", the number of different encoding rules a
   router may need to understand is potentially quite large. Although
   there is a saving in header space by using such a scheme as opposed
   to the more familiar "options", the cost in the complexity of
   negotiating the use and encoding of these facilities, together with
   re-coding the packets at each domain border, is a subject of some
   concern. Although it may be possible for hosts to "precompile" the
   encoding rules for their local domain, there are many potential
   implementaion difficulties.

   Although PIP offers the most flexibility of the three proposals, more
   work needs to be done on "likely use" scenarios which make the
   potential advantages and disadvantages more concrete.
5.2
SIP
SIP is simply IP with larger addresses and fewer options. Its main
   advantage is that it is even simpler that IPv4 to process. Its main
   disadvantages are:
Dixon                                                          [Page 12]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
- It is far from clear that, if 32 bits of address are
        insufficient, 64 will be enough for the forseeable future;

      - although there are a few "reserved" bits in the header, the
        extension of SIP to support new features is not obvious.

   There's really very little else to say!
5.3
TUBA
The characteristics of ISO CLNS are reasonably well known: the
   protocol bears a strong cultural resemblance to IPv4, though with
   20-byte network-layer addressing. Apart from a spurious "Not Invented
   Here" prejudice, the main argument againt TUBA is that it is rather
   too like IPv4, offering nothing other than larger, more flexible,
   addresses.  There is proof-by-example that routers are capable of
   handling the (very) long addresses efficiently, rather less that the
   longer headers do not adversely impact network bandwidth.

   There are a number of objections to the proposed control protocol
   (ISO 9542):

      - My early experience is that the process by which routers
        discover hosts is inefficient and resource consuming for
        routers - and requires quite fine timer resolution on hosts -
        if large LANs are to be accomodated reasonably. Proponents of
        TUBA suggest that recent experience suggests that ARP is no
        better, but I think this issue needs examination.

      - The "redirect" mechanism is based on (effectively) LAN
        addresses and not network addresses, meaning that local routers
        can only "hand-off" complex routing decisions to other routers
        on the same LAN.  Equally, redirection schemes (such as that of
        IPv4) which redirect to network addresses can result in
        unnecessary extra hops.  Analysis of which solution is better
        is rather dependent on the scenarios which are constructed.

   To be fair, however, the part of the protocol which provides for
   router-discovery provides a mechanism, absent from other proposals,
   by which hosts can locate nearby gateways and potentially
   automatically configure their addresses.
6
. Transition Plans
It should be obvious that a transition which permits "old" hosts to
   talk to "new" hosts requires:
Dixon                                                          [Page 13]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
Either:

      (a) That IPng hosts can also use IPv4 or
      (b) There is translation by an intermediate system

   and either:

      (c) The infrastructure between systems is capable of carrying both
          IPng and IPv4 or (d) Tunneling or translation is used to carry
          one protocol within another in parts of the network

   The transition plans espoused by the various proposals are simply
   different combinations of the above. Experience would tend to show
   that all these things will in fact happen, regardless of which
   protocol is chosen.

   One problem of the tunneling/translation process is that there is
   additional information (the extra address parts) which must be
   carried across IPv4 tunnels in the network. This can either be
   carried by adding an extra "header" to the data before encapsulation
   in the IPv4 packet, or by encoding the information as new IPv4 option
   types. In the former case, it may be difficult to map error messages
   correctly, since the original packet is truncated before return; in
   the latter case there is a danger of the packet being discarded (IPv4
   options are not self-describing and new ones may not pass through
   IPv4 routers). There is thus the possibility of having to introduce a
   "new" version of IPv4 in order to support IPng tunneling.

   The alternative (in which IPng hosts have two stacks and the
   infrastructure may or may not support IPng or IPv4) of course
   requires a mechanism for resolving which protocols to try.
7
. Random Comments
This is the first fundamental change in the Internet protocols that
   has occurred since the Internet was manageable as an entity and its
   development was tied to US government contracts. It was perhaps
   inevitable that the IETF/IESG/IAB structure would not have evolved to
   manage a change of this magnitude and it is to be hoped that the new
   structures that are proposed will be more successful in promoting a
   (useful) consensus. It is interesting to see that many of the
   perceived problems of the OSI process (slow progress, factional
   infighting over trivia, convergence on the lowest-common denominator
   solution, lack of consideration for the end-user) are in danger of
   attaching themselves to IPng and it will be interesting to see to
   what extent these difficulties are an inevitable consequence of wide
   representation and participation in network design.
Dixon                                                          [Page 14]
RFC 1454
Comparison of Next Version IP Proposals         May 1993
It could be regarded either as a sign of success or failure of the
   competitive process for the selection of IPng that the three main
   proposals  have few really significant differences. In this respect,
   the result of the selection process is not of particular
   significance, but the process itself is perhaps necessary to repair
   the social and technical cohesion of the Internet Engineering
   process.
8
. Further Information
The main discussion lists for the proposals listed are:

        TUBA:           tuba@lanl.gov
        PIP:            pip@thumper.bellcore.com
        SIP:            sip@caldera.usc.edu
        General:        big-internet@munnari.oz.au

        (Requests to: <list name>-request@<host>)

   Internet-Drafts and RFCs for the various proposals can be found in
   the usual places.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Tim Dixon
   RARE Secretariat
   Singel 466-468
   NL-1017AW Amsterdam
   (Netherlands)

   Phone: +31 20 639 1131 or + 44 91 232 0936
   EMail: dixon@rare.nl or Tim.Dixon@newcastle.ac.uk

Dixon                                                          [Page 15]
RFC
1454
: Comparison of Proposals for Next Version of IP
Informational


RFC 3935: A Mission Statement for the IETF | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 3935
Info
RFC
3935
:
BCP
95
:
A Mission Statement for the IETF
H. Alvestrand
Best Current Practice
Network Working Group H. Alvestrand
Request for Comments: 3935 Cisco Systems
BCP: 95 October 2004
Category: Best Current Practice
A Mission Statement for the IETF
Status of this Memo

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2004).

Abstract

This memo gives a mission statement for the IETF, tries to define the
terms used in the statement sufficiently to make the mission
statement understandable and useful, argues why the IETF needs a
mission statement, and tries to capture some of the debate that led
to this point.
1
. Mission Statement
The goal of the IETF is to make the Internet work better.

The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better. These documents include protocol standards,
best current practices, and informational documents of various kinds.

The IETF will pursue this mission in adherence to the following
cardinal principles:

Open process - any interested person can participate in the work,
know what is being decided, and make his or her voice heard on the
issue. Part of this principle is our commitment to making our
documents, our WG mailing lists, our attendance lists, and our
meeting minutes publicly available on the Internet.

Technical competence - the issues on which the IETF produces its
documents are issues where the IETF has the competence needed to
speak to them, and that the IETF is willing to listen to
Alvestrand Best Current Practice [Page 1]
RFC 3935
IETF Mission Statement October 2004
technically competent input from any source. Technical competence
also means that we expect IETF output to be designed to sound
network engineering principles - this is also often referred to as
"engineering quality".

Volunteer Core - our participants and our leadership are people who
come to the IETF because they want to do work that furthers the
IETF's mission of "making the Internet work better".

Rough consensus and running code - We make standards based on the
combined engineering judgement of our participants and our real-
world experience in implementing and deploying our specifications.

Protocol ownership - when the IETF takes ownership of a protocol or
function, it accepts the responsibility for all aspects of the
protocol, even though some aspects may rarely or never be seen on
the Internet. Conversely, when the IETF is not responsible for a
protocol or function, it does not attempt to exert control over
it, even though it may at times touch or affect the Internet.
2
. Definition of Terms
Mission: What an organization sets out to do. This is in contrast to
its goal (which is what it hopes to achieve by fulfilling its
mission), and to its activities (which is what specific actions it
takes to achieve its mission).

The Internet: A large, heterogeneous collection of interconnected
systems that can be used for communication of many different types
between any interested parties connected to it. The term includes
both the "core Internet" (ISP networks) and "edge Internet"
(corporate and private networks, often connected via firewalls,
NAT boxes, application layer gateways and similar devices). The
Internet is a truly global network, reaching into just about every
country in the world.
The IETF community wants the Internet to succeed because we
believe that the existence of the Internet, and its influence on
economics, communication, and education, will help us to build a
better human society.

Standard: As used here, the term describes a specification of a
protocol, system behaviour or procedure that has a unique
identifier, and where the IETF has agreed that "if you want to do
this thing, this is the description of how to do it". It does not
imply any attempt by the IETF to mandate its use, or any attempt
to police its usage - only that "if you say that you are doing
this according to this standard, do it this way". The benefit of
Alvestrand Best Current Practice [Page 2]
RFC 3935
IETF Mission Statement October 2004
a standard to the Internet is in interoperability - that multiple
products implementing a standard are able to work together in
order to deliver valuable functions to the Internet's users.

Participants: Individuals who participate in the process are the
fundamental unit of the IETF organization and the IETF's work.
The IETF has found that the process works best when focused around
people, rather than around organizations, companies, governments
or interest groups. That is not to say that these other entities
are uninteresting - but they are not what constitutes the IETF.

Quality: In this context, the ability to express ideas with enough
clarity that they can be understood in the same way by all people
building systems to conform to them, and the ability (and
willingness) to describe the properties of the system well enough
to understand important consequences of its design, and to ensure
that those consequences are beneficial to the Internet as a whole.
It also means that the specifications are designed with adherence
to sound network engineering principles, so that use for its
intended purpose is likely to be effective and not harmful to the
Internet as a whole.

Relevant: In this context, useful to some group of people who have to
make decisions that affect the Internet, including, but not
limited to, hardware and software implementors, network builders,
network operators, and users of the Internet. Note that it does
not mean "correct" or "positive" - a report of an experiment that
failed, or a specification that clearly says why you should not
use it in a given situation, can be highly relevant - for deciding
what NOT to do. A part of being relevant is being timely - very
often, documents delivered a year after core decisions have been
taken are far less useful than documents that are available to the
decision-makers at decision time.
3
. The Need for a Mission Statement
The IETF has to make decisions. And in some cases, people acting on
behalf of the IETF have to make decisions without consulting the
entire IETF first.

There are many reasons for this, including the near-impossibility of
getting an informed consensus opinion on a complex subject out of a
community of several thousand people in a short time.

Having a defined mission is one of the steps we can take in order to
evaluate alternatives: Does this help or hinder the mission, or is it
orthogonal to it? If there are limited resources, are there things
that they could be invested in that help the mission better?
Alvestrand Best Current Practice [Page 3]
RFC 3935
IETF Mission Statement October 2004
(Another step is to choose leaders that we trust to exercise their
good judgement and do the right thing. But we're already trying to
do that.)
4
. Issues with Scoping the IETF's Mission
4.1
. The Scope of the Internet
A very difficult issue in discussing the IETF's mission has been the
scope of the term "for the Internet". The Internet is used for many
things, many of which the IETF community has neither interest nor
competence in making standards for.

The Internet isn't value-neutral, and neither is the IETF. We want
the Internet to be useful for communities that share our commitment
to openness and fairness. We embrace technical concepts such as
decentralized control, edge-user empowerment and sharing of
resources, because those concepts resonate with the core values of
the IETF community. These concepts have little to do with the
technology that's possible, and much to do with the technology that
we choose to create.

At the same time, it is clear that many of the IETF-defined
technologies are useful not only for the Internet, but also for
networks that have no direct relation to the Internet itself.

In attempting to resolve the question of the IETF's scope, perhaps
the fairest balance is struck by this formulation: "protocols and
practices for which secure and scalable implementations are expected
to have wide deployment and interoperation on the Internet, or to
form part of the infrastructure of the Internet."

In addition to this constraint, we are also constrained by the
principle of competence: Where we do not have, and cannot gather, the
competence needed to make technically sound standards, we should not
attempt to take the leadership.
4.2
. The Balance Between Research, Invention and Adoption
The IETF has traditionally been a community for experimentation with
things that are not fully understood, standardization of protocols
for which some understanding has been reached, and publication of
(and refinement of) protocols originally specified outside the IETF
process.
Alvestrand Best Current Practice [Page 4]
RFC 3935
IETF Mission Statement October 2004
All of these activities have in common that they produce documents -
but the documents should be judged by very different criteria when
the time to publish comes around, and it's not uncommon to see people
confused about what documents are in which category.

In deciding whether or not these activities should be done within the
IETF, one should not chiefly look at the type of activity, but the
potential benefit to the Internet - an experiment that yields
information about the fact that an approach is not viable might be of
greater benefit to the Internet than publishing a standard that is
technically competent, but only useful in a few special cases.

For research of an essentially unbounded nature, with unknown
probability of success, it may be more relevant to charter a research
group than a standards group. For activities with a bounded scope -
such as specifying several alternative protocols to the point where
experiments can identify the better one for standardization - the
IETF's working group mechanism may be an appropriate tool.
4.3
. The Balance Between Mission and Procedures
The mission is intended to state what the IETF is trying to achieve.
There are many methods that can be chosen to achieve these outcomes -
for instance, the appeals procedure is defined so that we can detect
cases where our fundamental principles of technical competence and
open process has been violated; it is not itself a fundamental value.

Similarly, the question of what body in the IETF declares that a
document is ready for publication is entirely outside the mission
statement; we can imagine changing that without in any way impacting
what the IETF mission is - even though it may significantly impact
the ability to achieve that mission.
4.4
. The Reach of the Internet
The Internet is a global phenomenon. The people interested in its
evolution are from every culture under the sun and from all walks of
life. The IETF puts its emphasis on technical competence, rough
consensus and individual participation, and needs to be open to
competent input from any source. The IETF uses the English language
for its work is because of its utility for working in a global
context.
Alvestrand Best Current Practice [Page 5]
RFC 3935
IETF Mission Statement October 2004
4.5
. Protocol Ownership
A problem akin to the problem of deciding on the area of the IETF's
competence arises when a protocol that is clearly in the IETF's scope
is used both on and off the Internet - the premier example is of
course the Internet Protocol itself.

Sometimes the IETF defines standards that ultimately see the most use
outside the global Internet. The IETF, having defined the standard,
will continue to provide the necessary administration of that
protocol.

Sometimes the IETF leverages standards that are defined and
maintained by other organizations; we continue to work with those
organizations on their standards and do not attempt to take them
over.
5
. Security Considerations
Considering security is one of the core principles of sound network
engineering for the Internet. Apart from that, it's not relevant to
this memo.
6
. Acknowledgements
This document is a result of many hours of debate, countless reviews,
and limitless emails. As such, any acknowledgements section is bound
to be incomplete.

Among the many who provided input were the current members of the
IESG (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David
Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott
Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent
IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as
multiple IAB members, and many members from the community, including
James Polk, John Klensin, Pekka Savola, Paul Hoffman, Eliot Lear,
Jonne Soininen, Fred Baker, Dean Anderson, John Leslie, Susan Harris,
and many others. Special thanks go to Leslie Daigle, the IAB chair.

Author's Address

Harald Tveit Alvestrand
Cisco Systems
Weidemanns vei 27
Trondheim 7043
NO

EMail: harald@alvestrand.no
Alvestrand Best Current Practice [Page 6]
RFC 3935
IETF Mission Statement October 2004
Full Copyright Statement

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions
contained in
BCP 78
, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in
BCP 78
and
BCP 79
.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr
.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Alvestrand Best Current Practice [Page 7]
RFC
3935
: A Mission Statement for the IETF
Best Current Practice
Contents
About this RFC
Errata
1
In this section
1. Mission Statement
2. Definition of Terms
3. The Need for a Mission Statement
4. Issues with Scoping the IETF's Mission
4.1. The Scope of the Internet
4.2. The Balance Between Research, Invention and Adoption
4.3. The Balance Between Mission and Procedures
4.4. The Reach of the Internet
4.5. Protocol Ownership
5. Security Considerations
6. Acknowledgements
Footer
rfc-editor.org is maintained by the
Internet Engineering Task Force
System Status
·
Report a Bug
·
Version 1.76.1
Useful links
IETF.org
IRTF.org
IAB.org
Datatracker
Author Resources
Contact Us
RFC Editor
rfc-dist Info Page
rfc-interest Info Page
Expand sidebar

RFC publication date from document header


RFC 7258: Pervasive Monitoring Is an Attack | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 7258
Info
RFC
7258
:
BCP
188
:
Pervasive Monitoring Is an Attack
S. Farrell
,
H. Tschofenig
Best Current Practice
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 7258 Trinity College Dublin
BCP: 188 H. Tschofenig
Category: Best Current Practice ARM Ltd.
ISSN: 2070-1721 May 2014
Pervasive Monitoring Is an Attack
Abstract

Pervasive monitoring is a technical attack that should be mitigated
in the design of IETF protocols, where possible.

Status of This Memo

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in
Section 2 of RFC 5741
.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7258
.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to
BCP 78
and the IETF Trust's Legal
Provisions Relating to IETF Documents
(
http://trustee.ietf.org/license-info
) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Farrell & Tschofenig Best Current Practice [Page 1]
RFC 7258
Pervasive Monitoring Is an Attack May 2014
1
. Pervasive Monitoring Is a Widespread Attack on Privacy
Pervasive Monitoring (PM) is widespread (and often covert)
surveillance through intrusive gathering of protocol artefacts,
including application content, or protocol metadata such as headers.
Active or passive wiretaps and traffic analysis, (e.g., correlation,
timing or measuring packet sizes), or subverting the cryptographic
keys used to secure protocols can also be used as part of pervasive
monitoring. PM is distinguished by being indiscriminate and very
large scale, rather than by introducing new types of technical
compromise.

The IETF community's technical assessment is that PM is an attack on
the privacy of Internet users and organisations. The IETF community
has expressed strong agreement that PM is an attack that needs to be
mitigated where possible, via the design of protocols that make PM
significantly more expensive or infeasible. Pervasive monitoring was
discussed at the technical plenary of the November 2013 IETF meeting
[
IETF88Plenary
] and then through extensive exchanges on IETF mailing
lists. This document records the IETF community's consensus and
establishes the technical nature of PM.

The term "attack" is used here in a technical sense that differs
somewhat from common English usage. In common English usage, an
attack is an aggressive action perpetrated by an opponent, intended
to enforce the opponent's will on the attacked party. The term is
used here to refer to behavior that subverts the intent of
communicating parties without the agreement of those parties. An
attack may change the content of the communication, record the
content or external characteristics of the communication, or through
correlation with other communication events, reveal information the
parties did not intend to be revealed. It may also have other
effects that similarly subvert the intent of a communicator.
[
RFC4949
] contains a more complete definition for the term "attack".
We also use the term in the singular here, even though PM in reality
may consist of a multifaceted set of coordinated attacks.

In particular, the term "attack", used technically, implies nothing
about the motivation of the actor mounting the attack. The
motivation for PM can range from non-targeted nation-state
surveillance, to legal but privacy-unfriendly purposes by commercial
enterprises, to illegal actions by criminals. The same techniques to
achieve PM can be used regardless of motivation. Thus, we cannot
defend against the most nefarious actors while allowing monitoring by
other actors no matter how benevolent some might consider them to be,
since the actions required of the attacker are indistinguishable from
other attacks. The motivation for PM is, therefore, not relevant for
how PM is mitigated in IETF protocols.
Farrell & Tschofenig Best Current Practice [Page 2]
RFC 7258
Pervasive Monitoring Is an Attack May 2014
2
. The IETF Will Work to Mitigate Pervasive Monitoring
"Mitigation" is a technical term that does not imply an ability to
completely prevent or thwart an attack. Protocols that mitigate PM
will not prevent the attack but can significantly change the threat.
(See the diagram on page 24 of
RFC 4949
for how the terms "attack"
and "threat" are related.) This can significantly increase the cost
of attacking, force what was covert to be overt, or make the attack
more likely to be detected, possibly later.

IETF standards already provide mechanisms to protect Internet
communications and there are guidelines [
RFC3552
] for applying these
in protocol design. But those standards generally do not address PM,
the confidentiality of protocol metadata, countering traffic
analysis, or data minimisation. In all cases, there will remain some
privacy-relevant information that is inevitably disclosed by
protocols. As technology advances, techniques that were once only
available to extremely well-funded actors become more widely
accessible. Mitigating PM is therefore a protection against a wide
range of similar attacks.

It is therefore timely to revisit the security and privacy properties
of our standards. The IETF will work to mitigate the technical
aspects of PM, just as we do for protocol vulnerabilities in general.
The ways in which IETF protocols mitigate PM will change over time as
mitigation and attack techniques evolve and so are not described
here.

Those developing IETF specifications need to be able to describe how
they have considered PM, and, if the attack is relevant to the work
to be published, be able to justify related design decisions. This
does not mean a new "pervasive monitoring considerations" section is
needed in IETF documentation. It means that, if asked, there needs
to be a good answer to the question "Is pervasive monitoring relevant
to this work and if so, how has it been considered?"

In particular, architectural decisions, including which existing
technology is reused, may significantly impact the vulnerability of a
protocol to PM. Those developing IETF specifications therefore need
to consider mitigating PM when making architectural decisions.
Getting adequate, early review of architectural decisions including
whether appropriate mitigation of PM can be made is important.
Revisiting these architectural decisions late in the process is very
costly.

While PM is an attack, other forms of monitoring that might fit the
definition of PM can be beneficial and not part of any attack, e.g.,
network management functions monitor packets or flows and anti-spam
Farrell & Tschofenig Best Current Practice [Page 3]
RFC 7258
Pervasive Monitoring Is an Attack May 2014
mechanisms need to see mail message content. Some monitoring can
even be part of the mitigation for PM, for example, certificate
transparency [
RFC6962
] involves monitoring Public Key Infrastructure
in ways that could detect some PM attack techniques. However, there
is clear potential for monitoring mechanisms to be abused for PM, so
this tension needs careful consideration in protocol design. Making
networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here. An
appropriate balance will emerge over time as real instances of this
tension are considered.

Finally, the IETF, as a standards development organisation, does not
control the implementation or deployment of our specifications
(though IETF participants do develop many implementations), nor does
the IETF standardise all layers of the protocol stack. Moreover, the
non-technical (e.g., legal and political) aspects of mitigating
pervasive monitoring are outside of the scope of the IETF. The
broader Internet community will need to step forward to tackle PM, if
it is to be fully addressed.

To summarise: current capabilities permit some actors to monitor
content and metadata across the Internet at a scale never before
seen. This pervasive monitoring is an attack on Internet privacy.
The IETF will strive to produce specifications that mitigate
pervasive monitoring attacks.
3
. Process Note
In the past, architectural statements of this sort, e.g., [
RFC1984
]
and [
RFC2804
], have been published as joint products of the Internet
Engineering Steering Group (IESG) and the Internet Architecture Board
(IAB). However, since those documents were published, the IETF and
IAB have separated their publication "streams" as described in
[
RFC4844
] and [
RFC5741
]. This document was initiated after
discussions in both the IESG and IAB, but is published as an IETF-
stream consensus document, in order to ensure that it properly
reflects the consensus of the IETF community as a whole.
4
. Security Considerations
This document is entirely about privacy. More information about the
relationship between security and privacy threats can be found in
[
RFC6973
].
Section 5.1.1 of [RFC6973]
specifically addresses
surveillance as a combined security-privacy threat.
Farrell & Tschofenig Best Current Practice [Page 4]
RFC 7258
Pervasive Monitoring Is an Attack May 2014
5
. Acknowledgements
We would like to thank the participants of the IETF 88 technical
plenary for their feedback. Thanks in particular to the following
for useful suggestions or comments: Jari Arkko, Fred Baker, Marc
Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit
Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria,
Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Phillip
Hallam-Baker, Ted Hardie, Sam Hartmann, Paul Hoffman, Bjoern
Hoehrmann, Russ Housley, Joel Jaeggli, Stephen Kent, Eliot Lear,
Barry Leiba, Ted Lemon, Subramanian Moonesamy, Erik Nordmark, Pete
Resnick, Peter Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas
Weaver, Stefan Winter, and Lloyd Wood. Additionally, we would like
to thank all those who contributed suggestions on how to improve
Internet security and privacy or who commented on this on various
IETF mailing lists, such as the ietf@ietf.org and the
perpass@ietf.org lists.
6
. Informative References
[
IETF88Plenary
]
IETF, "IETF 88 Plenary Meeting Materials", November 2013,
<
http://www.ietf.org/proceedings/88/
>.

[
RFC1984
] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
Statement on Cryptographic Technology and the Internet",
RFC 1984
, August 1996.

[
RFC2804
] IAB and IESG, "IETF Policy on Wiretapping",
RFC 2804
, May
2000.

[
RFC3552
] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations",
BCP 72
,
RFC 3552
, July
2003.

[
RFC4844
] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor",
RFC 4844
, July 2007.

[
RFC4949
] Shirey, R., "Internet Security Glossary, Version 2",
RFC
4949
, August 2007.

[
RFC5741
] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,
and Boilerplates",
RFC 5741
, December 2009.

[
RFC6962
] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency",
RFC 6962
, June 2013.
Farrell & Tschofenig Best Current Practice [Page 5]
RFC 7258
Pervasive Monitoring Is an Attack May 2014
[
RFC6973
] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols",
RFC 6973
, July
2013.

Authors' Addresses

Stephen Farrell
Trinity College Dublin
Dublin 2
Ireland

Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie

Hannes Tschofenig
ARM Ltd.
6060 Hall in Tirol
Austria

EMail: Hannes.tschofenig@gmx.net
URI:
http://www.tschofenig.priv.at
Farrell & Tschofenig Best Current Practice [Page 6]
RFC
7258
: Pervasive Monitoring Is an Attack
Best Current Practice
Contents
About this RFC
Errata
In this section
1. Pervasive Monitoring Is a Widespread Attack on Privacy
2. The IETF Will Work to Mitigate Pervasive Monitoring
3. Process Note
4. Security Considerations
5. Acknowledgements
6. Informative References
Footer
rfc-editor.org is maintained by the
Internet Engineering Task Force
System Status
·
Report a Bug
·
Version 1.76.1
Useful links
IETF.org
IRTF.org
IAB.org
Datatracker
Author Resources
Contact Us
RFC Editor
rfc-dist Info Page
rfc-interest Info Page
Expand sidebar


Office for Digital and Emerging Technologies |
Skip to main content
Welcome to the United Nations
Toggle navigation
Language:
عربي
中文
English
Français
Русский
Español
Office for Digital and Emerging Technologies
Search form
A-Z Site Index
Search
Toggle navigation
Home
Global Digital Compact
Endorse the Global Digital Compact
UN Digital Cooperation Portal
AI Governance
Independent International Scientific Panel on AI
Global Dialogue on AI Governance
AI Governance for Humanity Lab
HLAB on Artificial Intelligence (2023–2024)
Digital Public Infrastructure
Events
Past Events
India AI Impact Summit (February 2026)
Building the Commons (December 2025)
UN Digital Cooperation Day (September 2025)
STI Forum Action Day (May 2025)
UN Open Source Week 2026 (June 2026)
UN Digital Cooperation Day (September 2026)
About
Contact
News and Resources
Homepage
Your browser does not support the video tag.
→ Just released:
Preliminary Report of the Independent International Scientific Panel on AI —
Read it now
Advancing Global Technology Cooperation for a Better Future
The United Nations Office for Digital and Emerging Technologies (ODET) was established by the General Assembly on 1 January 2025 to advance inclusive, rights-based and multi-stakeholder digital cooperation that respects national priorities and contexts. ODET also serve as the United Nations system-wide focal point for digital issues.
↓
explore more
What ODET Is Working On
Digital Cooperation Portal
Global Digital Compact
AI Governance Cooperation
Digital Public Infrastructure Cooperation
Digital Transformation
Open Source Cooperation
Featured Reports
Preliminary Report of the Independent International Scientific Panel on AI
Report of the Secretary-General: Innovative Voluntary Financing Options for Artificial Intelligence Capacity-Building
Reference documents
Overview of consultation process
Strategic Pathways for AI Capacity Building
Overview of UN system AI capacity-building activities in the civilian domain
Overview of AI capacity-building financing announcements 2020–2025
Case Studies of Existing Innovative Financing Mechanisms and how they could be adapted for AI Capacity Building in LMICs
Governing AI for Humanity
Mind the AI Divide
The Universal DPI Safeguards Framework
UN Open Source Week 2025 Conference Report
Stay Up to Date
LinkedIn
X
Bluesky
Tech Envoy’s Substack
News & Resources
Mailing List
Sign Up for Updates
Donate
facebook
twitter
youtube
flickr
instagram
Footer
A-Z Site Index
Contact
Copyright
FAQ
Fraud Alert
Privacy Notice
Terms of Use


ICANN Fellowship Program - ICANN

ICANN Fellowship Program - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
ICANN Fellowship Program
About
|
Eligibility
|
Requirements
|
Apply
|
Dates & Deadlines
|
Program Status
|
Important Links
About
The goal of the ICANN Fellowship Program is to strengthen the representation of the multistakeholder model by fostering opportunities for individuals from underserved and underrepresented communities to become active participants in the ICANN community.
Fellows are exposed to the workings of the ICANN community, are assigned a mentor, and receive training across different areas of knowledge and skill building before, during, and after an
ICANN Public Meeting
. Travel assistance to attend the meeting is also provided.
Fellowship participants come from a variety of backgrounds. Check out program
participants
and
statistics
for more information.
Eligibility
Candidates from all regions and sectors are welcome to apply to the ICANN Fellowship Program.
Participants of the Fellowship Program must:
Be at least 21 years of age
Be interested in, or already engaged in, the various components of ICANN's work in policy building, the operation of the Domain Name System and the security and stability of the global Internet
Complete mandatory ICANN Learn course(s); learn more
here
NOT be involved in or associated with other ICANN supported travel programs at time of selection
Policy Forum applicants must have successfully completed an ICANN Fellowship
Have previously received no more than two fellowships; second and third time fellows must prove their involvement and engagement in one of the
ICANN communities
(learn more
here
)
Returning fellows will be considered for the Tarek Kamel Fellowship Recognition. The award recognizes outstanding contributions of fellows in furthering ICANN's capacity development efforts in their respective regions. Learn more
here
.
A selected Fellow, who lives or works in African region with technical background will be considered for Paul Muchene Fellow Award. The Paul Muchene Fellow Award is a tribute to Paul Muchene, an ICANN Fellowship Program participant and ICANN organization staff member who passed away in August 2022. To learn more
here
.
For more information, please see the program's
Terms & Conditions
and
Selection Criteria
.
Requirements
Fellowship recipients are expected to:
Engage in
Fellowship Program Mentoring
processes
Complete additional required ICANN Learn courses
Attend the ICANN Public Meeting and required activities, including but not limited to ICANN Fellowship sessions during the ICANN Meeting
Network and interact with program alumni and community members
Complete the post-meeting survey
Participants are encouraged to actively contribute to ICANN policy development processes and Fellowship alumni network upon completion of the Fellowship Program.
Apply
The Fellowship application round for ICANN88 Community Forum is now
open
. The deadline for submission is 21 August, 2026 at 23:59 UTC Time.
Please note, that you need an ICANN Account in order to apply for the Fellowship Program.
If ICANN meeting is held virtually, the Fellowship Program will also be held virtually.
ICANN87 Annual General Meeting Fellowship Program Successful Candidates Announced – The
following individuals
had been selected to participate at the ICANN87 Annual General Meeting to be held from 17-22 October, 2026 in Bali, Indonesia.
For more information please see program's
Frequently Asked Questions
,
Terms & Conditions
,
Selection Criteria
and
Selection Committee
.
Application Dates & Deadlines
ICANN Meeting
ICANN Region
Meeting Dates
Opening of application round
Closing of application round
Announcement of selected Fellows
ICANN87 Annual General Meeting in Bali, Indonesia
Asia Pacific
17-22 October 2026
19 March 2026 at 23:59 UTC
Closed
18 June 2026 at 23:59 UTC
ICANN88 Community Forum in Lisbon, Portugal
Europe
13-18 March 2027
21 July 2026 at 23:59 UTC
21 August 2026 at 23:59 UTC
10 November 2026 at 23:59 UTC
ICANN89 Policy Forum in Vancouver, Canada *
North America
14-17 June 2027
5 November 2026 at 23:59 UTC
5 December 2026 at 23:59 UTC
14 February 2027 at 23:59 UTC
* Only those who have successfully completed an ICANN Fellowship Program (Fellowship Program Alumni) are eligible to apply for a Policy Forum fellowship.
Current Program Status
The Fellowship application round for ICANN88 Community Forum is now
open
. The deadline for submission is 21 August, 2026 at 23:59 UTC Time.
Please note, that you need an ICANN Account in order to apply for the Fellowship Program.
If ICANN meeting is held virtually, the Fellowship Program will also be held virtually**.
**Virtual participation will incorporate all of the key elements of the Fellowship Program.
ICANN87 Annual General Meeting Fellowship Program Successful Candidates Announced – The
following individuals
had been selected to participate at the ICANN87 Annual General Meeting to be held from 17-22 October, 2026 in Bali, Indonesia.
The Fellowship Program Post-Meeting Report for ICANN85 is available
here
.
Important Links
Apply to the Fellowship Program
Submit an application during open rounds
Terms & Conditions
More information on the program's Terms & Conditions
Upcoming Application Dates & Deadlines
Planned launch dates for future application round
FAQs
Check out frequently asked questions and answers about the Fellowship Program and Fellowship Application Instructions
Fellowship Selection Criteria
See Fellowship selection criteria
ICANN Fellowship Program Mentoring
More information about the mentoring process
Fellowship Selection Committee
More information about the Fellowship Selection Committee.
New Fellowship Program Approach
More information about the
community consultation
and
public comment
process to review the Fellowship Program
List of Fellowship Participants
See list of Fellowship Program participants for each ICANN Meeting
Fellowship Program 10 Year Survey Report
[PDF, 981 KB]
Check out the results of the 10 Year Fellowship Survey with program alumni (28 June 2017)
Program Statistics
Check out statistics on Fellowship participants
ICANN Fellowship Program Promotional Flyer
Tarek Kamel Fellowship Recognition
More information about the Tarek Kamel Fellowship Recognition.
Paul Muchene Fellow Award
More information about the Paul Muchene Fellow Award
Post-Meeting Reports
Read reports written by the fellows about their experiences and future plans.
2021 Fellowship Alumni Survey Report
Check out the results of the 2021 Fellowship Alumni Survey (17 February 2022)
Archive
For more information, please contact
[email protected]
.
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."


Home Page — ICANN Open Data

Home Page — ICANN Open Data
Back to ICANN Account
SEARCH
Home
Data
Charts
API
About
Help
Back to ICANN Account
Search
Search
Other ICANN sites
ICANN.org
Address Supporting Organization (ASO)
At-Large
ICANN Community Wiki
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Connect with us
CONTACT US
CAREERS AT ICANN
© 2021 Internet Corporation for Assigned Names and Numbers
Privacy Policy
Cookies Policy
Terms of Service