+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Y. Arrouye
-February 15, 2002 RealNames Corp.
-Expires August 15, 2002 T. W. Tan
- National University of Singapore
- X. Lee
- Chinese Academy of Sciences & CNNIC
-
- Keywords Systems - Definition and Requirements
- draft-arrouye-keywords-reqs-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- The DNS (Domain Name System), which was designed as a network
- resource naming layer, is not able to serve today's Internet users
- naming needs anymore. Attempts to change the DNS to adapt to those
- needs, such as the IDN (Internationalized Domain Name) IETF effort,
- are not only proving themselves unsatisfactory in many ways, they are
- also limited by the nature of DNS itself. There is now strong
- consensus that the solution for naming for the Internet requires
- layers above DNS. For example, John Klensin has advocated a multi-
- layered model that undertakes to address the naming needs of the
- modern Internet. In Klensin's model, the layer immediately above DNS
- is fully multilingual and user-friendly. It is expected that this
- layer will support a variety of distinct services. This document
-
-
-
-Arrouye and Tan [Page 1]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- presents the requirements of one class of naming service called
- Keywords systems, of which there are several deployed today. These
- requirements are presented from the perspective of Internet users,
- for whom there exists no satisfactory standard naming system.
-
-1. Introduction
-
- The Internet has evolved from a simple interconnection of networks to
- a global infrastructure supporting academic, personal, governmental,
- and commercial communications. As a result, the Internet's main
- naming system, the DNS, has seen its use change dramatically. As the
- number of names in demand has increased, so has the realization that
- there is a profound mismatch between a name meant to be used by
- humans and one meant to be used by applications. Because they have
- been the only names available for use on the Internet, domain names
- could not remain simply resource names, but rather were pushed to
- became the labels that every Internet user would ideally associate
- with the content they sought to access. That push has not happened
- smoothly. Attempts to change the nature of DNS names by
- internationalizing them do not solve the main problem of the
- awkwardness of DNS names in a versatile, multilingual, human-friendly
- naming scheme for the global Internet.
-
- As result of the apparent inadequacy of approaches that try to
- improve the ability of the DNS to serve as a universal, human-
- friendly naming scheme, there is now strong consensus for
- establishing a new layer of naming on top of the DNS [DNSROLE,
- DNSSEARCH]. This new layer will allow the Internet community to
- redefine naming in light of actual needs, without having to change
- the DNS or rely on its evolution. The community stresses the
- necessity for the new layer to go beyond the needs of the Domain Name
- System to realize an architecture capable of accommodating diverse
- services, with separate ownerships, different scopes and distinct
- operating models.
-
- One of the operating and addressing models proposed as a component of
- this new layer is Keywords systems. These systems offer a
- multilingual naming layer that is human-friendly and simple to use.
- Many Keywords systems that offer similar user experiences are in
- existence today: RealNames, worldwide; CNNIC, in China; 3721, in
- China; TWNIC in Taiwan; Netpia, in Korea; Nipa, in Thailand, and AOL,
- within its own network. The proliferation of Keywords systems in the
- Asia-Pacific region emphasizes the DNS's lack of support for non-
- Latin scripts.
-
- This document presents the requirements that define Keywords systems
- that will be able to interoperate and expand their usefulness.
-
-
-
-
-Arrouye and Tan [Page 2]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- The goals of this document are:
-
- 1. To present a clear list of Keywords requirements.
-
- 2. To document the Keywords user experience. This defines how
- Keywords are being and should be used by Internet users.
-
- 3. To document properties of Keywords systems or Keywords objects
- that are deemed useful in every Keywords system.
-
- 4. To provide a framework for discussion of Keywords systems and
- their standardization.
-
- In this document, the terms Keyword or Keyword name have the same
- meaning, which is the name of a Keyword. The term Keyword object, or
- Keyword resource descriptor, refers to a more complex object
- containing properties, or facets, of which the Keyword name is one.
- The Keyword object is described in detail in this document.
-
- The definition of terms related to internationalization are those
- introduced in [I18NTERMS].
-
-2. User Requirements that are Met by Keyword Systems
-
- Keywords systems should be architected to meet user expectations. The
- industry generally agrees that the following are the basic
- requirements of any successful Keywords system.
-
-2.1. Unique Names and Identities
-
- The Keyword name is the only element of the Keyword object that the
- users manipulate. In order for Keywords to function as an effective
- addressing system (see Direct Navigation Using Keywords), a name must
- be associated with only one destination in a given context (cf.
- context below).
-
- The importance of the uniqueness of the names is reinforced by the
- need to support the notion of online identity. One's identity needs
- to be clearly and unambiguously defined, and thus unique.
-
-2.2. Above DNS
-
- The DNS in its current form cannot accommodate the Internet's current
- naming requirements. Neither can it be changed significantly.
- Keywords systems must exist separately from the DNS to offer
- applications an independent naming interface. The common view of DNS
- and other addressing system is to place the low level systems below
- others, so DNS is viewed as above IP addresses, and Keywords systems
-
-
-
-Arrouye and Tan [Page 3]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- would be viewed as above DNS and URIs.
-
-2.3. Multilingual
-
- Keywords must be available in all languages and scripts. Because
- Keywords systems are implemented electronically, and because it is
- agreed that it is practical to use a single encoding for the names,
- the languages and scripts that Keywords must support are those of
- that encoding that will be picked.
-
-2.4. Context-Based
-
- While the name is the most important element of a Keyword object, it
- benefits from being supplemented by other attributes such as country,
- language, type of application (also called service type in [SLS] and
- [KLS]), etc. These attributes are also referred to as facets. (See
- "Benefits of Direct Navigation" for a further discussion of context.)
-
-2.5. Applicable Across Multiple Applications
-
- Keywords must function in a broad variety of applications and
- devices, such as the World Wide Web, mobile phones, e-mail, etc.
-
-2.6. Multiple Interoperable Namespaces
-
- Due to the complexities of languages, local usage and policy
- differences in countries or application domains, it is neither
- feasible nor practical to implement a single, worldwide Keywords
- system. A differentiated, interoperable federation of Keywords
- systems will provide the flexibility and depth needed. These Keywords
- systems will be unified by a single resolution protocol that will
- guarantee interoperability of the Keywords systems for applications.
-
-3. Keywords User Experiences
-
- There are two common user experiences associated with Keywords. The
- most common one, and the one that makes Keywords appealing, is
- navigation. The second one is discovery. These experiences are
- described below.
-
-3.1. Direct Navigation Using Keywords
-
- The goal of all Keywords systems is to make it as simple as possible
- to reach a given physical destination by using a simple human-
- friendly name. A physical destination is anything that can be
- described by a URI [RFC2396], so for example a Web page, an e-mail
- address, or a WAP page on a mobile phone are all physical
- destinations. Internet destinations are one kind of physical
-
-
-
-Arrouye and Tan [Page 4]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- destinations.
-
- The typical experience of a user of a Keywords system is as follows:
-
- 1. The user enters a Keyword in her own language in her application,
- and eventually selects an action (e.g. "go" in a Web browser, or
- simply hitting the "enter" key).
-
- 2. The application transparently uses a Keywords system to map the
- Keyword to a physical address that is appropriate to its domain
- (e.g. a Web address for a Web browser, an e-mail address for a
- mail user agent, etc.).
-
- 3. The physical address that has just been obtained is used to
- perform the user-specified action (e.g. load a Web page, send e-
- mail to a specific mailbox, etc.).
-
- This is called direct navigation, as it lets a user go directly to a
- destination using this simple name.
-
-3.1.1. Benefits of Direct Navigation
-
- Direct navigation is what makes Keywords systems appealing to users
- as an addressing system. Keywords systems are designed with the
- objective of providing the best user experience: intuitive names that
- deliver expected results. This section looks at a few benefits of
- Keyword systems.
-
- 1. Users see Keywords as actual Internet addresses, and they work
- just like any other addressing system. Contrarily to traditional
- Internet addresses, they are easy to remember. The critical part
- of the Keywords navigation experience is in the second step, where
- the application uses the Keyword input by the user to obtain a
- physical address. This can be done today using proprietary
- protocols or CNRP (Common Name Resolution protocol) [CNRP],
- although it is likely that if Keywords systems are deployed on a
- large scale a more compact protocol will be designed. What is
- important to understand is how the application uses the Keyword as
- well as other data to make a query to a Keywords system.
-
- 2. A given Keyword object may contain different physical addresses
- for different applications, which is akin to saying that Keyword
- objects are identified by a combination of name and application
- type. That application type (also called service type in [SLS] and
- [KLS]) makes up some of the context that is passed to a Keywords
- system, along with a name (also part of that context), in order to
- identify a given Keyword object. Whenever the context is fully
- specified, a Keywords system will return at most one matching
-
-
-
-Arrouye and Tan [Page 5]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- Keyword object. This notion of context is key to the resolution of
- a Keyword query into a physical address.
-
- 3. The more context is available, the more powerful a Keywords system
- can be, and the better user experience it can provide. For
- example, just by introducing the language as an element of
- context, one can then use a global name like BMW, or Coca-Cola,
- and access content in the appropriate language. Obviously, such a
- language facet contributes to the human-friendliness of the system
- by allowing not only the Keyword names, but also the content they
- refer to, to be in the user's language. Such a language context is
- also quite easy to obtain, since operating systems as well as
- applications already support the notion of a user-selected
- language (such as one's browser language setting) or locale.
-
- Note that direct navigation does not mean that the only thing that
- can happen to a Keywords user is either to get to a destination or
- get nowhere. A Keywords service, when there is no matching Keyword
- object for the user's query, may return a list of approximate
- matches. It is up to the application to use that list and interact
- with the user as needed to pick between these matches if desired.
- Applications may also choose alternate behaviors such as using a
- search engine, or combining the approximate matches with other
- heuristics, etc...
-
-3.1.2. Definition of the Context
-
- It is very tempting to make a long list of desirable facets of a
- Keyword object. Location and industry category, for example, are two
- properties that are often mentioned, and more facets are regularly
- offered for consideration.
-
- An important lesson learned from operating Keywords system so far is
- that it is very difficult to ask users to supply context that is not
- already available to the application. Not only does this usually
- bring up user interface issues, it changes the user experience from a
- "type the name, get what you want" to a less direct, much more
- painful experience that drives users away from the system. It is also
- worth noting that asking for determination after the user has input a
- partial context that can match a number of Keyword objects, has the
- same effect of breaking the user experience and discouraging her. The
- key to context information in a Keywords system is that context must
- be implicit (i.e. known a priori to the application) in order to
- offer a good user experience.
-
- As a result, one must be very careful in introducing facets that need
- to be part of the context. On the other hand, one should always ask
- the registrant of a Keyword to provide as many facets as possible, in
-
-
-
-Arrouye and Tan [Page 6]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- order to be able to use them later, as applications improve and
- become able to supply meaningful values for those facets as part of a
- query to a Keywords system.
-
-3.1.3. Manipulation of the Context
-
- While the user should only be required to enter a name in order to
- reach a destination, it is desirable that the hidden parts of the
- context can be manipulated by the user. This is usually done by
- providing settings that can be used to do these manipulations. For
- example, a Web browser typically offers a way to set language
- preferences, from which the language context can be drawn.
-
-3.2. Discovery of Keywords
-
- We have so far described the experience of a user who uses a Keyword
- in order to get to a physical address. There is also a need for users
- to discover Keywords. Discovery may happen either when a user is not
- able to supply all the facets necessary to make a single
- determination, or when she only has partial data such as a few words
- of a multi-word Keyword.
-
- Discovery services are valuable because they offer users a way to
- browse a Keywords namespace and explore its content. They need to be
- separate from direct navigation in order to preserve the directness
- of the navigation experience. It is however possible to offer
- discovery as a fallback after a failed navigation experience, as long
- as the two experiences are clearly distinct.
-
-3.3. Other Variations
-
- In some environments, such as mobile phones, typing a full Keyword
- may prove cumbersome. It is thus a good experience, in these
- environments, to support some form of automatic completion of partial
- Keywords. The navigation may not be direct then, because confirmation
- from the user is needed, but the overall experience of using Keywords
- is improved because of the diminished pain factor in entering the
- names.
-
-
-4. The Keyword Object
-
- We have so far described the Keywords user experience and looked at
- two of its aspects. We have said that Keywords system contain
- Keywords objects that contain a number of facets. This section
- describes facets that make up a Keyword object. There are two kinds
- of facets, depending on whether they are used as part of the context
- or not:
-
-
-
-Arrouye and Tan [Page 7]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- 1. Key facets are part of the context that is necessary to establish
- a one-to-one mapping between context and a physical address. The
- name and the service type are good example of such facets.
-
- 2. Informational facets carry information that is useful but not
- required as part of the context. A description of a Keyword is a
- good example of such a facet.
-
- Key facets are always required. Some informational facets may be
- optional, and others may be required. In this section, the facets are
- listed with an indication of their kind.
-
- One should note that some facets may make sense for some service
- types and not for others. The categorization of facets below is
- intended to ensure that the facets that are key are required for all
- service types. Also, it may be interesting to allow optional context
- facets, whose presence can improve the user experience.
-
-4.1. Name (Key Facet)
-
- The name is the most visible part of a Keyword system, as it is what
- users see, remember, and then use in order to navigate. It is also
- what defines one's online identity.
-
- It is widely agreed that DNS and other Web-addressing systems (such
- as the URI) cannot create human-friendly names. To be human-friendly,
- a name must satisfy a number of conditions. It should be easy to
- remember. Familiar brand names should be transferable to the
- Internet naming system with no change if possible. Names should be
- available for the whole user population, and should be available in a
- user's native languages and scripts. Finally, the syntax of names
- should be flexible enough to allow for desirable names. One will note
- that that lack of syntax not only makes the names easier to remember
- and use, it also opens the door to the use of Keywords through voice
- recognition technology available today.
-
- Issues pertaining to names are discussed further in the "Multilingual
- Support" section.
-
- While it is useful to have syntax free names, some restrictions can
- be placed on name availability in order to preserve existing
- namespaces. For instance, if a Keywords system offers a transparent
- interface to namespaces like DNS, ENUM, etc... it can prevent the
- subscription of Keywords that follow the syntax of these namespaces
- in order to avoid confusion between the different namespaces.
-
-4.2. Service Type (Key Facet)
-
-
-
-
-Arrouye and Tan [Page 8]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- The service type is used to describe a class of applications that
- provide a given service to users. For example, tentative service
- types are "web," "e-mail," "mobile web," and even "dns" or "phone."
- The service type is a primary mechanism to support the reuse of one
- given name to denote different bits of information (which are
- accessed through a given physical address).
-
-4.3. Service Provider (Key Facet)
-
- Because there are many different Keywords systems in existence, there
- is a need to be able to refer to them to determine which system a
- Keyword belongs too. That is the purpose of a service provider facet.
- The facet is part of the context that defines the uniqueness of a
- Keyword, allowing distinct Keywords provider to have their own
- Keyword object for a given Keyword.
-
-4.4. Language (Key Facet)
-
- The language facet denotes the language of the Keyword. It can be
- used, for example, to enable language-specific rules of
- normalization, or simply to determine how to display a CJK name made
- of unified Han characters.
-
- There are many standards or would-be standards for the identification
- of languages. The IETF standard for languages is defined in
- [RFC3066], which obsoletes [RFC1766], still cited by many protocols
- and IETF work documents. Also note that [RFC2277] says that language
- tagging in IETF protocols should be done using this standard. The
- biggest advantage of using language tags as defined in [RFC1766] is
- that existing protocols and applications support them, which makes it
- easy to obtain a language facet value as part of the Keyword request
- context without user interaction.
-
- An oft-cited categorization of languages is the one produced by SIL
- International. Known as the Ethnologue [ETHNOLOGUE] their work
- categorizes and uniquely identifies more than 6,700 languages used in
- 228 countries. There have been proposals to make the Ethnologue
- categorization available as an Internet categorization, and one could
- indeed use i-sil-xxx to refer to the Ethnologue language code xxx in
- perfect conformance with [RFC1766], but today's applications are not
- aware of Ethnologue language codes.
-
-4.5. Content-Language (Key Facet)
-
- The content-language facet describes the language of the content that
- is accessed through the physical address. For instance, if the
- Keyword named "Deutsche Telekom" has the Web physical address
- http://www.telekom.de/dtag/ipl2e/cda/t1/ then the content language
-
-
-
-Arrouye and Tan [Page 9]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- should be English since that is the language of the content.
-
- This facet can be used for language negotiation, which is supported
- in some protocols already. he facet uses the same standard as the
- language facet to identify the language.
-
-4.6. Country (Key Facet)
-
- The country facet refers to the country for which the content
- accessed through the physical address is intended. Countries are
- indicated by using country codes from ISO 3166 [ISO3166]. ISO 3166 is
- a three-part standard. The part relevant to current countries is ISO
- 3166-1. It standardizes names of countries and associates them with 2
- and 3 letter codes referred to as alpha-2 and alpha-3, respectively.
- Internet usage, primarily stemming from RFC3066, is to use the
- alpha-2 variant.
-
- Applications are only starting to support separation between language
- and countries. Such a separation is very important, because it
- enables to offer a good service to ethnic groups in a given location.
- When language and country are mixed, only the populations large
- enough to have a recognized dialect in that country can be serviced.
- In order to provide backwards compatibility, it is permissible to use
- the country component of an RFC3066 language tag in order to
- determine the value of the country facet.
-
-4.7. Physical Address (Informational Facet, Required)
-
- This facet contains the address that the Keyword overlays, i.e. the
- real name of the data that are accessed using the Keyword. It is
- proposed that this facet always be a URI, which may require the
- definition of new URI schemes for existing addressing systems. The
- URI was designed as an extensible addressing system, and it would be
- nice to take advantage of its properties for the physical addressing
- component of Keywords systems.
-
-4.8. Description (Informational Facet)
-
- While key facets are necessary for querying a Keywords system,
- informational facets are useful when displaying Keywords in listings,
- such as the ones that a discovery service may provide. The
- description facets describes a Keyword in a few sentences, in such a
- way that its meaning is obvious to a reader.
-
- There must be one description for the language of the Keyword, i.e.
- if the Keyword is associated to Korean content, there must be a
- Korean description. It may be desirable to support additional
- descriptions in other languages.
-
-
-
-Arrouye and Tan [Page 10]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
-4.9. Location (Informational Facet)
-
- This facet is often mentioned as something that is very useful. One
- of the main problem is to decide what kind of location to use. Valid
- suggestions include: a system like country, province, zip code, or a
- subset thereof; ISO 3166-2; latitude, longitude, altitude; ECEF
- (Earth-Centered, Earth-Fixed); and probably others. Note that it is
- possible to go from one of the fine-grain systems to the coarser-
- grain ones, but that the (lack of) availability of mapping tables may
- be a factor. It is also possible to support more than one location
- notation at the same time.
-
- For applications like mobile phones, the location of the user
- relative to cell towers (whose locations on or above Earth are
- themselves known) is known by the mobile phone operator and could be
- made part of the context. Note that this particular example raises
- some privacy issues that the operator or service need to take care
- of.
-
-4.10. Category (Informational Facet)
-
- There has been talk of the necessity of having some sort of industry
- category facet in the next Internet naming layer, and of making it
- part of the facets that determine the uniqueness of records in this
- layer. While we agree that such information is useful meta-data that
- can be used in a discovery service, there are some problems with
- making such a category part of the context:
-
- - Even though one may argue that the categories listed in WIPO's Nice
- agreement [WIPO-NICE] are encompassing enough for industry
- categories, there is no established standard for non-industry
- categories. The development and ratification of such standard is a
- very big task in itself.
-
- - Applications do not support categories. If they did, it is doubtful
- that a typical user could come to grasp with the big tree of
- categories. And if only the top-level classes were to be offered to
- users for selections, they would be lost even more since those
- classes mix things such as computer software design and animal
- grooming. And the fact that our [Ed.: RealNames'] marketing lady
- calls us monkeys does not make that really clearer for everyone.
-
- As a consequence of these problems, Keywords systems do not support
- such data as a key facet, but only as an informational one.
-
-
-5. Multilingual Support
-
-
-
-
-Arrouye and Tan [Page 11]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- It is understood that today, the best way to manipulate names for
- multiple scripts is to rely on encoding those names using Unicode
- [UNICODE]. This is the proposed encoding of names for Keywords
- system. References to characters or character sequences in this
- document are made using Unicode.
-
-5.1. Human-friendliness can also be achieved by helping users get the
- desired result through some normalization of the names that are used.
- For example, it is desirable to treat the sequence <U+0065 LATIN
- SMALL LETTER e><U+0301 COMBINING ACUTE ACCENT> as equivalent as
- <U+00E9 LATIN SMALL LETTER E WITH ACUTE> (the former sequence being a
- canonical decomposition of the second one [UTR15]). But other
- features of human-friendliness, for example respecting alternate
- spelling rules for German, or handling traditional versus simplified
- Chinese writing systems, are not always understood, or simply agreed
- on. There is a need to define the requirements necessary for the
- interoperability of Keywords systems, and what features can be used
- to distinguish different services between each other. These issues
- are discussed at a further point in this document.
-
- Note that the discussion of normalization above is not a discussion
- of Unicode normalization. It is a discussion of string normalization
- that may use Unicode normalization as a tool. A better term may be
- string preparation, and it would be desirable to use the framework
- defined in [STRINGPREP] for such a normalization, if possible. Note
- that there may be a need for different Stringprep profiles for
- different languages, something that Keywords systems can support
- thanks to their rich set of facets.
-
- Different names normalization on top of the default normalization may
- be an interesting service differentiator.
-
-5.2. Traditional and Simplified Chinese
-
- The Chinese language can be written in two forms: Simplified Chinese
- (SC), used in the People's Republic of China (PRC) and Singapore; and
- Traditional Chinese (TC) used in Taiwan, Hong Kong, Macau, and by
- most Chinese people overseas. One of the issues that face naming
- systems is that one name registered in one form may be used by users
- writing the other form. Also, mixed form names may be an issue for
- the same reason.
-
- A common fallacy is to believe that there is a straightforward 1-to-1
- mapping between the forms. Some of the Chinese characters of one form
- have 1-to-many mappings, others have many-to-1 mappings, and others,
- when in groups, cannot be easily converted without risking changes in
- the meaning of the converted sequence. Also, some characters are used
- in both traditional and simplified Chinese. As a result, the problem
-
-
-
-Arrouye and Tan [Page 12]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- of matching Chinese input to registered Chinese names is complex.
- However, Keywords systems may be able to offer a better solution than
- existing systems to the problem of handling traditional and
- simplified Chinese names.
-
- First of all, Keywords systems fully support the notions of country
- and language. Because the choice of using traditional and simplified
- Chinese was dictated by countries, that support will help solving
- that problem. For example, one common objection to mapping between
- Traditional and Simplified Chinese forms is that the Unicode code
- points for Traditional Chinese are also used in Japanese and Korean.
- Having the language available prevents unwanted alteration of names
- in these languages. Also, the availability of the country could lead
- to different mapping rules agreeable to that particular country.
-
-6. Conclusion
-
- We have presented the requirements for Keywords systems, the Keywords
- user experience, as well as some design and architecture
- considerations.
-
- Keywords systems, which are already deployed worldwide, will
- represent an important component of the next Internet naming
- architecture.
-
-7. References
-
- [CNRP] N. Popp, M. Mealling, and M. Moseley, Common Name Resolution
- Protocol (CNRP), draft-ietf-cnrp-10.txt, June 2001.
-
- [CONTLANG] H. Alvestrand, Content Language Headers, draft-alvestrand-
- content-language-02.txt, May 2001.
-
- [DNSROLE] J. Klensin, Role of the Domain Name System, draft-klensin-
- dns-role-01.txt, May 2001.
-
- [DNSSEARCH] J. Klensin, A Search-based access model for the DNS,
- draft-klensin-dns-search-01.txt, July 2001.
-
- [ETHNOLOGUE] SIL International, The Ethnologue,
- http://www.ethnologue.org/.
-
- [I18NTERMS] P. Hoffman, Terminology Used in Internationalization in
- the IETF, draft-hoffman-i18n-terms-05.txt, January 2002.
-
- [IDNWG] IETF IDN Working group,
- http://www.ietf.org/html.charters/idn-charter.html.
-
-
-
-
-Arrouye and Tan [Page 13]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- [ISO3166] ISO 3166 Maintenance Agency, ISO 3166 Standard,
- http://www.din.de/gremien/nas/nabd/iso3166ma/.
-
- [KLS] Y. Arrouye, V. Parikh, and N. Popp, Keyword Lookup Systems As a
- Class of Naming Systems, draft-arrouye-kls-00.txt, August 2001.
-
- [NAMEPREP] P. Hoffman and M. Blanchet, Stringprep Profile for
- Internationalized Domain Name, draft-ietf-idn-nameprep-07.txt,
- January 2002.
-
- [PROVREGWG] IETF Provreg Working Group,
- http://www.ietf.org/html.charters/provreg-charter.html.
-
- [RFC1766] H. Alvestrand, Tags for the Identification of Languages,
- RFC 1766, March 1995.
-
- [RFC2277] H. Alvestrand, IETF Policy on Character Sets and Languages,
- RFC 2277, January 1998.
-
- [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource
- Identifiers (URI): Generic Syntax, RFC 2396, August 1998.
-
- [RFC2916] P. Faltstrom, E.164 number and DNS, RFC 2916, September
- 2000.
-
- [RFC3066] H. Alvestrand, Tags for the Identification of Languages,
- RFC 1766, January 2001.
-
- [SLS] M. Mealling and L. Daigle, Service Lookup System (SLS), draft-
- mealling-sls-00.txt, July 2001.
-
- [STRINGPREP] P. Hoffman and M. Blanchet, Preparation of
- Internationalized Strings ("stringprep"), draft-hoffman-
- stringprep-00.txt, Septermber 2001.
-
- [UAX15] M. Davis and M. Duerst, Unicode Standard Annex #15: Unicode
- Normalization Forms, March 2001
- (http://www.unicode.org/reports/tr15/).
-
- [UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0,
- Addison-Wesley, Reading, MA, January 2000 (ISBN 0-201-61633-5).
- Amended by the Unicode Standard Annex #27: Unicode 3.1, May 2001
- (http://www.unicode.org/reports/tr27/), and by the Unicode Standard
- Annex #28: Unicode 3.2, December 2001
- (http://www.unicode.org/reports/tr28/).
-
- [WIPO-NICE] World Intellectual Property Organization, "Nice Agreement
- concerning the International Classification of Goods and Services for
-
-
-
-Arrouye and Tan [Page 14]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- the Purposes of the Registration of Mark," June 1957.
- http://classifications.wipo.int/fulltext/nice/ennnic.htm.
-
-Authors' Addresses
-
- Yves Arrouye
- RealNames Corporation
- 150 Shoreline Drive
- Redwood City, CA 94065
-
- Phone: +1 (650) 486-5503
-
- E-mail: yves@realnames.com
-
-
- Tan Tin Wee
- Bioinformatics Centre
- National University of Singapore
- 10 Kent Ridge Crescent
- Singapore 119260
-
- E-mail: tinwee@pobox.org.sg
-
-
- Xiaodong Lee
- Chinese Academy of Sciences & China Network Information Center
- 4 South 4th Street
- ZhongGuanCun
- Beijing
- P.R. China 100080
-
- Phone: +86 10 62619750 3020
-
- E-mail: lee@cnnic.net.cn
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
-
-
-
-Arrouye and Tan [Page 15]
-\f
-draft-arrouye-keywords-reqs-01.txt 4 February 2002
-
-
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arrouye and Tan [Page 16]
-\f
+++ /dev/null
-
-DNSEXT Working Group Randy Bush (ed.)
- Alain Durand (ed.)
- Bob Fink (ed.)
- Olafur Gudmundsson (ed.)
- Tony Hain (ed.)
-INTERNET-DRAFT September 2001
-
-<draft-ietf-dnsext-ipv6-addresses-00.txt>
-
-Updates: RFC 1886, RFC 2673, RFC 2874
-
-
-
- Representing IPv6 addresses in DNS.
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Comments should be sent to the authors or the DNSEXT WG mailing list
- namedroppers@ops.ietf.org
-
- This draft expires on March 25, 2002.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-
-
-
-
-Expires 25/March/2002 DNSEXT [Page 1]
-\f
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
-
-
-Abstract
-
- This document clarifies and updates the standards status of RFCs that
- define direct and reverse map of IPv6 addresses in DNS. This document
- moves the A6 and Bit label specifications to experimental status.
-
-
-
-
-1 - Introduction
-
- The IETF had begun the process of standardizing two different address
- formats for IPv6 addresses AAAA[RFC1886] and A6[RFC2874] and both are
- at proposed standard. This had led to confusion and conflicts on
- which one to deploy. It is important for deployment that any
- confusion in this area be cleared up, as there is a feeling in the
- community that having more than one choice will lead to delays in the
- deployment of IPv6. The goal of this document is to clarify the
- situation.
-
- This document is based on extensive technical discussion on various
- relevant working groups mailing lists and a joint DNSEXT and NGTRANS
- meeting at the 51st IETF in August 2001. This document attempts to
- capture the sense of the discussions and reflect them in this
- document to represent the consensus of the community.
-
- The main arguments and the issues are covered in a separate
- document[Tradeoff] that reflects the current understanding of the
- issues. This document summarizes the outcome of these discussions.
-
- The issue of the root of reverse IPv6 address map is outside the
- scope of this document and is covered in a different
- document[RFC3152].
-
-1.1 Standards action taken
-
- This document changes the status of RFCs 2673 and 2874 from Proposed
- Standard to Experimental.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 25/March/2002 DNSEXT [Page 2]
-\f
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
-
-
-2 - IPv6 addresses: AAAA RR vs A6 RR
-
- Working group consensus as perceived by the chairs of the DNSEXT and
- NGTRANS working groups is that:
-
- a) AAAA records are preferable at the moment for production
- deployment of IPv6, and
-
- b) that A6 records have interesting properties that need to be
- better understood before deployment.
-
- c) It is not known if the benefits of A6 outweigh the costs and
- risks.
-
-
-2.1 Rationale
-
- There are several potential issues with A6 RRs that stem directly
- from the feature that makes them different from AAAA RRs: the ability
- to build up addresses via chaining.
-
- Resolving a chain of A6 RRs involves resolving a series of what are
- nearly-independent queries. Each of these sub-queries takes some
- non-zero amount of time, unless the answer happens to be in the
- resolver's local cache already. Other things being equal, we expect
- that the time it takes to resolve an N-link chain of A6 RRs will be
- roughly proportional to N. What data we have suggests that users are
- already impatient with the length of time it takes to resolve A RRs
- in the IPv4 Internet, which suggests that users are not likely to be
- patient with significantly longer delays in the IPv6 Internet, but
- terminating queries prematurely is both a waste of resources and
- another source of user frustration. Thus, we are forced to conclude
- that indiscriminate use of long A6 chains is likely to lead to
- increased user frustration.
-
- The probability of failure during the process of resolving an N-link
- A6 chain also appears to be roughly proportional to N, since each of
- the queries involved in resolving an A6 chain has roughly the same
- probability of failure as a single AAAA query.
-
- Last, several of the most interesting potential applications for A6
- RRs involve situations where the prefix name field in the A6 RR
- points to a target that is not only outside the DNS zone containing
- the A6 RR, but is administered by a different organization entirely.
- While pointers out of zone are not a problem per se, experience both
- with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
- pointers to other organizations are often not maintained properly,
- perhaps because they're less susceptible to automation than pointers
-
-
-
-Expires 25/March/2002 DNSEXT [Page 3]
-\f
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
-
-
- within a single organization would be.
-
-2.2 Recommended standard action
-
- Based on the perceived consensus, this document recommend that RFC
- 1886 stay on standards track and be advanced, while moving RFC 2874
- to Experimental status.
-
-3 - Bitlabels in the reverse DNS tree
-
- RFC 2673 defines a new DNS label type. This was the first new type
- defined since RFC 1035[RFC1035]. Since the development of 2673 it has
- been learned that deployment of a new type is difficult since DNS
- servers that do not support bitlabels reject queries containing bit
- labels as being malformed. The community has also indicated that this
- new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
- The hexadecimal text representation of IPv6 addresses appears to be
- capable of expressing all of the delegation schemes that we expect to
- be used in the DNS reverse tree, since we do not ever expect to see
- delegation in the least significant possible hexadecimal label. That
- is, we do not ever expect to see an IPv6 address architecture that
- advocates address delegation in the least significant four bits of an
- IPv6 address.
-
-3.2 Recommended standard action
-
- RFC 2673 standard status is to be changed from Proposed to
- Experimental. Future standardization of these documents is to be done
- by the DNSEXT working group or its successor.
-
-4 DNAME in IPv6 reverse tree
-
- The issues for DNAME chaining in the reverse tree are substantially
- identical to the issues for A6 chaining in the forward tree.
- Therefore, in moving RFC 2874 to experimental, the intent of this
- document is that use of DNAME RRs in the reverse tree be deprecated.
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 25/March/2002 DNSEXT [Page 4]
-\f
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
-
-
-5 Acknowledgments
-
- This document is based on input from many members of the various IETF
- working groups involved in this issues. Special thanks go to the
- people that prepared reading material for the joint DNSEXT and
- NGTRANS working group meeting at the 51st IETF in London, Rob
- Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
- Christian Huitema. Number of other people have made number of
- comments on mailing lists about this issue including Robert Elz ,
- Johan Ihren , Bill Manning
-
-6 - Security Considerations:
-
- As this document specifies a course of action, there are no direct
- security considerations. There is an indirect security impact of the
- choice, in that the relationship between A6 and DNSSEC is not well
- understood throughout the community, while the choice of AAAA does
- leads to a model for use of DNSSEC in IPv6 networks which parallels
- current IPv4 practice.
-
-
-7 - IANA Considerations:
-
- None.
-
-References:
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'' STD 13, RFC 1035, November 1987.
-
-[RFC1886] S. Thompson, C. Huitema, ``DNS Extensions to support IP
- version 6'', RFC 1886, December 1995.
-
-[RFC2673] M. Crawford ``Binary Labels in the Domain Name System``, RFC
- 2673, August 1999.
-
-[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6
- Address Aggregation and Renumbering'', RFC 2874, July 2000.
-
-[RFC3152] R. Bush, ``Delegation of IP6.ARPA'', RFC 3152 also BCP0049,
- August 2001,
-
-[Tradeoff] R. Austein, ``Tradeoffs in DNS support for IPv6'', Work in
- progress, draft-ietf-dnsext-ipv6-dns-tradeoffs-xx.txt, July
- 2001.
-
-
-
-
-
-
-Expires 25/March/2002 DNSEXT [Page 5]
-\f
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
-
-
-Editors Address
-
- Randy Bush <randy@psg.com>
- Alain Durand <alain.durand@sun.com>
- Bob Fink <fink@es.net>
- Olafur Gudmundsson <ogud@ogud.com>
- Tony Hain <hain@tndh.net>
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 25/March/2002 DNSEXT [Page 6]
-
+++ /dev/null
-Internet Draft Philip Hazel
-draft-ietf-dnsop-dontpublish-unreachable-02.txt University of Cambridge
-Valid for six months January 2002
-Category: Best Current Practice
-
-
-
-
- IP Addresses that should never appear in the public DNS
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-Abstract
-
- This document specifies an Internet Best Current Practice for the
- Internet Community. It has two themes. Firstly, it reinforces the
- prohibition in [RFC 1918] about the appearance of private IP
- addresses in publicly visible DNS records. Secondly, the document
- discusses the problems that can be caused by the appearance of public
- addresses, or indirect references to them, when the service implied
- by the address or reference is inaccessible from the public Internet.
-
- Specifying a blanket prohibition in the second case is difficult
- because inaccessibility may arise from many causes, some possibly
- legitimate. Instead, the document points out some of the problems
- that can arise, and suggests that other means of achieving the
- desired effects should be used wherever possible.
-
-
-1. Introduction
-
- The increasing use of firewalls, NAT boxes, and similar technology
- has resulted in the fragmentation of the Internet into regions whose
- boundaries do not allow general connectivity. There are two primary
- reasons for this:
-
- (1) The perceived shortage of IPv4 addresses has caused increasing
- use of private IP network addresses such as 10.0.0.0/8 on LANs. A
- number of such private address ranges are designated in [RFC 1918],
- and others may be also assigned by IANA.
-
-[Note: For example, there's 169.254/16, which is mentioned in
-draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a
-draft, I can't cite it.]
-
- Hosts using private addresses that wish to communicate with the
- public Internet must do so via an address translation mechanism such
- as a NAT box. This allows a host with a private address to send
- packets to public Internet hosts, and to receive replies. However,
- unsolicited incoming packets cannot reach these hosts from outside
- their own private network.
-
- (2) Increasing security concerns have caused many sites to install
- firewalls or to implement restrictions in their boundary routers in
- order to lock out certain kinds of connection to their hosts, even
- when the hosts are using public Internet addresses, though in many
- cases firewalls also provide NAT functionality.
-
- Thus, there are two classes of host which some or all types of
- unexpected incoming packet from the public Internet cannot reach.
-
- A number of instances have been observed where IP addresses that are
- never accessible from the public Internet have nevertheless been
- inserted into resource records in the public DNS. This document seeks
- to prohibit such behaviour in the case of truly private addresses,
- and to discourage it in the case of public, but unreachable,
- addresses.
-
- The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
- The phrase "address record" means an A record or an AAAA record, or
- any other kind of name-to-address record that may come into use.
-
-
-2. Private network addresses
-
- Examples of [RFC 1918] private host addresses are 10.0.0.1 and
- 172.16.42.53. Packets cannot be routed to such addresses from the
- public Internet. [RFC 1918] explains this in section 3, from where
- this paragraph is taken:
-
- Because private addresses have no global meaning, routing
- information about private networks shall not be propagated on
- inter-enterprise links, and packets with private source or
- destination addresses should not be forwarded across such links.
- Routers in networks not using private address space, especially
- those of Internet service providers, are expected to be
- configured to reject (filter out) routing information about
- private networks.
-
- Because the same private addresses are in use in many different
- organizations, they are ambiguous. The appearance of private
- addresses in the DNS could therefore lead to unpredictable and
- unwanted behaviour. Consider this set of entries:
-
- @ IN MX 10 smtp
- smtp IN A 10.1.2.3
- smtp IN A 131.111.10.206
-
- The MX record resolves to two IP addresses, one of which is private
- and one of which is public. Zones set up in this way have been seen,
- and some administrators apparently believe this is useful, because
- it allows mail on their local network to be delivered straight to
- the internal server (the one with address 10.1.2.3). However, this
- approach breaks down when a host on a foreign network that is also
- using the address 10.1.2.3 attempts to send mail to the domain.
-
- In section 5 of [RFC 1918] there is a prohibition of the appearance
- of private addresses in publicly visible DNS records. It says:
-
- If an enterprise uses the private address space, or a mix of
- private and public address spaces, then DNS clients outside of
- the enterprise should not see addresses in the private address
- space used by the enterprise, since these addresses would be
- ambiguous.
-
- The wording "should not" is not a very strong prohibition,
- considering the interworking problems that ignoring it can cause.
- Therefore, this document makes a stronger statement:
-
- Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other
- addresses designated by IANA as private, in any resource records.
-
-
-3. Public network addresses that are inacessible
-
- The situation with public network addresses is more complicated
- because the Internet cannot in general be cleanly divided into
- "public" and "private" parts in this case. Examples of situations
- where the division is fuzzy are:
-
- (1) A host with a public address that is behind a firewall may be
- accessible for SSH sessions, but not for SMTP sessions. That is,
- the blocking may apply only to certain ports.
-
- (2) A host with a public address may make certain services available
- only to specific client hosts, for example, those in partner
- enterprises, or those in a specific geographic area.
-
- (3) A host might respond to incoming packets only if the client host
- is using IPsec.
-
- When a host is providing any service at all over the public Internet,
- a publicly visible address record is of course required to give
- access to that host.
-
- However, for some protocols and services, additional DNS records
- are defined that reference hosts' address records. These are the NS
- record for name servers, the MX record for SMTP, and the SRV record
- for other services. The existence of such indirect records advertises
- the availability of the relevant service.
-
- If these services are always inaccessible over the public Internet,
- it is bad practice to include the NS, MX or SRV records in public DNS
- zones, for the following reason:
-
- A host that tries to connect to an unreachable address (or port)
- may not receive an immediate rejection; in many cases the connection
- will fail only after a timeout expires. The wasted effort ties up
- resources on the calling host and the network, possibly for some
- considerable time (SMTP timeouts, for example, are of the order of
- minutes). It may also cause a gratuitous slowing down of the
- application.
-
- Furthermore, in the case of dial-up connections, ISDN, or other kinds
- of usage-based charged network connection, the wasted network
- resources may cost real money.
-
- Public DNS zones SHOULD NOT contain NS, MX or SRV records that point
- to hosts for which the relevant services are never accessible over the
- public Internet. In other words, if there is no host that is able to
- make use of the service using the public Internet, the service SHOULD
- NOT be publicly advertised.
-
-
-4. Loopback addresses
-
- The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are
- another form of private address. There has been a practice of including
- them in DNS zones for two entirely different reasons.
-
-4.1 The name "localhost"
-
- Some hostmasters include records of this type in their zones:
-
- localhost.some.domain.example. A 127.0.0.1
-
- The reason for doing this is so that other hosts in the domain
- that use the DNS for all their name resolution can make use of the
- unqualified name "localhost". This works because DNS resolvers
- normally add the local enclosing domain to unqualified names.
-
- DNS zones MAY make use of this technique for the name "localhost"
- only, if it is required in their environment, but SHOULD avoid it
- if possible.
-
-4.2 DNS "black lists"
-
- There is an increasingly popular practice of creating "black
- lists" of misbehaving hosts (for example, open mail relays) in
- the DNS. The first of these was the "Realtime Blackhole List"
- (RBL). Such lists make use of addresses in the 127.0.0.0/8
- network in DNS address records to give information about listed
- hosts (which are looked up via their inverted IP addresses).
-
- Such records are in specific "black list" domains, and are well
- understood not to be invitations to attempt connections to the
- addresses they publish.
-
- DNS zones MAY continue to make use of this technique.
-
-4.3 Other uses of loopback networks
-
- Apart from the exceptions mentioned in 4.1 and 4.2 above, the
- loopback addresses MUST NOT appear in address records in the public
- DNS.
-
-4.4 References to loopback addresses
-
- When address records that contain loopback addresses do exist,
- DNS zones MUST NOT contain indirect records (NS, MX or SRV) that
- reference them.
-
-
-5. Alternative techniques
-
-5.1 Splitting DNS zones
-
- A site that is using private addresses may well want to use DNS
- lookups for address resolution on its hosts. The lazy way approach is
- simply to put the data into the public DNS zone, as in the example
- shown in section 2 above. Because this can cause problems for
- external hosts, this MUST NOT be done.
-
- One approach that is commonly taken is to run a so-called "split
- DNS". Two different authoritative servers are created: one containing
- all the zone data is accessible only from within the private network.
- External DNS queries are directed to the second server, which
- contains a filtered version of the zone, without the private
- addresses.
-
-5.2 SMTP servers behind firewalls
-
- The complication of a split DNS is not normally needed if it is only
- SMTP traffic that is being blocked to a public address on a host
- behind a firewall. Setting up MX records like this:
-
- plc.example. MX 5 mail.plc.example.
- MX 10 public.plc.example.
-
- where both hosts have public IP addresses, but the first is blocked
- at the firewall, SHOULD NOT be done. Only the publicly accessible
- host should be used:
-
- plc.example. MX 10 public.plc.example.
-
- If a split DNS is in use, the host public.plc.example can use the
- internal version to route the mail onwards. However, most MTAs have
- configuration facilities to allow for explicit routing of mail, without
- the need to use a DNS lookup.
-
-5.3 Specification of no SMTP service
-
- MX records that point to host names whose address records specify the
- loopback address have been seen in the DNS. This seems to be a
- misguided attempt to specify "no SMTP service for this domain" more
- positively than just refusing connections to the SMTP port. (A refused
- connection is treated as a temporary error, because it might be the
- result of a system rebooting, for example.)
-
- If such a facility is required, it SHOULD instead be done by
- arranging for the hosts in question to return
-
- 554 No SMTP service here
-
- to all SMTP connections.
-
-
-6. Security Considerations
-
- This document is not known to create new security issues in the DNS,
- mail agents, etc. In some sense, it may reduce security exposure by
- insisting that a site's inappropriate internal data not be exposed.
-
-
-7. IANA Considerations
-
- No IANA actions are required by this document.
-
-
-8. Acknowledgements
-
- Randy Bush read an early draft of this document and suggested several
- improvements.
-
- Draft 01 has benefitted from comments made by Daniel Senie, John
- Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire.
-
- Draft 02 has benefitted from comments made by David Keegel and Simon
- Josefsson.
-
-
-9. Author's Address
-
- Philip Hazel
- University of Cambridge Computing Service
- New Museums Site, Pembroke Street
- Cambridge CB2 3QH, England
-
- Phone: + 44 1223 334714
- Email: ph10@cam.ac.uk
-
-
-10. References
-
- [RFC 1918] Rekhter, Y. et al "Address allocation for Private
- Internets", BCP 5, RFC 1918, February 1996.
-
- [RFC 2119] Bradner, S."Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-11. Changes made during development of this document
-
- This section is provided for the convenients of those tracking the
- document. It will be removed from the final draft.
-
-11.1 Changes made to the -00 version to create -01
-
- . While leaving the MUSTs in for truly private addresses, I've tried
- to be more "educational" about the case of public addresses that are
- inaccessible, and backed down to SHOULD in those cases.
-
- . I've pointed out the lack of a clear-cut public/private boundary,
- and tried to make the case for not advertising unavailable services
- without being so probititive in the wording. This includes using
- "never accessible" instead of "not accessible".
-
- . Changed "hostmaster" to "zone" in a couple of cases.
-
- . Included an example of bad MX practice with an [RFC 1918] address.
-
- . Noted that [RFC 1918] is not the only list of private addresses.
-
- . General tidying of the wording and rearrangement of the material.
-
- . The Post Office changed our postcode!
-
-11.2 Changes made to the -01 version to create -02
-
- . Add NS to MX and SRV as another DNS record that advertises a service
- indirectly.
-
- . Changed the address 1.2.3.4 in an example to a genuine real address
- to make it quite clear what I mean.
-
- . Added "geographic area" as another example of a service restriction.
-
- . Suggested why people might want something other than "connection
- refused" from hosts that don't provide SMTP service.
-
- . Some other very minor rewording.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
+++ /dev/null
-\r
-This Internet-Draft has been deleted. Unrevised documents placed in the\r
-Internet-Drafts directories have a maximum life of six months. After\r
-that time, they are deleted. This Internet-Draft was not published as\r
-an RFC.\r
-\r
-Internet-Drafts are not an archival document series, and expired\r
-drafts, such as this one, are not available; please do not ask for\r
-copies... they are not available. The Secretariat does not have\r
-information as to future plans of the authors or working groups WRT the\r
-deleted Internet-Draft.\r
-\r
-For more information or a copy of the document, contact the author directly.\r
-\r
-Draft Author(s):\r
-\r
-O. Kolkman: okolkman@ripe.net \r
-\r
-\r
+++ /dev/null
-IPNG Working Group R.E. Gilligan
-INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-08.txt Cache Flow
-Obsoletes RFC 2553 S. Thomson
- Cisco
- J. Bound
- J. McCann
- Hewlett-Packard
- W. R. Stevens
- October 2002
-
-
- Basic Socket Interface Extensions for IPv6
-
- <draft-ietf-ipngwg-rfc2553bis-08.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- This document is a submission by the Internet Protocol IPv6 Working
- Group of the Internet Engineering Task Force (IETF). Comments should
- be submitted to the ipng@sunroof.eng.sun.com mailing list.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet- Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-Abstract
-
- The de facto standard application program interface (API) for TCP/IP
- applications is the "sockets" interface. Although this API was
- developed for Unix in the early 1980s it has also been implemented on
- a wide variety of non-Unix systems. TCP/IP applications written
- using the sockets API have in the past enjoyed a high degree of
- portability and we would like the same portability with IPv6
- applications. But changes are required to the sockets API to support
- IPv6 and this memo describes these changes. These include a new
- socket address structure to carry IPv6 addresses, new address
- conversion functions, and some new socket options. These extensions
- are designed to provide access to the basic IPv6 features required by
- TCP and UDP applications, including multicasting, while introducing a
- minimum of change into the system and providing complete
- compatibility for existing IPv4 applications. Additional extensions
- for advanced IPv6 features (raw sockets and access to the IPv6
- extension headers) are defined in another document [4].
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 1]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-Table of Contents:
-
-1. Introduction.................................................3
-2. Design Considerations........................................3
-2.1 What Needs to be Changed....................................4
-2.2 Data Types..................................................5
-2.3 Headers.....................................................5
-2.4 Structures..................................................5
-3. Socket Interface.............................................5
-3.1 IPv6 Address Family and Protocol Family.....................6
-3.2 IPv6 Address Structure......................................6
-3.3 Socket Address Structure for 4.3BSD-Based Systems...........6
-3.4 Socket Address Structure for 4.4BSD-Based Systems...........7
-3.5 The Socket Functions........................................8
-3.6 Compatibility with IPv4 Applications........................9
-3.7 Compatibility with IPv4 Nodes...............................9
-3.8 IPv6 Wildcard Address......................................10
-3.9 IPv6 Loopback Address......................................11
-3.10 Portability Additions.....................................11
-4. Interface Identification....................................13
-4.1 Name-to-Index..............................................14
-4.2 Index-to-Name..............................................14
-4.3 Return All Interface Names and Indexes.....................14
-4.4 Free Memory................................................15
-5. Socket Options..............................................15
-5.1 Unicast Hop Limit..........................................15
-5.2 Sending and Receiving Multicast Packets....................16
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets....................18
-6. Library Functions...........................................18
-6.1 Protocol-Independent Nodename and Service Name Translation.19
-6.2 Socket Address Structure to Node Name and Service Name.....23
-6.3 Address Conversion Functions...............................25
-6.4 Address Testing Macros.....................................26
-7. Summary of New Definitions..................................27
-8. Security Considerations.....................................29
-Changes from RFC 2553..........................................29
-Acknowledgments................................................29
-References.....................................................30
-Authors' Addresses.............................................31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 2]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-1. Introduction
-
-While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits long.
-The socket interface makes the size of an IP address quite visible to an
-application; virtually all TCP/IP applications for BSD-based systems
-have knowledge of the size of an IP address. Those parts of the API
-that expose the addresses must be changed to accommodate the larger IPv6
-address size. IPv6 also introduces new features (e.g., traffic class
-and flowlabel), some of which must be made visible to applications via
-the API. This memo defines a set of extensions to the socket interface
-to support the larger address size and new features of IPv6. It defines
-"basic" extensions that are of use to a broad range of applications. A
-companion document, the "advanced" API [4], covers extensions that are
-of use to more specialized applications, examples of which include
-routing daemons, and the "ping" and "traceroute" utilities.
-
-The development of this API was started in 1994 in the IETF IPng working
-group. The API has evolved over the years, published first in RFC 2133,
-then again in RFC 2553, and reaching its final form in this document.
-
-As the API matured and stabilized, it was incorporated into the Open
-Group's Networking Services (XNS) specification, issue 5.2, which was
-subsequently incorporated into a joint Open Group/IEEE/ISO standard [3].
-
-Effort has been made to ensure that this document and [3] contain the
-same information with regard to the API definitions. However, the
-reader should note that this document is for informational purposes
-only, and that the official standard specification of the sockets API is
-[3].
-
-It is expected that any future standardization work on this API would be
-done by the Open Group Base Working Group [6].
-
-It should also be noted that this document describes only those portions
-of the API needed for IPv4 and IPv6 communications. Other potential
-uses of the API, for example the use of getaddrinfo() and getnameinfo()
-with the AF_UNIX address family, are beyond the scope of this document.
-
-
-
-2. Design Considerations
-
-There are a number of important considerations in designing changes to
-this well-worn API:
-
- - The API changes should provide both source and binary
- compatibility for programs written to the original API. That
- is, existing program binaries should continue to operate when
- run on a system supporting the new API. In addition, existing
- applications that are re-compiled and run on a system supporting
- the new API should continue to operate. Simply put, the API
- changes for IPv6 should not break existing programs. An additional
- mechanism for implementations to verify this is to verify the new
- symbols are protected by Feature Test Macros as described in [3].
- (Such Feature Test Macros are not defined by this RFC.)
-
- - The changes to the API should be as small as possible in order
- to simplify the task of converting existing IPv4 applications to
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 3]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- IPv6.
-
- - Where possible, applications should be able to use this
- API to interoperate with both IPv6 and IPv4 hosts. Applications
- should not need to know which type of host they are
- communicating with.
-
- - IPv6 addresses carried in data structures should be 64-bit
- aligned. This is necessary in order to obtain optimum
- performance on 64-bit machine architectures.
-
-Because of the importance of providing IPv4 compatibility in the API,
-these extensions are explicitly designed to operate on machines that
-provide complete support for both IPv4 and IPv6. A subset of this API
-could probably be designed for operation on systems that support only
-IPv6. However, this is not addressed in this memo.
-
-
-
-2.1 What Needs to be Changed
-
-The socket interface API consists of a few distinct components:
-
- - Core socket functions.
-
- - Address data structures.
-
- - Name-to-address translation functions.
-
- - Address conversion functions.
-
-The core socket functions -- those functions that deal with such things
-as setting up and tearing down TCP connections, and sending and
-receiving UDP packets -- were designed to be transport independent.
-Where protocol addresses are passed as function arguments, they are
-carried via opaque pointers. A protocol-specific address data structure
-is defined for each protocol that the socket functions support.
-Applications must cast pointers to these protocol-specific address
-structures into pointers to the generic "sockaddr" address structure
-when using the socket functions. These functions need not change for
-IPv6, but a new IPv6-specific address data structure is needed.
-
-The "sockaddr_in" structure is the protocol-specific data structure for
-IPv4. This data structure actually includes 8-octets of unused space,
-and it is tempting to try to use this space to adapt the sockaddr_in
-structure to IPv6. Unfortunately, the sockaddr_in structure is not
-large enough to hold the 16-octet IPv6 address as well as the other
-information (address family and port number) that is needed. So a new
-address data structure must be defined for IPv6.
-
-IPv6 addresses are scoped [2] so they could be link-local, site,
-organization, global, or other scopes at this time undefined. To
-support applications that want to be able to identify a set of
-interfaces for a specific scope, the IPv6 sockaddr_in structure must
-support a field that can be used by an implementation to identify a set
-of interfaces identifying the scope for an IPv6 address.
-
-The IPv4 name-to-address translation functions in the socket interface
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 4]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-are gethostbyname() and gethostbyaddr(). These are left as is, and new
-functions are defined which support both IPv4 and IPv6.
-
-The IPv4 address conversion functions -- inet_ntoa() and inet_addr() --
-convert IPv4 addresses between binary and printable form. These
-functions are quite specific to 32-bit IPv4 addresses. We have designed
-two analogous functions that convert both IPv4 and IPv6 addresses, and
-carry an address type parameter so that they can be extended to other
-protocol families as well.
-
-Finally, a few miscellaneous features are needed to support IPv6. New
-interfaces are needed to support the IPv6 traffic class, flow label, and
-hop limit header fields. New socket options are needed to control the
-sending and receiving of IPv6 multicast packets.
-
-The socket interface will be enhanced in the future to provide access to
-other IPv6 features. These extensions are described in [4].
-
-
-
-
-2.2 Data Types
-
-The data types of the structure elements given in this memo are intended
-to track the relevant standards. uintN_t means an unsigned integer of
-exactly N bits (e.g., uint16_t). The sa_family_t and in_port_t types
-are defined in [3].
-
-
-
-2.3 Headers
-
-When function prototypes and structures are shown we show the headers
-that must be #included to cause that item to be defined.
-
-
-
-2.4 Structures
-
-When structures are described the members shown are the ones that must
-appear in an implementation. Additional, nonstandard members may also
-be defined by an implementation. As an additional precaution
-nonstandard members could be verified by Feature Test Macros as
-described in [3]. (Such Feature Test Macros are not defined by this
-RFC.)
-
-The ordering shown for the members of a structure is the recommended
-ordering, given alignment considerations of multibyte members, but an
-implementation may order the members differently.
-
-
-
-3. Socket Interface
-
-This section specifies the socket interface changes for IPv6.
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 5]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-3.1 IPv6 Address Family and Protocol Family
-
-A new address family name, AF_INET6, is defined in <sys/socket.h>. The
-AF_INET6 definition distinguishes between the original sockaddr_in
-address data structure, and the new sockaddr_in6 data structure.
-
-A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-Like most of the other protocol family names, this will usually be
-defined to have the same value as the corresponding address family name:
-
- #define PF_INET6 AF_INET6
-
-The AF_INET6 is used in the first argument to the socket() function to
-indicate that an IPv6 socket is being created.
-
-
-
-3.2 IPv6 Address Structure
-
-A new in6_addr structure holds a single IPv6 address and is defined as a
-result of including <netinet/in.h>:
-
- struct in6_addr {
- uint8_t s6_addr[16]; /* IPv6 address */
- };
-
-This data structure contains an array of sixteen 8-bit elements, which
-make up one 128-bit IPv6 address. The IPv6 address is stored in network
-byte order.
-
-The structure in6_addr above is usually implemented with an embedded
-union with extra fields that force the desired alignment level in a
-manner similar to BSD implementations of "struct in_addr". Those
-additional implementation details are omitted here for simplicity.
-
-An example is as follows:
-
-struct in6_addr {
- union {
- uint8_t _S6_u8[16];
- uint32_t _S6_u32[4];
- uint64_t _S6_u64[2];
- } _S6_un;
-};
-#define s6_addr _S6_un._S6_u8
-
-
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-In the socket interface, a different protocol-specific data structure is
-defined to carry the addresses for each protocol suite. Each protocol-
-specific data structure is designed so it can be cast into a protocol-
-independent data structure -- the "sockaddr" structure. Each has a
-"family" field that overlays the "sa_family" of the sockaddr data
-structure. This field identifies the type of the data structure.
-
-The sockaddr_in structure is the protocol-specific address data
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 6]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-structure for IPv4. It is used to pass addresses between applications
-and the system in the socket functions. The following sockaddr_in6
-structure holds IPv6 addresses and is defined as a result of including
-the <netinet/in.h> header:
-
- struct sockaddr_in6 {
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
- };
-
-This structure is designed to be compatible with the sockaddr data
-structure used in the 4.3BSD release.
-
-The sin6_family field identifies this as a sockaddr_in6 structure. This
-field overlays the sa_family field when the buffer is cast to a sockaddr
-data structure. The value of this field must be AF_INET6.
-
-The sin6_port field contains the 16-bit UDP or TCP port number. This
-field is used in the same way as the sin_port field of the sockaddr_in
-structure. The port number is stored in network byte order.
-
-The sin6_flowinfo field is a 32-bit field intended to contain
-flow-related information. The exact use of this field is not
-currently specified.
-
-The sin6_addr field is a single in6_addr structure (defined in the
-previous section). This field holds one 128-bit IPv6 address. The
-address is stored in network byte order.
-
-The ordering of elements in this structure is specifically designed so
-that when sin6_addr field is aligned on a 64-bit boundary, the start of
-the structure will also be aligned on a 64-bit boundary. This is done
-for optimum performance on 64-bit architectures.
-
-The sin6_scope_id field is a 32-bit integer that identifies a set of
-interfaces as appropriate for the scope [2] of the address carried in
-the sin6_addr field. The mapping of sin6_scope_id to an interface or
-set of interfaces is left to implementation and future specifications on
-the subject of scoped addresses.
-
-Notice that the sockaddr_in6 structure will normally be larger than the
-generic sockaddr structure. On many existing implementations the
-sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-being 16 bytes. Any existing code that makes this assumption needs to
-be examined carefully when converting to IPv6.
-
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-The 4.4BSD release includes a small, but incompatible change to the
-socket interface. The "sa_family" field of the sockaddr data structure
-was changed from a 16-bit value to an 8-bit value, and the space saved
-used to hold a length field, named "sa_len". The sockaddr_in6 data
-structure given in the previous section cannot be correctly cast into
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 7]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-the newer sockaddr data structure. For this reason, the following
-alternative IPv6 address data structure is provided to be used on
-systems based on 4.4BSD. It is defined as a result of including the
-<netinet/in.h> header.
-
- struct sockaddr_in6 {
- uint8_t sin6_len; /* length of this struct */
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
- };
-
-The only differences between this data structure and the 4.3BSD variant
-are the inclusion of the length field, and the change of the family
-field to a 8-bit data type. The definitions of all the other fields are
-identical to the structure defined in the previous section.
-
-Systems that provide this version of the sockaddr_in6 data structure
-must also declare SIN6_LEN as a result of including the <netinet/in.h>
-header. This macro allows applications to determine whether they are
-being built on a system that supports the 4.3BSD or 4.4BSD variants of
-the data structure.
-
-
-
-3.5 The Socket Functions
-
-Applications call the socket() function to create a socket descriptor
-that represents a communication endpoint. The arguments to the socket()
-function tell the system which protocol to use, and what format address
-structure will be used in subsequent functions. For example, to create
-an IPv4/TCP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_STREAM, 0);
-
-To create an IPv4/UDP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_DGRAM, 0);
-
-Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
-handle IPv4 communication as described in section 3.7) by simply using
-the constant AF_INET6 instead of AF_INET in the first argument. For
-example, to create an IPv6/TCP socket, applications make the call:
-
- s = socket(AF_INET6, SOCK_STREAM, 0);
-
-To create an IPv6/UDP socket, applications make the call:
-
- s = socket(AF_INET6, SOCK_DGRAM, 0);
-
-Once the application has created a AF_INET6 socket, it must use the
-sockaddr_in6 address structure when passing addresses in to the system.
-The functions that the application uses to pass addresses into the
-system are:
-
- bind()
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 8]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- connect()
- sendmsg()
- sendto()
-
-The system will use the sockaddr_in6 address structure to return
-addresses to applications that are using AF_INET6 sockets. The
-functions that return an address from the system to an application are:
-
- accept()
- recvfrom()
- recvmsg()
- getpeername()
- getsockname()
-
-No changes to the syntax of the socket functions are needed to support
-IPv6, since all of the "address carrying" functions use an opaque
-address pointer, and carry an address length as a function argument.
-
-
-
-3.6 Compatibility with IPv4 Applications
-
-In order to support the large base of applications using the original
-API, system implementations must provide complete source and binary
-compatibility with the original API. This means that systems must
-continue to support AF_INET sockets and the sockaddr_in address
-structure. Applications must be able to create IPv4/TCP and IPv4/UDP
-sockets using the AF_INET constant in the socket() function, as
-described in the previous section. Applications should be able to hold
-a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets
-simultaneously within the same process.
-
-Applications using the original API should continue to operate as they
-did on systems supporting only IPv4. That is, they should continue to
-interoperate with IPv4 nodes.
-
-
-
-3.7 Compatibility with IPv4 Nodes
-
-The API also provides a different type of compatibility: the ability for
-IPv6 applications to interoperate with IPv4 applications. This feature
-uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing
-architecture specification [2]. This address format allows the IPv4
-address of an IPv4 node to be represented as an IPv6 address. The IPv4
-address is encoded into the low-order 32 bits of the IPv6 address, and
-the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4-
-mapped addresses are written as follows:
-
- ::FFFF:<IPv4-address>
-
-These addresses can be generated automatically by the getaddrinfo()
-function, as described in Section 6.1.
-
-Applications may use AF_INET6 sockets to open TCP connections to IPv4
-nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-destination's IPv4 address as an IPv4-mapped IPv6 address, and passing
-that address, within a sockaddr_in6 structure, in the connect() or
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 9]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-sendto() call. When applications use AF_INET6 sockets to accept TCP
-connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the
-system returns the peer's address to the application in the accept(),
-recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded
-this way.
-
-Few applications will likely need to know which type of node they are
-interoperating with. However, for those applications that do need to
-know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
-provided.
-
-
-
-3.8 IPv6 Wildcard Address
-
-While the bind() function allows applications to select the source IP
-address of UDP packets and TCP connections, applications often want the
-system to select the source address for them. With IPv4, one specifies
-the address as the symbolic constant INADDR_ANY (called the "wildcard"
-address) in the bind() call, or simply omits the bind() entirely.
-
-Since the IPv6 address type is a structure (struct in6_addr), a symbolic
-constant can be used to initialize an IPv6 address variable, but cannot
-be used in an assignment. Therefore systems provide the IPv6 wildcard
-address in two forms.
-
-The first version is a global variable named "in6addr_any" that is an
-in6_addr structure. The extern declaration for this variable is defined
-in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_any;
-
-Applications use in6addr_any similarly to the way they use INADDR_ANY in
-IPv4. For example, to bind a socket to port number 23, but let the
-system select the source address, an application could use the following
-code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_any; /* structure assignment */
- . . .
- if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
-The other version is a symbolic constant named IN6ADDR_ANY_INIT and is
-defined in <netinet/in.h>. This constant can be used to initialize an
-in6_addr structure:
-
- struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-Note that this constant can be used ONLY at declaration time. It can
-not be used to assign a previously declared in6_addr structure. For
-example, the following code will not work:
-
- /* This is the WRONG way to assign an unspecified address */
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 10]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-Be aware that the IPv4 INADDR_xxx constants are all defined in host byte
-order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx
-externals are defined in network byte order.
-
-
-
-3.9 IPv6 Loopback Address
-
-Applications may need to send UDP packets to, or originate TCP
-connections to, services residing on the local node. In IPv4, they can
-do this by using the constant IPv4 address INADDR_LOOPBACK in their
-connect(), sendto(), or sendmsg() call.
-
-IPv6 also provides a loopback address to contact local TCP and UDP
-services. Like the unspecified address, the IPv6 loopback address is
-provided in two forms -- a global variable and a symbolic constant.
-
-The global variable is an in6_addr structure named "in6addr_loopback."
-The extern declaration for this variable is defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_loopback;
-
-Applications use in6addr_loopback as they would use INADDR_LOOPBACK in
-IPv4 applications (but beware of the byte ordering difference mentioned
-at the end of the previous section). For example, to open a TCP
-connection to the local telnet server, an application could use the
-following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_loopback; /* structure assignment */
- . . .
- if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
-The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in
-<netinet/in.h>. It can be used at declaration time ONLY; for example:
-
- struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to
-a previously declared IPv6 address variable.
-
-
-
-3.10 Portability Additions
-
-One simple addition to the sockets API that can help application writers
-is the "struct sockaddr_storage". This data structure can simplify
-writing code that is portable across multiple address families and
-platforms. This data structure is designed with the following goals.
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 11]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- - Large enough to accommodate all supported protocol-specific address
- structures.
-
- - Aligned at an appropriate boundary so that pointers to it can be cast
- as pointers to protocol specific address structures and used to
- access the fields of those structures without alignment problems.
-
-
-The sockaddr_storage structure contains field ss_family which is of type
-sa_family_t. When a sockaddr_storage structure is cast to a sockaddr
-structure, the ss_family field of the sockaddr_storage structure maps
-onto the sa_family field of the sockaddr structure. When a
-sockaddr_storage structure is cast as a protocol specific address
-structure, the ss_family field maps onto a field of that structure that
-is of type sa_family_t and that identifies the protocol's address
-family.
-
-An example implementation design of such a data structure would be as
-follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE 128 /* Implementation specific max size */
-#define _SS_ALIGNSIZE (sizeof (int64_t))
- /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_family */
- /* __ss_pad1, __ss_align fields is 112 */
-};
-
-The above example implementation illustrates a data structure which will
-align on a 64-bit boundary. An implementation-specific field
-"__ss_align" along with "__ss_pad1" is used to force a 64-bit alignment
-which covers proper alignment good enough for the needs of sockaddr_in6
-(IPv6), sockaddr_in (IPv4) address data structures. The size of padding
-field __ss_pad1 depends on the chosen alignment boundary. The size of
-padding field __ss_pad2 depends on the value of overall size chosen for
-the total size of the structure. This size and alignment are represented
-in the above example by implementation specific (not required) constants
-_SS_MAXSIZE (chosen value 128) and _SS_ALIGNSIZE (with chosen value 8).
-Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 12]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-112) are also for illustration and not required. The derived values
-assume sa_family_t is 2 bytes. The implementation specific definitions
-and structure field names above start with an underscore to denote
-implementation private namespace. Portable code is not expected to
-access or reference those fields or constants.
-
-On implementations where the sockaddr data structure includes a "sa_len"
-field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- uint8_t ss_len; /* address length */
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_len, */
- /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-
-
-4. Interface Identification
-
-This API uses an interface index (a small positive integer) to identify
-the local interface on which a multicast group is joined (Section 5.3).
-Additionally, the advanced API [4] uses these same interface indexes to
-identify the interface on which a datagram is received, or to specify
-the interface on which a datagram is to be sent.
-
-Interfaces are normally known by names such as "le0", "sl1", "ppp2", and
-the like. On Berkeley-derived implementations, when an interface is
-made known to the system, the kernel assigns a unique positive integer
-value (called the interface index) to that interface. These are small
-positive integers that start at 1. (Note that 0 is never used for an
-interface index.) There may be gaps so that there is no current
-interface for a particular positive interface index.
-
-This API defines two functions that map between an interface name and
-index, a third function that returns all the interface names and
-indexes, and a fourth function to return the dynamic memory allocated by
-the previous function. How these functions are implemented is left up
-to the implementation. 4.4BSD implementations can implement these
-functions using the existing sysctl() function with the NET_RT_IFLIST
-command. Other implementations may wish to use ioctl() for this
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 13]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-purpose.
-
-
-
-4.1 Name-to-Index
-
-The first function maps an interface name into its corresponding index.
-
- #include <net/if.h>
-
- unsigned int if_nametoindex(const char *ifname);
-
-If ifname is the name of an interface, the if_nametoindex() function
-shall return the interface index corresponding to name ifname;
-otherwise, it shall return zero. No errors are defined.
-
-
-
-4.2 Index-to-Name
-
-The second function maps an interface index into its corresponding name.
-
- #include <net/if.h>
-
- char *if_indextoname(unsigned int ifindex, char *ifname);
-
-When this function is called, the ifname argument shall point to a
-buffer of at least IF_NAMESIZE bytes. The function shall place in this
-buffer the name of the interface with index ifindex. (IF_NAMESIZE is
-also defined in <net/if.h> and its value includes a terminating null
-byte at the end of the interface name.) If ifindex is an interface
-index, then the function shall return the value supplied in ifname,
-which points to a buffer now containing the interface name. Otherwise,
-the function shall return a NULL pointer and set errno to indicate the
-error. If there is no interface corresponding to the specified index,
-errno is set to ENXIO. If there was a system error (such as running out
-of memory), errno would be set to the proper value (e.g., ENOMEM).
-
-
-
-4.3 Return All Interface Names and Indexes
-
-The if_nameindex structure holds the information about a single
-interface and is defined as a result of including the <net/if.h> header.
-
- struct if_nameindex {
- unsigned int if_index; /* 1, 2, ... */
- char *if_name; /* null terminated name: "le0", ... */
- };
-
-The final function returns an array of if_nameindex structures, one
-structure per interface.
-
- #include <net/if.h>
-
- struct if_nameindex *if_nameindex(void);
-
-The end of the array of structures is indicated by a structure with an
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 14]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-if_index of 0 and an if_name of NULL. The function returns a NULL
-pointer upon an error, and would set errno to the appropriate value.
-
-The memory used for this array of structures along with the interface
-names pointed to by the if_name members is obtained dynamically. This
-memory is freed by the next function.
-
-
-
-4.4 Free Memory
-
-The following function frees the dynamic memory that was allocated by
-if_nameindex().
-
- #include <net/if.h>
-
- void if_freenameindex(struct if_nameindex *ptr);
-
-The ptr argument shall be a pointer that was returned by if_nameindex().
-After if_freenameindex() has been called, the application shall not use
-the array of which ptr is the address.
-
-
-
-5. Socket Options
-
-A number of new socket options are defined for IPv6. All of these new
-options are at the IPPROTO_IPV6 level. That is, the "level" parameter
-in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using
-these options. The constant name prefix IPV6_ is used in all of the new
-socket options. This serves to clearly identify these options as
-applying to IPv6.
-
-The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-related constants defined in this section are obtained by including the
-header <netinet/in.h>.
-
-
-
-5.1 Unicast Hop Limit
-
-A new setsockopt() option controls the hop limit used in outgoing
-unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and
-it is used at the IPPROTO_IPV6 layer. The following example illustrates
-how it is used:
-
- int hoplimit = 10;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, sizeof(hoplimit)) == -1)
- perror("setsockopt IPV6_UNICAST_HOPS");
-
-When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option
-value given is used as the hop limit for all subsequent unicast packets
-sent via that socket. If the option is not set, the system selects a
-default value. The integer hop limit value (called x) is interpreted as
-follows:
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 15]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine
-the hop limit value that the system will use for subsequent unicast
-packets sent via that socket. For example:
-
- int hoplimit;
- socklen_t len = sizeof(hoplimit);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, &len) == -1)
- perror("getsockopt IPV6_UNICAST_HOPS");
- else
- printf("Using %d for hop limit.\n", hoplimit);
-
-
-
-5.2 Sending and Receiving Multicast Packets
-
-IPv6 applications may send multicast packets by simply specifying an
-IPv6 multicast address as the destination address, for example in the
-destination address argument of the sendto() function.
-
-Three socket options at the IPPROTO_IPV6 layer control some of the
-parameters for sending multicast packets. Setting these options is not
-required: applications may send multicast packets without using these
-options. The setsockopt() options for controlling the sending of
-multicast packets are summarized below. These three options can also be
-used with getsockopt().
-
- IPV6_MULTICAST_IF
-
- Set the interface to use for outgoing multicast packets.
- The argument is the index of the interface to use.
- If the interface index is specified as zero, the system
- selects the interface (for example, by looking up the
- address in a routing table and using the resulting interface).
-
- Argument type: unsigned int
-
- IPV6_MULTICAST_HOPS
-
- Set the hop limit to use for outgoing multicast packets.
- (Note a separate option - IPV6_UNICAST_HOPS - is
- provided to set the hop limit to use for outgoing
- unicast packets.)
-
- The interpretation of the argument is the same
- as for the IPV6_UNICAST_HOPS option:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 16]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- If IPV6_MULTICAST_HOPS is not set, the default is 1
- (same as IPv4 today)
-
- Argument type: int
-
- IPV6_MULTICAST_LOOP
-
- If a multicast datagram is sent to a group to which the sending host
- itself belongs (on the outgoing interface), a copy of the datagram is
- looped back by the IP layer for local delivery if this option is set to
- 1. If this option is set to 0 a copy is not looped back. Other option
- values return an error of EINVAL.
-
- If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as
- IPv4 today).
-
- Argument type: unsigned int
-
-The reception of multicast packets is controlled by the two setsockopt()
-options summarized below. An error of EOPNOTSUPP is returned if these
-two options are used with getsockopt().
-
- IPV6_JOIN_GROUP
-
- Join a multicast group on a specified local interface.
- If the interface index is specified as 0,
- the kernel chooses the local interface.
- For example, some kernels look up the multicast group
- in the normal IPv6 routing table and use the resulting interface.
-
- Argument type: struct ipv6_mreq
-
- IPV6_LEAVE_GROUP
-
- Leave a multicast group on a specified interface.
- If the interface index is specified as 0, the system
- may choose a multicast group membership to drop by
- matching the multicast address only.
-
- Argument type: struct ipv6_mreq
-
-The argument type of both of these options is the ipv6_mreq structure,
-defined as a result of including the <netinet/in.h> header;
-
- struct ipv6_mreq {
- struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
- unsigned int ipv6mr_interface; /* interface index */
- };
-
-Note that to receive multicast datagrams a process must join the
-multicast group to which datagrams will be sent. UDP applications must
-also bind the UDP port to which datagrams will be sent. Some processes
-also bind the multicast group address to the socket, in addition to the
-port, to prevent other datagrams destined to that same port from being
-delivered to the socket.
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 17]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
-This socket option restricts AF_INET6 sockets to IPv6 communications
-only. As stated in section <3.7 Compatibility with IPv4 Nodes>,
-AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some
-applications may want to restrict their use of an AF_INET6 socket to
-IPv6 communications only. For these applications the IPV6_V6ONLY socket
-option is defined. When this option is turned on, the socket can be
-used to send and receive IPv6 packets only. This is an IPPROTO_IPV6
-level option. This option takes an int value. This is a boolean
-option. By default this option is turned off.
-
- Here is an example of setting this option:
-
- int on = 1;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
- (char *)&on, sizeof(on)) == -1)
- perror("setsockopt IPV6_V6ONLY");
- else
- printf("IPV6_V6ONLY set\n");
-
-Note - This option has no effect on the use of IPv4 Mapped addresses
-which enter a node as a valid IPv6 addresses for IPv6 communications as
-defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
-An example use of this option is to allow two versions of the same
-server process to run on the same port, one providing service over IPv6,
-the other providing the same service over IPv4.
-
-
-
-
-6. Library Functions
-
-New library functions are needed to perform a variety of operations with
-IPv6 addresses. Functions are needed to lookup IPv6 addresses in the
-Domain Name System (DNS). Both forward lookup (nodename-to-address
-translation) and reverse lookup (address-to-nodename translation) need
-to be supported. Functions are also needed to convert IPv6 addresses
-between their binary and textual form.
-
-We note that the two existing functions, gethostbyname() and
-gethostbyaddr(), are left as-is. New functions are defined to handle
-both IPv4 and IPv6 addresses.
-
-The commonly used function gethostbyname() is inadequate for many
-applications, first because it provides no way for the caller to specify
-anything about the types of addresses desired (IPv4 only, IPv6 only,
-IPv4-mapped IPv6 are OK, etc.), and second because many implementations
-of this function are not thread safe. RFC 2133 defined a function named
-gethostbyname2() but this function was also inadequate, first because
-its use required setting a global option (RES_USE_INET6) when IPv6
-addresses were required, and second because a flag argument is needed to
-provide the caller with additional control over the types of addresses
-required. The gethostbyname2() function was deprecated in RFC 2553 and
-is no longer part of the basic API.
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 18]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
-Nodename-to-address translation is done in a protocol-independent
-fashion using the getaddrinfo() function.
-
- #include <sys/socket.h>
- #include <netdb.h>
-
-
- int getaddrinfo(const char *nodename, const char *servname,
- const struct addrinfo *hints, struct addrinfo **res);
-
- void freeaddrinfo(struct addrinfo *ai);
-
- struct addrinfo {
- int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */
- int ai_family; /* AF_xxx */
- int ai_socktype; /* SOCK_xxx */
- int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
- socklen_t ai_addrlen; /* length of ai_addr */
- char *ai_canonname; /* canonical name for nodename */
- struct sockaddr *ai_addr; /* binary address */
- struct addrinfo *ai_next; /* next structure in linked list */
- };
-
- The getaddrinfo() function translates the name of a service location
- (for example, a host name) and/or a service name and returns a set of
- socket addresses and associated information to be used in creating a
- socket with which to address the specified service.
-
- The nodename and servname arguments are either null pointers or
- pointers to null-terminated strings. One or both of these two
- arguments must be a non-null pointer.
-
- The format of a valid name depends on the address family or families.
- If a specific family is not given and the name could be interpreted
- as valid within multiple supported families, the implementation will
- attempt to resolve the name in all supported families and, in absence
- of errors, one or more results shall be returned.
-
- If the nodename argument is not null, it can be a descriptive name or
- can be an address string. If the specified address family is AF_INET,
- AF_INET6, or AF_UNSPEC, valid descriptive names include host names.
- If the specified address family is AF_INET or AF_UNSPEC, address
- strings using Internet standard dot notation as specified in
- inet_addr() are valid. If the specified address family is AF_INET6
- or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
- valid.
-
- If nodename is not null, the requested service location is named by
- nodename; otherwise, the requested service location is local to the
- caller.
-
- If servname is null, the call shall return network-level addresses
- for the specified nodename. If servname is not null, it is a null-
- terminated character string identifying the requested service. This
- can be either a descriptive name or a numeric representation suitable
- for use with the address family or families. If the specified address
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 19]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
- specified as a string specifying a decimal port number.
-
- If the argument hints is not null, it refers to a structure
- containing input values that may direct the operation by providing
- options and by limiting the returned information to a specific socket
- type, address family and/or protocol. In this hints structure every
- member other than ai_flags, ai_family, ai_socktype and ai_protocol
- shall be set to zero or a null pointer. A value of AF_UNSPEC for
- ai_family means that the caller shall accept any address family. A
- value of zero for ai_socktype means that the caller shall accept any
- socket type. A value of zero for ai_protocol means that the caller
- shall accept any protocol. If hints is a null pointer, the behavior
- shall be as if it referred to a structure containing the value zero
- for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
- for the ai_family field.
-
- Note:
-
- 1. If the caller handles only TCP and not UDP, for example, then the
- ai_protocol member of the hints structure should be set to
- IPPROTO_TCP when getaddrinfo() is called.
-
- 2. If the caller handles only IPv4 and not IPv6, then the ai_family
- member of the hints structure should be set to AF_INET when
- getaddrinfo() is called.
-
- The ai_flags field to which hints parameter points shall be set to
- zero or be the bitwise-inclusive OR of one or more of the values
- AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
- AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
- If the AI_PASSIVE flag is specified, the returned address information
- shall be suitable for use in binding a socket for accepting incoming
- connections for the specified service (i.e. a call to bind()). In
- this case, if the nodename argument is null, then the IP address
- portion of the socket address structure shall be set to INADDR_ANY
- for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the
- AI_PASSIVE flag is not specified, the returned address information
- shall be suitable for a call to connect() (for a connection-mode
- protocol) or for a call to connect(), sendto() or sendmsg() (for a
- connectionless protocol). In this case, if the nodename argument is
- null, then the IP address portion of the socket address structure
- shall be set to the loopback address. This flag is ignored if the
- nodename argument is not null.
-
- If the AI_CANONNAME flag is specified and the nodename argument is
- not null, the function shall attempt to determine the canonical name
- corresponding to nodename (for example, if nodename is an alias or
- shorthand notation for a complete name).
-
- If the AI_NUMERICHOST flag is specified, then a non-null nodename
- string supplied shall be a numeric host address string. Otherwise, an
- [EAI_NONAME] error is returned. This flag shall prevent any type of
- name resolution service (for example, the DNS) from being invoked.
-
- If the AI_NUMERICSERV flag is specified, then a non-null servname
- string supplied shall be a numeric port string. Otherwise, an
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 20]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- [EAI_NONAME] error shall be returned. This flag shall prevent any
- type of name resolution service (for example, NIS+) from being
- invoked.
-
- If the AI_V4MAPPED flag is specified along with an ai_family of
- AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
- on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
- For example, when using the DNS, if no AAAA records are found
- then a query is made for A records and any found are returned as
- IPv4-mapped IPv6 addresses.
-
- The AI_V4MAPPED flag shall be ignored unless ai_family equals
- AF_INET6.
-
- If the AI_ALL flag is used with the AI_V4MAPPED flag, then
- getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
- For example, when using the DNS, queries are made for both AAAA
- records and A records, and getaddrinfo() returns the combined
- results of both queries. Any IPv4 addresses found are returned
- as IPv4-mapped IPv6 addresses.
-
- The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
- Note:
-
- When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
- AI_ALL flags will only be used if AF_INET6 is supported.
-
- If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
- returned only if an IPv4 address is configured on the local system,
- and IPv6 addresses shall be returned only if an IPv6 address is
- configured on the local system. The loopback address is not
- considered for this case as valid as a configured address.
-
- For example, when using the DNS, a query for AAAA records
- should occur only if the node has at least one IPv6 address
- configured (other than IPv6 loopback) and a query for A records
- should occur only if the node has at least one IPv4 address
- configured (other than the IPv4 loopback).
-
- The ai_socktype field to which argument hints points specifies the
- socket type for the service, as defined for socket(). If a specific
- socket type is not given (for example, a value of zero) and the
- service name could be interpreted as valid with multiple supported
- socket types, the implementation shall attempt to resolve the service
- name for all supported socket types and, in the absence of errors,
- all possible results shall be returned. A non-zero socket type value
- shall limit the returned information to values with the specified
- socket type.
-
- If the ai_family field to which hints points has the value AF_UNSPEC,
- addresses shall be returned for use with any address family that can
- be used with the specified nodename and/or servname. Otherwise,
- addresses shall be returned for use only with the specified address
- family. If ai_family is not AF_UNSPEC and ai_protocol is not zero,
- then addresses are returned for use only with the specified address
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 21]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- family and protocol; the value of ai_protocol shall be interpreted as
- in a call to the socket() function with the corresponding values of
- ai_family and ai_protocol .
-
- The freeaddrinfo() function frees one or more addrinfo structures
- returned by getaddrinfo(), along with any additional storage
- associated with those structures (for example, storage pointed to by
- the ai_canonname and ai_addr fields; an application must not
- reference this storage after the associated addrinfo structure has
- been freed). If the ai_next field of the structure is not null, the
- entire list of structures is freed. The freeaddrinfo() function must
- support the freeing of arbitrary sublists of an addrinfo list
- originally returned by getaddrinfo().
-
- Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
- A zero return value for getaddrinfo() indicates successful
- completion; a non-zero return value indicates failure. The possible
- values for the failures are listed below under Error Return Values.
-
- Upon successful return of getaddrinfo(), the location to which res
- points shall refer to a linked list of addrinfo structures, each of
- which shall specify a socket address and information for use in
- creating a socket with which to use that socket address. The list
- shall include at least one addrinfo structure. The ai_next field of
- each structure contains a pointer to the next structure on the list,
- or a null pointer if it is the last structure on the list. Each
- structure on the list shall include values for use with a call to the
- socket() function, and a socket address for use with the connect()
- function or, if the AI_PASSIVE flag was specified, for use with the
- bind() function. The fields ai_family, ai_socktype, and ai_protocol
- shall be usable as the arguments to the socket() function to create a
- socket suitable for use with the returned address. The fields ai_addr
- and ai_addrlen are usable as the arguments to the connect() or bind()
- functions with such a socket, according to the AI_PASSIVE flag.
-
- If nodename is not null, and if requested by the AI_CANONNAME flag,
- the ai_canonname field of the first returned addrinfo structure shall
- point to a null-terminated string containing the canonical name
- corresponding to the input nodename; if the canonical name is not
- available, then ai_canonname shall refer to the nodename argument or
- a string with the same contents. The contents of the ai_flags field
- of the returned structures are undefined.
-
- All fields in socket address structures returned by getaddrinfo()
- that are not filled in through an explicit argument (for example,
- sin6_flowinfo) shall be set to zero.
-
- Note: This makes it easier to compare socket address structures.
-
- Error Return Values:
-
- The getaddrinfo() function shall fail and return the corresponding
- value if:
-
- [EAI_AGAIN] The name could not be resolved at this time. Future
- attempts may succeed.
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 22]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- [EAI_BADFLAGS] The flags parameter had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred when attempting to
- resolve the name.
-
- [EAI_FAMILY] The address family was not recognized.
-
- [EAI_MEMORY] There was a memory allocation failure when trying to
- allocate storage for the return value.
-
- [EAI_NONAME] The name does not resolve for the supplied parameters.
- Neither nodename nor servname were supplied. At least one
- of these must be supplied.
-
- [EAI_SERVICE] The service passed was not recognized for the specified
- socket type.
-
- [EAI_SOCKTYPE] The intended socket type was not recognized.
-
- [EAI_SYSTEM] A system error occurred; the error code can be found in
- errno.
-
-The gai_strerror() function provides a descriptive text string
-corresponding to an EAI_xxx error value.
-
-
- #include <netdb.h>
-
- const char *gai_strerror(int ecode);
-
-The argument is one of the EAI_xxx values defined for the getaddrinfo()
-and getnameinfo() functions. The return value points to a string
-describing the error. If the argument is not one of the EAI_xxx values,
-the function still returns a pointer to a string whose contents indicate
-an unknown error.
-
-
-
-6.2 Socket Address Structure to Node Name and Service Name
-
-The getnameinfo() function is used to translate the contents of a socket
-address structure to a node name and/or service name.
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getnameinfo(const struct sockaddr *sa, socklen_t salen,
- char *node, socklen_t nodelen,
- char *service, socklen_t servicelen,
- int flags);
-
-The getnameinfo() function shall translate a socket address to a node
-name and service location, all of which are defined as in getaddrinfo().
-
-The sa argument points to a socket address structure to be translated.
-
-The salen argument holds the size of the socket address structure
-pointed to by sa.
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 23]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-If the socket address structure contains an IPv4-mapped IPv6 address or
-an IPv4-compatible IPv6 address, the implementation shall extract the
-embedded IPv4 address and lookup the node name for that IPv4 address.
-
- Note: The IPv6 unspecified address ("::") and the IPv6
- loopback address ("::1") are not IPv4-compatible addresses.
- If the address is the IPv6 unspecified address ("::"), a
- lookup is not performed, and the [EAI_NONAME] error is returned.
-
-If the node argument is non-NULL and the nodelen argument is nonzero,
-then the node argument points to a buffer able to contain up to nodelen
-characters that receives the node name as a null-terminated string. If
-the node argument is NULL or the nodelen argument is zero, the node name
-shall not be returned. If the node's name cannot be located, the numeric
-form of the node's address is returned instead of its name.
-
-If the service argument is non-NULL and the servicelen argument is non-
-zero, then the service argument points to a buffer able to contain up to
-servicelen bytes that receives the service name as a null-terminated
-string. If the service argument is NULL or the servicelen argument is
-zero, the service name shall not be returned. If the service's name
-cannot be located, the numeric form of the service address (for example,
-its port number) shall be returned instead of its name.
-
-The arguments node and service cannot both be NULL.
-
-The flags argument is a flag that changes the default actions of the
-function. By default the fully-qualified domain name (FQDN) for the host
-shall be returned, but:
-
- - If the flag bit NI_NOFQDN is set, only the node name portion of the
- FQDN shall be returned for local hosts.
-
- - If the flag bit NI_NUMERICHOST is set, the numeric form of the
- host's address shall be returned instead of its name, under all
- circumstances.
-
- - If the flag bit NI_NAMEREQD is set, an error shall be returned if the
- host's name cannot be located.
-
- - If the flag bit NI_NUMERICSERV is set, the numeric form of the
- service address shall be returned (for example, its port number)
- instead of its name, under all circumstances.
-
- - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the
- scope identifier shall be returned (for example, interface index)
- instead of its name. This flag is ignored if the sa argument is
- not an IPv6 address.
-
- - If the flag bit NI_DGRAM is set, this indicates that the service is
- a datagram service (SOCK_DGRAM). The default behavior shall assume that
- the service is a stream service (SOCK_STREAM).
-
-Note:
-
- 1. The three NI_NUMERICxxx flags are required to support the "-n"
- flags that many commands provide.
- 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 port
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 24]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- numbers (for example, [512,514]) that represent different services
- for UDP and TCP.
-
-The getnameinfo() function shall be thread safe.
-
-A zero return value for getnameinfo() indicates successful completion; a
-non-zero return value indicates failure.
-
-Upon successful completion, getnameinfo() shall return the node and
-service names, if requested, in the buffers provided. The returned names
-are always null-terminated strings.
-
-Error Return Values:
-
-The getnameinfo() function shall fail and return the corresponding value
-if:
-
- [EAI_AGAIN] The name could not be resolved at this time.
- Future attempts may succeed.
-
- [EAI_BADFLAGS] The flags had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred.
-
- [EAI_FAMILY] The address family was not recognized or the address
- length was invalid for the specified family.
-
- [EAI_MEMORY] There was a memory allocation failure.
-
- [EAI_NONAME] The name does not resolve for the supplied parameters.
- NI_NAMEREQD is set and the host's name cannot be located, or
- both nodename and servname were null.
-
- [EAI_OVERFLOW] An argument buffer overflowed.
-
- [EAI_SYSTEM] A system error occurred. The error code can be found in
- errno.
-
-
-
-6.3 Address Conversion Functions
-
-The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
-address between binary and text form. IPv6 applications need similar
-functions. The following two functions convert both IPv6 and IPv4
-addresses:
-
- #include <arpa/inet.h>
-
- int inet_pton(int af, const char *src, void *dst);
-
- const char *inet_ntop(int af, const void *src,
- char *dst, socklen_t size);
-
-The inet_pton() function shall convert an address in its standard text
-presentation form into its numeric binary form. The af argument shall
-specify the family of the address. The AF_INET and AF_INET6 address
-families shall be supported. The src argument points to the string
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 25]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-being passed in. The dst argument points to a buffer into which the
-function stores the numeric address; this shall be large enough to hold
-the numeric address (32 bits for AF_INET, 128 bits for AF_INET6). The
-inet_pton() function shall return 1 if the conversion succeeds, with the
-address pointed to by dst in network byte order. It shall return 0 if
-the input is not a valid IPv4 dotted-decimal string or a valid IPv6
-address string, or -1 with errno set to EAFNOSUPPORT if the af argument
-is unknown.
-
-If the af argument of inet_pton() is AF_INET, the src string shall be in
-the standard IPv4 dotted-decimal form:
-
- ddd.ddd.ddd.ddd
-
-where "ddd" is a one to three digit decimal number between 0 and 255.
-The inet_pton() function does not accept other formats (such as the
-octal numbers, hexadecimal numbers, and fewer than four numbers that
-inet_addr() accepts).
-
-If the af argument of inet_pton() is AF_INET6, the src string shall be
-in one of the standard IPv6 text forms defined in Section 2.2 of the
-addressing architecture specification [2].
-
-The inet_ntop() function shall convert a numeric address into a text
-string suitable for presentation. The af argument shall specify the
-family of the address. This can be AF_INET or AF_INET6. The src
-argument points to a buffer holding an IPv4 address if the af argument
-is AF_INET, or an IPv6 address if the af argument is AF_INET6; the
-address must be in network byte order. The dst argument points to a
-buffer where the function stores the resulting text string; it shall not
-be NULL. The size argument specifies the size of this buffer, which
-shall be large enough to hold the text string (INET_ADDRSTRLEN
-characters for IPv4, INET6_ADDRSTRLEN characters for IPv6).
-
-In order to allow applications to easily declare buffers of the proper
-size to store IPv4 and IPv6 addresses in string form, the following two
-constants are defined in <netinet/in.h>:
-
- #define INET_ADDRSTRLEN 16
- #define INET6_ADDRSTRLEN 46
-
-The inet_ntop() function shall return a pointer to the buffer containing
-the text string if the conversion succeeds, and NULL otherwise. Upon
-failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
-ENOSPC if the size of the result buffer is inadequate.
-
-
-
-6.4 Address Testing Macros
-
-The following macros can be used to test for special IPv6 addresses.
-
- #include <netinet/in.h>
-
- int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
- int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
- int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
- int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 26]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
- int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
-
- int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
-
-The first seven macros return true if the address is of the specified
-type, or false otherwise. The last five test the scope of a multicast
-address and return true if the address is a multicast address of the
-specified scope or false if the address is either not a multicast
-address or not of the specified scope.
-
-Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
-only for the two types of local-use IPv6 unicast addresses (Link-Local
-and Site-Local) defined in [2], and that by this definition, the
-IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback address
-(::1). These two macros do not return true for IPv6 multicast addresses
-of either link-local scope or site-local scope.
-
-
-
-7. Summary of New Definitions
-
-The following list summarizes the constants, structure, and extern
-definitions discussed in this memo, sorted by header.
-
- <net/if.h> IF_NAMESIZE
- <net/if.h> struct if_nameindex{};
-
- <netdb.h> AI_ADDRCONFIG
- <netdb.h> AI_ALL
- <netdb.h> AI_CANONNAME
- <netdb.h> AI_NUMERICHOST
- <netdb.h> AI_NUMERICSERV
- <netdb.h> AI_PASSIVE
- <netdb.h> AI_V4MAPPED
- <netdb.h> EAI_AGAIN
- <netdb.h> EAI_BADFLAGS
- <netdb.h> EAI_FAIL
- <netdb.h> EAI_FAMILY
- <netdb.h> EAI_MEMORY
- <netdb.h> EAI_NONAME
- <netdb.h> EAI_OVERFLOW
- <netdb.h> EAI_SERVICE
- <netdb.h> EAI_SOCKTYPE
- <netdb.h> EAI_SYSTEM
- <netdb.h> NI_DGRAM
- <netdb.h> NI_NAMEREQD
- <netdb.h> NI_NOFQDN
- <netdb.h> NI_NUMERICHOST
- <netdb.h> NI_NUMERICSERV
- <netdb.h> struct addrinfo{};
-
- <netinet/in.h> IN6ADDR_ANY_INIT
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 27]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
- <netinet/in.h> IN6ADDR_LOOPBACK_INIT
- <netinet/in.h> INET6_ADDRSTRLEN
- <netinet/in.h> INET_ADDRSTRLEN
- <netinet/in.h> IPPROTO_IPV6
- <netinet/in.h> IPV6_JOIN_GROUP
- <netinet/in.h> IPV6_LEAVE_GROUP
- <netinet/in.h> IPV6_MULTICAST_HOPS
- <netinet/in.h> IPV6_MULTICAST_IF
- <netinet/in.h> IPV6_MULTICAST_LOOP
- <netinet/in.h> IPV6_UNICAST_HOPS
- <netinet/in.h> IPV6_V6ONLY
- <netinet/in.h> SIN6_LEN
- <netinet/in.h> extern const struct in6_addr in6addr_any;
- <netinet/in.h> extern const struct in6_addr in6addr_loopback;
- <netinet/in.h> struct in6_addr{};
- <netinet/in.h> struct ipv6_mreq{};
- <netinet/in.h> struct sockaddr_in6{};
-
- <sys/socket.h> AF_INET6
- <sys/socket.h> PF_INET6
- <sys/socket.h> struct sockaddr_storage;
-
-The following list summarizes the function and macro prototypes
-discussed in this memo, sorted by header.
-
- <arpa/inet.h> int inet_pton(int, const char *, void *);
- <arpa/inet.h> const char *inet_ntop(int, const void *,
- char *, socklen_t);
-
- <net/if.h> char *if_indextoname(unsigned int, char *);
- <net/if.h> unsigned int if_nametoindex(const char *);
- <net/if.h> void if_freenameindex(struct if_nameindex *);
- <net/if.h> struct if_nameindex *if_nameindex(void);
-
- <netdb.h> int getaddrinfo(const char *, const char *,
- const struct addrinfo *,
- struct addrinfo **);
- <netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
- char *, socklen_t, char *, socklen_t, int);
- <netdb.h> void freeaddrinfo(struct addrinfo *);
- <netdb.h> const char *gai_strerror(int);
-
- <netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 28]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-8. Security Considerations
-
-IPv6 provides a number of new security mechanisms, many of which need to
-be accessible to applications. Companion memos detailing the extensions
-to the socket interfaces to support IPv6 security are being written.
-
-
-
-Changes from RFC 2553
-
- 1. Add brief description of the history of this API and its
- relation to the Open Group/IEEE/ISO standards.
-
- 2. Alignments with [3].
-
- 3. Removed all references to getipnodebyname() and
- getipnodebyaddr(), which are deprecated in favor
- of getaddrinfo() and getnameinfo().
-
- 4. Added IPV6_V6ONLY IP level socket option to permit nodes
- to not process IPv4 packets as IPv4 Mapped addresses
- in implementations.
-
- 5. Added SIIT to references and added new contributors.
-
-
-
-
-Acknowledgments
-
-This specification's evolution and completeness were significantly
-influenced by the efforts of Richard Stevens, who has passed on.
-Richard's wisdom and talent made the specification what it is today.
-The co-authors will long think of Richard with great respect.
-
-Thanks to the many people who made suggestions and provided feedback to
-this document, including:
-
-Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
-Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis
-Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, Marc
-Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji
-Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald,
-Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, Craig
-Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith
-Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean
-D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl
-Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill.
-
-The getaddrinfo() and getnameinfo() functions are taken from an earlier
-Internet Draft by Keith Sklower. As noted in that draft, William Durst,
-Steven Wise, Michael Karels, and Eric Allman provided many useful
-discussions on the subject of protocol-independent name-to-address
-translation, and reviewed early versions of Keith Sklower's original
-proposal. Eric Allman implemented the first prototype of getaddrinfo().
-The observation that specifying the pair of name and service would
-suffice for connecting to a service independent of protocol details was
-made by Marshall Rose in a proposal to X/Open for a "Uniform Network
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 29]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-Interface".
-
-Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker
-made many contributions to this document. Ramesh Govindan made a number
-of contributions and co-authored an earlier version of this memo.
-
-
-
-References
-
- [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460 Draft Standard.
-
- [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998 Draft Standard.
-
- [3] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX)
-
- Open Group Technical Standard: Base Specifications, Issue 6
- December 2001
-
- ISO 9945 (pending final approval by ISO)
-
- http://www.opengroup.org/austin
-
- [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
- [5] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)"
- RFC 2765, February 2000.
-
- [6] The Open Group Base Working Group
- http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 30]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002
-
-
-Authors' Addresses
-
-Bob Gilligan
-Cacheflow, Inc.
-650 Almanor Ave.
-Sunnyvale, CA 94086
-Telephone: 408-220-2084 (voice)
- 408-220-2250 (fax)
-Email: gilligan@cacheflow.com
-
-Susan Thomson
-Cisco Systems
-499 Thornall Street, 8th floor
-Edison, NJ 08837
-Telephone: 732-635-3086
-Email: sethomso@cisco.com
-
-Jim Bound
-Hewlett-Packard Company
-110 Spitbrook Road ZKO3-3/W20
-Nashua, NH 03062
-Telephone: 603-884-0062
-Email: Jim.Bound@hp.com
-
-Jack McCann
-Hewlett-Packard Company
-110 Spitbrook Road ZKO3-3/W20
-Nashua, NH 03062
-Telephone: 603-884-2608
-Email: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 31]
-
+++ /dev/null
-Internet Engineering Task Force Shin Miyakawa
-INTERNET-DRAFT NTT Communications
-<draft-ietf-ipv6-prefix-delegation-requirement-00.txt>
-
-Expires: May 1, 2003
- Nov 1, 2002
-
-
- Requirements for IPv6 prefix delegation
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months. The date of expiration will
-be May 1, 2003.
-
-
-Abstract
-
-
- This document describes requirements about how an IPv6 address prefix
- should be delegated to an IPv6 subscriber's network (or "site").
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Motivation
-
- With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs
- are ready to offer their services to the public in conjunction with
- widely deployed IP subscription method such as ADSL and so on. But,
- thinking about following situation of IPv6 commercial service as one
- of the most likely examples,
-
- IPv6 ISP router
- |
- | point-to-point link
- |
- User's Site router
- |
- ----+----- User's Site Network
-
- though it is needed a standardized way to delegate one or more IPv6
- address prefix(es) from the IPv6 ISP to the User's site
- automatically, it is not identified clearly yet.
-
- Originally, it seemed that just RA (Router Avertisement) considered
- as good enough to be used for P-P link between ISP and User's site,
- but according to the NCCs' recommendations, one site should be
- delegated /48 usually.
-
- So, ISP which now would like to start its own IPv6 commercial service
- TODAY, need to have some method other than RA protocol which only can
- handle one signle /64 prefix but something else or enhanced
-
- - to delegate not just one signle /64 prefix to the user - to satisfy
- all the other (standard) requirements which is needed to realize
- commercial service
-
- Therefore, this documents clarifies requirements for IPv6 address
- prefix delegation from the ISP to the site, especially from the
- (commercial) ISP point of view to boost IPv6 business quick as
- possible.
-
- Requirements for prefix delegation management
- Focusing commercial IPv6 ISP service, there are several kinds of
- category of requirements for the mechanism / protocol to delegate one
- or more IPv6 prefixes from ISP to a site.
-
- - layer 2 consideration
-
- The method should work on any layer 2 technologies. In other words,
- it should be layer 2 technology independent. Though, at the same
- time, it should be noted that now ISP would like to have a solution
- for Point-to-Point link which has own authentication mechanism first.
- PPP link with CHAP authentication is a good example. (Simulated)
- Ethernet and IEEE802.11 (wireless LAN) should be covered in near
- future, but they have low priority (just) for now. It should be
- clarified that the method should work with all L2 protocols either
- with authentication mechanism or without, but ISP would like to take
- advantage of a L2 protocol's authentication mechanism if it exits.
-
- - accounting
-
- It should provide accounting capability such as logging about by
- whom, when and what prefix(es) is used for the service with proper
- authentication techniques.
-
- - kinds of prefixes
-
- It should be able to delegate both statically and dynamically
- assigned prefix assignment by authenticated identification, depended
- by resources and/or any reasons.
-
- - negotiation between ISP and site
-
- ISP may deny the service, due to various reasons such as there is no
- contract or bad financial credit etc. Also ISP should be able to use
- one single technique to pass parameters of the prefix such as scope
- (global and/or site), prefix length (/48, /64 or any other length)
- and any other appropriate related information to the site. On the
- other hand, a site should be able to request multiple prefixes to the
- ISP. Also a site should be able to pass parameters of the prefix
- such as scope (global and/or site), prefix length (/48, /64 or any
- other length), number of prefixes and so on to the ISP to negotiate.
-
- - less impact on ISP equipments
-
- ISP usualy use some kind of equipment to provide subscription service
- to the users such as access concentrating router, PPP server and so
- on. This may aggregate thousands or more connections toward the
- ISP's backbone. Prefix delegation mechanism must be compatible with
- this situation.
-
- References Deering, 1998. S. Deering and R. Hinden, "Internet
- Protocol, Version 6 (IPv6) Specification", RFC2460 (December 1998).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-History
- Jun 2002, first draft was presented as personal submission.
- At the IETF-54th at Yokohama, it became a working group draft.
- Nov 2003, the draft published as -01 draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Acknowledgements
- People in Internet Association of Japan have gave me a lot of good input.
- Team members of NTT Communications IPv6 project, especially Toshi Yamasaki
- and Yasuhiro Shirasaki, gave me quite useful suggestions for this
- document. Chairs of IETF IPv6 working group especially Bob Hinden
- who gave me a good suggestions before I submitted this draft.
- Also communications with other folks in the IPv6 community, such
- as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have
- been quite helpful. Thanks a lot.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Author's address
- Shin Miyakawa, Ph.D
- Innovative IP Architecture Center, NTT Communications Corporation
- Tokyo, Japan
- Tel: +81-3-6800-3262
- Fax: +81-3-5265-2990
- Email: miyakawa@nttv6.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-
-Network Working Group S. Josefsson
-Internet-Draft RSA Security
-Expires: August 23, 2002 W. Griffin
- NAI Labs
- February 22, 2002
-
-
- Notes on Application Key Distribution
- draft-josefsson-siked-framework-00
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 23, 2002.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- The debate over whether to store cryptographic keys used by
- applications in the Domain Name System or not has been going on for
- some time. There are arguments for and against [6]. This document
- tries to take a step further and provides some initial terminology,
- problem statement and use cases for storing application keys in DNS,
- in order to enable more substantiated input to the discussion. We
- mention some proposed solutions so far. We also give some
- requirements on a solution (be it DNS based or not) that would
- satisfy the use cases.
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 1]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 6. Survey of Proposals . . . . . . . . . . . . . . . . . . . . . 7
- 7. Requirements on a Solution . . . . . . . . . . . . . . . . . . 9
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 2]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
-1. Introduction
-
- The intention of this draft is to document some of the discussions
- that have taken place on a number of mailing lists, including the
- DNSSEC mailing list [8], the DNSEXT mailing list [9], and the KEYDIST
- mailing list [10], regarding (primarily) distributing keys for
- Internet applications without additional end-user configuration.
-
- The goal of this draft is not to advocate one single solution.
- Instead, the goal is to be a first step towards more well-defined
- terminology and a framework in which proposed solutions can be
- discussed.
-
- A few suggested proposals are discussed in this document.
-
- We acknowledge that all areas discussed in this document need further
- work.
-
- Comments and feedback is requested, preferably to the keydist mailing
- list [10].
-
-2. Terminology
-
- "Application" or "Internet Application"
-
- Network software that uses Domain names or IP addresses to
- communicate with other entities. To operate securely, these
- applications usually need cryptographic key material. Examples
- of applications under considerations are secure IP-based
- communication (IPSEC [12], SSH [13]) and secure email (OpenPGP
- [4], S/MIME [14]).
-
- A note on "infrastructure" vs "application" is appropriate as
- well, as there has been some confusion about calling IPSEC an
- "application". IPSEC is often considered "infrastructure", and
- applications are something you build on top of IPSEC. However,
- from the point of view of looking up keys for use with IPSEC,
- IPSEC behaves like all other clients to the "lookup keys"
- system. Hence, we consider the system that provides lookup and
- retrieval of application keys the "infrastructure" and all
- clients of this infrastructure are "applications". From this
- point of view, IPSEC is an application.
-
- "Application Keys"
-
- The piece of information an application needs to establish
- secure communication with an entity. This usually includes
- cryptographic (public) keys, but may also include other
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 3]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- information such as an address to the security gateway.
-
- Note that the format of the keys is not fixed, it ranges from
- PKIX certificates to raw RSA public keys.
-
- The reason for including "application" in this term is due the
- DNS-centered origins of these discussions. Keys in DNS often
- refer to DNSSEC [3] keys which are used by DNS itself.
- Applications keys, on the other hand, are used by "applications
- of DNS", thus "application keys".
-
- "Application Key Infrastructure"
-
- This is the mechanism that provides application key
- distribution. The discussions have so far been centered around
- using DNS for this purpose. One solution is to simply store
- the application keys within DNS, another is to only store a
- pointer in DNS, pointing to where the keys can retrieved. The
- rationale behind this is that DNS provides name to address
- mapping on the Internet, and most applications need to find
- keys based on such names. Involving DNS is natural, unless one
- aims at replacing or amending the DNS name space.
-
- Note that the infrastructure is in general not assumed to be
- secured. That is, e.g., DNSSEC is not assumed to be deployed.
- However, some problems and use cases may assume partial or full
- deployment of DNSSEC. Also, some problems and use cases may
- assume usage of secure peer to peer DNS communication using
- TSIG [16].
-
-
-3. Problem Statement
-
- At least the following two problems has been discussed:
-
- "Opportunistic Encryption" or "Zero configuration security"
-
- Certain applications have a need to find cryptographic keying
- material for entities which they have no prior arrangement
- with. Examples includes IPSEC and secure email. In both cases
- the user only know the address of the remote machine or person,
- and need to locate and retrieve the keying material for this
- entity.
-
- "Campus-based application key distribution"
-
- Secure remote machine administration requires that keys are
- distributed somehow. Mechanisms used by, e.g., SSH include
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 4]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- retrieving the key from the remote machine and asking the user
- if she wants to trust it or not (including a fingerprint of the
- key for verification purposes), and later store the keys in a
- local file. Other applications have other mechanisms.
-
- The solution to these two problems can be related to DNS. People
- ultimately trust names of machines (hostnames) or persons (email
- addresses). Making the trust point relate to DNS thus makes sense,
- because DNS is used to lookup hostnames and mail servers for email
- addresses.
-
-4. Applications
-
- This section discusses how some applications and how they currently
- use keys/certificates.
-
- Opportunistic Encryption in IPsec
-
- [17] discusses a protocol for opportunistic encryption in
- IPsec. That protocol currently uses a TXT record to store a
- Gateway IP address and the public key associated with the
- gateway. This TXT record is placed in the reverse map at the
- label of the host that is authorizing the gateway to perform
- opportunistic IPsec on its behalf.
-
- Opportunistic S/MIME and OpenPGP
-
- S/MIME uses X.509 public key certificates and OpenPGP uses
- public key certificates defined by RFC2440. In practice,
- S/MIME uses pre-configured CAs in mail readers and OpenPGP
- implementations uses web of trust verification possibly aided
- by online databases such as pgp.net or keyserver.net. However,
- these models are not required by S/MIME or OpenPGP per se, but
- this is what is currently deployed.
-
- Secure Shell (SSH)
-
- Secure Shell currently uses a client-side "local database that
- associates each host name (as typed by the user) with the
- corresponding public host key" [18]. [18] also describes a
- heirarchy model of trust, where the clients are configured with
- a trusted CA root key, and the "host name-to-key association is
- certified by some trusted certification authority."
-
- STIME
-
- [19] defines how NTP uses Public Key Cryptography to
- authenticate servers. The protocol assumes, "public encryption
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 5]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- keys and certificates must be retrievable directly from servers
- without requiring secured channels; however, the fundamental
- security of identification credentials and public values bound
- to those credentials must be a function of external certificate
- authorities and/or webs of trust."
-
-
-5. Use cases
-
- Opportunistic IPSEC
-
- See [17].
-
- Binding Updates for Mobile IP
-
- Assuming DNSSEC is deployed, attaching KEY records for Internet
- hosts to achieve secure Binding Updates in Mobile IP is
- compelling. It would make it possible for a Mobile Node to
- prove that it owns the IP address it claims to do, by providing
- a signed statement to a Correspondent Node. The Correspondent
- Node would use DNS and DNSSEC to retrieve the hosts' public key
- and verify the signed statement. This needs to be combined
- with DNS Dynamic Update (authorized by, e.g., a DHCP server) to
- allow the Mobile Node to insert its own KEY record into the DNS
- space in the visiting network.
-
- Binding Updates for Mobile IP achieved in this manner can be
- seen as a special case of Opportunistic IPSEC.
-
- Opportunistic S/MIME and OpenPGP
-
- Storing PGP keys in DNS would be possible using the CERT RR
- [5]. The naming standard used could be the suggested one (SOA
- translation of email address), or based on the PGP KeyId, e.g.,
- 0x47114711.dnskeys.net.
-
- SSH with improved DNS public key verification using [20]:
-
- A campus runs SSH and either DNSSEC or TSIG (clients configured
- with DNSSEC key or TSIG key) to protect from people that plug
- in their laptops and tries to gain unauthorized access using
- spoofing techniques. When contacting SSH hosts the first time,
- instead of receiving:
-
- The authenticity of host 'cc (195.42.214.244)' can't be established.
- RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
- Are you sure you want to continue connecting (yes/no)?
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 6]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- which most users is not able to answer correctly, the SSH host
- key is retrieved from DNS, verified using the DNSSEC or TSIG,
- and the following question might be presented:
-
- The host key of 'cc (195.42.214.244)' authenticated by DNSSEC root 'kth.se'.
- RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
- Are you sure you want to continue connecting (yes/no)?
-
- This enables the user to relate the question to something she
- might already trust (the "kth.se" DNS zone). In practice,
- administrators will probably configure the SSH client to always
- trust certain SSH zone keys and thereby removing the user
- interaction completely.
-
-
-6. Survey of Proposals
-
- "Store application keys in the CERT RR, subtyping for every
- applications"
-
- This proposal re-uses the already defined CERT RR, but
- clarifies it to be used for non-certificate lookups as well.
- Given that the CERT RR allows for PKIX CRLs (which isn't a
- certificate), and that from the DNS software's point of view
- there is no difference between a certificate and a raw key,
- this interpretation have some bearing in the specification.
-
- This would not require any changes to DNS software. It would
- make it easy for applications that support more than one format
- of applications keys, e.g. both raw key and X.509 certificate.
-
- This proposal may be amended with owner name guidelines, such
- as [7] for email applications.
-
- For certificates, no additional security infrastructure is
- required. For raw keys DNSSEC, TSIG or similar is required.
-
- "Use APPKEY for raw keys and CERT for certificates, subtyping for
- every application"
-
- This is similar to the previous, but that it separates raw keys
- from certificate like formats.
-
- This has the same advantages and disadvantages than the
- previous proposal, but it does add complexity in case software
- supports both raw keys and certificates. It also requires that
- DNS administrators and DNS software knows if a certain blob is
- a key or certificate when storing it in DNS.
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 7]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- All APPKEYs must be protected with DNSSEC, TSIG or similar.
- All CERT RR do not in principle require DNSSEC, TSIG or similar
- but may benefit from it.
-
- "Store referral in DNS, retrieve keys via other protocols"
-
- This is possible now using, e.g., SRV and LDAP.
-
- If raw keys are used, DNSSEC and LDAP over TLS or something
- similar is required. If certs are used, plain DNS and LDAP
- would work.
-
- However, since there isn't one global PKI, the security offered
- by this is not sufficient in general. Consider Alice asking
- for Bob's certificate using SRV and LDAP, and receiving a
- certificate signed by a CA which Alice does not know or trust.
- This model does work well in situations where Alice and Bob
- share the same CA or uses cross certified CAs.
-
- "Store referral with fingerprint in DNS, retrieve keys via other
- protocols"
-
- This is similar to the previous proposal, but it makes it
- possible to chose the security infrastructure that should be
- used. Either leverage on DNSSEC, TSIG or similar, or protect
- the other protocol with, e.g., TLS, or use certificates (this
- assumes that involved entities has a trust relationship with a
- common CA).
-
- "Define RR for each application"
-
- This pushes everything onto application designers, forcing them
- to write the specification. Then this effort would change into
- simply giving recommendations on how to write such
- specifications.
-
- Security-wise it gives total flexibility, however each
- application need to write a document similar to this discussing
- if they need raw keys, certificates etc, and if they will store
- the key or certificate in DNS or use a separate protocol. It
- also requires that DNS software handles unknown RRs correctly
- (or that all new RRs are supported by DNS software directly,
- which is unlikely to happen).
-
-
-
-
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 8]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
-7. Requirements on a Solution
-
- "MUST be possible to locate application keys given only IP address or
- hostname, and access to standard Internet infrastructure"
-
- Interpretation: This acknowledge that IP addresses and hostnames are
- used to find application keys, not X.400 DN or OpenPGP key IDs. It
- also acknowledge that user configuration (of e.g. LDAP servers)
- should not be necessary. The mechanism should require "zero
- configuration" by the end user.
-
- "MUST be possible to secure locating and retrival of the key"
-
- Interpretation: This could be achieved with DNSSEC, DNS TSIG, or
- referral from DNS with a key fingerprint in DNS similar to WPKI [14],
- or using CMS [14] or TLS [15] with PKIX certificates [11].
-
- "SHOULD be efficient"
-
- Interpretation: UDP would be an advantage, but this is subject to the
- size of keying material. Raw keys might fit into UDP, but
- certificates will not in general.
-
- "MUST not create operational problems"
-
- Interpretation: E.g., the DNS system should not have operational
- problems resulting from this use.
-
-Acknowledgement
-
- Thanks to members of the Namedroppers, DNSSEC and KEYDIST mailing
- list.
-
-References
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
- 1034, November 1987.
-
- [2] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
- Message Format", RFC 2440, November 1998.
-
- [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 9]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- Domain Name System (DNS)", RFC 2538, March 1999.
-
- [6] Lewis, E., "Discussing Application Public Keys in the DNS", I-D
- draft-lewis-siked-dnsargs, February 2002.
-
- [7] Schlyter, J., Josefsson, S. and R. Arends, "Storing
- certificates in DNS for email applications", I-D draft-
- schlyter-mailcert-dns-00.txt, November 2001.
-
- [8] "DNSSEC Mailing List", Email dnssec@cafax.se.
-
- [9] "DNSEXT Mailing List", Email namedroppers@ops.ietf.org.
-
- [10] "KEYDIST Mailing List", Email keydist@cafax.se.
-
- [11] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
- Public Key Infrastructure Certificate and CRL Profile", RFC
- 2459, January 1999.
-
- [12] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [13] "Secure Shell Working Group", WWW
- http://www.ietf.org/html.charters/secsh-charter.html.
-
- [14] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
- 1999.
-
- [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
- 2246, January 1999.
-
- [16] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [17] Richardsson, M., Redelmeier, D. and H. Spencer, "A method for
- doing opportunistic encryption with IKE", I-D draft-richardson-
- ipsec-opportunistic-02.txt, September 2001.
-
- [18] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
- Lehtinen, "SSH Protocol Architecture", I-D draft-ietf-secsh-
- architecture-12.txt, January 2002.
-
- [19] Mills, D., "Public key Cryptography for the Network Time
- Protocol Version 2", I-D draft-ietf-stime-ntpauth-03.txt,
- February 2002.
-
- [20] Griffin, W., "Storing SSH Host Keys in DNS", I-D draft-ietf-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 10]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
- secsh-dns-key-format-00.txt, May 2001.
-
- [21] WAP Forum, "WAP Public Key Infrastructure Definition", WAP 217-
- WPKI, April 2001.
-
-
-Authors' Addresses
-
- Simon Josefsson
- RSA Security
- Arenav\84gen 29
- Stockholm 121 29
- Sweden
-
- Phone: +46 8 7250914
- EMail: sjosefsson@rsasecurity.com
-
-
- Wesley Griffin
- NAI Labs
-
- EMail: wgriffin@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 11]
-\f
-Internet-Draft Notes on Application Key Distribution February 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Griffin Expires August 23, 2002 [Page 12]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires: 20 May 2002 20 November 2001
-
-
- Use of DNS SRV in LDAP Named Subordinate References
- <draft-zeilenga-ldap-dnsref-02.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Experimental document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright 2001, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-Abstract
-
- This document describes how LDAP service location information stored
- on DNS SRV resource records may be used to in conjunction with named
- subordinate referral objects. This document defines the dNSReferral
- object class.
-
-
-
-
-
-Zeilenga LDAP DNSreferral [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
-
-
-Conventions
-
- Schema definitions are provided using LDAPv3 description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped) for
- readability.
-
- The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
- NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
- this document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-1. Background and Intended Use
-
- Named subordinate referral [NAMEDREF] defines a specific method for
- representing subordinate references in LDAP [RFC2251] directories.
- This document describes a mechanism for using LDAP service location
- information [LOCATE] available in DNS SRV resource records [RFC2782]
- to rewrite select LDAP URLs [RFC2255] returned to clients as referrals
- and search continuations.
-
-
-2. Schema
-
- A dNSReferral object is a directory entry whose structural object
- class is the dNSreferral object class.
-
- ( 1.3.6.1.4.1.4203.1.4.8 NAME 'dNSReferral'
- DESC 'DNS SRV aware named subordinate referral object'
- SUP referral STRUCTURAL )
-
- dNSReferral objects SHOULD have distinguished names comprising of RDNs
- consisting of only dc (domainComponent) attributes (e.g.,
- dc=example,dc=net) as detailed in [RFC2247].
-
- dNSReferral objects SHALL behave like referral objects [NAMEDREF]
- except as detailed in the following section.
-
-
-3. Construction of Referrals and Search References
-
- In the referral processing described by [NAMEDREF], if a LDAP URL with
- no hostpart is to be returned to the client as part of a referral or
- search continuation, it is replaced with one or more LDAP URLs based
- upon service location information.
-
- The server SHOULD obtain service location information [LOCATE] for the
- DN [RFC2253] present in (or implied by) the LDAP URL [RFC2255]. If no
- service location information is available, the server MUST return the
-
-
-
-Zeilenga LDAP DNSreferral [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
-
-
- LDAP URL as described in [NAMEDREF].
-
- Otherwise, the server SHALL replace the LDAP URL with a set of
- constructed LDAP URLs. For each service host port pair provided, the
- server constructs an LDAP URL by replacing the empty hostport with
- concatenation of the service host, ":", and the port.
-
-
-4. Example
-
- Suppose a directory server contains:
-
- dn: dc=sub,dc=example,dc=net
- dc: sub
- objectClass: dNSReferral
- objectClass: extensibleObject
- ref: ldap:///dc=sub,dc=example,dc=net
-
- and DNS holds the following SRV records:
-
- _ldap._tcp.sub.example.net. IN SRV 0 0 389 l1.sub.example.net.
- _ldap._tcp.sub.example.net. IN SRV 0 0 389 l2.sub.example.net.
-
- and a client requests a compareRequest with a target DN of
- "dc=sub,dc=example,dc=net". In response to this request, the server
- would return:
-
- compareResponse "referral" {
- ldap://l1.sub.example.net:389/dc=sub,dc=example,dc=net
- ldap://l2.sub.example.net:389/dc=sub,dc=example,dc=net
- }
-
-
-5. Security Considerations
-
- This mechanism extends [NAMEDREF] based upon [LOCATE]. The security
- considerations discussed in these documents generally apply to the
- specification described in this document.
-
- In addition, this mechanism requires the server to make DNS queries.
- DNS responses are subject to spoofing. Use of DNSSEC is RECOMMENDED
- where appropriate. Also, DNS queries may require significant time and
- resources.
-
-
-6. Acknowledgments
-
- This document is borrows heavily from previous work by IETF LDAPext
-
-
-
-Zeilenga LDAP DNSreferral [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
-
-
- Working Group including [NAMEDREF] and [LOCATE].
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-8. Normative References
-
- [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (Also RFC 2119), March 1997.
-
- [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
- "Using Domains in LDAP/X.500 Distinguished Names", RFC
- 2247, January 1998.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished
- Names", RFC 2253, December 1997.
-
- [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
- December, 1997.
-
- [RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [LOCATE] M. Armijo, P. Leach, L Esibov, RL Morgan. "Discovering LDAP
- Services with DNS", draft-ietf-ldapext-locate-xx.txt (work
- in progress).
-
- [NAMEDREF] K. Zeilenga (editor), "Named Subordinate References in LDAP
- Directories" draft-zeilenga-ldap-namedref-xx.txt (work in
- progress)
-
-
-Full Copyright Statement
-
- Copyright 2001, The Internet Society. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
-
-
-
-Zeilenga LDAP DNSreferral [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
-
-
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP DNSreferral [Page 5]
-\f
projects / thirdparty / bind9.git / commitdiff
