ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-08-10 16:52:10 +00:00
parent a81dd161f7
commit 6007bd1c1e
7 changed files with 1944 additions and 1404 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1158
doc/draft/draft-ietf-dnsext-gss-tsig-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

124
doc/draft/draft-ietf-dnsext-tkey-03.txt → doc/draft/draft-ietf-dnsext-tkey-04.txt
View File

@@ -1,13 +1,13 @@
DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola
Expires: December 2000 June 2000
Expires: January 2001 July 2000
Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
<draft-ietf-dnsext-tkey-03.txt>
<draft-ietf-dnsext-tkey-04.txt>
@@ -24,10 +24,11 @@ Status of This Document
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."
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
@@ -53,22 +54,20 @@ Status of This Document
Donald Eastlake 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
Abstract
[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
Domain Name System (DNS) queries and responses using shared secret
keys via the TSIG resource record (RR). However, it provides no
mechanism for setting up such keys other than manual exchange. This
document describes a TKEY RR that can be used in a number of
different modes to establish shared secret keys between a DNS
resolver and server.
[RFC 2845] provides a means of authenticating Domain Name System
(DNS) queries and responses using shared secret keys via the TSIG
resource record (RR). However, it provides no mechanism for setting
up such keys other than manual exchange. This document describes a
TKEY RR that can be used in a number of different modes to establish
shared secret keys between a DNS resolver and server.
@@ -110,12 +109,13 @@ Acknowledgments
Donald Eastlake 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
Table of Contents
@@ -173,7 +173,7 @@ Table of Contents
Donald Eastlake 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
1. Introduction
@@ -185,12 +185,12 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed.
[draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently
authenticating DNS messages using shared secret keys via the TSIG
resource record (RR) but provides no mechanism for setting up such
keys other than manual exchange. This document specifies a TKEY RR
that can be used in a number of different modes to establish and
delete such shared secret keys between a DNS resolver and server.
[RFC 2845] provides a means of efficiently authenticating DNS
messages using shared secret keys via the TSIG resource record (RR)
but provides no mechanism for setting up such keys other than manual
exchange. This document specifies a TKEY RR that can be used in a
number of different modes to establish and delete such shared secret
keys between a DNS resolver and server.
Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated
@@ -231,7 +231,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
servers which is currently used only for key deletion.
@@ -289,7 +289,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
name SHOULD be a domain locally unique at the resolver, less than 128
@@ -327,9 +327,9 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same
meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm
determines how the secret keying material agreed to using the TKEY RR
is actually used to derive the algorithm specific key.
meaning as in [RFC 2845]. The algorithm determines how the secret
keying material agreed to using the TKEY RR is actually used to
derive the algorithm specific key.
@@ -347,7 +347,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
To avoid different interpretations of the inception and expiration
@@ -390,9 +390,9 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (tsig)
17 BADKEY (tsig)
18 BADTIME (tsig)
16 BADSIG (TSIG)
17 BADKEY (TSIG)
18 BADTIME (TSIG)
19 BADMODE
20 BADNAME
21 BADALG
@@ -405,7 +405,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
RR and DNS header error field could have unrelated non-zero error
@@ -463,7 +463,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
TKEY queries MUST be authenticated for all modes except GSS-API and,
@@ -521,7 +521,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
algorithm field is set to the authentication algorithm the resolver
@@ -579,7 +579,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
the discarded key.
@@ -637,18 +637,17 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is
authenticated by the resolver with a TSIG RR [draft-ietf-dnsext-
tsig-*.txt] or SIG(0) RR and that authentication is verified, then
any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in
such a query SHOULD have a name that corresponds to the resolver but
it is only essential that it be a public key for which the resolver
has the corresponding private key so it can decrypt the response
data.
authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
and that authentication is verified, then any SIG(KEY) provided in
the query SHOULD be ignored. The KEY RR in such a query SHOULD have
a name that corresponds to the resolver but it is only essential that
it be a public key for which the resolver has the corresponding
private key so it can decrypt the response data.
The server response contains a TKEY RR in its answer section with the
server assigned mode and echoes the KEY RR provided in the query in
@@ -690,15 +689,15 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the
Donald Eastlake 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR. It is also important that
no untrusted party (preferably no other party than the server) has
the private key corresponding to the KEY RR because, if they do, they
@@ -750,10 +749,11 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
6. Methods of Encryption
@@ -790,10 +790,10 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action. Special
consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF.
Mode field values 0x0000 and 0xFFFF are reserved.
Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
can only be assigned by an IETF Standards Action.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus.
@@ -811,7 +811,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
The following assignments are documented herein:
@@ -829,7 +829,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in
support of TSIG [draft-ietf-dnsext-tsig-*.txt].
support of TSIG [RFC 2845].
Protection against denial of service via the use of TKEY is not
provided.
@@ -869,7 +869,7 @@ INTERNET-DRAFT The DNS TKEY RR June 2000
Donald Eastlake 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
References
@@ -916,9 +916,9 @@ References
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999.
draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
RFC 2845 - P. Vixie, O. Gudmundsson, D. Eastlake, B.
Wellington,"Secret Key Transaction Authentication for DNS (TSIG)",
May 2000.
@@ -927,7 +927,7 @@ References
Donald Eastlake 3rd [Page 16]
INTERNET-DRAFT The DNS TKEY RR June 2000
INTERNET-DRAFT The DNS TKEY RR July 2000.
Author's Address
@@ -939,17 +939,17 @@ Author's Address
Telephone: +1 978-562-2827 (h)
+1 508-261-5434 (w)
FAX: +1 978-567-7941 (h)
+1 508-261-4447 (w)
FAX: +1 508-261-4447 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires December 2000.
This draft expires January 2001.
Its file name is draft-ietf-dnsext-tkey-04.txt.
Its file name is draft-ietf-dnsext-tkey-03.txt.

587
doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt
View File

@@ -1,587 +0,0 @@
IPng Working Group R. Draves
Internet Draft Microsoft Research
Document: draft-ietf-ipngwg-default-addr-select-00.txt October 22, 1999
Category: Standards Track
Default Address Selection for IPv6
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
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 describes two algorithms, for destination address
ordering and for source address selection. The algorithms specify
default behavior for all IPv6 implementations. They do not override
choices made by applications or upper-layer protocols, nor do they
preclude the development of more advanced mechanisms for address
selection. The two algorithms share a common framework, including an
optional mechanism for allowing administrators to provide policy
that can override the default behavior.
1. Introduction
The IPv6 addressing architecture [2] allows multiple unicast
addresses to be assigned to interfaces. These addresses may have
different reachability scopes (link-local, site-local, or global).
These addresses may be "preferred" or "deprecated" [3]. In addition,
multi-homing situations will result in more addresses per node. For
example, a node may have multiple interfaces, some of them tunnels
or virtual interfaces, or a site may have multiple ISP attachments.
The end result is that IPv6 implementations will very often be faced
with multiple possible source and destination addresses when
initiating communication. It is desirable to have simple default
algorithms, common across all implementations, for selecting source
Draves Standards Track - Expires May 2000 1
Default Address Selection for IPv6 October 22, 1999
and destination addresses so that developers and administrators can
reason about and predict the behavior of their systems.
This document specifies source address selection and destination
address selection separately, but using a common framework so that
together the two algorithms yield useful results. The algorithms
attempt to choose source and destination addresses of appropriate
scope and configuration status (preferred or deprecated).
Furthermore, this document suggests a preferred method, longest
matching prefix, for choosing among otherwise equivalent addresses
in the absence of better information.
The framework also has policy hooks to allow administrative override
of the default behavior. For example, using these hooks an
administrator can specify a preferred source prefix for use with a
destination prefix, or prefer destination addresses with one prefix
over addresses with another prefix. These hooks give an
administrator flexibility in dealing with some multi-homing and
transition scenarios, but they are certainly not a panacea.
The rules specified in this document MUST NOT be construed to
override an application or upper-layer's explicit choice of
destination or source address.
1.1. Conventions used in this document
The key words "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 [4].
2. Framework
Our framework for address selection derives from the most common
implementation architecture, which separates the choice of
destination address from the choice of source address. Consequently,
the framework specifies two separate algorithms for these tasks. The
algorithms are designed to work well together and they share a
mechanism for administrative policy override.
In this implementation architecture, applications use APIs [5] like
getipnodebyname() and getaddrinfo() that return a list of addresses
to the application. The application then passes a destination
address to the IPv6 layer with connect() or sendto(). The
application might just use the first address in the list, or it
might loop over the list of addresses to find a working address. In
any case, the IPv6 network layer is never in a position where it
needs to choose a destination address from several alternatives. The
application might also specify a source address with bind(), but
often the source address is left unspecified. Therefore the IPv6
layer does often choose a source address from several alternatives.
As a consequence, we intend that implementations of
getipnodebyname() and getaddrinfo() will use the destination address
Draves Standards Track - Expires May 2000 2
Default Address Selection for IPv6 October 22, 1999
ordering algorithm specified here to sort the list of addresses that
they return. Separately, the IPv6 network layer will use the source
address selection algorithm when an application or upper-layer has
not specified a source address.
The algorithms use several criteria in making their decisions. The
combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non-
deprecated source addresses of sufficient scope to reach the
destination, avoid the use of transitional addresses when native
addresses are available, and all else being equal prefer address
pairs having the longest possible common prefix.
The framework optionally allows for the possibility of
administrative configuration of policy that can override the default
behavior of the algorithms. The policy override takes the form of a
configurable table that provides precedence values and preferred
source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured,
then the default policy table specified in this document MUST be
used.
2.1. Scope Comparisons
Multicast destination addresses have a 4-bit scope field that
controls the propagation of the multicast packet. The IPv6
addressing architecture defines scope field values for node-local
(0x1), link-local (0x2), site-local (0x5), organization-local (0x8),
and global (0xE) scopes.
Application of the address selection algorithms in the presence of
multicast destination addresses requires the comparison of a unicast
address scope with a multicast address scope. We map unicast link-
local to multicast link-local, unicast site-local to multicast site-
local, and unicast global scope to multicast global scope. For
example, unicast site-local is equal to multicast site-local, which
is smaller than multicast organization-local, which is smaller than
unicast global, which is equal to multicast global.
We write Scope(A) to mean the scope of address A. For example, if A
is a link-local unicast address and B is a site-local multicast
address, then Scope(A) < Scope(B).
This mapping implicitly conflates unicast site boundaries and
multicast site boundaries.
2.2. IPv4-Compatible Addresses and Other Format Prefixes
For the purposes of this document, IPv4-compatible addresses have
global scope and "preferred" configuration status.
Draves Standards Track - Expires May 2000 3
Default Address Selection for IPv6 October 22, 1999
Similarly, NSAP addresses, IPX addresses, or addresses with as-yet-
undefined format prefixes should be treated as having global scope
and "preferred" configuration status. Later standards may supercede
this treatment.
The loopback address should be treated as having link-local scope
and "preferred" configuration status.
2.3. Policy Table
The policy table is a longest-matching-prefix lookup table, like a
routing table. Given an address A, a lookup in the policy table
produces three values: a precedence value Precedence(A), a
classification or label Label(A), and a second label
MatchSrcLabel(A).
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm
will prefer to sort destination address A before destination address
B.
The labels Label(A) and MatchSrcLabel(A) allow for policies that
prefer a particular source address prefix for use with a destination
address prefix. The algorithms prefer to use a source address S with
a destination address D if Label(S) = MatchSrcLabel(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
here. If an implementation is not configurable or has not been
configured, then it MUST operate according to the algorithms
specified here in conjunction with the following default policy
table:
Prefix Precedence Label MatchSrcLabel
fe80::/10 40 1 1
fec0::/10 30 2 2
::/0 20 3 3
2002::/16 10 4 4
::/96 10 5 5
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 source
addresses with 6to4 destination addresses, and v4-compatible source
addresses with v4-compatible destination addresses. Another effect
of the default policy table is to prefer communication using native
addresses to communication using either 6to4 or v4-compatible
addresses, but not to express a preference for 6to4 addresses over
v4-compatible addresses or vice-versa.
Draves Standards Track - Expires May 2000 4
Default Address Selection for IPv6 October 22, 1999
2.4. Candidate Source Addresses
Both the destination address ordering algorithm and the source
address selection algorithm use the concept of a "candidate set" of
potential source addresses for a given destination address.
We write CandidateSrc(A) to denote the candidate set for the address
A. In some cases the destination address A may be qualified with a
scope-id or other information that will constrain the candidate set.
We write PreferSrc(A) to denote the subset of preferred (non-
deprecated) addresses in CandidateSrc(A) We write MatchSrc(A) to
denote the subset of addresses S in PreferSrc(A) for which Label(S)
= MatchSrcLabel(A).
The destination address ordering algorithm and the source address
selection algorithm specify somewhat different definitions for
CandidateSrc(A). This is because the two algorithms operate in
different environments. The source address selection algorithm
assumes that an outgoing interface for a packet has already been
selected, while the destination address ordering algorithm does not
assume that knowledge. Therefore the destination address ordering
algorithm uses a broader or more-inclusive definition of
CandidateSrc(A).
In any case, anycast addresses, multicast addresses, and the
unspecified address MUST NOT be included in a candidate set.
2.5. Common Prefix Length
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix that the two
addresses have in common. It ranges from 0 to 128.
We define the maximum common prefix length MaxCommonPrefixLen(A, X)
of an address A and a non-empty set of addresses X as the maximum of
CommonPrefixLen(A, B) for addresses B in the set X.
3. Destination Address Ordering
The destination address ordering algorithm takes a list of
destination addresses and sorts the addresses to produce a new list.
It is specified here in terms of the pair-wise comparison of
addresses DA and DB, where DA appears before DB in the original
list.
The pair-wise comparison consists of four rules, which MUST be
applied in order. If a rule determines a result, then the remaining
rules are not relevant and MUST be ignored. Subsequent rules act as
tie-breakers for earlier rules.
Rule 1: If MatchSrc(DA) is non-empty and MatchSrc(DB) is empty, then
sort DA before DB. Similarly, if MatchSrc(DA) is empty and
MatchSrc(DB) is non-empty, then sort DB before DA.
Draves Standards Track - Expires May 2000 5
Default Address Selection for IPv6 October 22, 1999
Rule 2: If Precedence(A) > Precedence(B), then sort DA before DB.
Similarly, if Precedence(B) > Precedence(A), then sort DB before DA.
Rule 3: If MatchSrc(DA) and MatchSrc(DB) are both non-empty. If
MaxCommonPrefixLen(DA, MatchSrc(DA)) > MaxCommonPrefixLen(DB,
MatchSrc(DB)), then sort DA before DB. Similarly, if
MaxCommonPrefixLen(DB, MatchSrc(DB)) > MaxCommonPrefixLen(DA,
MatchSrc(DA)), then sort DB before DA.
Rule 4: Sort DA before DB.
The third and fourth rules MAY be superceded if the implementation
has other means of sorting destination addresses. For example, if
the implementation somehow knows which destination addresses will
result in the "best" communications performance.
3.1. Candidate Source Addresses
For the purposes of destination address ordering, the candidate set
of source addresses CandidateSrc(D) for a destination address D
SHOULD contain all and only the unicast addresses assigned to
interfaces that might be used to send to the destination D.
For example, if the address D is a link-local unicast address that
is qualified with a scope-id value specifying a particular
interface, then CandidateSrc(D) SHOULD contain all and only the
unicast addresses assigned to that interface.
For example, if the address D is a global scope unicast address,
then CandidateSrc(D) MAY contain every unicast address assigned to
all interfaces. However if the implementation wishes to consult a
routing table and determine a likely outgoing interface, then
CandidateSrc(D) MAY contain only unicast addresses assigned to that
outgoing interface.
4. Source Address Selection
The source address selection algorithm chooses a source address for
use with a destination address D. It is specified here in terms of
the pair-wise comparison of addresses SA and SB. The pair-wise
comparison can be used to select an address from the set
CandidateSrc(D).
The pair-wise comparison consists of six rules, which MUST be
applied in order. If a rule chooses an address, then the remaining
rules are not relevant and MUST be ignored. Subsequent rules act as
tie-breakers for earlier rules. If the six rules fail to choose an
address, some unspecified tie-breaker MUST be used.
Rule 1: If SA is in MatchSrc(D) and SB is not, then choose SA.
Similarly, if SB is in MatchSrc(D) and SA is not, then choose SB.
Draves Standards Track - Expires May 2000 6
Default Address Selection for IPv6 October 22, 1999
Rule 2: If SA is equal to D, then choose SA. Similarly, if SB is
equal to D, then choose SB.
Rule 3a: If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then
choose SB. Otherwise, if one of the source addresses is "preferred"
and one of them is "deprecated", then choose the "preferred"
address. Otherwise, choose SA.
Rule 3b: Similarly, if Scope(SB) < Scope(SA). If Scope(SB) <
Scope(D), then choose SA. Otherwise, if one of the source addresses
is "preferred" and one of them is "deprecated", then choose the
"preferred" address. Otherwise, choose SB.
Rule 4: The addresses SA and SB have the same scope. If one of the
source addresses is "preferred" and one of them is "deprecated", an
implementation MUST choose the one that is preferred.
Rule 5: If Label(SA) = MatchSrcLabel(D) and Label(SB) <>
MatchSrcLabel(D), then choose SA. Similarly, if Label(SA) <>
MatchSrcLabel(D) and Label(SB) = MatchSrcLabel(D), then choose SB.
(Note that this rule will apply only when both SA and SB are
deprecated.)
Rule 6: If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then
choose SA. Similarly, if CommonPrefixLen(SB, D) >
CommonPrefixLen(SA, D), then choose SB.
The sixth rule MAY be superceded if the implementation has other
means of choosing among source addresses. For example, if the
implementation somehow knows which source address will result in the
"best" communications performance.
4.1. Candidate Source Addresses
For the purposes of source address selection, the candidate set of
source addresses CandidateSrc(D) for a destination address D MUST
contain all and only the unicast addresses assigned to the interface
that will be used to send to the destination D.
5. Interactions with Routing
All IPv6 nodes, including both hosts and routers, MUST conform to
this specification.
This specification of source address selection implies that routing
(more precisely, selecting an outgoing interface on a node with
multiple interfaces) is done before source address selection.
However, implementations MAY use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes.
For example, suppose a node has interfaces on two different links,
with both links having a working default router. One of the
interfaces has a preferred global address and the other interface
Draves Standards Track - Expires May 2000 7
Default Address Selection for IPv6 October 22, 1999
only has a deprecated global address. When sending to a global
destination address, if there's no routing reason to prefer one
interface over the other, then an implementation MAY preferentially
choose the outgoing interface that will allow it to use the
preferred global source address.
6. Interactions with Mobility
TBD
7. Implementation Considerations
The destination address ordering algorithm needs information about
potential source addresses. One possible implementation strategy is
for getipnodebyname() and getaddrinfo() to call down to the IPv6
network layer with a list of destination addresses, sort the list in
the network layer with full current knowledge of available source
addresses, and return the sorted list to getipnodebyname() or
getaddrinfo(). This is simple but it introduces overhead.
Another implementation strategy is to call down to the network layer
to retrieve source address information and then sort the list of
addresses directly in the context of getipnodebyname() or
getaddrinfo(). To reduce overhead in this approach, the source
address information SHOULD be cached, amortizing the overhead of
retrieving it across multiple calls to getipnodebyname() and
getaddrinfo(). If an implementation uses cached and possibly stale
source address information in its implementation of destination
address ordering, then it MUST ensure that the source address
information is no more than one second out of date.
8. Security Considerations
This document has no direct impact on Internet infrastructure
security.
References
1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
3 S. Thompson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462 , December 1998.
4 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999.
Draves Standards Track - Expires May 2000 8
Acknowledgments
The author would like to acknowledge the contributions of the IPng
Working Group.
Author's Address
Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052
Email: richdr@microsoft.com
Revision History
Changes from draft-draves-ipngw-simple-srcaddr-01
Added framework discussion.
Added algorithm for destination address ordering.
Added mechanism to allow the specification of administrative policy
that can override the default behavior.
Added section on routing interactions and TBD section on mobility
interactions.
Changed the candidate set definition for source address selection,
so that only addresses assigned to the outgoing interface are
allowed.
Changed the loopback address treatment to link-local scope.
Changes from draft-draves-ipngw-simple-srcaddr-00
Minor wording changes because DHCPv6 also supports "preferred" and
"deprecated" addresses.
Specified treatment of other format prefixes; now they are
considered global scope, "preferred" addresses.
Reiterated that anycast and multicast addresses are not allowed as
source addresses.
Recommended that source addresses be taken from the outgoing
interface. Required this for multicast destinations. Added analogous
requirements for link-local and site-local destinations.
Specified treatment of the loopback address.
Changed the second selection rule so that if both candidate source
addresses have scope greater or equal than the destination address
and only of them is preferred, the preferred address is chosen.
Draves Standards Track - Expires May 2000 9
Default Address Selection for IPv6 October 22, 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Draves Standards Track - Expires May 2000 10

695
doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt Normal file
View File

@@ -0,0 +1,695 @@
IPng Working Group Richard Draves
Internet Draft Microsoft Research
Document: draft-ietf-ipngwg-default-addr-select-01.txt July 14, 2000
Category: Standards Track
Default Address Selection for IPv6
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
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 describes two algorithms, for source address selection
and for destination address selection. The algorithms specify
default behavior for all IPv6 implementations. They do not override
choices made by applications or upper-layer protocols, nor do they
preclude the development of more advanced mechanisms for address
selection. The two algorithms share a common framework, including an
optional mechanism for allowing administrators to provide policy
that can override the default behavior. In dual stack
implementations, the framework allows the destination address
selection algorithm to consider both IPv4 and IPv6 addresses -
depending on the available source addresses, the algorithm might
prefer IPv6 addresses over IPv4 addresses, or vice-versa.
1. Introduction
The IPv6 addressing architecture [2] allows multiple unicast
addresses to be assigned to interfaces. These addresses may have
different reachability scopes (link-local, site-local, or global).
These addresses may also be "preferred" or "deprecated" [3]. Privacy
considerations have introduced the concepts of "public addresses"
and "anonymous addresses" [4]. The mobility architecture introduces
"home addresses" and "care-of addresses" [5]. In addition, multi-
homing situations will result in more addresses per node. For
Draves Standards Track - Expires January 2001 1
Default Address Selection for IPv6 July 14, 2000
example, a node may have multiple interfaces, some of them tunnels
or virtual interfaces, or a site may have multiple ISP attachments
with a global prefix per ISP.
The end result is that IPv6 implementations will very often be faced
with multiple possible source and destination addresses when
initiating communication. It is desirable to have simple default
algorithms, common across all implementations, for selecting source
and destination addresses so that developers and administrators can
reason about and predict the behavior of their systems.
Furthermore, dual or hybrid stack implementations, which support
both IPv6 and IPv4, will very often need to choose between IPv6 and
IPv4 when initiating communication. For example, when DNS name
resolution yields both IPv6 and IPv4 addresses and the network
protocol stack has available both IPv6 and IPv4 source addresses. In
such cases, a simple policy to always prefer IPv6 or always prefer
IPv4 can produce poor behavior. As one example, suppose a DNS name
resolves to a global IPv6 address and a global IPv4 address. If the
node has assigned a global IPv6 address and a 169.254/16 "autonet"
IPv4 address, then IPv6 is the best choice for communication. But if
the node has assigned only a link-local IPv6 address and a global
IPv4 address, then IPv4 is the best choice for communication. The
destination address selection algorithm solves this with a unified
procedure for choosing among both IPv6 and IPv4 addresses.
This document specifies source address selection and destination
address selection separately, but using a common framework so that
together the two algorithms yield useful results. The algorithms
attempt to choose source and destination addresses of appropriate
scope and configuration status (preferred or deprecated).
Furthermore, this document suggests a preferred method, longest
matching prefix, for choosing among otherwise equivalent addresses
in the absence of better information.
The framework also has policy hooks to allow administrative override
of the default behavior. For example, using these hooks an
administrator can specify a preferred source prefix for use with a
destination prefix, or prefer destination addresses with one prefix
over addresses with another prefix. These hooks give an
administrator flexibility in dealing with some multi-homing and
transition scenarios, but they are certainly not a panacea.
The rules specified in this document MUST NOT be construed to
override an application or upper-layer's explicit choice of
destination or source address.
1.1. Conventions used in this document
The key words "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 [6].
Draves Standards Track - Expires May 2000 2
Default Address Selection for IPv6 July 14, 2000
2. Framework
Our framework for address selection derives from the most common
implementation architecture, which separates the choice of
destination address from the choice of source address. Consequently,
the framework specifies two separate algorithms for these tasks. The
algorithms are designed to work well together and they share a
mechanism for administrative policy override.
In this implementation architecture, applications use APIs [7] like
getaddrinfo() and getipnodebyname() that return a list of addresses
to the application. This list might contain both IPv6 and IPv4
addresses (sometimes represented as IPv4-mapped addresses). The
application then passes a destination address to the network stack
with connect() or sendto(). The application might use only the first
address in the list, or it might loop over the list of addresses to
find a working address. In any case, the network layer is never in a
situation where it needs to choose a destination address from
several alternatives. The application might also specify a source
address with bind(), but often the source address is left
unspecified. Therefore the network layer does often choose a source
address from several alternatives.
As a consequence, we intend that implementations of getaddrinfo()
and getipnodebyname() will use the destination address selection
algorithm specified here to sort the list of IPv6 and IPv4 addresses
that they return. Separately, the IPv6 network layer will use the
source address selection algorithm when an application or upper-
layer has not specified a source address. Application of this
framework to source address selection in an IPv4 network layer may
be possible but this is not explored further here.
The algorithms use several criteria in making their decisions. The
combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non-
deprecated source addresses of sufficient scope to reach the
destination, avoid the use of transitional addresses when native
addresses are available, and all else being equal prefer address
pairs having the longest possible common prefix. For source address
selection, an anonymous address [4] is preferred over its
corresponding public address. In mobile situations [5], home
addresses are preferred over care-of addresses.
The framework optionally allows for the possibility of
administrative configuration of policy that can override the default
behavior of the algorithms. The policy override takes the form of a
configurable table that provides precedence values and preferred
source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured,
then the default policy table specified in this document SHOULD be
used.
Draves Standards Track - Expires May 2000 3
Default Address Selection for IPv6 July 14, 2000
2.1. Scope Comparisons
Multicast destination addresses have a 4-bit scope field that
controls the propagation of the multicast packet. The IPv6
addressing architecture defines scope field values for node-local
(0x1), link-local (0x2), site-local (0x5), organization-local (0x8),
and global (0xE) scopes.
Use of the source address selection algorithm in the presence of
multicast destination addresses requires the comparison of a unicast
address scope with a multicast address scope. We map unicast link-
local to multicast link-local, unicast site-local to multicast site-
local, and unicast global scope to multicast global scope. For
example, unicast site-local is equal to multicast site-local, which
is smaller than multicast organization-local, which is smaller than
unicast global, which is equal to multicast global.
We write Scope(A) to mean the scope of address A. For example, if A
is a link-local unicast address and B is a site-local multicast
address, then Scope(A) < Scope(B).
This mapping implicitly conflates unicast site boundaries and
multicast site boundaries.
2.2. IPv4-Compatible Addresses and Other Format Prefixes
For the purposes of this document, IPv4-compatible addresses have
global scope and "preferred" configuration status.
Similarly, NSAP addresses, IPX addresses, or addresses with as-yet-
undefined format prefixes should be treated as having global scope
and "preferred" configuration status. Later standards may supercede
this treatment.
The loopback address should be treated as having link-local scope
and "preferred" configuration status.
2.3. IPv4 Addresses and IPv4-Mapped Addresses
The destination address selection algorithm operates on both IPv6
and IPv4 addresses. For this purpose, IPv4 addresses should be
represented as IPv4-mapped addresses. For example, to lookup the
precedence or other attributes of an IPv4 address in the policy
table, lookup the corresponding IPv4-mapped IPv6 address.
2.4. Policy Table
The policy table is a longest-matching-prefix lookup table, much
like a routing table. Given an address A, a lookup in the policy
table produces three values: a precedence value Precedence(A), a
classification or label Label(A), and a second label
MatchSrcLabel(A).
Draves Standards Track - Expires May 2000 4
Default Address Selection for IPv6 July 14, 2000
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm
will prefer to sort destination address A before destination address
B.
The labels Label(A) and MatchSrcLabel(A) allow for policies that
prefer a particular source address prefix for use with a destination
address prefix. The algorithms prefer to use a source address S with
a destination address D if Label(S) = MatchSrcLabel(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
here. If an implementation is not configurable or has not been
configured, then it SHOULD operate according to the algorithms
specified here in conjunction with the following default policy
table:
Prefix Precedence Label MatchSrcLabel
::1/128 100 1 1
fe80::/10 90 2 2
fec0::/10 80 3 3
::/0 70 4 4
2002::/16 60 5 5
::/96 50 6 6
::ffff:169.254.0.0/112 30 7 7
::ffff:10.0.0.0/104 20 8 8
::ffff:172.16.0.0/108 20 9 9
::ffff:192.168.0.0/112 20 10 10
::ffff:0:0/96 10 11 11
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 source
addresses with 6to4 destination addresses, and v4-compatible source
addresses with v4-compatible destination addresses. Another effect
of the default policy table is to prefer communication using IPv6
addresses to communication using IPv4 addresses, if matching source
addresses are available.
Policy table entries for scoped address prefixes MAY be qualified
with an optional scope-id. If so, a prefix table entry only matches
against an address during a lookup if the scope-id also matches the
address's scope-id.
2.5. Common Prefix Length
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix (looking at
the most significant, or leftmost, bits) that the two addresses have
in common. It ranges from 0 to 128.
Draves Standards Track - Expires May 2000 5
Default Address Selection for IPv6 July 14, 2000
3. Candidate Source Addresses
The source address selection algorithm uses the concept of a
"candidate set" of potential source addresses for a given
destination address. We write CandidateSource(A) to denote the
candidate set for the address A.
It is RECOMMENDED that the candidate source addresses be the set of
unicast addresses assigned to the interface that will be used to
send to the destination. (The "outgoing" interface.) On routers, the
candidate set MAY include unicast addresses assigned to any
interface that could forward the destination address to the outgoing
interface.
In some cases the destination address may be qualified with a scope-
id or other information that will constrain the candidate set.
For multicast and link-local destination addresses, the set of
candidate source addresses MUST only include addresses assigned to
interfaces belonging to the same link as the outgoing interface.
For site-local destination addresses, the set of candidate source
addresses MUST only include addresses assigned to interfaces
belonging to the same site as the outgoing interface.
In any case, anycast addresses, multicast addresses, and the
unspecified address MUST NOT be included in a candidate set.
4. Source Address Selection
The source address selection algorithm chooses a source address for
use with a destination address D. It is specified here in terms of
the pair-wise comparison of addresses SA and SB. The pair-wise
comparison can be used to select an address from the set
CandidateSource(D).
The pair-wise comparison consists of eight rules, which MUST be
applied in order. If a rule chooses an address, then the remaining
rules are not relevant and MUST be ignored. Subsequent rules act as
tie-breakers for earlier rules. If the eight rules fail to choose an
address, some unspecified tie-breaker must be used.
Rule 1: Prefer same address.
If SA = D, then choose SA. Similarly, if SB = D, then choose SB.
Rule 2: Prefer matching label.
If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D),
then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and
Label(SA) <> MatchSrcLabel(D), then choose SB.
Draves Standards Track - Expires May 2000 6
Default Address Selection for IPv6 July 14, 2000
Rule 3: Prefer appropriate scope.
If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB.
Otherwise, if one of the source addresses is "preferred" and one of
them is "deprecated", then choose the "preferred" address.
Otherwise, choose SA.
Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then
choose SA. Otherwise, if one of the source addresses is "preferred"
and one of them is "deprecated", then choose the "preferred"
address. Otherwise, choose SB.
Rule 4: Avoid deprecated addresses.
The addresses SA and SB have the same scope. If one of the source
addresses is "preferred" and one of them is "deprecated", an
implementation MUST choose the one that is preferred.
Rule 5: Prefer home addresses.
If SA is a home address and SB is a care-of address, then prefer SA.
Similarly, if SB is a home address and SA is a care-of address, then
prefer SB.
An implementation MAY support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of
this preference and prefer care-of addresses over home addresses.
Rule 6: Prefer outgoing interface.
If SA is assigned to the interface that will be used to send to D
and SB is assigned to a different interface, then prefer SA.
Similarly, if SB is assigned to the interface that will be used to
send to D and SA is assigned to a different interface, then prefer
SB.
Rule 7: Prefer anonymous addresses.
If SA is an anonymous address and SB is its corresponding public
address, then prefer SA. Similarly, if SB is an anonymous address
and SA is its corresponding public address, then prefer SB.
An implementation MAY support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of
this preference and prefer public addresses over anonymous
addresses.
Rule 8: Use longest matching prefix.
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
choose SB.
Rule 8 MAY be superceded if the implementation has other means of
choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.
5. Destination Address Selection
The destination address selection algorithm takes a list of
destination addresses and sorts the addresses to produce a new list.
Draves Standards Track - Expires May 2000 7
Default Address Selection for IPv6 July 14, 2000
It is specified here in terms of the pair-wise comparison of
addresses DA and DB, where DA appears before DB in the original
list.
The destination address selection algorithm uses the source address
selection algorithm as a subroutine. We write Source(D) to indicate
the selected source address for a destination D.
The pair-wise comparison of destination addresses consists of four
rules, which MUST be applied in order. If a rule determines a
result, then the remaining rules are not relevant and MUST be
ignored. Subsequent rules act as tie-breakers for earlier rules.
Rule 1: Prefer destinations with a matching source.
If Label(Source(DA)) = MatchSrcLabel(DA) and Label(Source(DB)) <>
MatchSrcLabel(DB), then sort DA before DB. Similarly, if
Label(Source(DB)) = MatchSrcLabel(DB) and Label(Source(DA)) <>
MatchSrcLabel(DA), then sort DB before DA.
Rule 2: Prefer higher precedence.
If Precedence(DA) > Precedence(DB), then sort DA before DB.
Similarly, if Precedence(DB) > Precedence(DA), then sort DB before
DA.
Rule 3: Use longest matching prefix.
Applies only if Label(Source(DA)) = MatchSrcLabel(DA) and
Label(Source(DB)) = MatchSrcLabel(DB).
If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB,
Source(DB)), then sort DA before DB. Similarly, if
CommonPrefixLen(DB, Source(DB)) > CommonPrefixLen(DA, Source(DA)),
then sort DB before DA.
Rule 4: Otherwise, leave the order unchanged.
Sort DA before DB.
The third and fourth rules MAY be superceded if the implementation
has other means of sorting destination addresses. For example, if
the implementation somehow knows which destination addresses will
result in the "best" communications performance.
6. Interactions with Routing
All IPv6 nodes, including both hosts and routers, SHOULD conform to
this specification.
This specification of source address selection assumes that routing
(more precisely, selecting an outgoing interface on a node with
multiple interfaces) is done before source address selection.
However, implementations MAY use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes.
For example, suppose a node has interfaces on two different links,
with both links having a working default router. Both of the
Draves Standards Track - Expires May 2000 8
Default Address Selection for IPv6 July 14, 2000
interfaces have preferred global addresses. When sending to a global
destination address, if there's no routing reason to prefer one
interface over the other, then an implementation MAY preferentially
choose the outgoing interface that will allow it to use the source
address that shares a longer common prefix with the destination.
7. Implementation Considerations
The destination address selection algorithm needs information about
potential source addresses. One possible implementation strategy is
for getipnodebyname() and getaddrinfo() to call down to the IPv6
network layer with a list of destination addresses, sort the list in
the network layer with full current knowledge of available source
addresses, and return the sorted list to getipnodebyname() or
getaddrinfo(). This is simple and gives the best results but it
introduces the overhead of another system call. One way to reduce
this overhead is to cache the sorted address list in the resolver,
so that subsequent calls for the same name do not need to resort the
list.
Another implementation strategy is to call down to the network layer
to retrieve source address information and then sort the list of
addresses directly in the context of getipnodebyname() or
getaddrinfo(). To reduce overhead in this approach, the source
address information can be cached, amortizing the overhead of
retrieving it across multiple calls to getipnodebyname() and
getaddrinfo().
In any case, if the implementation uses cached and possibly stale
information in its implementation of destination address selection,
or if the ordering of a cached list of destination addresses is
possibly stale, then it MUST ensure that the destination address
ordering returned to the application is no more than one second out
of date. For example, an implementation might make a system call to
check if any routing table entries or source address assignments
that might affect these algorithms have changed.
8. Security Considerations
This document has no direct impact on Internet infrastructure
security.
References
1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
3 S. Thompson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462 , December 1998.
Draves Standards Track - Expires May 2000 9
Default Address Selection for IPv6 July 14, 2000
4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy-
01.txt, July 2000.
5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
mobileip-ipv6-12.txt, April 2000.
6 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999.
Acknowledgments
The author would like to acknowledge the contributions of the IPng
Working Group.
Author's Address
Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052
Phone: 1-425-936-2268
Email: richdr@microsoft.com
Revision History
Changes from draft-ietf-ipngwg-default-addr-select-00
Changed the candidate set definition so that the strong host model
is recommended but not required. Added a rule to source address
selection to prefer addresses assigned to the outgoing interface.
Simplified the destination address selection algorithm, by having it
use source address selection as a subroutine.
Added a rule to source address selection to handle anonymous/public
addresses.
Added a rule to source address selection to handle home/care-of
addresses.
Changed to allow destination address selection to sort both IPv6 and
IPv4 addresses. Added entries in the default policy table for IPv4-
mapped addresses.
Changed default precedences, so v4-compatible addresses have lower
precedence than 6to4 addresses.
Draves Standards Track - Expires May 2000 10
Default Address Selection for IPv6 July 14, 2000
Changes from draft-draves-ipngwg-simple-srcaddr-01
Added framework discussion.
Added algorithm for destination address ordering.
Added mechanism to allow the specification of administrative policy
that can override the default behavior.
Added section on routing interactions and TBD section on mobility
interactions.
Changed the candidate set definition for source address selection,
so that only addresses assigned to the outgoing interface are
allowed.
Changed the loopback address treatment to link-local scope.
Changes from draft-draves-ipngwg-simple-srcaddr-00
Minor wording changes because DHCPv6 also supports "preferred" and
"deprecated" addresses.
Specified treatment of other format prefixes; now they are
considered global scope, "preferred" addresses.
Reiterated that anycast and multicast addresses are not allowed as
source addresses.
Recommended that source addresses be taken from the outgoing
interface. Required this for multicast destinations. Added analogous
requirements for link-local and site-local destinations.
Specified treatment of the loopback address.
Changed the second selection rule so that if both candidate source
addresses have scope greater or equal than the destination address
and only of them is preferred, the preferred address is chosen.
Draves Standards Track - Expires May 2000 11
Default Address Selection for IPv6 July 14, 2000
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Draves Standards Track - Expires May 2000 12

738
doc/draft/draft-skwan-gss-tsig-05.txt
View File

@@ -1,738 +0,0 @@
INTERNET-DRAFT Stuart Kwan
Praerit Garg
James Gilroy
Microsoft Corp.
February 2000
<draft-skwan-gss-tsig-05.txt> Expires August 2000
GSS Algorithm for TSIG (GSS-TSIG)
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
The TSIG protocol provides transaction level authentication for DNS.
TSIG is extensible through the definition of new algorithms. This
document specifies an algorithm based on the Generic Security Service
Application Program Interface (GSS-API) [RFC2078].
Expires August 2000 [Page 1]
INTERNET-DRAFT GSS-TSIG February 2000
Table of Contents
1: Introduction......................................................2
2: Protocol Overview.................................................3
2.1: GSS Details...................................................4
3: Client Protocol Details...........................................4
3.1: Negotiating Context...........................................4
3.1.1: Call GSS_Init_sec_context.................................5
3.1.2: Send TKEY Query to Server.................................6
3.1.3: Receive TKEY Query-Response from Server...................6
3.2: Context Established...........................................8
4: Server Protocol Details...........................................8
4.1: Negotiating Context...........................................8
4.1.1: Receive TKEY Query from Client............................9
4.1.2: Call GSS_Accept_sec_context...............................9
4.1.3: Send TKEY Query-Response to Client........................9
4.2: Context Established..........................................10
4.2.1: Terminating a Context....................................10
5: Sending and Verifying Signed Messages............................11
5.1: Sending a Signed Message - Call GSS_GetMIC...................11
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............12
6: Security Considerations..........................................12
7: Acknowledgements.................................................13
8: References.......................................................13
1. Introduction
The Secret Key Transaction Signature for DNS [TSIG] protocol was
developed to provide a lightweight alternative to full DNS security
[RFC2535] and secure dynamic update [RFC2137], where full security is
impractical due to implementation complexity, management overhead, or
computational cost.
The [TSIG] protocol is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic
Security Service Application Program Interface (GSS-API) [RFC2078].
GSS-API is a framework that provides an abstraction of security to the
application protocol developer. The security services offered can
include authentication, integrity, and confidentiality.
The GSS-API framework has several benefits:
* Mechanism and protocol independence. The underlying mechanisms that
realize the security services can be negotiated on the fly and varied
over time. For example, a client and server may use Kerberos for one
transaction, whereas that same server may use TLS with a different
client.
Expires August 2000 [Page 2]
INTERNET-DRAFT GSS-TSIG February 2000
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
developer does not need to create new key distribution or key
management systems. Instead the developer relies on the security
service mechanism to manage this on its behalf.
2. Protocol Overview
Readers that are unfamiliar with the GSS-API concepts are encouraged
to read the characteristics and concepts section of [RFC2078] before
examining this protocol in detail.
In GSS, client and server interact to create a "security context".
The security context is used to create and verify transaction
signatures on messages between the two parties. A unique security
context is required for each unique connection between client and
server.
Creating a security context involves a negotiation between client and
server. Once a context has been established, it has a finite lifetime
for which it can be used to secure messages. Thus there are three
states of a context associated with a connection:
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state.
Expires August 2000 [Page 3]
INTERNET-DRAFT GSS-TSIG February 2000
2.1 GSS Details
Client and server must be locally authenticated and have acquired
default credentials per [RFC2078] before using this protocol.
Not all flags used in GSS-API interfaces are specified in this
document. Where omitted, clients and servers may select the default
or use a value based on local system policy.
Not all error return values from GSS-API interfaces are specified in
this document. When errors are encountered, the caller should act
appropriately.
3. Client Protocol Details
A unique context is required for each server to which the client sends
secure messages. A context is identified by a context handle. A
client maintains a mapping of handles to servers,
(target_server_name, key_name, context_handle)
The value key_name also identifies a context handle, and is used on
the wire to indicate to a server which context should be used to
process the current request.
3.1 Negotiating Context
In GSS, establishing a security context involves the passing of opaque
tokens between the client and the server. The client generates the
initial token and sends it to the server. The server processes the
token and if necessary, returns a subsequent token to the client. The
client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
The TKEY resource record [TKEY] is used as the vehicle to transfer
tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [TKEY].
Expires August 2000 [Page 4]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.1 Call GSS_Init_sec_context
The client obtains the first token by calling GSS_Init_sec_context.
The following input parameters are used. The outcome of the call
is indicated with the output values below. Consult [RFC2078] for
syntax definitions.
INPUTS
CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = DNS/<target_server_name>
OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE
BOOLEAN deleg_req_flag = TRUE (optional)
OUTPUTS
INTEGER major_status
CONTEXT HANDLE output_context_handle
OCTET STRING output_token
BOOLEAN replay_det_state
BOOLEAN mutual_state
The values of replay_det_state and mutual_state indicate if the
security package can provide replay detection and mutual
authentication, respectively. If one or both of these values
are FALSE, the client must abandon this protocol.
The deleg_req_flag is optional, and can be used if the client wants
the server to be able to call out to other services under the
context of the client.
If major_status indicates an error, the client must abandon the
protocol. Success values of major_status are GSS_S_CONTINUE_NEEDED
and GSS_S_COMPLETE. The exact success code is important during later
processing.
The handle output_context_handle is unique to this negotiation and
is stored in the client's mapping table as the context_handle that
maps to target_server_name.
Expires August 2000 [Page 5]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.2 Send TKEY Query to Server
The output_token from GSS_Init_sec_context is transmitted to the
server in a query request for a TKEY record. The token itself
will be placed in a TKEY record in the additional records section of
the query. The domain-like name of the TKEY record set queried for
and the name of the supplied TKEY record in the additional section
will uniquely identify the security context to both the client and
server, and thus the client should use a value which is globally
unique.
TKEY Record
NAME = client-generated globally unique domain name string
(see [TKEY])
RDATA
Algorithm Name = gss-tsig.microsoft.com
Mode = 3 (GSS-API negotiation - see [TKEY])
Key Size = size of output_token
Key = output_token
Assign the remaining fields in the TKEY RDATA appropriate values
per [TKEY].
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_COMPLETE, then the message should be signed with a TSIG
record before being sent to the server. See section 5, Sending
and Verifying Signed Messages, for the signing procedure.
The query is transmitted to the server.
3.1.3 Receive TKEY Query-Response from Server
The server will return a standard TKEY query-response (see [TKEY]).
The response may indicate that TKEY is not supported, or that the
GSS-API mode and algorithm are not supported. If this is the case,
the client must abandon this algorithm.
If the value of the Error field in the TKEY RDATA (TKEY.Error) is
BADKEY, then the token provided by the client was invalid. The
client must abandon this algorithm.
If TKEY.Error indicates success, then the client may continue. The
next processing step depends on the value of major_status from the
most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or
GSS_S_CONTINUE.
Expires August 2000 [Page 6]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.3.1 Value of major_status == GSS_S_COMPLETE
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
then the client side component of the negotiation is complete and the
client is awaiting confirmation from the server.
Confirmation will be in the form of a NOERROR query response
containing the last client supplied TKEY record in the answer section
of the query. The response may also be signed with a TSIG record,
and if present this signature must be verified using the procedure
detailed in section 5, Sending and Verifying Signed Messages.
If the message verification completes without an error, or if a TSIG
signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.1.3.2 Value of major_status == GSS_S_CONTINUE
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_CONTINUE, then the negotiation is not yet complete. The
server will respond to the TKEY query with a NOERROR query response
that contains a TKEY record in the answer section. The TKEY record
contains a token that is passed to GSS_Init_sec_context using the
parameters from the previous call and the following modifications:
INPUTS
CONTEXT HANDLE input_context_handle = context_handle
OCTET STRING input_token = token from Key field of
TKEY record
OUTPUTS
INTEGER major_status
OCTET STRING output_token
If major_status indicates an error, the client must abandon this
algorithm. Success values are GSS_S_CONTINUE and GSS_S_COMPLETE.
If major_status is GSS_S_CONTINUE the negotiation is not yet
finished. The token output_token must again be passed to the server
in a TKEY record. The negotiation sequence is repeated beginning
with section 3.1.2. The client should place a limit on the number
of continuations in a context negotiation to prevent endless
looping.
Expires August 2000 [Page 7]
INTERNET-DRAFT GSS-TSIG February 2000
If major_status is GSS_S_COMPLETE and output_token is non-NULL,
the client-side component of the negotiation is complete but the
token output_token must be passed to the server. The negotiation
sequence is repeated beginning with section 3.1.2.
If major_status is GSS_S_COMPLETE and output_token is NULL, context
negotiation is complete. The response from the server may be signed
with a TSIG record, and if present this signature must be verified
using the procedure detailed in section 5, Sending and
Verifying Signed Messages.
If the message verification completes without an error, or if a TSIG
signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.2 Context Established
When context negotiation is complete, the handle context_handle is
used for the generation and verification of transaction signatures.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4. Server Protocol Details
As on the client-side, the result of a successful context negotiation
is a context handle used in future processing.
A server may be managing several contexts with several clients.
Clients identify their contexts by providing a key name in their
request. The server maintains a mapping of key names to handles:
(key_name, context_handle)
4.1 Negotiating Context
A server recognizes TKEY queries as security context negotiation
messages.
Expires August 2000 [Page 8]
INTERNET-DRAFT GSS-TSIG February 2000
4.1.1 Receive TKEY Query from Client
Upon receiving a TKEY query, the server must examine the Mode and
Algorithm Name fields to see if they match this algorithm. If they
match, the (key_name, context_handle) mapping table is searched for
the NAME value of the TKEY record. If the name is found in the table,
the corresponding context_handle is used in following GSS operations.
If the name is not found a new negotiation is started.
4.1.2 Call GSS_Accept_sec_context
The server performs its side of a context negotiation by calling
GSS_Accept_sec_context with the token provided by the client in the
TKEY record.
The server calls GSS_Accept_sec_context:
INPUTS
CONTEXT HANDLE input_context_handle = 0 if new negotiation,
context_handle if ongoing
OCTET STRING input_token = Key field from TKEY RR
OUTPUTS
INTEGER major_status
CONTEXT_HANDLE output_context_handle
OCTET STRING output_token
If this is the first call to GSS_Accept_sec_context in a new
negotiation, then output_context_handle is stored in the server's
key-mapping table as the context_handle that maps to the name of the
TKEY record.
4.1.3 Send TKEY Query-Response to Client
If major_status returns a GSS failure code, the negotiation has
failed. The server must respond to the client with a standard
TKEY query-response where the TKEY error field value is set to
BADKEY.
Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE.
Expires August 2000 [Page 9]
INTERNET-DRAFT GSS-TSIG February 2000
If major_status is GSS_S_COMPLETE the server component of the
negotiation is finished. The message from the client may be signed
with a TSIG RR, and if present this signature must be verified
using the procedure detailed in section 5, Sending and
Verifying Signed Messages. The server responds to the TKEY query
using a standard query response. If output_token is non-NULL, then it
must be returned to the client in a TKEY in the Answer section of the
response. If output_token is NULL, then the TKEY record received from
the client must be returned in the Answer section of the response.
The answer should be signed with a TSIG record per the procedure given
in section 5, Sending and Verifying Signed Messages.
The context state is advanced to Established. Section 4.2 discusses
the usage of the security context.
If major_status is GSS_S_CONTINUE, the server component of the
negotiation is not yet finished. The server responds to the TKEY
query with a standard query response, placing a TKEY record containing
output_token in the answer section. The negotiation sequence then
repeats beginning with section 4.1.1. The server must limit the
number of times that a given context is allowed to repeat, to prevent
endless looping.
4.2 Context Established
When context negotiation is complete, the handle context_handle
is used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server may unilaterally terminate
a context at any time.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4.2.1 Terminating a Context
A server can terminate any established context at any time. The
server may hint to the client that the context is being deleted
by including a TKEY RR in a response with the mode field set to
"key deletion". See [TKEY] for more details.
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
Expires August 2000 [Page 10]
INTERNET-DRAFT GSS-TSIG February 2000
5. Sending and Verifying Signed Messages
5.1 Sending a Signed Message - Call GSS_GetMIC
The procedure for sending a signature-protected message is specified
in [TSIG]. The data to be passed to the signature routine includes
the whole DNS message with specific TSIG variables appended. For the
exact format, see [TSIG]. For this protocol, use the following
TSIG variable values:
TSIG Record
NAME = key_name that identifies this context
RDATA
Algorithm Name = gss-tsig.microsoft.com
Assign the remaining fields in the TKEY RDATA appropriate values
per [TKEY].
For the GSS algorithm, the signature is generated by calling
GSS_GetMIC:
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = outgoing message plus TSIG
variables (see [TSIG])
OUTPUTS
INTEGER major_status
OCTET STRING per_msg_token
If major_status is GSS_S_COMPLETE, then signature generation
succeeded. The signature in per_msg_token is inserted into the
Signature field of the TSIG RR and the message is transmitted.
If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED,
the caller needs to return to the uninitialized state and negotiate
a new security context.
Expires August 2000 [Page 11]
INTERNET-DRAFT GSS-TSIG February 2000
5.2 Verifying a Signed Message - Call GSS_VerifyMIC
The procedure for verifying a signature-protected message is specified
in [TSIG].
The NAME of the TSIG record determines which context_handle
maps to this context. If the NAME does not map to a currently active
context, the server must send a standard TSIG error response to the
client indicating BADKEY in the TSIG error field (see [TSIG]).
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = incoming message plus TSIG
variables (see [TSIG])
OCTET STRING per_msg_token = Signature field from TSIG RR
OUTPUTS
INTEGER major_status
If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [TSIG], the timer values of the
TSIG record must also be valid before considering the message to be
authentic. The caller must not act on the request or response in the
message until these checks are verified.
If major_status is GSS_S_CONTEXT_EXPIRED, the negotiated context is no
longer valid. If this failure occurs when a server is processing a
client request, the server must send a standard TSIG error response
to the client indicating BADKEY in the TSIG error field (see [TSIG]).
If major_status is any other error code or if the timer values of the
TSIG record are invalid, the message must not be considered authentic.
If this error checking fails when a server is processing a client
request, the appropriate error response must be sent to the client
per [TSIG].
6. Security Considerations
This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
Expires August 2000 [Page 12]
INTERNET-DRAFT GSS-TSIG February 2000
7. Acknowledgements
The authors of this document would like to thank the following people
for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan and Donald E. Eastlake 3rd.
8. References
[RFC2078] J. Linn, "Generic Security Service Application Program
Interface, Version 2," RFC 2078, OpenVision Technologies,
January 1997.
[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key
Transaction Signatures for DNS (TSIG),"
draft-ietf-dnsind-tsig-*..txt, ISC, TIS, Cybercash.
[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY
RR)," draft-ietf-dnssec-tkey-*.txt.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
RFC 2535, IBM, March 1999.
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
9. Author's Addresses
Stuart Kwan Praerit Garg
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
<skwan@microsoft.com> <praeritg@microsoft.com>
James Gilroy
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
<jamesg@microsoft.com>
Expires August 2000 [Page 13]

11
doc/draft/draft-skwan-gss-tsig-06.txt Normal file
View File

@@ -0,0 +1,11 @@
This document has been replaced by draft-ietf-dnsext-gss-tsig-00.txt.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
S. Kwan: skwan@microsoft.com
J. Gilroy: jamesg@microsoft.com
P. Garg: praeritg@microsoft.com

35
doc/draft/draft-skwan-utf8-dns-03.txt → doc/draft/draft-skwan-utf8-dns-04.txt
View File

@@ -1,9 +1,8 @@
INTERNET-DRAFT Stuart Kwan
James Gilroy
Microsoft Corp.
February 2000
<draft-skwan-utf8-dns-03.txt> Expires August 2000
July 2000
<draft-skwan-utf8-dns-04.txt> Expires January 2001
Using the UTF-8 Character Set in the Domain Name System
@@ -34,8 +33,8 @@ http://www.ietf.org/shadow.html.
Abstract
The Domain Name System standard specifies that names are represented
using the ASCII character encoding. This document expands that
The Domain Name System standard specifies that names are represented
using the ASCII character encoding. This document expands that
specification to allow the use of the UTF-8 character encoding, a
superset of ASCII and a translation of the UCS-2 character encoding.
@@ -50,10 +49,10 @@ superset of ASCII and a translation of the UCS-2 character encoding.
Expires August 2000 [Page 1]
Expires January 2001 [Page 1]
INTERNET-DRAFT UTF-8 DNS February 2000
INTERNET-DRAFT UTF-8 DNS July 2000
1. Introduction
@@ -106,10 +105,10 @@ UTF-8 characters before transmitting those names in any message.
Expires August 2000 [Page 2]
Expires January 2001 [Page 2]
INTERNET-DRAFT UTF-8 DNS February 2000
INTERNET-DRAFT UTF-8 DNS July 2000
For consistency, UTF-8-aware DNS servers must compare names that
@@ -152,7 +151,7 @@ containing UTF-8 names to a non-UTF-8-aware DNS server.
4. Security Considerations
The choice of character encoding for names does not impact the
security of the DNS protocol.
security of the DNS protocol.
5. Acknowledgements
@@ -163,10 +162,10 @@ Cliff Van Dyke and Bjorn Rettig.
Expires August 2000 [Page 3]
Expires January 2001 [Page 3]
INTERNET-DRAFT UTF-8 DNS February 2000
INTERNET-DRAFT UTF-8 DNS July 2000
6. References
@@ -174,7 +173,7 @@ INTERNET-DRAFT UTF-8 DNS February 2000
[RFC1035] P.V. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1035, ISI, Nov 1987.
[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646," RFC 2044, Alis Technologies, Oct 1996.
[RFC1958] B. Carpenter, "Architectural Principles of the
@@ -183,11 +182,11 @@ INTERNET-DRAFT UTF-8 DNS February 2000
[RFC1123] R. Braden, "Requirements for Internet Hosts -
Application and Support," STD 3, RFC 1123, January 1989.
[RFC2130] C. Weider et. al., "The Report of the IAB Character
Set Workshop held 29 February - 1 March 1996",
[RFC2130] C. Weider et. al., "The Report of the IAB Character
Set Workshop held 29 July - 1 March 1996",
RFC 2130, Apr 1997.
[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
Specification," RFC 2181, University of Melbourne and
RGnet Inc, July 1997.
@@ -220,6 +219,8 @@ USA USA
Expires August 2000 [Page 4]
Expires January 2001 [Page 4]