From 5ddeca3a82709ec3ed82ea38d2587f6a6bed704a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 9 Sep 2005 06:26:02 +0000 Subject: [PATCH] cleanup --- doc/draft/draft-arrouye-keywords-reqs-01.txt | 899 -------- .../draft-ietf-dnsext-ipv6-addresses-00.txt | 334 --- ...-ietf-dnsop-dontpublish-unreachable-02.txt | 423 ---- .../draft-ietf-dnsop-resolver-rollover-01.txt | 19 - doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt | 2044 ----------------- ...-ipv6-prefix-delegation-requirement-00.txt | 360 --- .../draft-josefsson-siked-framework-00.txt | 672 ------ doc/draft/draft-zeilenga-ldap-dnsref-02.txt | 283 --- 8 files changed, 5034 deletions(-) delete mode 100644 doc/draft/draft-arrouye-keywords-reqs-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-ipv6-addresses-00.txt delete mode 100644 doc/draft/draft-ietf-dnsop-dontpublish-unreachable-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-resolver-rollover-01.txt delete mode 100644 doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt delete mode 100644 doc/draft/draft-ietf-ipv6-prefix-delegation-requirement-00.txt delete mode 100644 doc/draft/draft-josefsson-siked-framework-00.txt delete mode 100644 doc/draft/draft-zeilenga-ldap-dnsref-02.txt diff --git a/doc/draft/draft-arrouye-keywords-reqs-01.txt b/doc/draft/draft-arrouye-keywords-reqs-01.txt deleted file mode 100644 index 18b2bea575..0000000000 --- a/doc/draft/draft-arrouye-keywords-reqs-01.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 as equivalent as - (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] - -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] - -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] - -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] - -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] - diff --git a/doc/draft/draft-ietf-dnsext-ipv6-addresses-00.txt b/doc/draft/draft-ietf-dnsext-ipv6-addresses-00.txt deleted file mode 100644 index 38496d5e00..0000000000 --- a/doc/draft/draft-ietf-dnsext-ipv6-addresses-00.txt +++ /dev/null @@ -1,334 +0,0 @@ - -DNSEXT Working Group Randy Bush (ed.) - Alain Durand (ed.) - Bob Fink (ed.) - Olafur Gudmundsson (ed.) - Tony Hain (ed.) -INTERNET-DRAFT September 2001 - - - -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] - -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] - -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] - -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] - -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] - -INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001 - - -Editors Address - - Randy Bush - Alain Durand - Bob Fink - Olafur Gudmundsson - Tony Hain - -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] - diff --git a/doc/draft/draft-ietf-dnsop-dontpublish-unreachable-02.txt b/doc/draft/draft-ietf-dnsop-dontpublish-unreachable-02.txt deleted file mode 100644 index a6921be9cb..0000000000 --- a/doc/draft/draft-ietf-dnsop-dontpublish-unreachable-02.txt +++ /dev/null @@ -1,423 +0,0 @@ -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. diff --git a/doc/draft/draft-ietf-dnsop-resolver-rollover-01.txt b/doc/draft/draft-ietf-dnsop-resolver-rollover-01.txt deleted file mode 100644 index c6bcb939be..0000000000 --- a/doc/draft/draft-ietf-dnsop-resolver-rollover-01.txt +++ /dev/null @@ -1,19 +0,0 @@ - -This Internet-Draft has been deleted. Unrevised documents placed in the -Internet-Drafts directories have a maximum life of six months. After -that time, they are deleted. This Internet-Draft was not published as -an RFC. - -Internet-Drafts are not an archival document series, and expired -drafts, such as this one, are not available; please do not ask for -copies... they are not available. The Secretariat does not have -information as to future plans of the authors or working groups WRT the -deleted Internet-Draft. - -For more information or a copy of the document, contact the author directly. - -Draft Author(s): - -O. Kolkman: okolkman@ripe.net - - diff --git a/doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt b/doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt deleted file mode 100644 index d9d3eee9f8..0000000000 --- a/doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt +++ /dev/null @@ -1,2044 +0,0 @@ -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 - - - - -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 . 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 . -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 : - - 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 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 - 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 -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: - -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 : - - 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 . 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 : - - 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 -. 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 - - 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 - - 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 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 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 - - 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 - - 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 . - - - -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 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 - #include - - - 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 - - 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 - #include - - 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 - - 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 : - - #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 - - 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. - - IF_NAMESIZE - struct if_nameindex{}; - - AI_ADDRCONFIG - AI_ALL - AI_CANONNAME - AI_NUMERICHOST - AI_NUMERICSERV - AI_PASSIVE - AI_V4MAPPED - EAI_AGAIN - EAI_BADFLAGS - EAI_FAIL - EAI_FAMILY - EAI_MEMORY - EAI_NONAME - EAI_OVERFLOW - EAI_SERVICE - EAI_SOCKTYPE - EAI_SYSTEM - NI_DGRAM - NI_NAMEREQD - NI_NOFQDN - NI_NUMERICHOST - NI_NUMERICSERV - struct addrinfo{}; - - IN6ADDR_ANY_INIT - - -draft-ietf-ipngwg-rfc2553bis-08.txt Expires April 2003 [Page 27] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-08.txt October 2002 - - - IN6ADDR_LOOPBACK_INIT - INET6_ADDRSTRLEN - INET_ADDRSTRLEN - IPPROTO_IPV6 - IPV6_JOIN_GROUP - IPV6_LEAVE_GROUP - IPV6_MULTICAST_HOPS - IPV6_MULTICAST_IF - IPV6_MULTICAST_LOOP - IPV6_UNICAST_HOPS - IPV6_V6ONLY - SIN6_LEN - extern const struct in6_addr in6addr_any; - extern const struct in6_addr in6addr_loopback; - struct in6_addr{}; - struct ipv6_mreq{}; - struct sockaddr_in6{}; - - AF_INET6 - PF_INET6 - struct sockaddr_storage; - -The following list summarizes the function and macro prototypes -discussed in this memo, sorted by header. - - int inet_pton(int, const char *, void *); - const char *inet_ntop(int, const void *, - char *, socklen_t); - - char *if_indextoname(unsigned int, char *); - unsigned int if_nametoindex(const char *); - void if_freenameindex(struct if_nameindex *); - struct if_nameindex *if_nameindex(void); - - int getaddrinfo(const char *, const char *, - const struct addrinfo *, - struct addrinfo **); - int getnameinfo(const struct sockaddr *, socklen_t, - char *, socklen_t, char *, socklen_t, int); - void freeaddrinfo(struct addrinfo *); - const char *gai_strerror(int); - - int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); - 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] - diff --git a/doc/draft/draft-ietf-ipv6-prefix-delegation-requirement-00.txt b/doc/draft/draft-ietf-ipv6-prefix-delegation-requirement-00.txt deleted file mode 100644 index 57238c1d44..0000000000 --- a/doc/draft/draft-ietf-ipv6-prefix-delegation-requirement-00.txt +++ /dev/null @@ -1,360 +0,0 @@ -Internet Engineering Task Force Shin Miyakawa -INTERNET-DRAFT NTT Communications - - -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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-josefsson-siked-framework-00.txt b/doc/draft/draft-josefsson-siked-framework-00.txt deleted file mode 100644 index 40bac4ea98..0000000000 --- a/doc/draft/draft-josefsson-siked-framework-00.txt +++ /dev/null @@ -1,672 +0,0 @@ - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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„gen 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] - -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] - diff --git a/doc/draft/draft-zeilenga-ldap-dnsref-02.txt b/doc/draft/draft-zeilenga-ldap-dnsref-02.txt deleted file mode 100644 index 83dac5286b..0000000000 --- a/doc/draft/draft-zeilenga-ldap-dnsref-02.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -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 - - - -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 . Please send editorial - comments directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - 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] - -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] - -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] - -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 - - - -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] - -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] -