mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 14:07:59 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 2000-12-13 18:16:16 +00:00
parent cdb41f0dc3
commit fe9c5d2fc5
6 changed files with 1569 additions and 2103 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1072
doc/draft/draft-ietf-dhc-dhcp-dns-12.txt
View File

File diff suppressed because it is too large Load Diff

20
doc/draft/draft-ietf-dhc-dhcp-dns-13.txt Normal file
View File

@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
Y. Rekhter: yakov@cisco.com
M. Stapp: mark@american.com

336
doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt
View File

@ -1,336 +0,0 @@
Network Working Group A. Gustafsson
Internet-Draft T. Lemon
Expires: January 12, 2001 Nominum, Inc.
M. Stapp
Cisco Systems, Inc.
July 14, 2000
A DNS RR for encoding DHCP information
<draft-ietf-dnsext-dhcid-rr-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes
storing client identifiers in the DNS to unambiguously associate
domain names with the DHCP clients "owning" them. This memo defines
a distinct RR type for use by DHCP servers, the "DHCID" RR.
Gustafsson, et. al. Expires January 12, 2001 [Page 1]
Internet-Draft A DNS RR for encoding DHCP information July 2000
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6
Gustafsson, et. al. Expires January 12, 2001 [Page 2]
Internet-Draft A DNS RR for encoding DHCP information July 2000
1. Terminology
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[1].
2. Introduction
A set of procedures to allow DHCP [RFC2131] clients and servers to
automatically update the DNS (RFC1034[2], RFC1035[3]) is proposed in
Resolution of DNS Name Conflicts[7].
A situation can arise where multiple DHCP clients wish to use the
same DNS name. To resolve such conflicts, Resolution of DNS Name
Conflicts[7] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it would be preferable for this
DHCP information to use a distinct RR type.
This memo defines a distinct RR type for this purpose for use by
DHCP clients or servers, the "DHCID" RR.
3. The DHCID RR
The DHCP RR is defined with mnemonic DHCID and type code [TBD].
4. DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its
interpretation by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented as a hexadecimal string with
an optional "0x" or "0X" prefix. Periods (".") may be inserted
anywhere after the "0x" for readability. This format is identical
to that of the NSAP RR (RFC1706[4]). The number of hexadecimal
digits MUST be even.
DHCP clients or servers use the DHCID RR to associate a DHCP
client's identity with a DNS name, so that multiple DHCP clients and
servers may safely perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record consists
of a 16-bit identifier type, followed by one or more bytes
representing the actual identifier. There are two possible forms
for a DHCID RR - one that is used when the DHCP server is using the
client's link-layer address to identify it, and one that is used
when the DHCP server is using some DHCP option that the DHCP client
sent to identify it. When the link-layer address is used as the
Gustafsson, et. al. Expires January 12, 2001 [Page 3]
Internet-Draft A DNS RR for encoding DHCP information July 2000
identifier, the first two bytes of the RRDATA are set to 0. When a
DHCP option is used as the identifier, the first two bytes of the
RRDATA contain the option number, in network byte order. The two
bytes 0xffff are reserved. In both cases, the remainder of the
RRDATA is the result of performing a one-way hash across the
identifier.
The details of the method used to generate the data in the RR and
the use to which a DHCP client or server may put this association
are beyond the scope of this draft, and are discussed in the draft
that specifies the DNS update behavior, 'Resolution of DNS Name
Conflicts'[7]. This RR MUST NOT be used for any purpose other than
that detailed in the DHC document. Althought this RR contains data
that is opaque to DNS servers, the data is meaningful to DHCP
updaters. Therefore, new data formats may only be defined through
actions of the DHC Working Group.
4.1 Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might use the client's link-layer address to
identify the client:
client.org.nil. A 10.0.0.1
client.org.nil. DHCID
00.00.18.29.11.17.22.0a.ad.c1.88.10.a3.dd.ff.c8.d9.49
A DHCP server allocating the IPv4 address 10.0.12.99 to a client
"chi.org.nil" might use the DHCP client identifier option to
identify the client:
chi.org.nil. A 10.0.12.99
chi.org.nil. DHCID 00.61.92.71.22.da.01.88.dd.3a.11.8c.1c.a0.ff.94.9d.81
5. Security Considerations
The DHCID record as such does not introduce any new security
problems into the DNS. In order to avoid exposing private
information about DHCP clients to public scrutiny, a one-way-hash is
used to obscure all client information.
6. IANA Considerations
The IANA is requested to allocate an RR type number for the DHCP
record type.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Gustafsson, et. al. Expires January 12, 2001 [Page 4]
Internet-Draft A DNS RR for encoding DHCP information July 2000
[2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987.
[3] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987.
[4] Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC
1706, Oct 1994.
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
1997.
[6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Mar 1997.
[7] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-dns-resolution-*)", July 2000.
Authors' Addresses
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: gson@nominum.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: mellon@nominum.com
Mark Stapp
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
USA
Phone: 978.244.8498
EMail: mjs@cisco.com
Gustafsson, et. al. Expires January 12, 2001 [Page 5]
Internet-Draft A DNS RR for encoding DHCP information July 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Gustafsson, et. al. Expires January 12, 2001 [Page 6]

448
doc/draft/draft-ietf-dnsext-dhcid-rr-01.txt Normal file
View File

@ -0,0 +1,448 @@
Network Working Group M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: June 1, 2001 T. Lemon
A. Gustafsson
Nominum, Inc.
December 2000
A DNS RR for Encoding DHCP Information
<draft-ietf-dnsext-dhcid-rr-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, 'Resolution of DNS Name Conflicts'[5] proposes
storing client identifiers in the DNS to unambiguously associate
domain names with the DHCP clients "owning" them. This memo defines
a distinct RR type for use by DHCP servers, the "DHCID" RR.
Stapp, et. al. Expires June 1, 2001 [Page 1]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
Stapp, et. al. Expires June 1, 2001 [Page 2]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
1. Terminology
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[1].
2. Introduction
A set of procedures to allow DHCP[2] clients and servers to
automatically update the DNS (RFC1034[3], RFC1035[4]) is proposed in
"Resolution of DNS Name Conflicts"[5].
A situation can arise where multiple DHCP clients wish to use the
same DNS name. To resolve such conflicts, Resolution of DNS Name
Conflicts[5] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it would be preferable for this
DHCP information to use a distinct RR type.
This memo defines a distinct RR type for this purpose for use by
DHCP clients or servers, the "DHCID" RR.
3. The DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code [TBD].
4. DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its
interpretation by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented in base 64 (see Appendix A)
and may be divided up into any number of white space separated
substrings, down to single base 64 digits, which are concatenated to
obtain the full signature. These substrings can span lines using
the standard parenthesis. This format is identical to that used for
representing binary data in DNSSEC (RFC2535[6]).
DHCP clients or servers use the DHCID RR to associate a DHCP
client's identity with a DNS name, so that multiple DHCP clients and
servers may safely perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record consists
of a 16-bit identifier type, followed by one or more bytes
representing the actual identifier. There are two possible forms
for a DHCID RR - one that is used when the DHCP server is using the
client's link-layer address to identify it, and one that is used
when the DHCP server is using some DHCP option that the DHCP client
Stapp, et. al. Expires June 1, 2001 [Page 3]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
sent to identify it. When the link-layer address is used as the
identifier, the first two bytes of the RRDATA are set to 0. When a
DHCP option is used as the identifier, the first two bytes of the
RRDATA contain the option number, in network byte order. The two
bytes 0xffff are reserved for future extensibility. In both cases,
the remainder of the RRDATA is the result of performing a one-way
hash across the identifier.
The details of the method used to generate the data in the RR and
the use to which a DHCP client or server may put this association
are beyond the scope of this draft, and are discussed in the
specification of the DNS update behavior, 'Resolution of DNS Name
Conflicts'[5]. This RR MUST NOT be used for any purpose other than
that detailed in the DHC document. Althought this RR contains data
that is opaque to DNS servers, the data is meaningful to DHCP
updaters. Therefore, new data formats may only be defined through
actions of the DHC Working Group.
4.1 Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might use the client's link-layer address to
identify the client:
client.org.nil. A 10.0.0.1
client.org.nil. DHCID AAAY KREX Igqt wYgQ o93/ yNlJ
A DHCP server allocating the IPv4 address 10.0.12.99 to a client
"chi.org.nil" might use the DHCP client identifier option to
identify the client:
chi.org.nil. A 10.0.12.99
chi.org.nil. DHCID AGGS cSLa AYjd OhGM HKD/ lJ2B
5. Security Considerations
The DHCID record as such does not introduce any new security
problems into the DNS. In order to avoid exposing private
information about DHCP clients to public scrutiny, a one-way-hash is
used to obscure all client information.
6. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
7. Appendix A: Base 64 Encoding
The following encoding technique is taken from RFC 2045[7] by N.
Stapp, et. al. Expires June 1, 2001 [Page 4]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Borenstein and N. Freed. It is reproduced here in an edited form
for convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to
right, a 24-bit input group is formed by concatenating 3 8-bit input
groups. These 24 bits are then treated as 4 concatenated 6-bit
groups, each of which is translated into a single digit in the base
64 alphabet.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string.
The Base 64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a quantity. When fewer than 24 input
bits are available in an input group, zero bits are added (on the
right) to form an integral number of 6-bit groups. Padding at the
end of the data is performed using the '=' character. Since all
base 64 input is an integral number of octets, only the following
cases can arise: (1) the final quantum of encoding input is an
integral multiple of 24 bits; here, the final unit of encoded output
Stapp, et. al. Expires June 1, 2001 [Page 5]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
will be an integral multiple of 4 characters with no "=" padding,
(2) the final quantum of encoding input is exactly 8 bits; here, the
final unit of encoded output will be two characters followed by two
"=" padding characters, or (3) the final quantum of encoding input
is exactly 16 bits; here, the final unit of encoded output will be
three characters followed by one "=" padding character.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
1997.
[3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987.
[4] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987.
[5] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-dns-resolution-*)", July 2000.
[6] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
USA
Phone: 978.244.8498
EMail: mjs@cisco.com
Stapp, et. al. Expires June 1, 2001 [Page 6]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: mellon@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: gson@nominum.com
Stapp, et. al. Expires June 1, 2001 [Page 7]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Stapp, et. al. Expires June 1, 2001 [Page 8]

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

@ -1,695 +0,0 @@
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

1101
doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt Normal file
View File

File diff suppressed because it is too large Load Diff