IPv6 addresses are 128-bit identifiers for interfaces and
sets of interfaces which were introduced in the DNS to facilitate
scalable Internet routing. There are three types of addresses: Unicast,
an identifier for a single interface;
an identifier for a set of interfaces; and Multicast,
an identifier for a set of interfaces. Here we describe the global
Unicast address scheme. For more information, see RFC 3587,
"Global Unicast Address Format."
IPv6 unicast addresses consist of a
global routing prefix, a
subnet identifier, and an
The global routing prefix is provided by the
upstream provider or ISP, and (roughly) corresponds to the
IPv4 network section
of the address range.
The subnet identifier is for local subnetting, much the
same as subnetting an
IPv4 /16 network into /24 subnets.
The interface identifier is the address of an individual
interface on a given network; in IPv6, addresses belong to
interfaces rather than to machines.
The subnetting capability of IPv6 is much more flexible than
that of IPv4: subnetting can be carried out on bit boundaries,
in much the same way as Classless InterDomain Routing
(CIDR), and the DNS PTR representation ("nibble" format)
makes setting up reverse zones easier.
The Interface Identifier must be unique on the local link,
and is usually generated automatically by the IPv6
implementation, although it is usually possible to
override the default setting if necessary. A typical IPv6
address might look like:
IPv6 address specifications often contain long strings
of zeros, so the architects have included a shorthand for
them. The double colon (`::') indicates the longest possible
of zeros that can fit, and can be used only once in an address.
Bibliography (and Suggested Reading)
Request for Comments (RFCs)
Specification documents for the Internet protocol suite, including
the DNS, are published as part of
the Request for Comments (RFCs)
series of technical notes. The standards themselves are defined
by the Internet Engineering Task Force (IETF) and the Internet
Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
the number of the RFC). RFCs are also available via the Web at:
Mail Routing and the Domain System.
Domain Names — Concepts and Facilities.
Domain Names — Implementation and
Clarifications to the DNS
Negative Caching of DNS
Incremental Zone Transfer in DNS.
A Mechanism for Prompt Notification of Zone Changes.
Dynamic Updates in the Domain Name System.
Extension Mechanisms for DNS (EDNS0).
Non-Terminal DNS Name Redirection.
Secret Key Transaction Authentication for DNS (TSIG).
Secret Key Establishment for DNS (TKEY RR).
DNS Request and Transaction Signatures (SIG(0)s).
Secure Domain Name System (DNS) Dynamic Update.
Generic Security Service Algorithm for Secret
Key Transaction Authentication for DNS
Indicating Resolver Support of DNSSEC.
Threat Analysis of the Domain Name System (DNS).
DNS Security Introduction and Requirements.
Resource Records for the DNS Security Extensions.
Protocol Modifications for the DNS
A Security Problem and Proposed Correction With Widely
Deployed DNS Software.
Common DNS Implementation
Errors and Suggested Fixes.
Serial Number Arithmetic.
Common Misbehaviour Against DNS
Queries for IPv6 Addresses.
New DNS RR Definitions.
DNS NSAP Resource Records.
Resolution of Uniform Resource Identifiers using
the Domain Name System.
A Means for Expressing Location Information in the
A DNS RR for Specifying the
Using the Internet DNS to
Conformant Global Address Mapping.
Key Exchange Delegation Record for the DNS.
DSA KEYs and SIGs in the Domain Name System (DNS).
RSA/MD5 KEYs and SIGs in the Domain Name System (DNS).
Storing Certificates in the Domain Name System (DNS).
Storage of Diffie-Hellman Keys in the Domain Name System (DNS).
Detached Domain Name System (DNS) Information.
A DNS RR for specifying the location of services (DNS SRV).
The Naming Authority Pointer (NAPTR) DNS Resource Record.
RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS).
A DNS RR Type for Lists of Address Prefixes (APL RR).
DNS Extensions to support IP
Handling of Unknown DNS Resource Record (RR) Types.
DNS Encoding of Network Names
and Other Types.
Requirements for Internet Hosts - Application and
Domain Name System Structure and Delegation.
Classless IN-ADDR.ARPA Delegation.
IAB Technical Comment on the Unique DNS Root.
Domain Name System (DNS) IANA Considerations.
Domain administrators operations guide.
Common DNS Data File
Common DNS Operational and
Operational Criteria for Root Name Servers.
Use of DNS Aliases for
A Tangled Web: Issues of I18N, Domain Names,
and the Other Internet protocols.
Internationalizing Domain Names in Applications (IDNA).
Nameprep: A Stringprep Profile for Internationalized Domain Names.
Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in
Note: the following list of RFCs, although
DNS-related, are not
concerned with implementing software.
Using the Domain Name System To Store Arbitrary String
Tools for DNS Debugging.
DNS Support for Load
A Legal Basis for Domain Name Allocation.
Domain Names and Company Name Retrieval.
A Convention For Using Legal Names as Domain Names.
Reflections on the DNS, RFC 1591, and Categories of Domains.
Distributing Authoritative Name Servers via
Shared Unicast Addresses.
DNS IPv6 Transport Operational Guidelines.
DNS Encoding of Geographical
Binary Labels in the Domain Name System.
DNS Extensions to Support IPv6 Address Aggregation
Most of these have been consolidated into RFC4033,
RFC4034 and RFC4035 which collectively describe DNSSECbis.
Domain Name System Security Extensions.
Secure Domain Name System Dynamic Update.
Domain Name System Security Extensions.
Domain Name System Security (DNSSEC)
DNS Security Extension Clarification on Zone Status.
Limiting the Scope of the KEY Resource Record (RR).
Redefinition of DNS Authenticated Data (AD) bit.
Delegation Signer (DS) Resource Record (RR).
Legacy Resolver Compatibility for Delegation Signer (DS).
Domain Name System KEY (DNSKEY) Resource Record
(RR) Secure Entry Point (SEP) Flag.
DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format.
Internet Drafts (IDs) are rough-draft working documents of
the Internet Engineering Task Force. They are, in essence, RFCs
in the preliminary stages of development. Implementors are
to regard IDs as archival, and they should not be quoted or cited
in any formal documents unless accompanied by the disclaimer that
they are "works in progress." IDs have a lifespan of six months
after which they are deleted unless updated by their authors.
Other Documents About BIND
DNS and BIND.
Copyright © 1998 Sebastopol, CA: O'Reilly and Associates.