Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Adaptive DNS Discovery (add)

WG	Name	Adaptive DNS Discovery
	Acronym	add
	Area	Internet Area (int)
	State	Active
	Charter	charter-ietf-add-01 Approved
	Document dependencies	Document dependencies Loading... Pan and zoom the dependency graph after the layout settles. Show legend Loading...
	Additional resources	GitHub Organization Issue tracker Wiki Zulip Stream
Personnel	Chairs	David C Lawrence, Glenn Deen
	Area Director	Éric Vyncke
Mailing list	Address	add@ietf.org
	To subscribe	https://www.ietf.org/mailman/listinfo/add
	Archive	https://mailarchive.ietf.org/arch/browse/add/
Chat	Room address	https://zulip.ietf.org/#narrow/stream/add

Charter for Working Group

Network Working Group E. Gray Request for Comments: 4548 J. Rutemiller Updates: 1888, 4048 Ericsson Category: Standards Track G. Swallow Cisco Systems, Inc. May 2006 Internet Code Point (ICP) Assignments for NSAP Addresses Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. Table of Contents 1. Introduction ....................................................2 1.1. Conventions ................................................2 1.2. Acronyms and Terminology ...................................3 2. IANA Considerations .............................................3 3. Initial Allocations and Uses ....................................4 3.1. IPv4 Address Encoding in an NSAPA ..........................4 3.2. IPv6 Address Encoding in an NSAPA ..........................5 4. Security Considerations .........................................6 5. References ......................................................7 5.1. Normative References .......................................7 5.2. Informative References .....................................7 Gray, et al. Standards Track [Page 1] RFC 4548 Internet Code Point (ICP) Assignments May 2006 1. Introduction Section 6 of RFC 1888 [1888] previously provided for assignment of the initial Internet Code Point (ICP) value '0' for encoding an IPv6 address in a Network Service Access (or Attachment) Point [NSAP] address. RFC 1888 also defined multiple means for restricted encoding of an NSAP address in an IPv6 address. The means RFC 1888 defined for encoding NSAP addresses in IPv6 address format was heavily annotated with warnings and limitations that apply should this encoding be used. Possibly as a result, these encodings are not used and appear never to have been used in any IPv6 deployment. In addition, section 6 contains minor errors. As a result of these various considerations, RFC 1888 [1888] has been obsoleted and declared Historic by RFC 4048 [4048]. It is the belief of the authors of this document that the errors in section 6 of RFC 1888 resulted -- at least in part -- because the ITU-T specification [X.213] that originally assigned Authority and Format Identifier (AFI) '35' to IANA was not freely publicized, nor was it incorporated or explained using the mechanism commonly used in the IETF, i.e., an RFC. It is therefore part of the purpose of this document to provide that explanation. In addition, because there are other documents that refer to the IPv6 ICP assignment in RFC 1888, it is necessary for the errors in section 6 of RFC 1888 to be corrected, irrespective of the RFC&
groups are included in major document reviews at appropriate times.
It will also work with capport to ensure that solutions are applicable
to captive networks.